WCAG 2.2 in the enterprise, without the slide deck.

WCAG is 78 success criteria. In an enterprise SaaS codebase, that’s approximately 78 debates.

The accessibility deck never survives contact with a release calendar. I’ve watched it happen three times: a brilliant designer presents the WCAG landscape; engineering nods politely; the next quarter ships three features that fail AA. The deck didn’t fail because the deck was wrong. It failed because nothing connected it to the work.

What does connect it is operational. Concretely:

• Encoding in the design system. Component-level accessibility — focus states, contrast tokens, keyboard formulas — has to live in the component. Not in a “guidelines” PDF. Not in a Slack thread.
• Lint in the code pipeline. axe-core or a similar tool, run on every PR, blocking on critical violations. This catches the things your eye misses.
• Audit before ship. Axe audits are not QA. They’re a checkpoint. Run them 48 hours before a release, on the actual feature branches that will ship, not on the demo environment.
• Disclose the status. Internal dashboard: feature X, audit state Y, last reviewed Z. Ship a “no criticals” tag externally somewhere; it matters more than it looks.

Operational is not aspirational. Operational is the difference between a values statement and a release. A values statement changes nothing; a release constraint changes everything.

The bigger lesson carried over to other domains: inclusive design isn’t a separate workstream. It’s a property of the system, like performance or security. Treat it like one.