Accessibility overlays: what they can and cannot fix

An accessibility overlay is third-party technology added to a website, usually through JavaScript, that changes how the page appears or attempts to alter its front-end code. Some products add a toolbar for text size, colour or spacing. Others claim to identify and repair accessibility problems automatically.

Those features may help in limited situations, but an overlay cannot understand every piece of content, repair every interaction or prove that a store meets WCAG or legal requirements. It should not replace work on the underlying design, content and code.

The terms are often blurred in marketing, so separate the jobs before assessing a product.

• An overlay runs on top of an existing page and changes presentation or markup after the site has been delivered.
• An evaluation tool reports possible problems so a person can investigate and fix them.
• A built-in accessibility feature is deliberately designed into the product, component or content.
• Source remediation changes the original design, HTML, CSS, JavaScript, media or workflow that caused the barrier.
• Assistive technology and browser settings belong to the user and work across many sites, rather than being attached to one store.

A scanner such as AccessPeek is an evaluation tool, not an overlay. It reports detectable issues and does not modify the scanned website.

Products vary. A toolbar may offer controls for larger text, different colours, increased spacing, reduced motion or simplified presentation. An automated-remediation product may try to add labels, roles or image descriptions.

A particular user might find a particular control useful, especially on a shared or locked-down device. That possibility should be evaluated with users rather than assumed. Many comparable preferences already exist in browsers, operating systems and assistive technologies.

The European Disability Forum and International Association of Accessibility Professionals (opens in a new tab) recognise the potential of emerging technology but state that none can instantly fix an inaccessible website. Their joint statement also warns that some overlays can override user settings or interfere with assistive technology.

Accessibility frequently depends on meaning and context. Software may detect that an image lacks alternative text, but it cannot always decide whether the image is decorative, describe the information that matters in that shopping context, or determine that nearby text already provides an equivalent.

The same problem appears throughout an online store. A script can see code; it cannot reliably understand every customer’s task or judge whether the overall experience makes sense.

• Whether product-image descriptions communicate the details needed to choose an item.
• Whether headings and labels describe the content clearly rather than merely existing.
• Whether focus moves logically through menus, dialogs, filters and checkout.
• Whether a custom product selector works predictably with different assistive technologies.
• Whether form instructions and errors help a customer recover from a mistake.
• Whether captions, transcripts or audio descriptions accurately represent media.
• Whether third-party checkout, chat, review or payment tools remain usable.

W3C’s guidance on evaluation tools (opens in a new tab) is direct: tools can quickly identify potential issues, but they cannot check every accessibility aspect and cannot determine accessibility. Human judgement remains necessary, and automated results can be false or misleading.

WCAG conformance is a claim about complete pages and processes, not the presence of a widget. W3C’s conformance guidance (opens in a new tab) describes testing as a combination of automated testing and human evaluation.

An overlay therefore cannot be treated as a compliance certificate. If a vendor promises instant, complete or guaranteed compliance from one script, ask for precise evidence covering the entire site, every customer process, supported assistive technologies and ongoing content changes.

It can. A script that rewrites names, roles, focus behaviour or visual presentation after page load may conflict with the original code, a user’s browser preferences or assistive technology. The risk depends on the product, page and user, so test the actual combination rather than relying on a demonstration.

There are also operational questions. What happens if the vendor script is slow or unavailable? Does it process information about users or detect assistive technology? Can customers opt out? Does it work inside third-party frames and payment services? Accessibility, privacy, performance and security reviews should all be part of procurement.

Use automation as an efficient finder, then fix the source of each confirmed problem. This produces improvements that remain part of the site rather than depending on a layer loaded afterward.

1. 1Map important tasks: finding a product, choosing options, creating an account, paying and requesting support.
2. 2Run automated checks on representative pages and treat the results as leads, not a verdict.
3. 3Fix confirmed issues in the theme, component, content or third-party integration that introduced them.
4. 4Test every critical journey using only a keyboard and with relevant screen readers.
5. 5Include disabled users in evaluation where practical; W3C notes that this reveals usability issues conformance evaluation alone can miss.
6. 6Re-test after fixes, theme releases, app updates and major content changes.
7. 7Assign ownership so accessibility becomes part of normal design, content and development work.

If you are evaluating a product, require testable answers instead of a general accessibility badge.

• Which exact WCAG success criteria can the product test or change, and which remain manual?
• Can you provide results from independent testing with disabled users?
• How does the product interact with screen readers, zoom, browser preferences and keyboard navigation?
• What happens when the script fails to load?
• What user data is collected, and can assistive-technology detection be disabled?
• Who fixes issues in source code, documents, media and third-party services?
• Does the contract promise legal compliance, or does the marketing merely imply it?

Run a free one-page accessibility scan (opens in a new tab) to identify common machine-detectable barriers on a public store page. Review each result, fix confirmed problems at their source, then expand into manual testing of the full buying journey.

AccessPeek does not modify your site and does not claim to make it compliant. That narrower promise is intentional: automation is valuable when it tells you what it can see and remains honest about what it cannot.