Accessibility used to be treated as a checklist you ran through right before launch, if there was time. That approach does not hold up anymore. Digital accessibility lawsuits keep climbing year over year, screen reader and keyboard usage keeps growing, and clients increasingly ask for WCAG conformance in the brief itself rather than as an afterthought.
What Changed With WCAG 2.2
WCAG 2.2 added new success criteria focused on real friction points: clearer focus indicators, more forgiving drag interactions, larger and more consistent tap targets, and better protection against accidental form submission. None of it is exotic. All of it reflects how people actually navigate a site with a keyboard, a switch device, or low vision.
Why "Fix It Later" Fails
Retrofitting accessibility into a finished site is always more expensive than designing for it from the start, for the same reason retrofitting responsive design into a fixed-width site is expensive: the problems are structural, not cosmetic. Color contrast, heading structure, focus order, and form labeling are decisions baked into the design and markup, not settings you flip afterward.
Accessible design is not a constraint on good design. It is what good design looks like once you account for everyone who has to use it.
Building It In From Day One
- Design with real color contrast ratios from the first mockup, not just brand-approved colors
- Build a visible, logical focus order before a single line of JavaScript adds an interaction
- Write real alt text and form labels during content entry, not as a pre-launch cleanup task
- Test with an actual keyboard and screen reader, not just a browser extension score
The sites that handle this well are not the ones that bolt on an accessibility overlay before launch. They are the ones that treat accessible by default as a baseline requirement, the same way they treat mobile-responsive or fast-loading.
