Web Accessibility Beyond Alt Text: Keyboard Navigation and Screen Readers
A public-sector client came to us after passing an automated accessibility audit tool with a 98% score, then failing a manual review conducted with an actual screen reader user ahead of a procurement requirement. Automated tools catch missing alt text, insufficient color contrast, and missing form labels well, but they can't tell you whether a modal traps focus correctly or whether a custom dropdown is operable with a keyboard at all — and both were broken.
The custom dropdown components, built with divs and click handlers rather than native select elements or proper ARIA combobox patterns, were entirely unusable via keyboard — no Tab focus, no arrow key navigation between options, no Escape to close. We rebuilt the core interactive components (dropdowns, date pickers, and a multi-select filter) using Radix UI primitives, which implement the correct ARIA roles, keyboard interaction patterns, and focus management out of the box, rather than reimplementing WAI-ARIA authoring practices from scratch.
Modal focus management was the other major gap. Opening a modal didn't move focus into it, so a screen reader user tabbing through the page had no indication a modal had even opened, and closing it didn't return focus to the triggering element, which left keyboard users disoriented and forced them to tab from the top of the page again. We fixed this with a focus trap on open, an initial focus target set explicitly (not just 'first focusable element,' which was sometimes a decorative close icon), and focus restoration to the trigger on close.
We tested with VoiceOver on macOS and NVDA on Windows, since they behave differently enough that testing only one gives a false sense of coverage — NVDA in particular was more strict about redundant or missing ARIA live region announcements on the client's toast notification system, which VoiceOver read acceptably but NVDA either skipped or read twice.
Skip links, heading hierarchy, and landmark regions (nav, main, aside with proper aria-label when there were multiples) rounded out the fixes — small individually, but they were what let a screen reader user actually navigate the page structure instead of listening through every element linearly from the top.
The client passed their procurement accessibility review on the second attempt, and more importantly, we now run a manual keyboard-only pass and a screen reader smoke test as a standard part of QA on every project, not just ones with a compliance requirement — automated scores alone had given us false confidence before.
