WCAG Quick Audit

---
name: WCAG Quick Audit
description: Structured WCAG 2.2 AA triage pass on a pasted webpage or component, returning a prioritized fix list.
when_to_use: User pastes HTML/JSX/a screenshot and asks "is this accessible?" or "can you audit this before I ship?"
---

# WCAG Quick Audit

## What this skill does
Walks Claude through a fast, structured WCAG 2.2 AA review of a pasted page or component. It produces a prioritized fix list with specific success criteria, severities, and copy-paste-ready code fixes — not a formal audit, but enough triage to ship safer.

## When to load this skill
Load when the user pastes HTML, JSX, a component, a screenshot, or a URL description and says any of: "audit this", "is this accessible", "check this for a11y", "WCAG pass", "before I ship", or "PR review for accessibility". Also load when a developer is asking for a checklist they can run themselves.

## The procedure

### Step 1 — Clarify the scope in one sentence
Before auditing, state back what Claude is reviewing and what it is not. Example: "Auditing the pasted login form markup only. Not reviewing: the server round-trip, email content, password-reset flow, or surrounding page chrome." This keeps the scope honest and prevents the user from thinking Claude ran a full-site audit.

### Step 2 — Perceivable pass
Walk the four WCAG principles in order, starting with Perceivable. Check for: text alternatives on non-text content (1.1.1), captions on video (1.2), meaningful sequence when CSS is disabled (1.3.2), info conveyed by color alone (1.4.1), contrast of text and UI components (1.4.3 / 1.4.11), text resize behavior (1.4.4), and reflow at 320px (1.4.10). For each miss, record the success criterion number, the exact offending element, a plain-English explanation of who it hurts, and a specific fix.

### Step 3 — Operable pass
Next, Operable. Check: keyboard accessibility (2.1.1), no keyboard trap (2.1.2), focus visible (2.4.7), focus order (2.4.3), link purpose from text (2.4.4), target size minimum 24x24 CSS pixels (2.5.8 — new in 2.2), dragging alternatives (2.5.7 — new in 2.2), and consistent help (3.2.6 — new in 2.2). Flag interactive elements built on non-interactive tags (`div` onclick) immediately — they almost always fail multiple criteria at once.

### Step 4 — Understandable and Robust pass
Understandable: language of page (3.1.1), labels on inputs (3.3.2), error identification (3.3.1), consistent navigation (3.2.3), and the 2.2 redundant-entry rule (3.3.7). Robust: name/role/value for custom components (4.1.2), and status messages announced to assistive tech (4.1.3). If the code uses ARIA, verify every aria-* attribute points to a real ID and the role is valid. Broken ARIA is worse than no ARIA.

### Step 5 — Prioritize and write the fix list
Sort findings into three buckets: **Block ship** (WCAG A violations, keyboard traps, contrast failures on primary actions, form labels missing), **Fix this sprint** (AA violations that aren't blocking anyone today but will fail audit), and **Backlog** (AAA niceties, inconsistencies, polish). For each item, output: criterion number, element selector or line, severity, who it hurts (one short phrase), and the specific fix as code.

### Step 6 — State the limits honestly
Close with what this pass did not cover: dynamic states Claude couldn't see, screen-reader announcement quality (the rehearsal skill handles that), motion and animation behavior under user preference, and anything requiring live interaction. Hand off to [The Accessibility Auditor](/agents/soul-the-accessibility-auditor) if the user wants to talk through findings, or to [A11y Axe Scanner MCP](/agents/mcp-a11y-axe-scanner) for automated regression coverage.

## A worked example

**User:** Quick audit on this? Shipping tomorrow.
```html
<div class="btn" onclick="submit()">Submit</div>
<input type="text" placeholder="Email">
<img src="logo.png">
<a href="/more">click here</a>
```

**Claude:** Auditing four elements in the pasted snippet. Not reviewing: surrounding page, CSS, or server behavior.

**Perceivable**
- 1.1.1 — `<img src="logo.png">` has no alt text. Screen readers will read the filename. Fix: `<img src="logo.png" alt="Acme logo">` or `alt=""` if decorative.
- 1.4.3 — Can't verify contrast without seeing the `.btn` styles. Flag for manual check.

**Operable**
- 2.1.1, 4.1.2 — `<div onclick>` is not keyboard-reachable and has no role. Screen readers announce it as "Submit" (plain text), not as a button. Fix: use `<button type="submit">Submit</button>`.
- 2.4.4 — `<a>click here</a>` has no purpose from link text alone. Fix: `<a href="/more">Read the full pricing breakdown</a>`.

**Understandable**
- 3.3.2 — `<input type="text" placeholder="Email">` has no label. Placeholder is not a label. Fix: `<label for="email">Email</label><input id="email" type="email" autocomplete="email">`.

**Block ship:** the div-button, the missing input label, the missing alt. All three are A-level and trivial to fix.
**Fix this sprint:** the link text.
**Backlog:** none from this snippet.

Out of scope for this pass: focus styles, error states, screen-reader rehearsal, motion preferences. Want me to rehearse the screen-reader announcement next?

**User:** Yes please.

**Claude:** Loading the screen reader rehearsal skill...

## What this skill will NOT do
- Will NOT declare a page "WCAG compliant" or sign off on legal compliance. Compliance requires a human auditor and a VPAT. This skill produces triage, not certification.
- Will NOT invent findings it can't verify from the pasted code. If contrast can't be measured because styles aren't included, it says so and asks for them.
- Will NOT skip the severity ranking. Every finding gets a bucket, or it doesn't go in the list.
- Will NOT replace testing with real assistive technology and real disabled users. It says so at the end, every time.
- Will NOT audit code the user didn't paste. Scope is whatever's on screen, nothing more.