Cheap early, expensive as an afterthought

No, and we won't tell you it does. WCAG is a floor — a testable minimum that covers a wide range of access needs but not every one. Meeting it is necessary and often legally required, but it doesn't replace testing with real users across different assistive technology and disability types.

Automated scanners catch a fraction of WCAG issues — missing alt text, contrast ratios, missing labels. They can't tell you whether a screen reader announcement makes sense in context, whether focus order matches visual order, or whether a custom widget is actually operable. Manual and assistive-technology testing catches what scanning can't see.

Yes, though it costs more than building it in from the start. Structural decisions — how a modal traps focus, whether a table uses real markup or divs — get expensive to unwind once features are already built on top of them. We prioritize the fixes that unblock the most users first.

We audit the library first. If accessible behavior is fixed at the component level, every product using it inherits the fix at once. If it's not, each consuming team has been rebuilding the same workaround separately, and that's usually where the biggest wins are.

Regulated and public-sector buyers are the ones putting it in RFPs, but the underlying need doesn't stop there — any product a colleague or customer might navigate by keyboard or screen reader benefits from the same fixes. If your users are internal and few, this is a smaller priority than a public-facing product.