As asked
A shared Button and Dropdown library is used by 30 teams. How do you prevent accessibility regressions as the library evolves?
Sample answer outline
Bake accessibility into component contracts rather than treating it as after-the-fact QA. Use unit tests for keyboard behaviour and ARIA attributes, Storybook accessibility checks for common states, and end-to-end tests for focus movement in realistic flows. Document expected usage and reject APIs that let consumers remove labels or break semantics too easily. Manual screen reader testing is still needed for complex interactions because automated tools catch only part of the problem. Strong candidates also mention release notes and migration guidance because consumers can create regressions even when the library is sound.
Expect these follow-ups
- Which accessibility issues do automated tools usually miss?
- How do you test keyboard behaviour for a composite widget?
- What do you do when a consuming team misuses the component?