State of Accessibility - May 19, 2026
You Cannot Bolt On What Should Be Built In
Digital accessibility keeps getting treated like a problem you can solve at the end. Scan the site, slap on a widget, check a box. But the evidence tells a different story. Accessibility that works is accessibility that starts at the foundation. Everything else is expensive theater.
The HHS Section 504 Rule: Medical Access on the Line
On May 9, 2024, the U.S. Department of Health and Human Services published a sweeping update to its Section 504 regulations—the first major rewrite in nearly fifty years. The rule mandates that patient-facing digital systems (websites, mobile apps, patient portals, kiosks) conform to WCAG 2.1 Level A and AA. It also prohibits hospitals from rationing emergency care or denying organ transplants based on ableist assumptions about quality of life, requires diagnostic equipment to be physically accessible, and mandates community-integrated care over forced institutionalization.
This is not a web standards conversation. It is a medical civil rights rule.
For kiosks—the self-check-in terminals in hospital lobbies—the rule leans on the European ICT standard EN 301 549, since the U.S. has no unified kiosk accessibility standard. That means built-in speech output, tactile cues, volume controls, and keyboard navigation. Providers cannot reroute disabled patients to a staffed line where they have to disclose personal health information out loud in a crowded room.
The Timeline Shift
Original compliance deadlines were May 11, 2026 (15+ employees) and May 10, 2027 (smaller organizations). On May 7, 2026, HHS extended both by one year, citing the financial burden on rural and smaller providers.
But the underlying non-discrimination obligations remain enforceable now. The extension changes when formalized audits become the basis for punitive action. It does not narrow the technical scope or roll back any requirements. Organizations that treat the extension as permission to wait are misreading the situation.
The Threat
The entire 2024 update is in danger. An Interim Final Rule has been submitted through the Office of Information and Regulatory Affairs, bypassing normal notice-and-comment procedures. If this IFR eliminates the 2024 provisions, there is no fallback. Unlike the DOJ's Title II web accessibility rules, which sit on decades of case law and settlement history, the HHS rule was designed to fill gaps where no litigation safety net exists. If it goes, those protections vanish.
The Exemptions
The rule includes five narrow exemptions under Section 84.85: archived content no longer in active use; legacy documents created before the compliance date (unless still actively used); third-party content not under contract; password-protected individualized documents (with accessible alternatives on request); and pre-existing social media posts (new posts must comply). None of these are broad escape hatches.
Overlays: The 54% Failure Rate
Accessibility overlays—third-party JavaScript widgets that claim to detect and fix accessibility violations after page render—remain one of the most aggressively marketed and technically broken products in the space.
The fundamental problem is architectural. Modern UI frameworks (React, Angular, Vue, Svelte, Lit) own the DOM. They are the single source of truth for structure, state, and event handling. An overlay that injects ARIA attributes post-render is fighting the framework on every re-render cycle. Attributes get erased. Event handlers get detached. State gets reverse-engineered from CSS class names instead of read from the application, meaning a routine class rename silently breaks the remediation layer.
Karl Groves tested this systematically: 29 React components, 292 intentional accessibility errors. The overlay layer fixed 46%. The remaining 54% either could not be fixed at all (12%) or broke silently under normal rendering conditions (42%). The failures fall into three buckets:
You cannot convert a <div> into a real <button> from outside the framework without destroying event delegation. Using role="link" instead of a native <a> tag strips context menus, middle-click behavior, and URL previews. Color-only status indicators cannot be fixed for color-deficient sighted users without injecting visible elements that break the layout.
Type-ahead navigation in complex grids, auto-play pause controls, click-to-close behaviors on modals—these require orchestration that an external script cannot perform without destabilizing the framework's event bubbling.
Navigation matrices that cost O(rows × columns) per keystroke. State inferred from inline CSS strings. Simulated mouse events dispatched based on bounding rectangles that return zero-width during load. Fixes that appear to work in testing and fail in production.
And this is React, the best-case scenario. Angular's Zone.js pushes estimated failure rates to 55–60%. Lit and Web Components use Shadow DOM encapsulation, making up to 75% of the application unreachable by any external script.
The Cost Trap
Overlays are sold as the affordable option. The data says otherwise.
The subscription buys a partial, fragile fix that vanishes the moment the contract lapses. The remediation buys a permanent architectural correction.
The Privacy Problem
To automate user settings, overlays often detect whether assistive technologies are running on the user's machine. This exposes the medical fact that a user has a disability, without their consent. Some overlays deposit tracking cookies across unaffiliated domains. The Overlay Factsheet—signed by hundreds of accessibility experts from Apple, Microsoft, Google, and others—documents these GDPR and CCPA violations in detail.
What Users Actually Think
Among respondents with disabilities, the ineffectiveness rating rises to 72%. Users report hijacked Tab keys, prices announced as headings, and screen readers producing nonsensical output. Many block overlay domains entirely via their operating system's HOSTS file.
Shift Left or Pay Later
If overlays are a dead end, what works? The short version: you cannot audit your way into accessibility culture. Audits are lagging indicators. They evaluate outcomes, not the decisions that produced them.
The alternative is embedding accessibility into the earliest stages of the development lifecycle. During planning, accessibility becomes part of acceptance criteria and the definition of done. During design, color palettes and interaction patterns are validated against WCAG constraints before a single line of code is written. During development, tools like @accesslint/jest run accessibility checks at the component level during local commits, catching semantic HTML violations and missing ARIA labels before code reaches the main branch.
When prevention absorbs the bulk of basic defect detection, audits return to their proper role: a final validation pass that catches complex cognitive edge cases rather than cataloging avoidable structural failures.
Design Constraints as Creative Tools
Color Contrast and Subjective Perception
WCAG contrast ratios are not arbitrary restrictions. Human color perception varies dramatically—not just physiologically (color deficiency) but cognitively. Research by Dr. Patrick Mineault, whose "Is My Blue Your Blue?" test drew over 1.5 million interactions, demonstrated that people categorize the boundary between green and blue completely differently. The same hex code reads as "green," "blue," or "teal" depending on who is looking.
Because perception is subjective, design systems need objective mathematical boundaries. UCLA's approach is instructive: a definitive color contrast comparison matrix that cross-references brand colors and marks failing combinations with a red "DNP" tag. Tools like the Directed Edges Contrast Grid and Michael Herchel's Contrast Grid (which parses raw CSS variables and Sass maps directly) move this validation to the start of the design process, where it generates creative friction instead of expensive rework.
Target Size and Touch Physics
WCAG 2.5.8 addresses the physical mechanics of interaction. The rule is geometric: every interactive element must accommodate a 12-pixel radius circle from its center, and that circle must not overlap with any adjacent control's circle. Minimum functional footprint: 24×24 CSS pixels. A row of tight 16-pixel icons on a mobile toolbar may look clean, but it penalizes users with motor tremors, reduced dexterity, or larger fingers.
WCAG 2.5.7 extends this to dragging movements. Dragging requires sustained, coordinated pressure—impossible for users with a broken wrist, chronic motor impairments, or single-switch navigation hardware. Every drag-and-drop operation needs a click-based alternative. Swipe-to-delete without a checkbox fallback is not a UX decision. It is an exclusion decision.
Link Labels
"Click here" is useless to screen reader users navigating via an extracted link list. It is useless to sighted users scanning a page. And "click" is anachronistic on touch interfaces. Links must be self-sustaining: "Change your avatar" beats "To change your avatar, visit the profile page" with a partial link buried somewhere in the sentence.
Sustainability and the Hardware Lifecycle
Up to 81% of the carbon emissions from a consumer device like an iPhone occur during manufacturing, not daily use. The most impactful environmental intervention a software team can make is extending the useful life of existing hardware by reducing CPU and GPU strain.
Design system optimizations that accomplish this: event debouncing and throttling to prevent CPU spikes during scroll and resize, requestAnimationFrame and hardware-accelerated CSS transforms instead of layout recalculations, list virtualization to render only visible DOM nodes, aggressive font subsetting or system font defaults to cut network payloads, and dependency pruning to replace bloated libraries with native browser APIs. These savings propagate across every product built on the system.
Accessible Gaming as Proof of Concept
If the argument is that accessibility constrains what you can build, RetroRapid is a counterexample. Built by Daniel Devesa Derksen-Staats (an engineer whose accessibility work started at the BBC), this LCD-style racing game ships natively on watchOS, iOS, iPadOS, and macOS. It assigns distinct musical notes to driving lanes so visually impaired players can dodge traffic through spatial audio. Input is fully abstracted: touchscreen taps, directional swipes, hardware keyboard, Apple Watch Digital Crown, with game controller support planned. It works natively with VoiceOver, scales with Dynamic Type, and adapts to Dark Mode.
This is a fast-paced arcade game. If accessibility can be built into the architecture here, the argument that it compromises "real" products does not hold.
Presence vs. Participation
All of this technical and regulatory work serves a single purpose: closing the gap between being somewhere and actually participating.
Elin, a visually impaired football fan, attended a Women's Euro match between Wales and England in St. Gallen, Switzerland. She was physically in the stadium, wearing her Wales bucket hat, surrounded by a crowd. But the audio descriptive commentary was available only in German, and the radio broadcast ran 30 to 60 seconds behind real time. She learned about goals, fouls, and scorers long after they happened, guessing at the action based on crowd noise.
She was present. She was not participating.
Contrast this with venues like Wrexham's Racecourse or Everton's Hill Dickinson Stadium, where real-time audio description conveys immediate player movements, expressions, and tactical shifts. The technology is not exotic. It transforms a bystander into a participant.
The pattern repeats across digital environments. Group chats where photos have no alt text. Documents available only in inaccessible formats. Questions directed to a disabled person's companion instead of to them. The systemic expectation that a disabled person will notice the absence of accessibility, spend energy complaining, and then wait for the retrofit. This conditions people to treat exclusion as the default.
The Bottom Line
Post-production overlays are architecturally hostile to modern frameworks, legally dangerous for privacy, and more expensive over time than fixing the source code. The HHS Section 504 rule ties digital accessibility directly to life-saving medical equity—and that rule is under active threat. Design constraints around color contrast, touch targets, and input modalities are not aesthetic compromises; they are engineering specifications rooted in the physical and cognitive diversity of actual users.
The work is structural. It starts at planning, gets validated in design, gets tested during development, and gets confirmed—not discovered—during audits. The alternative is building systems where disabled people are technically present but functionally excluded, then wondering why the lawsuits keep coming.