Chapter 60 introduced accessibility testing with cypress-axe for Cypress projects. This lesson takes a broader view: accessibility testing is not tool-specific — it is a discipline that combines automated scans, manual keyboard testing, screen reader verification, and cognitive accessibility evaluation. Whether you use Selenium, Cypress, Playwright, or no automation at all, the accessibility testing methodology is the same.
Comprehensive Accessibility Testing — Beyond Automated Scans
A complete accessibility testing strategy has four layers, each catching different categories of WCAG violations.
# Four-layer accessibility testing strategy
A11Y_LAYERS = [
{
"layer": "Layer 1 — Automated Scans (30-40% of violations)",
"tools": "axe-core (via cypress-axe, playwright-axe, or axe CLI), WAVE, Lighthouse",
"catches": [
"Missing alt text on images",
"Missing form labels",
"Insufficient colour contrast",
"Incorrect heading hierarchy (h1 → h3 skipping h2)",
"Missing ARIA roles and landmarks",
"Duplicate IDs",
],
"integration": "Add to every functional test: cy.checkA11y() / page.accessibility()",
"time": "Seconds per page — fully automated",
},
{
"layer": "Layer 2 — Keyboard Testing (20-25% of violations)",
"tools": "Your keyboard — Tab, Shift+Tab, Enter, Space, Escape, Arrow keys",
"catches": [
"Elements unreachable by Tab key",
"Focus not visible (no outline on focused elements)",
"Focus order illogical (jumps randomly around the page)",
"Keyboard traps (focus enters but cannot leave)",
"Modal focus not trapped (Tab escapes the modal)",
"Interactive elements not operable by Enter/Space",
],
"integration": "Manual testing during sprint; automate critical flows with Cypress/Playwright",
"time": "5-10 minutes per page — manual with selective automation",
},
{
"layer": "Layer 3 — Screen Reader Testing (20-25% of violations)",
"tools": "VoiceOver (macOS), NVDA (Windows, free), JAWS (Windows, paid), TalkBack (Android)",
"catches": [
"Announcements that do not make sense in context",
"Dynamic content changes not announced (missing aria-live)",
"Form errors not announced to screen reader users",
"Custom components (tabs, accordions) not navigable",
"Images described as 'image' instead of meaningful alt text",
"Decorative images announced unnecessarily",
],
"integration": "Manual testing by QA — quarterly or pre-release for key flows",
"time": "30-60 minutes per user flow — fully manual",
},
{
"layer": "Layer 4 — Cognitive and Content Accessibility (10-15%)",
"tools": "Human review, readability checkers, plain language guidelines",
"catches": [
"Error messages that do not explain how to fix the problem",
"Complex language requiring high reading level",
"Inconsistent navigation patterns across pages",
"Time limits without extension options",
"Content that flashes or auto-plays without pause controls",
],
"integration": "UX review during design; QA review during testing",
"time": "15-30 minutes per feature — human evaluation",
},
]
# WCAG 2.1 conformance levels
WCAG_LEVELS = {
"Level A (minimum)": "Basic accessibility — must be met for any claim of conformance",
"Level AA (standard)": "The target for most organisations and legal requirements",
"Level AAA (enhanced)": "Highest level — recommended for specialised audiences, not required",
}
# Legal requirements (2025-2026)
LEGAL = [
"European Accessibility Act (EAA) — effective June 2025, requires digital accessibility for products/services in the EU",
"Americans with Disabilities Act (ADA) — US courts interpret this to cover websites and apps",
"Section 508 — US federal agencies must make digital content accessible",
"EN 301 549 — European standard referencing WCAG 2.1 Level AA",
"Accessibility lawsuits increased 300%+ from 2018-2024 in the US",
]
print("Accessibility Testing Layers:")
for layer in A11Y_LAYERS:
print(f"\n {layer['layer']}")
print(f" Tools: {layer['tools']}")
print(f" Time: {layer['time']}")
print(f" Catches:")
for item in layer['catches'][:3]:
print(f" - {item}")
Note: The 30-40% figure for automated detection is well-established in accessibility research. Automated tools excel at programmatic checks (is there an alt attribute? does the contrast ratio meet 4.5:1?) but cannot evaluate subjective requirements (is the alt text meaningful? does the tab order make logical sense? do screen reader announcements convey the right context?). The remaining 60-70% requires human judgment — keyboard navigation, screen reader evaluation, and cognitive accessibility review. A team that relies solely on automated scans misses the majority of accessibility barriers.
Tip: Learn one screen reader and use it for 15 minutes per sprint on your application’s critical flows. VoiceOver is built into every Mac (Cmd+F5 to toggle). NVDA is free for Windows. Even basic screen reader familiarity — navigating a form, hearing link text announced, experiencing a modal — transforms your understanding of accessibility from theoretical knowledge to visceral experience. Once you hear a screen reader say “image image image link link” on a poorly labelled page, you never forget to add meaningful alt text again.
Warning: Accessibility compliance is increasingly a legal requirement, not a best practice. The European Accessibility Act (effective June 2025) mandates digital accessibility for products and services sold in the EU. ADA lawsuits in the US have increased dramatically. Organisations that treat accessibility as “nice to have” face legal risk, financial penalties, and reputational damage. Integrating accessibility testing into every sprint is risk mitigation as much as user advocacy.
Common Mistakes
Mistake 1 — Equating automated scan results with “accessible”
❌ Wrong: “Our Lighthouse accessibility score is 98. The application is accessible.”
✅ Correct: “Automated scans pass. We also verified keyboard navigation, tested with VoiceOver on critical flows, and reviewed error messages for clarity. Automated scores cover 30-40%; the remaining 60-70% requires manual verification.”
Mistake 2 — Testing accessibility only on desktop
❌ Wrong: Running axe-core on desktop Chrome and declaring accessibility compliance.
✅ Correct: Testing on desktop (keyboard + screen reader) AND mobile (touch target sizes, screen reader with TalkBack/VoiceOver, zoom to 200%). Mobile accessibility barriers are distinct from desktop barriers.