Accessibility overlay

An accessibility overlay is one line of JavaScript sold as a solution. It loads a floating button, usually a wheelchair or a person glyph in a corner, which opens a panel of knobs: bigger text, higher contrast, a dyslexia font, a reading guide, sometimes a cursor the size of a thumb. The promise attached to it is that the site is now compliant. The knobs are real and the promise is not. This entry does not pretend the question is open, because among people who do this work it is not.

Start with what the panel can and cannot reach. Text size and colour are properties of the rendering, so a script can change them, although browsers and operating systems already offer both and do it better. Everything a script cannot reach is where accessibility actually lives: an icon button with no accessible name has nothing for the widget to enlarge, a form whose only error signal is red text still fails use of color after the contrast toggle, a custom control that ignores the keyboard is still unreachable, a video still has no captions, and a heading structure that was never authored cannot be inferred from font sizes. Some overlays attempt exactly that inference, guessing at names and roles and injecting ARIA, which is how they end up making things worse: a wrong name is more damaging than an absent one, because the reader has no way to tell it is wrong. Several also break the assistive technology the reader brought with them, by intercepting keys or repainting the page underneath it.

The consensus is documented, not anecdotal. An open letter against overlays as a substitute for remediation has been signed by thousands of accessibility practitioners, engineers, and disabled users, including many who build the screen readers involved. The Overlay Fact Sheet collects the technical claims and the evidence against them. And the legal argument, which is usually the reason a widget gets bought, runs the other way in practice: sites carrying overlays have been sued over the same barriers the overlay was supposed to have removed, and the widget is not a defence because the underlying page still fails. No conformance level is achievable by a script that does not have access to the authored intent.

The uncomfortable part is why they sell so well, and it is not stupidity. An overlay is a purchase order, and remediation is a roadmap: one is a decision a single person can make this quarter, the other is design work, engineering work, and testing spread across every team. Answering “just buy the widget” therefore needs more than contempt. Name the specific barriers on your own site, show which of them the panel does not touch, and offer the smallest real first step, usually names and labels, keyboard operability, and one honest audit. The features overlay panels advertise are worth having, but they belong in the product, built in and testable, where they work for readers who never find the floating button at all.