Accessibility (WCAG 2.2)

Accessibility isn't a feature or a nice-to-have. It's a legal requirement in most jurisdictions, and it affects far more users than you think. About 15-20% of the population has some form of disability. Add in temporary impairments (broken arm, bright sunlight, loud environment) and situational limitations (holding a baby, slow connection), and you're designing for the majority.

The Four Principles (POUR)

All of WCAG is organized under four principles:

WCAG 2.2 Conformance Levels

Target AA. It's the legal standard and covers the vast majority of real-world accessibility needs.

Key Requirements: Detailed Checklist

Perceivable

Operable

Understandable

Robust

WCAG 2.2 New Criteria (2023)

These are the criteria added in WCAG 2.2 that you need to know:

ARIA: Practical Guide

The Rules of ARIA

1. Don't use ARIA if native HTML works. A <button> is better than <div role="button"> in every way.
2. Don't change native semantics unless you must. Don't add role="heading" to a <button>.
3. All interactive ARIA controls must be keyboard-accessible. If you add role="button", you must also handle Enter and Space key events.
4. Don't use role="presentation" or aria-hidden="true" on focusable elements. You'll make things invisible to screen readers but still keyboard-focusable.
5. All interactive elements must have an accessible name. Via aria-label, aria-labelledby, or visible text content.

Common ARIA Patterns

<!-- Landmark regions -->
<header role="banner">
<nav aria-label="Main navigation">
<main role="main">
<aside aria-label="Related articles">
<footer role="contentinfo">

<!-- When you have multiple navs, label them -->
<nav aria-label="Main navigation">...</nav>
<nav aria-label="Footer navigation">...</nav>

<!-- Live regions for dynamic content -->
<div aria-live="polite">  <!-- Non-urgent updates -->
  Items in cart: 3
</div>
<div aria-live="assertive">  <!-- Urgent alerts -->
  Error: Payment failed
</div>

<!-- Expandable content -->
<button aria-expanded="false" aria-controls="panel-1">
  Show details
</button>
<div id="panel-1" hidden>
  Panel content here
</div>

<!-- Tabs -->
<div role="tablist" aria-label="Account settings">
  <button role="tab" aria-selected="true" aria-controls="panel-1">
    Profile
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel-2">
    Security
  </button>
</div>
<div role="tabpanel" id="panel-1">Profile content</div>
<div role="tabpanel" id="panel-2" hidden>Security content</div>

<!-- Modal dialog -->
<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Delete account?</h2>
  <p>This action cannot be undone.</p>
  <button>Cancel</button>
  <button>Delete</button>
</div>

<!-- Form errors -->
<label for="email">Email address</label>
<input id="email"
  type="email"
  aria-describedby="email-error"
  aria-invalid="true"
>
<span id="email-error" role="alert">
  Please enter a valid email address
</span>

<!-- Loading state -->
<button aria-busy="true" aria-disabled="true">
  <span class="spinner"></span>
  Saving...
</button>

Semantic HTML Cheat Sheet

Prefer these over ARIA when possible:

Keyboard Navigation

Expected Keyboard Behaviors

Focus Management

Focus Trap for Modals

When a modal is open, Tab should cycle within the modal only. It shouldn't escape to the page behind it:

// Focus trap: cycle Tab within modal
function trapFocus(modal) {
  const focusable = modal.querySelectorAll(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];

  modal.addEventListener('keydown', (e) => {
    if (e.key === 'Tab') {
      if (e.shiftKey && document.activeElement === first) {
        e.preventDefault();
        last.focus();
      } else if (!e.shiftKey && document.activeElement === last) {
        e.preventDefault();
        first.focus();
      }
    }
    if (e.key === 'Escape') {
      closeModal();
    }
  });
}

Testing for Accessibility

Automated Testing (Catches ~30-40% of Issues)

Manual Testing Checklist

Do this for every major feature:

Screen Reader Testing Basics

Test these specific things:

Common Mistakes

Accessibility Testing in CI/CD

# Run axe-core tests in your CI pipeline
npx @axe-core/cli https://your-site.com

# Use Pa11y for automated testing
npx pa11y https://your-site.com --standard WCAG2AA

# Lighthouse CI
npx lhci autorun --collect.url=https://your-site.com

Set a threshold: Fail the build if the accessibility score drops below a defined level (e.g., 90/100 on Lighthouse).

Key Takeaways

• Target WCAG 2.2 AA. It's the legal standard and covers real-world needs.
• Use semantic HTML first. Only reach for ARIA when native elements can't achieve the pattern.
• Test with keyboard, screen reader, zoom, and color blindness simulation. Automated tools catch less than half of issues.
• Color must never be the only indicator. Always pair with icons, text, or patterns.
• Every interactive element needs visible focus indicators, keyboard access, and an accessible name.
• Manage focus explicitly: move focus into modals, back on close, to errors on submit.
• Alt text: describe what the image shows, not what it is. "Team celebrating product launch" not "photo.jpg".
• Accessibility benefits everyone: screen readers, keyboard users, slow connections, bright sunlight, one-handed use.