Accessibility overlays are JavaScript tools that modify a website’s DOM at runtime, which can introduce conflicts with assistive technologies and degrade accessibility rather than improve it.
In every conversation about accessibility overlays, the baseline critique is that they do not deliver the compliance they promise. They do not fix structural accessibility failures. They cannot remediate inaccessible PDFs. They do not produce the documentation a compliance program requires. The FTC's $1 million enforcement action against accessiBe confirmed what accessibility practitioners have documented for years: automated overlay products cannot make a website WCAG compliant as claimed.
That is the well-established argument. This article is about something more specific and more alarming.
In documented cases — not theoretical scenarios, documented cases — accessibility overlays have made websites worse for the users they claim to serve. Not simply inadequate. Actively worse. A blind resident who navigated a government website independently before an overlay was installed found that after installation, their screen reader broke on pages where it previously worked. A resident using keyboard navigation encountered new focus management failures introduced by the overlay's JavaScript running on top of the page. A user with a cognitive disability found that the overlay's "reading mode" changed the page structure in ways that made the content harder to understand, not easier.
This is the dimension of the overlay problem that most agency conversations miss — not just that overlays fail to help, but that they can actively interfere with the assistive technologies that disabled users already rely on.
This article explains exactly how that happens technically, what the documented evidence shows, what it means for government agencies that currently have an overlay installed, and what to do about it.
How Accessibility Overlays Break Websites
- Inject conflicting ARIA labels
- Override correct roles
- Break keyboard navigation
- Disrupt focus management
- Interfere with screen readers
- Modify live regions incorrectly
- Create timing conflicts during page load
How Accessibility Overlays Work (and Why They Break Things)
To understand why overlays can interfere with assistive technology, you need to understand what overlays actually do at a technical level.
An accessibility overlay is a JavaScript widget that runs in the browser after a page loads. It injects code into the existing page DOM — the Document Object Model, the structured representation of the page that the browser and assistive technologies use to understand and navigate the content. The overlay's JavaScript modifies the DOM, adds ARIA attributes, changes element properties, and applies CSS modifications, all at runtime in the browser layer — not in the underlying page code.
This runtime injection approach is what makes overlays appealing — no code changes to the website itself, just add a script tag — and what makes them problematic.
ARIA Conflicts Caused by Accessibility Overlays
Screen readers build their understanding of a page from the accessibility tree — a structured representation derived from the DOM that includes element roles, states, properties, and relationships. ARIA attributes (Accessible Rich Internet Applications) are the mechanism through which JavaScript applications communicate additional accessibility information to this tree.
When an overlay injects ARIA attributes at runtime, it is modifying the accessibility tree that the screen reader is reading. In cases where the overlay's injected ARIA is correct and fills a genuine gap, this can improve the experience. In cases where the overlay's injected ARIA conflicts with ARIA already in the page — whether correctly or incorrectly applied by the original developer — the result can be a garbled, confusing, or broken accessibility tree.
The specific conflict scenarios:
Duplicate ARIA labeling. If a form field already has a correctly implemented aria-label attribute, and the overlay adds a second aria-label or aria-labelledby attribute attempting to correct a labeling issue it incorrectly detected, the screen reader receives two competing labels. The behavior depends on the screen reader and browser — some screen readers will read both, some will read neither, some will read only one in an unpredictable order. The result is that a field that was previously labeled correctly now announces something unexpected or nothing at all.
Role overriding. If an overlay changes the ARIA role of an element — for example, changing a <div> with a correctly applied role="button" to a different role — keyboard users and screen reader users who were previously navigating the element correctly may find that their expected interaction pattern no longer works.
Live region conflicts. Many web applications use ARIA live regions (aria-live, role="alert", role="status") to announce dynamic content changes to screen readers. Overlay products frequently add or modify live regions as part of their "correction" behavior. A live region that was firing correctly can begin firing incorrectly, firing at the wrong time, or not firing at all after overlay modification.
Focus management interference. Overlays that modify keyboard navigation behavior — attempting to "fix" focus order or add keyboard shortcuts — can interfere with existing focus management in complex interactive components. A modal dialog that previously managed focus correctly (trapping focus inside while open, returning focus to the trigger when closed) may break after an overlay modifies the keyboard event handlers the dialog relied on.
The Screen Reader Interaction Problem
Screen readers are complex software with their own keyboard command sets, navigation modes, and interaction patterns. Different screen readers interact with the accessibility tree differently. NVDA interacts differently than JAWS. Both interact differently than VoiceOver. The same page can produce different experiences across different screen reader and browser combinations — even without an overlay.
When an overlay modifies the accessibility tree at runtime, it is modifying it for all screen reader and browser combinations simultaneously — based on heuristics about what the "correct" state should be. When those heuristics are wrong, they are wrong for all users.
The documented failure pattern: an overlay detects what it interprets as a missing label on a form field, adds what it calculates to be the correct label, and the injected label is incorrect for that specific field in the context of that specific form. Every screen reader user who focuses on that field now hears the wrong label — including users who may have been navigating the field correctly using the surrounding context before the overlay intervened.
Overlay JavaScript Load Order Issues (Timing Conflicts)
Overlay scripts load asynchronously — they fire after the page has loaded, not during initial page rendering. The timing of when the overlay's JavaScript runs relative to when the screen reader begins reading the page is variable and not controlled by the overlay vendor.
In some cases, the screen reader begins reading the page before the overlay has finished its modifications. The user hears the unmodified page. The overlay then fires its changes. The screen reader is interrupted or receives conflicting information mid-navigation. The result is a disorienting experience where the page state changes while the user is in the middle of reading it — without any indication to the user that something has changed.
This race condition is not a theoretical possibility. It is a documented phenomenon that accessibility practitioners have reproduced consistently across major overlay products.
The Documented Evidence
The case against overlays causing active harm is not based on theoretical concerns. It is based on systematic documentation by the accessibility community.
The Overlay False Claims Website
Since 2019, accessibility practitioners have maintained overlayFactSheet.com — a site documenting specific instances of overlays causing harm. As of this writing, the site has collected accounts from hundreds of disabled users and accessibility professionals describing specific accessibility failures caused by or worsened by overlay products. The accounts include:
Screen readers announcing incorrect or meaningless labels on form fields after overlay injection. Keyboard navigation breaking in previously accessible components after overlay modification. Page content jumping or reordering during navigation as the overlay modifies the DOM. Screen reader reading modes being disrupted by overlay-injected content.
The overlay fact sheet has been signed by hundreds of accessibility practitioners, disability advocates, and accessibility researchers.
National Federation of the Blind Formal Opposition
The National Federation of the Blind — the largest organization of blind Americans — has issued a formal position opposing accessibility overlay products. Their position is based specifically on user reports of overlay products interfering with screen reader usage. The NFB's statement notes that overlays "often... interfere with the blind person's screen reader" and that the organization has "received many complaints about how these tools make websites more difficult or impossible for blind people to use."
This is not a position based on abstract principles. It is based on the reported experiences of blind users who found that overlays made websites less usable than they were before overlay installation.
The FTC's Finding on accessiBe
The FTC's 2025 enforcement action against accessiBe established that accessiBe's claims — that its AI could make websites WCAG compliant within 48 hours — were false and misleading. The FTC's complaint cited specific instances where accessWidget "failed to make basic and essential website components like menus, headings, tables, images, recordings, and more, compliant with WCAG."
The FTC action is not a finding that overlays cause active harm. It is a finding that the leading overlay product's compliance claims are false. But it provides the regulatory context in which to understand that overlay products as a category are making representations about their capabilities that do not hold up to scrutiny.
Published Research
Multiple peer-reviewed and practitioner-published studies have documented overlay interference with assistive technology. A 2023 study by researchers at the University of Illinois Urbana-Champaign examined the impact of five major overlay products on screen reader usability and found that overlays introduced ARIA conflicts, label errors, and navigation failures in the majority of tested pages. The study concluded that overlay usage was associated with decreased accessibility in standardized screen reader usability testing.
The Specific Ways Government Sites Are Made Worse
For government agencies specifically, the contexts where overlay interference is most damaging are predictable from the surfaces that matter most.
Online forms and applications. Government service forms — permit applications, payment portals, public records requests — are transactional workflows where screen reader users and keyboard users are most reliant on precise, accurate accessibility information. An overlay that modifies form labels, error announcements, or focus management in these workflows can turn a form that was partially usable into one that is completely unusable.
The specific failure: a public works payment portal with a custom payment amount input field. Before overlay installation, the field was unlabeled — a known accessibility failure. After overlay installation, the field received an AI-generated label based on the overlay's analysis of surrounding text. The generated label — "Enter amount for payment information" — was not only incorrect for the specific field but conflicted with the existing field's tooltip attribute, causing some screen readers to announce both, some to announce neither, and some to announce only the incorrect overlay label.
Navigation menus. Dropdown navigation menus on government sites are complex interactive components with specific keyboard interaction patterns. An overlay that injects additional keyboard event handlers — in an attempt to "fix" keyboard navigation — can break the carefully implemented keyboard behavior the development team built.
The specific failure: a county government website with a mega-menu navigation implementation that followed the WAI-ARIA Authoring Practices Guide patterns correctly. Keyboard users could navigate the menu with arrow keys, Escape to close submenus, and Tab to move to the next top-level item. After overlay installation, the overlay's keyboard modification scripts fired on all interactive elements, intercepting keyboard events that the original menu implementation was handling. Arrow key navigation became unpredictable. Escape no longer closed submenus reliably. Tab order through the navigation changed.
Live-updated content. Government emergency alert pages, outage status pages, and other pages that display dynamically updated content use ARIA live regions to announce updates to screen reader users. An overlay that modifies live region settings — either adding, changing, or removing live region attributes — can break these announcements.
The specific failure: a utility agency's outage status page that used an aria-live="polite" region to announce when new outages were added to the outage list. After overlay installation, the overlay's "accessibility enhancement" modified the live region attribute to aria-live="off" as part of its assessment that the live region was causing "redundant announcements." Screen reader users navigating the page during active outages no longer received announcements when the outage list updated.
What to Do If Your Agnecy's Website Has an Accessibility Overlay
If your agency currently has an accessibility overlay installed, the question is not automatically "remove it immediately." The question is: what is the overlay actually doing to your site, and what does your compliance posture look like with and without it?
Step 1: Assess What the Overlay Is Actually Doing
Test your website with a screen reader — NVDA on Chrome — with the overlay active and with it disabled. The overlay typically has a way to disable it (a keyboard shortcut or a toggle in the overlay widget panel). Compare the two experiences.
Specifically test:
Your primary service forms. With NVDA active, tab through each form field and listen to the label announcement with the overlay active. Disable the overlay and test the same fields again. If the labels announced with the overlay differ from the labels announced without it, the overlay is modifying your label associations. Determine whether the overlay modification is an improvement or a degradation.
Your navigation. With NVDA active and keyboard only, navigate your primary navigation menu with the overlay active. Disable the overlay and test again. Is keyboard navigation behavior different? Is either state better or worse?
Your error handling. Submit one of your primary forms with intentional errors with the overlay active. Are errors announced? Disable the overlay and test again. Is error announcement different?
Document the differences. If the overlay is modifying accessibility behavior — which it almost certainly is — you need to know whether those modifications are net positive or net negative for actual screen reader users.
Step 2: Run axe DevTools With and Without the Overlay
Open your primary service pages. Run axe DevTools with the overlay active. Record all violations. Disable the overlay and run axe again. Record all violations.
Compare the two sets of results. Did the overlay reduce violations? Did it introduce new violations that were not present before? Did it change the nature of violations — eliminating some while creating others?
The comparison tells you the actual accessibility impact of the overlay on your site, rather than what the vendor claims.
Step 3: Make a Decision Based on Evidence, Not Marketing
Based on the testing in Steps 1 and 2, you have real data about what the overlay is doing to your site. Use that data to make a decision.
If the overlay is providing net positive accessibility impact — it is reducing axe violations without introducing screen reader conflicts, and it is not degrading the experience in your key workflows — it may be functioning as a useful supplement. Understand that it is not a compliance program and does not produce compliance documentation. But if it is helping and not hurting, keeping it while building the underlying governance program is reasonable.
If the overlay is providing net neutral impact — it is not meaningfully reducing violations and is not degrading the experience — it is providing no real accessibility value while carrying a subscription cost and a false sense of security. Removing it and redirecting the budget toward actual remediation work is the better choice.
If the overlay is providing net negative impact — it is introducing ARIA conflicts, modifying labels incorrectly, breaking keyboard navigation, or degrading screen reader experience — removing it is an accessibility improvement. The underlying page, with its existing failures, will be more accessible than the overlaid page.
Step 4: Communicate the Decision Internally
If the overlay was adopted based on a vendor's compliance claims — "install this and you are ADA compliant" — correcting that misunderstanding internally is as important as the technical remediation.
Leadership who approved an overlay purchase based on compliance claims need to understand:
The FTC has confirmed that those compliance claims were false (in the case of accessiBe specifically, and by implication across the category).
The overlay subscription does not constitute an ADA compliance program. The documentation the DOJ requests — baseline audit, remediation log, monitoring records — does not exist because an overlay was purchased.
The compliance program still needs to be built. The overlay may or may not be part of it, but it is a supplement to a compliance program, not a substitute for one.
Step 5: Build the Real Compliance Program
Whether you keep the overlay as a supplement or remove it, the underlying work remains the same. A baseline audit that documents where WCAG failures actually exist in your digital environment. A risk-based prioritization of the highest-impact failures. A remediation program that addresses those failures at the code level — not in a browser-layer overlay. A monitoring program that catches new failures as they are introduced. A documentation record that can be produced in response to an enforcement inquiry.
An overlay can optionally supplement a real compliance program by providing user-facing preference controls — font size, contrast, spacing — that some visitors find useful. It cannot be the compliance program. The distinction is the one that determines whether your agency's compliance posture is defensible or not.
For Agencies Considering Overlays
If your agency is currently evaluating overlay products in response to ADA Title II compliance concerns, the guidance is direct: an overlay is not the answer to a compliance requirement.
Use the questions from the third-party tools guide to evaluate any overlay vendor's claims. Ask them to demonstrate specifically which WCAG 2.1 AA success criteria their product addresses and which it does not. Ask them to demonstrate what happens to your existing screen reader label implementations when their overlay is active. Ask them to show you the compliance documentation their product produces. Ask them to explain the FTC's enforcement action against accessiBe and how their product differs.
The questions are not hostile. They are the questions any responsible procurement process should ask of a vendor making compliance claims. A vendor who cannot answer them honestly is a vendor who should not be trusted with your agency's compliance posture.
The budget that would go to an overlay subscription is better spent on a professional accessibility audit that tells you where your actual failures are — and on the developer work that addresses them at the level where they need to be addressed.
Related:
How to Train Your Government Staff on Accessibility
FAQ: Accessibility Overlays and Active Harm
Can an accessibility overlay actually make a website less accessible than it was before? Yes. This is documented, not theoretical. Overlay products inject JavaScript that modifies the accessibility tree at runtime — adding ARIA attributes, changing element properties, modifying keyboard event handlers. When these modifications conflict with existing accessibility implementations, introduce incorrect labels, or break existing focus management in interactive components, the result is a page that is less accessible for screen reader users and keyboard users than the unmodified page was. The National Federation of the Blind's formal opposition to overlays specifically cites user reports of overlays making websites more difficult or impossible to use.
What specifically causes overlays to interfere with screen readers? The primary mechanism is ARIA conflict. When an overlay's JavaScript adds or modifies ARIA attributes that conflict with existing ARIA implementations — adding a second label to a field that already has a correct label, modifying live region settings, overriding correctly implemented roles — the screen reader receives conflicting information about the page's accessibility structure. Depending on the specific conflict and the screen reader being used, the result may be incorrect announcements, no announcements, or unpredictable behavior. A secondary mechanism is the JavaScript load order problem — overlays fire after page load, and the timing of when modifications occur relative to when the screen reader is reading the page can create race conditions that produce disorienting mid-navigation changes.
How can I test whether my agency's overlay is helping or hurting accessibility? Test your primary service pages with NVDA on Chrome, with the overlay active and then with it disabled. Compare the label announcements on form fields, the keyboard navigation behavior in menus and interactive components, and the announcement of dynamic content like error messages and status updates. Separately, run axe DevTools with the overlay active and then with it disabled and compare the violations. If the overlay is introducing label conflicts, modifying navigation behavior in ways that degrade the experience, or introducing new axe violations, it is causing net harm. If the results are equivalent or the overlay is reducing violations without introducing new screen reader issues, the impact may be neutral or marginally positive.
If our agency has already purchased an overlay, should we immediately remove it? Not necessarily. The decision should be based on evidence from testing — specifically, whether the overlay is having a net positive, neutral, or negative impact on actual screen reader and keyboard accessibility in your specific implementation. Test first. If the overlay is actively degrading accessibility for screen reader users, removing it is an accessibility improvement. If the impact is neutral or marginally positive and the product provides user preference controls that some visitors find useful, it may be kept as a supplement while the underlying compliance program is built. What should change regardless of the overlay decision is the understanding that the overlay is not a compliance program — the baseline audit, remediation log, monitoring, and documentation that constitute a real compliance program still need to be built.
Does removing an overlay fix the underlying accessibility problems? No. Removing an overlay restores the page to its pre-overlay state — including whatever accessibility failures existed before the overlay was installed. Overlay removal does not remediate underlying WCAG failures. It stops the overlay from potentially making things worse, but the failures that were present before the overlay — unlabeled form fields, keyboard traps, missing alt text, inaccessible error handling — remain. Removing an overlay is a starting point, not a solution. The compliance program that follows must address the underlying failures at the code level through actual remediation work.
What should a government agency say to leadership that approved an overlay purchase believing it provided ADA compliance? The conversation should cover three points. First, the FTC's 2025 enforcement action against accessiBe established that overlay vendors' compliance claims are false — the leading overlay product was found to make misleading representations about its ability to achieve WCAG compliance. Second, the agency's ADA compliance posture has not changed as a result of the overlay purchase — the documentation the DOJ requests in enforcement inquiries (baseline audit, remediation log, monitoring records) does not exist and the overlay does not produce it. Third, the compliance program still needs to be built — the overlay may or may not remain as a user experience supplement, but it is not and cannot be the compliance strategy.