Screen reader compatibility is not the same as screen reader usability

Overview

Two related but different questions

A page can pass an automated accessibility scan, meet every applicable WCAG success criterion, and still be difficult to use with a screen reader. Compatibility and usability are related but distinct. Compatibility asks whether assistive technology can parse and announce the content correctly. Usability asks whether a screen reader user can actually accomplish their goal in a reasonable amount of time and effort. A page can score well on the first question and poorly on the second.

Compliance

What automated testing actually measures

Automated accessibility tools check for the presence of specific technical properties, such as alt attributes on images, labels associated with form fields, sufficient color contrast, and valid heading structure. These checks are valuable and catch real problems, but they evaluate the code, not the experience of using it. A form can have a properly labeled field for every input and still present those fields in an order that makes no logical sense when read aloud, forcing a screen reader user to build a mental map of the form before they can complete it.

None of this shows up in an automated report, because the report has no way to evaluate sequence, redundancy, or cognitive load. Those qualities only become visible when someone actually navigates the page with a screen reader.

Patterns

Where the gap shows up most often

Three patterns repeatedly separated a technically compliant page from a usable one in this research. Long, unlabeled regions of repeated content, such as a list of products with no distinguishing information read aloud before the product name, forced participants to listen through redundant text on every item. Deeply nested navigation, where reaching a specific setting required moving through several unlabeled levels, was technically navigable but exhausting to use, since screen reader users typically move through content sequentially rather than scanning visually the way a sighted user would. Dynamic content updates, such as a cart total changing after a quantity edit, were sometimes invisible to a screen reader entirely if the update was not announced through a live region, even though the visual page updated correctly.

Method

Testing with real assistive technology use

Closing this gap requires testing with people who use screen readers daily, not just running an automated scan or having a sighted team member navigate with a screen reader turned on temporarily. Daily users have developed habits, keyboard shortcuts, and expectations built over years of using the technology, and they notice friction that a first time user of a screen reader will not. Their feedback tends to focus less on whether something is technically accessible and more on whether it is efficient, which is ultimately the more useful question for a team trying to build something people will actually use.

Takeaways

What to carry forward

References

Further reading