WCAG 2.2 AA In Plain Language
A clear, human explanation of the latest accessibility standards.
This guide explains WCAG 2.2 AA in simple, direct language. No jargon. No legal words or overly complex explanations. I’m going to explain what the standard means, why it matters, and what your organization can do about it.
If you work in:
- Marketing / Content
- Product design
- Engineering
- Development
- QA
- Operations / Management
…this will help you understand how to make digital experiences more accessible and the guidelines behind WCAG 2.2 AA.
Why WCAG Matters
The Web Content Accessibility Guidelines (WCAG) are the global standard for digital accessibility. They define how to make websites and apps usable for as many people as possible, including people with disabilities. The web is for everyone, and WCAG provides the standards to support that.
When digital experiences fail accessibility standards, the result is frustration, exclusion, or barriers to accessing important information and services. It’s a drop in user reach and brand reputation.
What’s New In WCAG 2.2
WCAG 2.2 adds 9 new success criteria. Most of them focus on:
- Making interactions easier
- Reducing cognitive overload
- Ensuring users don’t get stuck
- Supporting users who navigate without a mouse
If your organization aims for WCAG 2.1 AA today, moving to 2.2 AA is mostly an incremental upgrade, not a total rewrite.
WCAG 2.2 AA — Explained Simply
Below are the new criteria in plain language, with quick examples.
| WCAG 2.2 Criteria | Plain Language Explanation | Why It Matters | Quick Example |
|---|---|---|---|
| Focus Not Obscured | Don’t hide the keyboard focus indicator behind sticky headers or popups. | Keyboard users need to see where they are. | When you tab, the selected link must remain visible. |
| Focus Appearance | The focus state must be visible, not subtle. | If you can’t see focus, you can’t navigate. | A blue border on a blue button is not visible. |
| Dragging Movements | Anything that requires drag must also be doable with a simple click. | Some users can’t drag due to motor limitations. | Carousels must have clickable arrows, not drag-only. |
| Target Size (Minimum) | Tappable areas must be big enough. | Small tap targets are unusable on mobile. | Buttons should be ~44px tall. |
| Hidden Controls | Controls needed to complete tasks must stay visible. | If controls disappear on hover only, many users miss them. | “Delete” icon shouldn’t only show on mouse hover. |
| Accessible Authentication | Logging in can’t require memorization of complex information. | Memory-based tasks can be exclusionary. | Offer copy/paste fields, show password, use email login links. |
| Consistent Help | If your site offers help (chat, help link, contact), place it consistently. | Predictability reduces cognitive load. | “Help” shouldn’t move between pages. |
| Redundant Entry | Don’t make users retype information they’ve already entered. | Repetition is an unnecessary burden. | Auto-fill or store previously entered form fields. |
Big picture:
WCAG 2.2 focuses on reducing friction and making interfaces predictable, visible, and forgiving.
How to Assess WCAG 2.2 Quickly (5-Min Manual Check)
Unplug your mouse.
Try to navigate your website using:
- Tab
- Shift + Tab
- Enter
- Space
Ask:
- Can you see focus?
- Can you complete the main actions?
- Do you ever get stuck?
This may be your first time trying to navigate the web without a mouse and for that reason it will be slower but in general, If the experience is confusing, if things are hidden, or slow → there are accessibility gaps.
This single test often reveals a large share of accessibility issues because many WCAG requirements relate to how users navigate and interact without a mouse. It’s not a complete audit of course, but it is an effective way to spot roughly 60% of accessibility issues in under 5 minutes.
A Few Common Mistakes to Avoid
| Mistake | Why It Breaks Accessibility | Simple Fix |
|---|---|---|
| Relying on “we’ll fix it in QA” | Accessibility must be designed upfront. | Include accessibility acceptance criteria in tickets and as early on as possible. |
| Using brand-colored focus states | They often blend in. | Use a highly visible focus ring (4px outline recommended). |
| Hover-only controls | Non-mouse users never see them. | Make controls permanently visible. |
| Forcing password complexity without reveal option | Memory tasks are exclusionary. | Always include “Show password”. |
Checklist: WCAG 2.2 AA Quick Wins
You can take action today on these:
- Ensure focus states are clear and visible
- Make all clickable areas large enough to tap comfortably
- Provide alternatives to drag-only interactions
- Don’t hide interactive controls behind hover-only states
- Keep help contact/options in the same place on every page
- Allow users to show password or paste into fields
- Don’t ask users to enter the same data twice
If you do these, you’re already moving toward compliance and better user experience — for everyone.
Ally works with organizations who care about getting this right and want to move forward with clarity and confidence.
Why This Matters
When we make digital experiences easier to use, we serve:
- People with motor disabilities
- People with visual disabilities
- New parents holding a baby one-handed
- People with temporary injuries
- Aging users
- People using phones in sunlight
- And everyone who just wants a smoother experience
Accessibility is universal usability.
If You Need Help
We support:
- Accessibility audits
- End-to-end WCAG 2.2 AA remediation
- Web accessibility certification
- Ongoing monitoring and support
Ally works with organizations who care about getting this right and want to move forward with clarity and confidence.
