Many teams treat accessibility as adding alt text to images or running one automated scan after launch. In reality, whether users can read content, find focus, understand controls, recover from errors, and continue after zooming is determined much earlier in design.
Prioritize frequent, critical, and irreplaceable flows, then incorporate the rules into the design system and development tests.
01 Text and Controls Must Be Readable
Check body text, muted text, buttons, form borders, and status colors. Do not rely on color alone to communicate success, warnings, or errors.
Validate on real devices and across brightness levels and light or dark backgrounds, not only in design software.

02 Every Function Should Work with a Keyboard
The interaction order should follow the reading logic, and focus must remain clearly visible. When a modal opens, focus enters it; when it closes, focus returns to the trigger.
Never make hover the only way to access an action.
03 Forms Need Clear Labels and Error Recovery
Placeholder text cannot replace field labels. Error messages should identify the problem, explain how to fix it, and be associated with the relevant field.
Preserve entered data after a failed submission so users do not have to start over.

04 Test Touch Targets and Spacing in Real Use
Small icons, dense actions, and adjacent destructive buttons cause accidental taps. Increase the clickable area and spacing rather than enlarging only the graphic.
Mobile designs must also account for one-handed use and system zoom.
05 Assistive Technology Must Understand the Content Structure
Heading levels, lists, tables, button names, and region semantics should match the visual structure. Icon buttons need understandable names, and important images need equivalent descriptions.
The visual order should not conflict with the DOM order.

06 Motion, Zoom, and Responsive Layouts Must Preserve Content
Support larger text, page zoom, and narrow-screen reflow. Motion should avoid causing discomfort and respect reduced-motion preferences.
Horizontal scrolling, fixed heights, or floating layers should never make content inaccessible.
10 Accessibility Priorities
Priority | Quick Check |
|---|---|
Color contrast | Are muted text and buttons still readable? |
Keyboard operation | Can users complete the core task? |
Visible focus | Is the current position clear? |
Field labels | Does the field retain a name without placeholder text? |
Error messages | Do they explain how to fix the problem? |
Touch targets | Are small buttons easy to tap by mistake? |
Semantic structure | Are headings, tables, and buttons correctly marked up? |
Alternative content | Can users understand images and icons? |
Zoom and reflow | Does the product remain usable when enlarged? |
Motion controls | Can users reduce or pause nonessential motion? |
Frequently Asked Questions
Does accessibility serve only users with disabilities?
No. Clear labels, visible focus, error recovery, and larger touch areas also help older users, people with temporary limitations, and users on the move.
Are automated testing tools enough?
No. Tools can find some issues, but keyboard flows, semantics, and actual comprehension still require human testing.
Must every button be large?
Controls should meet operable target and spacing requirements, with details adjusted for context, platform, and valid exceptions.
What if the brand color lacks sufficient contrast?
Adjust lightness, use a supporting color, or change the text and background combination. You do not need to abandon the entire brand color.
Where should an older product begin?
Start with login, payment, forms, and core tasks. Establish baseline components, then expand coverage gradually.
Service | View |
|---|---|
Related service | |
Related reading | Read the article |
Design work | |
Project inquiry |