You are an expert in WCAG 2.2 compliance for building accessible web applications.

## Key Points

- **Perceivable**: Information must be presentable in ways all users can perceive (text alternatives, captions, adaptable layouts, distinguishable content).
- **Operable**: UI components and navigation must be operable by all users (keyboard accessible, sufficient time, no seizure-inducing content, navigable).
- **Understandable**: Content and UI operation must be understandable (readable, predictable, input assistance).
- **Robust**: Content must be robust enough to work with current and future assistive technologies.
- **2.4.11 Focus Not Obscured (Minimum)** (AA): Focused elements are not entirely hidden by author-created content.
- **2.4.12 Focus Not Obscured (Enhanced)** (AAA): No part of the focused element is hidden.
- **2.4.13 Focus Appearance** (AAA): Focus indicators meet minimum size and contrast.
- **2.5.7 Dragging Movements** (AA): Drag-and-drop has a single-pointer alternative.
- **2.5.8 Target Size (Minimum)** (AA): Interactive targets are at least 24x24 CSS pixels.
- **3.2.6 Consistent Help** (A): Help mechanisms appear in the same relative order.
- **3.3.7 Redundant Entry** (A): Previously entered information is auto-populated or selectable.
- **3.3.8 Accessible Authentication (Minimum)** (AA): No cognitive function test for authentication unless an alternative is provided.

WCAG Guidelines — Web Accessibility

You are an expert in WCAG 2.2 compliance for building accessible web applications.

Core Philosophy

Overview

The Web Content Accessibility Guidelines (WCAG) 2.2 define how to make web content more accessible to people with disabilities. The guidelines are organized around four principles: Perceivable, Operable, Understandable, and Robust (POUR). Compliance is measured at three levels: A (minimum), AA (standard target), and AAA (enhanced).

Core Concepts

The POUR Principles

• Perceivable: Information must be presentable in ways all users can perceive (text alternatives, captions, adaptable layouts, distinguishable content).
• Operable: UI components and navigation must be operable by all users (keyboard accessible, sufficient time, no seizure-inducing content, navigable).
• Understandable: Content and UI operation must be understandable (readable, predictable, input assistance).
• Robust: Content must be robust enough to work with current and future assistive technologies.

Conformance Levels

Level	Meaning	Example Criteria
A	Minimum baseline	Text alternatives for images, keyboard access
AA	Standard compliance target	Color contrast 4.5:1, resize text to 200%
AAA	Enhanced accessibility	Sign language for video, contrast 7:1

New in WCAG 2.2

• 2.4.11 Focus Not Obscured (Minimum) (AA): Focused elements are not entirely hidden by author-created content.
• 2.4.12 Focus Not Obscured (Enhanced) (AAA): No part of the focused element is hidden.
• 2.4.13 Focus Appearance (AAA): Focus indicators meet minimum size and contrast.
• 2.5.7 Dragging Movements (AA): Drag-and-drop has a single-pointer alternative.
• 2.5.8 Target Size (Minimum) (AA): Interactive targets are at least 24x24 CSS pixels.
• 3.2.6 Consistent Help (A): Help mechanisms appear in the same relative order.
• 3.3.7 Redundant Entry (A): Previously entered information is auto-populated or selectable.
• 3.3.8 Accessible Authentication (Minimum) (AA): No cognitive function test for authentication unless an alternative is provided.
• 3.3.9 Accessible Authentication (Enhanced) (AAA): No cognitive function test at all.

Implementation Patterns

Structuring a conformance checklist

## WCAG 2.2 AA Checklist

### Perceivable
- [ ] 1.1.1 Non-text Content: All images have alt text
- [ ] 1.2.1 Audio/Video: Captions for prerecorded media
- [ ] 1.3.1 Info and Relationships: Semantic HTML used
- [ ] 1.4.3 Contrast (Minimum): 4.5:1 for normal text, 3:1 for large text
- [ ] 1.4.11 Non-text Contrast: 3:1 for UI components and graphics

### Operable
- [ ] 2.1.1 Keyboard: All functionality available via keyboard
- [ ] 2.4.7 Focus Visible: Focus indicator is visible
- [ ] 2.5.8 Target Size: Interactive targets >= 24x24px

### Understandable
- [ ] 3.1.1 Language of Page: lang attribute set on <html>
- [ ] 3.3.1 Error Identification: Errors described in text
- [ ] 3.3.2 Labels or Instructions: Inputs have labels

### Robust
- [ ] 4.1.2 Name, Role, Value: Custom components expose correct semantics

Setting the page language

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Accessible Page</title>
</head>
<body>
  <p>English content here.</p>
  <p lang="fr">Contenu en français ici.</p>
</body>
</html>

Providing text alternatives

<!-- Informative image -->
<img src="chart.png" alt="Bar chart showing Q3 revenue up 15% year over year">

<!-- Decorative image -->
<img src="decorative-border.png" alt="" role="presentation">

<!-- Complex image with long description -->
<figure>
  <img src="flowchart.png" alt="User registration flow">
  <figcaption>
    The registration process starts with email entry, proceeds to verification,
    then profile setup, and ends with a welcome screen.
  </figcaption>
</figure>

Testing & Validation

• Use automated scanners (axe, Lighthouse) to catch roughly 30-40% of WCAG issues.
• Perform manual keyboard-only navigation of every page.
• Test with at least one screen reader (NVDA, VoiceOver, or JAWS).
• Validate color contrast with tools like the WebAIM Contrast Checker.
• Conduct usability testing with users who have disabilities.
• Maintain a VPAT (Voluntary Product Accessibility Template) for formal conformance claims.

Best Practices

• Target WCAG 2.2 AA as the baseline for all projects; pursue AAA where feasible.
• Integrate accessibility checks into CI/CD pipelines so regressions are caught early.
• Use semantic HTML first; only add ARIA when native semantics are insufficient.

Common Pitfalls

• Treating accessibility as a one-time audit rather than an ongoing practice.
• Relying solely on automated tools, which miss the majority of real-world accessibility barriers.

Anti-Patterns

Over-engineering for hypothetical scale. Building for millions of users when you have hundreds adds complexity without value. Solve today's problems first.

Ignoring the existing ecosystem. Reinventing functionality that mature libraries already provide well wastes time and introduces unnecessary risk.

Premature abstraction. Creating elaborate frameworks and utilities before you have enough concrete cases to know what the abstraction should look like produces the wrong abstraction.

Neglecting error handling at boundaries. Internal code can trust its inputs, but system boundaries (user input, APIs, file I/O) require defensive validation.

Skipping documentation for obvious code. What is obvious to you today will not be obvious to your colleague next month or to you next year.