The accessibility program I'd build if I started over

Take a program away. Imagine it doesn't exist yet at the company you're at, no incumbent team, no half-built tooling, no political memory of an earlier attempt that went sideways. Just you, a real product, and the question of how you'd build the program from a blank page. Here's mine for accessibility.

The first move isn't to hire an accessibility specialist. It's to put one person inside the design systems team whose job description names accessibility as a primary responsibility, not as an extra they handle when the calendar permits. The reason is leverage. A specialist working outside the system's components ends up filing tickets against every team and chasing them quarter after quarter. The same person working at the component level fixes one button and quietly fixes every place that button appears in the product.

The second move is to refuse to ship a base component that isn't accessible. No exceptions. A modal without focus trap and return doesn't get a version number. A field component without an associated label pattern doesn't get exported. This sounds like an obvious rule and almost no team I've worked with keeps it, because shipping feels urgent and accessibility feels like the part you can come back to. You can't. The base components calcify; whatever they were on day one is what gets copied everywhere for the next three years.

The third move is the definition-of-done. Accessibility goes onto the list of release criteria before the first ticket gets cut, as specific checkable items: keyboard reachable, visible focus state, programmatic name, correct role, color contrast, motion that respects prefers-reduced. An engineer who has these on a card next to them can answer most of them in under a minute. The bottleneck is rarely time. It's almost always that nobody told them what to check, and they don't know what they don't know.

What does ownership look like in the clean version? One person who is the named owner, with the authority to file blocking bugs and halt a release. That person reports to someone who treats accessibility issues as product-quality issues, not as legal exposure. The distinction matters more than it should. A program run as a compliance hedge optimizes for documentation; a program run as quality optimizes for whether the product works.

What I'd skip

I'd skip the maturity model. They look reassuring on a slide and they tell you very little about whether your product is usable. By the time you're at "stage three" of someone's framework you've spent a year producing artifacts that describe accessibility instead of practicing it.

I'd skip the big upfront audit. The audit makes sense once the practice exists, as a measurement against an established baseline. Done first, the findings list becomes the program, and you spend a quarter fixing yesterday's bugs while the process that produced them keeps producing new ones.

I'd skip the "accessibility champions" structure too, at least early. Champions networks are a sensible response to a team that's too small to do everything centrally and too big to coordinate informally. At the start, when the team is small enough to coordinate informally, the champions structure adds meetings and slows decisions, and the people who would have been champions are more useful working directly on the components and the DoD.

What I'd front-load that almost nobody does

I'd put real disabled users in front of the team in the first month, as repeated plain exposure rather than as a usability study with a deliverable. The team watches someone navigate the product with a screen reader, with a keyboard only, with one hand, with cognitive fatigue. The point isn't to fix anything yet. It's to make the users specific before any patterns get committed to. The teams that sustain an accessibility practice are the ones where the engineers and designers can name a real person whose use of the product they care about. That's a cheap thing to set up and almost nobody does it before the patterns are already in place.

I'd also invest early in the engineer's local loop. Linting that flags missing alts and bad heading order in the editor. A pre-commit hook that runs axe on the changed files. A keyboard-only test mode in Storybook that's the default, not an option. The further down the loop you push the feedback, the less it costs to act on. Catching an accessibility issue in code review is fine; catching it before the commit is better; never letting it leave the editor is better still.

What stays the same

The audit eventually shows up. The remediation backlog eventually exists. The training curriculum eventually gets written. The clean-page version doesn't skip those; it gets to them in a different order, after the practice is real. By the time the first external audit lands, it's measuring residual issues against a process that's already producing accessible work, and the findings get treated as tuning rather than as the program itself.

The version of this program that holds up over years has the same shape whether you inherited it or built it new. It's built around components, anchored in a definition of done, owned by someone with authority, and grounded in specific users the team has actually met. The reason the clean-page version is worth thinking about is that doing the same things in the right order, with no debt to pay down, makes the whole thing two years faster.