Skip to Main Content
Testing & Auditing07 July 2026

Why Automated Accessibility Testing Tools Are Not Everything

Author

Redaksi Disabilitas.com

3 Min Read2 Views

Automated Accessibility Tools Are Not Everything: The Reality of Testing

When first implementing web accessibility, many developers immediately turn to automated testing tools like Google Lighthouse, Axe DevTools, or WAVE. Achieving a "100/100" score in Lighthouse is often perceived as the finish line, a medal signifying that their website is now fully inclusive.

However, this is one of the most dangerous misconceptions in the accessibility world. Based on the deep analysis from the book Practical Web Accessibility by Ashley Firth (Chapter 11: Tools and Auditing), this article will uncover why automated tools are merely the first step, not a guarantee of compliance.


1. The Mathematical Fact: Automated Tools Only Detect 20-30% of Errors

Automated testing tools are brilliant at statically scanning markup structure. They can perfectly detect if an image lacks an alt attribute, if a button's color contrast ratio violates the 4.5:1 mathematical standard, or if HTML elements are illegally nested.

But, according to various studies cited by experts like Firth, these tools historically only catch about 20% to 30% of total accessibility issues (WCAG Violations).

Why is that? Because machines cannot (yet) evaluate context and meaning.


2. Contextual Blindness

Let's take the alt attribute on an image as a classic example. If you have code like this:

<img src="revenue-chart.png" alt="image">

Every automated tool on the market will give this a PASS. Why? Because syntactically, the alt attribute is present. The code is valid.

However, for a blind user relying on a Screen Reader, hearing the word "image" when they should be hearing data about the "Q3 revenue chart" is entirely useless. Automated tools cannot evaluate the quality or relevance of the alternative description; they merely check for its existence.


3. Keyboard Traps and Logical Focus

Advanced interactive issues are nearly impossible for static scanners to catch.

  • Keyboard Trap: Can a user navigating with the Tab key enter a Modal/Popup window, but then get trapped inside because there's no way to exit using the Esc key?
  • Focus Order: Is the tabbing order logically moving from left to right, top to bottom? Or does the cursor jump around randomly because you overused the tabindex="1" attribute?

Tools like Lighthouse cannot mimic the human experience of trying to navigate a complex dropdown menu using a single key.


4. The Importance of Manual Testing and Lived Experience

Getting a high score on an automated tool should be seen as basic housekeeping—sweeping the dust before mopping the floor. The crucial next step is Manual Testing.

  1. Pure Keyboard Test: Unplug your mouse. Try to surf your site, shop, or fill out a contact form using only the Tab, Enter, Space, and arrow keys. If you can't see where the cursor is (due to a missing focus outline), you have failed.
  2. Screen Reader Test: Turn on NVDA (Windows) or VoiceOver (Mac) and close your eyes. Can you understand the architecture of the page?
  3. Testing with Disabled Users: As the "Nothing About Us Without Us" movement emphasizes, no simulation or machine can replace the lived experience of users with disabilities during User Testing.

5. Conclusion

Do not remove automated tools from your workflow. Integrating Axe-core into your CI/CD pipeline (like GitHub Actions) is a fantastic step to prevent silly regression errors like unnamed buttons.

However, a 100/100 accessibility score on an automated tool is not a guarantee that your site is disability-friendly. It only guarantees that your code is syntactically safe from basic errors. Testing by humans, for humans, will always be the gold standard.


References

The analysis regarding the percentage limitations of automated tool detection and the importance of contextual testing is summarized based on insights from Practical Web Accessibility by Ashley Firth (Chapter: Tools and Auditing). The methodologies for manual testing and Screen Reader trials refer to industry standards promoted in that literature.

What do you think?

Give your reaction to this article