Overlay alternatives: what to use instead of a widget

If a client has been sold an accessibility overlay — a script that adds buttons and "fixes" on top of their site — you have probably been asked whether it means the job is done. Here is the honest answer, the reason behind it, and what to put in its place. We do not name the vendors here, and we are not going to: the argument does not depend on which one it is.

What an overlay actually does

An overlay is JavaScript that runs in the visitor's browser. It adds a floating button, a panel of reading options, and often cosmetic changes around the page. What it does not do is change the page's HTML. You can check this yourself in thirty seconds: view the page source with the overlay installed and look for the image with no alt, the icon link with no name, the unlabelled input. They are all still there, exactly as before.

Why that matters

• Anything that reads the page without running that script sees the original problems: a screen reader following a link to the page, a search engine, a PDF export of the page, an email client preview, a browser with heavy script blocking, or the same page printed.
• The problems that an overlay genuinely can improve — contrast, font size, spacing — are the ones a careful stylesheet fixes properly, for everybody, without a toolbar to discover.
• The problems it cannot touch at all — alt text that means something, labels that say what to type, heading order, table headers, error messages that are announced — are the ones that actually block people from completing a task.
• An overlay often makes a legally risky promise on the client's behalf. Buyers have been fined for claims of that kind; whatever the wording, certification is not something a script can issue.

What to use instead, in order

1. A scan, to build the work list. Automated checks find the mechanical problems and quote the exact markup: missing alt text, empty links and buttons, unlabelled fields, heading skips, tables without headers, frames without titles, zoom-blocked viewports. That is the cheap third of the job, and it is the part you can start today.
2. Fixes in the markup, page by page. Every finding has a correct answer, and it is usually small: an attribute, a label, a heading level, a caption.
3. Keyboard testing. Unplug the mouse and complete the client's main task. Twenty minutes of this finds more than any report.
4. Screen reader testing of the flows that earn money. Checkout, booking, contact, the account area. Nothing else substitutes for it.
5. Monitoring, so a new page or a plugin update does not quietly reintroduce the problems you just fixed.

Steps 1 and 5 are what software can do properly, and that is what AccessAudit does: it finds what can be proven from the HTML, keeps a monthly eye on the pages that matter, and says out loud which parts only a person can judge.

Talking to a client who already bought one

Do not start with an argument about the vendor; that sounds like a competitor talking. Ask two questions:

1. "Can we see the underlying page source before and after the widget was installed?" The answer is the demonstration.
2. "Which parts of our checkout does the widget fix?" Then test one flow with a screen reader, or simply with the keyboard, and write down what blocks you.

Then propose something small and concrete: a scan of the pages that convert, a fixed set of markup fixes, and a monthly re-test. Clients rarely want to remove the widget while they are paying for it — that is a sunk-cost conversation. They do accept a work list that makes the widget irrelevant.

What we will not do

We will not sell you an overlay, and we will not claim that our scanner makes a site compliant. The honest position is worth more than the convenient one: automated checks of this kind cover part of the problem, they say which part, and every finding they produce can be checked by a stranger in ten seconds.

See how the tool works Check any page free What no plugin can check