Accessibility Is Not a Sprint Ticket

There is a ritual in our industry that everyone participates in and nobody defends. A site ships. A year later, an accessibility audit produces a two-hundred-row spreadsheet. A remediation sprint fixes the loudest rows. The spreadsheet is archived, the team moves on, and next year's audit finds two hundred new rows, because the process that generates inaccessible interfaces was never touched. Only its output was.

We stopped participating in this ritual. Not because audits are useless, but because remediation is where accessibility budgets go to be wasted. The leverage is upstream, and it is almost entirely an architecture question.

Make the right way the easy way

Here is the observation that reorganized our practice: developers do not ship inaccessible interfaces out of malice or even ignorance, mostly. They ship them because the inaccessible version is fewer keystrokes on a deadline. A div with a click handler is faster to write than a properly labeled, keyboard-operable disclosure widget, so under pressure, the div wins.

The fix is not exhortation. It is making the accessible version the shortest path. That means a component library where the hard problems, focus management, keyboard interaction, ARIA relationships, live announcements, are solved once by whoever knows them best, and every consumer inherits the solution for free.

// The team writes this...
<Dialog title="Remove item?" onConfirm={removeItem} />

// ...and never hand-rolls focus trapping, Escape handling,
// aria-modal, or focus return. The component owns all of it.

When we rebuilt Northwind's component layer this year, roughly a dozen primitives, dialogs, menus, tabs, toasts, form fields, accounted for the overwhelming majority of historical audit findings. Solve the primitives, and product teams stop being able to create most defects even when they are rushing. Rushing is a constant. Design for it.

The parts a library cannot solve

Honesty requires the second half of the story. Component-level accessibility handles mechanics, but three classes of problems stay stubbornly human:

• Content. No component enforces a meaningful heading hierarchy, alt text that says something, or link text better than "learn more." This belongs in the editorial workflow, with checks in the CMS, not in engineering.
• Flows. Every step of checkout can pass an audit while the whole remains bewildering with a screen reader. Only usage catches this, which is why our definition of done for critical paths includes completing the flow with VoiceOver and keyboard only. Fifteen minutes, most bugs found before any tool runs.
• Color and motion at the design layer. Contrast and reduced-motion behavior have to be decided in the design tokens, where they propagate everywhere, rather than negotiated screen by screen.

Automate the floor, not the ceiling

Our CI runs axe-core on every pull request, and it catches maybe a third of real-world issues, which matches the industry's honest estimates. That third is worth automating precisely because it is the tedious third. But treating a passing automated check as "accessible" is how teams end up with certified-compliant products that no actual screen reader user can operate. Automation sets the floor. Humans, ideally including disabled users in actual research sessions, set the ceiling.

The business case has gotten easier

If you need the pragmatic framing for stakeholders, 2022 has supplied it: web accessibility lawsuits continue climbing year over year, with e-commerce the most-sued sector, and holiday season is exactly when your riskiest, highest-traffic surfaces get the most scrutiny.

But the argument we actually believe is simpler. Something like one in four adults lives with a disability. Building interfaces a quarter of people struggle to use is not a compliance gap. It is a craft failure, and we are supposed to be craftspeople. The spreadsheet ritual let us feel diligent about that failure once a year. Architecture lets us stop committing it.