The engineering leaders whose products actually stay accessible, quarter after quarter, release after release, are almost never the ones who scheduled the most trainings. Training is easy to point to in a slide deck. It is much harder to point to as the reason a product still works with a screen reader eighteen months later, after a dozen engineers have rotated through the team and nobody remembers the workshop.
What those leaders actually did was smaller and less visible than a training program, and it happened earlier. They moved the accessibility check from the end of the pipeline, where a QA pass either catches the problem or does not, back to the beginning, where the shared component was never broken to begin with. One decision, made once, instead of the same vigilance demanded of every engineer on every page for the life of the product.
That difference sounds subtle. It is not. It is the entire gap between an accessibility program that decays the moment attention moves elsewhere, and one that holds.
The Stat: Automated accessibility scanning catches roughly 57.38% of WCAG issues on its own, according to Deque's own published research - which means leaders who depend only on a late-stage QA scan are still missing a meaningful share of real issues, every single release. (Source: Deque)
The Training Trap
Training is not worthless. Every engineer benefits from knowing what a screen reader announces when a div is used where a button should be, or why a modal that does not trap focus properly strands a keyboard user inside a page they cannot escape. But training relies on every single person, on every single team, remembering that lesson at the exact moment they are writing a new component, months or years after the session ended.
That is a lot of weight to put on memory and goodwill. New hires join without the training. Contractors ship code without it. A tired engineer on a Friday afternoon, racing a deadline, is not thinking about focus order. Training scales attention. It does not scale enforcement.
Great engineering leaders noticed this early and stopped treating accessibility as a fact to be remembered. They treated it as a property to be engineered into the thing everyone already reuses.
Where the Failure Actually Gets Built In
Almost every accessibility bug that ships to production traces back to one of two places: a one-off implementation on a single page, or a shared component that was built without the check and then copied everywhere. The first kind is annoying but contained. The second kind is the one that does real damage, because it multiplies.
Consider WCAG 4.1.2 Name, Role, Value, a Level A success criterion that requires every interactive element to expose what it is, what state it is in, and what values it accepts, to assistive technology. A custom dropdown, a toggle switch, a tab panel: each of these needs the right role, the right name, and the right state communicated programmatically, not just visually.
Now ask: is it more efficient to verify that once, inside the shared Dropdown component that every team imports, or to re-verify it on every single page where a product team happens to build its own dropdown from scratch? The math is not close. A design system component gets used dozens or hundreds of times. Fix it once there, and every page that imports it inherits the fix for free, forever, with zero additional QA effort per page.
This is the actual mechanism behind "shift left." It is not a slogan about testing earlier in the sprint. It is a decision about where in the system the check lives.
Common Approach vs. What Actually Holds
| Stage | Common approach | What great leaders do instead |
|---|---|---|
| Design | Accessibility is a note in a Figma comment, easy to miss | Accessible states (focus, disabled, error) are baked into the component spec itself |
| Build | Each team re-implements interactive patterns their own way | Teams import a shared, pre-verified component from the design system |
| QA | A late-stage scan or manual pass tries to catch what slipped through | There is little left to catch, because the shared pattern was already correct |
| Result | Fixes are applied page by page, bug by bug, forever | One fix in the component library propagates everywhere it is used |
Neither column is about effort spent. Both take real engineering work. The difference is where that work is spent, and whether it compounds or resets to zero on every new page.
Why "Catch It in QA" Was Always Going to Leak
Even a well-staffed, well-intentioned QA process built around automated scanning has a hard ceiling. Deque's published research on automated accessibility testing coverage puts automated tools at catching roughly 57.38% of WCAG issues on their own. That is a genuinely useful number, and no serious accessibility program should skip automated scanning. But it also means that leaders who treat a passing scan as the finish line are, by design, missing a real portion of the issues that matter.
Fixing a pattern at the component level sidesteps this gap entirely for that pattern. You are not relying on a scanner to notice that the same broken dropdown exists on forty different pages. You are relying on the fact that there is only one dropdown, and it was correct before anyone had the chance to copy it wrong.
A Definition of Done That Actually Includes Accessibility
The leaders who make this stick do not add an "accessibility review" as an extra step tacked onto the end of a sprint. They fold specific, testable criteria into the same definition of done that already governs whether a component can be merged and published to the design system.
- Every interactive component exposes its name, role, and current state programmatically, matching WCAG 4.1.2
- Focus is visible and predictable for every interactive state, including custom controls
- The component works end to end using only a keyboard, before it is approved for the library
- Color is never the only signal for state (error, selected, disabled)
- A component cannot be published to the shared library without sign-off against this list, the same way it cannot be published without a passing unit test
Notice what is missing from that list: a reminder to "remember your training." The checklist does the remembering. The gate in the pipeline does the enforcing. No individual engineer has to be the hero who catches it, because there is nothing left standing that needs catching.
How to Know If It Is Actually Working
A definition of done is only real if someone is tracking whether it holds over time, not just at the moment a component ships. If you want the metric that actually reflects this shift rather than vanity numbers like training attendance, read the one metric that actually shows progress on this - it is the number that tells you whether your gate is holding or quietly eroding.
The teams that get this right also stop auditing pages one at a time and start auditing the system those pages are built from. A handful of components, checked properly, tell you more about the health of your entire product than a hundred individual page scans ever will.
If you lead an engineering org and you are still finding the same category of accessibility bug on page after page, the fix probably is not another audit of those pages. It is getting your design system audited, not just individual pages, an approach we build into our accessibility program for SaaS engineering teams, so the fix happens once, at the source, instead of every time someone reuses the pattern that was never actually fixed.
That is also the conversation worth having with us directly: we would rather help you audit the ten or twenty components your whole product is built from than chase the same bug across two hundred pages. If that sounds like where your team actually needs to start, talk to us about auditing your design system, not just your pages, or write to the team at experts@wcag.world and we will walk through what that would look like for your stack.