Accessibility Basics Every Product Team Should Ship: A WCAG 2.2 AA Checklist for Contrast, Focus, Targets and Labels

Accessibility work can feel enormous, so teams postpone it. A better way to start is to ship the basics on every screen. A small set of repeated problems accounts for a large share of what blocks people from using an interface: text that is too faint, controls you cannot reach by keyboard, tap targets that are too small, and form fields with no clear label.

The standard to aim for is WCAG 2.2 level AA. WCAG is the Web Content Accessibility Guidelines, published by the W3C. Version 2.2 is the current one, and AA is the level most laws, contracts and procurement rules point to. This post covers the parts of AA that product and design teams can act on this week.

It is a starting point, not a full audit. Passing these checks does not make a product fully accessible, and automated tools cannot judge everything. Treat the list as the floor.

1. Colour contrast

The rule (WCAG 1.4.3 and 1.4.11).

• Normal text needs a contrast ratio of at least 4.5:1 against its background.
• Large text (at least 24 CSS px, or 18.66 CSS px if bold) needs at least 3:1.
• Meaningful non-text elements, such as input borders, icons that carry meaning, and focus indicators, need at least 3:1 against adjacent colours.

Where teams slip. Light grey placeholder text, pale helper text, white text on a mid-tone brand colour, disabled-looking buttons that are actually active, and input borders that fade into the page.

How to check. Use the contrast checker in your design tool, a plugin, or the browser's developer tools. Check the colour pairs once, in your design tokens, instead of screen by screen.

A fix that scales. Define text colours as tokens (primary text, secondary text, link, error) and record the verified ratio next to each one. If a new colour is added, it needs a ratio before it joins the system.

Do not rely on colour alone (WCAG 1.4.1). A red border on an invalid field is invisible to some users. Add an icon and a text message. Links inside body text need more than a colour difference, such as an underline.

2. Visible keyboard focus

The rule (WCAG 2.4.7 and 2.4.11). Every interactive element must show where keyboard focus is, and the focused element must not be fully hidden behind other content such as a sticky header or cookie banner.

Where teams slip. Removing the browser's default outline with outline: none and adding nothing in its place. Custom components built from generic elements that cannot receive focus at all. Sticky bars that cover the focused field when the page scrolls.

How to check. Put your mouse aside and press Tab through the page.

1. Can you see where you are at every step?
2. Does the order follow the visual reading order?
3. Can you reach and operate every control, including menus, modals and date pickers?
4. Can you leave a modal with Escape, and does focus return to where it was?
5. Does the focus ring stay visible when a sticky header is present?

A fix that scales. Design a single focus style in your system: a solid two-pixel outline in a colour that has at least 3:1 contrast against both the background and the control, with a small offset. Apply it to every interactive component.

3. Target size

The rule (WCAG 2.5.8, new in 2.2). Pointer targets should be at least 24 by 24 CSS pixels, unless there is enough spacing around smaller ones or the target is an inline link in a sentence.

Many design systems already aim higher, for example 44 by 44 for primary touch controls, which is a stronger practice and a sensible default on mobile. The 24 pixel minimum is the AA floor.

Where teams slip. Tiny close icons, dense table row actions, social icons packed together, and pagination links with almost no space between them.

How to check. Measure the clickable area, not the icon. A 16 pixel icon inside a 40 pixel button is fine. A 16 pixel icon that is the whole button is not.

4. Labels and instructions on forms

The rules (WCAG 1.3.1, 3.3.2 and 4.1.2). Every input needs a programmatically linked label, and users need to know what is expected before they type.

Where teams slip.

• Placeholder as label. The text vanishes when someone types, so people forget what the field asks for, and screen readers may not announce it reliably. Use a visible label above the field, and treat placeholder text as an extra hint at most.
• Icon-only buttons with no name. A magnifying glass button needs an accessible name such as "Search". A trash icon needs "Delete" plus context when it appears in a list.
• Required fields marked only with a red asterisk. Say "required" in text, or mark optional fields instead.
• Unlinked helper text. If a field has a format hint, tie it to the input so assistive technology reads it.

A minimal form pattern.

<label for="email">Work email</label>
<input id="email" type="email" autocomplete="email" aria-describedby="email-hint">
<p id="email-hint">We will send the invoice here.</p>

Note the autocomplete attribute. WCAG 1.3.5 asks for correct input purposes on fields about the user, which also helps everyone fill forms faster.

5. Error messages that help

The rules (WCAG 3.3.1 and 3.3.3). When input is wrong, identify the field and describe the problem in text, and suggest a fix where you can.

Poor: "Invalid input." Better: "Enter a date in the format DD/MM/YYYY, for example 05/11/2026."

Practical checks:

• Show the message next to the field, not only at the top of the page.
• Move focus to the first error or to a summary at the top after a failed submit.
• Keep what the user typed. Clearing a long form on error is a serious usability failure.

WCAG 2.2 also adds 3.3.8 (Accessible Authentication): a login should not require users to solve a puzzle or recall and transcribe something to prove who they are, unless an alternative exists. In practice, allow password managers and pasting into password fields.

How to build this into your process

1. Design. Put contrast ratios, focus styles and minimum target sizes in your design system, not in a separate document.
2. Definition of done. Add three lines to your ticket template: keyboard-only pass, contrast checked, labels and errors written.
3. Review. Before release, one person tabs through each new flow while another reads the screen aloud with a screen reader such as VoiceOver or NVDA.
4. Automated tools. Run an automated checker such as axe or Lighthouse. They catch only part of the problems, so use them as a smoke test and not as a pass mark.
5. Include real users when you can, especially people who use assistive technology daily.

FAQ

Is WCAG 2.2 AA a legal requirement?

It depends on your country, sector and customers. Many regulations and public-sector contracts refer to WCAG, often at level AA, but versions differ. Check the rules that apply to you.

Where should a small team start?

Start with the sign-up, login and checkout or main conversion flow. Fix contrast, focus, labels and errors there first.

Talk to us

If you want a team to review your product against these checks or to build them into your design system, write to hello@risingstation.com or visit risingstation.com/contact-us.