IT AI Skill

Accessibility Compliance Testing

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 manua...

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

Edge Cases