---
name: accessibility-audit-wcag
description: "Checks a page or component against WCAG 2.1 AA and returns a ranked list of failures, each with the rule, the evidence and a concrete fix. Use when a page, component or design needs a WCAG 2.1 AA check covering contrast, keyboard use, focus, labels and screen reader behaviour. Do not use for fixing a single known bug or running an automated scanner. Related topics: design, coding."
---

# Accessibility Audit (WCAG)

Checks a page or component against WCAG 2.1 AA and returns a ranked list of failures, each with the rule, the evidence and a concrete fix.

## When to use

Use this skill when a page, component or design needs a WCAG 2.1 AA check covering contrast, keyboard use, focus, labels and screen reader behaviour. Do not use it for fixing a single known bug or running an automated scanner.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Compute the contrast ratio for every supplied colour pair and list each one that misses its threshold.
3. Trace the keyboard path through the interface and record unreachable controls, wrong order, hidden focus and traps.
4. Check labels, alt text, link text, headings and landmarks, naming the element each finding applies to.
5. Read the markup as a screen reader would and note state changes, errors or updates that go unannounced.
6. Rank findings by severity with criterion number, evidence and a concrete fix, and list what could not be verified.

## Inputs

- **What is being audited** (free text, e.g. "Page or component name")
- **Markup or description** (longer free text)
- **Design colours** (longer free text)
- **Platform** (choose one: Website, Web app, Mobile web, Design mockup)
- **Assistive tech in scope** (choose any: Screen reader, Keyboard only, Voice control, Zoom, Reduced motion)
- **Audience notes** (longer free text)

## Output

A findings table sorted by severity with columns for criterion, element, evidence and fix, then a short list of unverified areas and a summary of pass or fail per area.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Accessibility Audit (WCAG)

Audit this interface for WCAG 2.1 AA.

- What is being audited: {{What is being audited}}
- Markup or description: {{Markup or description}}
- Design colours: {{Design colours}}
- Platform: {{Platform}}
- Assistive tech in scope: {{Assistive tech in scope}}
- Audience notes: {{Audience notes}}

Work through four areas in order. Contrast: compute the ratio for each pair given and flag text under 4.5 to 1 (3 to 1 for large text and UI borders). Keyboard and focus: check that every control is reachable, the order follows the visual order, focus is visible, and nothing traps focus. Labels and structure: look for inputs without labels, images without useful alt text, vague link text, skipped heading levels and missing landmarks. Screen reader: read the markup as an announcement and note where state, errors or live updates would be silent. For each failure give the WCAG criterion number, the evidence, severity (blocker, serious or minor) and a specific fix, ideally with corrected code. Say plainly what you could not check from the supplied material, such as real device behaviour.

## Pitfalls

- Claiming a pass on screen reader behaviour from markup alone, when real announcements depend on browser and reader combinations.
- Counting only missing alt attributes and skipping poor alt text, which technically passes while still failing users.
- Suggesting ARIA roles where native elements would do, which adds failure modes instead of removing them.