---
name: accessibility-compliance-testing
description: Test and ensure digital accessibility compliance with WCAG 2.1/2.2 AA standards, Section 508, ADA, and international accessibility regulations. Use when conducting accessibility audits, implementing automated accessibility testing in CI/CD, performing manual accessibility testing, remediating accessibility issues, training developers on accessible coding, or preparing for accessibility compliance audits. Triggers on phrases like "accessibility testing", "WCAG compliance", "Section 508", "ADA compliance", "a11y", "screen reader testing", "accessibility audit", "accessibility remediation", "keyboard navigation", "color contrast", "aria attributes", "accessibility statement", "VPAT".
---

# Accessibility Compliance Testing

Ensure digital products meet accessibility standards (WCAG 2.1/2.2, Section 508, ADA) through automated testing, manual validation, screen reader testing, and ongoing compliance monitoring.

## Workflow

1. Establish accessibility standards: adopt WCAG 2.1/2.2 Level AA as baseline; identify additional legal requirements (Section 508 for US federal, ADA for US businesses, EAA for EU, AODA for Canada).
2. Integrate automated accessibility testing into CI/CD: axe-core, Lighthouse, Pa11y, WAVE; set thresholds for blocking vs. warning violations; run on every PR and deployment.
3. Conduct manual accessibility audits: keyboard navigation testing, screen reader testing (NVDA, JAWS, VoiceOver), color contrast verification, cognitive accessibility review; use WCAG checklist.
4. Perform accessibility testing with assistive technologies: test with real screen readers (NVDA for Windows, JAWS for Windows, VoiceOver for macOS/iOS, TalkBack for Android); test with keyboard-only navigation; test with zoom/magnification.
5. Remediate identified issues: prioritize by severity (critical → serious → moderate → minor); assign to development teams; verify fixes with both automated and manual testing.
6. Train development teams: accessible HTML markup, ARIA best practices, keyboard navigation patterns, color contrast guidelines, form accessibility, dynamic content accessibility.
7. Establish accessibility governance: accessibility champions in each team; accessibility review as part of design review; accessibility sign-off before release.
8. Create and maintain accessibility statement: publish on website; describe conformance level; provide feedback mechanism; document known issues and remediation timeline.
9. Generate VPAT/ACR (Voluntary Product Accessibility Template/Accessibility Conformance Report): document compliance status for each WCAG criterion; required for government contracts and enterprise sales.
10. Continuous monitoring: post-deployment accessibility scanning; user feedback collection; periodic re-audits; track accessibility metrics over time.

## WCAG Compliance Framework

```
WCAG 2.1/2.2 LEVEL AA REQUIREMENTS
=====================================

PRINCIPLE 1: PERCEIVABLE (Information must be presentable in ways users can perceive)

  1.1 Text Alternatives:
    → 1.1.1 Non-text Content (Level A):
       ✓ All non-text content has text alternative (alt text for images, captions for video, descriptions for charts)
       ✓ Decorative images have empty alt attribute (alt="")
       ✓ Complex images have detailed descriptions (longdesc or linked description)
       ✓ Form images have descriptive alt text
       ✓ Icons with text: icon is decorative (alt="" or aria-hidden="true")

  1.2 Time-Based Media:
    → 1.2.2 Captions (Level A): All pre-recorded video has accurate captions
    → 1.2.3 Audio Description (Level AA): All pre-recorded video has audio description or extended audio description
    → 1.2.4 Captions Live (Level AA): Live video has captions (real-time captioning)
    → Implementation: caption files (.vtt), sign language interpretation, transcript links

  1.3 Adaptable:
    → 1.3.1 Info and Relationships (Level A):
       ✓ Proper HTML semantics (headings h1-h6, lists, tables with headers, landmarks)
       ✓ Form labels associated with inputs (label[for] → input[id])
       ✓ Grouped form elements (fieldset/legend for radio buttons and checkboxes)
       ✓ ARIA roles, states, and properties used correctly when native HTML insufficient

    → 1.3.2 Meaningful Sequence (Level A):
       ✓ DOM order matches visual order (not reordered via CSS for visual presentation only)
       ✓ Screen reader reads content in logical sequence

    → 1.3.3 Sensory Characteristics (Level A):
       ✓ Instructions do not rely solely on sensory characteristics ("click the red button" → "click the Submit button")
       ✓ Do not instruct to respond to sounds or visual characteristics alone

  1.4 Distinguishable:
    → 1.4.1 Use of Color (Level A):
       ✓ Color is not the sole means of conveying information
       ✓ Form errors indicated with text AND color (not color alone)
       ✓ Links distinguishable from text by more than color alone (underline, icon)

    → 1.4.3 Contrast Minimum (Level AA):
       ✓ Text: 4.5:1 contrast ratio minimum (normal text)
       ✓ Large text (18pt+ or 14pt bold): 3:1 contrast ratio minimum
       ✓ UI components and graphical objects: 3:1 contrast ratio
       ✓ Non-text elements (icons, borders): 3:1 contrast ratio
       ✓ Testing tools: axe DevTools, Contrast, WebAIM Contrast Checker, Lighthouse

    → 1.4.4 Resize Text (Level AA):
       ✓ Text resizable up to 200% without loss of content or functionality
       ✓ Use relative units (rem, em, %) not fixed pixels for font sizes
       ✓ Layout does not break at 200% zoom

    → 1.4.11 Non-text Contrast (Level AA):
       ✓ Visual indicators (focus, required fields) have 3:1 contrast
       ✓ Input field borders visible against background
       ✓ Interactive elements distinguishable from non-interactive

PRINCIPLE 2: OPERABLE (UI components must be operable by all users)

  2.1 Keyboard Accessible:
    → 2.1.1 Keyboard (Level A):
       ✓ All functionality operable via keyboard alone
       ✓ No keyboard traps (user can tab forward and backward freely)
       ✓ Custom components (dropdowns, modals, date pickers) have keyboard support
       ✓ Focus management for dynamic content (modals, dialogs, carousels)

    → 2.1.2 No Keyboard Trap (Level A):
       ✓ User can move focus away from any component using standard keyboard navigation
       ✓ Custom widgets do not trap focus

  2.2 Enough Time:
    → 2.2.1 Timing Adjustable (Level A):
       ✓ Timeouts can be turned off, adjusted, or extended (at least 20x the default)
       ✓ Session timeouts: warning at 5 minutes, 2 minutes, 30 seconds before expiry
       ✓ Auto-advancing content (carousels, slideshows) can be paused

  2.3 Seizures and Physical Reactions:
    → 2.3.1 Three Flashes or Below Threshold (Level A):
       ✓ No content flashes more than 3 times per second
       ✓ Flash does not exceed red flash threshold (for users with photosensitive epilepsy)

  2.4 Navigable:
    → 2.4.1 Bypass Blocks (Level A):
       ✓ Skip navigation link provided (first focusable element on page)
       ✓ Landmark navigation (aria-label on nav, main, aside landmarks)

    → 2.4.2 Page Titled (Level A):
       ✓ Every page has unique, descriptive <title> element
       ✓ Title reflects page content and purpose (not just site name)

    → 2.4.3 Focus Order (Level A):
       ✓ Tab order follows logical reading order
       ✓ Focus order matches visual layout

    → 2.4.7 Visible Focus Indicator (Level AA):
       ✓ Keyboard focus visible with clear indicator (outline, border, background change)
       ✓ Focus indicator has 2:1 contrast against adjacent colors
       ✓ Do NOT use outline:none without replacement
       ✓ Custom focus styles must be at least as visible as default browser outline

    → 2.4.11 Focus Not Obscured (Level AA):
       ✓ Focused element not hidden behind other content
       ✓ Scroll-into-view for focused elements (mobile especially)
```

## Automated Accessibility Testing

```
AUTOMATED ACCESSIBILITY TESTING TOOLCHAIN
============================================

CI/CD INTEGRATED TOOLS:

  axe-core (Deque Systems):
    → Industry standard accessibility testing engine
    → Integration: axe DevTools (browser extension), jest-axe (unit tests), cypress-axe (E2E tests), pa11y (CLI)
    → CI/CD: npm script in pipeline; fail build on violations
    → Coverage: ~30-40% of WCAG rules (automatable portion)
    → Pricing: axe DevTools $2,700/year; axe-core engine free (open-source)

  Lighthouse (Google):
    → Built into Chrome DevTools; CLI available (lighthouse-ci)
    → CI/CD: lighthouse-ci collects and asserts scores; assert accessibility ≥ 90
    → Coverage: Accessibility, Performance, SEO, Best Practices
    → Pricing: Free (open-source)

  Pa11y:
    → CLI tool for automated accessibility testing
    → Engine: Uses axe-core, HTMLCS, or Lighthouse
    → CI/CD: npm script; configurable thresholds; multiple URL testing
    → Output: JSON, CSV, HTML reports
    → Pricing: Free (open-source)

  WAVE (WebAIM):
    → Browser extension and API-based testing
    → Visual overlay showing accessibility issues on page
    → API: Programmatic testing via REST API
    → Coverage: WCAG 2.0/2.1 rules; ARIA validation
    → Pricing: Free (extension); API $99-$299/month

UNIT AND COMPONENT TESTING:

  jest-axe:
    → Integration with Jest testing framework
    → Test React/Vue/Angular components for accessibility
    → Example: render(Component); expect(container).toHaveNoViolations()
    → CI/CD: Runs as part of unit test suite

  @testing-library/react (React Testing Library):
    → Promotes accessible testing patterns
    → Queries by role, label, text (not by class/id)
    → Encourages testing from user perspective (not implementation details)

  cypress-axe:
    → Integration with Cypress E2E testing
    → Run accessibility audits on rendered pages
    → cy.checkA11y() after page load
    → CI/CD: Part of E2E test suite

CONTINUOUS MONITORING:

  Siteimprove:
    → Website-wide accessibility scanning
    → New issue detection (regression monitoring)
    → Priority scoring and remediation guidance
    → Integration with CMS, Jira, GitHub
    → Pricing: $1,500-$5,000/month (based on page count)

  UserWay / AccessiBe:
    → Accessibility overlay/widget (controversial — does NOT achieve compliance)
    → Automated fixes for some issues (contrast, zoom, text-to-speech)
    → Limitation: Does NOT fix keyboard navigation, ARIA, semantic HTML
    → Legal risk: Overlays have been challenged in ADA litigation
    → Recommendation: Use for supplemental support ONLY; not as primary compliance method

AUTOMATED TESTING COVERAGE REALITIES:

  Automated testing catches ~30-40% of WCAG violations:
    → Easily automated: Contrast, alt text, ARIA attributes, label association, heading hierarchy, color-only indicators
    → Cannot automate: Meaningful content order, logical focus order, meaningful alt text quality, keyboard usability of custom components, screen reader experience, cognitive accessibility

  Manual testing catches remaining 60-70%:
    → Screen reader testing (NVDA, JAWS, VoiceOver, TalkBack)
    → Keyboard-only navigation testing
    → Cognitive accessibility review (reading level, clarity, consistency)
    → Mobile accessibility testing (touch targets, gestures, viewport)
    → User testing with people who have disabilities
```

## Manual Testing Procedures

```
MANUAL ACCESSIBILITY TESTING CHECKLIST
========================================

SCREEN READER TESTING:

  NVDA (Windows — Free):
    → Navigate entire application with keyboard + NVDA
    → Verify: page title announced, landmarks identified, headings announced in order
    → Verify: all form elements have labels; error messages announced
    → Verify: dynamic content changes announced (live regions)
    → Verify: custom components (dropdowns, modals) work with screen reader
    → Key commands: N (next landmark), H (next heading), F (next form element), D (next table)

  JAWS (Windows — $1,195/year):
    → Most widely used screen reader in US corporate environment
    → Test with Virtual PC mode (default) and Focus Mode
    → Verify: complex data tables navigable (column/row headers announced)
    → Verify: ARIA live regions update announced appropriately
    → Key commands: Insert+F7 (item navigator), Insert+Number keys (headings)

  VoiceOver (macOS/iOS — Built-in, Free):
    → Enable: Cmd+F5 (macOS) or double-tap with 3 fingers (iOS)
    → Verify: iOS app navigable with VoiceOver gestures
    → Verify: Dynamic Type (large text) does not break layout
    → Verify: Custom controls have VoiceOver accessibility labels
    → Rotor: Navigate by headings, links, form elements, tables

  TalkBack (Android — Built-in, Free):
    → Enable: Accessibility → TalkBack
    → Verify: Android app navigable with TalkBack gestures
    → Verify: Content Description set on all image views
    → Verify: Focus order matches visual order
    → Verify: Custom views have proper accessibility properties

KEYBOARD-ONLY TESTING:

  Procedure:
    → Disconnect mouse; navigate entire application using keyboard only
    → Tab through all interactive elements
    → Verify: every interactive element is reachable and operable
    → Verify: focus indicator visible on all focused elements
    → Verify: no keyboard traps (can tab out of every component)
    → Verify: modals/dialogs trap focus appropriately (cannot tab outside modal)
    → Verify: custom components work with keyboard:
       Dropdown: Enter/Space to open, Arrow keys to navigate, Escape to close
       Modal: Escape to close, Tab cycles within modal, focus returns to trigger on close
       Carousel: Arrow keys to navigate, Escape to pause
       Date picker: Arrow keys to navigate dates, Enter to select

  Keyboard Shortcuts:
    → Tab: Move focus forward
    → Shift+Tab: Move focus backward
    → Enter/Space: Activate button/link/toggle
    → Arrow keys: Navigate within composite widgets
    → Escape: Close modal/dropdown/menu
    → Home/End: First/last item in list

COLOR CONTRAST VERIFICATION:

  Tools:
    → axe DevTools: Automated contrast checking with pass/fail
    → WebAIM Contrast Checker: Manual color pair testing
    → Chrome DevTools Elements panel: Audit → Run accessibility audit → contrast issues
    → Stark (Figma/Sketch plugin): Design-time contrast checking

  Minimum Ratios (WCAG 2.1 AA):
    → Normal text (< 18pt or < 14pt bold): 4.5:1
    → Large text (≥ 18pt or ≥ 14pt bold): 3:1
    → UI components and graphical objects: 3:1
    → Non-text elements (icons, form borders): 3:1

  Common Failures:
    → Light gray text on white background (e.g., #999 on #FFF = 2.85:1 — FAIL)
    → Blue links on colored backgrounds (e.g., #0066CC on #E6F0FF = 2.89:1 — FAIL)
    → Subtle icons on same-color background
    → Placeholder text (not a substitute for labels)
```

## Integration Points

- **axe DevTools by Deque**: Browser extension + CI/CD integration; enterprise accessibility testing; remediation guidance; Jira/GitHub integration; $2,700/year
- **Lighthouse CI**: Automated accessibility scoring in CI/CD; threshold assertions; report generation; free/open-source; integrates with GitHub, GitLab, Bitbucket
- **Siteimprove**: Continuous website monitoring; new issue detection; priority scoring; CMS integration; training platform; $1,500-$5,000/month
- **Stark Plugin (Figma/Sketch/Adobe XD)**: Design-time accessibility checking; contrast verification; color blindness simulation; component labeling; $9/month
- **A11y Project / WCAG 2.2 Quick Reference**: Free accessibility resources; checklist; technique documentation; community support
- **Jest + jest-axe**: Component-level accessibility testing in unit tests; fail tests on violations; integrates with existing test suite
- **Cypress + cypress-axe**: End-to-end accessibility testing; test rendered pages; integrate with E2E test suite; free
- **Pa11y CI**: Command-line accessibility testing; configurable thresholds; multi-URL testing; integrates with any CI/CD platform; free

## Edge Cases

- **Legacy applications (jQuery, AngularJS, classic ASP)**: Modern accessibility patterns difficult to retrofit; solution: progressive enhancement; add ARIA attributes incrementally; prioritize most-used pages; plan full modernization
- **Third-party components and widgets**: Chat widgets, analytics, payment forms may have accessibility issues beyond your control; solution: audit third-party components; request VPAT from vendors; provide accessible alternatives; isolate in iframes with proper labeling
- **Complex data visualizations (charts, graphs, dashboards)**: Screen reader description of visual data challenging; solution: provide data tables as alternative; add detailed text descriptions; use ARIA for chart semantics; consider accessible chart libraries (NVD3, accessible-chart-js)
- **Rich media (videos, audio, interactive content)**: Captions, transcripts, audio descriptions required; solution: automated captioning services (Rev, Otter.ai) with human review; provide downloadable transcripts; audio description track for critical visual information
- **International accessibility laws**: EU Accessibility Act (effective 2025); AODA (Canada); Equality Act (UK); JIS (Japan); each with specific requirements and enforcement; solution: adopt WCAG 2.2 AA as global baseline; add jurisdiction-specific requirements; legal review for target markets
- **ADA litigation risk**: Drive-by litigation targeting website accessibility; settlements ranging $10K-$100K+; solution: proactive compliance; publish accessibility statement; provide feedback mechanism; document accessibility efforts; consult accessibility legal counsel
- **Design system accessibility**: Build accessibility into design system components; solution: accessible component library with documented patterns; design-time contrast and accessibility checks; component-level automated testing; accessibility review as part of design system release process