WCAG 2.2 Explained for UI/UX Designers

If you have ever opened an accessibility checklist and thought, “Where do I even start?”, you are not alone. Accessibility can sound technical until you connect it to the small decisions we make every day: how a button looks when it has focus, how large a tap target is, what happens when a form has an error, or whether someone can complete a task without using a mouse.

That is where WCAG 2.2 becomes useful. Instead of treating accessibility as a separate discipline that belongs to QA or development, designers can use it as a practical framework for making products easier to perceive, navigate, understand and use.

This guide is written for designers who want the practical version—not a wall of standards language. You do not need to memorize every success criterion. You need to understand the design decisions behind them and know when they matter.

So, what exactly is WCAG 2.2?

WCAG stands for Web Content Accessibility Guidelines. It is a W3C accessibility standard that helps teams make digital content and interfaces more accessible to people with disabilities.

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It adds nine new success criteria to WCAG 2.1, while keeping the overall WCAG 2.x approach and backward compatibility.

For a UI/UX designer, the most useful mental model is POUR:

• Perceivable — Can people perceive the information?
• Operable — Can people interact with it using the input methods available to them?
• Understandable — Can people understand what is happening and what to do next?
• Robust — Does the experience work reliably with browsers and assistive technologies?

WCAG also has three conformance levels: A, AA and AAA. Conformance is based on the success criteria, not on whether a particular technique was used.

Why should a designer care?

Because many accessibility problems are born long before a developer writes the final line of code.

A designer decides whether an icon has enough context. Whether an error is communicated only with red. Whether a sticky footer covers content. Whether a drag interaction has an alternative. Whether a disabled state is distinguishable. Whether a form asks for the same information twice.

These choices may look small on a Figma canvas. For someone using a keyboard, screen reader, voice input, magnification or a touch device, they can determine whether the product feels effortless—or impossible.

POUR, but in everyday design language

1. Perceivable: make the information available

If a user cannot perceive something, the interface has already lost them.

Think about text alternatives for meaningful images, captions for video, readable contrast, scalable layouts and information that does not depend on color alone.

Designer example: A finance dashboard uses a red dot for “payment failed” and a green dot for “payment completed.” It looks simple, but color is doing all the communication. Add a label, icon or other clear cue so the meaning survives without the color difference.

2. Operable: make interaction possible

A beautiful interface is not accessible if a person cannot operate it.

Keyboard navigation, visible focus, reasonable target sizes and alternatives to pointer-only interactions are all part of this thinking.

Designer example: A product table has a tiny three-dot menu at the far right of every row. Keep the visual icon compact if you like, but give the control a comfortable interactive area.

3. Understandable: reduce unnecessary thinking

Good UX already aims to make things clear and predictable. Accessibility makes that goal even more important.

Use meaningful labels. Keep navigation patterns consistent. Explain errors in plain language. Tell users what happened and what they can do next.

Design rule: design the recovery path, not only the happy path.

4. Robust: design for the real world

Your Figma file may look perfect, but the real product has browsers, operating systems, screen readers, zoom settings, keyboard users and different assistive technologies.

Designers do not need to control all of that. We do need to work with developers to preserve meaningful structure, accessible names, predictable interaction states and semantic relationships.

What is actually new in WCAG 2.2?

WCAG 2.2 adds nine new success criteria. Several map directly to components and interaction patterns designers work with every day.

1. Focus Not Obscured (Minimum) — Level AA

When a keyboard user moves focus to a component, that component should not be completely hidden by content created by the author.

Think about: sticky headers, cookie banners, bottom navigation, floating widgets and persistent toolbars.

Design takeaway: Do not design focus states in isolation. Check what happens when the focused component meets the rest of the page.

2. Focus Not Obscured (Enhanced) — Level AAA

This goes further: when a component receives keyboard focus, no part of it should be hidden by author-created content.

Even if your product targets AA rather than AAA, the principle is valuable: let people see what they are interacting with.

3. Focus Appearance — Level AAA

WCAG 2.2 gives more specific guidance around the size and contrast of focus indicators. The criterion includes a minimum focus-indicator area and a 3:1 contrast change between focused and unfocused states, subject to its defined exceptions.

Design takeaway: Never treat the focus ring as something to simply remove. Make focus a real component state in your design system.

4. Dragging Movements — Level AA

If an interaction requires dragging, WCAG 2.2 asks you to provide another way to complete the action unless dragging is essential.

Think about: sliders, kanban boards, sortable lists, maps and range controls.

Design takeaway: If I can drag an item, can I also move it with buttons, keyboard controls or another clear interaction?

5. Target Size (Minimum) — Level AA

Interactive targets need enough size and spacing to reduce accidental activation, especially on touch devices.

Design takeaway: Design the hit area, not just the visible icon. A 16px icon can still have a much larger interactive area.

6. Consistent Help — Level A

Repeated help mechanisms should appear in a consistent relative order across pages where they occur.

Design takeaway: Consistency is not just a visual preference. It helps people know where to look when they need help.

7. Accessible Authentication (Minimum) — Level AA

Authentication should not unnecessarily force users to remember, transcribe or solve cognitive challenges when an accessible alternative is available.

Design takeaway: Make room for password managers, copy and paste, passkeys and accessible recovery flows.

8. Accessible Authentication (Enhanced) — Level AAA

The enhanced criterion places stronger limits on authentication processes that rely on cognitive function tests.

You may not design for AAA conformance on every project, but the direction is worth remembering: security and accessibility should not be treated as opposites.

9. Redundant Entry — Level A

If a user has already provided information during a process, they generally should not have to type the same information again when it is required later in that same process.

Think about: checkout flows, onboarding, registrations and multi-step forms.

Design takeaway: Prefill what you already know. Let users review and edit it. Do not make them enter the same address three times.

Forms: where accessibility becomes very real

Forms are one of the easiest places to see whether an interface has been designed around the user or around the happy path.

• Give every field a clear, meaningful label.
• Do not use placeholder text as the only label.
• Explain errors in a way that tells users how to fix them.
• Keep entered information when validation fails where appropriate.
• Make required, optional and error states understandable without color alone.
• Use logical focus and reading order.
• Group related information so the structure makes sense.
• Avoid asking for information that has already been provided.

Try this simple test: look at the form without the design context and read only the labels, values and error messages. Does the flow still make sense?

Accessibility should live inside your components

Accessibility becomes much easier when it is part of the design system rather than a reminder added to a project checklist.

For a button, do not create only a default state. Think about:

• Default
• Hover
• Focus
• Pressed
• Disabled
• Loading
• Error or validation context, where relevant

Do the same for inputs, tabs, menus, dialogs, cards, links and navigation.

A practical WCAG workflow for designers

1. Start with the user. Consider differences in vision, hearing, mobility, speech, cognition and the ways people use devices.
2. Check the foundations. Review typography, hierarchy, contrast, spacing, responsive behaviour and information density.
3. Design the states. Include focus, error, loading, empty, success, selected, expanded and disabled states where relevant.
4. Question the interaction. Can the important action be completed without relying only on dragging, hover, a mouse or precise tapping?
5. Review the content. Are labels, instructions, error messages and calls to action actually clear?
6. Test the real interface. Use keyboard navigation, browser zoom and assistive technologies where possible. A Figma review is useful, but it is not the same as using the finished product.
7. Work with developers early. Discuss semantics, focus order, keyboard behaviour and implementation constraints before they become expensive fixes.
8. Keep improving. Accessibility is product quality, not a one-time audit.

A quick checklist before handoff

• Can I understand the interface without relying on colour alone?
• Can I see where keyboard focus is?
• Can sticky or floating UI cover the focused element?
• Are important targets comfortable to activate?
• Is there an alternative to a drag-only interaction?
• Are repeated help options predictable?
• Can users use accessible authentication methods?
• Am I asking for information the user already gave me?
• Are error and recovery states designed?
• Have I considered zoom, responsive layouts and different input methods?

A few common mistakes worth catching early

• “The colour contrast looks fine.” Contrast is important, but accessibility is much bigger than colour.
• “We can add focus later.” Focus affects layout, component styling and interaction states. Design it early.
• “The icon is 20px, so the target is 20px.” The visual size and interactive hit area are not the same thing.
• “Everyone knows how drag and drop works.” Familiarity does not make an interaction universally operable.
• “The error is red, so users will understand it.” Colour alone is not a complete explanation.
• “Accessibility is a developer problem.” Developers implement accessibility, but designers make many of the decisions that determine whether it is possible to implement well.

The bigger picture: accessibility is good product design

There is a tendency to talk about accessibility as a collection of restrictions: do not use this colour, do not make this target too small, do not hide the focus ring.

I think it is more useful to see it differently.

Accessibility asks us to design with fewer assumptions.

We stop assuming everyone sees the same way. We stop assuming everyone has a mouse. We stop assuming everyone remembers the same information. We stop assuming a tiny icon is easy to tap or that a familiar gesture is available to everyone.

That usually makes the product better for more people—not just people who identify as having a disability.

Clear forms help everyone. Larger touch targets help everyone. Predictable navigation helps everyone. Good focus states help keyboard users and people who are temporarily using a different input method. Helpful error messages help anyone who makes a mistake.

Final thoughts

WCAG 2.2 can look intimidating when you first encounter it. But you do not have to become an accessibility specialist overnight.

Start small. Learn the criteria that connect to the kind of products you design. Turn repeated requirements into design-system rules. Design states instead of just static screens. Test with a keyboard. Zoom the interface. Try the flow without relying on colour. And involve real users whenever you can.

The goal is not to make a product “pass WCAG” and move on.

The goal is to remove unnecessary barriers so more people can use the product with confidence.

That is not extra UX. That is UX.