What a website accessibility cost is actually built from

The seven counts a quote is built from#

There are seven, and every one of them comes off your own site. The seventh is not a count at all. It is a question you put to every firm you speak to.

A band would be unverifiable against your own site, so it would only look like an answer. Those seven counts are checkable, which is the whole difference.

Two of them surprise people. States per component matters because you check a component in each state it can reach, not once. Document formats matter because a PDF application form is often the least accessible thing an organisation publishes. Yet it rarely appears on anybody's page count.

Why company size is the wrong proxy for a website accessibility cost#

Company size does not appear anywhere in the standard that measures the work. WCAG 2.2, published by W3C as a Recommendation, names pages, complete processes and the technologies relied upon. Those are the units conformance is scoped against. Headcount is not one of them.

That matters practically rather than philosophically. If you are trying to locate yourself in someone else's bracket, you are answering a question the standard cannot settle. A twelve-person company running a multi-tenant product with forty interactive components has more to check than a two-hundred-person firm with a brochure site.

Therefore the bracket question has no answer as posed. Two firms of identical size can differ by an order of magnitude in what you have to check. Moreover, nothing about their headcount predicts which is which. The question that does have one is about your site.

What WCAG says the unit of work actually is#

The unit is a full page checked against five requirements, at every width it renders. WCAG 2.2 states it directly: "In order for a web page to conform to WCAG 2.2, all of the following conformance requirements must be satisfied". All five. Not the three that a tool happens to reach.

⤢Full size

One full page multiplied by each width it automatically presents and by all five conformance requirements, and then the same again for every step of a complete process, with one failing step voiding the claim for the whole process.×

Two of those requirements do most of the work on scope. W3C writes that "Conformance (and conformance level) is for full web page(s) only, and cannot be achieved if part of a web page is excluded." It also writes that "A full page includes each variation of the page that is automatically presented by the page for various screen sizes". In practice, a responsive page is several pages of checking.

The third scope multiplier is processes. W3C requires that when a page is one of a series presenting a process, "all web pages in the process conform at the specified level or better". As a result, a checkout that fails at step four fails as a whole.

For instance, two sites with two hundred pages each are not the same job. One has three breakpoints and no forms; the other has five breakpoints and a four-step application.

The count that moves an estimate is variety, not volume#

A sound evaluation samples by variety. WCAG-EM 2.0, W3C's evaluation methodology and a Group Note dated 23 July 2026, builds a structured sample. That sample covers common views, essential functionality, distinct sample types and the technologies relied upon. A random set is then added on top of it.

The anchored arithmetic is one line. W3C states that "The number of samples to randomly select is 10% of the structured sample set selected through the previous steps." That random set exists to test whether the structured one was representative at all.

Also worth knowing: W3C says that "If feasible, it is recommended to evaluate the entire digital product. The sampling procedure may then be skipped." Sampling is a compromise made when evaluating everything is not feasible.

Our reading of what that methodology asks an evaluator to weigh, when deciding how large a sample set must be, is eight things. They are size, age, complexity, how content is generated, consistency of coding style, number of authors, how formalised the development process is, and the confidence required. Those are our words, not W3C's.

By our own illustration, a five-hundred-page site can sample smaller than a sixty-page site. The five-hundred-page site is built from four templates by two people with a formal QA process; the sixty-page site is assembled by twelve authors from three systems. Page count says the opposite. Sizing by page count gets that backwards.

The worksheet: seven counts you can take this afternoon#

Here is how to produce each number without a specialist. None of this requires a tool licence.

Count unique templates by opening your site and grouping pages that share a layout. A blog index, a blog post, a product page, a checkout step. Most large estates collapse hard here.

Count interactive components: menus, modals, carousels, date pickers, tabs, accordions, custom selects, data tables. Then count states per component. For example, a modal that opens, traps focus, validates and errors is four things to check, not one.

Count critical journeys from first click to confirmation, and count them as whole processes. A journey that crosses a subdomain is still one journey. Next, count document formats in scope. Finally, write down the assistive technology and browser matrix you expect to test against. Put the re-test question to every firm.

400

URLs in the estate

The number that matters

11

Unique templates the URLs resolve to

A firm quoting from your sitemap alone has priced the wrong number, because it has not looked at your site.

Page count against template count (A hypothetical estate. Invented illustration, not a project we ran. Counts are URLs and templates, not hours and not money.)

Option	A hypothetical estate. Invented illustration, not a project we ran. Counts are URLs and templates, not hours and not money.
URLs in the estate	400
Unique templates the URLs resolve to	11

For example, a hypothetical four-hundred-page estate is an invented illustration rather than a project we ran. It might resolve to eleven templates, nine interactive components and three critical journeys. The number that changed was four hundred to eleven. It is also why a firm quoting from your sitemap alone has not looked at your site.

A scan and an audit are different purchases#

An automated scan reports what a tool can detect. Therefore it cannot settle conformance. That is why a free report and an audit are two different things rather than the same thing at two prices.

W3C is plain about this in WCAG-EM 2.0: "While most accessibility checks are not fully automatable, evaluation tools can significantly assist evaluators during the evaluation process and contribute to more effective evaluation." It can assist. Still, it cannot settle the question.

The strongest statement comes from a source whose entire dataset is automated. WebAIM, at the Institute for Disability Research, Policy, and Practice at Utah State University, writes in its 2026 Million report that "Because only automatically detectable WCAG failures were considered, this suggests that the rate of full WCAG 2 A/AA conformance was certainly lower than 4.1%." That 4.1% is an upper bound WebAIM places on conformance, not a measured rate.

A scan finds the repeated, machine-visible failures. It is silent on whether a keyboard user can finish your checkout. If you want the detail on why two scanners disagree with each other, our note on why two accessibility scanners return different results covers the mechanics. Our note on why automated scanners settle only part of WCAG covers the boundary.

What automated detection keeps finding, and what that tells you#

Across the top one million home pages, most have at least one automatically detectable instance of a short list of named failure types. Of the top one million home pages analysed in February 2026, WebAIM found that 95.9% had automatically detectable WCAG 2 failures.

The type breakdown carries the same population and the same predicate. It is the share of home pages carrying at least one instance of each type.

Show data table

Each bar is the share of home pages carrying at least one instance of that failure type. It is not a share of error volume, and it says nothing about how many instances any one page carries.

Item	share of home pages carrying at least one instance
Low contrast text	83.9%
Missing alternative text for images	53.1%
Missing form input labels	51%
Empty links	46.3%
Empty buttons	30.6%
Missing document language	13.5%

Six named types, each produced by a different part of a build, which is what makes them countable rather than mysterious.

The useful part for sizing is knowing which parts of your build produce those types. Low contrast comes from a colour palette. Missing labels come from a form component. Empty links and empty buttons come from icon-only controls. Consequently the remediation question is which of those your build produces, and where.

What this measurement cannot tell you is what proportion of your own error count those types will be. Because it measured one home page per domain, it speaks to prevalence across sites and to nothing else. A findings report on your site will contain one or more of the named types. However, this data does not say how many of each.

Show data table

The 2026 edition stands above 2025 on four of the six types: low contrast text, missing form input labels, empty links and empty buttons. WebAIM attributes the reversal to rising page complexity, more ARIA and third-party frameworks. Each bar is a share of home pages, not a share of error volume.

Dimension	2019 edition	2022 edition	2025 edition	2026 edition
Low contrast text	85.3%	83.9%	79.1%	83.9%
Missing alternative text for images	68%	55.4%	55.5%	53.1%
Missing form input labels	52.8%	46.1%	48.2%	51%
Empty links	58.1%	49.7%	45.4%	46.3%
Empty buttons	25%	27.2%	29.6%	30.6%
Missing document language	33.1%	22.3%	15.8%	13.5%

Automated detection is finding more of most of these types than it did a year earlier, not fewer.

Turn the counts into hours you own#

Split the work into three classes, then price each class against your own team's hours for comparable past work. You are substituting your last comparable ticket, not an industry rate. We publish no hours figure, and neither should anyone who has not seen your code.

The first class is defects of a named failure type, fixed at their source. A contrast token changed once. The second is sweeps that recur across every template, such as a heading structure corrected in every template. The third is interactive components that you have to rebuild and re-test per state. That is where the states count from the worksheet earns its place.

Effort hours worksheetInteractive

Count times your own hours per unit, summed down the column.

Class of effort	Your count	Your hours per unit	Hours for this class
Defects of a named failure type, fixed at their source	Your count for Defects of a named failure type, fixed at their source, in defects	Your hours per unit for Defects of a named failure type, fixed at their source, in hours	—
Sweeps that recur across every template	Your count for Sweeps that recur across every template, in templates	Your hours per unit for Sweeps that recur across every template, in hours	—
Interactive components rebuilt and re-tested per state	Your count for Interactive components rebuilt and re-tested per state, in component states	Your hours per unit for Interactive components rebuilt and re-tested per state, in hours	—
Total hours			—

No rows completed yet.

Fill your counts into the first column and your own hours into the second. The arithmetic is yours, and you can check every input in it. The output is a number you can defend internally and hold against whatever a firm returns. It will be an estimate, in hours your own team recognises.

Six questions that make two quotes comparable#

Two quotes become comparable once you know six things. Send these as they stand.

Note that W3C itself writes "It is not recommended that Level AAA conformance be required as a general policy for entire sites". That is how you recognise an over-specified scope.

Our comparison of which WCAG version and level actually binds you is the companion to the first question.

When the level is not yours to choose#

Sometimes a regulation names the standard, and the level stops being a budget line. The U.S. Department of Justice, Civil Rights Division, published a final rule in the Federal Register on 24 April 2024 covering web content and mobile apps provided by state and local governments. It names a technical standard, and the compliance deadline is a function of population size.

That is what the rule says and who it names. Whether any rule reaches your organisation is a question for your own counsel, and this page is general information rather than legal advice.

The cost consequence is narrow and worth stating. A named standard removes the level from the negotiation. However, it removes nothing from the scope, which you still have to count exactly as above. A named deadline changes when the counting work happens. It does not change how much of it there is.

When not to buy an audit at all#

Three situations make an audit the wrong purchase.

⤢Full size

Three situations in which an audit is the wrong purchase, and where each one routes instead: a rebuild next quarter routes the requirements into the build, a small brochure site routes to a scan plus a developer day, and no capacity with no intent to have the work delivered routes nowhere, while no capacity but a clear intent routes to the delivery conversation.×

A site being rebuilt next quarter is the first case: the findings expire before the fixes ship. Instead, the requirements belong in the build. That is the wrong purchase rather than the wrong service, and the routes below carry it.

If you run a small brochure site with no interactive components, a scan plus a developer day is the honest answer. Take the scan, fix the contrast and the alt text, and spend the rest elsewhere.

Say you have no capacity to act on a report, and no intention of having the work delivered by anyone. Then that report becomes a document nobody implements. Split that case carefully, though. No capacity but a clear intent to have the work delivered is a routing question, not a disqualification.

The worksheet has its own limit too. It sizes scope, and it does not tell anybody what an hour is worth. Where it breaks is for a reader with no team and therefore no rate to multiply by.

Where to go once you hold your own counts#

Your counts point at one of three next steps, and they are different work.

A template estate that needs remediating points to a WCAG audit, the fixes, and the re-test, which is the shape that matches. That page sets out the scope, the loop and what its re-test is not. A build already under way is a different case: building products everyone can actually use covers what forces the accessibility question and what happens on an accessible build. And when the rebuild is next quarter, the requirements belong in the design and the build, with how to get started with accessible websites as the starting point.

If you leave without talking to anybody, you leave holding seven counts, an hours model and six questions. That is enough to read any website accessibility cost estimate you are handed.

A final word on why a website accessibility cost resists a published band. You measure accessibility work in templates, components, states and journeys. No two sites of the same page count carry the same ones. Take the seven counts off your own site before you ask anyone for a number. Then the conversation is about your site rather than about a bracket.