Many accessibility programs mistakenly treat a clean automated scan as the end goal. If every button has an accessible name and the scanner reports no critical failures, the control is considered compliant. This belief is incomplete, and the gap is where complaints and potential legal issues often arise.
The Conventional Approach
Typically, the process involves running an automated tool across your templates. You fix every missing accessible name, empty button, and unlabeled form control. Then, you record the results in your Accessibility Conformance Report and move on.
This logic is sound to a point. WCAG 4.1.2 (Name, Role, Value) requires that user interface components expose a name programmatically, and WCAG 1.1.1 requires text alternatives for non-text content. Automated tools are effective Assistive Technology detecting these issues. They work across thousands of pages, produce repeatable evidence, and provide auditors with concrete data.
Why This Approach Is Incomplete
A label that exists isn't necessarily a label that works. Passing the programmatic check only confirms that something is announced. It doesn't ensure that the announcement helps a user decide what to do.
Consider the example documented by Michael Taylor in his series on composing social media posts with a mobile screen reader. An icon of two hands clapping might be labeled "Hands Clapping." A scanner sees an accessible name and passes it. However, the control actually signals celebration. Taylor's point is that the label describes the picture, while the user needs to understand the function. A literal label works for a wagon icon that opens a shopping cart but fails for a symbol with implied meaning.
This distinction matters under WCAG 2.4.6 (Headings and Labels) and 3.3.2 (Labels or Instructions), which concern whether labels describe purpose, and under 2.5.3 (Label in Name) for voice-control users. No scanner can judge if a description of purpose is adequate. A human must.
More serious are the failures automation can't detect. Taylor reports that moving screen reader focus away from the body field, even accidentally, can make it impossible to reenter. Dictation can leave a phantom "Attachment" announcement with no way to verify if anything is attached. Uploaded media can act as a focus trap during swipe navigation. A video can autoplay with no screen-reader-accessible way to pause it, disrupting the user's speech output until the post is published.
These are behavioral failures across a sequence of steps. They relate to WCAG 2.1.2 (No Keyboard Trap), 1.4.2 (Audio Control), 4.1.3 (Status Messages), and 2.4.3 (Focus Order). Each is a task-completion barrier that only appears when someone works through the flow.
The Evidence
The source experience highlights a pattern worth noting. Many barriers would likely pass a static scan or never appear in one:
- Unlabeled icon buttons are caught by scanners only when the label is truly absent. Vague results like "Icon" or "Button, Image" indicate a label that is present but meaningless.
- Color swatches with no text labels can be flagged, but the real failure is functional: a user can't change the color of any part of the post.
- A text field that can't be reentered is a state-dependent failure. It occurs after a sequence of interactions, not on page load.
- A character counter the screen reader can't consistently focus on is a dynamic content problem that depends on timing and focus behavior.
- Media thumbnails not exposed as actionable items may render as non-interactive content in the accessibility tree, so there's nothing for a scanner to flag as missing a name.
A conformance claim based only on automated output would miss all this. Under ADA Title III, where the question in a complaint is whether a person could actually use the service, "every control had an accessible name" is a weak defense against "I couldn't complete the task."
What to Do Instead
Keep the automated scan, but change its role. It's a triage layer, not a conformance determination.
- Define critical user journeys for each product: compose, select, upload, submit. Any flow where a user writes text, picks options, or adds media should be included.
- Run screen reader testing on those journeys manually on real devices. For mobile products, use VoiceOver on iOS and TalkBack on Android with touch navigation, not desktop simulation.
- Test recovery paths, not just the happy path. Move focus away from a field and try to return. Dictate text and inspect what is announced. Add media and attempt to leave it. Check autoplay behavior every time.
- Review labels for purpose, not just presence. Ask if a user hearing only the announcement could predict what activating the control will do. For ambiguous icons, add a description via aria-label or aria-describedby that states the consequence of selection.
- Write findings in task terms. "User can't complete post after touching outside the text field" gives engineering and legal teams something more actionable than a list of rule IDs.
- Make accessible procurement requirements task-based. When buying or licensing components, ask vendors to demonstrate these flows with assistive technology, not just supply a report.
When Automated Testing Is Right
Automated testing is still the right tool for many issues. Missing form labels, empty buttons, absent alternative text, and contrast failures are common, easy to detect, and easy to fix. Skipping the scan in favor of manual review alone would waste expert time.
Scanning also provides continuous monitoring that periodic manual audits can't. Regressions ship weekly; a human tester won't see them that often. Sometimes, a scan finding is itself the lead worth chasing since unlabeled controls often signal that the surrounding journey deserves a closer look.
The error isn't in running scans. It's in letting a passing scan stand in for the question regulators and plaintiffs actually ask: can a person with a disability complete the task? Your accessibility governance program should be able to answer that with evidence from the flow itself.
