Your Accessibility Audit Is Finding Errors That Were Made Six Months Ago
A designer picks a text color against a light background. The contrast ratio is 3.8:1. WCAG AA requires 4.5:1 for normal text. Nothing flags it — not the design tool, not the design review, not the handoff. The color goes into the component. The component goes into the design system. The design system propagates to forty-seven places across the product. Six months later, an accessibility audit logs forty-seven contrast failures and assigns them severity: critical.
The fix for one decision took one afternoon. The fix for forty-seven decisions, after they've been implemented, tested, and shipped, takes weeks and touches half the codebase.
This is the shape of most accessibility debt. It doesn't accumulate in code. It accumulates in design files — and it's invisible there because the tooling that would catch it is wired to a stage that arrives after the damage is done.
The Same Failures, Every Year, For Five Years Straight
The WebAIM Million report analyzes the accessibility of the top one million home pages. The 2024 edition found that 95.9% had automatically detectable WCAG failures. The top categories: low contrast text (80.6% of pages), missing alternative text on images (54.5%), missing form input labels (48.6%).
These numbers are almost identical to the 2019 report. And the 2020 report. And every year since.
What makes this striking isn't the scale — though 95.9% is a staggering failure rate for a set of requirements that have been public since 1999. What's striking is the stability. If teams were treating accessibility as a thing to fix, the numbers would move. They don't move because teams are treating accessibility as a thing to audit — which means they're finding failures they're too late to fix cheaply, and the backlog never clears.
The audit is not the intervention. The audit is the receipt.
Where the Errors Actually Originate
Low contrast, missing alt text, missing form labels — these three failures account for a majority of detectable WCAG errors across the web. They also share a common origin: they're decisions made before a line of code is written.
Low contrast is a color pairing decision. It happens in the design file when someone chooses a palette, defines text styles, or designs a component with insufficient contrast between foreground and background. By the time the contrast ratio shows up in an audit report, it has already been committed to a design system token, propagated to every component that uses that token, implemented across every screen those components appear in, and tested with the wrong visual baseline by QA engineers who may not have had a contrast checker in their toolkit.
Missing alt text is a content decision. In many design systems, image placeholders exist in components without defined alt text conventions. The component ships. Developers implement it. Content teams populate it. Nobody in that chain was explicitly briefed that alt text is required and meaningful. The audit flags hundreds of instances of a pattern that should have been designed with a required alt field and documented as non-negotiable.
Missing form labels is a layout decision. Designers sometimes use placeholder text as the visible label for form fields, removing the persistent label to achieve a cleaner look. It looks fine in Figma. It fails WCAG 1.3.1 and 4.1.2. The label is gone before the component is built.
These aren't implementation errors. They're design errors that become implementation errors.
The Three Failure Modes and What Catching Them Early Looks Like
Low contrast. The fix at the design stage: Figma has a built-in contrast checker. Plugins like Able and A11y — Color Contrast Checker surface the ratio directly in the design tool. The standard for design review should include a contrast check on every new color pairing, every new text style, every new component — not as a final gate, but as a mandatory property visible in the component's documentation. When a color is added to the system, the contrast ratio against the standard background colors goes in the token spec alongside hex values and usage guidelines.
Missing alt text. The fix at the design stage: image components in the design system should carry documented requirements for alt text — not placeholder copy, but a field that developers and content teams know is required. When a component is designed with an image slot, the documentation notes what makes alt text meaningful for that context: is it decorative (alt=""), is it functional (describes the action it triggers), is it informational (describes the content of the image)? A component spec with this documented eliminates an entire category of implementation ambiguity.
Missing form labels. The fix at the design stage: placeholder-as-label is a known pattern and a known failure. When a design uses placeholder text as the only visible label, the design review should flag it. The conversation happens in the design file, not in the WCAG audit. The alternatives — persistent floating labels, visually-hidden labels paired with the input, above-field labels — are well-documented. Choosing one of them before the component ships is trivially cheap compared to retrofitting it after implementation.
What Shifting Left Actually Requires
"Shift left" has become design-process shorthand for catching problems earlier. In accessibility, it means moving the detection point from the audit to the design review — and ideally from the design review to the design tool itself.
This requires three changes that aren't technically complex but are organizationally resistant:
First, accessibility criteria need to be part of design review as explicitly as visual consistency or brand alignment. If the person running design review isn't checking contrast ratios and label presence, those checks aren't happening. They don't need to be deep; the automated checks on a mockup take under five minutes. But they need to be part of the process, not an optional add-on.
Second, design system documentation needs to include accessibility requirements at the component level. Not in a separate accessibility guide that nobody reads — in the component spec, alongside the visual specs, as a primary property. A button component spec that documents state styles but not the minimum contrast requirement for each state is an incomplete spec.
Third, developers need a brief for accessibility that arrives with the component, not a retroactive checklist. The handoff should specify required attributes, expected DOM structure for screen reader users, and any keyboard interaction requirements. When these arrive in the design annotation layer, developers implement them in the first pass. When they arrive in the audit report six months later, they're a refactor.
The Cost Calculation Nobody Does
Teams accept accessibility audits as a cost of doing business. They rarely run the calculation that the audit methodology makes inevitable.
When a WCAG failure is caught in the design file, the fix is a property change. When it's caught in the design review, it's a revision. When it's caught in QA, it's a bug fix. When it's caught in an accessibility audit post-launch, it's a regression with a severity label, a ticket, a sprint allocation, a developer, a re-test, and a re-audit.
The multiplicative cost of late detection in accessibility follows the same curve as every other software quality metric. An error found early is cheap. The same error found late is expensive. The distinction is that accessibility errors are rarely found early because the tooling for catching them early doesn't exist in most teams' workflows — not because the tools don't exist, but because nobody installed them or made them mandatory.
The WebAIM report documents the result: five years of stable failure rates at scale, across the industry, because the detection mechanism is wired to the wrong stage.
This is structurally identical to the database performance problems described in the previous post on missing indexes: invisible in development, expensive at scale, fixable cheaply only at the stage where nobody thought to look.
The audit tells you what the design file decided six months ago. The design file is where the decision should have been contested.
Photo by Anete Lusina via Pexels — a close view of design work in progress, where the decisions that reach users are made.