An accessibility checklist belongs at the start of a project, not at the end of review. Discover too late that your color contrast fails or that a component can’t be reached by keyboard, and the fix is often structural — not a tweak but a rebuild. The economics are simple: the earlier the check, the cheaper the correction. What follows is the practical checklist worth keeping open from the first screen onward.
1. Start with color contrast
The baseline numbers come straight from WCAG: body text should hit a contrast ratio of at least 4.5:1 against its background, and large text at least 3:1. The part teams forget is that the 3:1 threshold also applies to meaningful graphics — buttons, icons, form field borders — anything a user must perceive to operate the interface.
The same stage is the right moment to check that color is never the only carrier of meaning. An error state that is communicated purely by turning red is invisible to many colorblind users; pair the color with an icon or a text label and the state survives regardless of how the viewer perceives hue.
2. Walk the interface by keyboard
Put the mouse aside and try to operate the entire screen with the Tab key. Every interactive element should be reachable. Focus should be visibly marked with a clear outline, so the user always knows where they are. Opening a modal should move focus into it; closing the modal should return focus to where it came from. And the tab order should follow the visual flow of the page rather than jumping around it. None of this is exotic — it just has to actually be tried, element by element, and it earns a permanent slot in the design QA checklist you run before every release.
Confirm every interactive element can be reached with Tab alone.
Check that focus is marked by a clearly visible outline at all times.
Open a modal: focus moves inside. Close it: focus returns to its origin.
Verify the tab order matches the visual reading order of the screen.
Screen reader basics are design decisions
Whether images carry alt text, whether buttons and links have labels that state their purpose, whether form fields are programmatically tied to their labels — these read like engineering concerns, but they are decided at the design stage. Link text deserves special attention. A link that says “learn more” tells a screen reader user almost nothing, because out of context there is no way to know more about what. Writing rules for link text belongs in your conventions right alongside component naming.
The unhelpful link
“Learn more” — destination unknown, meaningless when read out of context.
The helpful link
“Read the accessibility guide” — the destination is in the text itself.
3. Give touch targets room to breathe
On mobile, a touch target needs to be at least 44×44 pixels before mis-taps drop to a tolerable level. Spacing matters as much as size: two buttons that look comfortably separated on a desktop monitor can sit close enough on a phone that thumbs hit the wrong one. The reliable fix is structural — encode minimum spacing into the components themselves with auto layout, so the padding rules are enforced at the source rather than remembered screen by screen.
💡 Pro tip — Link the W3C’s official WCAG quick reference in your team wiki, and make walking this checklist a standing part of every design review. The habit matters more than any single audit.
4. Know what automated checkers can’t see
Automated tools like Lighthouse and axe are excellent at what they do: they catch mechanically verifiable failures — contrast ratios, missing alt text, absent labels — in seconds, at scale. What they cannot judge is anything requiring context. Whether link text actually describes its destination, whether the focus order is logical rather than merely present, whether the experience makes sense through a screen reader — those calls need a human. Treating a passing automated audit as proof of accessibility is one of the most common mistakes teams make.
Automation catches
Contrast values, missing alt text, unlabeled fields, semantic markup gaps.
Humans must judge
Logical focus order, meaningful link text, the actual screen reader experience.
The strongest habit is to run a real screen reader over the interface at least once before release — it is the most reliable way to surface what the tools structurally cannot. Since manually reviewing every screen on every release isn’t realistic, prioritize: new components and the core user flows get the manual pass first, and automation covers the rest. Together the two methods patch each other’s blind spots.
Closing thoughts
The working checklist condenses to this: 4.5:1 contrast for body text and 3:1 for large text and graphics, states distinguished by more than color alone, every interaction reachable by Tab, alt text and form labels in place, and touch targets at 44×44 pixels with real spacing between them.
Accessibility is not a side quest performed for a subset of users. Every item on this list — clearer contrast, predictable focus, honest link text, forgiving touch targets — makes the product easier for everyone. That is what makes it a fundamental, not a feature.
Design Daily Life · Notes on design, daily