Accessibility Testing

Accessibility testing verifies that your application works for everyone — including users with visual, auditory, motor, or cognitive disabilities. It’s not a nice-to-have: in many jurisdictions it’s a legal requirement, and for enterprise products it’s increasingly a contract requirement. Beyond compliance, accessible software is better software: it’s more keyboard-navigable, more screen-reader-friendly, and more robust across devices.

---

WCAG Compliance Levels

Level	Requirement	Coverage
A	Minimum accessibility	Basic: alt text, keyboard navigation, no seizure triggers
AA	Standard (most legal requirements)	Color contrast, resize support, consistent navigation
AAA	Enhanced	Sign language, extended audio descriptions, cognitive aids

Most organizations target WCAG 2.1 AA — this is the standard referenced in ADA lawsuits, EU accessibility directives, and enterprise procurement.

---

Automated Testing Tools

Tool	Integration	Coverage	Best For
axe-core	Browser extension, CI, Playwright	~57% of WCAG issues	Developer-friendly, extensible
Lighthouse	Chrome DevTools, CI	Subset of a11y checks	Quick audits with performance
pa11y	CLI, CI	WCAG 2.1 AA	CI pipeline integration
WAVE	Browser extension	Visual overlay	Designer/QA review
Deque axe DevTools	Chrome/Firefox extension	Extended axe rules	Professional auditing

What Automation Catches vs. What It Misses

Automation Catches (~40%)	Requires Manual Testing (~60%)
Missing alt text	Alt text quality and accuracy
Color contrast ratios	Meaningful color usage
Missing form labels	Label clarity and context
Missing ARIA attributes	ARIA used correctly
Heading hierarchy violations	Heading text makes sense
Keyboard trap detection	Logical tab order
Missing lang attribute	Content language accuracy

---

Manual Testing Procedures

Keyboard Navigation

Test	Expected Behavior
Tab through all interactive elements	Focus moves in logical order
Shift+Tab to navigate backward	Focus moves backward correctly
Enter/Space to activate buttons	All buttons respond to keyboard
Escape to close modals/dropdowns	Overlay closes, focus returns to trigger
Arrow keys in menus/lists	Navigation within grouped elements
Focus visible on all elements	Clear visual focus indicator (not just browser default)

Screen Reader Testing

Screen Reader	Platform	Browser
NVDA	Windows	Chrome, Firefox
JAWS	Windows	Chrome, IE/Edge
VoiceOver	macOS, iOS	Safari
TalkBack	Android	Chrome
Narrator	Windows	Edge

Screen Reader Test Scenarios

Scenario	What to Verify
Navigate headings (H key)	Heading hierarchy makes content scannable
Navigate links (K key)	Link text is descriptive (not “click here”)
Navigate forms	Labels announce correctly, error messages read
Navigate tables	Headers associated with cells
Dynamic content updates	ARIA live regions announce changes
Images	Alt text reads correctly, decorative images hidden

---

Color and Contrast

Element	Minimum Contrast (AA)	Enhanced (AAA)
Normal text (< 18pt)	4.5:1	7:1
Large text (≥ 18pt or 14pt bold)	3:1	4.5:1
UI components and graphics	3:1	3:1
Focus indicators	3:1	3:1

Tool	What It Does
Contrast checker (WebAIM)	Verify specific color pairs
Colour Contrast Analyser	Desktop eyedropper tool
Stark (Figma plugin)	Design-time contrast checking

---

ARIA Best Practices

Rule	Example
Prefer semantic HTML first	Use <button> not <div role="button">
Don’t override native semantics	Don’t add role="heading" to a <h2>
All ARIA states maintained	aria-expanded toggles with accordion state
Live regions for dynamic content	aria-live="polite" for toast notifications
Hidden content properly hidden	aria-hidden="true" for decorative elements

---

CI/CD Integration

Pull Request:
    → axe-core scan (Playwright integration)
    → Block on any critical a11y violations
    → Report new warnings in PR comment

Pre-release:
    → Full Lighthouse a11y audit
    → pa11y scan of all public pages
    → Manual keyboard + screen reader spot check

Quarterly:
    → Full manual audit with screen reader
    → Third-party accessibility audit (if required by contract)

---

Anti-Patterns

Anti-Pattern	Problem	Fix
Relying only on automated tools	Catches < 50% of real issues	Combine automated + manual + screen reader testing
Adding ARIA to fix everything	ARIA misuse creates worse experience	Use semantic HTML first, ARIA only when needed
Color as the only indicator	Color-blind users can’t distinguish	Add icons, patterns, or text alongside color
Treating a11y as a post-launch audit	Expensive to retrofit	Test during development on every PR
Ignoring keyboard navigation	Power users and screen readers blocked	Every interactive element must be keyboard accessible

---

Checklist

• WCAG 2.1 AA target documented and agreed upon
• axe-core integrated into CI pipeline (block on critical violations)
• Keyboard navigation tested for all interactive flows
• Screen reader testing performed quarterly (VoiceOver + NVDA minimum)
• Color contrast meets 4.5:1 for normal text, 3:1 for large text
• All images have meaningful alt text (or aria-hidden for decorative)
• Form inputs have associated labels
• Focus management: logical tab order, visible focus indicator, focus trapping in modals
• ARIA live regions for dynamic content updates
• Skip navigation link on all pages

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For accessibility consulting, visit garnetgrid.com. :::