Accessibility overlay: the widget cannot fix your sale

An accessibility overlay cannot fix a sale if the underlying website still prevents disabled buyers from completing the checkout or enquiry path without it.

In April 2025, the US Federal Trade Commission finalised an order requiring an overlay vendor to pay $1 million over claims that its automated product could make websites compliant with accessibility standards. That was a US enforcement case, not an EU compliance ruling. It still exposes the commercial mistake behind the pitch: treating a floating button as evidence that the underlying website has been fixed.

The button is not the test. The test is whether somebody can find the offer, understand it, use the controls, recover from an error and finish the checkout or form without a mouse.

TL;DR: Treat the complete buying path as one accessibility test. Turn the overlay off, test every step with a keyboard and assistive technology, fix defects in the source, then keep the path in your release checks. A widget can be an optional aid. It cannot be your acceptance criteria.

What an accessibility overlay actually changes

“Accessibility overlay” is used for a few different products. Some add a toolbar with controls for contrast, text size, spacing or motion. Others insert a script that tries to detect and alter page elements automatically. Many combine the two and attach a dashboard score or compliance claim.

Those controls are not automatically useless. A visitor may prefer one of them, and a temporary layer can sit alongside a genuine remediation programme while source-code fixes are being shipped. The problem starts when the layer is sold or accepted as the fix.

The website beneath it still has headings, buttons, form labels, focus order, status messages and third-party embeds. If those are broken, a toolbar has to guess what the developer meant. It can mislabel a control, duplicate behaviour already provided by a browser or screen reader, or interfere with a visitor's own settings. The joint statement from the European Disability Forum and the International Association of Accessibility Professionals is blunt: overlays are not an acceptable substitute for fixing the website itself and can interfere with assistive technology.

The fair position is not “every widget is evil”. It is simpler: useful personalisation is optional; accessible code, content and processes are not.

Why the checkout decides whether the website works

Accessibility is often reviewed page by page. A homepage gets scanned, a few colour contrasts get changed, the score turns green and the job is declared complete. Buyers do not experience your website that way. They experience a process.

The W3C's guidance on WCAG conformance says that when a page forms part of a complete process, every page in that process must conform. Its example is an online shop: product selection, basket, address, payment and confirmation all belong to the same job.

The same principle applies to a service business. The process might be:

1. Arrive on a service page.
2. Compare the offer and terms.
3. Open the contact form or booking tool.
4. Complete required fields.
5. Understand and correct an error.
6. Submit successfully.
7. Receive a clear confirmation.

One broken step breaks the result. The embedded calendar traps keyboard focus. The cookie banner covers the submit button at 200% zoom. An error turns the field border red but never explains the problem in text. The payment provider opens a modal that the screen reader does not announce. Each page may look respectable in a dashboard. The buyer still cannot finish.

If the checkout fails without the overlay, the site is still inaccessible. The badge only made the failure easier to ignore.

This is why accessibility belongs inside conversion-first website work. The form, booking or payment is not a legal footnote bolted onto the design. It is where access and revenue meet.

Why the dashboard score cannot prove accessibility

Automated testing is useful. It catches repeatable defects quickly: missing labels, some contrast failures, invalid markup and certain problems with accessible names. Run it in development and in production. Just do not confuse coverage with proof.

The W3C's evaluation guidance states that no tool alone can determine whether a website meets accessibility standards. Knowledgeable human evaluation is required. A scanner can detect that an image has alternative text; it cannot reliably decide whether that text helps a person understand the image. It can see that a form field has a label; it may not know whether the label makes the requested information clear.

That distinction matters when a vendor presents a score such as 96/100. Ask what the denominator contains. Was the booking journey tested or just the landing page? Was the test run with the overlay enabled? Did anyone use a screen reader? Were validation errors, timeouts and failed payments checked? Did the third-party tools make it into scope?

The FTC's final order is a useful warning against absolute automated-compliance claims. It does not mean your overlay vendor is breaking the law, nor does it decide whether your European business is covered by a particular rule. It means the promise deserves evidence stronger than a score generated by the product being sold.

Is an accessibility overlay enough for the European Accessibility Act?

No widget can answer that question for your business. The European Accessibility Act has applied since 28 June 2025 to selected products and services, including e-commerce platforms, but coverage, exemptions and obligations depend on what you provide and how your business operates. Get specific legal advice if scope is uncertain.

What an owner can decide without pretending to be a lawyer is whether the website's critical path works. That is a better operating standard than buying a script and waiting for a complaint to reveal what the dashboard missed.

How to test the buying path without the widget

Start with one transaction or enquiry, not the whole website. Pick the action that matters most to the business and write down every step from arrival to confirmation. Then disable the overlay and run the path in realistic conditions.

1. Use only the keyboard

Put the mouse aside. Use Tab, Shift+Tab, Enter, Space and Escape. You should always know which control has focus, reach controls in a sensible order, operate menus and modals, and leave every component you enter. A keyboard trap is not a minor inconvenience. It ends the process.

2. Listen, do not just look

Run the path with VoiceOver on macOS or iOS, or NVDA on Windows. Listen to the link and button names without looking at the screen. “Learn more” repeated six times is useless out of context. So is “button, unlabeled” at the final step.

This is an initial technical check, not a substitute for testing with disabled users. Your team knows the intended interface too well. People who use assistive technology every day find assumptions that a scripted audit will not.

3. Increase text size and zoom

Zoom the browser and increase text size. Check whether the navigation, cookie controls, forms and error messages remain visible and usable. Watch for horizontal scrolling, clipped labels, buttons hidden behind sticky elements and instructions separated from the field they describe.

4. Make the form fail on purpose

Submit an empty form. Use an invalid email. Miss a required consent box. Let a timed session expire if the process has one. The W3C's form guidance treats labels, instructions, notifications and error recovery as part of accessible completion. The message should identify the problem in text, move attention sensibly and explain how to fix it.

5. Test every third-party seam

Booking tools, payment providers, maps, chat widgets, consent managers and video players are part of the customer experience even when another company wrote the code. Record which vendor owns each defect, but keep ownership of the outcome. “That is inside an iframe” will not help the buyer finish.

6. Check the confirmation

Submission is not the last line of code. Confirm that success is announced, visually clear and persistent enough to understand. State what happens next. If the user is returned to the top of the same form with no message, the process is not complete in any useful sense.

7. Keep evidence somebody else can inspect

For every failure, save the URL, browser, device, assistive technology, steps to reproduce, expected result and actual result. Attach a short screen recording. Assign an owner and deadline. When it is fixed, rerun the same script with the overlay off.

That small evidence pack is worth more than a badge. It tells a developer what to repair, tells an owner what remains risky and gives the next release a regression check.

What to ask before you pay for an overlay

Do not ask only whether the product is “WCAG compliant”. Ask what work it changes and what evidence survives if you remove it.

• Which defects are repaired in our source code, CMS templates and content?
• Which changes exist only while your script loads?
• What happens when the script is blocked, delayed or conflicts with another tool?
• Which browsers, screen readers and mobile devices are included in manual testing?
• Will you test our whole checkout or enquiry path, including third parties?
• How are disabled users involved in evaluation?
• Can we inspect the issue list, reproduction steps and retest evidence?
• Who fixes new defects after a design, content or vendor update?
• What claims can you support without using your own dashboard as the only evidence?
• Can we cancel the product without losing the underlying improvements?

A credible answer separates convenience features, automated detection, manual evaluation and source-code remediation. A vague answer wraps all four in the word “compliance”.

If procurement needs a one-line acceptance gate, use this: the critical path works with the overlay off, and the evidence is repeatable by someone who did not build it.

What durable accessibility work looks like

Durable work is less theatrical than installing a widget. It starts with a prioritised defect list and changes the components that create the problem everywhere: navigation, buttons, forms, modal dialogs, error messages and content templates. It includes the awkward third-party conversations. It adds automated checks to development, manual checks to releases and periodic testing with disabled users.

It also treats accessibility as maintenance. A compliant-looking launch can decay when a new cookie tool ships, a CMS editor skips heading levels, a campaign page copies an old form or a payment provider changes its embed. The same weekly shipping rhythm used for conversion, performance and content is the practical way to keep those changes visible.

The trade-off is honest. You give up the comfort of an instant badge and accept a real backlog. In return, the site becomes easier to use, the evidence becomes auditable and the improvement remains when a subscription script disappears.

You do not need to rebuild everything before taking the first useful step. Choose the path that creates the enquiry or sale. Test it. Repair the source. Add the test to the next release. Then move to the next critical process.

If you want a senior technical read on that path, book a 30-minute call. Bring the page that matters most; we will map the breaks from first click to confirmation and give you a fix-it order.

Plan. Build. Iterate.