Skip to content
wcagc
←Back to blog
full site scanWCAGsamplingEAAEN 301 549

Why homepage-only scans miss your real accessibility risk

WCAG conformance applies to full pages and complete processes. Here is what a homepage-only scan cannot tell you, and what to scan instead.

P

Pavel Charkasau

A homepage scan tests one URL. WCAG conformance does not work that way: it applies to full pages and to every page in a complete process, so a clean result on your home page says nothing about your signup, your checkout, or your account settings (W3C). That is the gap. WebAIM's February 2026 analysis found detected WCAG failures on 95.9% of the top million home pages, an average of 56.1 errors per page, and WebAIM says plainly that it measured "only 1,000,000 home pages" (WebAIM). Even that study, run on the most polished page most companies own, is not a verdict on the site behind it. A full site accessibility scan crawls the templates a home page never touches: the product listing, the multi-step form, the checkout, everything behind a login. Those are where people get stuck and give up. Run the single-page check if you want a first signal. Just do not file it as evidence of anything beyond that one page.

What does a homepage scan actually cover?

One URL, rendered once, checked against the rules a machine can decide on its own.

That is genuinely useful work. A scanner parses the DOM after JavaScript has run and flags what it can prove from the code: a contrast ratio of 3.1:1 on grey footer text, an <img> with no alt, a <button> with no accessible name, so a screen reader announces "button" and nothing else. WebAIM's 2026 run shows how repetitive those failures are across the web. Low-contrast text appeared on 83.9% of home pages, missing image alternatives on 53.1%, missing form input labels on 51%, empty links on 46.3% (WebAIM).

Now look at what those failure types have in common. They live in the header, the footer, the button styles, the icon set. Template-level defects, in other words, which appear on every page of the site. A homepage scan catches them because they happen to also be on the home page, not because the home page holds anything special. Step off that URL and you are into templates the scan never loaded: the search results grid, the filter sidebar, the date picker inside a booking form, the payment step.

Here is the opinion I will put my name to. The home page is the page your team has already fixed. It gets designed first and reviewed most, then demoed to whoever signs off on the budget. That makes it the least representative page you own.

Why doesn't WCAG conformance work page by page?

Because the standard rules it out, in two separate requirements.

Conformance requirement 2, full pages: "Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded" (W3C).

Conformance requirement 3, complete processes: "When a web page is one of a series of web pages presenting a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), all web pages in the process conform at the specified level or better" (W3C).

Read that second one with a checkout in mind. Cart, shipping, payment, confirmation. If the payment step ships a date picker that a keyboard user cannot operate, the process does not conform at AA, and neither does any individual page inside it for the purpose of that claim. A spotless home page does not offset it. Conformance is not an average across your URLs.

This is also why "our accessibility score is 94" is a number without a unit. A score describes the pages someone tested, at the moment they tested them. It carries no information about the pages nobody visited.

Where do the barriers that matter actually live?

In the parts of the site where a user has to finish something.

The failures that stop a task cluster in interactive, stateful pages:

  • Multi-step forms. Submit an incomplete form and listen. Does anything get announced, does focus move to the error, and is the failing field named, or just outlined in red?
  • Everything behind a login. Account settings, order history, the onboarding wizard, the dashboard your customers use daily. An anonymous crawler never sees any of it.
  • Components that exist only after an interaction. A modal that traps focus, an autocomplete whose results are never announced, or the cookie banner that eats your first Tab press. None of this is in the initial HTML the crawler fetched.
  • Content types your home page does not have. Data tables, PDF invoices, a video player, an embedded map, a third-party payment iframe.

There is a second ceiling stacked on top of the coverage problem, and it is worth naming. Automated tools catch roughly 30 to 57% of accessibility issues depending on how you count. By success criteria, the machine-decidable share sits at the low end. By volume of individual issues, Deque's review of more than 2,000 audits across roughly 13,000 pages put automated coverage at about 57% (Deque). WebAIM makes the same point about its own tool: "Absence of detected errors does not indicate that a page is accessible or conformant" (WebAIM). So a homepage-only scan gives you a partial method applied to a single page. Two limits multiplied together, then reported as a status.

How do you choose which pages to scan?

Follow the W3C's evaluation methodology, WCAG-EM, which has a step for exactly this. Step 3 tells you to build a structured sample covering common views, essential functionality, the different types of view, the technologies relied upon, and other relevant views such as pages that describe your accessibility features (W3C). Essential functionality is illustrated with the obvious example: selecting and purchasing products from a web shop.

Two further parts of step 3 do the heavy lifting:

Random sampling. WCAG-EM asks you to add a random selection worth 10% of the structured sample set (W3C). The point is to catch what your own assumptions skipped. Teams pick the pages they already think about, and the broken ones tend to be elsewhere.

Complete processes. Step 3.3 says to include all views that belong to a series presenting a complete process, which means the default path and the realistic alternatives through it (W3C). If a user can pay by card or by invoice, both branches are in scope.

WCAG-EM also says to evaluate the whole product where that is feasible, and to sample only when it is not. On a 40-page marketing site, feasible means all 40. Sampling is a concession to size, not a default.

A practical order that works: crawl the site to get the machine-checkable failures off the board across every template, then take the two or three journeys your business depends on and walk them by hand with a keyboard and a screen reader. Our scanner will not tell you whether the focus order in your checkout makes sense. That part needs a person, and no honest vendor will claim otherwise.

What does a full site accessibility scan mean for EAA and EN 301 549 evidence?

Under the European Accessibility Act, the obligation attaches to the service, not to a landing page. Consumer-facing e-commerce, banking, transport booking, and e-books have been in scope for new services since 28 June 2025 (EUR-Lex). The technical bar is EN 301 549, whose clause 9 incorporates WCAG 2.1 Level AA for the web, and Annex C is the clause-by-clause table where each requirement is recorded as met, not met, or not applicable.

That table is where homepage-only testing falls apart on contact with paper. You cannot mark clause 9 requirements "met" for a service when you tested the entry page and never opened the transaction. The honest entry in that case is "not met" or a documented partial, with the untested scope written down. The same discipline applies to your accessibility statement, which documents what you evaluated and what you know is still broken. It is a record of effort, not a clearance certificate.

Overstating what a scan proves is not a theoretical risk either. The US Federal Trade Commission's final order against accessiBe, approved in April 2025, required a $1 million payment and barred unsupported claims that its automated product made websites compliant (FTC). Scope inflation is the same species of claim. If your evidence covers one page, say one page.

Frequently asked questions

Is a homepage accessibility scan useless?

No. It is a fast, cheap first signal that finds template-level failures such as low contrast, missing image alternatives, and unlabelled form fields, which WebAIM's 2026 data shows are extremely common (WebAIM). It becomes a problem only when a single-page result is presented as the accessibility status of a whole site.

How many pages should a full site accessibility scan cover?

Every page, where that is feasible. WCAG-EM recommends evaluating the entire product when practical and sampling only when it is not, in which case you build a structured sample of common views, essential functionality, view types and technologies, add a random sample worth 10% of it, and include all views in every complete process (W3C).

Can an automated scanner test pages behind a login?

Only if it can authenticate. An anonymous crawler stops at the login form, so account areas, dashboards, and post-purchase flows go untested by default. Testing those requires a scanner configured with credentials or a scripted journey that walks the steps in order.

Does a passing homepage scan help with EAA compliance?

Only as partial evidence. The EAA applies to the service as a whole, and EN 301 549 clause 9 conformance is recorded per requirement in the Annex C table. A result covering one page supports a claim about one page, and the untested scope belongs in your accessibility statement.

Why do accessibility problems concentrate in checkout and signup?

Because those pages carry the most interaction: custom widgets, validation states, focus movement, and content that appears only after a user action. Static marketing pages have fewer moving parts, and their failure modes are the ones automated tools already catch well.

Scan the whole site, then test the flows by hand

Start with coverage. Run a free scan to get the machine-checkable failures across your templates rather than one page, and use our WCAG checklist to track the criteria that need a human. Then take your two most important journeys, the ones where money or signups happen, and walk them end to end with a keyboard and a screen reader. That combination gives you something you can put in an accessibility statement and defend later, which a green home page never will.

Pavel Charkasau, founder, wcagc.com. Last updated 22 August 2026.

Sources