Accessibility overlays are not an acceptable accessibility solution

If you manage a website you’ve probably come across accessibility overlays. The makers of these products (sometimes also called accessibility widgets), claim that they automate the process of making a website accessible. In fact one well known company providing these tools uses the phrase, “Technology that works, so you don’t have to”. The pitch from these companies is so reassuringly simple, ‘Install this widget and your site will be accessible, job done’. 

The difficulty is that accessibility does not work like that.

What overlays actually do

An accessibility overlay is a piece of third-party code added to a website. It typically provides a toolbar allowing users to adjust contrast, increase text size, pause animation or to read the site aloud. These tools can give the impression that accessibility has been ‘added’ but overlays sit on top of the existing site. They do not fix structural issues within it.

If headings are incorrectly structured, the overlay does not rewrite your HTML.

If images lack meaningful alternative text, it cannot reliably infer intent.

If your ticketing journey cannot be completed by keyboard alone, an overlay does not rebuild it.

Accessibility issues are often embedded in design decisions, content practices and technical implementation. They require thoughtful correction, not a cosmetic layer.

Interference

Many disabled users already have carefully configured accessibility settings in place, at operating system, browser or assistive technology level. These settings are personalised and refined over time and overlays can override or interfere with these configurations.

For example, users of JAWS, Voiceover or NVDA do not need each overlay toolbar item to be read out by a site specific screen reader. Some toolbars inject unnecessary ARIA-labels into a website’s HTML markup causing unnecessary, unclear or duplicate labels.

Some toolbars may change the visual labels of buttons or links without changing the accessible name, making it difficult or impossible to target those elements as a speech-to-text user.

In attempting to ‘fix’ accessibility, overlays can remove control from the user. Accessibility should support user autonomy not impose an alternative system on top of the one they already rely on. In a survey conducted by WebAIM, 69% of accessibility practitioners rated overlays as not very or not at all effective (amongst respondents with disabilities, this increased to 72%).

The Illusion of completion

The other reason overlays can be problematic is that they can cause an organisation to believe that accessibility has been ‘dealt with’ and the subject moves off the agenda.

Accessibility becomes something visible but superficial, a toolbar badge rather than an embedded practice. Meanwhile, the barriers remain embedded in the site’s structure.

Legal and reputational implications

It is also worth noting that overlays do not automatically ensure compliance with recognised accessibility standards such as WCAG. Structural failures can still leave organisations exposed to complaints or legal challenges.

As the A11y Collective point out in their excellent article on the topic, by using an overlay you’re actually proving that you understand accessibility requirements, and that you’re choosing “a surface-level fix over genuine remediation”. From a legal perspective this is extremely risky. Additionally, the European Commission has made it clear that in their view overlays are not an acceptable solution to fix accessibility issues: “Overlays, or any other tools which do not ensure the website itself meets the detailed criteria of the standard, are not an appropriate solution. It is best to fix accessibility issues at their source”.

Aside from potential legal issues, the reputational risk is also real. Disabled users are highly aware of overlays and the debate surrounding them. Installing one without addressing underlying barriers can be perceived as performative rather than substantive.

Accessibility is not a feature you install

An accessible website is the outcome of:

  • Well-structured, semantic code
  • Logical information hierarchy
  • Clear content design
  • Robust keyboard functionality
  • Meaningful alternative text
  • Sufficient colour contrast          
  • Testing with real users

It requires collaboration between users, designers, developers, content teams and leadership. There is no single switch to turn it on.

A more sustainable approach

Instead of asking, “What can we install?”, the better questions are:

  • Where are our biggest barriers?
  • Which issues have the highest impact on users?
  • How do we build accessibility knowledge into our team?
  • How do we ensure improvements are sustained over time?

Overlays promise speed and a quick fix, whereas a meaningful approach to accessibility requires intention and genuine commitment.