Your report cannot price itself, and that is not a shortcoming in the report. It records what is broken, where, and against which rule. What a price depends on is how your codebase is put together, who is available, what else is in the release, and how many decisions somebody has to make before a developer can start. None of that is visible from the outside, which is why a supplier who quotes before opening your pages is reading you a rate card rather than an estimate.
You can still build a number, and you are better placed to build it than anybody else, because the four unknowns above are all things you know. What follows is the model, in four steps, and the discipline that makes it defensible. Every step produces an assumption, and the assumptions travel with the number.
One boundary first. This page is about pricing one specific findings list. If what you want is the wider question, so what this work costs across the market, why no price list exists, and the only public figures anybody has published, that is a different page. It is what remediation costs.
Step One, Collapse the Findings to Their Causes
The single most expensive mistake is counting rows. A report lists findings, and a finding is a symptom. Money follows causes, and there are far fewer of those.
So go through the list and group by the thing that has to change. Not by criterion, not by page, and not by severity. By the file, the component, the template, the content type or the third-party product that produces the behavior. A report with 23 findings very commonly collapses to eight or nine causes, and half the total effort sits in two of them.
Two warnings while you do it. Findings on different criteria can share a cause, so a control with no name and no keyboard support is two rules and one fix. And one finding can hide several causes, so forms do not report errors may be three different form implementations that happen to fail the same way. Neither of those is visible from the row count. Reading an audit report covers the grouping itself in more detail, and this page picks up where that leaves off.
The other thing to remember is that your report probably lists one specimen per failure rather than every occurrence. W3C's evaluation methodology sets the default at least one example for each criterion not met, and every-occurrence listing is something the buyer asks for in the brief. So when you find the cause, go and search for its siblings. The count in the report is a floor.
Step Two, Put Each Cause in a Band
Five bands, and they are defined by the shape of the work rather than by hours, because your team's hours are not our hours and a number we invented would be worth nothing to you. Assign the band, then price the band with your own team's figures at the end.
| Band | What it looks like | What decides it |
|---|---|---|
| Trivial | One declaration, one attribute, one string, in one place. Deleting an outline: none. Adding a lang. Writing one missing label. | Nothing. A developer with the report open can do several of these before lunch |
| Small | One component changed in one way, plus its test. Wiring a label to its field. Making a div a real button. Adding an error element and pointing aria-describedby at it. | Nothing outside engineering, as long as the component exists and somebody owns it |
| Medium | A component whose behavior changes, with knock-on effects on everything that uses it. Or a content job at volume, such as alt text across a catalog. | How many places consume the component, and for content, how many items there are and who writes them |
| Large | A pattern rebuilt rather than repaired. A custom dropdown becoming a real combobox. A drag-only interaction gaining a pointer alternative. A journey re-sequenced so a step stops losing entered data. | Design involvement, a decision about the pattern, and usually a round of testing that is not just a unit test |
| Unknown | Something you do not control or cannot yet see. A third-party embed. A vendor component. A finding whose cause is not obvious from the evidence. | Somebody spending an hour finding out. Until they do, this band has no number and should not be given one |
The Unknown band is the one that makes the estimate honest. The instinct is to guess a number so the total looks complete, and that guess is the line that will be wrong. Leave it named, unpriced, with a stated next action, and it becomes a question somebody can answer this week rather than a figure somebody quotes back at you next quarter.
Severity Is Not Effort, and the Two Get Confused Constantly
This is worth stopping on, because the confusion is built into how reports look. Findings arrive sorted by severity, severity is the most visible field on the page, and it is entirely natural to read the top of the list as the big job. It is not. Those are two different axes and they are close to uncorrelated.
Severity measures what happens to a person. The published version of that grading, in US federal practice, is a risk level of High, Medium or Low based on the number of users affected and how critical the functionality is. Both of those are about impact. Neither says anything about how long the change takes.
| The finding | Severity | Effort | Why they diverge |
|---|---|---|---|
*:focus { outline: none } in the global stylesheet | High. Every keyboard user on every page is steering blind | Trivial to Small. Delete the reset, style :focus-visible | One line of CSS locks out an entire input method. Impact is enormous, work is minimal |
| A custom sortable table with drag-only reordering | Medium. Real, and there is usually another way to achieve the same thing | Large. A pointer alternative has to be designed as well as built | A moderate barrier can sit inside a pattern that has to be rebuilt from the ground up |
| Alt text missing across 900 catalog images | High on a store, because nobody can tell one product from another | Medium, and mostly not engineering at all | The work is writing, at volume, by people who are not developers. A sprint plan that treats it as a dev ticket will miss by weeks |
| A decorative icon exposed with a meaningless name | Low. It adds noise rather than blocking anything | Trivial | The one case where the two axes agree, which is why the disagreement in the other three keeps surprising people |
And one more thing about that severity column. It is not the standard's. WCAG grades a criterion pass or fail and says nothing at all about how much a failure hurts, which is why every report you will ever read uses a different set of words. Sort your board by it. Do not report it upward as though a standard produced it, and do not let it stand in for effort in a budget.
Step Three, Attach a Confidence Rather Than a Bigger Number
The usual response to uncertainty is padding, which hides the uncertainty inside a number and guarantees an argument later. The better move is to say which parts you are sure about, because that turns an estimate into a plan for finding out.
- High confidence. You have seen the code, you have done this exact change before, and nothing outside engineering has to be decided. Most Trivial and Small work sits here.
- Medium confidence. You know the shape of the work and not the size. Usually because the volume is unknown, so how many products, how many documents, how many templates consume this component.
- Low confidence. Something has to be decided before anybody can start. A brand color has to move. A pattern has to be chosen. A supplier has to answer. This is not an engineering estimate yet.
- No estimate. The Unknown band. Name the question and name who is going to answer it, with a date on that rather than on the work.
Then the rule that makes this worth doing. Low confidence is a request for discovery, not a request for more budget. Almost every low-confidence line resolves with an hour of somebody's time. Open the vendor's documentation. Ask the design lead whether the palette can move. Count the PDFs. An afternoon of that turns half your low-confidence lines into medium ones, and it is the cheapest hour in the whole project.
There is a precedent worth borrowing for the discipline of publishing the method with the number. W3C's advice on aggregated accessibility scores says that whenever a score is provided, the scoring approach has to be documented and given to whoever commissioned the work, so the result is transparent and repeatable. Same principle, applied to money. The estimate is only defensible if the person reading it can see how it was built.
Step Four, Turn Effort Into a Calendar
Effort is how much work there is. Duration is how long it takes, and the gap between them is where every accessibility timeline goes wrong. Four things stretch it, and none of them is developer speed.
- Your release cadence. Work finished on a Tuesday reaches users when your release process says it does. A fortnightly train turns nine causes into a minimum of a few cycles regardless of how fast anybody codes.
- Decisions that block work. A brand color, a chosen pattern, a legal review of new wording. These take calendar time and no engineering time, and they are the reason a two-day fix sits for three weeks.
- Dependencies you do not own. A third-party embed fixes on the supplier's schedule. You can raise the ticket and you cannot set the date, so the honest plan names the request, the date it was raised, and the alternative if the answer is no.
- Verification. The work is not done when it ships. Somebody has to confirm it, and a retest is a booked piece of work with its own lead time. Published remediation planning treats this as a named step, and the plan stays open until the fixes are validated by testing rather than merely resolved.
One thing that does not parallelize, and it catches teams out. Causes sitting in the same shared component are one queue, whatever the headcount. Three developers cannot fix the same button three times, so we will put more people on it buys less than it looks like it will on exactly the work that produces the most findings.
Which is also the argument for sequencing by journey rather than by severity. Every page in a process has to conform for any page in it to conform, so nine fixes spread across nine journeys leave nine journeys still broken, while the same nine concentrated on checkout leave checkout finished. Finishing something beats improving everything, and it is the only ordering that produces a result you can honestly describe.
The Worked Estimate
This is an illustration built on the shape of our own sample report, which carries 23 findings across ten pages of a store. The numbers of causes and the bands are real reasoning. The site is not a client and the figures at the end are the ones you supply.
| Cause | Findings it explains | Band | Confidence |
|---|---|---|---|
| Global focus reset in the stylesheet | 3 | Small | High. One file, one change, and the design system already has a focus token |
Add-to-cart control built from a div | 2, because it fails two criteria at once | Small | High. It becomes a real button and both criteria close together |
| Product images with no text alternative | 4 | Medium | Medium. The template change is small. The writing is 900 products and nobody has said who does it |
| Form error handling across three forms | 5 | Medium | Medium. Three implementations, one pattern, and the pattern has to be agreed once before it is applied three times |
| Custom dropdown used for category filters | 3 | Large | Low. Rebuild or replace is a decision nobody has made, and the two answers cost very different amounts |
| Brand palette failing contrast on secondary text | 3 | Small in code | Low. The change is a token. The decision belongs to whoever owns the brand and that conversation has not started |
| Heading structure on two page templates | 1, listed once as a specimen | Small | Medium. One specimen was listed, so somebody has to check the other templates first |
| Third-party cookie banner | 2 | Unknown | No estimate. Raise it with the supplier, and price the alternative of replacing the banner separately |
| Price list PDF linked from every page | 0 in the report, flagged as out of scope | Unknown | No estimate. Count the documents before anybody guesses. Documents inherit nothing from each other |
Read what that table actually tells a stakeholder, because it is more than a number would. Twenty-three findings are nine pieces of work. Three of them can start this morning. Four are blocked on a decision rather than on engineering, and the decisions are a brand call, two pattern calls and an ownership call for the alt text. The last two have no estimate at all, and both need an hour of somebody's time this week to stop being unknowns.
Now price it. Take your team's own day rate or internal cost, apply it to the bands, and add a line for the retest. Two figures come out, a floor from the high-confidence work and a ceiling that includes the low-confidence lines at their pessimistic end, and the honest presentation is both of them with the assumptions listed underneath. A single number would have hidden every one of the four decisions this table just surfaced.
Should the Audit Itself Carry Effort Estimates?
It is a fair thing to ask for and there is a real cost on both sides, so the answer depends on who is doing the estimating and what they have seen.
The case for is that the person who found the barrier understands it better than anybody, and a report with no sense of scale is hard to plan against. A finding list sorted only by severity implies a work order that is often wrong, and a reader with no engineering background cannot tell which of 23 items is the afternoon and which is the month.
The case against is that an evaluator sees your rendered pages, not your codebase. They do not know whether that button is one component or eleven copies, whether your design system has a focus token already, who writes your product copy, or what your release process does to a two-day change. An estimate produced without those is a guess with a decimal point on it, and once a number is written down it gets quoted back as a commitment.
The workable middle is to ask for the inputs to an estimate rather than the estimate. Three things, all of which an evaluator genuinely knows.
- Grouping by cause. Which findings share a root, so you can see nine pieces of work rather than 23 rows. This is the one that changes the number most, and it costs the evaluator nothing because they already know.
- Whether the cause looks like template, content or document work. Three different kinds of job, with three different people doing them, and the split is visible from the outside.
- Which findings sit in code somebody else controls. A third-party embed is a scheduling problem rather than an engineering one, and knowing which rows those are changes the plan more than any hours figure would.
Then your own team turns those into hours, because they are the only ones who can. If you want the sequencing done properly, the remediation roadmap puts findings into sprints by user impact and engineering effort, grouped so one template fix clears many pages, and it is priced per document. If you want them as issues your board can import with acceptance criteria attached, that is the developer ticket pack. Neither one publishes an hours figure, for the reasons above.
What This Number Is Not
Three limits, and they are worth writing on the estimate itself rather than remembering later.
It is not a price for conformance. It is a price for closing the findings on the pages somebody opened. Every template the sample never reached is an open line, and W3C's methodology is direct about why. It is always possible an unexamined page carries an error, and no sample size closes that. So state the coverage next to the number rather than inflating the number to cover the gap.
It is not a schedule. Effort became duration only after you added your own release cadence, your own decision-makers and your own dependencies, and any of those moving moves the date without changing the work.
It is not somebody else's quote. If you are taking this to suppliers, ask for a price per template and per document rather than one figure for the site. A supplier who can quote that way has opened your pages. One who insists on a single number has not. And ask who verifies the result, because a supplier signing off its own repair has checked nothing.
Why there is no rate on this page
No credible price index for accessibility remediation exists. No published average, no benchmark, nothing a buyer can hold a quote up against, and that is structural rather than a gap somebody will fill next year. There is no unit to price, because conformance is defined for a web page and getting the site fixed names nothing the standard can measure. So this page hands you the model and you supply the numbers, which is the only version of this that is not made up. The wider cost picture has the only public figures anybody has published, and says plainly who they describe.
The Afternoon, in Order
Collapse the findings to causes. Band each cause by what the work touches. Mark the confidence and name the discovery that would raise it. Add your release cadence, your blocking decisions and your verification slot. Then put your own rate against it and publish the assumptions with the total.
Do that and you walk into the budget conversation with nine pieces of work, four decisions and two questions, instead of a number somebody can argue with. That is a much better meeting.