What Automation Can and Can’t Detect in Accessibility

Every accessibility platform draws a line between what a machine can detect on its own and what needs a person, and most teams meet that line the hard way. A scan comes back clean, the dashboard turns green, and teams move on to the next project. Then a real user with a screen reader hits a custom checkout, and it breaks on something automation isn’t able to identify. 

The gap was never hidden. It was just never explained. Here’s where the line actually falls: what automation actually detects, what it cannot, how accurate the detection actually is, and why that boundary is the reason a human expert layer exists.

What Automation Can Detect

Automation performs well on deterministic, rule-based Web Content Accessibility Guidelines(opens in a new tab) (WCAG) issues. Color contrast, missing alt-text attributes, form-label associations, and basic ARIA landmark structure are all problems that a machine can consistently detect. 

These issues share one trait. They are rule-checkable. A machine can measure a contrast ratio against a fixed threshold. It can detect an image element with no alt attribute. It can find a form input with no associated label. There is a correct answer, and the answer doesn’t depend on context or intent.

Here’s what automated detection reliably catches:

• Color contrast (WCAG 1.4.3): Automation measures the color contrast ratio between text and background and flags anything below the Level AA threshold (4.5:1 for normal text).

• Missing alt text (WCAG 1.1.1): Automation detects images with no alt text since detecting the absence of alt text is deterministic.

• Missing form labels and name-role-value (WCAG 4.1.2): Automation identifies inputs, buttons, and controls that lack programmatic names or labels. 

• Missing lang attribute (WCAG 3.1.1): Automation checks whether the page declares its language and identifies the attribute when it is absent.

• Empty links and buttons: Automation flags interactive elements with no accessible name, a common and easily detectable failure.

• Basic ARIA landmarks: Automation can identify landmark structure errors and recommend fixes to help assistive technology users better navigate regions of a page.

If you want to see which automated scanning tools surface on your own site, a free accessibility checker can run this type of detection. It’s a useful first look at the rule-based layer.

The point is that this detection is real and valuable. Automation identifies the high-volume, rule-based issues at scale that no human could match by hand. That work matters — but it has a ceiling.

What Automation Can’t Detect

Automated remediation can’t fully identify custom interactive components. It cannot evaluate reading order or content clarity. All of these require expert testing.

The reason is judgment. Rule-based issues have a correct answer that a machine can check. These issues do not. They depend on context, intent, and how a real person moves through a page.

Here’s where automation falls short:

• Meaningful alt text versus present alt text: Automation can confirm an alt attribute exists. It cannot reliably confirm that the description conveys the image's meaning in context. “Image of a chart” passes a presence check and fails a human one. 

• Complex and custom UI components: A custom dropdown, a modal, a date picker, a drag-and-drop interface. Automation cannot fully verify that these behave correctly with assistive technology, because behavior depends on interactions that the machine does not perform. 

• Keyboard operability of custom controls (WCAG 2.1.1): Automation can check for some keyboard traps, but it cannot confirm that a custom widget is fully operable by keyboard alone. That requires a person tabbing through it. 

• Logical reading order: The order in which a screen reader reads the content must make sense. Automation can read the DOM order, but it can’t judge whether that order is logical for an actual human.

• Error identification and suggestion logic (WCAG 3.3): When a form rejects an entry, the error must be clearly identified and, where possible, a fix suggested. Whether the message actually helps a user resolve an error is a judgment call. 

• Content clarity: Whether text is understandable is a human evaluation, not a rule check.

None of this makes automation less useful. It’s a description of the boundary. Automation is precise on what it identifies and silent on what it cannot. Pretending otherwise is where trust breaks down.

A monitor displaying an accessibility icon, surrounded by internet-themed graphics and security symbols.

How Accurate is Automated Detection?

Automated accessibility testing reliably detects only a portion of WCAG success criteria. A large share of the standard depends on context, meaning, and interaction, which a machine cannot assess. Automation is accurate on what it detects and limited in how much of the standard it can reach.

The useful way to think about this is precision and recall:

• Precision is how often automation is right when it identifies something. Automated detection tends to score high here. A flagged contrast failure is almost always a real contrast failure, for example. 

• Recall is how much of the full problem it finds. This is where automation is limited. Most WCAG success criteria require human judgment, so a scan cannot detect them, no matter how well it runs.

This is simply how the work divides. Automation covers the criteria it can check, and expert review covers the ones it cannot. What matters is whether a platform is honest about that line. One that reports a clean automated scan as full compliance is telling you about the criteria it can see and staying quiet about the ones it cannot.

Why Automation Needs a Human Layer

A combined approach exists because automation has a ceiling. Pairing automation with expert testing is the only way to cover the WCAG criteria that automation can’t reach.

The point is that this detection is real and valuable. Automation identifies rule-based issues across hundreds of pages, faster than any human could review by hand. The strongest approach pairs automation for scale with human experts for everything scale can't see.

A platform combines automation with expert testing, using certified experts and assistive technology to verify accessibility rather than assume it. Automation handles scale. Human experts handle the issues that require judgment. Neither layer is sufficient alone, and saying so plainly is what makes the claim believable.

The distinction comes down to one word: standalone. An accessibility overlay is meant to be the whole answer. A platform is designed so automation handles scale, and human experts handle the issues that require judgment.

This is also where the contrast with overlays sits. Overlays promised one-click compliance but could not deliver. The problem was never automation but rather the promise that automation alone was the whole answer. What matters here is simple: a single automated overlay cannot close the gap, and selling it as if it can is the false promise buyers learned to distrust.

Where the Human Expert Layer Takes Over

The human expert layer takes over on assistive technology testing, custom component validation, and judgment calls. These are the high-impact issues that automation can flag but not fix.

In practice, that handoff covers four things automation cannot do on its own:

• Run screen readers and other assistive technology against the site, the way an actual user would.

• Validate custom components by operating them, not by inspecting code.

• Make the judgment calls automation cannot, e.g., is this alt text meaningful, is this reading order logical, does this error message help, etc.

• Fix the issues a scan can surface but not resolve.

This is the work that decides whether accessibility holds up or falls apart in real use. Closing that gap takes expert testing, delivered by people who know what to look for.

A series of icons representing things like web cursors and Braille keyboards, next to an accessibility symbol.

AudioEye: Automation and Expertise, Together

Accessibility is not measured by passing a scan. It’s measured by whether a person using a screen reader can complete a purchase, whether someone navigating with a keyboard can move through a form without getting stuck, and whether the content actually makes sense when read aloud. A green dashboard says none of that. Real people do. 

AudioEye is built to cover both. Automation handles rule-based issues at scale, so common problems are caught on every page. That detection runs deep: an independent study found AudioEye’s automation catches 2.5x more issues than other leading tools, before a single expert gets involved. 

Then, certified experts and users with disabilities test with assistive technology to catch high-impact issues that a scan cannot see. The result is accessibility that holds up in real use, not just on a report.

See where automation ends, and expertise begins. Talk to an expert now.

Curious how accessible your existing content is? Use our free accessibility checker to find out.