( Development )
Your accessibility backlog is really a component problem
This is the write-up of that scan: what we found, how we measured it, and what it means for the way you work through a report. The full 22-page PDF is at the end, free and with no email gate.
Why does my accessibility scan show hundreds of issues?
Because the scanner counts renders, not defects. Every failing element becomes its own row, so a single mistake written once into a shared component is reported again on every page that renders it. The queue is long; the list of things actually broken is much shorter.
Run any automated tool across a site and you get a queue. Every failing element is a row. The queue is sorted by severity if you’re lucky, by page if you’re not, and either way it invites you to work through it in order.
That framing treats each row as an independent defect. On a modern site it usually isn’t. Pages are assembled from shared parts, so a defect written once appears everywhere that part is rendered. The queue counts renders. You want to fix sources.
The median page in our scan carried 24 confirmed findings. The median affected site had 18.5 recurring patterns. Those two numbers describe the same site from opposite ends, and only one of them is a to-do list.
How often do accessibility issues repeat across a site?
In this scan, 60.3% of confirmed findings belonged to a repeating cross-page pattern, and 90.9% of eligible sites had at least one. Because ambiguous cases were marked unclassified rather than isolated, that figure is a floor.
We scanned 4,135 publicly accessible pages across 92 anonymised business websites on 8 August 2026, using axe-core 4.11.2 plus our own automated checks, and analysed 114,843 confirmed violations.
Findings were classified as recurring only where the same rule failed against the same distinctive component fingerprint on at least two different pages of the same site:
- 60.3% of confirmed findings (69,224) belonged to a high-confidence recurring pattern
- 10.7% were isolated: adequate evidence, appears once
- 29.0% were unclassified: the evidence was too weak to judge either way
- 90.9% of eligible sites (80 of 88) had at least one recurring pattern
That 29% matters, and we left it visible on purpose. Where we couldn’t tell, we marked it unclassified rather than assuming it was isolated. So 60.3% is a floor, not an estimate. The real recurrence rate may be higher.
How concentrated are recurring accessibility issues?
Severely. Just 27.7% of recurring patterns produced 82.8% of all recurring findings, and the median site had almost half its recurring findings sitting in only three patterns.
Recurrence alone would be a mildly interesting statistic. This distribution is what changes your morning.
| Pattern reach | Share of patterns | Share of recurring findings |
|---|---|---|
| 2–4 pages | 48.4% | 5.9% |
| 5–9 pages | 16.2% | 6.1% |
| 10–19 pages | 7.7% | 5.2% |
| 20+ pages | 27.7% | 82.8% |
Just over a quarter of recurring patterns produced more than four fifths of the recurring findings. Nearly half of all patterns, the ones spanning two to four pages, accounted for under 6%.
It gets narrower at site level. The median site had 47.6% of its recurring findings concentrated in just three patterns. For 37 of 80 affected sites, three patterns explained half or more of everything recurring.
Three. Not three hundred.
Do the most serious accessibility issues also repeat the most?
In this dataset, yes. 72.2% of eligible serious and critical findings were recurring against 36.2% of moderate ones, so sorting by user impact and sorting by cross-page reach pointed at broadly the same components.
The usual tension in remediation is that the worst issues and the most widespread issues are different issues, so you have to choose. Here they largely coincided.
72.2% of eligible serious and critical findings were recurring, against 36.2% of moderate ones. Serious problems repeated more than mild ones did. Sorting by impact and sorting by reach pointed at broadly the same components.
One caveat worth reading properly: the moderate row carries a high unclassified share, driven mostly by target-size findings whose fingerprints are too generic to attribute to a specific component. That’s absence of evidence, not evidence of isolation.
Which components cause the most repeated accessibility issues?
The shared furniture: navigation, headers, footers, modals, repeated cards and forms. Navigation accounted for only 7.3% of patterns but reached 5,676 pages, which is the signature of a component defined once and used everywhere.
Where structural evidence supported assignment, patterns clustered exactly where you’d expect:
| Component family | Patterns | Pages affected |
|---|---|---|
| Images / media | 213 | 1,965 |
| Navigation | 172 | 5,676 |
| Modals / dialogs | 163 | 3,815 |
| Repeated cards | 150 | 1,493 |
| Forms | 147 | 2,382 |
| Footer | 122 | 2,949 |
| Buttons and controls | 117 | 1,229 |
| Header | 57 | 1,811 |
Look at navigation and header. Navigation is 7.3% of patterns but reaches 5,676 pages. Header is 2.4% of patterns and reaches 1,811. Few patterns, enormous reach. That is consistent with a component defined once and used site-wide.
Half of all patterns could not be confidently assigned to a family at all, so treat this table as a map of where evidence was strongest, not a complete census.
Do all accessibility issues come from shared components?
No, and the ones that don’t need a different fix. Editorial problems such as links that aren’t visually distinguishable inside a paragraph recur far less, and they are solved by content standards and CMS validation rather than by changing a template.
If every issue looked like a component defect, the classifier would be telling you nothing. It doesn’t.
link-in-text-block, links that aren’t visually distinguishable inside a paragraph, appeared on 35.9% of sites but only 9.0% of pages, with a median site spread of 13.0%. Only 23.3% of its eligible findings were recurring; 37.7% were isolated. It looks nothing like a component problem, because it isn’t one. It’s editorial. Someone pasted a link into a paragraph and the styling didn’t distinguish it. The fix is editorial standards, CMS validation and training, not a template change.
Compare broken skip-link targets: 96.7% of eligible findings recurring, 100% median site spread. One skip link, defined once in a shared layout, wrong on every page that layout renders.
Same scanner, same site, two findings that need completely different responses. If your remediation process treats them identically, it’s wrong about one of them.
How should I work through an accessibility backlog?
Work outwards from reach rather than down the list. A queue of 800 rows is not a plan; these six steps are.
- Group before you sort. Ask which findings share a rule and a structural fingerprint across pages, then rank the groups by reach.
- Start with recurring serious and critical patterns. They combine potential user impact with cross-page scale, and in this data they were the same set.
- Look at your global furniture first: navigation, header, footer, modals, shared forms, repeated cards.
- Handle target sizing at the design-system level. Resizing controls one at a time is the slowest possible route to the same outcome.
- Route editorial problems to editorial fixes. Content standards and CMS controls, not component changes.
- Rescan afterwards. A shared correction should propagate across every page that uses the component. Rescanning is how you find out whether it did, and catches the places where the component was quietly duplicated.
How was the scan run?
We scanned 4,135 pages on 8 August 2026, using axe-core 4.11.2 plus RedFlag’s own automated checks, across the WCAG 2.0 A, 2.0 AA, 2.1 AA and 2.2 AA rule sets, with six further axe rules explicitly enabled. Level AAA was not systematically evaluated.
| Sample | 92 anonymised business websites, purposive rather than random, none excluded |
| Pages | 4,135 recorded, capped at 100 per site; 18 sites reached that cap |
| Population | 114,843 confirmed violations. 27,011 advisory findings kept separate and excluded |
| Recurrence test | Same rule failing against the same distinctive component fingerprint on at least two pages of one site |
| Verification | Independently re-derived with a second implementation; pattern grouping differences below 0.6 percentage points |
Why are these numbers deliberately conservative?
Two decisions hold the headline figure down, on purpose.
Where the evidence was too weak to judge, findings were marked unclassified rather than isolated. Generic markup, a bare button or a framework utility class, was never accepted as proof of a shared component. That unclassified share is 29.0% of all findings and it stays visible in the report, which means 60.3% is a floor and the real figure is probably higher. We can’t tell you by how much.
The report also refuses to rank issue types by raw instance count. Different rules cap how many elements they record per page at different thresholds, so 32.1% of confirmed findings sat in groups that hit a ceiling. Ranking censored counts against each other produces a confident, wrong league table, so we didn’t.
What does this research not tell you?
It does not prove a single root cause, promise that one commit clears a pattern, or say anything about whether a site conforms to WCAG.
A recurring pattern identifies a probable shared implementation worth investigating, and that is all it identifies.
The 92 websites were a purposive sample from one Australian business network directory. They are not representative of Australian businesses, or of the web. And every finding here is automatically detectable, which is a real but partial slice of WCAG. Nothing in this scan establishes whether keyboard journeys work end to end, whether focus order is logical, whether alt text is meaningful rather than merely present, or whether a site conforms to WCAG. Those need a human.
Get the report
The full 22-page report is free, with no email gate. It carries the complete method, the per-issue breakdowns, the censoring analysis and a rule-reference appendix mapping all 13 issue types to their documentation.
Download the report (PDF, 22 pages) →
It is tagged to PDF/UA-1 and validated with veraPDF 1.30.2: 106 rules passed, 79,936 checks, zero failures. A report about accessibility that wasn’t accessible would be a poor advertisement. That said, veraPDF checks the machine-testable part of the standard: it confirms the tags exist and are well formed, not that the reading order makes sense. The same caveat we apply to websites.
This report is based on automated accessibility testing. It does not constitute a complete accessibility audit, an assessment of WCAG conformance, or legal advice.
Frequently asked questions
Why do the same accessibility issues appear on every page of a site?
Because most pages are assembled from the same parts. A navigation bar, footer, modal or card component is written once and rendered everywhere, so a defect in that component is reproduced on every page that uses it. In our scan of 92 websites, navigation patterns reached 5,676 pages and footer patterns 2,949 pages, which is consistent with site-wide reuse rather than page-by-page mistakes.
Should I fix accessibility issues page by page or component by component?
Start with what repeats. In this dataset 27.7% of recurring patterns accounted for 82.8% of all recurring findings, so a small number of shared components explains most of the volume. Page-by-page work is still needed for genuinely scattered problems, particularly editorial ones, but it is the wrong place to start.
Does fixing one component fix every instance of the issue?
Not automatically. A recurring pattern identifies a probable shared implementation worth investigating, not a guaranteed single code change. The component may be duplicated, overridden locally, or reimplemented in places. Rescanning after a fix is how you confirm the correction actually propagated.
Are the most serious accessibility issues the ones that repeat?
In this dataset, largely yes. 72.2% of eligible serious and critical findings belonged to a recurring pattern, against 36.2% of moderate ones. Prioritising by user impact and prioritising by scale mostly pointed in the same direction, which is unusual and convenient.