An accessibility audit finds that a custom dropdown is unusable with a screen reader. It passed automated checks. Why, and what is the systemic fix?

What the interviewer is testing

Whether you know the limits of automated checking and where accessibility is actually decided.

Why automation missed it

Automated tooling detects roughly a third of the issues in the standards — the machine-checkable subset: missing alt text, contrast, absent labels, invalid ARIA syntax, missing document structure.

It cannot judge whether the interaction works. A custom dropdown built from generic elements can have technically valid ARIA attributes and still be unusable, because:

• Arrow keys do not move between options
• Escape does not close it
• Focus is not managed on open and close
• The current selection is not announced
• Typeahead does not work
• The expanded state is not communicated

Each of these is a behaviour, not an attribute, and no scanner assesses behaviour.

The systemic fix

This is a design system problem, not an audit finding. The single most common source of accessibility failures is a custom interactive control rebuilt from generic elements without the keyboard handling and semantics the native one had.

So:

Use native elements where they exist. A native select is accessible by default across every assistive technology and platform, and the visual customisation that motivated the rebuild is usually achievable within it or with a much thinner wrapper.

Where a custom control is genuinely needed, build it once in the design system, test it properly with real assistive technology, and have every product inherit it. Then a fix reaches every product at the next version bump, rather than being remediated twelve times.

Follow the established interaction patterns for the component type rather than inventing keyboard behaviour.

What the testing practice should be

Automated checks in the pipeline as a regression gate. Keyboard-only navigation as a manual step in review — the highest-value manual check and it costs minutes. Screen reader testing for new components in the design system. Periodic testing with real users where the product warrants it.

What a strong answer adds

The commercial and legal framing: accessibility is a statutory requirement in a growing number of jurisdictions and a contractual one in most public-sector procurement — so the design system investment is risk reduction, not goodwill.

Common weak answers

Fixing the one component. Adding more automated rules, which cannot detect behaviour.