Accessibility Testing Tools and Workflows
By Mykhailo Boichuk · Co-founder & Vice-President
In short
Automated accessibility tools catch a meaningful fraction of issues but miss most of the ones that matter, because many accessibility failures are about meaning and behavior that a machine cannot judge. A sound workflow uses automation as a fast first pass, adds manual keyboard and screen-reader testing for what automation misses, and includes people who use assistive technology for the issues only real use reveals.
What automation can and cannot catch
Automated accessibility checkers are valuable because they are fast and catch a class of mechanical problems: missing alternative text, insufficient color contrast, form fields without labels, invalid markup relationships. Running them is the right first step because they find the easy failures cheaply and consistently. But they detect only a portion of accessibility issues, and the portion they miss includes many of the most important ones.
The reason is that much of accessibility is about meaning and behavior, not structure. Whether alternative text actually describes the image, whether the focus order makes sense, whether a custom control behaves as its role implies, whether content is understandable, these require human judgment. A page can pass every automated check and still be unusable with a screen reader.
Manual testing for behavior and meaning
The next layer is manual testing by the team. Operating the entire interface with the keyboard alone reveals focus and operability problems that automation cannot see. Navigating with a screen reader reveals whether the experience makes sense when content is announced rather than seen. These tests are not difficult to perform and catch a large share of what automation leaves behind.
- Run automated checks as a fast, consistent first pass.
- Test the whole interface with the keyboard alone.
- Navigate with a screen reader to hear how the experience is announced.
Real users find what testing misses
The final and most revealing layer is testing with people who actually rely on assistive technology in daily life. They use it fluently and encounter problems that someone testing occasionally will not notice, because their expectations and patterns of use differ from a sighted developer simulating the experience. Their feedback surfaces issues that no automated tool and no internal test will catch.
Key takeaways
- Automated tools catch mechanical issues quickly but miss most meaning-and-behavior failures.
- A page can pass every automated check and still be unusable with a screen reader.
- Test the whole interface with the keyboard alone to find operability problems.
- Navigate with a screen reader to judge how the experience is announced.
- Include people who rely on assistive technology to catch what testing misses.
Frequently asked questions
- Are automated accessibility tools enough?
- No. They catch mechanical issues like missing labels and low contrast, but miss most issues of meaning and behavior, which require human judgment.
- What manual testing should a team do?
- Operate the whole interface with the keyboard alone and navigate it with a screen reader to find focus, operability, and announcement problems automation cannot see.
- Why involve real assistive-technology users?
- They use the technology fluently and encounter issues a developer testing occasionally will not notice, surfacing problems no tool or internal test catches.
References
About the author
Mykhailo Boichuk
Co-founder & Vice-President
Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.