The most common website accessibility faults, and how long they take to fix

An accessibility report can make one systemic fault look like 400 separate problems. It can also do the reverse: a single reported keyboard fault can turn out to require redesigning an entire component. Severity, occurrence count and repair effort are three different measurements, and a remediation plan built on the wrong one wastes money. The useful question is not "how many errors?" but "which barriers affect users, where are they generated and who owns the fix?" This article works through that question, fault by fault. Request a sample accessibility report to see how we answer it for a real site.

Prepared in collaboration with our AI tools

What faults do automated scans find most often?

The 2026 WebAIM Million report, published in February 2026, scanned one million homepages and found automatically detectable WCAG failures on 95.9% of them, averaging 56.1 detected errors per page. Six fault categories accounted for 96% of everything detected.

Those are global homepage findings, not a description of any one site, and they come with a limitation the W3C itself states plainly: automated tools identify valuable patterns, but no tool can determine whether a website is accessible or WCAG conformant. A scan cannot tell whether alt text is accurate, whether a keyboard journey makes sense, or whether an error message helps anyone recover. Human judgement stays in the process. What the scan gives you is a map of where to send it.

Why does one fault not equal one fix?

One of the most common misconceptions in accessibility work is that the error count measures the size of the repair job. Three scenarios show why the two are quite different.

One content fault. A single image is missing alternative text. An author writes suitable text, previews the page and republishes it. The repair takes minutes and is owned entirely by the content team.

One repeated content pattern. Three hundred news teasers all link with the words "read more". Each instance is trivial, but there are three hundred of them, spread across years of content, and each needs a human to write link text that says where the link goes. The fault is small; the volume is the cost.

One systemic fault. A CMS component renders an empty button on every page that uses it. The scan reports it 2,000 times. The repair is one change to one component, followed by retesting, and all 2,000 findings close at once.

This is where remediation becomes an engineering discipline rather than a clean-up job. The question we ask of every finding is: where is this generated? Faults generated by a template or component get fixed at the source, once. Only faults that live in the content itself need to be fixed in the content, and those are scheduled as editorial work with the people who own the words. In practice, treating a systemic fault as 2,000 separate tickets is one of the most expensive mistakes in remediation planning, and scan reports invite it.

How long do common accessibility repairs take?

It is important to be honest about what this question can and cannot answer. A precise published average, "empty buttons take 2.4 hours", would look authoritative, but it would be false precision: repair effort depends on where the fault is generated, how the component is built and how much retesting the change triggers. The table below therefore gives effort bands drawn from how this work behaves in practice, for the first instance of each fault fixed at its source. We will publish measured medians and ranges from our own completed remediation work once the sample is large enough to report a sample size alongside them, because a benchmark without one is not evidence.

Two multipliers sit behind every row. First, repetition: once a component is fixed, every further occurrence closes for the cost of retesting, but every content-level fault costs the same again for each instance. Second, deployment: a code change carries the overhead of release, regression testing and verification, which is why bundling accessibility fixes into planned releases is cheaper than shipping them one at a time.

Which fixes are usually quick wins?

Some repairs combine high frequency with low effort, which makes them sensible early work. Page language set once at template level clears a finding from every page on the site. Empty or duplicated accessible names on icon links and buttons are usually a one-line template fix. Incorrect heading levels on a single page, vague link text and alt text for ordinary editorial imagery are all author-level corrections that need no release cycle at all. A practical rule of thumb is that anything an author can correct without a deployment can begin immediately, in parallel with the engineering work.

It is worth being clear that quick does not mean low priority, and slow does not mean unimportant. A missing document language is fixed in minutes and matters to every screen reader user on every page. Sequencing by effort alone gets the order wrong; the quick wins are simply the repairs there is no reason to still be carrying next quarter.

Which faults point to a larger engineering problem?

Some findings are not really findings; they are symptoms. Keyboard traps, focus that vanishes after an interaction, modals and menus that ignore the escape key, form validation that announces nothing, authentication steps that time out silently, complex data tables, reflow failures at 400% zoom, third-party widgets nobody can modify, and reusable components carrying incorrect ARIA: each of these usually means an interactive pattern was built without accessibility in its design, and the repair is a rebuild of the pattern, not a patch.

These are the faults that deserve engineering scrutiny before anyone writes an estimate, because the honest range runs from a day's work to a redesign. They are also the faults automated scans are worst at finding, which is why a site can pass a scan and still be unusable without a mouse.

How should faults be prioritised?

We weigh four factors, in this order: the impact on users, the importance of the journey the fault sits in, the number of occurrences, and whether the fault can be removed at its source. An essential payment, application or enrolment process outranks a minor issue on an obsolete campaign page every time, even when the campaign page carries more raw errors. A systemic fault with a single-source fix jumps the queue because one repair closes hundreds of findings; the same fault buried in third-party code may drop down it, because the practical options are narrower.

Why does retesting belong in the estimate?

A code change can fix one problem and quietly introduce another, so an estimate that ends at the code change covers only half the job. Closing a fault properly means re-running the automated tests, repeating the affected keyboard and assistive-technology journey, checking the responsive and zoomed states the change could disturb, and recording the evidence and the closure date. That record is what turns remediation into something you can show an auditor, a funder or your own board, rather than something you assert.

How do you stop the same faults returning?

Remediation on its own does not stay fixed. Without prevention, the same faults return and the same repair bill arrives with them, because the faults in the table above come back through two doors: new code and new content. Closing the first means an accessible component library, brand colour tokens that are contrast-checked before a project starts, and automated accessibility tests in the deployment pipeline. Closing the second means CMS authoring constraints that make the accessible choice the default, pre-publication review, and training for the authors and developers who create tomorrow's pages.

This is how our own accessibility assurance plans are built: SilkTide and SEMrush scanning dashboards the client can see, quarterly reports, a major annual review, pre-publication content review, and a commitment to bring site content to WCAG 2.2 AA within four months. The dashboards matter because content changes daily, and an accessibility assessment ages as quickly as the content it describes.

Count barriers, not errors

An error count is a starting map, not a verdict. A 400-error report and a 4-error report can describe the same amount of work, and a site that passes its automated scan can still exclude keyboard and screen reader users from its most important journeys. The more useful questions are the ones this article began with: which barriers affect users, where are they generated, who owns the fix and what proves it stayed fixed? Those four questions turn an alarming report into a remediation schedule, and a schedule can be funded, resourced and completed.

Frequently asked questions