A UserWay alternative: what the widget does, what it costs, and fixing the code

UserWay's main product is the Accessibility Widget. On its home page UserWay describes it as AI-powered technology "that automatically finds and fixes common issues with every page load". The pricing page describes the core feature, Automated Remediation Technology, as fixing "many common accessibility issues directly within your website or application in real time", with human-in-the-loop oversight. Visitors also get more than 100 personalisation tools: a screen reader, contrast and saturation settings, bigger text, text spacing, link highlighting and similar controls.

Next to the widget UserWay sells monitoring, which it describes as continuous scanning for violations "in your source code", manual accessibility audits, VPATs, and a Litigation Support Program on annual plans. Its own description of the audit is telling: it is there to "identify code-level issues that automation can't detect through a manual evaluation". The Usage Stats add-on, in UserWay's words, shows which widget features are used "to help guide source-code remediation". The vendor itself treats the source as the place where some problems have to be fixed.

UserWay is owned by Level Access. Level Access announced on 20 March 2024 that it had completed the acquisition, and described what UserWay brought as automated remediation, "the ability to apply AI and human-driven automated fixes to live experiences". UserWay's site now calls Level Access "our parent company", and its pricing page points organisations with larger programmes to the Level Access Platform.

UserWay publishes prices on two pages, both read on 5 November 2026. The widget page has a Monthly and a Yearly view ("SAVE 16%") for sites with up to 100K page views a month; the pricing page shows annual prices only. The Litigation Support Program is listed for annual plans only.

• Pro: $49/ monthly, or $490/ year. Monitoring of 10 pages.
• Pro Plus: $119/ monthly, or $1,190/ year. Adds Usage Stats, Modify Menu and Live Translations, and monitoring of 50 pages.
• Ultimate: $249/ monthly, or $2,490/ year. Monitoring of 100 pages.
• Accessibility Pro Widget plans on the pricing page: Small $490 / year (up to 100K page views a month), Medium $1,490 / year (up to 1M), Large custom (over 1M).
• Expanded monitoring, on its own or inside a plan: $990 / year for 100 pages, $4,490 / year for 500 pages, $10,990 / year for 1,500 pages.
• Accessibility audits and VPATs: "Talk to us". Prices not published.

The FTC's 2025 order against accessiBe binds accessiBe alone. It is still useful reading for anyone buying a widget, because it shows what the regulator asked for when a vendor claimed full WCAG conformance by automation: competent and reliable evidence, and a clear disclosure that the product does not fix barriers on third-party domains that do not run it.

The US Department of Justice took up overlays in its 2024 rule on web accessibility for state and local governments. It noted comments raising concerns about overlays and automated checkers, and answered that the rule sets a technical standard for web content and mobile apps and does not address the internal policies or procedures an entity uses to meet it. The test is the content itself, against WCAG 2.1 Level AA. W3C's guidance on evaluation tools adds that "Tools cannot check all accessibility aspects automatically. Human judgement is required."

Practitioners have been blunter. The Overlay Fact Sheet is a statement signed by accessibility specialists and users with disabilities. It lists UserWay among the overlay products it discusses, and its signatories commit to advocating "for the remediation of accessibility issues at the source of the original error". It is a professional position, not a regulator's finding.

"With every page load" is the mechanism. The browser downloads your page, then the widget's script, and the script edits the page in that browser. The HTML your server sends is unchanged, so the fix is made again on every visit. A screen reader reads what the browser has built, so a visitor whose browser ran the script may get the edited version. Everyone else gets the original: a tester reading the source, a visitor whose browser blocks third-party scripts, and any page on another domain, such as a payment provider or a booking engine.

Some things a page script cannot reach at all: a PDF, a video without captions, a form inside a third party's iframe. And some it can only guess at: whether an image description is accurate, whether a custom menu makes sense with a keyboard, whether the order of a page matches its meaning. Those are the criteria where a person has to look.

The alternative is to fix the page itself and keep checking it. It has three parts.

Audit. A person tests a defined set of pages and journeys against WCAG with a keyboard and a screen reader, and records each failure with the success criterion, where it occurs and how severe it is. Automated scans cover part of WCAG; the audit covers the criteria that need judgement, such as whether alt text is meaningful or whether a custom menu can be operated.

Remediation. The failures are fixed where they start: in templates, components, content and documents. A missing label is added to the form markup, a keyboard trap is removed from the component's code, a PDF is tagged. The fix ships as ordinary HTML, so every visitor, every browser and every tester receives it, with or without any script.

Monitoring. Sites change every week. A scheduled rescan of the same pages catches the regressions automation can see, and a repeat manual check after a redesign catches the rest.

That is the shape of our own work: a WCAG audit by a person, with findings by criterion and severity and a remediation plan, fixes made in your code, and monitoring that rescans your pages and reports what got worse. None of it requires removing a widget first.

If you already pay for UserWay monitoring or an audit, keep the findings: a list of code-level issues is the input to remediation, whoever writes the fixes.

If the source is fixed and tested, a widget that offers display preferences may do little harm. Check that it does not take keyboard focus or announce itself in a way that gets in a screen reader user's way, that it does not change what assistive technology hears in ways nobody has tested, and that nobody treats it as proof the site conforms.

Do not remove it in a hurry. If the widget patches a real defect today, removing it before the source is fixed brings that defect back. Fix first, test with the script blocked, then decide.

Our free overlay checker fetches one address and reads the HTML source without running it. It compares the src and href of every tag that loads a resource (ordinary links to a vendor's site are ignored) with the script addresses of seven vendors: accessiBe, UserWay, EqualWeb, AudioEye, AccessiWay, Recite Me and Allyable. In the same pass it runs 13 source-level checks: page language, title, the h1 heading, skipped heading levels, image alt attributes, form labels, links with no text, vague link text, positive tabindex, the main landmark, character encoding, the viewport and zoom, and table headers. The result is a score out of 100 and up to eight finding types, each with its WCAG criterion. Finding an overlay does not change the score.

Because nothing is run, the findings describe the page as your server sends it, before any widget has acted. That is the point: it is the version a tester reads in the source, and the version every visitor gets if the script fails to load. A widget added through a tag manager does not appear in the source and is not named, and contrast, focus order and keyboard behaviour are not measured. Our free scan goes further on the same address: where its browser pass can run, it also measures the rendered page, which catches faults such as colour contrast, and the result says which checks it could not run.

Then test by hand. Pick the journeys that matter (sign-up, search, checkout, a contact form). Go through each with the keyboard alone, then with a screen reader, once with the widget running and once with its script blocked in the browser's developer tools or a content blocker. Write down where the two runs differ. Those differences are exactly what the widget is carrying for you, and what a fix in the source has to replace.