Designing for Accessibility: A Practical WCAG 2.2 Guide for Product Teams

Accessibility lawsuits against digital products have more than tripled over the past five years. In the United States alone, thousands of ADA-related web accessibility cases are filed annually. The European Accessibility Act came into force in June 2025, requiring most digital products and services in EU markets to meet accessibility standards. And in October 2023, the W3C published WCAG 2.2 as the official successor to WCAG 2.1 — the version most teams still design and build against today.

This is not a distant compliance concern. It is a present-tense product responsibility. And for teams that have been treating accessibility as a final-stage checklist rather than a design-phase discipline, the gap between what they have shipped and what standards now require is likely larger than they realise.

This guide is a practical, non-overwhelming introduction to WCAG 2.2 for product teams — what is new, what matters most, how to audit what you have, and how to build accessibility into your design process going forward.

What Is WCAG and Why Does 2.2 Matter?

The Web Content Accessibility Guidelines (WCAG) are the internationally recognised standard for making digital content accessible to people with disabilities. Published by the W3C's Web Accessibility Initiative, they are referenced in legislation across the UK, EU, US, Australia, and most other developed markets. Meeting WCAG 2.2 AA is not just best practice — it is increasingly a legal baseline.

WCAG is organised around four core principles, known by the acronym POUR: content must be Perceivable, Operable, Understandable, and Robust. Each principle contains guidelines, each guideline contains testable success criteria, and each criterion is rated at Level A (minimum), Level AA (standard), or Level AAA (enhanced). For most product teams, WCAG 2.2 AA is the target — it is the level referenced in most legislation and procurement requirements.

WCAG 2.2 adds nine new success criteria to the 2.1 standard, removes one (4.1.1 Parsing, which browsers now handle automatically), and tightens the language on several existing criteria. The additions are almost entirely focused on motor impairments, cognitive accessibility, and authentication — areas where the previous standard had significant gaps.

What Is New in WCAG 2.2: The Key Changes

Of the nine new success criteria in WCAG 2.2, four are at Level AA and therefore represent new compliance requirements for most product teams. Here is what each means in practice.

2.4.11 Focus Not Obscured — AA

When a keyboard user navigates to a focused element, that element must not be entirely hidden behind a sticky header, floating action button, cookie banner, or chat widget. This is one of the most commonly violated criteria in products with sticky navigation — users who rely on keyboard navigation lose track of where they are on the page when focus scrolls behind a fixed element.

2.5.7 Dragging Movements — AA

Any functionality that requires dragging — sliders, sortable lists, drag-and-drop file uploads, kanban boards — must also be operable with a single pointer without dragging. This is critical for users with motor impairments who cannot reliably perform dragging gestures. If your product has drag-and-drop interactions, you need an alternative: click-to-select-and-click-to-place, keyboard controls, or equivalent single-tap actions.

2.5.8 Target Size Minimum — AA

Interactive targets must be at least 24x24 CSS pixels, with exceptions for inline text links and targets where spacing around the element compensates. This is a minimum — Apple's Human Interface Guidelines recommend 44x44pt, and Material Design recommends 48x48dp. The new WCAG requirement sets a floor, not an ideal. Most teams building mobile-first products will already exceed this, but icon-only buttons, close icons, and pagination controls are common offenders.

3.2.6 Consistent Help — AA

If your product offers a help mechanism — a live chat widget, a help link, a phone number, a contact form — it must appear in the same location on every page or screen where it is present. Users with cognitive disabilities rely on consistent placement to find support when they are confused. Moving a chat button between the bottom right of some pages and a header menu on others violates this criterion.

3.3.7 Redundant Entry — AA

Users should not be required to enter the same information twice within a single session unless there is a clear reason to do so. Asking for an email address on a signup form and then again on a checkout form in the same session violates this criterion. Autofill, pre-populated fields, and session persistence are the primary solutions.

3.3.8 Accessible Authentication — AA

Authentication processes must not rely on cognitive function tests unless an alternative is provided. CAPTCHAs that require recognising distorted text, solving puzzles, or performing memory tasks are a significant barrier for users with cognitive disabilities. This criterion requires that at least one of the following is available: an object recognition alternative, a personal content recognition alternative (such as recognising a user's own uploaded photo), or no cognitive test at all. Passkeys, magic links, and social sign-in are all compliant solutions.

The POUR Principles in Practice

Perceivable: Everything Has a Non-Visual Alternative

All information must be perceivable through at least one sense. Images need descriptive alt text. Videos need captions and audio descriptions. Charts and data visualisations need text alternatives. Colour cannot be the only means of conveying information — an error state signalled only by turning a field red fails users with colour blindness. Content must maintain meaningful structure when rendered without CSS or with a screen reader navigating by headings.

Operable: Every Action Has a Keyboard Alternative

All functionality must be operable without a mouse. Keyboard navigation must follow a logical, predictable tab order. Focus states must be visible — not a faint dotted outline but a clearly visible focus ring that meets the contrast requirements introduced in WCAG 2.2. Dropdown menus, modals, date pickers, and custom interactive components all need proper keyboard support including Escape key to close, arrow key navigation where appropriate, and focus trapping inside modals.

Understandable: Language Is Clear, Errors Are Helpful

Content must be readable and predictable. The page language must be declared in the HTML so screen readers can pronounce content correctly. Navigation and UI behaviour must be consistent across pages. Error messages must identify what went wrong and explain how to fix it — 'Invalid input' fails this criterion; 'Your email address must include an @ symbol' passes it.

Robust: Content Works Across Assistive Technologies

Content must be compatible with current and future assistive technologies. This means valid, semantic HTML — using the right elements for their intended purpose. Buttons for actions, links for navigation, headings in logical hierarchical order, landmark elements (header, main, nav, footer) to enable screen reader navigation. Custom components built with div and span need ARIA roles, states, and properties to communicate their behaviour to assistive technology.

How to Audit Your Product for WCAG 2.2 Compliance

A full WCAG conformance audit requires a combination of automated testing and manual expert review. Automated tools can catch approximately 30 to 40 percent of accessibility issues — the rest require human judgment. Both are necessary.

Automated Testing Tools

• axe DevTools — the most comprehensive browser extension for automated accessibility testing; the free version catches a significant range of violations and integrates with Chrome DevTools

• WAVE by WebAIM — visual overlay tool that annotates accessibility issues directly on the page; excellent for non-technical stakeholders who need to see and understand the issues

• Lighthouse — built into Chrome DevTools; provides an accessibility score and specific criterion failures; useful for monitoring scores over time in CI/CD pipelines

• WebAIM Contrast Checker — fast, free tool for checking colour contrast ratios against WCAG AA and AAA thresholds

Manual Testing Checklist

• Navigate your core flows using only the keyboard — Tab, Shift+Tab, Enter, Space, Escape, and arrow keys — and note anywhere you get stuck or lose focus

• Switch on VoiceOver on macOS or iOS, or TalkBack on Android, and attempt to complete your primary user task — note anywhere the screen reader fails to announce the right information

• Use a colour blindness simulator (Figma has this built in, as does Chrome DevTools) to check all error states, status indicators, and data visualisations for colour-only information

• Increase your browser text size to 200% and check that no content is obscured, clipped, or broken

• Check all form fields for visible labels, helpful placeholder text, and clear, actionable error messages

• Verify that focus states are visible on every interactive element — if you cannot clearly see where keyboard focus is at all times, your focus styles are insufficient

The 5 Most Impactful Fixes to Prioritise First

If your product has never had a formal accessibility review, the audit will likely produce more issues than your team can address in a single sprint. Here is where to focus first for the greatest combination of user impact and legal risk reduction.

• Colour contrast — check every text element against its background; body text requires a 4.5:1 ratio, large text (18pt or 14pt bold) requires 3:1; this is the most cited violation in accessibility lawsuits and the fastest to fix

• Image alt text — every meaningful image needs descriptive alt text; decorative images need an empty alt attribute (alt="") so screen readers skip them; missing alt text on product images and UI icons is one of the most common and most fixable violations

• Keyboard navigability of core flows — if a user cannot complete signup, login, or your primary task using only a keyboard, you have a critical barrier that affects a large proportion of users with motor impairments

• Form labels and error messages — every form field must have a visible, associated label (not just a placeholder); every error must explain what went wrong and how to fix it; form accessibility issues are the single largest driver of task abandonment for users with cognitive and visual impairments

• Focus visibility — remove any CSS that hides the browser's default focus ring without replacing it with a clearly visible alternative; visible focus states cost nothing to implement and are required by WCAG 2.2

Building Accessibility into Your Design Process

The most effective and least expensive approach to accessibility is to build it in from the start, not audit it in at the end. Here is how to integrate accessibility into each stage of your design process.

• Research — include users with disabilities in your research and testing panels; assistive technology users will surface issues no automated tool or expert evaluation can anticipate

• Design — use Figma's built-in colour contrast checker and accessibility annotation kits to document focus order, ARIA labels, and reading order as part of your design files before handoff

• Development — integrate axe-core or similar automated testing into your CI/CD pipeline so accessibility regressions are caught before they reach production

• Review — include keyboard navigation and screen reader testing in your definition of done for every new feature, not as a separate accessibility sprint

• Governance — publish an accessibility statement on your website, maintain a mechanism for users to report accessibility issues, and respond to reports within a committed timeframe

The W3C's official WCAG 2.2 documentation and the WebAIM WCAG 2 Checklist are both essential bookmarks for any team taking accessibility seriously. The WebAIM checklist in particular is the most practical quick-reference resource available for translating the WCAG specification into actionable design and development tasks.

Accessibility is not a feature. It is a quality standard. A product that excludes users with disabilities is not a finished product — it is an unfinished one.

Final Thoughts: Accessibility Is a Design Decision

Approximately one in five people globally lives with some form of disability. That is not a niche user group — it is a fifth of your potential audience. And the benefits of accessible design extend far beyond users with permanent disabilities: captions help users in noisy environments, keyboard navigation helps power users, sufficient contrast helps users in bright sunlight, and clear error messages help every user who makes a mistake. Accessibility done well is just good design.

At Afrodity Designs, accessibility is embedded into our design process from discovery through to handoff. We build to WCAG 2.2 AA by default and conduct accessibility reviews as part of every design system engagement we deliver. If you would like to understand where your product stands against the current standard and what to prioritise first, our accessibility audit is a practical, actionable starting point. We would love to help.