An accessiBe alternative: the FTC order, the prices, and fixing the source

accessiBe describes accessWidget as an "AI-powered web accessibility and compliance solution". It is installed as a JavaScript snippet, through Google Tag Manager or through a CMS extension. Once installed, accessiBe says, it scans the site, remediates the issues it finds, "enabling keyboard navigation and use with screen readers", and repeats the scan and the fixes every 24 hours. Visitors also get a panel for text size, contrast, spacing and animation, which the pricing page calls "session-based UI modifications", and a newer AI assistant that answers requests such as a plain-language summary of the page.

The company sells more than the widget. accessFlow is a developer tool that audits pages, gives fix guidance and can open pull requests in GitHub. accessServices covers expert audits, VPATs, file and PDF remediation, user testing by people with disabilities, and litigation support. The higher widget plans add yearly manual testing of key pages, after which, in accessiBe's words, experts "apply tailored code enhancements directly to accessWidget". Those fixes live in the widget, not in the site's own code.

accessiBe also publishes a list of "Excluded Issues" that neither accessWidget nor accessFlow resolves. It includes documents and PDFs, audio and video, content in third-party iframes such as payment forms, third-party pages where the widget is not installed, and CAPTCHA. For web and single-page applications, the list says remediation "may not be fully effective" and that verifying accessibility is the customer's responsibility.

accessWidget is priced by traffic, not by page count. accessiBe estimates a domain's average monthly visits from Similarweb data for the past six months and places the site in a plan. A plan covers the pages of one domain; the pricing page FAQ says subdomains need additional plans. Each plan has a monthly and a yearly price, with the yearly option marked "SAVE 30%". As shown on 5 November 2026:

• Micro: $59 /month billed monthly, or $490 /year billed yearly. Up to 5,000 website visits a month.
• Growth: $179 /month, or $1,490 /year. Up to 30,000 visits a month. Adds the litigation support package with a claims portal and a case manager.
• Scale: $479 /month, or $3,990 /year. Up to 100,000 visits a month. Adds yearly expert testing and custom fixes in the widget.
• Enterprise: custom price, above 100,000 visits a month.
• accessFlow (Essential, Professional, Enterprise): "Book a demo". Prices not published.
• accessServices (expert audit, VPAT, file accessibility, user testing, litigation support): "Get A Quote". Prices not published.

On 3 January 2025 the Federal Trade Commission announced a proposed consent order with accessiBe Inc. and accessiBe Ltd. After a 30-day comment period the Commission voted 3-0 to make it final. The Decision and Order was issued on 21 April 2025 under Docket No. C-4817, and the FTC announced it the next day.

The complaint made two kinds of allegation. The first was about performance. accessiBe had claimed that installing accessWidget's "one line of code" made a site compliant with 30 percent of WCAG at once and with the rest within 48 hours. The FTC alleged that "accessWidget did not make all user websites WCAG-compliant" and listed barriers found on sites running it: missing or inaccurate alt text, missing focus indicators, keyboard traps, incorrect headings, and problems with menus, buttons and tables. The second was about marketing: the FTC alleged that accessiBe "deceptively formatted third-party articles and reviews to appear as if they were independent opinions" and did not disclose that it had paid for them.

The order requires accessiBe to pay $1,000,000 to the Commission, which the FTC says may be used for refunds to consumers. It bars accessiBe from claiming that its automated products can make any website WCAG compliant, or keep it compliant as content changes, unless it has competent and reliable evidence. It bars presenting third-party reviews as independent opinions by impartial authors and requires disclosure of material connections with endorsers. One provision matters to every buyer: before a customer pays, accessiBe must disclose that its automated products will not correct barriers on third-party domains or subdomains that are part of the user experience unless those domains also run the product. The order generally runs for 20 years.

accessiBe agreed to the order without admitting or denying the allegations. On its own page about the settlement, accessiBe says it disagrees with the FTC's claims, which it believes "were largely based on flawed testing methodologies and outdated information", and that it settled to avoid a lengthy legal process. The order does not ban the product. It requires evidence behind any claim that automation delivers WCAG conformance.

An overlay is a script. The browser downloads the page, then downloads the vendor's file, and the script edits the page in that browser: it adds attributes, rewrites labels and alt text, and offers a settings panel. The FTC complaint describes overlays as "not intended to permanently alter web code or design" but to allow temporary changes to the interface. accessiBe's own exclusions list refers to changes made to "the user-session code". The HTML your server sends stays as it was.

That has consequences in both directions. A screen reader reads what the browser has built, so a visitor whose browser ran the script may hear the edited version; whether that version is right is the question the FTC complaint tested by hand. Everyone else gets the original: a tester reading the source, a visitor whose browser blocks third-party scripts, and every page on another domain, such as a booking engine or a payment form.

W3C's guidance on evaluation tools puts the limit plainly: "Tools cannot check all accessibility aspects automatically. Human judgement is required." The FTC complaint relied on the same principle and based its findings on manual testing.

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 the source has been fixed and tested, a widget that only offers display preferences may do little harm. Three checks decide it. The widget must not take keyboard focus or announce itself to screen reader users in a way that gets in their way. It must not change what assistive technology hears in ways nobody has tested. And nobody in your organisation should treat it, or its accessibility statement, as the evidence that the site conforms.

Do not remove it in a hurry either. If the widget currently patches a real defect, such as a missing form label, taking it out before the source is fixed makes that defect visible again. Fix first, test with the widget blocked, then decide whether it still earns its subscription.

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.