Accessibility overlays don't fix your site

If you run a website, someone has probably offered you a one-line fix for accessibility. Paste a script, get a toolbar with a little icon in the corner, and the site is taken care of. It's an appealing pitch. It doesn't hold up.

An overlay runs in the visitor's browser after your page has loaded. It tries to guess what the page should have said and patch it on the fly. The page your server sends is unchanged. The missing labels are still missing. And screen reader users, who already have their own tools set up the way they like, now have a second set of controls competing with theirs.

We're not lawyers, and nothing here is legal advice. If you've received a demand letter or are worried about one, talk to an attorney. This post is about what makes a site work for the people using it.

What actually fails

Most accessibility problems are boring and specific. When we scan sites against WCAG 2.1 AA, the same kinds of problems keep coming up:

• Images with no text alternative, or with the file name as the description. A menu posted as a photo is the worst case: the whole menu is invisible to a screen reader.
• Text that doesn't contrast enough with its background, like light gray on white, or white on a busy photo.
• Focus you can't see. Tab through the page and the outline vanishes, so a keyboard user has no idea where they are.
• Things you can't reach by keyboard at all: menus that only open on hover, pop-ups with no way to close them.
• Form fields with no label, so a screen reader announces “edit text” and nothing else.
• Links that say “click here”, and buttons that are just an icon with no name.
• Headings picked for their size rather than their place in the page outline.

None of these are hard to fix in the source. All of them are hard to fix reliably from a script that's guessing.

Fix the source, or fix the output

The right fix is in the page itself. Write the alt text. Change the color. Put the label on the field. Bring back the focus outline. If your site runs on a theme or a page builder, the fix often belongs in the template, so it applies to every page at once.

Sometimes a rebuild isn't in the budget and the content can't be touched. That was the situation with the website retrofit: restaurant and venue sites that worked, but failed accessibility checks. We fixed what the site outputs, in a layer on the server, without editing the content. The difference from an overlay is the one that matters: the page arrives correct, instead of being patched afterwards in the visitor's browser.

We also replaced menu images with text menus and wrote descriptions for the images. Then we proved it: automated crawls, keyboard tests, and a before-and-after report anyone can read.

Check every morning

A site that passed an audit in January has changed by March. Someone uploaded photos without descriptions. A plugin update changed the menu. A new landing page went up with a gray-on-gray button. A yearly audit PDF describes a site that no longer exists.

That's why we scan every site daily. Each one gets a score, sorted worst first, with each problem explained in plain English and the fix written out. It also says what changed since yesterday. A new problem caught the morning after it appeared is a small fix. The same problem found eight months later is an archaeology project.

Automated scans don't catch everything. They can tell you an image has no alt text. They can't tell you the alt text is wrong. So pair the daily scan with a short manual check whenever something big changes: tab through the page, zoom to 200%, and try it with a screen reader.

Hold your tools to the same standard. Any dashboard or report you use for this should pass the standard it checks.

Keep a record

Fixing problems is the work. Writing down that you fixed them is what lets you show it later. Keep a dated record of what was found, what was fixed and when, and what's still open with a plan for it. We write separate reports for developers and for legal, because those two readers want different things from the same facts.

Publish an accessibility statement too. Say which standard you aim for, what you know isn't there yet, and how someone can reach you if they hit a problem. Then answer when they do.

Where to start

1. 1.Take the overlay off, if you have one.
2. 2.Run an automated scan against WCAG 2.1 AA and fix the template-level problems first, since they repeat on every page.
3. 3.Tab through your five most important pages without a mouse. Fix anything you can't reach or can't see.
4. 4.Replace any menu or price list posted as an image with real text.
5. 5.Set up a daily scan, so new problems show up the day they appear.
6. 6.Start the record, and publish the statement.

None of this needs a toolbar. It needs someone to own it and a check that runs whether or not they remember.