Accessibility overlays, widgets and real fixes

If you’ve looked into accessibility for your site, you’ve probably heard two opposite things. Some vendors say one script makes your site compliant. Some blog posts say overlays are a scam and you should never install one. Neither is the whole story, and a lot of the store owners I talk to are stuck somewhere between the two.

We sell an accessibility widget, so read this with that in mind. But we would rather you understand what the product does than buy it for something it cannot do.

What people mean by “overlay”

An overlay, or widget, is a script you add to your site. It puts a small button on every page. Visitors click it and get a panel where they can change how the page looks and behaves: bigger text, more line height, a different font, higher contrast, a reading guide, text read aloud, fewer animations.

Some products stop there. Others also change the page under the hood as it loads, patching common mistakes in the HTML. And some, the ones that earned the word “overlay” its bad reputation, claim that this alone makes a site meet WCAG and protects you from complaints.

That last claim is the problem. The panel and the patches can both help people, but no script can promise that.

What a widget genuinely does for visitors

Think of the widget as a settings panel for your site. It helps people who need the page to look or behave a bit differently and do not have, or do not want, special software for it.

• Someone with low vision bumps Font Size up two steps and turns on High Contrast.
• Someone with dyslexia switches to the Dyslexic Font and adds Line Height.
• Someone with ADHD turns on the Reading Mask so only one strip of the page is lit.
• Someone with a hand tremor turns on Big Cursor and Stop Animations, so less moves around under their pointer.
• Someone who is tired uses Text to Speech to hear paragraphs read aloud.
• Someone who reads better in another language switches the panel itself to one of 44 languages.

None of these people are rare, and many of them don’t use a screen reader or think of themselves as disabled. A good widget meets them on your page, with profiles that switch on a set of adjustments for low vision, cognitive needs, ADHD or motor difficulties in one click. That’s what the Accessora widget is for.

The panel does little for screen reader users. They bring their own tool, and the best thing a widget can do for them is stay out of the way. It shouldn’t open by itself, grab focus, or change settings they’ve already set up. A widget that fights assistive technology makes your site worse for exactly the people it claims to help.

What runtime fixes can do

Some widgets also patch common defects when the page loads. These patches change the page’s accessibility tree, so they reach screen reader and keyboard users too. Accessora’s automated fixes, on the Enterprise plan, are rule-based and include these:

• Buttons and links with no accessible name, such as an icon-only “close” button, get a name guessed from the icon, an image or a title attribute.
• Images with no alt attribute get one from their title or label. If they have neither, they get an empty alt, which tells screen readers to skip them. Real descriptions come from AI alt text, a separate feature.
• Form fields with no label get one from nearby text or a placeholder.
• Where heading levels skip, for example from H1 to H4, hidden placeholder headings fill the gap. That keeps checkers happy, but the placeholders carry no real text, so fixing the headings in your theme is still the real fix.
• Missing landmarks such as main and nav are added so people can jump around the page.

This helps most with the parts of a site that nobody edits by hand, like a third-party embed or a theme update that changed some markup. The fixes run on every page load, so they also reach content added since your last audit.

What runtime fixes cannot do

A fix applied in the browser is a best guess made in a few milliseconds by a script that does not know what your page is for. It cannot:

• Write captions or transcripts. A video without captions stays without captions. That is a job for a person.
• Fix contrast baked into images. Gray text on a light photo, text inside a banner image, a logo with no contrast against the header. A script can change CSS colors. It cannot repaint a JPEG.
• Make custom components work. A dropdown built from div elements, a modal that does not trap focus and does not return it, a carousel with no pause button, a date picker that only works with a mouse. These need their keyboard behavior and ARIA written properly in the source.
• Remove keyboard traps. If focus goes into an embedded map or a chat window and never comes out, nothing a script adds on top will reliably get it out.
• Rewrite confusing content. Error messages that say “invalid input”, forms that ask for the same thing three times, a checkout that times out silently. These are design and copy problems.
• Fix documents. PDFs, slide decks and spreadsheets you link to are outside the page. They need their own treatment.
• Judge quality. A generated alt text is a draft. Only you know that the photo is there to show the stitching, not the color.

If a vendor tells you their script handles all of the above, ask them to show you, on your own site, with a keyboard and a screen reader.

Why “install it and you are compliant” is wrong

WCAG is a standard for the pages you publish: the code, the content and the components, on every page and in every state. It is tested against the page as it is delivered to the visitor. A script can improve that page. It cannot certify it, and it cannot touch the categories above.

Sites with overlays installed still receive accessibility complaints and demand letters, and some of those complaints named the overlay itself as a barrier. A badge that says “accessible” won’t help you if the checkout can’t be completed with a keyboard. If anything, it makes the gap easier to spot.

Then there’s the “do no harm” rule. A widget that pops open on every visit, hijacks keyboard shortcuts, ignores the operating system’s reduced-motion setting, or slows the page down is a net loss even if the panel itself is lovely. Any widget you install should load asynchronously, respect user settings, and be easy to switch off feature by feature.

What a sensible setup looks like

Here is what we think a small team should do, in order.

1. Audit. Run a scan across your main page paths: home, a category, a product, the cart, the checkout, the contact form. Get a list of issues with the WCAG criterion each one fails and the elements it affects. Automated scans find many of the common problems, and they are the cheapest place to start.
2. Fix the source. Work through the list in your templates and components, so the fix applies to every page at once. Prioritize what blocks people: keyboard access, form labels, contrast, alt text on images that matter, heading structure.
3. Test by hand. Tab through your checkout. Zoom the browser to 200 percent. Open one page with the screen reader built into your phone or laptop. You will find things no scanner can.
4. Add the widget. Give visitors the adjustments described above. This is for them, not for your audit score.
5. If you use runtime fixes, leave them on as a safety net. They catch some of what slips in between audits, such as new embeds and theme updates.
6. Re-scan on a schedule. Accessibility drifts. A monthly scan and a quick look at the issue count keeps it from drifting far.

Accessora is built around that order. The widget gives visitors the adjustments, and on Enterprise it also runs the automated fixes. The dashboard runs the audits and lists each issue with its WCAG criterion and the elements it affects. On Growth and Enterprise it also writes draft alt text for images that have none. Compare plans to see what each one includes. We would rather show you an issue list with fifteen things on it than a green badge.

Questions to ask any vendor, including us

• Do you claim my site will be compliant after installing? If yes, walk away.
• Can I see the issues the product cannot fix, not only the ones it can?
• Does the widget stay out of the way of screen readers, and can I check that myself?
• Does it respect reduced-motion and the visitor’s own font and zoom settings?
• Can I turn off individual runtime fixes if one of them guesses wrong?
• Does the script load asynchronously, and how big is it?
• Where does the visitor data go, and what is collected?

The honest summary

A widget lets visitors adjust your pages to suit them, starting the day you install it. Audits and fixes in your own code are what move the site toward WCAG. Most sites benefit from both, and neither one replaces the other.

If you want to start somewhere concrete, read How to write alt text that actually helps and then WCAG 2.2 in plain English for small sites. Both have changes you can make this week, whether your site runs on Webflow, plain HTML or anything else. Then, once the list is shorter, add the widget.