An accessibility overlay is a third-party JavaScript widget that adds a control panel to a website allowing users to adjust visual and interface settings in their browser.
Accessibility overlays are one of the most aggressively marketed products in the public sector technology space right now. If you have been in any accessibility conversation in the past two or three years, you have almost certainly encountered the pitch. Install a single line of JavaScript. Automatically remediate your website. Achieve ADA compliance. Protect your agency from legal risk.
It sounds like exactly what an overextended public agency needs. One tool. One decision. Problem solved.
The reality is more complicated. And understanding the gap between what overlay vendors promise and what overlay tools actually deliver is one of the most important pieces of knowledge a public agency or university can have going into ADA Title II compliance planning.
This is not an argument that overlays are worthless. Some overlay features provide genuine value for some users in some contexts. It is an argument that overlays are not what they are sold as — and that an agency whose primary accessibility strategy is an overlay tool is significantly more exposed than it realizes.
What Accessibility Overlays Actually Are (And How They Work)
An accessibility overlay is a third-party JavaScript widget that is added to a website and runs in the browser when a user visits the site. The widget typically appears as a small icon — often a figure in a wheelchair or a universal accessibility symbol — that users can click to access a panel of accessibility adjustment options.
Common overlay features include options to increase font size, adjust color contrast, switch to a high-contrast mode, enable a screen reader mode, reduce motion, add a reading guide, adjust line spacing, and enable dyslexia-friendly fonts. Some overlays also include automated fixes that run in the background — attempting to add missing alternative text to images, repair heading hierarchy issues, or fix color contrast problems without manual intervention.
The value proposition of the automated fix layer is where the compliance claims live. The pitch is that the overlay can scan a website, identify accessibility issues, and fix them automatically — delivering WCAG conformance without manual audit, without developer remediation, without governance program.
That pitch does not hold up under examination. Here is why.
What Overlays Can Do
Overlays are not without utility. It is worth being precise about what they actually provide before explaining where they fall short.
User preference controls have genuine value. The ability to increase font size, enable high contrast, reduce motion, and adjust spacing provides real benefit to users who prefer to customize their reading experience. These controls are not substitutes for underlying accessibility — a screen reader user who cannot navigate a form does not benefit from a font size toggle — but they do serve users with situational preferences or mild visual adjustments who are not using formal assistive technologies.
Some automated fixes address detectable, low-complexity issues. Overlays that run automated remediation can identify and address certain categories of accessibility issues that are detectable through code analysis. Simple missing alt text attributes on images can sometimes be populated with AI-generated descriptions. Some heading hierarchy issues can be corrected programmatically. Some color contrast adjustments can be applied through CSS modifications.
Overlays can supplement a real accessibility program. For an agency that has a functioning governance program — documented audit, ongoing remediation, monitoring cadence — an overlay that provides user preference controls can be a reasonable supplemental tool. As a layer on top of a real compliance program, it adds user-facing customization options without replacing the underlying work.
The word "supplement" is the critical one. Overlays provide value as supplements. They do not provide compliance as substitutes.
What Overlays Cannot Do — and Why That Matters
The categories of accessibility failure that overlays cannot address are precisely the categories that create the most ADA Title II exposure and generate the most complaints.
Overlays cannot fix structural document accessibility. A scanned PDF published on your agency website is a flat image. A screen reader sees nothing. An overlay running on the page where the PDF is linked does nothing to change the accessibility of the PDF itself. The document is on a different server, served from a different location, and the overlay's JavaScript has no reach into it. Every scanned board agenda, every untagged permit form, every inaccessible regulation document on your domain is completely unaffected by whatever overlay is running on your page.
For agencies whose biggest accessibility exposure is in their document library — which is most public agencies — an overlay addresses none of it.
Overlays cannot fix inaccessible transactional workflows. The keyboard navigation failures in your permit application system, the inaccessible error handling in your payment portal, the screen reader incompatibility in your license purchase flow — these are code-level failures in interactive systems that require developer remediation to fix. An overlay can add a high-contrast mode to the page surrounding these systems. It cannot make the underlying form fields keyboard accessible, it cannot fix the keyboard trap in the date picker, and it cannot make the error messages programmatically announced to assistive technology.
The barriers that most directly deny residents access to government services are almost entirely outside the reach of overlay automation.
Overlays cannot fix third-party vendor tool accessibility. The payment gateway embedded in your website, the GIS mapping tool, the scheduling system, the permit portal built by a specialized vendor — these tools are served from third-party domains and their accessibility is determined by the vendor's code, not yours. An overlay running on your domain has no ability to remediate accessibility failures inside embedded third-party iFrames.
Overlays cannot create governance documentation. A defensible ADA compliance program requires specific documentation: a dated baseline audit, a risk-based prioritization framework, a timestamped remediation log, monitoring records, executive reporting history. An overlay produces none of these. It does not generate an audit report. It does not document what issues were identified and how they were addressed. It does not create a monitoring record. It does not demonstrate ongoing compliance effort.
When an enforcement inquiry arrives and an agency is asked to produce its compliance documentation, an overlay subscription receipt is not a compliance record.
AI-generated alternative text is not reliable for compliance purposes. Several overlay products include AI-generated alternative text that automatically populates missing alt attributes on images. The AI analyzes the image visually and generates a text description. In theory, this addresses a widespread accessibility failure automatically. In practice, AI-generated descriptions are frequently inaccurate for the images that matter most in public agency contexts — GIS maps, data charts, engineering diagrams, wildlife photos with specific identification significance, construction site photos with safety information, and any image where the meaningful content is contextual rather than visually obvious.
An AI that looks at a chart of municipal budget allocations and writes "bar graph showing colored bars of different heights" has not created useful alternative text. It has created a description that satisfies an attribute requirement while conveying none of the information the chart communicates. That is not compliance. It is a filled attribute that creates a false impression of accessibility.
The Legal Track Record
The legal track record of overlay-only accessibility strategies has been established clearly enough that it should inform every public agency's vendor evaluation process.
Courts and enforcement bodies have not accepted overlay tools as sufficient demonstration of ADA compliance. In multiple cases, agencies and organizations that relied on overlay tools as their primary accessibility solution found that the presence of an overlay did not constitute defensible compliance when the underlying digital environment remained inaccessible.
The National Federation of the Blind and other disability advocacy organizations have published formal positions stating that overlay products do not provide the accessibility they claim and can actively interfere with the assistive technology some users rely on — specifically screen readers. When an overlay attempts to "fix" a page that a screen reader is already interpreting correctly, the overlay's modifications can conflict with the screen reader's interpretation, producing a worse experience than the unmodified page.
The DOJ's ADA Title II rule does not reference overlay tools as a compliance pathway. It references WCAG 2.1 AA. WCAG conformance is evaluated against the actual accessibility of the digital environment — not the presence of a widget.
An agency that responds to an accessibility complaint by pointing to its overlay subscription is not in a materially different position than an agency that never addressed the complaint. The documentation that enforcement bodies need to see — the audit, the remediation log, the monitoring records — does not exist. The accessibility barriers that generated the complaint — likely in a transactional workflow or a document — are unaddressed. The overlay is irrelevant to both of those facts.
The False Security Problem
The most damaging consequence of overlay adoption is not the overlay itself. It is the organizational complacency that follows.
When an agency purchases an overlay product and is told by the vendor that it is now "ADA compliant," the organizational motivation to do the actual governance work frequently decreases or disappears. The leadership conversation about accessibility gets closed — the problem has been solved, the product has been purchased, the line item has been allocated. The web team is not asked to conduct an audit. The remediation log is never opened. The monitoring program is never built. The governance framework is never established.
Twelve months later, the agency has an overlay running on its website and a compliance posture that is completely indefensible. Not because nothing was done — an overlay was purchased, resources were spent — but because what was done does not constitute a compliance program. And the organizational window that existed to build a real program was closed by the false confidence the overlay purchase created.
This is the false security problem. It is more dangerous than ignorance, because ignorance at least preserves the organizational urgency to act. False confidence eliminates it.
The agencies most at risk from overlay products are not the ones that evaluated overlays carefully and decided to use them as supplements. They are the ones that evaluated overlays quickly, believed the compliance claims, made a purchase, and moved on — never building the underlying program that would have protected them.
What Overlays Get Recommended Instead Of
The tools that professional accessibility practitioners use to evaluate and remediate digital accessibility are different from overlay products. Understanding what they are helps clarify what a real accessibility program looks like in practice.
axe DevTools. A browser extension and enterprise testing platform developed by Deque Systems, one of the leading accessibility organizations in the field. axe provides automated scanning that identifies WCAG failures with high accuracy and low false positive rates. It is used by accessibility professionals for audit and monitoring work. The browser extension is free. The enterprise platform includes additional features for organizational scanning and reporting.
WAVE. The Web Accessibility Evaluation Tool, developed by WebAIM at Utah State University. A free browser extension that provides visual overlays on pages showing accessibility errors, alerts, and structural information. Widely used by accessibility practitioners and website auditors for page-level evaluation.
Siteimprove. An enterprise digital governance platform that includes comprehensive accessibility scanning alongside other web governance functions including content quality, SEO, and analytics. Commonly used by larger public sector organizations for ongoing monitoring across complex multi-site environments.
Screen readers for manual testing. NVDA (NonVisual Desktop Access, free) and JAWS (commercial) on Windows, and VoiceOver (built into macOS and iOS) on Apple devices. Manual testing with actual screen reader software is the only way to evaluate the accessibility of transactional workflows, form interactions, dynamic content behavior, and the real-world experience of users who rely on assistive technology. No automated tool — overlay or otherwise — substitutes for this testing.
The difference between these tools and overlay products is fundamental. These tools are used to identify and remediate accessibility failures. Overlay products are used to paper over them. One approach builds a real compliance program. The other creates the appearance of one.
How to Evaluate an Overlay Vendor's Claims
If your agency is currently using an overlay product or is evaluating one, these questions create the framework for an honest evaluation.
Ask for specific documentation of what the overlay actually fixes. Not marketing claims. Technical documentation of exactly which WCAG success criteria the overlay addresses through automated remediation, and which criteria remain the agency's responsibility to address through manual remediation. Any vendor who cannot provide this documentation clearly is not in a position to make compliance claims.
Ask whether the overlay addresses document accessibility. The answer is no. If a vendor claims their overlay addresses PDF accessibility, ask them to demonstrate it on a specific scanned PDF from your document library while a screen reader is running. The answer will be clear.
Ask whether the overlay addresses transactional workflow accessibility. Ask the vendor to demonstrate that their overlay makes a specific keyboard navigation failure in a form accessible. Have a screen reader user test the workflow before and after the overlay is applied. If the keyboard trap exists in the workflow code, the overlay does not fix it.
Ask what documentation the overlay produces for compliance purposes. Ask specifically for an example of the compliance documentation the overlay provides that would be responsive to a DOJ documentation request. The overlay should not be able to produce a dated audit report, a risk-based prioritization framework, or a timestamped remediation log — because it does not create any of these things.
Ask what percentage of your current accessibility failures the overlay addresses. The honest answer, for most agencies, is a minority — and in some categories, zero. If a vendor cannot give you a specific, verifiable answer to this question, they are not in a position to make compliance claims.
The Role Overlays Should Play in a Real Compliance Program
Overlays are not categorically excluded from a well-structured accessibility program. They have a legitimate supplemental role — but only in the context of a program that is doing the underlying work.
In a real compliance program, an overlay that provides user preference controls — font size, contrast, motion, spacing — can be a genuine addition to the user experience for visitors who prefer those customization options. That value is real. It is not compliance value. It is user experience value. And it is appropriate to invest in user experience value after the compliance work is done, not as a substitute for doing it.
The sequencing matters. Build the compliance program first. Conduct the audit. Remediate the highest-risk barriers. Establish the monitoring and documentation infrastructure. Build the governance framework. Then, if there is budget and organizational interest in adding user preference controls as an enhancement, an overlay widget can serve that purpose.
What is not appropriate — and what the legal track record confirms does not work — is purchasing an overlay as the compliance strategy and considering the obligation addressed.
What Defensible Accessibility Looks Like Without Overlays
The path to defensible ADA Title II compliance does not run through any single product purchase. It runs through a program.
A baseline audit that documents where accessibility failures exist across the digital environment. A risk-based prioritization model that sequences remediation starting with the barriers that most directly block access to public services. A remediation program that addresses those barriers through code-level fixes, document remediation, and vendor coordination. A monitoring program that catches new issues introduced through content updates, vendor changes, and template modifications. A documentation record that creates the timestamped evidence of ongoing compliance effort. An executive reporting cadence that creates organizational accountability. A governance framework that makes the program person-independent and institutionally durable.
That program is what protects an agency under ADA Title II. Not a widget. Not a JavaScript library. Not an AI that guesses at image descriptions.
The agencies that are managing ADA Title II compliance well are the ones that built that program. And the agencies creating the most risk right now are the ones that thought they bought compliance and discovered — or will discover — that they bought a subscription to a product that could not deliver what was promised.
[Create an accessibility remediation log →]
[Understand WCAG 2.1 AA better →]
[Fix these 5 ADA issues first →]
FAQ: Accessibility Overlays and ADA Compliance
What is an accessibility overlay? An accessibility overlay is a third-party JavaScript widget added to a website that provides user-facing customization controls — such as font size adjustment, high contrast mode, and reduced motion — and in some cases includes automated remediation features that attempt to fix accessibility issues detected through code analysis. Overlays are marketed to public agencies and institutions as ADA compliance solutions. They are more accurately described as user experience supplements that address a limited subset of accessibility issues while leaving the categories of failures most likely to generate ADA complaints entirely unaddressed.
Do accessibility overlays provide ADA Title II compliance? No. Courts and enforcement bodies have not accepted overlay tools as sufficient demonstration of ADA Title II compliance. An overlay does not produce the documentation that enforcement bodies request — baseline audit reports, remediation logs, monitoring records — and does not address the categories of accessibility failure most likely to generate complaints, including inaccessible transactional workflows, scanned PDF documents, and third-party vendor tool failures. The DOJ's ADA Title II rule references WCAG 2.1 AA as the technical standard, and WCAG conformance is evaluated against the actual accessibility of the digital environment, not the presence of an overlay widget.
What accessibility issues can overlays not fix? Overlays cannot fix inaccessible PDF and document accessibility — scanned documents remain inaccessible regardless of what overlay is running on the page where they are linked. Overlays cannot fix keyboard navigation failures, keyboard traps, or inaccessible error handling in transactional workflows — these require code-level developer remediation. Overlays cannot fix accessibility failures inside embedded third-party tools like payment gateways or permit portals served from external domains. Overlays cannot generate compliance documentation including audit reports, remediation logs, or monitoring records. These categories represent the majority of ADA Title II exposure for most public agencies.
Can AI-generated alternative text from overlay tools satisfy WCAG requirements? Generally no, particularly for the images that matter most in public sector contexts. AI-generated alternative text from overlay tools is based on visual image analysis and frequently produces descriptions that describe what an image looks like rather than what it communicates. A chart of budget allocations described as "bar graph with colored bars" does not convey the budget data. A GIS map described as "map showing green and blue areas" does not convey the geographic information the map communicates. For images where the meaningful content is data, spatial information, or contextual significance — which describes most high-value public agency images — AI-generated descriptions do not constitute accessible alternatives under WCAG 1.1.1.
Are there accessibility tools that actually work for public agency compliance? Yes. Tools used by accessibility practitioners for genuine compliance work include axe DevTools for automated scanning with high accuracy, WAVE for page-level visual accessibility evaluation, Siteimprove for enterprise-level monitoring across complex multi-site environments, and screen reader software including NVDA, JAWS, and VoiceOver for manual testing of transactional workflows and interactive content. These tools are used to identify and remediate accessibility failures rather than to paper over them. They form part of a real compliance program rather than substituting for one.
If my agency already has an overlay, what should we do? An overlay already in place does not need to be immediately removed — if it provides user preference controls that some visitors find useful, that value is real. What needs to happen in parallel is building the actual compliance program that the overlay cannot substitute for. That means conducting a baseline audit of the full digital environment, building a risk-based remediation program starting with transactional workflows and high-traffic documents, implementing a monitoring cadence, establishing a remediation log, and creating the governance framework and documentation record that constitute defensible ADA Title II compliance. The overlay can remain as a user experience supplement once the compliance program is in place. It should not be treated as the compliance program itself.