Accessibility is nonnegotiable infrastructure

[Share Article]

Most teams believe they are doing accessibility. They have a badge in the footer. A vendor contract is in place. An automated report indicates that everything appears acceptable. And yet, the web remains largely inaccessible.

In 2024, WebAIM analyzed the top one million homepages and found that nearly all still failed basic accessibility checks. That number has barely shifted over time. This persistence suggests that the failure is not about awareness. It is about ownership. Across multiple enterprise platforms I have audited, accessibility was present in documentation, vendor contracts, and compliance reports, yet absent in live use. The issue was never intended. It was where responsibility was placed.

The compliance paradox

We are currently in an era of peak tooling and peak failure. Organizations have never had more scanners, overlays, and audit partners than they do today, yet the user experience for individuals with disabilities remains fragile. This creates a paradox. Companies believe they are compliant because they are paying for compliance, while the actual product remains unusable.

Accessibility ownership is structurally diffuse. Designers build visual systems without semantic structure. Engineers inherit components that were never designed for keyboard use. QA teams test accessibility at the end, when foundational decisions are already locked in. Legal teams frame accessibility as risk mitigation rather than user experience.

The outcome is predictable. Accessibility becomes reactive instead of generative. Accessibility researcher Léonie Watson has noted that most failures are not caused by missing knowledge, but by broken processes and a lack of shared responsibility across teams. Accessibility does not fail at the guideline level. It fails at the system level.

Tools are signals, not solutions

Tools such as AccessiBe, UserWay, Siteimprove, and Axe exist for practical reasons. Teams need visibility, reporting, and benchmarks. Problems emerge when these tools are treated as substitutes for design decisions rather than inputs into them.

Deque Systems, the team behind Axe DevTools, states that automated testing typically identifies only about thirty percent of accessibility issues. The remaining majority, including keyboard navigation failures, confusing focus order, unclear error handling, and logical inconsistencies, requires human judgment rather than pattern recognition. When teams rely exclusively on automation, they optimize for passing reports instead of serving users.

I have witnessed teams treat overlay solutions as a finish line rather than a starting point. Once a badge appeared on the site, accessibility conversations often stopped, yet interaction patterns remained inaccessible. In some cases, overlay tools interfered with assistive technologies or exhibited inconsistent behavior across browsers. A visible accessibility badge signals intent, not outcome. The most effective teams treat these tools as inputs, not conclusions.

The design system imperative

If accessibility is not embedded in a design system, it will not survive scale. Design systems define how components behave, how content is structured, and how interactions repeat across platforms. When accessibility is absent from those foundations, teams are forced to patch problems repeatedly instead of preventing them in the first place.

In 2022, Microsoft reinforced this approach, noting that inclusive design must be integrated into product development workflows rather than treated as a specialized review phase. Internal research indicated that early accessibility consideration reduced downstream fixes and improved usability across products. Retrofitting accessibility is expensive. Designing for it from the start is simply more efficient.

The economic reality of exclusion

Inclusive design is not a charitable value add. It is a market expansion strategy. Exclusion is an operational cost. Approximately 1.3 billion people worldwide live with disabilities. When digital platforms fail to support assistive technologies, they artificially cap the audience they can serve.

The revenue implications of removing these barriers are documented. Following an accessible site redesign that improved structure and navigation, Tesco reported a 350 percent increase in online sales. Airbnb observed a 20 percent increase in bookings from customers using assistive technologies after upgrading its navigation features. These outcomes indicate that accessibility improvements reduce friction for a broad spectrum of users, driving conversion beyond the primary demographic.

While revenue represents the upside of inclusion, litigation is the lagging indicator of systemic failure. The legal landscape has shifted from warning letters to enforcement. The Domino’s Pizza Supreme Court case established a critical precedent. Digital presence is a public accommodation, and failure to provide access constitutes a violation of civil rights. Accessibility is no longer only a usability concern. It is an operational risk.

From verification to prevention

The maturity model for accessibility is shifting. Organizations are moving from asking how we prove we complied to how we prevent exclusion. This shift requires treating accessibility as a default design standard rather than an optional add-on.

Accessibility does not belong to specialists alone. It belongs to leadership. Creative Directors shape systems. Product leaders define scope. Engineering leaders enforce standards. When accessibility is treated as an external service rather than an internal expectation, it will always lag behind the product itself.

As interfaces become more dynamic and regulations tighten, approaching 2026, this distinction becomes unavoidable. Success will not be defined by tool adoption, but by ownership. Accessibility is not something you buy. It is something you build into the foundation of your work.

Like this article?

Subscribe to my newsletter

Get access to new and upcoming projects, new insights, and industry news straight to your inbox.

By signing up to receive emails from David Keyes, you agree to our Privacy Policy. Your information is treated responsibly. Unsubscribe anytime.

About

Article Insight

Accessibility is not a feature to be added; it is an outcome of system hygiene. This article explores why compliance checklists fail and how treating accessibility as a core architectural constraint improves quality for all users.

Article Sources
  • Robles v. Domino’s Pizza, LLC. No. 17-55504. United States Court of Appeals, Ninth Circuit. 2019.
    cdn.ca9.uscourts.gov/…
  • WebAIM. “The WebAIM Million: The 2024 Report on the Accessibility of the Top 1,000,000 Home Pages.” WebAIM, 2024.
    webaim.org/projects/million/
  • World Wide Web Consortium. “Web Content Accessibility Guidelines (WCAG) 2.1.” W3C Recommendation, 5 June 2018.
    w3.org/TR/WCAG21/
  • Robles v. Domino’s Pizza, LLC. No. 17-55504. United States Court of Appeals, Ninth Circuit. 2019.
    cdn.ca9.uscourts.gov/…
  • WebAIM. “The WebAIM Million: The 2024 Report on the Accessibility of the Top 1,000,000 Home Pages.” WebAIM, 2024.
    webaim.org/projects/million/
  • World Wide Web Consortium. “Web Content Accessibility Guidelines (WCAG) 2.1.” W3C Recommendation, 5 June 2018.
    w3.org/TR/WCAG21/

Related Articles