The Accessibility Debt Multiplier - Why Design Systems Are Your Biggest WCAG Risk

It was a Tuesday afternoon when our QA lead dropped a message in Slack that stopped me mid-coffee. “Hey, I just ran the axe-core audit on the new checkout flow. It’s showing 847 violations.”

We had just spent six weeks building a brand new component library. Clean code, well-documented, Storybook stories for every component. The team was proud of it. And now, 847 violations.

I pulled up the report and felt that familiar sinking feeling. The violations were not random. They came from one place: a Button component we built in week one. It did not have proper aria-label handling for icon-only variants. That single gap had multiplied across 34 pages, inside 12 different product features, consumed by 6 different teams.

One component. One gap. 847 violations.

That day I named what I was looking at: the accessibility debt multiplier.

The Scale That Makes This a System Problem

WebAIM - a non-profit accessibility research organisation at Utah State University - runs an annual audit of the top one million website home pages. Their 2026 report found the average homepage contains 56.1 detectable WCAG failures. That figure jumped 10 percent in a single year.

The CDC’s 2022 Behavioral Risk Factor Surveillance System found that 28.7 percent of U.S. adults - roughly 70 million people - report having a functional disability. That is your user base. And according to WebAIM, those users encounter a failure on roughly 1 in every 24 homepage elements.

The accessibility problem is not getting smaller. It is getting worse faster than teams are fixing it. And most teams are looking for the solution in the wrong place.

Most teams think about accessibility violations the way they think about bugs: find one, fix one. That mental model works fine for standalone pages. It falls apart completely when you are building a design system.

In a design system, a component is not just a component. It is a template consumed across your entire product surface. When that template has an accessibility gap, the gap does not stay in one place. It travels with every import, every npm install, every copy-paste.

“A flawed component in a shared design system is not a bug. It is a policy.” — Sandeep Upadhyay, Principal Frontend Architect

One Component, One Gap, 847 Violations

Here is the concrete scenario most frontend teams will recognise. A design system team builds a Button component and ships it. The component works visually. It handles click events. It responds to hover states. But it has one gap: icon-only variants do not include an accessible label.

// The design system ships this
const Button = ({ icon, onClick, variant }) => (
  <button className={`btn btn--${variant}`} onClick={onClick}>
    {icon}
  </button>
);

// Teams use it throughout the product
<Button icon={<TrashIcon />} variant="ghost" onClick={handleDelete} />
<Button icon={<EditIcon />}  variant="ghost" onClick={handleEdit}  />
<Button icon={<ShareIcon />} variant="ghost" onClick={handleShare} />

Now imagine this pattern appears across 30 different features. Every team pulls the same component from the design system. Every instance has the same gap. The axe-core audit later reports 240 violations of the same type - not because 30 teams were careless, but because one component shipped without a required label prop.

The fix is not a patch on each usage. It is a correction at the API level, where accessibility compliance becomes enforced by TypeScript rather than remembered by developers:

// TypeScript enforces this - the build fails if label is missing
interface ButtonProps {
  icon: React.ReactNode;
  label: string;       // required, no default, not optional
  onClick: () => void;
  variant?: 'primary' | 'ghost' | 'danger';
}

const Button = ({ icon, label, onClick, variant = 'primary' }: ButtonProps) => (
  <button
    className={`btn btn--${variant}`}
    onClick={onClick}
    aria-label={label}
  >
    {icon}
  </button>
);

// Every usage now requires an accessible label
<Button icon={<TrashIcon />} label="Delete item" onClick={handleDelete} />
<Button icon={<EditIcon />}  label="Edit item"   onClick={handleEdit}  />
<Button icon={<ShareIcon />} label="Share item"  onClick={handleShare} />

The PR cannot merge without a label. The build enforces the standard. This is what it means to build accessibility into the component contract rather than audit for it afterward.

What Screen Readers Actually Experience

Before moving to more failure patterns, it is worth being specific about what users actually encounter when these gaps ship. Automated audits abstract this into violation counts. The reality is more direct.

WebAIM’s Screen Reader User Survey 10 (2024) puts JAWS at 40.5% of desktop screen reader users and NVDA at 65.6% overall usage - the most commonly used free option globally.

JAWS (Windows, used by 40.5% of desktop screen reader users): Encounters the unlabelled icon button and announces “button” with no context. In a data table with 20 rows and three ghost icon buttons per row, JAWS reads “button” sixty times. The user cannot complete the task.

NVDA (Windows, free, 65.6% overall usage): Falls back to “clickable” when no accessible name is present. The user knows something is interactive but has no idea what it does. Users typically give up after three or four attempts.

TalkBack (Android mobile): Announces “unlabelled button” explicitly - the most honest failure message of the three, but also the most clearly broken. On mobile, where touch targets are small and navigation is by swipe, a row of unlabelled buttons is a dead end.

VoiceOver (Apple macOS and iOS): Reads the child element type when no label exists. If the icon is an SVG, it announces “image, button.” Neither tells the user what the button does.

Automated tools catch none of this reliably. A component can pass every axe-core check and still be completely unusable by a screen reader user. Deque Systems research puts automated detection at 30 to 40 percent of real WCAG violations. The majority require manual testing with real assistive technology.

Two More Places the Multiplier Lives

The Button pattern is the most visible, but the multiplier shows up in two other component categories with equal frequency.

Focus management in composite components. Modals, drawers, dropdowns, and date pickers all need to manage keyboard focus programmatically. When they do not, keyboard and screen reader users cannot complete tasks inside them.

// Broken: modal opens but focus stays on the trigger button
const Modal = ({ isOpen, children }) => {
  // No focus management
  return isOpen ? (
    <div role="dialog">{children}</div>
  ) : null;
};

// Fixed: move focus in on open, return it on close
const Modal = ({ isOpen, children, initialFocusRef }) => {
  useEffect(() => {
    if (isOpen && initialFocusRef?.current) {
      initialFocusRef.current.focus();
    }
  }, [isOpen]);

  return isOpen ? (
    <div role="dialog" aria-modal="true" aria-labelledby="modal-title">
      {children}
    </div>
  ) : null;
};

When this ships without focus management, the JAWS user hears nothing change when the modal opens. Focus is still on the trigger button. Tab moves to the next element behind the modal, not inside it. They cannot reach the modal content at all.

Live region announcements on dynamic content. When a form error appears, a loading state resolves, or a success message shows, sighted users see the change. Screen reader users hear nothing unless it is explicitly announced.

// Broken: error is visible but silent to screen readers
const FormField = ({ errorMessage }) => (
  <div>
    <input type="email" />
    {errorMessage && <div className="error">{errorMessage}</div>}
  </div>
);

// Fixed: role="alert" announces the change immediately
const FormField = ({ errorMessage }) => (
  <div>
    <input type="email" aria-describedby="email-error" />
    <div
      id="email-error"
      role="alert"
      aria-live="polite"
      className="error"
    >
      {errorMessage}
    </div>
  </div>
);

Without the live region, the user submits a form, the error appears visually, and the screen reader announces nothing. They do not know the form failed. On checkout or account creation flows, this is a direct task failure for the segment of users who need it most.

Why Overlays Do Not Solve This

Accessibility overlay widgets - third-party scripts that promise automated WCAG compliance - are sometimes positioned as a shortcut past this work. The evidence on outcomes is not favorable.

In 2024, 25 percent of all digital accessibility lawsuits explicitly cited overlay widgets as barriers rather than solutions, according to UsableNet’s year-end report. In January 2025, the Federal Trade Commission ordered accessiBe to pay $1 million after finding the company made misleading claims that its AI-powered overlay tool could fully automate ADA and WCAG compliance. The FTC found these claims were false and that the tool frequently introduced new barriers for screen reader users rather than removing existing ones.

The reason overlays fail at this scale is the same reason automated audits fail: they work on rendered output, not on the structural gaps baked into component APIs. An overlay cannot make an unlabelled icon button announce correctly if the component’s API never accepted a label prop in the first place.

Build Accessibility Into the Component Contract

The three failure patterns above share one structural property: the gap exists at the component API level. The fix must live at the same layer.

Required props over optional attributes for accessibility-critical fields. If a component needs an accessible name, that name is a required prop. TypeScript enforces it. The PR cannot merge without it. This is not a lint rule or a guideline - it is a hard build constraint.

Keyboard interaction built into the component, not left to consuming teams. If a modal should trap focus, that logic belongs in the modal component. If a dropdown should navigate with arrow keys, that behavior belongs in the dropdown. Consuming teams should not be able to get this wrong because they should not be responsible for implementing it.

Playwright accessibility assertions in the component test suite. Keyboard navigation, focus order, and ARIA correctness tested on every PR. The ARIA Authoring Practices Guide defines the expected keyboard behavior for every major widget type - these patterns are testable and should be tested.

Manual screen reader testing before any component ships. JAWS on Windows. NVDA on Windows. VoiceOver on macOS. TalkBack on Android. At minimum, JAWS and VoiceOver - the two environments with the most divergent behavior. No automated pipeline replaces this. It is 20 minutes per component, done once, before the component reaches any consuming team.

“The question is not whether your components are accessible - your audit will tell you they are. The question is whether they are accessible when real users navigate them with the tools those users actually own.” — Sandeep Upadhyay, Principal Frontend Architect

The Real Cost of the Multiplier

Seyfarth Shaw LLP’s 2025 ADA Title III report documented 8,800 ADA Title III complaints filed in federal courts in 2024 - a 7 percent increase over 2023. Website accessibility cases accounted for 36 percent of all ADA Title III filings in 2025. Settlements typically run between $5,000 and $75,000 per case, not counting legal fees.

The IBM Systems Sciences Institute found - in research cited across the software quality field for decades - that fixing a defect after product release costs up to 100 times more than catching it during the design phase. Deque Systems puts the average cost of a single production accessibility defect at $800 or more.

On a design system where one flawed component produces violations across 20 features, those numbers stack. Emergency remediation across 12 product teams for a single component gap costs more, takes longer, and damages user trust in ways that do not appear in any audit report.

The math on shift-left accessibility is straightforward. A 20-minute manual screen reader test before a component ships versus a three-sprint remediation cycle after it does. The only question is which planning meeting the conversation happens in.

The Test to Run This Week

Pull up your most-used component - the one that appears in the most places across your product. Run it through axe-core. Then manually tab through it with a keyboard only. Then open JAWS or NVDA and try to use it without touching the mouse.

If anything breaks in either pass, you have found your multiplier. And now you know exactly where to start.

The component that ships clean multiplies zero violations. The component that ships with one gap multiplies every time another team imports it. That asymmetry is the entire argument for building the accessibility standard into the component API - not because it is the right thing to do in the abstract, but because it is the only approach that actually controls the math.

---

All statistics are sourced from publicly available reports by recognised research institutions: WebAIM (Utah State University), CDC (2022 BRFSS), Seyfarth Shaw LLP (ADA Title III 2025), UsableNet (2024 Lawsuit Report), Deque Systems, and IBM Systems Sciences Institute (via TPGi/Vispero). Figures are paraphrased and cited per standard journalistic and academic practice.