Craft · 12 September 2025 · 6 min read
What WCAG AA actually costs (and why it's worth it)
Two live e-commerce builds got us to WCAG AA. Here's what actually changed in the codebase — and in the workflow — to get there.
Accessibility work has a reputation for being a checklist you run at the end — alt text, contrast ratios, a Lighthouse score you screenshot for the report. Getting a live e-commerce site to WCAG AA taught me it's closer to a set of constraints you design with from the start, not a pass you bolt on.
The expensive part was never the obvious stuff — labelling inputs, fixing colour contrast, adding focus states. It was the components that looked fine visually but broke down under a screen reader or a keyboard-only pass: modals that trapped focus in the wrong place, carousels that announced nothing useful, filters that updated a product grid without telling assistive tech anything had changed.
What changed the workflow more than any single fix was treating accessibility review as part of code review, not a separate audit bolted on before launch. Once 'can you tab through this' became a normal question in a pull request, most of the expensive problems stopped shipping in the first place.
AA conformance on a live storefront is a real constraint, not a badge. It shapes how you write markup, how you structure state, and how much you can get away with hiding in a div with an onClick. I'd rather build inside that constraint than retrofit around it later.