// guide
Getting Started with WCAG 2.2: What Developers Need to Know
A practical overview of the Web Content Accessibility Guidelines for developers who want to understand the standard, not just check boxes. Covers what changed, what the principles mean, and what each new criterion asks you to do.
// 01 · what is wcag?
What Is WCAG?
WCAG stands for Web Content Accessibility Guidelines. It's the international standard for making web content accessible to people with disabilities — including visual, auditory, motor, and cognitive disabilities.
WCAG is published by the W3C (World Wide Web Consortium) and is the basis for accessibility laws in many countries, including the ADA in the United States, the European Accessibility Act in the EU, and the Accessibility for Ontarians with Disabilities Act in Canada.
Version 2.2 was published in October 2023. It builds on WCAG 2.1 (2018) and WCAG 2.0 (2008), adding 9 new success criteria while removing one. If your site meets WCAG 2.2 AA, it also meets 2.1 AA and 2.0 AA.
// 02 · what changed from 2.1 to 2.2
What Changed from 2.1 to 2.2
WCAG 2.2 adds 9 new success criteria and removes one:
- Added: Focus Not Obscured (Minimum), Focus Not Obscured (Enhanced), Focus Appearance, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry, Accessible Authentication (Minimum), Accessible Authentication (Enhanced)
- Removed: 4.1.1 Parsing — this criterion required valid HTML markup, but modern browsers and assistive technologies are now resilient enough to handle parsing errors. It was removed because it no longer serves its original purpose.
The removal of 4.1.1 Parsing doesn't mean valid HTML no longer matters. Well-formed markup still helps assistive technology, and many of the issues 4.1.1 caught (duplicate IDs, broken ARIA references) are covered by other criteria like 4.1.2 Name, Role, Value. See our Switch, Combobox, and Dropdown Menu patterns for examples of proper name, role, and value implementation.
// 03 · the four principles (pour)
The Four Principles (POUR)
Every WCAG success criterion falls under one of four principles, known by the acronym POUR. If your content fails any one of these principles for any user, it is not accessible.
Perceivable
Users must be able to perceive the content. Information can't be invisible to all of a user's senses. This covers text alternatives for images, captions for video, sufficient color contrast, and content that adapts to different presentations. For example, Tooltips must remain visible on hover and focus (1.4.13), and Data Tables need proper structure so relationships are programmatically determinable (1.3.1).
Operable
Users must be able to operate the interface. All functionality must work from a keyboard, users need enough time to interact, and navigation must be logical. This is where focus management, target sizes, and keyboard support live. Our Dropdown Menu and Responsive Navigation patterns demonstrate full keyboard operability.
Understandable
Users must be able to understand both the content and how to use the interface. Language should be readable, behavior should be predictable, and input assistance should help users avoid and correct mistakes.
Robust
Content must work reliably across a wide range of user agents, including assistive technologies. This means using valid markup, ensuring programmatic names and roles, and providing status messages that screen readers can announce. See the Toast / Notifications pattern for proper status message implementation (4.1.3), and the Switch pattern for correct ARIA roles and states (4.1.2).
// 04 · the three conformance levels
The Three Conformance Levels
Each WCAG success criterion is assigned one of three levels. The levels are cumulative — AA includes everything in A, and AAA includes everything in A and AA.
| Level | What It Means | Who Targets It |
|---|---|---|
| Level A | The bare minimum. Without these, some users are completely blocked from accessing content. Covers fundamentals like keyboard access, text alternatives, and basic form labels. | Everyone — these are non-negotiable |
| Level AA | The standard target. Removes significant barriers for users with disabilities. Covers color contrast, focus indicators, error suggestions, consistent navigation, and more. | Most organizations, legal requirements, and industry standards |
| Level AAA | The highest level. Addresses edge cases and enhanced experiences. Covers sign language for video, extended audio descriptions, and enhanced contrast ratios. | Specialized sites serving disability communities; not realistic as a blanket requirement |
// 05 · the 9 new success criteria in wcag 2.2
The 9 New Success Criteria in WCAG 2.2
Here's what each new criterion requires, explained in plain language with links to A11yPath patterns that demonstrate them.
Focus and Navigation
2.4.11 Focus Not Obscured (Minimum) Level AA
When a UI element receives keyboard focus, it must not be entirely hidden by other content. At least part of the focused element must be visible. This commonly fails when sticky headers, footers, or overlays cover focused elements as the user tabs through the page.
What to do: Make sure sticky or fixed-position elements don't completely overlap focused items. Use scroll-padding-top to offset scrolled-into-view elements below sticky headers.
2.4.12 Focus Not Obscured (Enhanced) Level AAA
The enhanced version of 2.4.11. When an element receives keyboard focus, no part of it may be hidden by other content. The entire focused element must be fully visible — not just a sliver of it.
What to do: Same techniques as 2.4.11, but stricter. Test with sticky headers, cookie banners, chat widgets, and any other fixed-position content on your page.
2.4.13 Focus Appearance Level AAA
When a UI element has keyboard focus, the focus indicator must meet specific size and contrast requirements. The indicator must have an area of at least the perimeter of the element times 2 CSS pixels, and must have at least 3:1 contrast between focused and unfocused states.
What to do: Use a solid outline (not just a color change or subtle underline). A 2px solid outline around the element satisfies the size requirement. Ensure the outline color has 3:1 contrast against the background.
Demonstrated in:
- Modal Dialog — focus indicators on dialog buttons and close trigger
- Tabs — focus indicators on tab triggers and panels
- Accessible Forms — focus indicators on all form controls
Pointer and Touch
2.5.7 Dragging Movements Level AA
If a function uses dragging (drag-and-drop, sliders, sortable lists), there must be an alternative that works with a single pointer click without dragging. Users with motor disabilities, tremors, or who use alternative input devices may not be able to perform drag gestures.
What to do: For sortable lists, add "move up" / "move down" buttons. For sliders, allow clicking on the track or typing a value. For drag-and-drop, provide a select-then-click alternative. The drag method can still exist — just provide an alternative.
2.5.8 Target Size (Minimum) Level AA
Interactive targets (buttons, links, form controls) must be at least 24x24 CSS pixels, unless the target is inline in text, the user agent controls its size, the size is essential to the function, or there's sufficient spacing around smaller targets.
What to do: Set min-height and min-width (or adequate padding) on clickable elements. For inline links within paragraphs, this criterion doesn't apply — only for standalone interactive targets.
Demonstrated in:
- Accordion — summary elements span full width with
min-height: 2.75rem - Tabs — tab triggers use
min-height: 2.75rem - Accessible Forms — form controls meet minimum target size
Predictability and Assistance
3.2.6 Consistent Help Level A
If your site provides help mechanisms (contact info, a help page, a chatbot), they must appear in the same relative order across pages. Users who need help shouldn't have to hunt for it on every page.
What to do: Put help links, contact information, or chat widgets in the same location in your layout (typically the header or footer) and keep them consistent across all pages. The help doesn't have to exist — but if it does, it must be in a predictable place.
3.3.7 Redundant Entry Level A
If the user has already entered information in a process (like a multi-step form), don't make them enter it again in a later step. Either auto-populate it or let the user select from previously entered values. Exceptions exist for security (re-entering a password) and when the information has expired.
What to do: In multi-step forms, carry forward data from earlier steps. If you ask for a shipping address, pre-fill it as the billing address with an option to change. Store form progress so users don't lose work.
Authentication
3.3.8 Accessible Authentication (Minimum) Level AA
If a login step requires a cognitive function test (recognizing objects, solving puzzles, remembering passwords), an alternative must be available that doesn't rely on that cognitive function. Users with cognitive disabilities, memory impairments, or learning disabilities may not be able to perform these tasks.
What to do: Support password managers (don't block paste in password fields). Offer authentication alternatives like email magic links, passkeys, or OAuth. If you must use a CAPTCHA, provide an audio or logic-based alternative alongside the visual puzzle.
3.3.9 Accessible Authentication (Enhanced) Level AAA
The stricter version of 3.3.8. No cognitive function test is allowed at all in the authentication process — not even object recognition. The only permitted tests are ones where the user can rely on a mechanism (like a password manager or copy-paste) to complete them without memorization.
What to do: Same approach as 3.3.8, but stricter. Avoid image-based CAPTCHAs entirely, even with alternatives. Prefer passkeys, magic links, or OAuth flows that don't require cognitive effort beyond clicking a button.
// 06 · where to start
Where to Start
If you're new to WCAG, don't try to address all criteria at once. Start with the changes that have the highest impact for the least effort:
- Add skip links — a single HTML element that dramatically improves keyboard navigation. Takes minutes to implement. See the Skip Links pattern. Also consider adding a breadcrumb to help users orient themselves within your site.
- Check your focus indicators — make sure every interactive element has a visible focus ring with 3:1 contrast. Most browsers provide decent defaults, but custom styles often remove them.
- Audit your target sizes — buttons and links should be at least 24x24px. This is a CSS-only fix in most cases.
- Fix your forms — associate every
<label>with its input, use<fieldset>/<legend>for groups, and make errors accessible. See the Forms pattern. - Don't block paste on password fields — this is both the easiest authentication fix and the most common violation of 3.3.8.
From there, work through your interactive components. If you're building modals, tabs, accordions, dropdown menus, comboboxes, or toggle switches, use native HTML where possible and follow the patterns on this site. Don't forget structural components too — breadcrumbs, responsive navigation, and data tables all have specific accessibility requirements. Each pattern maps to the specific WCAG criteria it addresses.