Build accessibility into the first version

Make the core experience perceivable, operable, understandable, and robust from the start.

01

Use the platform before recreating it

Semantic HTML gives controls names, roles, states, and keyboard behavior. Use buttons for actions, links for destinations, labels for inputs, headings for structure, and tables for real tabular relationships.

Custom controls require more engineering and testing than they appear to.

EXAMPLE

A native select with a visible label is often more reliable than a stylized div-based dropdown.

MISTAKE TO AVOID

Making a clickable div look like a button without keyboard or screen-reader behavior.

NEXT ACTION

Inspect the accessibility tree for the primary journey.

02

Design focus, contrast, and errors

Meet WCAG AA contrast, preserve visible focus, and do not communicate state by color alone. Put validation messages beside the field and summarize problems when a long form fails.

Error messages should explain how to recover without erasing work.

EXAMPLE

‘Enter an email in the format name@example.com’ is more useful than ‘Invalid input.’

MISTAKE TO AVOID

Removing focus outlines because they do not match the design.

NEXT ACTION

Complete every interaction with keyboard only at 200% zoom.

03

Respect different reading and motion needs

Use readable line lengths, scalable text, clear headings, meaningful alternative text, captions where needed, and reduced-motion behavior.

Decorative images should not add noise to assistive technology.

EXAMPLE

A publishing animation becomes a static state change when reduced motion is requested.

MISTAKE TO AVOID

Putting essential instructions inside an image of a screen.

NEXT ACTION

Test narrow mobile, landscape, text scaling, reduced motion, and one screen-reader route.

USE THE GUIDE

Turn these decisions into a build specification.

Open the brief builder