DEV Community: Sergi Sánchez

The accessibility tree is the new API

Sergi Sánchez — Wed, 15 Apr 2026 10:51:27 +0000

There is a function call that every major AI browsing agent makes before it can do anything useful on a web page:

page.accessibility.snapshot()

It returns a JSON tree. Not the DOM, not a screenshot, but the accessibility tree: roles, names, states, and relationships, stripped of all visual styling.

{
  "role": "WebArea",
  "name": "Checkout",
  "children": [
    {
      "role": "main",
      "children": [
        { "role": "heading", "name": "Your order", "level": 1 },
        { "role": "textbox", "name": "Email address" },
        { "role": "textbox", "name": "Card number" },
        { "role": "button", "name": "Pay now" }
      ]
    }
  ]
}

That is what an AI agent sees when it looks at your checkout page. Not pixels, not CSS classes, not a visual rendering. Roles and names. It is also, almost exactly, what a screen reader sees. The same data structure, built for two entirely different audiences, thirty years apart.

The same tree, two consumers

The accessibility tree was designed in the 1990s to give assistive technologies a structured way to understand user interfaces. Browsers build it from HTML semantics and ARIA attributes, screen readers like NVDA and VoiceOver traverse it to announce what is on screen, and platform APIs on every operating system expose it to any program that asks. For thirty years, the primary audience was assistive technology users: a population measured in the low millions, often underserved, and almost always treated as an edge case by the teams building the products they needed to use.

Then AI agents started browsing the web. OpenAI's Operator, Anthropic's computer use, Google's Project Mariner, Microsoft's Copilot Vision, and the open-source libraries that power thousands of custom agents all faced the same problem: they needed a machine-readable representation of web pages. The first approach was screenshots, and screenshots turned out to be slow, expensive in tokens, and fundamentally ambiguous. A button that says "Submit" on screen is just a rectangle of pixels until the model guesses correctly.

The accessibility tree already had the answer. Every button has a role, every input has a name, every landmark has boundaries. The entire semantic structure of the page, in a format that fits in a few hundred tokens instead of the thousands required by a screenshot or a full DOM dump.

So they used it. browser-use, the open-source agent framework with over 85,000 GitHub stars, calls page.accessibility.snapshot() as its primary observation method. Its tagline is literally "Make websites accessible for AI agents." Microsoft's Playwright MCP reads the accessibility tree as structured YAML, deliberately choosing accessibility data over visual rendering for their browser automation standard. rtrvr.ai built a DOM Intelligence Library on ARIA roles and achieved an 81% success rate on WebBench, ahead of every screenshot-based approach tested, with screenshot-based agents taking two to three seconds per action while DOM-based agents operate in sub-second time.

The testing industry arrived at the same conclusion years earlier. Playwright's recommended locator strategy is not CSS selectors, not XPath, not test IDs — it is getByRole('button', { name: 'Submit' }), querying the accessibility tree directly. Testing Library adopted the same priority independently. Both frameworks chose accessibility semantics because they are more stable than CSS classes, survive refactoring, work across frameworks, and implicitly assert that the element is accessible. If the locator fails, either the element does not exist or it is not accessible — the test failure is an accessibility bug report. AI agents are now making the same architectural choice, for the same reasons.

The infrastructure that was built for people who cannot see the screen turns out to be the best interface for machines that do not have eyes at all.

What breaks when the tree is broken

A study by AgentLens found that 68% of websites had barriers preventing AI agents from completing basic tasks like submitting a contact form or browsing products. The agents are already visiting, and most sites are already failing them.

The failure patterns will look familiar to anyone who has tested with a screen reader. An <input> without a <label> appears in the accessibility tree as { role: "textbox", name: "" }: a screen reader says "edit blank" and moves on, and an AI agent has no idea what to type. A <div class="dropdown" onclick="toggle()"> does not register as an interactive element in the accessibility tree at all, which means a screen reader cannot operate it and an AI agent does not know it exists. Without <nav>, <main>, and <aside>, the accessibility tree is flat: screen reader users cannot jump between regions, and AI agents cannot distinguish navigation from content.

A CHI 2026 paper measured the gap from the other direction. Their AI agent succeeded on 78% of standard tasks, but when users relied on assistive technology like screen magnifiers or keyboard-only navigation, that rate collapsed to 28%. The agent could handle the page, but it could not handle the page the way people with disabilities actually use it. The accessibility layer was not just an interface for the agent; it was the shared ground between the agent and the user.

<!-- Invisible to both screen readers and AI agents -->
<div class="btn" onclick="submit()">
  <div class="btn-icon"><svg>...</svg></div>
</div>

<!-- Visible to both -->
<button type="submit" aria-label="Submit order">
  <svg aria-hidden="true" focusable="false">...</svg>
  Submit order
</button>

The fix for the AI agent is the same fix for the screen reader user. It has always been the same fix.

The triple win has data behind it

There used to be three separate arguments for structuring your HTML well: accessibility for disabled users, SEO for search engines, and usability for everyone. They were always the same argument wearing different hats, and now the data is catching up.

According to Adobe Digital Insights, AI-driven traffic to US retail sites from platforms like ChatGPT and Perplexity surged 4,700% year-over-year by mid-2025. An analysis of over 15,000 AI Overview results found that content scoring high on semantic completeness was 4.2 times more likely to be cited than content that buried its meaning in unstructured prose. A SEMrush study of 847 websites found that over 73% of those that implemented accessibility improvements saw measurable increases in organic traffic, with an average gain of 12%.

Google has said it directly: structured data is "critical for modern search features because it is efficient, precise, and easy for machines to process." Microsoft's NLWeb project, led by R.V. Guha, the creator of Schema.org, takes this further by turning schema-marked-up content into AI-queryable data, with every NLWeb instance doubling as an MCP server. Search engines, screen readers, and AI agents all parse the same semantic layer. They always did. The difference is that the audience just scaled from millions to hundreds of millions.

The market multiplier

Screen reader users worldwide number in the low millions. That has been the accessibility market for thirty years: important, underserved, and easy for executives to deprioritise when the budget conversation starts.

ChatGPT alone reported over 200 million weekly active users in mid-2024, and by early 2026 that number is approaching a billion. Even a small fraction of those users delegating tasks to agents means tens of millions of agent sessions per week interacting with real websites, far more than the entire global screen reader population. Add Operator, Mariner, Copilot, and the open-source ecosystem, and the number of non-human consumers of your accessibility tree is about to dwarf the number of human ones. Gartner predicts that by 2028, 33% of enterprise software will include agentic AI, up from less than 1% in 2024.

This is not a hypothetical. Shopify's CEO has been publicly building toward what he calls "agentic commerce": AI agents shopping, comparing, and purchasing on behalf of consumers, with Shopify launching Agentic Storefronts and a Universal Commerce Protocol with Google. Perplexity launched AI-powered shopping in late 2024 and expanded it with direct checkout through PayPal in 2025. Amazon hired Adept's founding team and licensed its technology, a company whose entire thesis was autonomous web browsing. If an AI agent cannot parse your product page, it cannot recommend your product. If it cannot fill your checkout form, it will fill a competitor's. The same economics that drove SEO adoption in the 2000s will drive accessibility adoption in the 2020s, not out of virtue, but because the checkout page that works for agents gets the sale.

The W3C is already asking the question that follows from this. They held sessions in March and November 2025 on how AI agents will change the web platform, debating whether ARIA, designed for human assistive technologies, is sufficient for machine agents or whether the web needs a new semantic layer entirely. The early consensus is that ARIA already covers most of what agents need. The infrastructure has been here for years. The question is whether sites bother to implement it.

The accessibility tree was built for people who cannot see. It is becoming the way machines see the web. The teams that invested in one are accidentally ready for the other.

The in-house illusion: why hiring an accessibility lead isn't a compliance strategy

Sergi Sánchez — Wed, 08 Apr 2026 10:35:00 +0000

A Forbes Tech Council post this week put a number on something the industry has been quietly avoiding. Accessibility settlements typically run $25,000 to $100,000 per case, before legal fees, executive time, and the remediation work that has to happen anyway as part of any settlement.

That's the bill. The interesting question is who keeps writing the cheque.

It's almost never the company without an accessibility programme. It's the company that has one.

The reassuring hire

The pattern goes like this. Legal flags exposure. A board member reads an article. Someone forwards a link about the European Accessibility Act. The response is to hire an accessibility lead, or appoint a champion from the existing team, or stand up a working group.

The role gets a title. The title gets a slide in the all-hands. The slide reassures everyone that accessibility is being managed.

This is the in-house illusion. The work of managing accessibility, the meetings, the audits, the quarterly reports, starts to feel indistinguishable from the work of being accessible. They are not the same thing. One produces calendar invites. The other produces compliant software.

One person, every pull request

Pick any reasonably active codebase. Count the pull requests merged last month. Now imagine one person manually reviewing each one for keyboard traps, focus order, contrast ratios, ARIA misuse, heading hierarchy, form labelling, reflow behaviour, motion sensitivity, and the forty other things WCAG 2.2 actually asks for.

They can't. Nobody can. The work scales with the codebase, not with headcount.

So the accessibility lead does what any reasonable person would do. They prioritise. They focus on the highest-risk surfaces. They run quarterly audits. They write a style guide. They train the team. They do all the things a single human can do, and the codebase keeps shipping, and most of what ships never gets reviewed by them at all.

Then a settlement letter arrives, and the question from the board is: "But we hired someone for this. What happened?"

What happened is that hiring a person was never going to be enough. The work needed a system.

Where the lawsuits actually live

The gap between "we have an accessibility programme" and "every merge is compliant" is where the $25k to $100k cheques get written. We've written before about the enforcement gap, the space between an AI finding issues and being able to prove they were fixed. The in-house illusion is the same gap, dressed up in headcount.

A team with an accessibility lead and no enforcement pipeline is in the exact same legal position as a team with neither. The audit log doesn't say "but we tried." The plaintiff's lawyer doesn't care that there was a champion. The regulator wants to know which components were checked, when, against what criterion, and whether the fixes were verified. If the answer lives in the head of one person who reviewed twelve PRs out of three hundred, there is no answer.

This is the part the Forbes piece gets right and most internal accessibility programmes get wrong. Settlements aren't priced on intent. They're priced on outcomes that can be evidenced, or the absence of them.

What a pipeline looks like

The companies not getting sued aren't the ones with the biggest accessibility teams. They're the ones who moved the work out of a single role and into the build itself.

That looks like rules running on every pull request, not in a quarterly audit. It looks like findings going into a tracked system the moment they're detected, not into a chat transcript that disappears at the end of the session. It looks like fixes being verified against criteria before they merge, not waved through because someone said they were done. And it looks like an audit trail that exists by default, because every step of the cycle wrote to it automatically.

The accessibility lead, in this version, isn't the bottleneck. They're the person who designs the pipeline, decides what the rules should be, handles the 40% of issues that genuinely need human judgement, and presents the evidence when someone asks for it. They're a force multiplier instead of a single point of failure.

The compliance framing

The other thing the Forbes piece does, almost incidentally, is reframe the conversation away from accessibility-as-virtue and towards accessibility-as-risk-management. This is the framing executives actually respond to. Nobody opens a budget meeting saying "make us more accessible." They open it saying "make us compliant with the law."

That's not cynicism. It's how compliance gets funded. And it's why the in-house illusion is so dangerous. A virtue framing tolerates "we're trying our best." A risk framing doesn't, because the cheque amount is the same whether you tried or not.

Compliance isn't a role. It's a pipeline. The role is what designs and runs the pipeline, but the pipeline is what produces the evidence that keeps the settlement letters in the drawer.

Try it

Look at your last twenty merged pull requests. For each one, ask: who reviewed it for accessibility, against which criteria, and where is that record stored?

If the answer is "our accessibility lead, when they have time, and it's in their head," the illusion is in the room.

Jeikin is what we built to close that gap. Every PR gets the same review. Every finding gets tracked. Every fix gets verified. The accessibility lead stops being the bottleneck and starts being the person who proves it works.

Hiring someone to care about accessibility is a good first step. Treating that hire as the strategy is where the cheques start getting written.

The enforcement gap: why finding issues was never the problem

Sergi Sánchez — Wed, 08 Apr 2026 10:32:14 +0000

Eightfold, a talent intelligence platform, recently shared something remarkable: they used AI agents to achieve WCAG 2.2 AA compliance in two months. The same work would have taken six to ten months manually.

The headline is impressive. But the interesting part isn't how fast they found the issues. It's what happened after they found them: every fix was reviewed by humans, verified against criteria, and tracked through to completion. The AI did the finding. A system did the enforcement.

Most teams trying the same approach today will get the first part right and miss the second entirely.

Everyone is shipping accessibility agents

The landscape changed fast. In the last few months alone:

An open-source project called Community Access released 57 accessibility agents for Claude Code, GitHub Copilot, and Claude Desktop. They enforce WCAG 2.2 AA by intercepting every prompt and delegating to specialist reviewers.
BrowserStack launched accessibility DevTools that lint code in real time, detecting WCAG violations before a commit even happens.
Deque shipped an axe MCP server, connecting their scanning engine directly to AI coding assistants.
Siteimprove published a framework for what they call "agentic accessibility," where AI agents handle compliance tasks autonomously.

The pattern is clear: accessibility tooling is moving into the places where code is written. The era of running a separate scan after the fact is ending.

This is genuinely good. AI coding agents are better at finding structural accessibility issues than most developers working from memory. They don't forget to check heading hierarchy. They don't skip alt text on the fifteenth image. They apply rules consistently, across every file, every time.

Finding issues is a solved problem. The hard part was never finding.

What happens after finding

Here's the question nobody is answering well: once the AI finds 40 accessibility issues in your codebase, then what?

The AI fixes them. Some of them. In this session. And tomorrow, a new conversation starts with no memory of what happened. A different developer runs a different agent and gets a different set of findings. Nobody knows which issues from Tuesday were actually resolved. Nobody knows if the fixes introduced new problems. Nobody can produce a list of what was reviewed and when.

This is the enforcement gap: the space between "an AI found issues" and "we can prove those issues were fixed, verified, and tracked."

It shows up in three specific ways.

Fixes without verification

An AI agent adds aria-label="navigation" to a <nav> element. Is that the right label? Does it conflict with an existing aria-labelledby? Does the computed accessible name make sense in context? The AI made a change and moved on. Nobody checked whether the change actually improved anything.

Automated scanning tools can verify some of these fixes. APCA can check contrast ratios against perceptual thresholds. axe-core can validate the rendered DOM. But if these verification steps aren't connected to the fix workflow, they don't happen.

Findings without persistence

Every AI coding session starts from zero. The agent doesn't know that it found a keyboard trap in the modal component last Wednesday, that a developer partially fixed it on Thursday, or that the fix broke focus management in a different component on Friday.

Without persistent tracking, the same issues get rediscovered, re-reported, and re-fixed. Or worse: they get found once, partially addressed, and forgotten.

Evidence without structure

A compliance officer asks: "Which components were reviewed for accessibility? When? What issues were found? Were they resolved?"

If the answer lives in chat transcripts scattered across multiple AI sessions, it's not evidence. It's archaeology.

Why this matters now

Since June 2025, the European Accessibility Act has been in active enforcement across Europe. The penalties are real and vary by country: up to €250,000 in France, up to €600,000 in Spain, with some member states allowing consumers to initiate civil proceedings directly. In the US, ADA lawsuits continue to climb. The UK Equality Act already covers digital services.

The regulatory question has shifted from "should products be accessible?" to "can you demonstrate that they are?"

"We use AI agents that follow WCAG rules" is a statement about intent. Regulators want evidence of outcomes: what was checked, what was found, what was fixed, how it was verified. That requires a system, not a prompt.

What closing the loop looks like

The teams getting this right share a common pattern. They don't just find issues. They enforce a cycle:

Find. AI agents and automated scanners identify accessibility barriers in the code. Static analysis catches structural issues. Runtime scanning catches rendered DOM issues. Guided review handles the 40% that resists automation entirely: focus order, cognitive load, content reflow, color vision accessibility.

Report. Every finding goes into a persistent tracking system with the specific WCAG criterion, the affected component, the severity, and a plain-language explanation of who is impacted. Not a chat transcript. Not a terminal log. A structured record.

Fix. The developer (or the AI, with guidance) addresses the issue. The fix is scoped to the specific finding, not a vague "make it accessible" pass.

Verify. The fix is checked against quality criteria. Did the contrast ratio actually improve? Does the screen reader announce the correct label? Does keyboard navigation work through the component without traps? If the verification fails, the issue stays open.

Evidence. The entire cycle is preserved. What was found, when, by whom, how it was fixed, whether it passed verification. This is what an auditor can review. This is what survives team changes, deadline pressure, and the six months between audits.

Skip any step and the gap reappears. Find without report means invisible work. Fix without verify means false confidence. Verify without evidence means unprovable compliance.

The WCAG 3.0 signal

The W3C published a new Working Draft of WCAG 3.0 in March 2026, introducing 174 new outcomes. The shift from "success criteria" to "outcomes" isn't just naming. It reflects a move toward measuring results, not just checking boxes.

WCAG 3.0 won't be finalized until 2028 at the earliest. But the direction is clear: the next version of the world's accessibility standard will ask not just "does this element have an alt attribute?" but "does this content achieve an accessible outcome for the people who use it?"

That's an enforcement question, not a finding question. And it makes the gap between "AI found issues" and "we can prove outcomes" even wider for teams without a system to close it.

The landscape converging

Something interesting is happening. The accessibility tool market and the AI coding tool market are merging.

Deque, the biggest name in accessibility scanning, ships an MCP server. Community Access builds agents that run inside coding assistants. BrowserStack adds real-time accessibility checking to their DevTools. TestParty embeds remediation into GitHub workflows.

At the same time, MCP itself is maturing. The ecosystem hit 97 million monthly SDK downloads. Marketplace platforms like MCP-Hive are adding billing layers for commercial tool servers. The infrastructure for connecting AI agents to specialized tools is becoming production-ready.

The teams that treat accessibility as something the AI handles "by default" will discover the gap when a regulator or client asks for evidence. The teams that connect their AI to an enforcement system will have the answer ready.

Try it

Ask your AI coding assistant to review a component for accessibility. It will probably find real issues. Now ask it: which components have already been reviewed? What was found last week? Can you show me the evidence?

The silence after those questions is the enforcement gap.

Closing it is what turns "we care about accessibility" from a claim into a fact.

I'm building Jeikin, an accessibility compliance tool that works inside AI coding agents. Instead of overlays or separate audits, it checks your actual code and tracks evidence on a dashboard. Try it with npx jeikin.

Accessibility belongs where developers already work

Sergi Sánchez — Mon, 30 Mar 2026 11:51:58 +0000

A developer I spoke with recently said something that stuck with me: "I can just add accessibility rules to my CLAUDE.md. Why would I need a tool for that?"

He's right that you can. You can write "follow WCAG AA" in your AI instructions and your coding assistant will try. It will add alt text sometimes. It will use semantic HTML when it remembers. It will suggest aria attributes in contexts where it has seen them before.

But try this: ask the same AI to review a codebase for accessibility tomorrow. It won't remember what it found yesterday. Ask it whether a fix it applied last week actually passed. It can't tell you. Ask it to prove to your compliance officer that every component was reviewed. There's nothing to show.

Instructions without enforcement are suggestions. And suggestions don't survive deadlines, team changes, or the EAA inspector who shows up asking for evidence.

The enforcement gap

Since June 2025, the European Accessibility Act has been in active enforcement. France issued legal notices to four major retailers within days. Penalties reach up to three million euros or 4% of annual revenue. The ADA lawsuit count in the US keeps climbing. The UK Equality Act already covers websites.

The question for development teams has shifted from "should we care about accessibility?" to "can we prove we do?"

And that's where the gap appears. An AI coding assistant can write accessible code. But it can't track what it reviewed, verify that fixes actually passed quality checks, or produce an evidence trail for an auditor. Those are system-level capabilities, not instruction-level ones.

The difference matters. "We told our AI to follow WCAG" is not compliance evidence. "Here's a dashboard showing 86 criteria evaluated, 12 issues found, 12 fixes verified" is.

What the AI sees versus what it misses

WCAG 2.2 has 86 success criteria across four levels. Some are things AI handles well: structural issues like heading hierarchy, missing alt text, buttons without labels. A well-prompted AI catches these reliably.

But many criteria resist automation entirely. Focus order only shows up at runtime. Contrast ratios depend on computed styles, not source code. Keyboard traps require simulating tab traversal. Content reflow at 320px needs a real viewport. Color vision accessibility requires simulating what deuteranopia, protanopia, and tritanopia actually look like.

The industry is converging on a layered approach. Static analysis (ESLint rules, code patterns) catches about 30% of issues. Runtime scanning (axe-core against the rendered DOM) adds another 30%. The remaining 40% requires guided human review: reading order, cognitive load, sensory characteristics, orientation handling.

No single tool covers everything. The question is how these layers coordinate.

The workflow that actually works

We've been thinking about this problem for months, and we keep arriving at the same conclusion: accessibility tools need to be invisible. Not invisible in the sense of overlays that hide problems, but invisible in the sense that the developer never switches context.

Today we shipped Jeikin to two places where developers already spend their time.

In the editor

The Jeikin extension for VS Code connects your AI coding assistant to a compliance system. Install it, click Connect, pick your compliance level. From that point forward, every AI interaction has your project's accessibility rules loaded via MCP.

This isn't just "instructions in a file." When the AI finds an issue, it reports it to a tracking system. When it fixes something, it has to verify the fix against quality checks. When the checks fail, it can't mark the issue as done. There's a system enforcing the loop: find, report, fix, verify. Skip a step and the dashboard shows the gap.

The extension itself is tiny (under 40 KB). It handles onboarding and shows your open issue count in the status bar. The real work happens through MCP, which means it works with Claude Code, GitHub Copilot, Cursor, Windsurf, and Cline.

In the pull request

The Jeikin GitHub App reviews every PR before merge. Issues appear as inline annotations in the code diff, not in a separate report. Each annotation includes the severity, the specific WCAG criterion, a plain-language explanation of who is affected, and a one-click link to fix it in Cursor or VS Code.

Critical violations block the merge. You can't ship inaccessible code by accident.

This catches what the AI in the editor missed. Maybe a junior developer didn't use the AI for that component. Maybe the AI hallucinated an aria attribute that doesn't exist. The PR review is the safety net.

On the dashboard

Everything flows to a central dashboard. Issues found, fixes verified, criteria evaluated, evidence preserved. The developer never needs to open it. But their engineering manager, their compliance officer, or their client can see exactly what was reviewed and what the results were.

Why this is different from adding rules to a file

There's a specific objection worth addressing directly, because it's the most reasonable one: "My AI already follows accessibility rules I've written in my project instructions."

Here's what project instructions can do:

Tell the AI to use semantic HTML
Remind it to add alt text to images
Set a general standard like "follow WCAG AA"

Here's what they can't do:

Track which files were actually reviewed and which were skipped
Enforce that a fix was verified before marking it done
Prove to an auditor what was checked and when
Coordinate across tools (editor AI, PR bot, runtime scanner) into one view
Remember findings across sessions. Every new conversation starts from zero
Run quality gates like APCA contrast, readability scoring, color vision simulation, or focus order tracing
Block a merge when a critical accessibility violation is present

Instructions are the input. A compliance system is the loop: input, review, evidence, enforcement. The loop is what auditors need to see. The loop is what prevents regressions. The loop is what makes "we care about accessibility" into a provable claim.

The landscape is moving

Accessibility tooling is converging with AI coding tools faster than most teams realize. Deque shipped an axe MCP server. AccessiMind does real-time WCAG analysis in VS Code. TestParty embeds remediation into GitHub workflows. The era of accessibility as a separate activity is ending.

The tools that win will be the ones developers don't have to think about. Not because accessibility doesn't matter, but because it matters too much to depend on someone remembering to run a scan.

Try it

Install the VS Code extension and ask your AI to review your code for accessibility.

Or install the GitHub App and open your next PR.

The first review usually surfaces things you didn't expect. Not because your code is bad, but because accessibility barriers are invisible until something looks for them systematically.

Accessibility overlays: why painting over problems doesn't fix them

Sergi Sánchez — Fri, 27 Mar 2026 17:19:34 +0000

There's a category of product that promises to make any website accessible by adding a single line of JavaScript. A floating widget appears in the corner, offering controls for contrast, font size, reading guides, and color adjustments. Some even claim compliance with WCAG, the EAA, or the ADA.

The pitch is appealing: paste a script tag, get a toolbar, check the compliance box. No code changes, no design work, no developer time.

It sounds too good because it is.

What overlays actually do

These widgets typically inject CSS and JavaScript that modifies how a page looks and behaves on the client side. Common features include:

Font size and spacing controls that adjust text display properties
Contrast modes that swap color palettes to higher-contrast themes
Reading aids like a line guide that follows the cursor, link highlighting, and title emphasis
Animation controls for pausing motion on the page
Profile presets ("seizure-safe", "ADHD-friendly", "vision-impaired") that bundle several adjustments together

Some of these features sound genuinely helpful. The problem isn't the idea of giving users control over their experience. The problem is where these controls live, and what they replace.

The core issue: overlays don't fix the code

If a form has no labels, an overlay can't add meaningful ones. If images have no alt text, the widget can't describe what's in the photo. If the tab order is broken, injecting CSS won't fix keyboard navigation. If heading levels jump from h1 to h4, no client-side script can rebuild your document structure.

Overlays address presentation, how things look. But most accessibility barriers are structural, how things are built. A screen reader doesn't read CSS. It reads the DOM. And if the DOM is broken, the overlay can't help.

This is like putting a fresh coat of paint on a building with no wheelchair ramp and calling it accessible. The paint looks nice. The ramp is still missing.

They can make things worse

This isn't theoretical. Research and user reports consistently show problems:

Conflicts with assistive technology. People who use screen readers, magnification software, or custom stylesheets already have their own tools configured for their needs. An overlay that injects its own focus management, color overrides, or font changes can interfere with these existing configurations. Users end up fighting two systems instead of one.

Performance impact. Overlays load additional JavaScript, sometimes significantly. For users on slower connections or older devices (the people who often need accessibility features most), this adds load time and can delay the page becoming interactive.

Inconsistent behavior. The overlay might work on one page but break on another where the site's own JavaScript conflicts with the injected modifications. Users can't predict when their adjustments will hold.

A separate experience. When accessibility depends on a widget instead of the native interface, users with disabilities get a fundamentally different experience from everyone else. The goal of accessible design is one good experience for everyone, not two separate paths.

The compliance question

Some overlay vendors market their products as making sites legally compliant. This claim doesn't hold up.

The European Accessibility Act (EAA), which took effect in June 2025, requires that products and services be accessible, not that they offer a separate tool for accessibility. WCAG conformance is measured against the site itself, not against what a third-party widget adds on top.

In the United States, courts have consistently ruled that overlays don't constitute compliance with the ADA. Organizations using overlays have been defendants in lawsuits because of their overlays, not despite them.

An overlay can't produce conformance with standards that require the underlying HTML to be correct. aria-label attributes, semantic heading structure, keyboard operability, form associations: these are code-level requirements.

Why overlays exist

This isn't about calling anyone negligent. Overlays became popular because accessibility is genuinely hard, tooling has historically been poor, and most teams face real constraints: limited budgets, tight deadlines, developers who weren't taught accessible patterns in school.

When someone offers a drop-in solution that promises compliance in five minutes, it's understandable that teams reach for it. The marketing is convincing, the urgency is real, and the alternative (learning and implementing accessible patterns across your entire codebase) sounds overwhelming.

The problem isn't that people want a shortcut. The problem is that this particular shortcut doesn't lead where it promises.

What actually works

Accessibility needs to be built into the code, not layered on top. That means:

Semantic HTML from the start. Use the right elements: <button> for actions, <nav> for navigation, <label> for form fields. This handles a surprising amount of accessibility without any extra effort.

Testing with real assistive technology. Screen readers, keyboard-only navigation, and magnification tools reveal issues that no automated scan or overlay will find.

Automated scanning in the development workflow. Tools like axe-core can catch structural issues during development, before they reach production. Catching a missing alt attribute during a code review is vastly better than patching it with an overlay after launch.

Continuous tracking. Accessibility isn't a one-time audit. Sites change constantly. Every new feature, every content update, every redesign can introduce new barriers. Teams need a way to verify that what was fixed stays fixed.

The WebAIM Million report finds that sites using overlays actually have more detectable accessibility errors on average than sites without them. This statistic alone tells the story.

The takeaway

If you're evaluating accessibility solutions, be cautious of anything that promises compliance without touching your codebase. Real accessibility is structural. It lives in your HTML, your ARIA attributes, your keyboard interactions, your color choices, your content hierarchy.

The good news: building accessible products is more achievable than it's ever been. Modern frameworks have better defaults, design systems are incorporating accessible patterns, and tools that integrate into development workflows can catch issues before they ship.

The work is worth doing properly. The people who depend on it deserve better than a widget.

I'm building Jeikin, an accessibility compliance tool that works inside AI coding agents (Claude Code, Cursor, Windsurf). Instead of an overlay, it checks your actual code and tracks evidence on a dashboard. If you're interested, you can try it with npx jeikin.