Accessibility

Accessibility is a community skill for implementing web accessibility standards and testing, covering ARIA attributes, semantic HTML, keyboard navigation, screen reader compatibility, and automated accessibility auditing for inclusive web applications.

What Is This?

Overview

Accessibility provides patterns for building web applications that meet WCAG guidelines and work for users with disabilities. It covers ARIA attribute implementation with roles, states, and properties for assistive technology, semantic HTML patterns using native elements for correct structure without ARIA overrides, keyboard navigation that ensures all interactive elements are reachable and operable without a mouse, screen reader compatibility with live regions and announcement patterns for dynamic content, and automated accessibility auditing that detects violations in development and CI pipelines. The skill enables developers to build inclusive applications that comply with accessibility standards.

Who Should Use This

This skill serves frontend developers building accessible web applications and components, QA engineers adding accessibility testing to CI pipelines, and teams working toward WCAG 2.1 AA compliance.

Why Use It?

Problems It Solves

Custom components built with div and span elements lack semantic meaning for assistive technology. Keyboard users cannot activate controls that rely solely on mouse handlers. Dynamic content updates are invisible to screen readers without live region announcements. Accessibility violations accumulate silently when not tested during development.

Core Highlights

ARIA patterns add semantic roles and states to custom components for assistive technology. Keyboard handlers implement standard navigation patterns like arrow keys, Tab, and Escape. Live regions announce dynamic content changes to screen readers automatically. Automated auditing catches common violations during development and in CI.

How to Use It?

Basic Usage

// Accessible dropdown component
import React, { useState,
  useRef, useEffect } from
  'react';

interface DropdownProps {
  label: string;
  options: string[];
  onSelect: (
    value: string) => void;
}

export function Dropdown({
  label, options, onSelect,
}: DropdownProps) {
  const [isOpen, setIsOpen] =
    useState(false);
  const [active, setActive] =
    useState(-1);
  const listRef =
    useRef<HTMLUListElement>(
      null);

  const handleKeyDown = (
    e: React.KeyboardEvent
  ) => {
    switch (e.key) {
      case 'ArrowDown':
        e.preventDefault();
        setActive((prev) =>
          Math.min(
            prev + 1,
            options.length - 1));
        break;
      case 'ArrowUp':
        e.preventDefault();
        setActive((prev) =>
          Math.max(prev - 1, 0));
        break;
      case 'Enter':
        if (active >= 0) {
          onSelect(
            options[active]);
          setIsOpen(false);
        }
        break;
      case 'Escape':
        setIsOpen(false);
        break;
    }
  };

  return (
    <div>
      <button
        aria-haspopup='listbox'
        aria-expanded={isOpen}
        onClick={() =>
          setIsOpen(!isOpen)}
        onKeyDown={handleKeyDown}
      >
        {label}
      </button>
      {isOpen && (
        <ul
          role='listbox'
          ref={listRef}
          aria-label={label}
        >
          {options.map(
            (opt, i) => (
            <li
              key={opt}
              role='option'
              aria-selected={
                i === active}
              onClick={() =>
                onSelect(opt)}
            >
              {opt}
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

Real-World Examples

// Automated accessibility testing
import { test, expect } from
  '@playwright/test';
import AxeBuilder from
  '@axe-core/playwright';

test('home page has no a11y'
  + ' violations', async ({
  page }) => {
  await page.goto('/');

  const results =
    await new AxeBuilder({
      page })
      .withTags([
        'wcag2a', 'wcag2aa'])
      .analyze();

  expect(
    results.violations
  ).toEqual([]);
});

test('modal traps focus',
  async ({ page }) => {
  await page.goto('/settings');
  await page.click(
    'button[aria-label='
    + '"Open settings"]');

  // Focus should be inside
  // the modal
  const focused =
    await page.evaluate(() =>
      document.activeElement
        ?.closest(
          '[role="dialog"]')
        !== null);
  expect(focused).toBe(true);

  // Tab should cycle within
  await page.keyboard
    .press('Tab');
  const stillInModal =
    await page.evaluate(() =>
      document.activeElement
        ?.closest(
          '[role="dialog"]')
        !== null);
  expect(
    stillInModal).toBe(true);
});

Advanced Tips

Use the roving tabindex pattern for composite widgets like toolbars and tab lists to maintain a single Tab stop with arrow key navigation. Implement skip navigation links for keyboard users to bypass repetitive navigation. Test with actual screen readers like NVDA and VoiceOver rather than relying solely on automated tools.

When to Use It?

Use Cases

Build an accessible form with proper label associations, error announcements, and keyboard-navigable inputs. Add axe-core testing to CI to catch accessibility regressions on every pull request. Implement a focus trap for modal dialogs that returns focus to the trigger element on close.

Related Topics

Web accessibility, WCAG compliance, ARIA patterns, screen reader testing, and keyboard navigation.

Important Notes

Requirements

Axe-core or similar library for automated accessibility auditing. Screen reader for manual testing of announcement patterns. Browser developer tools accessibility panel for inspecting computed roles.

Usage Recommendations

Do: use native HTML elements like button, select, and input before creating custom ARIA widgets. Test keyboard navigation for every interactive component. Add aria-live regions for content that updates dynamically.

Don't: use ARIA roles to override the semantics of native elements that already have correct behavior. Remove focus outlines without providing a visible alternative indicator. Rely exclusively on color to convey meaning or state changes.

Limitations

Automated tools catch roughly 30 to 40 percent of accessibility issues and cannot replace manual testing. Screen reader behavior varies across browsers and operating systems requiring cross-platform testing. Complex custom widgets like date pickers and rich text editors require extensive ARIA patterns that are difficult to implement.