Audit and improve web accessibility following WCAG 2.2 guidelines. Use when asked to "improve accessibility", "a11y audit", "WCAG compliance", "screen reader support", "keyboard navigation", or "make accessible".

Accessibility (a11y) Comprehensive accessibility guidelines based on WCAG 2.2 and Lighthouse accessibility audits. Goal: make content usable by everyone, including people with disabilities. Evidence led audit workflow When a rendered page is available: 1. Run a live Lighthouse Accessibility audit when that capability is available; with Chrome DevTools MCP, use lighthouse audit . Use mobile navigation mode for a general public page or snapshot mode when reloading would lose authenticated or user created state. 2. Use failed audit nodes to localize the relevant component or template instead of searching the whole repository for generic patterns. 3. Inspect a rendered accessibility tree snapshot for names, roles, states, landmarks, and heading structure; with Chrome DevTools MCP, use take snapshot . Exercise the affected flow with the keyboard. 4. Fix the source, then re run the same audit and manual interaction. If the live tools are unavailable, use Lighthouse CLI or axe for automated coverage and complete the same manual checks. Automated tools detect only a subset of accessibility barriers: a score of 100 is not WCAG conformance, and a low score does not replace issue level evidence. WCAG Principles: POUR Principle Description P erceivable Content can be perceived through different senses O perable Interface can be operated by all users U nderstandable Content and interface are understandable R obust Content works with assistive technologies Conformance levels Level Requirement Target A Minimum accessibility Must pass AA Standard compliance Should pass (legal requirement in many jurisdictions) AAA Enhanced accessibility Nice to have Perceivable Text alternatives (1.1) Images require alt text: Icon buttons need accessible names: Visually hidden class: Color contrast (1.4.3, 1.4.6) Text Size AA minimum AAA enhanced Normal text (< 18px / < 14px bold) 4.5:1 7:1 Large text (≥ 18px / ≥ 14px bold) 3:1 4.5:1 UI components & graphics 3:1 3:1 Don't rely on color alone: Media alternatives (1.2) Operable Keyboard accessible (2.1) All functionality must be keyboard accessible. Prefer native interactive elements — <button , <a href , and form controls handle Enter/Space activation, focus, and assistive tech semantics for free. Only add manual keyboard handling when you cannot use a native element. No keyboard traps. Users must be able to Tab into and out of every component. Use the [modal focus trap pattern](references/A11Y PATTERNS.md modal focus trap) for dialogs—the native <dialog element handles this automatically. Focus visible (2.4.7) Focus not obscured (2.4.11) — new in 2.2 When an element receives keyboard focus, it must not be entirely hidden by other author created content such as sticky headers, footers, or overlapping panels. At Level AAA (2.4.12), no part of the focused element may be hidden. Skip links (2.4.1) Provide a skip link so keyboard users can bypass repetitive navigation. See the [skip link pattern](references/A11Y PATTERNS.md skip link) for full markup and styles. Target size (2.5.8) — new in 2.2 Interactive targets must be at least 24 × 24 CSS pixels (AA). Exceptions: inline text links, elements where the browser controls the size, and targets where a 24px circle centered on the bounding box does not overlap another target. Dragging movements (2.5.7) — new in 2.2 Any action that requires dragging must have a single pointer alternative (e.g., buttons, inputs). See the [dragging movements pattern](references/A11Y PATTERNS.md dragging movements) for a sortable list example. Timing (2.2) Motion (2.3) Understandable Page language (3.1.1) Consistent navigation (3.2.3) Consistent help (3.2.6) — new in 2.2 If a help mechanism (contact info, chat widget, FAQ link, self help option) is repeated across multiple pages, it must appear in the same relative order each time. Users who rely on consistent placement shouldn't have to hunt for help on every page. Form labels (3.3.2) Every input needs a programmatically associated label. See the [form labels pattern](references/A11Y PATTERNS.md form labels) for explicit, implicit, and instructional examples. Error handling (3.3.1, 3.3.3) Announce errors to screen readers with role="alert" or aria live , set aria invalid="true" on invalid fields, and focus the first error on submit. See the [error handling pattern](references/A11Y PATTERNS.md error handling) for full markup and JS. Redundant entry (3.3.7) — new in 2.2 Don't force users to re enter information they already provided in the same session. Auto populate from earlier steps, or let users select from previously entered values. Exceptions: security re confirmation and content that has expired. Accessible authentication (3.3.8) — new in 2.2 Login flows must not rely on cognitive function tests (e.g., remembering a password, solving a puzzle) unless at least one of: A copy paste or autofill mechanism is available An alternative method exists (e.g., passkey, SSO, email link) The test uses object recognition or personal content (AA only; AAA removes this exception) Robust ARIA usage (4.1.2) Prefer native elements: When ARIA is needed, use the correct roles and states. See the [ARIA tabs pattern](references/A11Y PATTERNS.md aria tabs) for a complete tablist example. Live regions (4.1.3) Use aria live regions to announce dynamic content changes without moving focus. See the [live regions pattern](references/A11Y PATTERNS.md live regions and notifications) for markup and a showNotification() helper. Testing checklist Automated testing Prefer a live Lighthouse audit that returns failing rendered nodes directly to the agent. With Chrome DevTools MCP, this is lighthouse audit . Otherwise: Manual testing [ ] Keyboard navigation: Tab through entire page, use Enter/Space to activate [ ] Screen reader: Test with VoiceOver (Mac), NVDA (Windows), or TalkBack (Android) [ ] Zoom: Content usable at 200% zoom [ ] High contrast: Test with Windows High Contrast Mode [ ] Reduced motion: Test with prefers reduced motion: reduce [ ] Focus order: Logical and follows visual order [ ] Target size: Interactive elements meet 24×24px minimum See the [screen reader commands reference](references/A11Y PATTERNS.md screen reader commands) for VoiceOver and NVDA shortcuts. Common issues by impact Critical (fix immediately) 1. Missing form labels 2. Missing image alt text 3. Insufficient color contrast 4. Keyboard traps 5. No focus indicators Serious (fix before launch) 1. Missing page language 2. Missing heading structure 3. Non descriptive link text 4. Auto playing media 5. Missing skip links Moderate (fix soon) 1. Missing ARIA labels on icons 2. Inconsistent navigation 3. Missing error identification 4. Timing without controls 5. Missing landmark regions References [WCAG 2.2 Quick Reference](https://www.w3.org/WAI/WCAG22/quickref/) [WAI ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/) [Deque axe Rules](https://dequeuniversity.com/rules/axe/) [Web Quality Audit](../web quality audit/SKILL.md) [WCAG criteria reference](references/WCAG.md) [Accessibility code patterns](references/A11Y PATTERNS.md)