Designing for WCAG 2.2 AA: A Practical Primer
By CodexierPublished 7 min read
Accessibility is often handed to developers as a final check, which is the most expensive place to discover that the brand's light grey text fails contrast on every page. WCAG 2.2, the current version of the guidelines behind Sweden's and the EU's accessibility requirements, contains a set of criteria that are decided in the design phase. This primer covers those, in the order they usually bite, with a concrete check for each.
Contrast and colour use
Contrast is where most brands fail first, because the palette was chosen for print or for a logo, not for text on a screen. Check every text colour against every background it appears on, including text on images, on buttons and in disabled states, using a contrast checker or the plugin in your design tool. When a brand colour fails, keep it for large headings and decorative elements and introduce a darker tint for body text and links. Then check that meaning never depends on colour by itself: a red border on an error field must be paired with an icon and a message, and a chart's series need labels or patterns, not just hues.
Focus states and keyboard paths
Anyone navigating with a keyboard, a switch or a screen reader moves through the page by focus. If the design file has no focus state, the developer will either invent one or, more often, remove the browser default because it clashes with the look. WCAG 2.2 tightened this: focus must be visible, and the newer criterion on focus appearance asks that the indicator has enough contrast and is not hidden behind sticky headers or overlays. Design the focus state for every interactive component as deliberately as the hover state.
- Draw a focus ring for buttons, links, inputs, cards and custom controls, with at least 3 to 1 contrast against adjacent colours.
- Order the components in the file the way a keyboard user should meet them; the tab order follows the code order, and the code follows your layout.
- Make sure sticky headers, cookie banners and chat widgets never cover the focused element.
- Provide a way to skip repeated navigation, and make sure modals trap focus and return it on close.
Target size and spacing
WCAG 2.2 added a minimum target size criterion at AA: interactive targets should be at least 24 by 24 CSS pixels, or have enough spacing that a 24-pixel circle around them does not overlap a neighbour. This mostly affects icon buttons, pagination, tag chips, close icons and anything in a dense toolbar. The fix is rarely to make the icon bigger; it is to give the tappable area padding. Design components with the hit area drawn explicitly, not just the visible glyph, and your developer will build it that way.
| Component | Common failure | Design fix |
|---|---|---|
| Icon buttons in a toolbar | 16-pixel icons with no padding | Define a 40-pixel hit area around each icon |
| Pagination and breadcrumbs | Numbers set as plain text links close together | Add padding so each link is a comfortable target |
| Close buttons on modals and banners | Tiny cross in the corner | Larger hit area, and an Escape key alternative |
| Inline links in body text | Exempt from the target rule, but often too faint | Underline links; do not rely on colour alone |
| Date pickers and sliders | Small handles and day cells | Bigger handles, day cells with spacing, and a text input alternative |
Mobile is where target size decides whether a form is usable at all. Test on a phone, not in a desktop preview.
Forms, labels and errors
Forms are where a business loses the most from poor accessibility, because they are where the enquiry, the booking or the order happens. The design decisions are straightforward. Every field has a visible label above or beside it; placeholder text disappears when typing and is not a label. Required fields are marked in text, not only with a colour or an asterisk without explanation. Error messages appear next to the field, say what went wrong and how to fix it, and are also summarised at the top of the form on submit. WCAG 2.2 adds two criteria worth designing for: do not make people re-enter information they already gave in the same process, and do not rely on a cognitive test such as a puzzle for login without an alternative.
Labels
Visible, persistent, close to the field. Group related fields such as address lines under a heading.
Help text
Format hints such as how to write a phone number go before the field, not after the error.
Errors
Icon plus text in a colour that passes contrast, positioned with the field, with a summary that links to each problem.
Authentication
Allow paste in password fields, support password managers, and offer BankID or email link as alternatives to memory tests.
Motion and reduced-motion
Animation is a design choice with an accessibility cost. Autoplaying carousels, parallax effects and animated backgrounds can cause discomfort for people with vestibular disorders and distract people with attention difficulties. WCAG requires that anything moving for more than five seconds can be paused, stopped or hidden, and that nothing flashes more than three times a second. The practical design rule: design a reduced-motion variant of every animated component, so that when the user's operating system asks for less motion, the site can honour it. Fade instead of slide, static hero instead of video, and no motion that carries information without a static equivalent.
When you do not need to go further than this: for a small brochure site with a contact form, the criteria above cover most of what matters, and a designer can verify them in an afternoon without an audit. Where an audit earns its fee is on sites with checkout, booking or logged-in flows, where a failure blocks a transaction and the European Accessibility Act now applies to many private services. Our UX audit includes these checks alongside the user sessions described in user testing with five people. Which you need is a short call.
- UX audit and conversion improvementAccessibility checks against WCAG 2.2 AA, user sessions and a prioritised fix list.
- User testing with five peopleHow to see these problems happen to real people before you fix them.
- Book a free 15-minute callSend us the design file or the URL; we tell you which criteria are at risk.
Frequently asked questions
Does WCAG apply to private companies in Sweden?
Public bodies have been required to meet it for years under the Swedish law implementing the EU web accessibility directive. The European Accessibility Act extends requirements to many private services, including e-commerce, banking and transport, for products and services placed on the market from 2025. Even where it is not mandatory, the criteria describe what usable means for a large share of your customers.
What is the difference between WCAG 2.1 and 2.2?
Version 2.2 adds criteria on focus appearance, focus not being obscured, minimum target size, dragging alternatives, consistent help, redundant entry and accessible authentication, and it removes one obsolete criterion. If you designed for 2.1 AA, the new work is mostly focus states, target sizes and forms.
Can I check contrast myself?
Yes. Most design tools have plugins that show the contrast ratio between text and background, and free web tools do the same for any two colours. Check every combination that actually appears on the page, including text on images and in disabled states, not just the primary palette.
Will accessible design make the site look worse?
No. Contrast, clear labels, generous targets and visible focus are also what make an interface feel calm and easy. Constraints on very light greys and tiny icons are real, but a good designer works within them. What accessible design rules out is mostly decoration that was hurting usability anyway.
Want your design file checked against WCAG 2.2 before development starts?
Fifteen minutes with an engineer: send the Figma link or the live URL and we tell you which criteria are at risk and what it would take to fix them before code is written.
Book a free 15-minute call