Governance for accessibility regressions

WHAT THIS TESTS This evaluates whether you can build a sustainable governance process spanning many teams, going past CI checks into roles, triage, and accountability.

A GOOD ANSWER COVERS Define the full loop. Detection comes from multiple sources: scheduled accessibility audits, automated monitoring on key flows, support and user reports, and reports surfaced by consuming teams. Triage each issue by severity and impact, then determine ownership: is the root cause in the shared design-system component, or in how a product used it? This boundary is critical. Remediation follows severity-based service levels, for example critical blockers fixed urgently and minor issues scheduled. Prefer fixing in the shared component so every consumer benefits at once, then communicate and version the fix. Close the loop with prevention: add a regression test that reproduces the bug, update documentation and lint rules, and feed patterns back into reviews. Assign a clear owner or accessibility working group and report metrics like open issues by severity and time to remediate.

COMMON WRONG ANSWERS Describing only tools, not process. No severity or SLA model. No distinction between system bugs and consumer misuse. Fixing only the reporting product and leaving others broken.

LIKELY FOLLOW-UPS Who owns a regression when many products are affected? How do you prioritize against feature work? How do you prevent the same regression returning?

ONE CONCRETE EXAMPLE A user reports that the shared Dropdown traps focus. Triage marks it critical and locates the bug in the component, not the consumer. The team patches the component, releases a fix, and notifies all consumers. A regression test is added so the focus trap cannot reappear, and the audit checklist is updated.