Bolt-On Accessibility Is Not Compliance: A 2026 Argument for Retiring the Overlay Widget

Every few months a procurement conversation reaches the same juncture. A team has been told its platform is not accessible, a deadline is approaching, and someone has found a vendor offering a single line of JavaScript that will, apparently, resolve the problem. The appeal is obvious: a small script is cheaper than a design system overhaul, and it can be live before the end of the sprint.

The argument here is that this is a false economy, and that the legal framing used to justify it does not hold up. Overlays are not inherently useless — some offer genuinely helpful user-controlled preferences — but they cannot substitute for accessible design and testing.

What UK law actually asks for

The Equality Act 2010 places a duty on service providers not to discriminate against disabled people, and that duty is anticipatory: organisations are expected to think about barriers in advance rather than respond case by case after a complaint. The Equality and Human Rights Commission's statutory code of practice makes clear that reasonable adjustments can extend to the way a service is delivered, including its digital channels.

Separately, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require covered organisations to meet WCAG 2.2 at level AA, publish an accurate accessibility statement, and maintain a feedback route. Monitoring is carried out on a sample basis, and statements that do not reflect the actual state of a site are themselves a finding.

Neither instrument says anything about widgets. Both say a great deal about outcomes: can a disabled person perceive, operate, understand and navigate the service on equivalent terms?

Where the bolt-on approach breaks down

Overlay products typically work by injecting markup and styles into an existing page. That approach collides with reality in predictable ways.

• Assistive technology conflicts. Screen readers already interpret the underlying document. Additional ARIA, duplicated labels and restructured headings can produce double announcements, orphaned elements or contradictory semantics.
• Focus and keyboard behaviour. Custom menus and toolbars layered onto a page frequently trap focus, obscure content or break skip links.
• Content problems remain. A widget cannot rewrite a convoluted paragraph, add captions to a video, or correct a form that asks for information in a confusing order.
• Documents and third-party journeys. Linked PDFs, embedded payment flows and identity verification steps sit outside the script's reach.
• Performance and mobile layout. Injected stylesheets interact unpredictably with responsive breakpoints, sometimes worsening the experience on the small screens where many disabled users do most of their browsing.

There is also the question of who the overlay is for. Tools that offer font size, contrast and spacing controls provide welcome choice to some users. That is different from claiming the underlying service has been made accessible.

The compliance theatre problem

Perhaps the most serious risk is reputational and evidential. A published accessibility statement asserting conformance, backed only by an overlay, is difficult to defend once it is tested. In the UK, enforcement remains less litigious than in the United States — where overlay deployments have featured in a number of claims — but the regulatory picture here is tightening rather than loosening, and procurement questionnaires increasingly ask for evidence of testing rather than the name of a vendor.

For teams in regulated sectors — financial services, health, utilities, education — the overlay also tends to fail internal risk review. A control that cannot be evidenced through test results is not a control.

A remediation roadmap that holds up

Stage one: establish the actual position. Commission an audit against WCAG 2.2 AA that covers templates, transactional journeys and documents, not just the homepage. Record the results honestly, including where they are poor.

Stage two: fix the systemic issues first. Colour contrast, focus visibility, heading structure, form labelling and error identification are usually template-level problems. Correcting them in the design system resolves thousands of instances at once.

Stage three: train the people who create content. Most accessibility failures are introduced by well-intentioned authors working without guidance. Plain language, meaningful link text, alt text conventions and document exports belong in editorial standards.

Stage four: build accessibility into definition of done. Automated checks in the pipeline catch perhaps a third of issues. Manual keyboard testing, screen reader passes and testing with disabled participants catch the rest. Neither replaces the other.

Stage five: publish truthfully. An accessibility statement that names known gaps, sets out a timetable and gives a working contact route is more defensible than a claim of full conformance that cannot be substantiated.

Making the case internally

The strongest argument is rarely moral exhortation; it is cost of rework. Teams that defer accessibility spend the same money later, at a point when the architecture is fixed and the fixes are more expensive. Framing remediation as defect reduction — fewer support calls from users who cannot complete a form, fewer abandoned applications, fewer escalated complaints — tends to move the conversation faster than reference to statute.

Where overlays are retained, they should be positioned accurately: as optional user preferences alongside a genuinely accessible baseline, never as the baseline itself. The distinction matters, because it is the one a regulator, a procurement panel or an aggrieved user is most likely to test.