Skip to main content
Back to Blog

WCAG 2.2 Is Here: What Actually Changed and Why It Matters

WCAG 2.2 Is Here: What Actually Changed and Why It Matters
Bria Stone

By Bria Stone

Share

WCAG 2.2 became the recommended standard in October 2023. If you've been putting off reviewing the changes, now's the time.

The good news: most of 2.1 carries over. If your product was already compliant, you're not starting from scratch. The new success criteria target specific pain points that weren't adequately covered before.

Let's break down what's new and what you need to do about it.

Focus appearance gets stricter

The new Focus Appearance criterion raises the bar for visible focus indicators. They need to be more prominent than before, with specific size and contrast requirements.

Your focus indicators must be at least 2 CSS pixels thick or have an area at least as large as a 2 pixel thick perimeter. They need 3:1 contrast against both the focused component and the background.

This directly addresses a common issue: focus indicators that are technically present but practically invisible. If users can't see where focus is, keyboard navigation becomes guesswork.

Help for people with cognitive disabilities

Several new criteria specifically target cognitive accessibility. These are areas where previous versions of WCAG were notably weak.

Consistent Help means if you offer help mechanisms like contact info or chatbots, they appear in the same relative location across pages. Users shouldn't hunt for support options on every page.

Redundant Entry prevents forcing users to enter the same information multiple times in a single session. If they've already given you their email address, don't make them type it again three pages later.

These seem obvious, yet they address real frustrations users face daily. Implementing them improves the experience for everyone, not just people with disabilities.

Authentication without cognitive tests

The Accessible Authentication criterion tackles a major accessibility barrier: cognitive function tests required to log in.

At Level AA, you can't require users to solve puzzles, remember passwords, or transcribe text from images unless you provide an alternative. Password managers count as an alternative. So do biometric authentication and magic links.

This has major implications for how you implement login flows. Pure memorisation requirements are out. You need cognitive function test free alternatives.

Dragging movements need alternatives

Any functionality that relies on dragging must have a single pointer alternative. This covers drag and drop interfaces, sliders, sortable lists, anything requiring a dragging motion.

The fix usually means adding buttons or other controls that achieve the same result. A sortable list gets up and down buttons. A slider gets increment and decrement controls. A drag and drop file upload gets a traditional file picker.

This benefits people with motor disabilities who struggle with precise dragging motions, but also users on devices where dragging is awkward or unreliable.

Target size gets more specific

Touch targets need to be at least 24 by 24 CSS pixels, with some exceptions for inline links and controls where increasing the size would fundamentally change the functionality.

This is smaller than the 44 by 44 pixel requirement at Level AAA, but it's now required at Level AA. The practical impact: most of your interactive elements need to be bigger.

Check your icon buttons, close buttons on modals, and any compact UI controls. They probably need more padding or larger hit areas.

What this means for your roadmap

Don't panic. WCAG 2.1 isn't deprecated. You have time to plan your transition. But legal requirements will eventually catch up, and early adopters gain competitive advantage.

Start with an audit against the new criteria. Identify gaps. Prioritise fixes based on user impact and implementation effort. Work them into your regular sprint planning rather than treating them as a separate project.

The changes in WCAG 2.2 aren't arbitrary. They address real user needs that weren't adequately covered before. Meeting them makes your product genuinely better, not just more compliant.

Recommended Reading

You might also like

Cover image for Design Systems: Your Secret Weapon for Accessibility at Scale

Design Systems: Your Secret Weapon for Accessibility at Scale

Bria Stone

By Bria Stone

Accessibility feels overwhelming when every component, every page, every feature needs individual attention. There's a better way.Design systems let you bake accessibility into reusable components once, then use them everywhere. Fix an issue in the button component, and every button across your product gets better. Update focus styles in your system, and they propagate to hundreds of interfaces.This is how organisations scale accessibility without scaling effort. Let's look at how to build it right.Start with accessible foundationsYour design system is only as accessible as its base components. Get the fundamentals right from the beginning, or you'll be fixing the same issues across dozens of implementations.Build your colour palette with contrast in mind. Every text and background combination should meet WCAG standards. Document which combinations work together and why. Make it impossible to accidentally create low contrast pairings.Define focus states once. Make them prominent, consistent, and work across all components. Your developers shouldn't need to think about focus indicators. They should just work.Component-level accessibilityEach component should handle its own accessibility requirements. A button component manages keyboard interaction and ARIA attributes. A modal component implements focus trapping. A form component handles error announcements.Document the accessibility features built into each component. Developers using your system need to know what's handled automatically and what requires their attention. Make it clear, make it visible, make it hard to miss.When you discover an accessibility issue in a component, you fix it once and the fix propagates everywhere that component is used. This is the real power of design systems.Testing at the system levelEvery component in your design system should have accessibility tests. Automated tests catch regressions. Manual tests verify the experience actually works for users.Test keyboard navigation. Test screen reader behaviour. Test with different zoom levels. Test in high contrast mode. Build these tests into your component development workflow, not as an afterthought.Document test results alongside components. When developers pick a component from your system, they should know exactly how it behaves for all users, including those using assistive technologies.Governance and evolutionDesign systems aren't static. They evolve as your product grows and accessibility standards improve. Someone needs to own that evolution.Establish clear governance around accessibility updates. When WCAG releases new guidelines, who evaluates their impact on your system? When a component accessibility issue is discovered, who prioritises the fix?Make accessibility a required checklist item for any new component or significant update. Don't let inaccessible patterns enter your system in the first place.Documentation that actually helpsYour design system documentation should include specific accessibility guidance. Not generic statements about following WCAG, but concrete examples of how to use components accessibly.Show good and bad examples. Explain why certain patterns work and others don't. Include code snippets demonstrating proper implementation. Make it easier to do the right thing than to get it wrong.Document keyboard shortcuts, ARIA usage, and expected screen reader behaviour for complex components. Your developers shouldn't need to reverse engineer how accessibility works.The compound effectDesign systems create a compound effect for accessibility. Every improvement you make gets multiplied across every implementation. The effort you invest upfront pays dividends across your entire product portfolio.Compare this to the alternative: every team implementing their own components, making their own accessibility decisions, fixing their own issues. The duplication is massive. The inconsistency is confusing. The maintenance burden never ends.A well built design system doesn't just make accessibility easier. It makes it sustainable. That's how you build inclusive products at scale without burning out your team.

Read more
Cover image for Keyboard Navigation: The Complete Guide for Developers

Keyboard Navigation: The Complete Guide for Developers

Bria Stone

By Bria Stone

If you can't use your product with a keyboard alone, it's not accessible. Full stop.Keyboard navigation affects more users than you might think. People with motor disabilities, repetitive strain injuries, or those who simply prefer keyboard shortcuts. It's not a niche concern.Yet we consistently see products where critical features are completely unreachable via keyboard. Custom dropdowns that trap focus. Modal dialogs you can't escape from. Buttons that require a mouse click.Let's fix that. Here's everything you need to know about implementing proper keyboard navigation.The tab order mattersUsers navigate through your interface using the Tab key. The order they encounter elements should follow a logical, predictable path. Typically, that means left to right, top to bottom, matching the visual layout.Don't mess with the natural tab order using tabindex values greater than 0. It creates confusion and makes your site harder to navigate. If your tab order feels wrong, the solution is usually to restructure your HTML, not force a different order.Only interactive elements should be in the tab order. That means links, buttons, form inputs, and custom interactive widgets. Regular text and decorative images should be skipped.Focus management in single page appsTraditional websites handle focus automatically when you navigate to a new page. Single page applications don't work that way. Route changes happen without a page refresh, and focus often stays wherever it was.When your app navigates to a new view, move focus to a logical starting point. Usually that's the main heading of the new page. This tells keyboard and screen reader users that the content has changed and where they are now.Skip links deserve a mention here too. They let users jump past repetitive navigation directly to main content. Essential for keyboard users who don't want to tab through your entire header on every page.Building accessible custom widgetsStandard HTML controls work with keyboards out of the box. Native buttons, links, and form inputs all behave correctly without extra work. Problems start when you build custom components.If you're creating a custom dropdown, modal, or any interactive widget, you need to handle keyboard interaction yourself. That means implementing proper ARIA roles, managing focus, and responding to the right keyboard events.Arrow keys should navigate within components like menus and tabs. Escape should close dialogs and cancel operations. Space and Enter should activate buttons. These patterns are established conventions. Follow them.Focus traps and modal dialogsWhen a modal opens, focus should move to it and stay there until it's closed. Users shouldn't be able to tab out and interact with the page behind it. That's what we call a focus trap, and in this case, it's exactly what you want.Implement this by moving focus to the first focusable element in the modal when it opens. When users press Tab at the last focusable element, cycle back to the first. When they press Escape or close the modal, return focus to whatever triggered it.Get this wrong and users can find themselves lost, tabbing through invisible elements or unable to interact with your modal at all.Testing your keyboard navigationAutomated tests catch some keyboard issues, but you need to test manually. Unplug your mouse. Navigate through your entire application using only the keyboard.Can you reach every interactive element? Can you see where focus is at all times? Does the tab order make sense? Can you complete core tasks without touching your mouse?If you get stuck, frustrated, or confused during this test, your users will too. Take notes on pain points and fix them.Making it part of your processKeyboard accessibility isn't something to add at the end. Build it in from the start. Use semantic HTML. Test as you develop. Make keyboard navigation a requirement in code reviews.The patterns we've covered form the foundation. Master these basics and you're well on your way to building truly accessible interfaces. Your keyboard users will notice the difference immediately.

Read more
Get In Touch

Need accessibility support?

Get in touch for fast, friendly and personalised accessibility guidance today.