Key data points
- Across 13 separate digital products tested with blind participants, the average accessibility score given by blind testers was 29.0 out of 100, the lowest of any disability cohort measured.
- Low-vision testers scored the same products 46.2 out of 100 on average, and neurodivergent testers scored 49.2.
- By contrast, testers with physical disabilities scored 62.9 and Indigenous testers scored 66.6 on average across the same scoring framework.
- That is a gap of nearly 38 points between the lowest-scoring cohort (blind testers) and the highest-scoring cohort (Indigenous testers, on a much smaller sample), on products built by the same organisations for the same general audience.
- 25% of all findings logged against blind testers were rated “high” or “severe” severity, the highest rate of any cohort with a meaningful sample size, ahead of testers with limited English proficiency (21.3%) and testers aged 65+ (15.4%).
- The single most frequently cited accessibility failure among blind testers’ findings was tagged against WCAG 4.1.2 (Name, Role, Value), the criterion governing whether assistive technology can correctly identify and operate custom interface controls.
Why this matters
When organisations test “accessibility,” they usually run one study, average the results, and report a single score. That number hides a pattern found consistently across the 15 independent studies analysed here, spanning government services, financial products, healthcare information, and higher-education platforms: accessibility scores are not evenly distributed across disability groups. They collapse hardest for the cohort using the most different interaction model (screen reader and magnification users) while holding up reasonably well for cohorts whose primary barrier is content or trust rather than interface operability.
Averaged across 13 projects and 60 testing sessions, blind participants rated the accessibility of the products they tested at 29.0 out of 100. No other disability cohort in the dataset scored below 46. This is not one bad product dragging down an average: the 29.0 figure holds across 13 independently built and independently tested digital products, from public-sector portals to insurance calculators, which suggests a structural, industry-wide pattern rather than a one-off design failure.
The cohort-by-cohort breakdown
| Cohort | Testers (sessions) | Products tested | Avg. accessibility score (/100) | Avg. usability score (/100) |
|---|---|---|---|---|
| Blind | 60 | 13 | 29.0 | 28.8 |
| Low vision | 40 | 13 | 46.2 | 45.1 |
| Neurodivergent | 33 | 13 | 49.2 | 49.7 |
| Deaf / hard of hearing | 23 | 11 | 49.9 | 52.2 |
| Limited English proficiency | 33 | 12 | 51.0 | 55.5 |
| Over-65 | 18 | 9 | 56.6 | 51.8 |
| Physical disability | 6 | 4 | 62.9 | 53.7 |
| Indigenous | 8 | 8 | 66.6 | 58.3 |
Two patterns stand out at this level of aggregation. First, accessibility and usability scores sit close to each other for most cohorts, but not all: deaf and limited-English-proficiency testers rate usability higher than accessibility (by 2.3 and 4.5 points respectively), suggesting that once content is understandable, the product “feels” usable even when specific accessibility gaps remain unaddressed. The largest divergences in the table in fact run the other way: testers with physical disabilities (62.9 accessibility against 53.7 usability, a 9.2 point gap) and Indigenous testers (66.6 against 58.3, 8.3 points). Second, the two visually-oriented cohorts, blind and low-vision testers, sit in a category of their own, with blind testers roughly 17 points below every other group. That gap is consistent with a field-wide observation: most conformance testing (automated scanners, WCAG audits) checks whether accessible attributes exist in the code, not whether they actually produce a usable experience when combined with a screen reader in a real task flow. The scores in this dataset come from real task-based sessions, not code audits, which is why the gap shows up here and often doesn’t in a standard automated accessibility report.
A caveat on both of these patterns. The table above averages scores at the project level, and two follow-up analyses of this same dataset complicate the picture in ways worth flagging rather than smoothing over. First, on closer inspection at the individual-session level, a large share of records showed identical accessibility and usability scores, a sign the scoring pipeline sometimes copies one figure into both fields rather than assessing them independently. Once those sessions are excluded, the true relationship between accessibility and usability scores is much weaker than a same-direction pattern implies, and it runs in different directions for different cohorts (see our companion piece on the accessibility-usability correlation for the full breakdown). Second, an average score, including the 29.0 figure for blind testers above, can conceal enormous session-to-session variation: some task/cohort groups in this data range from a near-total failure for one tester to a near-perfect score for another on the identical task (see our piece on score volatility). The 29.0 average is real and the lowest of any cohort, but it should be read as “consistently the worst average,” not “uniformly bad”: a handful of products in this data do serve blind users well, which is itself informative about what’s achievable.
What’s actually failing for blind and low-vision users
Restricting the analysis to findings explicitly tagged as accessibility-related friction (rather than general usability friction), the WCAG criteria that appear most often are:
| WCAG 2.1 criterion | Name | Description | Occurrences in accessibility-tagged findings |
|---|---|---|---|
| 4.1.2 | Name, Role, Value | Every button, link and control must tell assistive technology what it is, what it’s called and what state it’s in. Example: a “Next” button built from styled text instead of a real button: a screen reader announces nothing at all, so the user hears silence where a sighted user sees a button. | 349 |
| 1.3.1 | Info and Relationships | Structure you can see on screen must also exist in the code behind it. Example: a heading that’s just larger bold text: a screen reader reads it as ordinary body text, so the user can’t jump between sections. | 267 |
| 1.4.3 | Contrast (Minimum) | Text must stand out enough from its background to be read. Example: light grey hint text inside a white form field, which fades out for anyone with low vision or on a screen in daylight. | 195 |
| 1.1.1 | Non-text Content | Images, icons and charts need a text description. Example: a bin icon meaning “delete” with no label: the screen reader just says “button”, or reads out the file name “icon-24.png”. | 105 |
| 2.4.6 | Headings and Labels | Headings and form labels must actually describe what they cover. Example: three separate fields all labelled “Enter details”, so the user can’t tell which one wants their phone number. | 101 |
| 2.4.3 | Focus Order | Pressing Tab must move through the page in a sensible order. Example: a pop-up opens, but Tab keeps moving through the page behind it, so the user never reaches the pop-up’s “Confirm” button. | 86 |
| 1.4.4 | Resize Text | Text must still work when the user enlarges it to twice the size. Example: zooming in to 200% and the text overlaps itself, or the “Submit” button slides off the edge of the screen. | 84 |
| 4.1.3 | Status Messages | Updates that appear without a page reload must be announced too. Example: “3 results found” or “Item added to basket” appears on screen, but a screen reader user is never told and assumes nothing happened. | 77 |
| 1.4.8 | Visual Presentation | Blocks of text must be comfortable to read: line length, spacing, and the user’s ability to change colours. Example: a full-width page of tightly spaced justified text that can’t be adjusted, so readers lose their place between lines. | 74 |
| 2.1.1 | Keyboard | Everything must be operable with a keyboard alone, no mouse. Example: a date picker or drag-and-drop upload that only responds to clicking and dragging, so keyboard and screen reader users can’t finish the form. | 72 |
4.1.2 alone accounts for more than a quarter of all accessibility-tagged findings and 178 of the 440 findings rated “severe.” In practice, this criterion is almost always violated by the same handful of implementation choices: custom dropdowns, tab systems, and interactive widgets built with <div> and <span> elements and JavaScript click handlers instead of native HTML controls or fully-specified ARIA roles, states, and properties. When a control has no programmatically determinable name or role, a screen reader user cannot tell what it is or whether their input registered, which is consistent with the qualitative pattern seen throughout this dataset, where blind testers frequently described needing “trial and error” to operate a control that a sighted user could identify at a glance.
1.3.1 (Info and Relationships) is the second-largest category and reflects a related but distinct problem: visual structure (headings, tables, groupings) that isn’t encoded in markup, so a screen reader announces a flat, unstructured stream of content instead of a navigable document.
What this means for design and engineering teams
Three practical implications follow directly from the data:
A single blended accessibility score on a dashboard can conceal a severe experience for screen reader users while looking acceptable overall: teams relying on an aggregate score should also track the score for blind and low-vision cohorts specifically, since this dataset shows that number moves independently of, and is consistently worse than, the headline average.
The concentration of severe findings on 4.1.2 and 1.3.1 means component libraries are a higher-leverage investment than page-by-page audits. Because these two criteria alone account for roughly 48% of accessibility-tagged findings in this dataset, fixing name/role/value handling and semantic structure once, in a shared component library, addresses the majority of the highest-severity accessibility findings a testing program is likely to surface, more so than remediating individual pages one at a time.
Automated scanning tools are necessary but not sufficient. Automated tools reliably catch missing alt text (1.1.1) and some contrast failures (1.4.3), but 4.1.2 and 2.4.3 (Focus Order) failures, the two most common categories of severe findings in this dataset, typically require a human or assistive-technology user actually operating the interface to detect, because the underlying HTML can appear valid while the resulting interaction is still broken.
Frequently asked questions
Do blind users really rate accessibility worse than other disability groups, on average?
Yes. Across 13 independently tested digital products, blind participants gave an average accessibility score of 29.0 out of 100, the lowest of eight disability cohorts measured, and roughly 17 points below the next-lowest cohort (low vision, at 46.2).
What is the single most common accessibility failure found in usability testing?
In this dataset, WCAG 4.1.2 (Name, Role, Value) was the most frequently cited criterion, appearing in 349 accessibility-related findings and 178 of 440 findings rated “severe”, more than any other WCAG success criterion.
Why do automated accessibility scans miss so many of the issues found in human testing?
Automated scanners check for the presence of accessible markup, not whether that markup produces a usable interaction. The two largest categories of severe findings in this dataset (Name, Role, Value (4.1.2) and Focus Order (2.4.3)) generally require a human tester using a screen reader or keyboard to detect, because the code can look structurally valid while the resulting experience is still broken.
About this analysis
Figures in this article are drawn from an anonymised aggregation of 15 independent usability testing projects conducted by See Me Please between late 2025 and mid-2026, covering government, financial services, healthcare, higher-education, and consumer digital products in Australia and the United Kingdom. All client and participant identities have been removed; figures reflect scores and findings pooled across projects, cohorts, and tasks rather than any single organisation or individual. Cohort sample sizes are reported alongside every statistic so readers can weigh confidence accordingly.
The cohort-average scores in this article are calculated at the project level and, on their own, understate two things a more granular analysis of the same underlying sessions surfaced afterward: the size of the session-to-session spread behind each average, and the true strength of the relationship between accessibility and usability scores once sessions with duplicated (non-independent) scoring are excluded. Readers using the figures in this article for benchmarking should also consult our companion pieces on score volatility and on the accessibility-usability correlation, which qualify both patterns discussed above.
