Accessibility

Manual testing vs automated accessibility scanners

TS Talha Shahzad··4 min read
The short version
  • Automated accessibility scanners are only capable of identifying 30-40% of WCAG compliance violations.
  • Scanners excel at checking raw static code like color contrast ratios and missing image alt tags.
  • Critical functional issues, such as keyboard traps and screen reader compatibility, require manual human verification.
  • A hybrid approach combining automated scans with manual testing represents the gold standard for compliance.

If you are building or auditing a website for compliance, you have probably wondered: can an automated tool tell me if my site is accessible? It is a common assumption in the web development world. You run a Google Lighthouse audit, see a green 100/100 score in the accessibility column, and assume your site is fully WCAG-compliant and legally secure.

This is a dangerous false sense of security.

While automated accessibility scanners (such as Lighthouse, axe-core, WAVE, or Siteimprove) are valuable tools for developers, they are severely limited. Industry research shows that automated tools can only identify between 30% and 40% of all WCAG compliance violations. The remaining 60% of barriers, which include the exact keyboard traps and form errors that trigger the majority of ADA lawsuits, can only be identified through manual human testing.

To secure your website legally and ensure a clean user experience for everyone, you must understand where scanners fail and how to combine them with manual audits.

What automated scanners do best

Automated scanners are excellent at checking static HTML rules and performing mathematical calculations.

They are highly efficient at:

  • Checking code syntax: Scanners instantly flag missing alt tags on images, form inputs that lack programmatic ID labels, and pages that miss a language declaration in the HTML header.
  • Calculating contrast ratios: A scanner reads the hex codes of your text and background in your CSS, calculates the mathematical contrast ratio, and immediately tells you if it falls below the required 4.5:1 standard. Doing this manually across a thousand pages would take weeks.
  • Flagging duplicate IDs: Automated tools scan your DOM to ensure you do not use the same element ID twice, which can confuse screen readers trying to parse page regions.

Think of automated scanners as spellcheckers. They catch obvious grammatical errors, but they cannot tell you if the book you wrote actually makes sense.

Where automated tools fail: the subjective blind spots

A scanner cannot read your website with human context. It only evaluates if a tag is present, not if the tag is correct or functional.

Here is where automated tools fall short:

1. Alt text accuracy

If you have a photo of a checkout button and set the alt text to alt="button image", a scanner will mark this as "Passed." The alt tag is present, and it contains text.

However, to a screen-reader user, this description is useless. The text should read alt="Submit payment and complete order". A scanner cannot evaluate if the text actually describes the image or is filled with keyword spam.

2. Logical keyboard flow

A scanner can verify that your links are focusable, but it cannot tell if the tab sequence moves in a logical order. If tabbing through your page jumps from the header to the footer, then back to the menu, and then to a sidebar, a scanner will see no error, but a keyboard user will be completely disoriented.

Want a website that turns visitors into customers, not just compliments?

Book a 15-min intro

3. Keyboard traps and interactive JavaScript

Scanners do not interact with your page. They read the static code when the page loads, but they do not click buttons, fill out forms, or advance sliders.

This means a scanner cannot detect:

  • Keyboard traps: A scanner cannot feel if a user gets stuck inside a popup cookie banner and cannot tab out of it.
  • State changes: When a user clicks a toggle button (such as switching from monthly to annual pricing), a scanner cannot verify if the screen reader is programmatically notified of the change using ARIA attributes.
  • Dynamic content: If a user submits a form and an error message appears on the screen, a scanner cannot tell if that message is announced to a blind user or if it remains silent because it lacks an aria-live container.

If your site uses interactive elements like Webflow sliders, custom accordion dropdowns, or embedded checkout forms, an automated tool will miss almost every barrier inside them.

The hybrid approach: the only way to be secure

To build a legally secure, usable website, you must combine automated speed with manual discipline.

  1. Run automated scans first: Use axe or Lighthouse to catch the low-hanging fruit: find missing alt tags, locate low-contrast colors, and fix basic HTML errors. This cleans up the code syntax quickly.
  2. Perform a manual keyboard check: Unplug your mouse and navigate your entire site using only the Tab and Enter keys. Confirm you can access all menus, expand accordions, fill out forms, and click checkout buttons without visual cursor blocks or keyboard traps.
  3. Run a screen reader dry run: Turn on VoiceOver or Narrator, close your eyes, and try to navigate your conversion funnel. Listen to how the page is described. If key menus are announced as "unlabeled button" or if the layout sounds confusing, edit the code labels.

By executing both steps, you build a sustainable accessibility workflow. Automated tools find the syntax errors, while manual testing ensures real usability. If your team is struggling to resolve complex keyboard blocks or wants to run a complete accessibility audit, a targeted manual testing and code repair project can secure your templates. Clean the code, test the flow, and ensure your site is readable for everyone.

Prefer to hire through Upwork?
Top Rated Plus, 100% Job Success, 450+ projects shipped. See the reviews and start a contract.
Hire me on Upwork

FAQ

Can an automated tool tell me if my site is accessible?

No. An automated tool can only check static HTML rules. It cannot verify if your interactive features work via keyboard, if your alt text descriptions are accurate, or if your page is actually usable for a person with a disability.

What are the limitations of automated accessibility scanners?

Scanners cannot evaluate subjective elements. They can check if an alt tag is present, but not if it accurately describes the image. They cannot identify keyboard focus traps inside interactive Javascript sliders or modals.

How do I perform a manual accessibility test?

Unplug your mouse and navigate your entire site using only the Tab and Enter keys. Turn on your device's built-in screen reader (VoiceOver or Narrator) and verify that you can complete a form or booking without visual cues.

All posts
the next step is small

Want a site that does this for you?

15 minutes, no deck, no pressure. Worst case, you leave with a free plan.

keep reading

More notes