Accessibility is cheaper than the lawsuit and better than the alternative
WCAG 2.2 AA on every project, from the token layer up. It has won us two enterprise contracts and cost us about 4% of design time.
Su Myat Noe
Product Designer
We build to WCAG 2.2 AA on every project, whether the client asks or not. It is not a moral position we are asking you to admire — it is a cheap one, and the accounting is straightforward.
What it costs
About 4% of design time and maybe 2% of engineering, when it is designed in. Retrofitted, it is 15–20% and it is miserable, because most accessibility failures are structural — heading hierarchy, focus order, semantic elements — and structure is the expensive thing to change late.
What it has paid
Two enterprise contracts. Both had a VPAT requirement in procurement that eliminated the other shortlisted vendors. Neither client had mentioned accessibility in the brief; it appeared in the legal review, at which point it is a yes/no gate you cannot fix in the two weeks you have.
That is the pitch that works with skeptical clients, and it is true. But it is not the reason.
How we build it in
Contrast pairs as tokens. A foreground token is defined together with the background it is legal on. You cannot pick a failing combination because the token is the pair, not the colour. This deletes an entire class of late-stage findings.
Focus states designed, not defaulted. Every interactive element gets a designed focus ring in the design file. If it is not in the file, engineering invents one, and it will be a 1px outline nobody can see.
Semantic HTML as a review item. A <div onClick> fails code review. Not because of a rule, but because a button gets keyboard activation, focus, and a screen-reader role for free, and reimplementing those correctly takes longer than typing <button>.
Motion respects `prefers-reduced-motion`. Our animation tokens have a reduced variant. It is one media query and it means someone with a vestibular disorder can use the site without nausea.
Keyboard test every sprint. Unplug the mouse, complete the primary flow. Five minutes. It catches more than any automated tool, because the common failures are focus traps and illogical order, which axe cannot see.
What automated tools miss
Axe and Lighthouse catch maybe 30% of real issues. They will tell you an image lacks alt text. They will not tell you the alt text says "image1.jpg", that your modal does not trap focus, that your error message is announced before the field it refers to, or that your carousel autoplays past a screen-reader user before they finish the first slide.
Run them in CI so the mechanical failures never land. Then have a person use the thing with a keyboard and a screen reader, because that is where the actual answer is.
