WCAG 2.2: Practical Accessibility Guide

Web Content Accessibility Guidelines (WCAG) 2.2 became a W3C Recommendation in October 2023, adding 9 new success criteria focused on cognitive accessibility, mobile interaction, and focus visibility. This guide covers implementation strategies for semantic HTML, ARIA patterns, and testing methodologies—practical knowledge for building inclusive web experiences that meet legal requirements in the US (ADA) and EU (European Accessibility Act).

Abstract

WCAG 2.2 builds on the POUR framework (Perceivable, Operable, Understandable, Robust) with three compliance tiers:

What’s new in WCAG 2.2 (9 criteria added, 1 removed):

• Cognitive accessibility: Redundant Entry (A), Accessible Authentication (AA/AAA), Consistent Help (A)—no memory tests, no duplicate data entry
• Motor accessibility: Target Size Minimum 24×24px (AA), Dragging Movements alternatives (AA)
• Focus visibility: Focus Not Obscured (AA/AAA), Focus Appearance (AAA)—sticky headers can’t hide focused elements
• Removed: 4.1.1 Parsing—browsers now handle HTML robustly; assistive tech no longer parses markup directly

Implementation priorities:

1. Semantic HTML provides 80% of accessibility for free—landmarks, headings, native form controls
2. ARIA supplements native semantics for custom widgets—roles, states, and live regions
3. Automated testing catches ~57% of individual issues but only ~35% of WCAG criteria; manual testing is non-negotiable
4. Focus management in SPAs and modals is the most common source of accessibility regressions

Understanding WCAG 2.2

WCAG 2.2, published October 2023 (with minor definition updates in December 2024), contains 86 success criteria across three conformance levels. Each level is cumulative—AA includes all of A, AAA includes all of AA.

Level A (32 criteria) establishes minimum viability. Without these, assistive technologies cannot navigate or operate the interface. Failures at this level are complete barriers—a missing form label makes a field unusable for screen reader users, not merely inconvenient.

Level AA (24 additional, 56 total) balances impact against implementation cost. This is the legal target: ADA Title II requires WCAG 2.1 AA by 2026 for state/local government; the European Accessibility Act (enforced June 2025) mandates AA for businesses serving EU customers. Courts consistently use AA as the de facto standard for private sector litigation.

Level AAA (30 additional, 86 total) represents maximum accessibility but is intentionally not a blanket requirement. Some content fundamentally cannot meet certain AAA criteria—a sign language video cannot have a sign language interpretation, and some pages legitimately require reading comprehension above lower secondary education level.

WCAG 2.1 → 2.2 Migration: If you’re already AA-compliant with WCAG 2.1, you need to address 6 new criteria: Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8).

What’s New in WCAG 2.2

WCAG 2.2 added 9 success criteria and removed 1. The additions target three gaps: cognitive disabilities (underserved in 2.0/2.1), mobile/touch interactions, and focus visibility.

New Level A Criteria

3.2.6 Consistent Help requires help mechanisms (contact info, chat, self-help) to appear in the same relative location across pages. Users with cognitive disabilities rely on spatial consistency to find help without searching.

1
<!-- Help in consistent footer position across all pages -->
2
<footer>
3
  <nav aria-label="Help">
4
    <a href="/contact">Contact Us</a>
5
    <a href="/faq">FAQ</a>
6
    <button id="chat-toggle">Chat Support</button>
7
  </nav>
8
</footer>

3.3.7 Redundant Entry prohibits asking users to re-enter information they’ve already provided in the same session, unless re-entry is essential (security confirmation) or the previous value is no longer valid. Auto-population or selection from previous entries satisfies this.

1
<!-- Shipping address auto-fills billing if same -->
2
<fieldset>
3
  <legend>Billing Address</legend>
4
  <label>
5
    <input type="checkbox" id="same-as-shipping" checked />
6
    Same as shipping address
7
  </label>
8
  <!-- Fields auto-populate when checked -->
9
</fieldset>

New Level AA Criteria

2.4.11 Focus Not Obscured (Minimum) ensures focused elements aren’t entirely hidden by sticky headers, footers, or overlays. Partial obscuring is permitted at AA; full visibility requires AAA (2.4.12).

1
/* Ensure focused content isn't hidden by sticky header */
2
:focus {
3
  scroll-margin-top: 80px; /* Height of sticky header + padding */
4
}
5

6
/* Or use scroll-padding on the scroll container */
7
html {
8
  scroll-padding-top: 80px;
9
}

2.5.7 Dragging Movements requires a single-pointer alternative for any drag operation. Users with motor impairments may not be able to maintain pressure while moving.

1
<!-- Drag-to-reorder list with button alternatives -->
2
<li draggable="true">
3
  <span>Item 1</span>
4
  <button aria-label="Move Item 1 up" onclick="moveUp(this)">↑</button>
5
  <button aria-label="Move Item 1 down" onclick="moveDown(this)">↓</button>
6
</li>

2.5.8 Target Size (Minimum) requires 24×24 CSS pixel minimum for pointer targets, with exceptions:

1
/* Minimum touch target with spacing exception fallback */
2
.icon-button {
3
  min-width: 24px;
4
  min-height: 24px;
5
  padding: 12px; /* Increases clickable area */
6
}
7

8
/* If 24px isn't achievable, ensure 24px spacing */
9
.small-button {
10
  min-width: 20px;
11
  min-height: 20px;
12
  margin: 4px; /* Creates 24px circle clearance */
13
}

3.3.8 Accessible Authentication (Minimum) prohibits cognitive function tests (memory, transcription, puzzle-solving) as the sole authentication method. Alternatives must exist:

• Copy-paste enabled for passwords (no blocking paste)
• Password managers can auto-fill
• OAuth/SSO (delegated authentication)
• Biometrics or hardware tokens
• Email/SMS codes (but not CAPTCHA that requires transcription)

1
<!-- Accessible login with password manager support -->
2
<form>
3
  <label for="email">Email</label>
4
  <input type="email" id="email" autocomplete="username" />
5

6
  <label for="password">Password</label>
7
  <input type="password" id="password" autocomplete="current-password" />
8

9
  <!-- Alternative: passwordless -->
10
  <button type="button" onclick="sendMagicLink()">Email me a login link</button>
11
</form>

New Level AAA Criteria

• 2.4.12 Focus Not Obscured (Enhanced): No part of focused element obscured (stricter than 2.4.11)
• 2.4.13 Focus Appearance: Minimum 2px perimeter, 3:1 contrast between focused/unfocused states
• 3.3.9 Accessible Authentication (Enhanced): No object recognition or personal content identification

Removed: 4.1.1 Parsing

WCAG 2.2 removed 4.1.1 Parsing because modern assistive technologies no longer parse HTML directly—they rely on browser accessibility APIs. Browsers now handle malformed HTML robustly, and issues that would have failed 4.1.1 (duplicate IDs, improper nesting) cause failures in other criteria (4.1.2 Name, Role, Value) when they actually impact users.

Migration note: If your test suite checks 4.1.1, don’t simply remove those tests. Duplicate IDs still fail 4.1.2 when they break accessible names. The change acknowledges that 4.1.1 was testing a mechanism (HTML validity) rather than an outcome (AT compatibility).

The POUR Principles

WCAG organizes all 86 success criteria under four principles. Understanding which principle a criterion belongs to clarifies what breaks when it fails.

Perceivable failures create absolute barriers for specific disabilities—a missing alt attribute means blind users receive nothing. Operable failures often affect multiple groups: keyboard traps block keyboard-only users, motor-impaired users, and many screen reader users.

Understandable criteria address cognitive accessibility, the focus of WCAG 2.2’s additions. Cognitive disabilities affect ~15% of the population—more than any other disability category—yet were underserved in earlier WCAG versions.

Robust ensures AT compatibility. With 4.1.1 Parsing removed, the remaining Robust criteria focus on what browsers expose to the accessibility tree (4.1.2 Name, Role, Value) and how updates are communicated (4.1.3 Status Messages).

Semantic HTML Implementation

Semantic HTML provides most accessibility automatically. Native elements expose roles, states, and keyboard behavior to assistive technologies without JavaScript.

Landmarks and Structure

1
<header>
2
  <nav aria-label="Main navigation">
3
    <ul>
4
      <li><a href="#main">Skip to main content</a></li>
5
      <li><a href="/home">Home</a></li>
6
      <li><a href="/about">About</a></li>
7
    </ul>
8
  </nav>
9
</header>
10

11
<main id="main">
12
  <article>
13
    <h1>Page Title</h1>
14
    <section>
15
      <h2>Section Heading</h2>
16
      <p>Content goes here...</p>
17
    </section>
18
  </article>
19
</main>
20

21
<aside>
22
  <h2>Related Information</h2>
23
</aside>
24

25
<footer>
26
  <p>&copy; 2024 Your Website</p>
27
</footer>

Heading Hierarchy Implement a logical heading structure without skipping levels:

1
<h1>Main Page Title</h1>
2
<h2>Major Section</h2>
3
<h3>Subsection</h3>
4
<h3>Another Subsection</h3>
5
<h2>Another Major Section</h2>
6
<h3>Subsection</h3>

Language Declaration Always specify the document language and mark language changes:

1
<html lang="en">
2
  <head>
3
    <title>English Page</title>
4
  </head>
5
  <body>
6
    <p>This is English text.</p>
7
    <p lang="es">Este texto está en español.</p>
8
  </body>
9
</html>

Forms and Input Elements

Forms are critical interaction points that require careful accessibility implementation:

Proper Labeling Every form control must have an accessible label:

1
<!-- Explicit labeling (preferred) -->
2
<label for="email">Email Address (required)</label>
3
<input type="email" id="email" name="email" required aria-describedby="email-error" />
4

5
<!-- Implicit labeling -->
6
<label>
7
  Password
8
  <input type="password" name="password" required />
9
</label>
10

11
<!-- Using aria-label when visual label isn't desired -->
12
<input type="search" name="search" aria-label="Search products" placeholder="Search..." />

Grouping Related Controls Use fieldset and legend for radio buttons and checkboxes:

1
<fieldset>
2
  <legend>Preferred Contact Method</legend>
3
  <input type="radio" id="email" name="contact" value="email" />
4
  <label for="email">Email</label>
5

6
  <input type="radio" id="phone" name="contact" value="phone" />
7
  <label for="phone">Phone</label>
8

9
  <input type="radio" id="mail" name="contact" value="mail" />
10
  <label for="mail">Mail</label>
11
</fieldset>

Error Handling and Validation Provide clear, helpful error messages:

1
<label for="username">Username (required)</label>
2
<input type="text" id="username" name="username" required aria-describedby="username-error" aria-invalid="true" />
3
<div id="username-error" role="alert">Username is required and must be at least 3 characters long.</div>

Instructions and Help Text Use aria-describedby to associate help text with form controls:

1
<label for="password">Password</label>
2
<input type="password" id="password" name="password" aria-describedby="password-help" required />
3
<div id="password-help">Password must be at least 8 characters long and contain at least one number.</div>

Images and Media

Alternative Text for Images Provide meaningful alt text that serves the same purpose as the image:

1
<!-- Informative image -->
2
<img src="sales-chart.png" alt="Sales increased 25% from January to March 2024" />
3

4
<!-- Decorative image -->
5
<img src="decorative-border.png" alt="" role="presentation" />
6

7
<!-- Functional image (button) -->
8
<button type="submit">
9
  <img src="search-icon.png" alt="Search" />
10
</button>
11

12
<!-- Complex image with longer description -->
13
<img src="complex-chart.png" alt="Quarterly sales data" aria-describedby="chart-desc" />
14
<div id="chart-desc">
15
  Detailed description: Sales data shows Q1 at $100k, Q2 at $150k, Q3 at $175k, and Q4 at $200k, representing steady
16
  growth throughout the year.
17
</div>

Video and Audio Accessibility Multimedia content requires multiple accessibility features:

1
<!-- Video with captions and audio description -->
2
<video controls>
3
  <source src="training-video.mp4" type="video/mp4" />
4
  <track kind="captions" src="captions.vtt" srclang="en" label="English captions" />
5
  <track kind="descriptions" src="descriptions.vtt" srclang="en" label="Audio descriptions" />
6
  <p>Your browser doesn't support video. <a href="transcript.html">Read the transcript</a></p>
7
</video>
8

9
<!-- Audio-only content -->
10
<audio controls>
11
  <source src="podcast.mp3" type="audio/mpeg" />
12
  <p>Your browser doesn't support audio. <a href="transcript.html">Read the transcript</a></p>
13
</audio>
14
<p><a href="podcast-transcript.txt">Download transcript</a></p>

Interactive Elements and Custom Components

Buttons and Links Ensure interactive elements have clear purposes and are keyboard accessible:

1
<!-- Descriptive button text -->
2
<button type="submit">Submit Contact Form</button>
3

4
<!-- Button with icon needs accessible text -->
5
<button type="button" aria-label="Close dialog">
6
  <svg aria-hidden="true">...</svg>
7
</button>
8

9
<!-- Link with clear destination -->
10
<a href="/products/laptops">View all laptop models</a>
11

12
<!-- Link opening new window/tab -->
13
<a href="/terms.pdf" target="_blank"> Terms of Service <span class="sr-only">(opens in new tab)</span> </a>

Custom Interactive Components When creating custom widgets, use ARIA roles, properties, and states:

1
<!-- Custom dropdown menu -->
2
<div class="dropdown">
3
  <button aria-haspopup="true" aria-expanded="false" id="menu-button">Options</button>
4
  <ul role="menu" aria-labelledby="menu-button" hidden>
5
    <li role="menuitem"><a href="/option1">Option 1</a></li>
6
    <li role="menuitem"><a href="/option2">Option 2</a></li>
7
    <li role="menuitem"><a href="/option3">Option 3</a></li>
8
  </ul>
9
</div>
10

11
<!-- Custom tab interface -->
12
<div role="tablist" aria-label="Content sections">
13
  <button role="tab" aria-selected="true" aria-controls="panel1" id="tab1">Section 1</button>
14
  <button role="tab" aria-selected="false" aria-controls="panel2" id="tab2">Section 2</button>
15
</div>
16

17
<div role="tabpanel" id="panel1" aria-labelledby="tab1">
18
  <h2>Section 1 Content</h2>
19
  <p>Content for the first section...</p>
20
</div>
21

22
<div role="tabpanel" id="panel2" aria-labelledby="tab2" hidden>
23
  <h2>Section 2 Content</h2>
24
  <p>Content for the second section...</p>
25
</div>

Color and Visual Design

Color Contrast Requirements Ensure sufficient contrast ratios for all text and UI components:

• Normal text: Minimum 4.5:1 contrast ratio (WCAG AA)
• Large text (18pt+ or 14pt+ bold): Minimum 3:1 contrast ratio
• UI components: Minimum 3:1 contrast ratio for borders, icons, and focus indicators

Color-Independent Information Never rely solely on color to convey information:

1
<!-- Bad: Only color indicates required field -->
2
<label style="color: red;">Email</label>
3
<input type="email" name="email" />
4

5
<!-- Good: Color plus text/symbol indicator -->
6
<label>Email <span class="required" aria-label="required">*</span></label>
7
<input type="email" name="email" required />
8

9
<!-- Good: Error states with multiple indicators -->
10
<label for="email">Email</label>
11
<input type="email" id="email" name="email" aria-invalid="true" class="error" aria-describedby="email-error" />
12
<div id="email-error" class="error-message" role="alert">⚠️ Please enter a valid email address</div>

Keyboard Navigation and Focus Management

Focus Indicators Provide clear, visible focus indicators for all interactive elements:

1
/* Ensure focus indicators are visible */
2
button:focus,
3
input:focus,
4
select:focus,
5
textarea:focus,
6
a:focus {
7
  outline: 2px solid #005fcc;
8
  outline-offset: 2px;
9
}
10

11
/* Custom focus styles that meet contrast requirements */
12
.custom-button:focus {
13
  box-shadow: 0 0 0 3px rgba(0, 95, 204, 0.5);
14
  outline: 2px solid #005fcc;
15
}

Focus Trapping

Modals must trap focus—users shouldn’t be able to Tab out of the modal to content behind it. The pattern: track first/last focusable elements, intercept Tab at boundaries.

3 collapsed lines
1
function trapFocus(element) {
2
  const focusable = element.querySelectorAll('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])')
3
  const first = focusable[0]
4
  const last = focusable[focusable.length - 1]
5

6
  element.addEventListener("keydown", (e) => {
7
    if (e.key !== "Tab") return
8
    if (e.shiftKey && document.activeElement === first) {
9
      last.focus()
10
      e.preventDefault()
11
    } else if (!e.shiftKey && document.activeElement === last) {
12
      first.focus()
13
      e.preventDefault()
3 collapsed lines
14
    }
15
  })
16
}

Dynamic Content and SPAs

SPAs and dynamic content require explicit accessibility management that static pages handle automatically.

Live Regions announce changes to screen readers without moving focus:

1
<!-- polite: announced when user is idle; assertive: immediate interruption -->
2
<div id="status" role="status" aria-live="polite"></div>
3
<div id="alerts" role="alert" aria-live="assertive"></div>

SPA Route Changes must update document title and move focus:

2 collapsed lines
1
function navigateToPage(pageContent, pageTitle) {
2
  document.getElementById("main-content").innerHTML = pageContent
3
  document.title = pageTitle
4

5
  // Move focus to main content, not page top
6
  const main = document.getElementById("main-content")
7
  main.setAttribute("tabindex", "-1")
8
  main.focus()
9
}

Modal Focus requires: (1) trap focus inside, (2) return focus on close.

2 collapsed lines
1
function openModal(modal) {
2
  const previousFocus = document.activeElement
3

4
  modal.removeAttribute("hidden")
5
  modal.querySelector("button, [href], input")?.focus()
6
  trapFocus(modal)
7

8
  modal.addEventListener("close", () => previousFocus.focus(), { once: true })
1 collapsed line
9
}

Testing Strategies

Automated tools detect ~57% of individual accessibility issues (Deque 2024 study across 13,000+ pages) but only ~35% of WCAG success criteria are fully automatable. The remaining issues require manual testing—there’s no shortcut.

Automated Testing Coverage

Contrast issues alone account for ~30% of detected issues—highly automatable but only part of the picture.

Tool Selection

axe-core powers most accessibility testing. Use @axe-core/playwright or cypress-axe for CI integration. Configure for WCAG 2.2 AA:

5 collapsed lines
1
// Configure axe for WCAG 2.2 AA
2
const axeConfig = {
3
  runOnly: {
4
    type: "tag",
5
    values: ["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"],
6
  },
7
}

Pa11y for CLI/CI pipelines—respects robots.txt and handles JavaScript-rendered content.

Lighthouse provides quick audits but uses a subset of axe-core rules. Use for initial scans, not compliance verification.

Screen Reader Testing

Test with at least one screen reader per platform your users access:

Focus testing on: navigation flow, form completion, dynamic content updates, and error recovery.

CI/CD Integration for Automated Accessibility Testing

Integrating accessibility testing into your continuous integration and deployment pipeline ensures that accessibility issues are caught early and consistently.

Setting Up Automated Testing in CI/CD

GitHub Actions Example:

22 collapsed lines
1
name: Accessibility Testing
2
on: [push, pull_request]
3

4
jobs:
5
  accessibility-test:
6
    runs-on: ubuntu-latest
7
    steps:
8
      - uses: actions/checkout@v2
9

10
      - name: Setup Node.js
11
        uses: actions/setup-node@v2
12
        with:
13
          node-version: "16"
14

15
      - name: Install dependencies
16
        run: npm install
17

18
      - name: Build application
19
        run: npm run build
20

21
      - name: Start application
22
        run: npm start &
23

24
      - name: Wait for application to start
25
        run: sleep 30
26

27
      - name: Run Pa11y tests
28
        run: |
29
          npx pa11y-ci --sitemap http://localhost:3000/sitemap.xml
30

31
      - name: Run axe tests with Cypress
32
        run: npx cypress run --spec "cypress/integration/accessibility.spec.js"

Cypress with axe-core:

6 collapsed lines
1
// cypress/integration/accessibility.spec.js
2
describe("Accessibility Tests", () => {
3
  beforeEach(() => {
4
    cy.visit("/")
5
    cy.injectAxe()
6
  })
7

8
  it("Has no accessibility violations on home page", () => {
9
    cy.checkA11y()
10
  })
11

12
  it("Has no accessibility violations on contact form", () => {
13
    cy.visit("/contact")
14
    cy.checkA11y()
15
  })
16

17
  it("Has no accessibility violations after form interaction", () => {
18
    cy.visit("/contact")
19
    cy.get("#name").type("Test User")
20
    cy.get("#email").type("test@example.com")
21
    cy.checkA11y()
22
  })
23
})

Playwright with axe-core:

3 collapsed lines
1
const { test, expect } = require("@playwright/test")
2
const AxeBuilder = require("@axe-core/playwright")
3

4
test("Homepage accessibility", async ({ page }) => {
5
  await page.goto("/")
6

7
  const accessibilityScanResults = await new AxeBuilder({ page }).analyze()
8

9
  expect(accessibilityScanResults.violations).toEqual([])
10
})

Quality Gates and Reporting

Implement accessibility quality gates that fail builds when critical issues are found:

1
- name: Run accessibility tests
2
  run: |
3
    npx pa11y-ci --threshold 5 http://localhost:3000
4
  continue-on-error: false
5

6
- name: Generate accessibility report
7
  run: |
8
    npx pa11y-ci --reporter json > accessibility-report.json
9

10
- name: Upload accessibility report
11
  uses: actions/upload-artifact@v2
12
  with:
13
    name: accessibility-report
14
    path: accessibility-report.json

Web Components and Shadow DOM

Shadow DOM creates accessibility challenges because ARIA attributes don’t penetrate the shadow boundary and screen readers may not correctly associate labels across boundaries.

Key patterns:

8 collapsed lines
1
class AccessibleComponent extends HTMLElement {
2
  static get observedAttributes() {
3
    return ["aria-label", "aria-describedby"]
4
  }
5

6
  connectedCallback() {
7
    // Forward ARIA from host to shadow root element
8
    const button = this.shadowRoot.querySelector("button")
9
    for (const attr of AccessibleComponent.observedAttributes) {
10
      if (this.hasAttribute(attr)) {
11
        button.setAttribute(attr, this.getAttribute(attr))
12
      }
13
    }
14
  }
15

16
  attributeChangedCallback(name, oldVal, newVal) {
17
    // Keep shadow DOM in sync with host attributes
18
    this.shadowRoot?.querySelector("button")?.setAttribute(name, newVal)
19
  }
20
}

Edge cases:

• aria-labelledby and aria-describedby cannot reference IDs outside the shadow root
• Use aria-label instead, or expose a <slot> for labeling content
• Focus delegation with delegatesFocus: true in attachShadow() options

Legal Requirements

Accessibility law has shifted from guidance to enforcement. Know your obligations.

United States

ADA Title II (state/local government): DOJ’s 2024 rule mandates WCAG 2.1 AA by April 2026 for entities with 50,000+ population, April 2027 for smaller entities.

ADA Title III (private sector): No explicit WCAG version in regulation, but courts consistently apply WCAG 2.1 AA as the standard. The “places of public accommodation” interpretation covers websites—Domino’s v. Robles (2019) confirmed this.

Section 508 (federal government): Still references WCAG 2.0 AA via the Revised 508 Standards (2017). Refresh expected but not yet scheduled.

European Union

European Accessibility Act (EAA): Enforced since June 28, 2025. Applies to businesses selling to EU customers regardless of where the business is located. Currently requires WCAG 2.1 AA via EN 301 549; update to include WCAG 2.2 in progress.

Web Accessibility Directive: Applies to public sector bodies. Required WCAG 2.1 AA since September 2020.

Practical note: Target WCAG 2.2 AA even if current laws reference 2.1. The delta is 6 criteria, and demonstrating awareness of current standards strengthens legal defensibility.

Appendix

Prerequisites

• HTML5 semantic elements and document structure
• CSS layout and responsive design fundamentals
• JavaScript event handling and DOM manipulation
• Basic understanding of assistive technology categories (screen readers, switch devices, voice control)

Summary

• WCAG 2.2 contains 86 success criteria across three levels (A: 32, AA: +24, AAA: +30)
• New in 2.2: 9 criteria targeting cognitive accessibility, motor accessibility, and focus visibility; 4.1.1 Parsing removed
• Legal compliance requires WCAG 2.1 AA minimum (US ADA, EU EAA); target 2.2 AA for future-proofing
• Automated testing catches ~57% of individual issues but only ~35% of criteria; manual testing is mandatory
• Semantic HTML provides most accessibility automatically; ARIA supplements for custom widgets
• Focus management in SPAs and modals is the most common source of regressions

Terminology

• a11y: Numeronym for “accessibility” (a + 11 letters + y)
• AT: Assistive Technology—software/hardware enabling people with disabilities to use computers
• POUR: Perceivable, Operable, Understandable, Robust—WCAG’s organizing principles
• ARIA: Accessible Rich Internet Applications—W3C specification for enhancing HTML semantics
• Live Region: ARIA mechanism for announcing dynamic content changes to screen readers
• Focus Trap: Containing keyboard focus within a component (intentional in modals, a bug elsewhere)

References

Specifications (Primary)

• WCAG 2.2 W3C Recommendation - Normative requirements
• Understanding WCAG 2.2 - Intent and techniques for each criterion
• What’s New in WCAG 2.2 - W3C summary of changes
• WAI-ARIA 1.2 - ARIA specification
• ARIA Authoring Practices Guide - Component patterns and keyboard interaction

Official Documentation

• MDN Accessibility Guide - Browser implementation details
• ADA.gov Web Accessibility Guidance - DOJ official guidance
• EN 301 549 - EU accessibility standard

Testing Tools

• axe-core - Accessibility testing engine
• Deque Automated Testing Coverage Report - Research on automation limits
• DWP Accessibility Manual: Automated Testing - UK government testing guidance

Legal

• DOJ ADA Title II Web Accessibility Rule (2024) - Federal Register notice
• European Accessibility Act - EU directive overview