A team runs an automated accessibility scanner, gets a green report, and declares the product accessible. Then a real audit, or a real user with a screen reader, finds serious barriers the scanner never flagged: a form that cannot be completed by keyboard, a control with no accessible name, a flow that traps focus. The automated tool passed because it checks only what tools can check, which is a fraction of what accessibility actually requires. The green report did not stand up to scrutiny.
This is more than a tooling gap. It is mistaking automated checks for real accessibility coverage.
Insurer Builds Fully Auditable Enterprise AI
An audit-readiness playbook for Chief Risk Officers in regulated insurance markets.
Accessibility testing that stands up to scrutiny is more than an automated scan. It combines automated checks, which catch a fraction of issues cheaply, with manual testing using keyboards and screen readers, which catches the barriers tools cannot, so the coverage reflects whether people can actually use the product and holds up when an auditor or a real user tests it.
However, many teams equate a passing automated scan with accessibility, and discover that automated tools catch only part of what accessibility requires.
If you are a VP of Engineering or Director of QA relying on automated accessibility scans, the intent of this article is:
- Define what automated accessibility testing does and does not catch
- Show why manual testing is required for real coverage
- Lay out how to build coverage that passes an audit
To do that, let's start with the basics.
What Is Accessibility Testing? The Basic Definition
At a high level, accessibility testing verifies that people with disabilities can perceive, operate, and understand a product. Automated tools check the issues that can be detected programmatically, missing labels, contrast, some structure, which is a real but limited fraction. The rest, whether a screen reader can actually complete a task, whether keyboard navigation works, whether focus behaves, requires a human testing with assistive technology. Real coverage combines both.
To compare:
Automated accessibility testing is a spell-checker. It catches misspellings and misses whether the sentence makes sense. You still need a human to read it. An automated scan catches missing alt text and misses whether a screen reader user can actually check out, which only a person using a screen reader can tell you.
Why Is Combined Accessibility Testing Necessary?
Issues that combined testing addresses or resolves:
- Automated scans catch only a fraction of barriers
- Real barriers pass the scan and fail an audit
- Whether people can use the product goes untested
Resolved Issues by Combined Testing
- Automated checks catch the detectable issues cheaply
- Manual testing catches what tools cannot
- Coverage reflects real usability and passes scrutiny
Core Components of Accessibility Testing
- Automated checks for detectable issues
- Manual testing with keyboard and screen reader
- Coverage of what automation misses
- Alignment to audit criteria
- Continuous testing as the product changes
Modern Accessibility Testing Practices
- Automated scanners in CI for detectable issues
- Manual keyboard and screen-reader testing
- Testing against WCAG success criteria
- Real assistive-technology user feedback where possible
- Accessibility testing repeated as the UI changes
The practices combine cheap automated breadth with the manual depth that catches real barriers; neither alone gives coverage that passes scrutiny.
Other Core Issues They Will Solve
- Audits pass because coverage is real
- Real users can actually complete tasks
- Accessibility regressions are caught as the UI changes
In Summary: Accessibility testing that stands up to scrutiny combines automated checks with manual assistive-technology testing, so coverage reflects real usability rather than what tools can detect.
Importance of Combined Accessibility Testing in 2026
Legal scrutiny and AI-generated UI make automated-only accessibility testing riskier. Four reasons explain why it matters now.
1. Automated tools catch a fraction.
Automated scanners detect only the programmatically checkable issues, a real but limited share of accessibility barriers. A green scan is not accessibility; it is the easy part done.
2. Audits and users test the rest.
An accessibility audit or a real assistive-technology user exercises the whole experience, including everything automation misses. Coverage has to match that scrutiny, which means manual testing.
3. Legal exposure is real.
Accessibility is increasingly a legal requirement, and a passing automated scan is not a defense when real barriers remain. Real coverage reduces both exclusion and legal risk.
4. AI-generated UI misses accessibility.
AI-generated interfaces often lack proper structure and accessible names, and automated scans miss much of it. Manual testing catches what both the generator and the scanner miss.
Traditional vs. Modern Accessibility Testing
- Automated scan equals accessible vs. automated plus manual for real coverage
- Detectable issues only vs. the barriers tools miss too
- Green report as proof vs. real usability as proof
- Tested once vs. tested as the UI changes
In summary: A modern approach combines automated breadth with manual assistive-technology testing, so coverage reflects real usability and holds up to an audit.
Details About the Core Components of Accessibility Testing: What Are You Designing?
Let's go through each layer.
1. Automated Layer
The cheap, detectable checks.
Automated decisions:
- Scanners for missing labels, contrast, and structure
- Run in CI on every change
- Understood as a fraction, not the whole
2. Manual Layer
The barriers only humans catch.
Manual decisions:
- Keyboard navigation tested by a person
- Screen-reader completion of real tasks
- Focus, order, and context verified
3. Coverage Gap Layer
What automation misses.
Gap decisions:
- The issues tools cannot detect identified
- Manual testing aimed at those gaps
- No assumption that a green scan means done
4. Audit Alignment Layer
Coverage that passes scrutiny.
Audit decisions:
- Testing against WCAG success criteria
- Real assistive-technology feedback where possible
- Coverage matching what an auditor exercises
5. Continuous Layer
Keeping coverage current.
Continuous decisions:
- Accessibility retested as the UI changes
- Regressions caught, not reintroduced
- Coverage kept current, not one-time
Benefits Gained from Combined Testing
- Coverage that passes an audit
- Real users able to complete tasks
- Regressions caught as the UI changes
How It All Works Together
Automated scanners run in CI on every change, catching the detectable issues, missing labels, contrast, some structure, cheaply and continuously. But the team treats that as a fraction, not the whole. Manual testing with keyboard and screen reader exercises what tools cannot: whether a screen-reader user can actually complete the checkout, whether focus behaves, whether navigation works without a mouse. This manual testing is aimed at the gaps automation leaves and measured against WCAG success criteria, with real assistive-technology user feedback where possible. Accessibility is retested as the UI changes, so regressions do not creep back. The result is coverage that reflects whether people can actually use the product, which is what stands up when an auditor or a real user tests it.
Common Misconception
A passing automated accessibility scan means the product is accessible.
Automated tools catch only the programmatically detectable issues, a real but limited fraction of accessibility barriers. A green scan means the easy part is done, not that the product is accessible. Serious barriers, keyboard traps, unlabeled controls, broken screen-reader flows, routinely pass automated scans and fail audits. Real coverage requires manual testing too.
Key Takeaway: A green automated scan is a fraction of accessibility, not proof of it. Real coverage requires manual assistive-technology testing that catches what tools cannot.
Real-World Accessibility Testing in Action
Let's take a look at how combined accessibility testing operates with a real-world example.
We worked with a team whose green automated scan failed a real audit, with these constraints:
- Cover the barriers automated scans missed
- Make coverage stand up to an audit
- Keep it current as the UI changed
Step 1: Run Automated Checks
Catch the detectable issues cheaply.
- Scanners run in CI on every change
- Missing labels, contrast, and structure caught
- Results understood as a fraction
Step 2: Test Manually
Catch what tools miss.
- Keyboard navigation tested by a person
- Screen-reader task completion checked
- Focus, order, and context verified
Step 3: Target the Gaps
Aim at what automation misses.
- The undetectable issues identified
- Manual testing focused there
- No assumption a green scan meant done
Step 4: Align to the Audit
Match real scrutiny.
- Testing against WCAG success criteria
- Real assistive-technology feedback gathered where possible
- Coverage matched to what an auditor exercises
Step 5: Keep It Continuous
Prevent regressions.
- Accessibility retested as the UI changed
- Regressions caught
- Coverage kept current
Where It Works Well
- Products with legal accessibility requirements
- Teams relying on automated scans alone
- UIs that change often, especially AI-generated
Where It Does Not Work Well
- Teams unwilling to invest in manual testing
- Cases treating accessibility as a one-time scan
- Products where accessibility is genuinely out of scope
Key Takeaway: Combined accessibility testing pays off wherever real usability and audit scrutiny matter, which automated scans alone cannot satisfy.
Common Pitfalls
i) Equating a green scan with accessibility
Trusting an automated scan as proof of accessibility leaves the majority of barriers untested, so the product fails an audit and excludes real users. Add manual testing.
- Automated scans catch only a fraction
- Real barriers pass the scan
- Audits and users find what the tool missed
ii) Skipping keyboard and screen-reader testing
The barriers that most affect real users, keyboard traps, broken screen-reader flows, are exactly the ones only manual testing catches. Test with the assistive technology.
iii) Testing accessibility once
Accessibility regresses as the UI changes, especially with AI-generated UI. Retest as the product changes, not once.
iv) Not aligning to audit criteria
Testing without reference to WCAG success criteria leaves coverage that may still fail the audit. Align testing to the criteria an auditor uses.
Takeaway from these lessons: The failures come from trusting automated scans. Combine automated breadth with manual depth, align to audit criteria, and retest as the UI changes.
Accessibility Testing Best Practices: What High-Performing Teams Do Differently
1. Combine automated and manual
Use automated scans for cheap breadth and manual assistive-technology testing for the barriers tools cannot catch.
2. Test with keyboard and screen reader
Verify that real tasks can be completed without a mouse and with a screen reader, where the barriers that matter most live.
3. Target automation's gaps
Aim manual testing at what scanners cannot detect, rather than re-checking what they already cover.
4. Align to audit criteria
Test against WCAG success criteria so coverage matches what an auditor or a real user will exercise.
5. Retest as the UI changes
Repeat accessibility testing continuously, so regressions do not creep back in, especially with AI-generated UI.
Logiciel's value add is helping teams build accessibility testing that combines automated and manual coverage, so it reflects real usability and stands up to an audit.
Takeaway for High-Performing Teams: Treat the automated scan as the easy fraction and invest in the manual testing that catches the barriers real users and auditors find.
Signals Your Accessibility Testing Holds Up
How do you know your coverage stands up to scrutiny rather than just a scanner? Not by whether the scan is green, but by whether real users and audits pass. These are the signals that separate real coverage from a green report.
Real tasks are completable with assistive tech. A screen-reader user can actually finish key flows.
Manual testing is routine. Keyboard and screen-reader testing happens, not just automated scans.
Audits pass. Coverage matches WCAG criteria and holds up under real scrutiny.
Coverage is current. Accessibility is retested as the UI changes, so regressions do not return.
The scan is treated as a fraction. A green report is the start, not the proof.
Adjacent Capabilities and Connected Work
This work does not exist in isolation. Accessibility testing depends on, and feeds into, the frontend and quality disciplines around it. Ignoring the adjacencies is the most common scoping mistake.
The WCAG compliance discipline builds accessibility in so there is less to catch. The design system provides accessible components that pass more checks by default. The visual and E2E testing exercise the flows accessibility testing also covers. Naming these adjacencies upfront keeps the work scoped and helps leadership see accessibility testing as verifying real usability, not running a scanner.
The common mistake is treating each adjacency as someone else's problem. The manual testing is your problem. The audit alignment is your problem. The retesting as the UI changes is your problem. Pretend otherwise and a green scan hides real barriers. Own the adjacencies you depend on, partner with the teams that hold them, and share the timeline.
Conclusion
An automated accessibility scanner catches the easy, detectable fraction of accessibility barriers and misses most of what actually stops people from using a product. A green scan is not accessibility, and it does not survive an audit or a real screen-reader user. Coverage that stands up to scrutiny combines automated breadth with manual keyboard and screen-reader testing, aligned to audit criteria and repeated as the UI changes. Do that and the product is usable by the people it was excluding, and the audit is something you pass, not fear.
Key Takeaways:
- Automated scans catch only a fraction of accessibility barriers
- Real coverage requires manual keyboard and screen-reader testing
- Aligning to audit criteria and retesting as the UI changes is what stands up to scrutiny
Accessibility testing that holds up requires combining automated and manual coverage. When done correctly, it produces:
- Coverage that passes an audit
- Real users able to complete tasks
- Regressions caught as the UI changes
- Confidence based on real usability, not a green scan
Health System Builds Multi-Agent Clinical Intake
A multi-agent architecture playbook for VPs of Digital who need clinical intake to scale without scaling staff.
What Logiciel Does Here
If a green automated accessibility scan is your proof of accessibility, build coverage that combines automated and manual testing, aligned to audit criteria, so it reflects real usability and passes scrutiny.
Learn More Here:
- WCAG Compliance: Building Accessibility In, Not Bolting It On
- Visual Regression Testing: Catching What Unit Tests Can't See
- Design Systems at Scale: Governance That Doesn't Choke Speed
At Logiciel Solutions, we work with VPs of Engineering and QA leaders on accessibility testing that stands up to scrutiny. Our reference patterns come from production deployments.
Book a technical deep-dive on accessibility coverage that passes audits.
Frequently Asked Questions
Does a passing automated accessibility scan mean the product is accessible?
No. Automated tools catch only the programmatically detectable issues, a real but limited fraction of barriers. Serious problems like keyboard traps and broken screen-reader flows routinely pass automated scans and fail audits. Manual testing is required for real coverage.
Why is manual accessibility testing necessary?
Because the barriers that most affect real users, whether a screen reader can complete a task, whether keyboard navigation and focus work, cannot be detected by automated tools. Only a human testing with assistive technology can verify them.
What do automated accessibility tools actually catch?
Programmatically detectable issues such as missing labels, insufficient contrast, and some structural problems. These are worth catching cheaply and continuously, but they are a fraction of what accessibility requires, not the whole.
How do we make accessibility coverage pass an audit?
Combine automated scans with manual keyboard and screen-reader testing, aim the manual testing at what automation misses, test against WCAG success criteria, and retest as the UI changes so regressions do not return.
How does AI-generated UI affect accessibility testing?
AI-generated interfaces often miss proper structure and accessible names, and automated scans miss much of that. Manual testing becomes more important, catching the barriers both the generator and the scanner leave behind.
