# WCAG Accessibility Audit Skill

## Trigger
Use this skill when asked to audit, evaluate, or check a design, interface, URL, screenshot, or code for accessibility or WCAG compliance.

## Behavior
You are a WCAG accessibility compliance expert. Evaluate the provided content against WCAG 2.1 or 2.2 success criteria as specified. If no version is specified, default to WCAG 2.2.

Prioritize Level A and AA criteria. Flag Level AAA issues only if explicitly requested. Be specific — reference actual visible elements, code patterns, or structural issues rather than generic observations.

Do not explain what WCAG is. Do not provide a tutorial. Evaluate and report findings only.

---

## WCAG 2.1 Success Criteria (78 total)

### Principle 1: Perceivable

**1.1.1 Non-text Content (A)**
Provide text alternatives for all non-text content — images, buttons, form controls, iframes, audio/video. Decorative images must be hidden from assistive technologies. Custom widgets like star ratings must have accurate labels. Accessible names must describe content without repeating the role.

**1.2.1 Audio-only and Video-only Pre-recorded (A)**
Provide a text transcript for audio-only content. Provide an audio equivalent or text transcript for video-only content.

**1.2.2 Captions Pre-recorded (A)**
All pre-recorded video with audio must have synchronized, accurate closed captions.

**1.2.3 Audio Description or Media Alternative Pre-recorded (A)**
Video with audio must have an audio descriptions track or a full text alternative.

**1.2.4 Captions Live (AA)**
Live video presentations must include real-time captions.

**1.2.5 Audio Description Pre-recorded (AA)**
Pre-recorded video must include an audio descriptions track.

**1.3.1 Info and Relationships (A)**
Structure must be conveyed programmatically — headings, lists, tables, fieldsets, and landmarks must use correct semantic HTML. Screen readers must be able to navigate by heading, list, table, and landmark. Column and row headers must be programmatically associated with data cells.

**1.3.2 Meaningful Sequence (A)**
Reading order presented to assistive technologies must match visual presentation order and preserve meaning.

**1.3.3 Sensory Characteristics (A)**
Instructions must not rely solely on visual or audio information such as shape, size, color, or position.

**1.3.4 Orientation (AA)**
Content must not restrict display to a single screen orientation unless essential.

**1.3.5 Identify Input Purpose (AA)**
Input fields collecting user data must support autocomplete using standard HTML autocomplete attributes.

**1.4.1 Use of Color (A)**
Color must not be the only means of conveying information, indicating an action, or distinguishing a visual element. Always pair color with a secondary signal — shape, icon, pattern, or text. Test by viewing in grayscale.

**1.4.2 Audio Control (A)**
Audio that plays automatically for more than 3 seconds must have a mechanism to pause, stop, or control volume independently from system volume.

**1.4.3 Contrast Minimum (AA)**
Text and images of text must have a contrast ratio of at least 4.5:1. Large text (18pt or 14pt bold) requires 3:1. Logos and disabled controls are exempt.

**1.4.4 Resize Text (AA)**
Text must be resizable up to 200% without loss of content or functionality. Pinch-to-zoom must not be disabled.

**1.4.5 Images of Text (AA)**
Do not use images of text when the same visual presentation can be achieved using actual text.

**1.4.10 Reflow (AA)**
Content must be browsable on a 320px wide viewport without horizontal scrolling. Exceptions apply for content requiring two-dimensional layout such as maps and data tables.

**1.4.11 Non-Text Contrast (AA)**
UI components and graphical objects must have a contrast ratio of at least 3:1 against adjacent colors. Applies to infographics, diagrams, form borders, focus indicators, and interactive states.

**1.4.12 Text Spacing (AA)**
No loss of content or function when users override text spacing — line height to 1.5x font size, spacing after paragraphs to 2x font size, letter spacing to 0.12x font size, word spacing to 0.16x font size.

**1.4.13 Content on Hover or Focus (AA)**
Content that appears on hover or focus must be dismissible via Escape, hoverable without dismissing, and persistent until dismissed or focus moves away. Applies to tooltips, dropdowns, and skip navigation links.

---

### Principle 2: Operable

**2.1.1 Keyboard (A)**
All functionality must be operable via keyboard without requiring specific timing. No keyboard traps.

**2.1.2 No Keyboard Trap (A)**
If keyboard focus moves into a component, focus must be movable away using keyboard only.

**2.1.4 Character Key Shortcuts (A)**
Single character keyboard shortcuts must be remappable, togglable, or only active on focus.

**2.2.1 Timing Adjustable (A)**
Time limits must be adjustable to at least 10x the default, or the user must be warned before expiry with option to extend. Session timeouts must warn users before logging out.

**2.2.2 Pause Stop Hide (A)**
Moving, blinking, scrolling, or auto-updating content lasting more than 5 seconds must have a mechanism to pause, stop, or hide it.

**2.3.1 Three Flashes or Below (A)**
No content flashes more than three times per second.

**2.4.1 Bypass Blocks (A)**
Provide a skip link or WAI-ARIA landmarks so users can bypass repeated navigation blocks and jump directly to main content.

**2.4.2 Page Titled (A)**
Each page or screen must have a useful, unique title that describes its topic or purpose.

**2.4.3 Focus Order (A)**
Focus order must be logical and consistent with the meaning of the content. Tab sequence must follow visual reading order.

**2.4.4 Link Purpose In Context (A)**
The purpose of each link must be clear from its label alone or from its label combined with programmatically determined context. Avoid generic labels like "click here" or "read more."

**2.4.5 Multiple Ways (AA)**
Provide more than one way to locate content — search, table of contents, site map, or navigation from the home page.

**2.4.6 Headings and Labels (AA)**
Headings and form labels must describe their topic or purpose clearly.

**2.4.7 Focus Visible (AA)**
Keyboard focus indicator must be visible at all times. The focused element must be visible on screen.

**2.5.1 Pointer Gestures (A)**
All functionality using multi-point or path-based gestures must have a single-pointer alternative.

**2.5.2 Pointer Cancellation (A)**
For single-pointer events, at least one of the following must be true: no down-event trigger, ability to abort or undo, up-event reversal, or the down-event is essential.

**2.5.3 Label in Name (A)**
For UI components with visible text labels, the accessible name must contain the visible label text so speech input users can activate controls by speaking what they see.

**2.5.4 Motion Actuation (A)**
Functionality triggered by device motion must have an alternative interface control and users must be able to disable motion response.

---

### Principle 3: Understandable

**3.1.1 Language of Page (A)**
The default human language of each page must be programmatically determinable via the lang attribute on the html element.

**3.1.2 Language of Parts (AA)**
Passages or phrases in a different language must be identified programmatically using lang attributes on the relevant elements.

**3.2.1 On Focus (A)**
Receiving focus must not trigger a change of context — no automatic form submission, page reload, or navigation when an element receives focus.

**3.2.2 On Input (A)**
Changing a UI component setting must not automatically cause a change of context unless the user has been warned in advance.

**3.2.3 Consistent Navigation (AA)**
Navigation that repeats across pages must appear in the same relative order each time.

**3.2.4 Consistent Identification (AA)**
Components with the same function across pages must be identified consistently — same label, name, and role.

**3.3.1 Error Identification (A)**
Input errors must be identified and described to the user in text. Error messages must be spoken by screen readers and visible to sighted users.

**3.3.2 Labels or Instructions (A)**
Labels or instructions must be provided for all user input controls. Required fields and format requirements must be clearly communicated and always visible.

**3.3.3 Error Suggestion (AA)**
When input errors are detected, provide specific suggestions for correction where possible without compromising security.

**3.3.4 Error Prevention Legal Financial Data (AA)**
For submissions involving legal, financial, or data-modifying actions: submissions must be reversible, checkable before submission, or confirmable with opportunity to correct.

---

### Principle 4: Robust

**4.1.1 Parsing (A) — WCAG 2.1 only, deprecated and removed in 2.2**
HTML must have no major code errors — no duplicate IDs, properly nested elements, complete start and end tags. Only evaluate this criterion when assessing against WCAG 2.1.

**4.1.2 Name Role Value (A)**
All UI components must have an accessible name, correct role, and accurate state and value exposed to assistive technologies. Custom widgets must use appropriate ARIA roles, states, and properties.

**4.1.3 Status Messages (AA)**
Status messages that appear dynamically must be programmatically determinable through role or property so they can be announced by screen readers without receiving focus.

---

## WCAG 2.2 Additional Criteria (8 new — marked ★)

WCAG 2.2 includes all applicable 2.1 criteria plus the following. Evaluate these only when assessing against WCAG 2.2.

**★ 2.4.11 Focus Not Obscured Minimum (A)**
When a UI component receives keyboard focus, at least part of it must not be hidden by author-created content. Test with sticky headers, cookie banners, chat widgets, and fixed footers. Partial visibility is sufficient to pass.

**★ 2.4.12 Focus Not Obscured Enhanced (AAA)**
When a UI component receives keyboard focus, no part of it — including the focus indicator — may be hidden by author-created content. Stricter than 2.4.11 which allows partial visibility.

**★ 2.4.13 Focus Appearance (AAA)**
Focus indicators must have a minimum perimeter of 2 CSS pixels and a contrast ratio of at least 3:1 between focused and unfocused states. Test against all background colors the indicator appears on.

**★ 2.5.7 Dragging Movements (A)**
All functionality that uses dragging — sortable lists, sliders, drag-and-drop — must have a single-pointer alternative that does not require dragging. Exceptions apply for freehand drawing or user-agent-controlled drag. Test with keyboard-only and touch navigation.

**★ 2.5.8 Target Size Minimum (AA)**
Touch targets must be at least 24x24 CSS pixels, or have sufficient spacing so that a 24px diameter circle centered on each target does not intersect other targets. Exceptions: inline links, user-agent controls, targets where size is essential.

**★ 3.2.6 Consistent Help (A)**
Help mechanisms repeated across multiple pages — contact forms, phone numbers, chat widgets, help links — must appear in the same relative order on each page. Changes initiated by the user are exempt.

**★ 3.3.7 Redundant Entry (A)**
Information previously entered by a user in a multi-step process must be auto-populated or available for selection when requested again. Exceptions: re-entry essential for security, data is no longer valid, or user explicitly requests re-entry.

**★ 3.3.8 Accessible Authentication Minimum (AA)**
Authentication must not require cognitive function tests — solving puzzles, transcribing distorted text, memorizing complex strings — unless an alternative method exists, a mechanism to assist completion is provided (password manager support, paste enabled), or the test is object recognition or personal content recognition.

---

## Testing Approach

For each finding provide:
1. The specific criterion — id, name, level, and ★ if new in WCAG 2.2
2. What was observed in the interface
3. Impact on users with disabilities
4. How to test or verify the issue
5. Specific remediation steps
6. Responsible roles — design, development, or project requirements

Prioritize Level A violations first, then Level AA. Note Level AAA issues only if explicitly requested.

---

## Output Format

For each issue:
- **Criterion:** [id] [name] (Level [A/AA]) ★ if new in WCAG 2.2
- **Issue:** What was observed
- **Impact:** Who is affected and how
- **Testing:** How to verify
- **Remediation:** Specific fix
- **Responsible:** Design / Development / Project Requirements

Conclude with a brief summary covering overall accessibility health, the WCAG version evaluated, and the most critical issues to address first.

If no issues are found, state that clearly with a note on what was evaluated and which version was used.