Screen readers cannot make inaccessible web sites accessible. The web sites have to be designed with accessibility in mind, or else they won’t be compatible with screen readers. To be compatible with screen readers, web sites must follow the rules in the Web Content Accessibility Guidelines 2.0.
Web accessibility testing with screen readers is the only way to learn if you’ve actually wants to achieve screen reader compatibility, especially when it comes to dynamic content and custom widgets. Automated tools and checklists are important, but they have their own limitations. Learning a screen reader can seem frustrating at first, but by learning a few keystrokes and understanding how people use screen readers, you’ll be able to test web content accessibility perfectly.
- People need screen reader access
The main reason to test with screen readers is because real people need screen reader access. Screen reader accessibility is a technical requirement, but we’re doing it to benefit human beings who rely on us to do our job as developers, designers, and testers so they can use their computers.
- Automated tools can’t catch every accessibility issue
Automated accessibility tools can identify a lot of accessibility issues in web content, such as images missing alt text, form input elements missing labels, and many more. But still, automated tools cannot find all the possible accessibility problems.
There are different types of issues that are difficult for automated tools to identify, such as:
Automated tools can only tell you whether an image has alt text. They cannot tell you whether the alt text is meaningful. The same is true of text labels for form elements, captions on tables, headers on data tables, and so on.
In other case, when a user clicks on a button, the focus should go to a logical target—such as a dialog or error message—but it is impossible for an automated tool to know what the appropriate focus location is. With custom widgets, like dialogs, carousels, and accordion menus, there is no way for an automated tool to detect all the possible ways of creating them incorrectly, especially when it comes to keyboard interaction patterns.
As every web site is different but the range of the estimate result with automated tools is usually between 30% and 50%. The more complex the web site in terms of scripting and custom widgets, the lower the estimate would be. Automated tools have their place, but you can’t depend on them only.
3 Custom widgets with JavaScript and ARIA require screen reader testing
The only way to know if a custom widget works with a screen reader is to test it with a screen reader. This is especially true when trying to implement ARIA widgets according to the ARIA 1.1 authoring practices. A badly implemented ARIA widget can be a disaster for accessibility. Even though the whole purpose of ARIA is to make things more accessible, there is enough power in ARIA to break accessibility completely when used inappropriately. That would be a bit extreme, but still, flaws in your ARIA techniques are best discovered by testing with a screen reader.
4 Screen reader brands aren’t exactly alike
When testing static HTML accessibility—things like paragraphs, lists, headings, landmarks, and images—it is usually enough to test in only one screen reader, and it doesn’t matter which screen reader you choose. When testing dynamic content—like custom JavaScript widgets and form validation—it is important to test with at least two screen readers, because there can be subtle differences in the way they handle the dynamic content. Sometimes there are even dramatic differences, or bugs in one of the screen readers, which can be important to take into account. Usually the differences are a matter of support for a given ARIA attribute or method, as opposed to outright bugs, but bugs do exist.
The support for ARIA across screen readers is quite good, but it is still evolving. None of the screen readers supports 100% of the ARIA specification, unfortunately, but they do come quite close.
