There Is No Right Page Count, and Here Is What to Count Instead

Nobody can tell you a page count before seeing your site, and a firm that offers one is quoting a package rather than answering your question. The number you need is whatever it takes to cover four things. Every distinct template. Every journey, from its first step to its last. Every state those pages can be in. And every layout each template presents at a different screen size. Count those four, add a random tenth on top, and the page count falls out at the bottom instead of being picked at the start and hoped over.

On most sites that lands somewhere between 10 and 25 pages, and the reason is the first of the four. A shop with 40,000 products has one product template, so testing 40 of them tells you almost exactly what testing one told you. What it does not tell you is anything about the checkout, the account screens, the search results with nothing in them, or the same product page as it arranges itself on a phone. Those are the rows that get missed, and they are the rows that decide whether the audit was worth buying.

The rest of this page is the worksheet. It runs in five passes, the first four you can do from your own sitemap in an afternoon, and the fifth is the one almost nobody does. After it there is a short summary of the method the passes come from, and then the one thing no page count can buy you, however large it gets.

Your Scope Is the Whole Product, and the Sample Is What Gets Opened

One correction before the counting starts, because getting this backwards is the most expensive mistake on the page. Your scope is not the pages being tested. Your scope is the product, all of it, and the pages being tested are a sample drawn from inside that scope. Those are two different lines in a proposal and they answer two different questions.

W3C's evaluation methodology is firm about which way round it goes. It asks for full product enclosure, meaning the scope covers every view, state and piece of functionality without carving parts out, and it gives the reason plainly. Excluding parts of a product from scope tends to collide with the conformance requirements for full pages and for complete processes, or else it quietly distorts the result. So the sentence that reads well in a proposal, the one saying the marketing site is in scope and the customer portal is not, has moved a limitation into a place where nobody has to own it.

Say the same thing the other way and it stops costing you anything. The product is the whole site. The sample is 19 pages of it. The pages nobody opened stay inside the scope and outside the evidence, which is exactly what the report should say. That framing survives a regulator, a client and your own team six months later, and the carved-out version does not.

It also raises a possibility worth checking before you sample at all. If your site is genuinely small, test all of it. The method recommends evaluating the entire product wherever that is feasible, and sampling is what you reach for when it is not. A twelve-page brochure site does not need a sampling strategy. It needs somebody to open twelve pages.

Count Templates First, Because Your Pages Repeat Them

A template is a layout your site fills with different content. Four hundred blog posts share one. Every product page on a store shares another. So a finding on the listing template is a finding on all 4,000 listing pages at once, which is why counting templates gives you an estimate a plan can hold and counting URLs gives you a number that means nothing.

This is also why testing more pages of the same kind stops paying quickly. The second product page confirms the first. The tenth tells you nothing new unless something about it genuinely differs, and if something does differ then it was a second template all along and belongs on its own row.

That is the splitting rule for the whole worksheet. Two pages belong on one row when the markup behind them is the same and only the content changes. They split into two rows the moment a component appears on one and not the other, because the component is the thing being tested. A product page with a video player, a size chart in a modal and a reviews widget is a different piece of work from a product page with none of those, whatever the theme file is called.

The Scope Worksheet, in Five Passes

Take a blank sheet and give it one column for the row name and one for why the row exists. Each pass below adds rows. Nothing gets removed once it is written down, because a row you decide to leave out of the audit is still a row somebody should know was left out, and the report can say so.

Pass One, the Template Inventory

List every layout your site uses, once each. Most sites have somewhere between six and a dozen, and the list is usually shorter than the team expects until the utility pages get added at the end.

• The home page, which is nearly always its own template and shares markup with nothing else.
• Listing pages, so a category, an archive, a blog index, a search results page. Search results split off when they can come back empty, because an empty state is different markup.
• Detail pages, so a product, an article, a profile, a property, a course.
• Forms, counted per form rather than per page. A contact form and a multi-step application are two rows even when they share a theme.
• Account and settings screens, which almost always sit behind a login and almost always get left off a first draft of the scope.
• Utility pages, so the 404, the sign-in screen, the accessibility statement, the help and contact pages, and anything explaining how to use the settings. W3C's evaluation method asks for these as a group of their own, alongside anything sensitive or high risk, which it names as authentication, managing personal information and financial transactions.

Pass Two, the Complete-Journey Inventory

A checkout is not a page and cannot be counted like one. Where a series of pages makes up a complete process, the standard requires every page in that series to conform before any single page in it counts as conforming. So an untested step five is not a small gap in the evidence. It is the reason steps one to four cannot be signed off.

That makes journeys the second unit of the worksheet, and the way to list them is to write the first step and the last step rather than a set of addresses. Then add the branches, meaning the routes people commonly take that a straight run through would never touch. The table below is the shape to copy, filled with the journeys we meet most often.

Two details make this inventory usable rather than decorative. Record the default route first, meaning the run where nobody makes a mistake and nothing unusual is chosen, so a checkout paid with the saved card and the stored address. Then record the branches separately, because a branch is extra work and pricing it as part of the straight run is how a quote comes in low.

And write down the actions, not only the addresses. Half the steps in a journey share one URL or have no URL at all, so a scope that lists addresses cannot describe them. Fill in name and address, press Continue. Choose the second delivery option, press Pay. Without that, nobody can reproduce a finding on step three, and that includes your own developer in three months when the ticket comes back disputed.

Pass Three, the States Each Page Can Be In

A state is the same page after something has happened to it. States are where most of the serious findings live, because they are the parts a crawler never reaches, and they are the parts that only exist once a person has pressed something. Our own free scan sees each page once in the state it arrives in, which is exactly the limit this pass exists to fill.

• Signed out and signed in, and then once more for every role that sees a different screen. An admin, a manager and an ordinary member are three rows, not one.
• Empty and full. An empty cart, a search with no results, an account with no orders yet, a table with one row and a table with two hundred.
• Every error state, per field and per form. The message nobody announces only exists after somebody presses the button.
• Every success state, so the confirmation, the saved banner, the sent message. These are the ones that get missed because nothing looks broken.
• Anything that opens over the page, so modals, drawers, cookie banners, chat launchers, date pickers and menus. Each one changes where keyboard focus is allowed to go.
• Anything on a timer, so a session timeout warning, a held booking slot, a carousel that advances on its own, a toast that disappears.

Count states as rows even when they have no address of their own, because the testing effort is real whether or not the URL changes. A five-step wizard with one error state and a confirmation is seven rows on this worksheet, and the scope that called it one page was wrong by six.

Pass Four, the Layouts Each Template Presents

The standard counts each layout a responsive page presents at a different screen size as a variation that has to conform on its own. So a template whose narrow arrangement is a genuinely different composition, with a different navigation pattern, a different table treatment or controls that only exist on one of them, is closer to two rows than one.

Most sites do not need a second row for every template. A layout that reflows the same components into one column is usually the same piece of work. A layout that swaps a horizontal menu for a hamburger, collapses a data table into cards, or hides a control behind a gesture is not, and those are the ones to write down.

You should have this from us before you buy rather than after. Our own testing is desktop-based, so a failure that only appears on a narrow screen is outside what we looked at rather than absent from your site. If your traffic is mostly mobile, that is worth saying out loud while scope is being confirmed, because it changes whether this is the right thing for you to buy at all.

Pass Five, the Random Tenth on Top

Now the pass almost nobody does, and it costs less than the argument it prevents. Everything you have written down so far was chosen on purpose, which means it can flatter you without anybody intending it to. So add a second set, drawn at random from anywhere inside the scope, sized at ten percent of the rows you already have. It goes on top rather than replacing any of them, and if a random draw lands on a row you already listed, swap it for another.

The point is not extra coverage. The random set is a test of your own sampling, and it has a defined failure condition attached. If the random rows turn up kinds of content or kinds of finding the chosen rows missed, your chosen rows were not representative, and the honest response is to go back to pass one and add more. You repeat that until the random slice stops surprising you.

Write down how the draw was made, too. A sample somebody can check is worth far more than a sample somebody has to trust, and the difference between the two is one sentence in the report.

What the Worksheet Adds Up To

Here is the arithmetic on a small store, built as an illustration rather than taken from a client engagement. Your own numbers will differ, and the shape almost never does.

Nineteen rows on a shop the owner would have described as a ten-page site. That gap is the whole reason to do this on paper before anybody quotes, because the ten-page version of that scope would have tested the product page four times and the checkout not at all.

WCAG-EM 2.0, the Published Method These Passes Come From

Passes two, three and five are not house style. They come from W3C's own evaluation methodology, WCAG-EM, which is free to read and worth knowing about by name if you are buying an audit or writing a brief for one.

One thing to hold on to first. WCAG-EM is a W3C Group Note, which means it advises rather than requires, and nothing conforms to it. That makes it the wrong document to name in a compliance clause and a very good one to measure a proposal against. Nobody can require you to follow it. Anybody can hold an audit report up against it and see what is missing.

The version matters too, because the current edition is a rewrite rather than a reprint, and even its name changed. The 2014 original was the Website Accessibility Conformance Evaluation Methodology, written about websites and web pages. The edition published in July 2026 is the WCAG Evaluation Methodology, written about digital products and views, which stretches it over web apps, mobile apps, kiosks, e-books and documents as well. So guidance describing WCAG-EM purely in terms of websites is describing the older document, and that is a quick way to date an article you found while comparing suppliers.

Five steps, in the buyer's version.

1. 1Define the scope. What is being evaluated, which conformance level is being targeted, and which browsers and assistive technologies the product is expected to work with. Level AA is named there as the generally accepted and recommended target. The browser and assistive technology list is the accessibility support baseline, and the method has it settled in consultation with whoever commissioned the work rather than chosen quietly by whoever tests.
2. 2Explore the product. Find the common views, the tasks that matter, the kinds of page, the technologies the site depends on, and the other views the method names specially, which run from help and settings through to sign-in and payment. This is pass one of the worksheet, done by the evaluator.
3. 3Select the sample. Build the structured set, add a random set at a tenth of its size, then pull in every step of every process the sample touches. That is passes two and five.
4. 4Evaluate. Check every sample against the success criteria at the target level, and then against the three conformance requirements people forget, which are conforming alternate versions, accessibility support and non-interference. Then compare the structured set against the random one to see whether the choosing was fair.
5. 5Report. Write down the outcome of the four steps above, including the baseline, the technologies relied upon, the random sample with the method used to draw it, and the complete processes. Those four are the ones commercial reports most often leave out.

That summary is deliberately short, because the full account of the method, the report minimum and the five questions to ask a supplier all live on a page of their own. Read the audit method W3C publishes if you are about to compare proposals, and read how our own three passes work if you want to see where ours borrows from it and where it departs.

What No Page Count Can Buy You

Conformance in WCAG is defined for a web page, and only for a web page. A conformance claim is allowed to cover more than one, and the standard says so plainly, because a claim may be made for a single page, for a series of pages, or for multiple related pages. What the standard does not do is loosen the requirement underneath. Every page inside the claim has to conform, so a claim is assembled out of per-page results rather than estimated across a site.

That is where a sample stops. W3C's evaluation methodology states that a conformance claim cannot be made for an entire website on the strength of an evaluation of a selected sub-set of its pages and functionality, and the reason it gives is stronger than the one people assume. Not that samples are careless. That it is always possible an unexamined page carries an error, which is a problem no sample size solves. Nineteen rows do not solve it. Neither do 200.

So a bigger worksheet buys you better evidence and a better guide to the templates behind the pages you opened. It never converts a sample into a certificate covering the URLs nobody looked at. Our pricing page says the same thing in nearly the same words under the heading about what none of the tiers buys you, and it says it before the money moves rather than after.

Turning the Worksheet Into an Order

Bring the filled sheet and the conversation gets short. The row count tells you which tier fits, the journey column tells us which steps have to be reachable, and the states column tells us what has to exist in whatever environment we are given. All three of those are published, so you can work out the fit before you speak to anybody. What each tier costs, how many pages it covers and what the report records are all on the pricing page, and the format itself is readable in full in the sample report.

One row on the sheet decides more than the rest. If a journey you care about sits behind a login, say so at the point of ordering, because access is the single most common reason an audit sits waiting. What to prepare before an audit covers the accounts, the test data and the privacy arrangements that go with that, and it is worth reading before you order rather than after.