Skip to content
Design

An Accessibility Checklist Engineers Will Actually Follow

Sofia Reyes, Design Engineer at Automative Tech
Sofia Reyes
Design Engineer
6 min read
1,380 words
Designer reviewing accessible interface layouts and inclusive UI patterns on a screen
Photo: Unsplash

Concrete WCAG checks wired into PRs — focus management, contrast, and live regions without turning design into bureaucracy.

Make a11y a PR habit

Engineers follow checklists that fit in a review, not thirty-page PDFs. We keep a short set of must-pass checks for interactive UI: keyboard reachability, visible focus, name/role/value for controls, and contrast on text and essential icons.

Automation catches regressions; humans still verify flows with a screen reader on non-trivial widgets.

Focus management in real apps

Modals, drawers, and route changes must move focus intentionally and restore it on close. Trapping focus incorrectly is as bad as not managing it at all.

Skip links and landmark structure help power users navigate dense product UIs without tabbing through the entire shell.

Live regions and dynamic content

Toasts, inline validation, and async results need polite or assertive live regions depending on urgency. Silent updates leave assistive tech users guessing.

Prefer clear text updates over colour-only state. Colour can reinforce meaning; it should not be the only signal.

Design and engineering shared ownership

Specs should include interaction notes for keyboard and reduced motion. Designers who annotate focus order prevent late thrash.

When accessibility is framed as quality — not as optional polish — it ships with the feature instead of as a remediation project.

a11yWCAGFrontend
Sofia Reyes, Design Engineer at Automative Tech
About the author

Sofia Reyes

Design Engineer

Design engineer bridging Figma systems, accessibility, and motion into production UI.