How to design for accessibility without slowing the team down

Accessibility slows a team down for exactly one reason: it gets treated as a phase at the end instead of a property of the work. Bolt it on after the design is signed off and the build is done, and yes, it is slow, because now it is a retrofit, and retrofits are always slow. Build it into the foundations and the day-to-day workflow, and it costs almost nothing per screen, because the expensive decisions were made once, early, when they were cheap.

I have argued the philosophy of this elsewhere, in a piece on treating accessibility as a budget you spend from the start. This is the practical companion to it: not why, but where the time actually goes, and how to arrange the work so accessibility stops being the thing that holds up a release.

Where the time actually goes

Watch a team that finds accessibility slow, and the time is almost never in the accessible version of a thing. It is in the redo. Someone ran an audit late, the audit came back with fifty contrast failures and a keyboard trap, and now every one of those has to be traced back through components that were built without any of it in mind. The fix touches shipped code, needs re-testing, and lands right when everyone wanted to launch. That is the slowness people blame on accessibility, and it is really the slowness of doing it twice.

The accessible version of a button, a form field, or a color choice, made the first time, takes about as long as the inaccessible version. A contrast-passing color pair is not harder to pick than a failing one; it is the same decision with one extra check. A focus style is not more work than no focus style once it lives in the component. The cost is only real when you skip it and pay it back with interest later.

Build it into the foundations, once

The single highest-leverage move is to push accessibility down into the foundations, where a decision made once applies to everything built on top. This is the same reason foundations exist at all, and I have written separately about what belongs in a design system before the first component. Accessibility belongs in that same early layer.

Contrast goes into the palette. When you define your colors as roles, you check each text-on-surface pair against the WCAG contrast minimums at the same time, and record the passing pairs as the approved ones. After that, nobody picks a failing combination, because the failing combinations were never in the system to pick. I did this for SeniorConnect, a platform whose readers are over fifty, where legible is not a nice-to-have but the entire point, and the contrast pairs were settled before a single screen existed.

Focus and states go into the components. Decide once what focus looks like everywhere, what disabled means visually and for a screen reader, and how error is signaled with more than color. Every component built afterward inherits those answers instead of reinventing a subset of them. The states are where accessibility usually leaks, so naming them up front closes the most common gap before it opens.

And semantic structure goes into how you build, not into a later pass. A real button element, a real heading order, a real label tied to its field: these are free at build time and expensive to graft on afterward. Using the right element from the start is the cheapest accessibility work there is, because the browser does most of it for you.

Put the checks where the work happens

The other half of not slowing down is moving the checks left, so problems surface while they are still one-line fixes rather than release-blocking audits.

Automated checks belong in the pipeline. A linter for accessibility issues and an automated contrast check catch a real share of problems the moment code is written, at the desk, before review. These tools do not catch everything, but the things they catch are exactly the tedious, mechanical failures that pile up into a scary audit if left alone. Catching them continuously means the audit at the end is small, because the big pile never formed.

Keyboard testing belongs in everyday review. Not a special event, just a habit: tab through the thing you built before you call it done. Can you reach everything, in a sensible order, and see where you are? That thirty-second pass during development prevents the keyboard traps that are miserable to find and fix once they are buried in a shipped flow.

Manual and assistive-technology testing still matter, and they are where a specialist's time is well spent, but they should be confirming a design that was built right, not discovering that it was not. When the foundations carry contrast, the components carry states, the markup is semantic, and the pipeline catches the mechanical failures, the human testing at the end is short and mostly passes. That is the whole trick to speed: arrange the work so the late, expensive checks have very little left to find.

Common questions

Does this need a dedicated accessibility specialist? It helps to have one for the manual and assistive-technology testing, but the foundation and workflow work is done by the same designers and developers already on the team. The point of pushing it early is that it stops being a separate specialist phase and becomes part of how everyone works.

We already shipped without any of this. Now what? Then you do have a retrofit ahead, and it will take real time once. Do it foundation-first anyway: fix the palette and the shared components, which propagates the most fixes for the least work, before chasing individual screens. Then adopt the workflow so the next thing you build does not join the backlog.

Is WCAG AA enough? For most products, meeting WCAG 2.1 AA is the right target and the one that lines up with common legal and procurement expectations. Treat it as the floor you build in from the start, not the ceiling you reach for at the end.

The short version

Accessibility is slow only as a retrofit. Move contrast into the palette, states into the components, and semantics into the markup, and you have made the expensive decisions once, cheaply. Move the mechanical checks into the pipeline and keyboard testing into everyday review, and the audit at the end shrinks to almost nothing. None of this is a phase you bolt on. It is a set of choices about where the work lives, and made early, it costs the team close to zero.

If you want this arranged properly for a product rather than described in the abstract, foundation-level accessibility and audits are part of my design and accessibility work, and the SeniorConnect case study shows what building this way from the brand up actually looks like.