Design Accessibility

Design Accessibility

Purpose

Ensure digital products meet WCAG compliance with semantic HTML, correct ARIA, keyboard support, and inclusive patterns. Enable users of all abilities to perceive, understand, navigate, and interact with digital products effectively and independently.

Agent Protocol

Trigger

Exact user phrases: "accessibility", "a11y", "WCAG", "screen reader", "keyboard navigation", "color contrast", "ARIA", "inclusive design", "accessible", "508 compliance", "disabled users".

Input Context

Before activating, verify:

• Target WCAG level (A, AA, or AAA)
• Supported assistive technologies (screen readers, voice control)
• Component or page scope (entire app vs specific feature)
• Current accessibility baseline (none, partial, audited)
• Regulatory requirements (section 508, ADA, EAA)
• Design system or component library being used

Output Artifact

Accessibility audit with WCAG compliance plan, ARIA patterns, and testing strategy.

Response Format

# WCAG compliance status per criterion
# Audit findings with severity, location, and fix

<!-- Correct ARIA patterns -->
<!-- Keyboard interaction implementation -->

No preamble. No postamble. No explanations. No filler/hedging/transitions. Compress output — why use many token when few do trick.

Completion Criteria

• WCAG level target confirmed (AA minimum)
• Color contrast ratios verified (4.5:1 text, 3:1 large text)
• All interactive elements keyboard accessible
• ARIA landmarks defined for page structure
• Screen reader announcements verified for dynamic content
• Focus management implemented (visible focus, logical order)
• Automated a11y tests configured (axe/Lighthouse)
• Manual keyboard audit completed
• Screen reader testing completed on target platforms
• Accessibility documentation created for reusable patterns

Max Response Length

200 lines of spec, patterns, and configuration.

Framework/Methodology

POUR Framework

WCAG is organized around four principles:

WCAG Compliance Levels

Accessibility Maturity Model

Inclusive Design Principles

Workflow

Step 1: WCAG Level Target

AA minimum for all public-facing interfaces. AAA for: government, healthcare, financial, educational. If budget/time constrained, prioritize AA and document AAA gaps. Perceivable, Operable, Understandable, Robust (POUR) — every fix maps to at least one principle.

Assess current state against target level:

1. Run automated scan (axe/Lighthouse) for baseline
2. Manual keyboard audit (can all functionality be accessed?)
3. Screen reader audit (can content be understood audibly?)
4. Compile findings into severity matrix
5. Estimate effort and prioritize fixes

Step 2: Semantic HTML

Use native HTML elements before ARIA: <nav> not <div role="navigation">, <button> not <div role="button">, <heading> elements in correct hierarchy (h1 → h2 → h3, no skipping). Landmarks: <header>, <main>, <nav>, <aside>, <footer>. Each page has exactly one <main>.

Semantic HTML benefits:

• Built-in keyboard accessibility (native elements handle Tab, Enter, Space)
• Screen reader announcements (roles and states are pre-defined)
• SEO improvements (search engines understand structure)
• Reduced code complexity (less ARIA, less JavaScript)
• Future-proofing (browser improvements apply automatically)

Step 3: Color Contrast

Text contrast ratios: 4.5:1 for normal text (<18px), 3:1 for large text (>=18px bold or >=24px). UI component contrast: 3:1 for borders, icons, focus indicators. Use tools: WebAIM Contrast Checker, axe DevTools, Stark plugin. Never rely on color alone to convey information — add icons, patterns, or text labels.

Contrast requirements by WCAG:

Step 4: Keyboard Navigation

Every interactive element is reachable via Tab. Tab order matches visual order. Visible focus indicator (3:1 contrast against background, 2px minimum). No keyboard traps. Custom widgets use arrow keys for internal navigation (tablist, menu, combobox). Skip link at page start: "Skip to main content".

Keyboard interaction patterns for custom widgets:

Step 5: ARIA Patterns

Use ARIA only when native HTML is insufficient. Roles: alert, dialog, tablist, tab, tabpanel. Properties: aria-label, aria-labelledby, aria-describedby, aria-expanded, aria-controls, aria-current. States: aria-disabled, aria-hidden, aria-selected, aria-checked. Always test ARIA with a screen reader — incorrect ARIA is worse than no ARIA.

ARIA usage rules:

• First rule of ARIA: Don't use ARIA if you can use a native HTML element
• Second rule: Don't change native semantics (don't add role="button" to <h1>)
• Third rule: All interactive ARIA widgets must be keyboard accessible
• Fourth rule: Don't use role="presentation" or aria-hidden="true" on focusable elements
• Fifth rule: All interactive elements must have an accessible name

Step 6: Dynamic Content

Loading states: aria-busy="true". Live regions: aria-live="polite" for non-critical updates, aria-live="assertive" for time-sensitive alerts. Toast/notification: role="alert". Modal: trap focus inside, role="dialog" + aria-modal="true", close on Escape. Announcements: use aria-live regions, not screen reader detection hacks.

Step 7: Testing Strategy

Automated (axe DevTools, Lighthouse in CI): catches 30% of issues — contrast, ARIA, heading hierarchy, label associations. Manual: keyboard-only navigation (full pass), screen reader testing (VoiceOver macOS, NVDA Windows, TalkBack Android, VoiceOver iOS). User testing with assistive tech users for complex interactions.

Testing frequency:

Common screen reader commands for testing:

Step 8: Accessible Forms

Every form input has a visible <label>. Labels must be programmatically associated (not just visually near). Error messages must be associated with inputs via aria-describedby. Required fields indicated with required attribute (not just asterisk). Success messages announced via live region.

Form accessibility checklist:

• All inputs have <label> with for attribute matching input id
• Required fields have required attribute (screen readers announce)
• Error messages linked to inputs via aria-describedby
• Error summary at top of form with links to error fields
• Input purpose can be programmatically determined (autocomplete attributes)
• No placeholder-only labeling (placeholder disappears on input)
• Distinct focus indicators on all form controls

Common Pitfalls

Best Practices

Templates & Tools

Accessibility Audit Template

Issue: {description}
WCAG Criterion: {SC number}
Severity: {Critical / Major / Minor / Suggestion}
Location: {URL or component path}
Current Behavior: {what happens}
Expected Behavior: {what should happen}
Fix: {specific remediation steps}
Owner: {person responsible}
Status: {Open / In Progress / Fixed / Verified}

Focus Management Implementation

function handleDialogOpen(dialogEl) {
  const previousFocus = document.activeElement;
  dialogEl.show();
  trapFocus(dialogEl);

  function handleEscape(e) {
    if (e.key === 'Escape') {
      dialogEl.close();
      previousFocus.focus();
    }
  }

  document.addEventListener('keydown', handleEscape);
}

Skip Link Implementation

<a href="#main-content" class="skip-link">Skip to main content</a>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px;
  z-index: 100;
}
.skip-link:focus {
  top: 0;
}

Automated Testing Configuration (axe-core)

import axe from 'axe-core';

function runA11yTests() {
  axe.run(document, {
    runOnly: ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa']
  }, (err, results) => {
    if (err) throw err;
    console.log(`${results.violations.length} violations found`);
    results.violations.forEach(v => {
      console.log(`- ${v.id}: ${v.description}`);
      v.nodes.forEach(n => console.log(`  ${n.target}`));
    });
  });
}

Testing Tools

Case Studies

Case Study 1: E-commerce Accessibility Redesign Increases Revenue

An online retailer redesigned their site for WCAG AA compliance. Changes included: semantic HTML restructuring, color contrast improvements, keyboard navigation, screen reader announcements for cart updates, and accessible form validation. Post-launch analytics showed:

• 20% increase in conversion rate from users with disabilities (estimated from assistive tech detection)
• 15% improvement in overall conversion (benefits extended to all users)
• 25% reduction in cart abandonment
• 40% reduction in form submission errors

Method: WCAG AA compliance audit → systematic remediation across 120 pages Key insight: Accessibility improvements benefited all users, not just those with disabilities Impact: 20% increase in conversions from assistive technology users, 15% overall

Case Study 2: Financial Services App Keyboard Navigation

A financial services web app received complaints from users who couldn't complete transactions using keyboard alone. A full keyboard audit revealed 47 focus and navigation issues. Fixes included: skip links, logical tab order, visible focus indicators, and keyboard shortcuts for common actions. After fixes, keyboard-only task completion increased from 45% to 95%, and support tickets related to keyboard navigation dropped by 80%.

Method: Keyboard-only usability audit → systematic issue remediation Key insight: Many power users (not just those with disabilities) prefer keyboard navigation Impact: Keyboard task completion 45% to 95%, support tickets -80%

Case Study 3: Design System Accessibility Integration

A SaaS company integrated accessibility into their design system by creating accessible component templates with:

• Built-in ARIA patterns for all interactive components
• Color token system enforcing minimum contrast ratios
• Focus indicator styles included in every component
• Automated testing in the component build pipeline
• Documentation for each component's accessibility features

Result: New features built with the design system achieved 95% automated compliance out of the box, reducing per-feature accessibility audit effort by 70%. Annual accessibility audit findings decreased by 60% year-over-year.

Method: Accessibility embedded in design system components, tokens, and documentation Key insight: Upstream accessibility (in the design system) is more efficient than per-feature fixes Impact: Per-feature a11y audit effort -70%, annual findings -60%

Rules

• Semantic HTML first — ARIA only as supplement.
• No color-only information — always pair with text or icon.
• Focus indicators are never removed — only improved.
• Every form input has a visible <label>.
• Dynamic content changes are announced via live regions.
• Tab order = DOM order (avoid tabindex > 0).
• Automated testing catches syntax — human testing catches experience.
• Disable animations with prefers-reduced-motion.
• Every interactive element must have an accessible name.
• Heading hierarchy must be sequential (no skipping levels).
• Keyboard testing must be completed for every feature before release.
• Custom widgets must follow WAI-ARIA Authoring Practices patterns.
• Error messages must be programmatically associated with their inputs.
• All images must have alt text (decorative images get alt="").
• Touch targets must be minimum 44x44px on mobile.
• Content must not require horizontal scrolling at 320px viewport width.
• Focus must be managed programmatically for dynamic content changes.
• Accessibility fixes must be prioritized alongside functional bugs.
• Screen reader testing must include at least VoiceOver and NVDA.
• Accessibility documentation must be included in component handoff.

Mobile Accessibility Patterns

Touch Target Sizing

Spacing between touch targets: minimum 8px (prevents accidental taps). For targets below recommended size, increase padding inside the touch target area rather than enlarging the visual element.

Mobile Screen Reader Patterns

Mobile accessibility testing must include: gesture-only interactions (can they be performed with screen reader gestures?), focus indicators on mobile (visible on colored backgrounds), dynamic content announcements (live regions work on mobile WebView?), orientation lock impact (can content be accessed in both orientations?).

Mobile-Specific WCAG Criteria

• 1.3.4 Orientation: Content must not be locked to a single orientation unless essential (e.g., piano app)
• 1.3.5 Identify Input Purpose: Autofill attributes on form fields for password managers
• 1.4.10 Reflow: Content must not require horizontal scrolling at 320px equivalent
• 1.4.11 Non-text Contrast: UI components and graphic objects must have 3:1 contrast ratio
• 1.4.12 Text Spacing: No loss of content when text spacing is overridden
• 1.4.13 Content on Hover or Focus: Dismissible, hoverable, persistent popovers
• 2.5.5 Target Size (AAA): Target size at least 44x44px
• 2.5.7 Dragging Movements (AA): All dragging functionality must have a single-pointer alternative
• 2.5.8 Target Size (AA, 2.2 new): Target size at least 24x24px with exceptions

Accessibility Governance and CI/CD

Automated Testing in CI

# GitHub Actions — accessibility checks
name: Accessibility CI
on: [pull_request]
jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build
      - name: Lighthouse CI
        uses: treosh/lighthouse-ci-action@v11
        with:
          urls: |
            https://staging.example.com/
            https://staging.example.com/checkout
          configPath: ./lighthouserc.js
      - name: axe-core
        run: npx axe --exit --show-errors
      - name: Pa11y CI
        run: npx pa11y-ci --sitemap https://staging.example.com/sitemap.xml

Governance Maturity Levels

A11y Debt Tracking

Track accessibility issues like technical debt:

• Severity: Critical (blocks task completion), Major (significant friction), Minor (annoyance), Suggestion
• Fix effort: hours estimated per issue
• Category: Perceivable, Operable, Understandable, Robust (POUR)
• Source: Automated scan, manual audit, user report

Report quarterly to leadership: total issues, issues fixed, issues added, median severity, time-to-fix by severity. Target: zero critical/major issues in production.

Production Accessibility Checklist

Pre-Launch Verification

• All pages pass automated axe-core scan (zero violations in wcag2a, wcag2aa)
• Manual keyboard audit: all interactive elements reachable and operable via keyboard
• Screen reader audit: all content perceivable with VoiceOver (macOS) and NVDA (Windows)
• Color contrast: all text/background combos verified programmatically (4.5:1 minimum)
• Zoom test: page renders without breakage at 200% and 400% zoom
• Focus management: visible focus indicators on all interactive elements
• Form labels: every form input has a programmatically associated label
• Error handling: form errors are announced and associated with inputs
• Dynamic content: all updates are announced via aria-live regions
• Video/audio: captions, transcripts, and accessible controls
• PDFs: tagged with proper heading hierarchy and alt text
• Mobile: 44x44px minimum touch targets, no horizontal scroll at 320px
• Reduced motion: all animations disable with prefers-reduced-motion: reduce

Post-Launch Monitoring

• Monthly: automated scan of top 20 pages
• Quarterly: full keyboard audit + screen reader audit
• Bi-annually: user testing with assistive technology users
• Continuous: monitor support tickets for accessibility-related complaints
• Per release: a11y regression check on changed pages

Anti-Patterns

Tools & Deliverables

References

• references/accessible-forms.md — Accessible Forms
• references/aria-patterns.md — ARIA Patterns
• references/color-contrast-design.md — Color Contrast Design
• references/testing-tools.md — Testing Tools
• references/wcag-checklist.md — WCAG Checklist
• references/wcag-guide.md — WCAG Guide
• references/accessibility-testing-methods.md — Accessibility Testing Methods
• references/accessible-design-patterns.md — Accessible Design Patterns

Handoff

design-design-systems for accessible component library integration. quality-visual-testing for visual regression with a11y states. Carry forward: WCAG audit report, ARIA patterns, testing checklist.