WCAG 2.2 for UX designers and product managers

Perceivable

Users can perceive all content. This means providing alt text for images so screen readers can describe them, and captions for video so deaf or hard-of-hearing users can follow along. If a user cannot sense the content through any available channel, it does not exist for them.

Operable

Users can operate all functionality. Every interaction — links, buttons, forms, menus — must be reachable and usable via keyboard alone. Any motion or animation that plays automatically must be pausable, stoppable, or hideable.

Understandable

Users can understand the content and how to use it. This means writing in plain language, labeling inputs clearly, and making error messages actionable — explaining what went wrong and how to fix it, not just highlighting the field in red.

Robust

Content works reliably across assistive technologies. This means using semantic HTML, proper ARIA roles, and tested compatibility with screen readers like NVDA, JAWS, and VoiceOver, as well as voice navigation tools.

Color contrast

Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18px+ regular or 14px+ bold) requires 3:1. Low contrast text is one of the most common failures — and one of the easiest to fix at the design stage.

Alt text

All meaningful images must have descriptive alt text that conveys the same information the image carries. Decorative images should use an empty alt attribute (alt="") so screen readers skip them. Alt text is not a caption — it is a substitution.

Keyboard navigation

Every interaction — buttons, links, dropdowns, modals, date pickers — must be reachable and operable using only the Tab, Enter, Space, and arrow keys. If a user has to reach for a mouse to complete an action, you have a keyboard accessibility failure.

Focus indicators

When a user navigates via keyboard, it must be visually obvious which element currently has focus. Removing the browser default outline without providing a replacement is one of the most common and most harmful accessibility mistakes in design systems.

Form labels

Every form input must have a visible label that is programmatically associated with it (using the HTML for/id relationship or an aria-label attribute). Placeholder text does not count as a label — it disappears when the user starts typing.

Error identification

Errors must be described in text — not only by color or icon. A red border alone is not sufficient. The error message must identify which field failed and explain what the user should do to correct it.

Target size

Interactive elements (buttons, links, checkboxes) must be at least 24×24 CSS pixels. 44×44px is the recommended minimum for touch targets per Apple and Google human interface guidelines. Small tap targets are a mobility impairment issue and a general usability issue.

No seizure-risk flashing

No content may flash more than 3 times per second. Content that flashes at this rate can trigger seizures in people with photosensitive epilepsy. This applies to animations, video, and any rapidly updating UI element.

Include contrast ratios in your design system

Document the contrast ratio of every text and background color combination in your design tokens. Link to the design system guide for implementation. See the design system guide.

Design visible focus states for every interactive component

Every button, link, input, and interactive element needs a designed focus state — not just the browser default. Treat focus rings as a design element, not an afterthought.

Test prototypes with keyboard navigation before handoff

Before handing off any screen, navigate it using only the Tab key. If you cannot reach every interactive element, or the order is confusing, fix it before development.

Write alt text for images in your wireframes

When adding images or icons to wireframes, annotate them with the intended alt text. This ensures developers and content teams implement it correctly — and forces you to consider what the image communicates.