Accessibility is one of the few topics where the gap between “our app is accessible” and “our app passes an audit” is enormous. Almost every team we’ve worked with believed they were doing fine until a real screen-reader user opened the app, hit the third tab stop, and got stuck.
Here’s the 7-check sweep that catches roughly 80% of issues. None of it replaces having actual disabled users in your testing pool — but it gets you from “possibly broken” to “defensibly competent.”
Check 1: Color contrast
WCAG 2.2 AA: 4.5:1 for body text, 3:1 for large text (18pt+, or 14pt+ bold). Tooling: axe-core in CI, WebAIM contrast checker for spot checks, Stark in Figma so designers don’t ship anti-patterns into the design system.
Watch-out: the “subtle” gray-on-white that designers love often fails. Brand palettes drift toward low contrast. Bake the contrast check into the design system, not the QA step.
Check 2: Keyboard-only navigation
Unplug your mouse. Open the app. Try to complete your most important flow using only Tab, Shift+Tab, Enter and Esc. If you get stuck, your users do too.
Common failures: custom dropdowns that don’t open on Enter, modals that don’t trap focus, lightboxes with no escape route, image carousels with no keyboard controls.
Check 3: Visible focus
Every focusable element MUST have a visible focus indicator. Many design systems remove the browser’s default outline for aesthetics — that’s an accessibility regression. Replace it with a focus style that respects the brand AND meets 3:1 contrast against the focused element’s background.
Pro tip: use :focus-visible rather than :focus— gives you keyboard-only outlines without click-induced ones.
Check 4: Labels for every input and icon-only button
Every <input> needs an associated <label> (or aria-label). Every icon-only button needs an aria-label that describes the action. “A button with no label” is the single most common screen-reader complaint we see in real audits.
Check 5: Alt text on informative images
Images that convey information need meaningful alt text. Decorative images get alt=""(NOT missing — explicitly empty, so screen readers skip them rather than announcing the filename).
Test: turn off images in the browser. Can you still understand the page? If no, your alt text is incomplete.
Check 6: Respect prefers-reduced-motion
Some users get motion sickness from animation. Honor their preference:
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}Parallax effects, auto-playing videos, decorative animations — all of them need to be off-by-default for users who’ve opted out of motion.
Check 7: Form errors that screen readers announce
When a user submits a form with errors, screen readers should announce them. Use aria-live="polite" on an error-summary region; associate each error with its input via aria-describedby. Don’t just turn the input border red — that’s invisible to non-sighted users.
Where to wire this in
- Design system:contrast, focus styles, label hooks — encoded once, reused everywhere.
- CI: axe-core via Playwright/Cypress. Fail PRs that introduce regressions.
- Manual review: the keyboard-only run + screen-reader pass, before every feature ships.
- Quarterly:a real user with assistive tech runs through the app. They’ll find things tools won’t.
How we approach this
Every project we ship through UI/UX Design and SaaS Product Development bakes these checks into the design system and CI. Accessibility is a property of the product, not a feature you add at the end — the cost of bolting it on later is ~10x the cost of building it in from week one.
Takeaways
- Seven checks: contrast · keyboard · focus · labels · alt · motion · forms.
- Wire enforcement into the design system, not the QA step.
- Tools find ~50%; manual sweep finds ~30%; real users find the last 20%.
- Cost of fixing late is ~10x the cost of building in.
