An AudioEye alternative: what the automation covers and what it leaves

AudioEye, Inc. is listed on Nasdaq and files annual reports with the SEC. Its 10-K for 2025 says it earns its revenue mainly from subscriptions to software that "finds and fixes common accessibility errors", designed to help sites reach "substantial conformance with AudioEye's interpretation of" WCAG. Next to the software it sells periodic auditing, custom fixes by experts, legal support, PDF remediation and mobile app audit reports. Subscriptions run month to month or for one or more years, and the base offering has a 14-day free trial.

The same filing is candid about the limit of the automated part: "We recognize that automation alone cannot fix all accessibility issues", and "We believe there is no fully automated solution on the market that can provide 100% compliance." It also says AudioEye works "without fundamental changes to the website architecture". The website puts a figure on the automation: the plans page says the automated tools address about 50 percent of accessibility issues, and the home page says AudioEye can "fix up to 50% of issues detected within minutes of installation".

Installation is a script. AudioEye's integration page tells site owners to copy the AudioEye JavaScript and paste it globally in the footer, and says the software "delivers approximately 100kB of compressed JavaScript to a client's browser", loading after the page itself is ready. The automated fixes therefore happen in the visitor's browser, on each page view.

The plans page, read on 5 November 2026, shows three plans and no prices. Prices are not published; the first plan offers "Get Started" and the other two "Talk to an Expert".

• Basic Protection (Automated): "Basic monitoring & automated fixes". Automated tools for about half of accessibility issues, continuous monitoring, a help desk and self-paced learning. Expert testing for the remaining issues is not included.
• Self-Serviced Protection (Self-Managed): "We guide you to fix at source". Developer tools, expert guidance, training, a scanner and an expert audit with reporting.
• Maximum Protection (Managed): "We manage accessibility for you". Automated tools, monitoring, audits, custom-written fixes for your site, AudioEye Assurance and an expert audit with reporting.

AudioEye is worth reading as two products. The automated half is an overlay in the mechanical sense: a script edits the page after it reaches the browser, and the HTML your server sends stays as it was. A screen reader reads what the browser has built, so a visitor whose browser ran the script may receive the edited version. A tester reading the source, a visitor whose browser blocks the script, and any page on another domain, such as a payment provider, get the original. PDFs and media are outside a page script's reach, which is why AudioEye sells PDF remediation separately.

The service half is different. An expert audit is a person testing your pages, and the Self-Serviced plan is explicitly about fixing "at source". If you are already an AudioEye customer, part of the alternative may be in the same contract. One question to ask before relying on custom fixes: are they written into your code, or deployed through AudioEye's script? AudioEye's home page says its experts "write and deploy" fixes to the site, without saying where they live. The answer decides whether a fix survives the end of the subscription.

W3C's guidance on evaluation tools draws the same line AudioEye's filing does: "Tools cannot check all accessibility aspects automatically. Human judgement is required." The FTC's 2025 order against another vendor, accessiBe, binds that company alone, but it shows what the regulator expects when automation is sold as WCAG conformance: competent and reliable evidence behind the claim.

Assurance comes only with a Managed package. AudioEye describes it as "limited, guaranteed financial protection against WCAG-related demand letters and/or lawsuits", subject to the terms of the customer's order. It is a contractual promise about money, so the place to read it is the order itself: what counts as a covered claim, the limits, and what the customer has to have done. It is not a statement that the site conforms to WCAG.

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 hold an AudioEye expert audit, it is a usable starting point: a list of failures by criterion is the input to remediation, whoever writes the code.

If the source is fixed and tested, a script that monitors the site and offers a help desk may do little harm. Check that it does not take keyboard focus or change what assistive technology hears in ways nobody has tested, and that nobody treats it or Assurance as proof the site conforms.

Do not remove it in a hurry. If the automated fixes patch a real defect today, removing the script before the source is fixed brings that defect back. Fix first, test with the script blocked, then decide which part of the contract you still need.

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.