Audit Accessibility

---
name: audit-accessibility
description: Use when auditing a product or component for accessibility compliance or when preparing for WCAG 2.1 AA certification
source: W3C WCAG 2.1 (2018); WAI-ARIA Authoring Practices 1.2; Deque axe-core open-source ruleset
tags: [accessibility, wcag, a11y, screen-reader, aria, inclusive-design, audit]
verified: true
---

# Audit Accessibility

Systematically test a product against WCAG 2.1 AA to find and prioritize accessibility barriers before they reach users with disabilities.

## Why This Is Best Practice

**Adopted by:** UK Government Digital Service (mandatory WCAG 2.1 AA), US Section 508, EU EN 301 549, and all major tech companies under legal obligation or voluntary commitment
**Impact:** WebAIM Million report (2024) found 95.9% of top 1M homepages had detectable WCAG failures; automated tools catch ~30–40% of issues — manual and assistive technology testing is required for full coverage

**Why best:** Accessibility is a legal requirement in most jurisdictions and expands the addressable market by ~1.3 billion people globally with disabilities. Retrofitting accessibility after launch costs 3–5× more than building it in.

## Steps

1. **Run automated scanning** — Use axe-core (browser extension or CI integration) on every page/view. Deque Axe DevTools or Lighthouse accessibility audit catch structural violations: missing alt text, insufficient color contrast, unlabeled form fields, missing landmark roles.
2. **Audit color contrast** — Check all text against WCAG 2.1 AA: normal text ≥ 4.5:1 ratio, large text (≥18pt or 14pt bold) ≥ 3:1. Use the Colour Contrast Analyser or browser DevTools.
3. **Test keyboard navigation** — Tab through the entire interface using only a keyboard. Verify: visible focus indicator on all interactive elements, logical tab order, no keyboard traps, all interactive elements reachable.
4. **Test with a screen reader** — Use NVDA+Chrome (Windows) or VoiceOver+Safari (macOS/iOS). Test: page title announced correctly, headings navigable in sequence, form labels associated, dynamic content announced (live regions), modal focus management.
5. **Audit heading structure** — Every page should have one `<h1>`. Headings must not skip levels (h1→h3 with no h2 is a violation). Use the browser's accessibility tree or a heading visualizer extension.
6. **Check images and media** — All informative images need descriptive `alt` text. Decorative images need `alt=""`. Videos need captions; audio needs transcripts.
7. **Audit interactive components** — For each custom widget (modal, dropdown, date picker, slider): verify ARIA roles, states, and properties match WAI-ARIA Authoring Practices patterns. Keyboard interactions must match the expected pattern.
8. **Document findings in a severity matrix** — Rate each issue: Critical (blocks access), Serious (significantly limits access), Moderate (inconvenient), Minor (cosmetic). Fix critical and serious before launch.

## Rules

- Automated tools alone are never sufficient — manual screen reader testing is mandatory for any shipped product.
- Color must not be the only means of conveying information (e.g., red = error must also have a text label or icon).
- All interactive elements must have a programmatically determinable name — not just a visible label.
- Focus must never be trapped except in modals, and modals must return focus to the trigger element when closed.
- Audit with real assistive technology users at least once per major release cycle.

## Examples

A modal audit reveals the close button has `aria-label="close"` but pressing Escape does not close the modal and focus does not return to the trigger. Fix: add `keydown` Escape handler and restore focus on close. This matches the WAI-ARIA Dialog pattern exactly.

## Common Mistakes

- **Audit = run Lighthouse** — Lighthouse catches ~30% of WCAG violations; teams that stop there ship inaccessible products confidently.
- **ARIA without semantics** — Adding `role="button"` to a `<div>` without also adding `tabindex="0"` and keyboard handlers creates the appearance of accessibility without the reality.
- **Fixing automation findings only** — Critical barriers like incorrect screen reader announcements for dynamic content are invisible to automated tools.

## When NOT to Use

- Do not substitute a WCAG 2.1 AA audit for a higher standard when the product serves users with cognitive disabilities or when the organization has committed to WCAG 2.2 or AAA — a passing AA audit does not guarantee the product is usable by all disability groups.
- Do not run an accessibility audit as a one-time pre-launch gate rather than a recurring practice — new components, content updates, and third-party script changes introduce violations continuously, so a single audit provides only a point-in-time snapshot.
- Do not treat an audit as complete if no real assistive technology users were involved in testing — automated tools and developer screen reader checks consistently miss interaction patterns that diverge from how actual users navigate with specialized hardware or custom AT configurations.