Why Accessibility Is Hard to Scale (And What to Do About It)

Accessibility is hard to scale because it is distributed: across components, content, vendors, and teams. A single checkout flow might involve design system primitives built by the platform team, form validation written by the product team, payment processing from a third-party vendor, error messaging defined by content ops, and testing done by QA. Each handoff is an opportunity for accessibility to break. Each team has different priorities, different knowledge levels, and different tooling.

Scale requires standardization and automation that ends in source code remediation. Without shared components that encode accessibility, every feature team solves the same problems independently—or doesn't solve them at all. Without CI gates, every release can introduce regressions. Without production monitoring, drift goes undetected. WebAIM's 2024 Million report found 95.9% of home pages have detectable WCAG failures, with an average of 56.8 errors per page. If accessibility were easy to scale, the internet wouldn't look like this.

Audits find problems; infrastructure prevents them. The organizations that achieve accessibility at scale don't do it through larger audit budgets or more compliance staff. They do it by building accessibility into the factory: accessible primitives, pipeline enforcement, production monitoring, and continuous remediation. This article examines the six factors that make scaling hard and the infrastructure approaches that address each.

Key Takeaways

Understanding why accessibility is hard to scale enables organizations to build systems that address root causes.

• Distributed responsibility is the core challenge – Accessibility fails at interfaces between design, engineering, content, QA, and vendors; no single team owns the complete outcome
• Component reuse is double-edged – Accessible components scale benefits; inaccessible components scale harm across every feature using them
• Dynamic state creates interaction complexity – SPAs, modals, and live updates require coordinated focus management that doesn't happen by default
• Interpretation variance multiplies confusion – Teams disagree on how to apply WCAG; different tools produce different results; consistency requires explicit standards
• Infrastructure beats audits at scale – Audits are snapshots that generate backlogs; infrastructure prevents issues and catches drift continuously

The Reality Check: The Web Is Still Failing

Before examining why accessibility is hard, consider the evidence that it is hard.

WebAIM's 2024 Million analysis tested one million home pages and found:

• 95.9% had detectable WCAG failures
• Average of 56.8 errors per page
• Most common failures: low contrast (81%), missing alt text (54%), missing form labels (48%), empty links (45%)

These aren't exotic edge cases. They're fundamental issues—text contrast, image descriptions, form labels—that have been understood for decades. If accessibility scaled easily, these patterns would have disappeared years ago.

The persistence of basic failures despite widespread awareness suggests systemic barriers, not knowledge gaps. Organizations know they should have alt text. The question is why they don't, at scale, across their entire digital presence.

The Six Scaling Problems

Accessibility faces six distinct scaling challenges. Each requires different solutions, and most organizations encounter all of them.

Problem #1: Surface Area Explosion

Modern digital products have enormous surface area:

+-------------------+----------------------------------------------------+
|    Surface Type   |                   Scale Example                    |
+-------------------+----------------------------------------------------+
|       Pages       | E-commerce: thousands to millions of product pages |
+-------------------+----------------------------------------------------+
|     Templates     | Dozens of page types (product, category, article, account, etc.) |
+-------------------+----------------------------------------------------+
|     Components    |    Hundreds of UI components in design systems     |
+-------------------+----------------------------------------------------+
|   Content items   |  CMS with thousands of images, documents, videos   |
+-------------------+----------------------------------------------------+
|   User journeys   | Many paths through navigation, search, checkout variants |
+-------------------+----------------------------------------------------+

Manual review of this surface area is mathematically impossible. If a manual accessibility review takes 30 minutes per page, reviewing 10,000 pages takes 5,000 person-hours. By the time you finish, the first pages have changed.

Scale requires automation and sampling strategies that can assess surface area efficiently. Testing every page with human review isn't feasible, but testing every template and monitoring production can provide coverage.

Problem #2: Component Reuse (Double-Edged Sword)

Component-driven architecture is standard practice. React, Vue, Angular, and Svelte applications build UIs from reusable components. This is efficient for development—but creates multiplicative effects for accessibility.

When components are accessible:

• Build accessibility once, benefit everywhere
• Consistent patterns across the product
• Reduced per-feature engineering effort

When components are inaccessible:

• A broken modal appears in every feature using modals
• A form input without label support creates hundreds of inaccessible forms
• Fixing the issue requires updating all instances

TestParty research based on Court Listener data found that 77% of website accessibility lawsuits target e-commerce businesses—organizations with large surface areas and extensive component reuse. A single inaccessible product card component creates accessibility barriers across thousands of product pages.

The scaling solution: invest heavily in accessible component primitives. Make the design system the source of accessibility truth. When the modal component handles focus correctly, every modal in the product handles focus correctly.

Problem #3: Dynamic State and Interactivity (SPAs)

Server-rendered pages had simpler accessibility models. Navigation refreshed the page. Focus returned to the top. Screen readers announced the new page.

Single-page applications (SPAs) break this model:

• Route changes don't refresh the page
• Focus must be explicitly managed
• Dynamic content updates need live region announcements
• Modal and drawer interactions require focus trapping
• State changes need ARIA attribute updates

+------------------------+-------------------------------------+-----------------------------------+
|    Dynamic Pattern     |      Accessibility Requirement      |           Common Failure          |
+------------------------+-------------------------------------+-----------------------------------+
|    Route navigation    |   Announce new page, manage focus   |   Silent navigation, focus lost   |
+------------------------+-------------------------------------+-----------------------------------+
|     Modal dialogs      |     Trap focus, return on close     |      Focus escapes, no return     |
+------------------------+-------------------------------------+-----------------------------------+
|      Live updates      |    Announce changes via aria-live   |        Updates unannounced        |
+------------------------+-------------------------------------+-----------------------------------+
|   Expandable content   |         Toggle aria-expanded        |       State not communicated      |
+------------------------+-------------------------------------+-----------------------------------+
|     Loading states     |       Announce loading/loaded       |        Users wait unknowing       |
+------------------------+-------------------------------------+-----------------------------------+

These aren't optional enhancements. They're requirements for keyboard and screen reader users to understand what's happening. But SPA frameworks don't enforce them by default. The W3C ARIA Authoring Practices Guide documents correct patterns, but implementation is left to developers.

Problem #4: Multi-Team Ownership

Accessibility breaks at organizational interfaces. No single team owns the complete user experience:

Design team:

• Creates visual mockups
• May or may not specify interaction patterns
• May or may not consider AT behaviors

Frontend engineering:

• Implements components
• Interprets design intent
• May not have accessibility training

Content team:

• Creates copy, uploads images
• Structures content in CMS
• May not know what "alt text" means

QA:

• Tests for visual correctness
• May not test with AT
• May not have AT available

Product management:

• Defines requirements
• Prioritizes backlog
• May not include accessibility criteria

Legal/compliance:

• Sets policy targets
• Reviews audit reports
• Doesn't implement fixes

At each handoff, assumptions are made. Design assumes engineering will handle keyboard navigation. Engineering assumes design specified focus behavior. QA assumes someone already tested with a screen reader. Content assumes the template handles accessibility. No one is wrong individually; the system is wrong collectively.

The scaling solution: explicit ownership, defined interfaces, and shared accountability. Platform team owns primitives. Product teams own their journeys. Everyone has accessibility in their definition of done.

Problem #5: Third-Party Dependencies

Modern web applications embed third-party services extensively:

+--------------------+-------------------------------------+--------------------------------+
|      Category      |               Examples              |     Accessibility Control      |
+--------------------+-------------------------------------+--------------------------------+
|      Payments      |        Stripe, PayPal, Square       |   Limited (iframe isolation)   |
+--------------------+-------------------------------------+--------------------------------+
|        Chat        |       Intercom, Drift, Zendesk      |   Limited (vendor-dependent)   |
+--------------------+-------------------------------------+--------------------------------+
|   Authentication   |      Auth0, Okta, social logins     |            Limited             |
+--------------------+-------------------------------------+--------------------------------+
|     Analytics      |   Tracking pixels, session replay   |   May inject inaccessible UI   |
+--------------------+-------------------------------------+--------------------------------+
|     Marketing      |       Forms, pop-ups, banners       |       Often inaccessible       |
+--------------------+-------------------------------------+--------------------------------+
|        Maps        |         Google Maps, Mapbox         |            Limited             |
+--------------------+-------------------------------------+--------------------------------+
|      CAPTCHA       |         reCAPTCHA, hCaptcha         |    Notoriously problematic     |
+--------------------+-------------------------------------+--------------------------------+

You can't fix third-party code. Your options are limited:

• Choose accessible vendors (requires evaluation during procurement)
• Provide accessible alternatives (fallback flows)
• Report issues to vendors (slow, uncertain)
• Replace inaccessible vendors (expensive, disruptive)

Third-party dependencies create accessibility exposure you don't control. The checkout flow is only as accessible as the payment form, and the payment form comes from a vendor who may or may not prioritize accessibility.

Problem #6: Content Operations

Accessibility isn't just code. It's content:

• Images need meaningful alt text
• Documents need accessible structure
• Videos need captions and transcripts
• Headings need logical hierarchy
• Links need descriptive text

Content operations often happen outside engineering workflows. A marketing team uploads a campaign banner. A product manager adds a PDF spec sheet. A content editor creates a help article. None of these trigger code review, CI checks, or accessibility testing.

CMS workflows that don't enforce accessibility produce inaccessible content at scale. If uploading an image doesn't require alt text, images will be uploaded without alt text. If publishing a PDF doesn't require accessibility review, inaccessible PDFs will be published.

The scaling solution: accessibility enforcement in content workflows. Required alt text fields. Heading structure validation. Document accessibility checks. Content guidelines with examples.

Why "More Audits" Doesn't Scale

The common response to accessibility failures is more audits: annual audits become quarterly, quarterly become monthly, scope increases. But audits don't scale.

Audits Are Snapshots

An audit captures state at a moment. The day after the audit, the site changes. Content updates. Features ship. Third parties release updates. The audit becomes historical rather than actionable.

Audits Generate Backlogs

Audit findings become tickets. Tickets go into a backlog. The backlog competes with feature work. New issues are found before old issues are fixed. The backlog grows.

Audits Don't Prevent Recurrence

Fixing a missing label in response to an audit finding doesn't prevent the next developer from creating another missing label. Audits identify symptoms; they don't address causes.

W3C Acknowledges the Limitation

W3C guidance on evaluating accessibility emphasizes that evaluation involves both automated testing and human review, and that accessibility should be integrated throughout the development process—not relegated to periodic audits. The guidance explicitly positions evaluation as ongoing, not one-time.

Interpretation Variance as a Hidden Factor

Teams disagree about what WCAG requires. Different tools report different issues. Auditors have different interpretations. This variance creates confusion that impedes scaling.

Tool Disagreement

Run three accessibility scanning tools against the same page. You'll often get three different sets of findings. Tools implement different rule sets, different sensitivity levels, and different interpretations of success criteria.

Auditor Disagreement

Send the same page to three accessibility auditors. You'll get three reports that overlap but don't match. Some issues are clear-cut; others involve judgment about what "sufficient" means.

The ACT Rules Effort

The W3C ACT Rules Community Group exists specifically to harmonize interpretation of WCAG for testing purposes. The existence of this effort acknowledges that interpretation variance is a known problem requiring coordination.

Scaling Implication

When teams can't agree on what "accessible" means, they can't systematically achieve it. Some interpret standards strictly; others loosely. Components pass one team's review but fail another's. Inconsistency undermines confidence and makes automation difficult.

The scaling solution: explicit internal standards that translate WCAG into component checklists and acceptance criteria. Your modal must do X, Y, Z. Your form must have A, B, C. Specificity reduces interpretation variance.

The Scalable Solution: Componentize Correctness

The path to scale is making accessibility a property of components, not pages.

Accessible Primitives

Create accessible versions of every common pattern:

+----------------+----------------------------------------------------+
|   Primitive    |               Accessibility Included               |
+----------------+----------------------------------------------------+
|     Button     | Accessible name required, keyboard activation, disabled state |
+----------------+----------------------------------------------------+
|   Form input   | Label association required, error announcement, required state |
+----------------+----------------------------------------------------+
|     Modal      |     Focus trap, escape to close, focus return      |
+----------------+----------------------------------------------------+
|      Menu      |      Keyboard navigation, arrow keys, escape       |
+----------------+----------------------------------------------------+
|      Tabs      |    Tab/panel association, arrow key navigation     |
+----------------+----------------------------------------------------+
|   Accordion    |       Expand/collapse state, keyboard toggle       |
+----------------+----------------------------------------------------+

When primitives are accessible, features built from them inherit accessibility. A product team building a checkout flow uses the accessible form components, modal component, and button component. They get accessibility without thinking about ARIA.

ARIA Authoring Practices as Reference

The W3C ARIA Authoring Practices Guide documents correct patterns for custom widgets. Use these as the specification for your component implementations. When building a combobox, follow the APG combobox pattern. When building a dialog, follow the APG dialog pattern.

One Fix, Many Benefits

Component-level fixes scale:

• Fix the modal focus behavior once → All modals work correctly
• Fix the form input labeling once → All forms are labeled
• Fix the button keyboard handling once → All buttons activate correctly

This contrasts with page-by-page remediation where each fix helps only one page. Component remediation is multiplicative; page remediation is additive.

Scaling Through Pipelines

Pipelines prevent regressions automatically. CI gates ensure that new code can't degrade the accessibility baseline.

Prevention Over Detection

Linting catches issues at code-writing time. A developer writes a button without an accessible name; the linter flags it immediately. The issue never reaches code review, never reaches CI, never reaches production.

Gating on Regressions

CI checks should block PRs that introduce accessibility regressions:

• New critical violations → Block merge
• New high violations → Require justification
• Baseline violations → Track, don't block (address separately)

This creates a "ratchet" effect: accessibility can improve, but can't easily degrade.

Monitoring Catches What Escapes

CI can't catch content drift or third-party changes. Production monitoring complements pipeline gating by watching for drift introduced outside the PR workflow.

Scaling Through Remediation

The biggest scaling mistake is treating accessibility as a ticket queue. Issues come in, tickets go out, developers work through the backlog page by page.

Why Ticket Queues Don't Scale

• Fix one page, another breaks
• No root cause addressing
• No prevention of recurrence
• Backlog grows faster than paydown

The Scalable Approach

Remediation should:

• Fix root causes in components
• Add regression tests to prevent recurrence
• Update lint rules to catch the pattern
• Document the fix for future reference

When you fix a button accessibility issue, you don't fix it on 50 pages. You fix the button component and add a lint rule that prevents the pattern from recurring. The 50 pages improve automatically, and page 51 can't have the same issue.

Organizational Scaling

Technical infrastructure alone isn't enough. Organizational design determines whether infrastructure gets built and maintained.

Platform Owns Primitives

A platform or design system team should own accessible component primitives. This centralizes accessibility expertise and ensures consistency across products.

Product Teams Own Journeys

Product teams own the accessibility of their user journeys. They use platform primitives and are responsible for correct composition and content.

Compliance Defines Targets

Legal/compliance defines accessibility targets (WCAG 2.1 AA, etc.) and evidence requirements. They don't implement solutions—they specify expectations.

Clear Interfaces

+---------------------------+------------------------------------------------+
|         Interface         |                 Responsibility                 |
+---------------------------+------------------------------------------------+
|     Platform → Product    |   Accessible components, clear documentation   |
+---------------------------+------------------------------------------------+
|     Product → Platform    |         Bug reports, feature requests          |
+---------------------------+------------------------------------------------+
|   Content → Engineering   |   Content requirements, workflow constraints   |
+---------------------------+------------------------------------------------+
|   Compliance → Everyone   |    Standards, evidence needs, risk context     |
+---------------------------+------------------------------------------------+

When interfaces are clear, gaps are visible. When they're ambiguous, everyone assumes someone else handles accessibility.

FAQ

Why can't we just hire more accessibility specialists?

Specialists help, but they don't scale linearly. One specialist can't review every PR or audit every page. Specialists should focus on high-value activities: training, pattern development, complex issue resolution, AT testing. The bulk of accessibility work must be distributed to feature teams using accessible infrastructure.

How do we handle third-party accessibility issues?

Document accessibility requirements in vendor procurement. Evaluate third parties before adoption, not after. When issues exist, report them to vendors with specific WCAG references and timelines. Have fallback plans for critical journeys (alternative flows that work if the vendor doesn't). Consider accessibility in vendor renewal decisions.

What if different teams interpret WCAG differently?

Create internal standards that translate WCAG to specific implementation requirements. "Button must have accessible name" is ambiguous. "Button component requires label prop; label must be non-empty string; see component docs for usage" is specific. Internal standards reduce interpretation variance across teams.

How long does it take to build accessibility infrastructure?

Initial foundation (lint rules, basic components, CI checks) can be established in weeks. Comprehensive design system coverage takes months. Mature operations with monitoring, governance, and continuous improvement evolves over quarters. The key is incremental progress—don't wait for perfect infrastructure to start.

Is accessibility scaling easier for smaller organizations?

Smaller organizations have less surface area but also fewer resources. The principles are the same: accessible components, CI enforcement, monitoring, clear ownership. Smaller teams can move faster but must be more deliberate since there's no specialized accessibility team to catch issues.

What metrics show we're scaling accessibility successfully?

Track: regression rate per release (should approach zero), mean time to remediate (should decrease), percentage of components in accessible design system (should increase), issues caught in CI vs. production (CI ratio should increase). These metrics indicate infrastructure health and scaling progress.

Related Resources

Internal Links

• Accessibility as Infrastructure, Not a Feature
• Accessibility Technical Debt Explained
• The Role of CI/CD in Accessibility
• Why Accessibility Is a Software Engineering Problem
• How Continuous Compliance Works
• What "Shift Left" Means for Accessibility

External Sources

• WebAIM Million 2024 Report
• W3C ARIA Authoring Practices Guide
• W3C ACT Rules Community Group
• W3C WAI: Evaluating Web Accessibility
• W3C WAI: Planning and Managing Accessibility
• CDC 2024 Disability Statistics

This article was written by TestParty's editorial team with AI assistance. All statistics and claims have been verified against primary sources. Last updated: January 2026.