Accessibility automation is incredibly useful.
Run a scanner against a page and within seconds you may find missing labels, contrast problems, ARIA mistakes, structural issues, and other WCAG-related signals.
For developers, that feedback loop is valuable.
The problem starts when we confuse:
“No automated failures found”
with:
“This interface is accessible.”
Those are very different statements.
W3C’s guidance is explicit that accessibility evaluation tools can quickly identify potential issues, but they cannot automatically check every aspect of accessibility. Human judgment is still required.
The practical takeaway for developers is simple:
Automate what is deterministic. Manually verify what depends on behavior, context, and actual user interaction.
Here is what that looks like in practice.
- Missing alternative text: automation is very good at this
Consider:
<img src="/products/red-chair.jpg">
Enter fullscreen mode Exit fullscreen mode
An automated accessibility checker can reliably detect that the image does not have an alt attribute.
The technical issue is deterministic.
A possible fix might be:
<img
src="/products/red-chair.jpg"
alt="Red upholstered lounge chair with wooden legs"
>
Enter fullscreen mode Exit fullscreen mode
This is exactly the kind of problem automation is good at discovering.
But now consider:
<img
src="/products/red-chair.jpg"
alt="image123"
>
Enter fullscreen mode Exit fullscreen mode
The alt attribute exists.
A simple technical presence check may therefore pass.
But is “image123” actually useful alternative text?
Probably not.
That question requires understanding the purpose of the image.
If the image is decorative, the correct implementation might instead be:
<img
src="/decorative-divider.svg"
alt=""
>
Enter fullscreen mode Exit fullscreen mode
So even with something as apparently straightforward as image alternatives, there are two separate questions:
Can automation detect that an attribute is missing?
Often, yes.
Can automation always determine whether the text communicates the right meaning?
No.
That second question requires context.
- Form labels: automation catches the association, humans verify the experience
This is another classic automated finding:
<input
type="email"
name="email"
placeholder="Email address"
>
Enter fullscreen mode Exit fullscreen mode
The placeholder is visually useful, but the input has no persistent programmatic label.
A better implementation is:
<label for="email">
Email address
</label>
<input
id="email"
type="email"
name="email"
autocomplete="email"
>
Enter fullscreen mode Exit fullscreen mode
This relationship is straightforward enough for automated tools to inspect.
But form accessibility does not stop at the label.
Suppose validation fails:
<p class="error">
Invalid value.
</p>
Enter fullscreen mode Exit fullscreen mode
A developer now needs to ask more questions.
Does the user know which field failed?
Is the error associated with that field?
Does a screen reader announce the error?
Does focus move somewhere unexpected?
Can the user correct the problem without losing previously entered information?
Is “Invalid value” even useful guidance?
Those are workflow questions, not simply DOM-presence questions.
- Accessible names can technically exist and still be poor
Imagine an icon button:
<button aria-label="Open">
<svg aria-hidden="true">
...
</svg>
</button>
Enter fullscreen mode Exit fullscreen mode
A scanner may confirm that the button has a role and an accessible name.
Technically, there is something for assistive technology to announce.
But:
Open what?
If the page contains five similar controls, “Open” may provide very little context.
A more useful implementation could be:
<button aria-label="Open billing settings">
<svg aria-hidden="true">
...
</svg>
</button>
Enter fullscreen mode Exit fullscreen mode
This is where developers need to stop treating accessibility as a binary attribute-validation exercise.
WCAG 2.2 includes requirements around headings and labels describing topic or purpose, among many other behavioral and contextual requirements.
Automation can tell you a label exists.
Human review helps determine whether that label actually makes sense.
- Custom controls expose the limits of static inspection
Here is a common pattern:
<div
role="button"
tabindex="0"
aria-label="Add to cart"
onclick="addToCart()"
>
Add to cart
</div>
Enter fullscreen mode Exit fullscreen mode
At first glance, this looks accessibility-aware.
It has:
role="button"
tabindex="0"
aria-label="Add to cart"
Enter fullscreen mode Exit fullscreen mode
But try using it without a mouse.
Tab to the element.
Now press:
Enter
Space
Depending on the implementation, nothing may happen because the developer implemented only the mouse click behavior.
The easiest fix in most cases is not more ARIA.
It is native HTML:
<button
type="button"
onclick="addToCart()"
>
Add to cart
</button>
Enter fullscreen mode Exit fullscreen mode
Native elements come with a substantial amount of browser behavior already implemented.
This is one reason accessibility bugs often appear when teams recreate native controls using generic elements.
A scanner can inspect semantics.
Actual keyboard testing tells you whether the interaction works.
- Visible focus requires using the keyboard, not just reading the DOM
Developers sometimes remove browser outlines because they do not match the design:
button:focus,
a:focus {
outline: none;
}
Enter fullscreen mode Exit fullscreen mode
That may make the UI appear cleaner to someone using a mouse.
It can also make keyboard navigation extremely difficult.
WCAG 2.2 Level AA requires a mode where keyboard focus is visible. W3C explains that sighted keyboard users need to know which element currently has focus.
A reasonable CSS pattern might be:
button:focus-visible,
a:focus-visible,
input:focus-visible {
outline: 3px solid currentColor;
outline-offset: 3px;
}
Enter fullscreen mode Exit fullscreen mode
But even that code is not the end of the test.
Open the page.
Put the mouse aside.
Press:
Tab
Tab
Tab
Shift + Tab
Enter
Escape
Then ask:
Can I always see where I am?
Does focus follow a logical sequence?
Does a sticky header cover the focused control?
Does opening a component unexpectedly move focus?
Does focus disappear inside a custom widget?
WCAG 2.2 also introduced the Level AA Focus Not Obscured requirement: keyboard-focused components must not be entirely hidden by author-created content.
You discover these problems much faster by actually navigating the interface than by staring at markup.
- Modals are where automated confidence can become dangerous
Consider this:
<button id="open-dialog">
Delete account
</button>
<div
role="dialog"
aria-modal="true"
aria-labelledby="dialog-title"
>
<h2 id="dialog-title">
Delete account?
</h2>
<button>Cancel</button>
<button>Delete</button>
</div>
Enter fullscreen mode Exit fullscreen mode
Semantically, this may look reasonable.
But several critical questions remain.
When the modal opens, where does keyboard focus go?
Can the user Tab into content behind the dialog?
Does pressing Escape close it?
After closing it, does focus return to the control that opened it?
Can a screen reader understand that the interaction context changed?
Are background controls effectively unavailable while the modal is open?
Those are not theoretical edge cases.
They determine whether somebody can actually use the component.
Automated tests may catch pieces of the implementation.
A human needs to test the interaction.
- Dynamic content can be visually obvious and invisible to assistive technology
Suppose a user saves a profile.
Your JavaScript does this:
statusElement.textContent = "Profile saved successfully";
Enter fullscreen mode Exit fullscreen mode
Visually, the message appears.
The sighted developer sees it and considers the flow complete.
But someone using a screen reader may receive no indication that anything changed.
One possible implementation is:
<div
id="save-status"
role="status"
aria-live="polite"
></div>
Enter fullscreen mode Exit fullscreen mode
Then:
document.getElementById("save-status").textContent =
"Profile saved successfully";
Enter fullscreen mode Exit fullscreen mode
WCAG 2.2 Success Criterion 4.1.3 addresses status messages that need to be programmatically determinable so assistive technologies can present them without moving focus.
Again, the implementation can look completely functional if you test only visually.
- Color contrast is a good automation problem — until context changes
Contrast calculations are one area where automation can be extremely effective.
Given a text color and background color, software can calculate the ratio.
That makes it an excellent candidate for automated regression testing.
But real interfaces complicate things.
Text may appear over:
gradients;
photographs;
video backgrounds;
hover states;
disabled states;
overlays;
dynamically selected themes.
A static check may identify many straightforward contrast failures.
A developer still needs to verify the states users actually encounter.
The broader lesson is useful:
Automation performs best when the question has a deterministic answer derived from machine-readable state.
The more a question depends on context or interaction, the more likely human testing becomes necessary.
- The DOM is not the complete user journey
Most development teams organize work by components.
Users experience workflows.
That difference matters.
Imagine an ecommerce checkout containing individually reasonable components:
Product page
→ Cart
→ Shipping form
→ Payment
→ Validation error
→ Confirmation
Even if every page produces relatively clean automated results, the complete journey can still fail.
Perhaps:
a cart drawer does not manage focus correctly;
validation errors are not announced;
a third-party payment widget introduces keyboard problems;
focus jumps to the top of the page after submission;
confirmation appears visually but is not announced;
a timeout modal interrupts keyboard users.
None of these problems makes much sense when evaluated only as isolated scanner alerts.
You need to execute the flow.
That is why accessibility testing gets more valuable as interfaces become more interactive.
A developer-friendly accessibility testing workflow
For most teams, I would not choose between automation and manual testing.
Use both.
A practical workflow is:
Automated scan
↓
Reproduce the candidate
↓
Inspect DOM + accessibility semantics
↓
Keyboard test
↓
Screen-reader spot check where relevant
↓
Identify component / template / vendor ownership
↓
Fix
↓
Retest the original behavior
↓
Run automated regression checks again
Enter fullscreen mode Exit fullscreen mode
Step 1: automate early
Run accessibility checks during development rather than waiting until release.
Automation is cheap feedback.
Use it.
Step 2: reproduce before fixing
Do not blindly fix every scanner message.
Understand what the tool actually observed.
False positives, duplicate symptoms, and component-level repetition can otherwise turn one underlying issue into dozens of apparent tasks.
Step 3: inspect semantics
Use browser developer tools and the accessibility tree where useful.
Ask what role, name, state, and relationship assistive technologies are actually receiving.
Step 4: use the keyboard
This takes minutes and catches a surprising number of serious interaction bugs.
Test:
Tab
Shift + Tab
Enter
Space
Escape
Arrow keys where appropriate
Do not just test whether focus reaches a control.
Test whether the entire interaction can be completed.
Step 5: verify context
Ask whether labels, errors, instructions, link purpose, and state changes make sense to an actual user.
Step 6: fix the source, not every symptom
If 40 pages fail because the same navigation component is broken, you do not have 40 independent remediation tasks.
You have one shared component problem with a broad impact.
That distinction matters enormously for engineering teams.
Step 7: retest the exact finding
“Code deployed” does not mean “accessibility issue fixed.”
Return to the original steps and verify the behavior.
Where an automated scanner fits
We recently built a free website accessibility scanner at Auditzo because automated discovery is genuinely useful.
It is designed as a first-pass technical check for one public webpage, covering supported automated WCAG 2.2 A/AA-oriented checks.
Free scanner:
Auditzo Free Website Accessibility Scanner
The important part is what we intentionally do not call it.
It is not an ADA compliance certificate.
It is not proof of complete WCAG conformance.
And it is not a substitute for human accessibility testing.
It is the first stage:
Discover
For issues that matter enough to investigate further, the workflow becomes:
Discover
→ Verify
→ Remediate
→ Retest
That distinction is important both technically and commercially.
A developer should know whether they are looking at:
an automated candidate
or
a verified accessibility finding.
Those are not the same thing.
If you want a broader breakdown of where automated testing ends and human accessibility review begins, we also put together a practical guide on Accessibility Scanner vs Manual Audit.
A useful mental model
When deciding whether a test belongs in automation, ask:
Can the correct answer be determined reliably from machine-observable state alone?
If yes, automate it.
Missing attributes, deterministic relationships, parsable semantics, certain contrast calculations, and similar rules are excellent candidates.
Then ask:
Does the answer depend on meaning, context, sequence, interaction, or whether somebody can actually complete a task?
If yes, test it with a human.
This model scales beyond accessibility.
Good engineering automation handles repeatable facts.
Human review handles ambiguity and context.
Accessibility simply makes that boundary particularly visible.
Final thought
Automated accessibility testing should be part of a modern frontend workflow.
Run it early.
Run it often.
Put appropriate checks into your regression process.
But do not let a clean automated result give you false confidence.
A scanner can inspect a lot about a page.
It cannot experience your application the way a person does.
So the workflow I keep coming back to is:
Automation discovers.
Developers reproduce.
Humans verify.
Teams remediate.
Then we test again.
That is much more useful than chasing a perfect accessibility score.
Auditzo provides automated website accessibility scanning and separately scoped human-reviewed accessibility evidence services. Automated scan results do not establish complete WCAG conformance, ADA compliance, legal compliance, or certification.