Marrow

Client: Marrow, staff scheduling for hospitals. Team: two engineers assigned for the engagement. Engagement: six weeks, 2022. Role: accessibility audit and remediation.

The problem

A hospital contract required WCAG 2.1 level AA. An external audit had produced a 60-page report with 140 findings, a deadline and no plan. The engineers had never done accessibility work and the report did not tell them how.

What I did

Week one: triage. I grouped the 140 findings into eleven patterns. Most of the report was the same five problems repeated across screens: missing form labels, icon buttons with no name, a focus ring that had been styled away, modals that trapped nothing and announced nothing, and a colour palette with three contrast failures.

Weeks two to five: fix the patterns, not the findings. Each pattern was fixed once in the component library and the fix propagated. The engineers did the work; I pair-programmed, reviewed and tested with a screen reader. By week four they were finding issues I had missed.

Week six: the checklist. A fifteen minute pre-release checklist that catches most of what an audit would, written for engineers with no accessibility background. It is the one in the accessibility checks I run before every launch, lightly adapted.

What shipped

All 140 findings closed and verified by the external auditor. The contract was signed. The checklist is run before every release and the team's audit findings have stayed in single digits since.

"John fixed 140 accessibility issues with our engineers in six weeks and left us a checklist we still run before every release." Daniel Osei, Product lead.

What I learned

Fixing patterns in the component library is ten times faster than fixing findings on screens, and it is the only way the fixes survive. And engineers who have fixed an accessibility problem with a screen reader running do not create that problem again.