Case Study: Accessibility Retrofit Under Deadline
Situation
A product team discovered late in launch that keyboard users could not complete a checkout-like workflow. The modal trapped focus inconsistently, errors were not announced, and a custom select had no reliable keyboard model.
Root cause
Accessibility was reviewed at page level after product behavior had already been encoded in custom components.
Architecture failure
- no shared dialog contract
- no form error announcement pattern
- custom select rebuilt native behavior without full keyboard support
- visual QA passed but interaction QA was missing
- deadline pressure pushed fixes into local patches
Better architecture
| Component | Required contract |
|---|---|
| Dialog | focus entry, trap, escape close, return focus, labelled title |
| Field | label, description, error association, invalid state |
| Select | native select where possible; otherwise complete keyboard model |
| Toast/alert | appropriate live-region announcement |
| Route change | focus management and heading structure |
Triage under deadline
- Block launch for any keyboard trap or impossible completion path.
- Replace custom select with native/selectable primitive if possible.
- Add error summary and field-level associations.
- Manually test keyboard and screen-reader happy path.
- Create follow-up to move local fixes into design-system primitives.
Lessons
- Accessibility retrofits are expensive because behavior has already spread.
- Page-level fixes do not scale.
- High-risk primitives need contracts before feature teams compose them.
- Deadline triage should distinguish launch blockers from follow-up hardening.
Source lens
Use Part VII accessibility contracts, inclusive component recipes, WCAG engineering practice, and the accessibility/design-system review packet.