A developer reference for WCAG 2.2.

Why this exists

Most accessibility content online falls into one of two buckets. Either it’s compliance-consultancy marketing — long on urgency, short on code — or it’s the W3C’s own specifications, which are authoritative but written for standards editors, not developers at 4pm on a Friday trying to ship an accessible dialog.

WCAG Patternssits between the two. Every page is grounded in the official criterion, links to the normative spec, and then does the thing the spec deliberately doesn’t: show you the production code, the ARIA wiring, the keyboard handling, and the common failure modes you’ll actually hit in a React, Vue, Angular, or Svelte codebase.

What you’ll find here

• WCAG 2.2 criteria— all 86 success criteria, each with a summary, a quick-checks list, and a long-form guide where the failure mode warrants one.
• A named author— so you know whose judgement you’re reading. See authors.
• Framework-specific patterns, fix-rule mappings, comparisons, and design-system guidance— these clusters are planned for later once the criterion spine stabilises.

What you won’t find here

• No “10 reasons accessibility matters” roundups.
• No compliance-theatre — no listicles padded with fluff.
• No affiliate-only pages. Affiliate links, where they appear, sit inside guides that would exist without them.

Standards applied

The site itself is held to the criteria it documents. AAA contrast across body text. Atkinson Hyperlegible (designed for low-vision readers) as the body font. GOV.UK-style focus rings. Keyboard reachable, screen-reader tested, reduced-motion respected. If you find an accessibility bug on this site, it’s a bug — file it.

Who writes it