A comparison, not a lecture
Two comboboxes. Same look.
Both of these search 8,000 ingredients and look identical. Try each one with only a keyboard — Tab in, type, press the arrow keys, press Enter. One of them was built to the WAI-ARIA combobox pattern. The other is how a lot of custom dropdowns actually get built.
Naive version
no ARIA, mouse-onlyScreen reader would announce
Nothing — there is no role, no aria-expanded, no live region. A screen reader has no way to know this popup exists.
Accessible version
APG combobox patternScreen reader would announce
Focus the field and start typing to see announcements appear here.
What’s actually different
- Focus never leaves the input. Arrow keys move
aria-activedescendant, not real DOM focus — that’s what lets you keep typing while a highlighted option is announced. - The result count is announced, not just shown. A sighted user sees “8 results” appear; a screen reader user needs the same information pushed to them, which is what the live region above does.
- Virtualisation doesn’t break the contract. With 8,000 options only a slice is ever in the DOM, but
aria-activedescendantalways points at an option that actually exists — scrolling the highlighted item into view is part of the keyboard handling, not an afterthought.
This page’s automated checks (axe-core, plus keyboard-only Playwright tests) catch a real slice of accessibility bugs, and the naive combobox deliberately fails them. They do not replace testing with an actual screen reader — NVDA, JAWS, or VoiceOver will surface things no automated tool does.