Accessibility & WCAG

A production-grade skill for building inclusive web experiences. It encodes WCAG 2.2 standards, ARIA authoring practices, keyboard interaction patterns, and screen reader testing guidance into actionable rules and working code. Accessibility is not a checkbox - it is the baseline quality bar. Every user deserves a working product, regardless of how they interact with it.

When to use this skill

Trigger this skill when the user:

• Asks to make a component or page accessible or "a11y compliant"
• Needs to add ARIA roles, states, or properties to custom widgets
• Wants keyboard navigation implemented for interactive components
• Asks about screen reader support, announcements, or live regions
• Needs a WCAG 2.2 audit or compliance review
• Is working on focus management (modals, SPAs, route changes)
• Asks about color contrast, alt text, semantic HTML, or form labeling
• Is building custom widgets (dialog, tabs, combobox, menu, tooltip)

Do NOT trigger this skill for:

• Pure backend code with no HTML output or DOM interaction
• CSS-only styling questions that have no accessibility implications

Key principles

1. Semantic HTML first - The single highest-leverage accessibility action is using the right HTML element. <button> gives you keyboard support, focus, activation, and screen reader announcement for free. No ARIA patch matches it.

2. ARIA is a last resort - ARIA fills gaps where native HTML falls short. Before adding an ARIA attribute, ask: "is there a native element that does this?" If yes, use that element instead. Bad ARIA is worse than no ARIA.

3. Keyboard accessible everything - If a sighted mouse user can do something, a keyboard-only user must be able to do the same thing. There are no exceptions in WCAG 2.1 AA. Test every interaction without a mouse.

4. Test with real assistive technology - Automated tools catch approximately 30% of WCAG failures. The remaining 70% - focus management correctness, announcement quality, logical reading order, cognitive load - requires manual testing with VoiceOver, NVDA, or real users with disabilities.

5. Accessibility is not optional - It is a legal requirement (ADA, Section 508, EN 301 549), a quality signal, and the right thing to do. Build it in from the start; retrofitting is ten times harder than doing it correctly the first time.

Core concepts

POUR Principles (WCAG foundation)

Every WCAG criterion maps to one of four properties:

WCAG Conformance Levels

Target AA. New WCAG 2.2 AA criteria: focus appearance (2.4.11), dragging alternative (2.5.7), minimum target size 24x24px (2.5.8).

ARIA Roles, States, and Properties

ARIA exposes semantics to the accessibility tree - it does not change visual rendering or add keyboard behavior. Three categories:

• Roles - What the element is: role="dialog", role="tab", role="alert"
• States - Dynamic condition: aria-expanded, aria-selected, aria-disabled, aria-invalid
• Properties - Stable relationships: aria-label, aria-labelledby, aria-describedby, aria-controls

The Five Rules of ARIA:

1. Don't use ARIA if a native HTML element exists
2. Don't change native semantics unless absolutely necessary
3. All interactive ARIA controls must be keyboard operable
4. Don't apply aria-hidden="true" to focusable elements
5. All interactive elements must have an accessible name

Focus Management Model

• Tab order follows DOM order - keep DOM order logical and matching visual order
• tabindex="0" - adds element to natural tab order
• tabindex="-1" - programmatically focusable but removed from tab sequence
• tabindex="1+" - avoid; creates unpredictable tab order
• Roving tabindex - composite widgets (tabs, toolbars, radio groups): only one item in tab order at a time; arrow keys navigate within
• Focus trap - modal dialogs must trap Tab/Shift+Tab within the dialog
• Focus return - always return focus to the trigger element when a modal or overlay closes

Common tasks

1. Write semantic HTML for common patterns

Choose elements for meaning, not appearance. Native semantics are free accessibility.

<!-- Page structure -->
<header>
  <nav aria-label="Primary navigation">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
</header>

<main id="main-content" tabindex="-1">
  <h1>Page Title</h1>
  <article>
    <h2>Article heading</h2>
    <p>Content...</p>
  </article>
  <aside aria-label="Related links">...</aside>
</main>

<footer>
  <nav aria-label="Footer navigation">...</nav>
</footer>

<!-- Skip link - must be first focusable element -->
<a href="#main-content" class="skip-link">Skip to main content</a>

.skip-link {
  position: absolute;
  top: -100%;
  left: 0;
  background: #005fcc;
  color: #fff;
  padding: 0.5rem 1rem;
  z-index: 9999;
}
.skip-link:focus {
  top: 0;
}

2. Implement keyboard navigation for custom widgets

Roving tabindex for a toolbar/tab list - only one item in tab order at a time:

function Toolbar({ items }: { items: { id: string; label: string }[] }) {
  const [activeIndex, setActiveIndex] = React.useState(0);
  const refs = React.useRef<(HTMLButtonElement | null)[]>([]);

  const handleKeyDown = (e: React.KeyboardEvent, index: number) => {
    let next = index;
    if (e.key === 'ArrowRight') next = (index + 1) % items.length;
    else if (e.key === 'ArrowLeft') next = (index - 1 + items.length) % items.length;
    else if (e.key === 'Home') next = 0;
    else if (e.key === 'End') next = items.length - 1;
    else return;

    e.preventDefault();
    setActiveIndex(next);
    refs.current[next]?.focus();
  };

  return (
    <div role="toolbar" aria-label="Text formatting">
      {items.map((item, i) => (
        <button
          key={item.id}
          ref={(el) => { refs.current[i] = el; }}
          tabIndex={i === activeIndex ? 0 : -1}
          onKeyDown={(e) => handleKeyDown(e, i)}
          onClick={() => setActiveIndex(i)}
        >
          {item.label}
        </button>
      ))}
    </div>
  );
}

3. Add ARIA to interactive components

For detailed accessible Dialog (Modal) and Tabs implementations with focus trapping, roving tabindex, and correct ARIA roles/states, see references/widget-examples.md.

4. Ensure color contrast compliance

WCAG AA contrast requirements:

/* Focus ring - must meet 3:1 against neighboring colors */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Never convey information by color alone */
.field-error {
  color: #c0392b; /* red - supplementary only */
  display: flex;
  align-items: center;
  gap: 0.25rem;
}
/* The icon + text label carry the meaning; color is an enhancement */
.field-error::before {
  content: '';
  display: inline-block;
  width: 1em;
  height: 1em;
  background: url('error-icon.svg') no-repeat center;
}

Tools: Chrome DevTools contrast panel, axe DevTools extension, Colour Contrast Analyser (desktop), npx lighthouse --only-categories=accessibility.

5. Manage focus for SPAs and modals

// SPA route change - announce and move focus
function useRouteAccessibility() {
  const location = useLocation();
  const headingRef = React.useRef<HTMLHeadingElement>(null);

  React.useEffect(() => {
    // Update document title
    document.title = `${getPageTitle(location.pathname)} - My App`;

    // Move focus to h1 so keyboard users know where they are
    headingRef.current?.focus();

    // Optional: announce via live region
    const announcer = document.getElementById('route-announcer');
    if (announcer) announcer.textContent = `Navigated to ${getPageTitle(location.pathname)}`;
  }, [location.pathname]);

  return headingRef;
}

// In your page component:
function Page({ title }: { title: string }) {
  const headingRef = useRouteAccessibility();
  return (
    <>
      {/* Persistent live region - created once, reused */}
      <div id="route-announcer" aria-live="polite" aria-atomic="true"
        className="sr-only" />
      <h1 tabIndex={-1} ref={headingRef}>{title}</h1>
    </>
  );
}

/* Visually hidden but available to screen readers */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

6. Write effective alt text and labels

<!-- Informative image: describe purpose, not appearance -->
<img src="revenue-chart.png"
     alt="Q4 revenue: grew from $2M in October to $3.5M in December">

<!-- Decorative image: empty alt, screen reader skips it -->
<img src="decorative-wave.svg" alt="">

<!-- Functional image (inside link or button): describe the action -->
<a href="/home"><img src="logo.svg" alt="Acme Corp - Go to homepage"></a>
<button><img src="search-icon.svg" alt="Search"></button>

<!-- Complex image: short alt + long description -->
<figure>
  <img src="architecture-diagram.png"
       alt="System architecture overview"
       aria-describedby="arch-desc">
  <figcaption id="arch-desc">
    The frontend (React) calls an API gateway which routes to three microservices:
    auth, products, and orders. All services write to PostgreSQL.
  </figcaption>
</figure>

<!-- Form labels: explicit association is most robust -->
<label for="email">Email address <span aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" required
       aria-describedby="email-hint email-error">
<span id="email-hint" class="hint">We'll never share your email.</span>
<span id="email-error" role="alert" hidden>
  Please enter a valid email address.
</span>

7. Audit accessibility with axe-core and Lighthouse

# Lighthouse CLI audit
npx lighthouse https://your-site.com --only-categories=accessibility --output=html

# axe CLI scan
npx axe https://your-site.com

// axe-core in Jest / Vitest with Testing Library
import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

test('Modal has no accessibility violations', async () => {
  const { container } = render(
    <Dialog open title="Confirm" onClose={() => {}}>
      <p>Are you sure?</p>
      <button>Cancel</button>
      <button>Confirm</button>
    </Dialog>
  );
  const results = await axe(container);
  expect(results).toHaveNoViolations();
});

// axe-core standalone audit (browser console or Playwright)
import axe from 'axe-core';
const results = await axe.run(document.body);
results.violations.forEach(v => {
  console.error(`[${v.impact}] ${v.description}`);
  v.nodes.forEach(n => console.error('  ', n.html));
});

Manual audit checklist beyond automated tools:

• Tab through every interactive element - reachable? Visible focus? Logical order?
• Activate all controls with Enter/Space - do they work without a mouse?
• Open every modal/overlay - focus trapped? Escape closes? Focus returns to trigger?
• Resize to 400% zoom - content still readable and operable?
• Test with VoiceOver (macOS: Cmd+F5) or NVDA (Windows, free) for announcement quality

Load references/aria-patterns.md for complete widget patterns with keyboard interactions.

Anti-patterns

Gotchas

1. aria-hidden="true" on a focusable element creates a keyboard trap - Screen readers skip the element, but keyboard focus still lands on it. The user is stuck on something invisible. Never apply aria-hidden to any element that can receive focus; remove tabindex or use inert instead.

2. role="button" without keyboard handlers does nothing - Adding role="button" to a <div> tells screen readers it's a button, but doesn't add keyboard activation. You must also add tabindex="0" and handle both Enter and Space keydown events. Just use <button> instead.

3. Live regions must be in the DOM before content is injected - aria-live regions only announce changes that happen after they're rendered. If you inject the region and its content at the same time, screen readers won't announce it. Render the empty live region on page load, then populate it.

4. Focus return after modal close is not automatic - When a modal closes, focus goes to <body> by default. Users lose their place in the page. Always store document.activeElement before opening a modal and call .focus() on that element when the modal closes.

5. Automated tools catch ~30% of violations - axe and Lighthouse pass does not mean WCAG compliant. Focus order, announcement quality, color-alone information encoding, and logical reading order all require manual testing with a screen reader (VoiceOver on macOS, NVDA on Windows).

References

For detailed patterns and widget specifications, load the relevant reference:

• references/aria-patterns.md - Complete ARIA widget patterns: combobox, menu, tree, listbox, accordion, tooltip with correct roles, states, and keyboard interactions
• references/widget-examples.md - Accessible Dialog (Modal) and Tabs implementations with focus trapping and roving tabindex

Only load reference files when the current task requires that depth - they contain dense technical detail.