Accessibility Overlays: Why They Will Not Make Your Website Compliant

An accessibility overlay is a third-party script, often sold as a widget or plugin, that claims to make a website accessible by changing the page in the visitor’s browser instead of fixing the underlying code. It will not make your website compliant with WCAG 2.2 AA, the Equality Act 2010 or the Public Sector Bodies Accessibility Regulations 2018 and in many cases it makes the experience worse for the disabled people it is meant to help. Across our work delivering digital services for the public sector, overlays are one of the most common shortcuts we are asked about, so this guide sets out why they fall short and what to do instead.

Overlays and accessibility plugins are usually marketed to organisations without a development team, with the promise of compliance in a single line of code. The appeal is understandable, but accessibility depends on how a website is built and written and a script added afterwards cannot change that foundation reliably.

The short answer comes down to five points. An overlay will not make your website compliant for the following reasons.

• WCAG conformance means meeting every success criterion and no overlay can repair every failure in the source code.
• Automated repairs to alt text, form labels and keyboard access are unreliable.
• Overlays can interfere with the screen readers and settings disabled people already use.
• Detecting assistive technology can expose sensitive personal data about a visitor’s disability.
• UK law looks at whether disabled people can use your service, not whether a tool is installed.

Each point is covered below, along with practical steps for replacing an overlay. The guidance applies to councils, NHS organisations and education providers and to private organisations with duties under the Equality Act.

What Is an Accessibility Overlay

An accessibility overlay is software that applies third-party code, usually JavaScript, to a website in an attempt to improve its accessibility as each page loads. The Overlay Fact Sheet, signed by accessibility practitioners, traces these products back to late 1990s tools that added text-to-speech to websites.

Modern overlays combine two kinds of feature. The first is a toolbar that lets visitors enlarge text or change contrast and the second is automated repair, where a script scans the page and tries to fix problems such as missing image descriptions or unlabelled form fields.

The term accessibility plugin covers a wider group of tools, particularly on WordPress. Some are simply overlays packaged for a content management system, while others help editors check their own content. Tools that help your team fix issues in the code can be useful, but any plugin promising compliance by adding a layer over the existing website has the same limitations as an overlay.

What Overlay Vendors Promise and What Happens in Practice

Overlay vendors typically promise WCAG compliance without code changes, audits or ongoing work. In practice, their features either duplicate settings disabled people already have or attempt automated fixes that cannot understand the content.

Alt text is a clear example of the gap. A script can guess at what an image shows but not why it is on the page, so a photograph of a clinical team might be described as a group of people standing in a room. Accurate descriptions depend on editorial judgement, which is why alt text belongs in the content workflow.

Why an Overlay Cannot Make a Website WCAG Compliant

An overlay cannot make a website WCAG compliant because conformance requires every success criterion to be met and overlays can only repair the problems their scripts can detect and interpret. The Overlay Fact Sheet notes that automated repair of text alternatives, form labels, error handling, focus control and keyboard access is not reliable and that overlays do not repair content in PDFs, media files or canvas elements.

Detection itself has clear limits. When the Government Digital Service tested 10 automated accessibility tools against a page containing 143 deliberate barriers, 29% of those barriers were missed by every tool and the most effective single tool found 41% of them once manual inspection prompts were counted. If testing tools built for specialists miss that much, a script trying to detect and fix issues as a page loads cannot be relied on to close the gap.

Many remaining issues depend on meaning rather than markup. Whether a heading describes its section, whether an error message explains how to correct a field and whether link text makes sense out of context all require human judgement and the WCAG 2.2 specification is written around those outcomes for users.

How Overlays Affect Disabled Users

Overlays can make websites harder to use for disabled people, because they interfere with the assistive technology and settings those users already rely on. In a joint statement, the European Disability Forum and the International Association of Accessibility Professionals said that overlays can override user settings and may prevent access to content and that they do not make a website compliant with European accessibility legislation.

Most people who need larger text or a screen reader have already configured their devices. The W3C Web Accessibility Initiative publishes guidance on changing text size and colours through the browser and explains that it chose instructions over a widget because widgets change only the website they are on. A toolbar therefore duplicates tools the user already has and adds another interface to learn.

The size of the audience makes this a service delivery issue as well as a compliance one. GOV.UK guidance on accessibility requirements for public sector websites states that at least 1 in 5 people in the UK have a long term illness, impairment or disability and many more have a temporary one. For a council or NHS Trust, that is a large share of the people using its online services.

Privacy and Security Concerns With Overlay Scripts

Some overlays raise data protection concerns because they detect when a visitor is using assistive technology and adjust the page automatically. The Overlay Fact Sheet explains that this detection can reveal that the person using the device has a disability and that some products store those settings in a cookie that follows the user across other websites running the same overlay.

Under UK GDPR, data concerning health is special category data and the ICO’s guidance on what counts as special category data notes that information about disability can fall into that category where it reveals something about a person’s health. Any tool that infers disability from visitor behaviour should be reviewed by your data protection officer first.

There is also a security question. An overlay is third-party JavaScript loaded on every page, so the vendor’s code can change the content and forms of your website at any time and it deserves the same supplier assurance as any other script with that level of access.

The Legal Position in the UK

Installing an overlay does not meet your legal obligations in the UK, because the law is concerned with whether disabled people can use your service, not the tools you have bought. For public sector bodies the requirement is specific and for other organisations it sits within the duty to make reasonable adjustments.

Under the Equality Act 2010, service providers must not discriminate against disabled people and the duty to make reasonable adjustments applies to them. Section 20 of the Act requires reasonable steps to avoid substantial disadvantage, including steps to provide information in an accessible format. An overlay that conflicts with a screen reader is difficult to present as a reasonable step when the barriers it was meant to address are still in the code.

Public sector bodies face a more precise test. The Public Sector Bodies Accessibility Regulations 2018 require websites and mobile apps to be accessible and to publish an accessibility statement and current GOV.UK guidance sets WCAG 2.2 AA as the standard. GDS monitors a sample of public sector websites each year and the Equality and Human Rights Commission enforces the requirements in England, Scotland and Wales, with the Equality Commission for Northern Ireland responsible in Northern Ireland.

The accessibility statement is where an overlay often causes trouble. A statement must describe how accessible the website is and which content is not accessible, so an organisation relying on an overlay still has to report the underlying failures. Our guide on how to write an accessibility statement covers what the statement needs to include.

WCAG is not named in the Equality Act, which does not refer to any technical standard for websites. In practice, WCAG 2.2 AA is the benchmark auditors and procurement teams use, so it is the most reliable measure for private organisations too.

What Real Accessibility Work Involves

Real accessibility work fixes barriers in the code, design and content of the website itself, so the improvements stay in place whatever tools a visitor uses. It starts with an audit that combines automated scanning with manual testing, because the GOV.UK Service Manual’s guidance on testing for accessibility warns that some issues will be missed if you rely on automated testing alone.

The work then follows a clear sequence. Fixes are prioritised by impact on users and legal risk.

Priority Pixels’ website accessibility audits and remediation follow this pattern. Our audits include a manual review against WCAG 2.2 Level AA across critical user paths, an automated scan with axe-core and WAVE, a severity-ranked issue register and a prioritised roadmap, plus an accessibility statement template and a free re-audit after remediation.

Remediation typically covers keyboard navigation, alt text, colour contrast, form labels, error messages, heading structure, ARIA attributes and focus indicators. Because these changes are made in the code, they remain in place when a toolbar is removed. Our comparison of accessibility testing tools explains how scanning tools fit alongside manual checks.

Replacing an Overlay With Lasting Fixes

If your website already runs an overlay, the safest approach is to plan its removal alongside an audit. Removing it will not make the website less compliant, because the overlay was never making it compliant, but an audit shows what needs fixing and in what order.

Feedback from disabled users is valuable at this stage. Speaking to people who use screen readers, keyboard navigation or magnification will show you where the most serious barriers are.

Cost is usually the reason overlays are chosen. A subscription leaves nothing behind when it ends, whereas remediation improves the website permanently and carries over into future redesigns. Keyboard access is a good place to start and our explainer on keyboard accessibility sets out what good looks like.

Building Accessibility Into Public Sector Websites

The most reliable way to avoid overlays is to build accessibility into the website from the first wireframe, so there is nothing for a script to patch. That means accessible design, semantic code and content workflows that keep standards in place after launch.

Priority Pixels designs and develops all WordPress websites to WCAG 2.2 AA as a minimum, hand coded without page builders or templates. Prototypes are tested with keyboard navigation and screen reader simulation before development begins. Our WordPress development work uses an in-house framework built for accessibility, security and long term support.

Launch is not the end of the work, because new pages, documents and images can introduce barriers at any time. For public sector clients, ongoing accessibility monitoring picks up issues introduced through content updates and WordPress training helps internal teams publish accessible content without outside support. Sound foundations, informed editors and regular checks keep a website accessible in a way no overlay can.