AudioEye fixes in live JavaScript. TrustScans helps you fix the source.

AudioEye says its “JavaScript evaluates your site’s structure and fixes accessibility issues in the live code before a user ever visits the page,” and that “Custom fixes are delivered via AudioEye’s JavaScript that runs in live code” [Source: AudioEye, platform]. It says automation “handles approximately 50% of detected issues in real time” [Source: AudioEye, platform].

AudioEye also sells 24/7 monitoring and says its platform “tests 37 of 55 WCAG 2.2 A/AA criteria” [Source: AudioEye]. Its plans include an accessibility scanner and expert audits, and managed plans with Assurance include “limited, guaranteed financial protection against WCAG-related demand letters and/or lawsuits” [Source: AudioEye, plans]. We did not find dollar prices published on its plans page on the date we checked [Source: AudioEye, plans].

For developers, AudioEye offers an MCP server that “lets an AI coding agent scan a live page for accessibility issues and propose source-level fixes” [Source: AudioEye, MCP server].

A lot of it. AudioEye monitors sites continuously, sells expert audits, and gives coding agents an MCP server that proposes source-level fixes [Source: AudioEye] [Source: AudioEye, plans] [Source: AudioEye, MCP server]. TrustScans monitors, reports and connects to coding agents over MCP too.

AudioEye does not describe its product as an overlay, and we describe it here in its own words. The practitioner-written Overlay Fact Sheet does list AudioEye among its examples of overlays [Source: Overlay Fact Sheet], because its fixes are delivered by JavaScript in the live page [Source: AudioEye, platform].

1. 01

   Nothing is installed on your site

   TrustScans loads your public pages in a real browser from the outside, the way a visitor would. There is no snippet, no toolbar and no change to what your visitors receive. Your site changes only when your team changes it.

2. 02

   Fixes happen in your code, where they reach everyone

   Every finding comes with plain-language guidance on why it matters and how to fix it, written for each rule we test. A fix in the source reaches every visitor, whatever browser or assistive technology they use.

3. 03

   Context, not just a verdict

   Each finding names the WCAG success criterion, the pages it appears on, the element’s selector and HTML, and a highlighted screenshot for the first occurrences on each page. When the same markup fails on three or more pages we flag it as a likely shared component, so one fix can clear them all.

4. 04

   A score you can explain to anyone

   The score counts confirmed WCAG failures only, and the method is explained in the app and in the PDF report. Items that need a person to judge, and best-practice recommendations, are kept in their own lists and never move the number.

5. 05

   Honest about what automation can find

   We never tell you a scan makes a site compliant. The W3C’s guidance is that evaluation tools “can not determine accessibility, they can only assist in doing so” [Source: W3C WAI]. Our reports say what failed, what needs a human, and what we could not test.

6. 06

   An agent loop that ends with a verification scan

   Our MCP server gives a coding agent a prioritised work queue, each issue’s selector, HTML, WCAG criteria and screenshot, and lets it mark issues resolved with a note and start a new scan. The score only moves when that scan confirms the fix. Around it sit recurring scans, regression alerts, report views by role, and PDF and CSV exports.

AudioEye’s approach is to fix issues in the live code through its JavaScript [Source: AudioEye, platform]. Independent groups argue that fixes belong in the site itself. The European Disability Forum and the International Association of Accessibility Professionals say overlays are not “a substitute for fixing the website itself” [Source: EDF and IAAP, 2023], and the Overlay Fact Sheet’s signatories commit to “the remediation of accessibility issues at the source of the original error” [Source: Overlay Fact Sheet].

In January 2024 an article in the National Federation of the Blind’s Braille Monitor asked AudioEye, UserWay and accessiBe to stop leading customers to believe “their accessibility widgets alone are the only way that true accessibility can be achieved” [Source: Braille Monitor, Jan 2024].

Why TrustScans doesn’t build an overlay→