A demand letter or a client email about ADA compliance tends to land the same way: someone needs an answer fast, and an overlay widget that promises to fix accessibility with one script tag looks like the fastest answer available. The harder question is what that script actually does once it is installed, and what it quietly leaves for someone else to handle. accessiBe and UserWay, the two most visible vendors in this category, both publish product pages that answer part of that question in their own words. Reading those pages closely shows a consistent pattern: each vendor draws its own line between what the widget automates and what it sells as a separate, human performed service.
The one-line-of-code pitch, and where it comes from
Overlay widgets exist as a category because the alternative, a manual code-level remediation project, is slower and priced as a one-off engagement rather than a subscription. Both accessiBe’s accessWidget and UserWay’s Accessibility Widget are installed the same way: a script added to the site, with dedicated apps and plugins for platforms including WordPress, Shopify, Wix and other major site builders, according to each vendor’s own integrations listing. That install model, not a development sprint, is the appeal for a brand that just received a letter and wants something live this week.
accessiBe’s own FAQ on the accessWidget page is specific about how long that first pass takes: it states the AI-powered remediation process takes up to 48 hours from the initial installation, and that a similar window applies again whenever site content changes. That is the vendor’s own stated timeline, not an outside estimate, and it means the widget is not instant even by accessiBe’s own description. It is fast relative to a manual audit, not fast relative to flipping a setting.
What the automated layer actually changes
| Claim | accessiBe (accessWidget) | UserWay (Accessibility Widget) |
|---|---|---|
| Screen reader support | Its page states the AI “adds ARIA attributes and alt text” to the site, and its FAQ credits machine learning with creating “accurate and concise image descriptions for alt text.” | [EVIDENCE NEEDED: a UserWay page section itemizing ARIA or alt text handling specifically, rather than the general automated remediation claim below] |
| Keyboard navigation | The page states a “contextual understanding AI engine optimizes your website so users with motor disabilities can access all elements without a mouse.” | [EVIDENCE NEEDED: a UserWay page section naming keyboard navigation specifically] |
| Visual and contrast adjustments | Lists contrast, text size and other UI perception adjustments under a “Vision impaired” profile on the same page. | [EVIDENCE NEEDED: a UserWay page section naming contrast or text size adjustments specifically] |
| General automation claim | Describes “automatic, ongoing remediation” according to WCAG standards. | Its homepage describes the widget as using “automated remediation technology (ART)” that “automatically finds and fixes common issues with every page load,” without itemizing which issues on that specific page. |
The gap in the UserWay column above is the point of the table, not an oversight. UserWay’s homepage names the mechanism, ART, and the outcome, common issues fixed on every page load, but it does not break that claim down by fix type on the page a visitor lands on first. accessiBe’s page is more granular about which disability profile gets which adjustment. Neither difference says one widget does more; it says one vendor’s homepage is more itemized than the other’s.
What each vendor lists as a separate product, not part of the widget
The more useful signal on both pages is not what they claim the widget does. It is what they sell next to the widget as something else entirely. accessiBe’s own FAQ states plainly that accessWidget “cannot fix” certain accessibility errors, naming captions for videos and PDF remediation specifically, and that these “must be handled separately.” That is a direct admission from the vendor, not a limitation a critic found. The same page lists Litigation Support, User Testing and Expert Audit as named services distinct from the accessWidget product itself, alongside a VPAT documentation service and a File & PDF accessibility service.
UserWay’s homepage runs the same pattern under its own labels. Its solutions section separates the Accessibility Widget from Accessibility Audits, which it describes as “manual audits by experts,” and from Accessibility Monitoring, which continuously scans source code rather than adjusting the page live. Its footer solutions list names Video Remediation and VPAT / ACR as their own products, sitting apart from the widget line.
Two vendors, arriving independently at the same shape: an always-on automated layer for one category of fix, and a roster of paid, human-performed services for the categories that layer does not reach. That symmetry is itself informative. If the widget covered everything, there would be nothing left for the audit or the litigation package to sell.
Reading a vendor’s own claim like a lawyer would
The method that falls out of the pattern above is simple to apply to any vendor page, not just these two. When a page says a tool “fixes” or “automatically remediates” something, check whether the same page also lists a manual, audit, or expert-driven product for that same category. If it does, the vendor has already drawn the boundary of its own automated claim, whether or not the marketing copy above the fold says so.
accessiBe’s own accessWidget page is a clean example of this in a single scroll. Near the top, it markets “automatic, ongoing remediation” that works “according to WCAG 2.2 Level AA standards.” Further down the same page, it lists “Expert audit,” described as a service to “conduct a manual accessibility audit,” and “User testing,” described as testing “with real end-users.” The vendor is not contradicting itself. It is describing two different products on one page: an automated layer sold as always-on, and a manual layer sold separately because the automated one was not built to replace it. A reader who only reads the hero section sees one claim. A reader who scrolls to the services list sees the vendor’s own boundary for that claim.
Talk to followed about accessibility tooling coverage
followed tracks pricing and product changes across the tools that a social or marketing team ends up evaluating, accessibility overlays included when a demand letter forces the question. If a vendor’s page changes what it discloses about its widget versus its paid services, that is the kind of shift worth flagging.
What this does not tell you
None of the above establishes what satisfies ADA Title III, what WCAG conformance level a court or regulator will treat as sufficient, or what any specific legal standard requires. A vendor’s own product page can state what its tool automates and what it sells separately, because that is a fact about the vendor’s product. It cannot serve as legal authority on what compliance requires, because a marketing page is not a legal text and a vendor’s description of its own remediation is not a certification that a court, a regulator, or opposing counsel will accept. accessiBe’s page itself uses two different WCAG figures in different sections, WCAG 2.2 Level AA in the marketing copy near the top and WCAG 2.1 AA in its own FAQ answer about legal compliance. That inconsistency on the vendor’s own page is one more reason a product page is the wrong document to settle a legal question, not a case for picking whichever number sounds more current. This post makes no claim about what a demand letter requires or what a court would accept, and does not resolve which of accessiBe’s own two WCAG figures should be treated as authoritative.
FAQ
Does an overlay widget fix everything a screen reader needs?
Not according to the vendor’s own disclosure. accessiBe’s FAQ names video captioning and PDF remediation specifically as things accessWidget cannot fix, stating these must be handled separately. Beyond what the vendor states outright, this post does not extend the claim further in either direction.
How long does an overlay widget take to work after installing it?
accessiBe’s own FAQ states its AI-powered remediation process takes up to 48 hours from the initial installation, with a similar window each time site content changes. That figure comes from the vendor itself and has not been independently verified here.
What is the difference between the widget and the audit these vendors also sell?
By each vendor’s own product pages, the widget is the automated, always-on layer that runs on every page load. The audit, whether accessiBe’s Expert audit or UserWay’s Accessibility Audits, is a separate, human-performed service sold alongside the widget. That the audit exists as its own paid product is itself evidence of what the automated layer does not close on its own.
Can an overlay widget stop a demand letter or lawsuit?
That is a legal question this post does not answer. The only disclosed fact worth noting is that accessiBe sells a Litigation Support Package as a named add-on to paying customers; this post makes no claim about what that package legally accomplishes.
Sources
- accessiBe, accessWidget product page, fetched 2026-09-09
- UserWay, homepage, fetched 2026-09-09
Back to Blog