Accessibility Overlays: annoying, dangerous, misplaced
Overlay vendors currently work by selling a product that is embedded into a webpage, so it sits in the web layer of the Assistive Technology Stack. These products start as soon as the webpage is loaded, and scan the page for known accessibility issues. Some of these issues are "fixed" by applying rules created by server side scans of the page at periodic intervals. This effectively means that some computer robot occasionally scans the target website, looking for accessibility issues, and creates a rule that is applied to remediate the issue automatically. Still other systems scan the page at runtime, and use services like computer vision to try to give descriptions to images. In this post I will discuss how accessibility overlays, as described above, are annoying, block users from receiving crutial information, present undesirable security issues, and are misplaced in the users technology stack.
Accessibility overlays are annoying
These accessibility overlay systems are either unfortunately running on every instance of a webpage, and must therefore make every user suffer performance penalties as the tool fixes the issues, even if that user doesn't need the fix, or require activation by the user. To make things worse for overlays, websites are expressly blocked by security policies from discovering whether a user is using assistive technologies. This is done because many people with disabilities don't want a website finding out that they have a disability. This info is simply not available to websites, even though in many cases the info is available at the application layer. This means that many accessibility overlays don't choose to apply all the fixes, for performance reasons (see above). The tool instead starts aggressively using techniques designed to annoy users with disabilities to activate the tool, for example, causing screen readers to say that a tool is available repetitively until the user activates the tool. The available things a web accessibility overlay can do are limited by the restrictions imposed by the browsers security sandbox, and the generally slow speed at which javascript can run. For example, these tools are included on individual sites, thus storing settings across sites is not usually possible, because for example, data from hello.com cannot be accessed by goodbye.com without use of methods such as third party cookies, which are slowly being removed from web standards. These tools are annoyhing because of the aggressive techniques needed to convince their users to use them, and the fact that less experienced users not only have to know there is a tool they can use, but use non-standard techniques on random websites to activate them. This causes overlays to not only be annoying but can actually present physical threats to the user.
Accessibility overlays are dangerous
Accessibility overlays are not just bad because they annoy disabled users and are ineffective, they are actually dangerous. The web is not a toy, and is used by billions of devices around the world for incredibly time sensitive information like evacuation maps. Additionally, the web is used to send incredibly sensitive data such as credit cards, national identification numbers, etc.
Physical threats presented by accessibility overlays
Immagine you have to deal with a natural disaster in your local area. You are trying to read reports that are occuring in realtime, and a fire is rappidly moving near you. You have minutes to discover if you need to evacuate and make plans. You load up a local government emergency notification site, and try to start reading the alerts about active evacuation zones. instead of receiving crutial information about the fire occuring near you, your computer tells you to press alt+b to activate some tool. You recently went blind, so you have no idea what alt+b means and you are just barely learning how to handle computer tasks as a blind person. not wanting to use this tool, you try doing what you learned in your training, and press 1 to move to the heading level 1 on the page. This works, and you think you are going to be able to find the content you need. You start reading the content. The tool that previously annoyed you moves you away from where you are reading, and throws your focus to itself telling you to activate it. so you try to ignore it again and read the content. You try this a couple more times, only to finally give up and press enter out of frustration, activating the tool. However, now the tool is applying fixes, and the page is changing under you. You can no longer find the emergency information you need. The emergency information page is less accessible with the tool than it was without it, but you just had precious minutes wasted by it anyway, and now your actual life is in danger.
Security threats
Also, as mentioned above, accessibility overlay products cannot modify pages iframe into them. Overlays cannot be given special permissions by browsers, because by the very nature of scripts being remote, they present a huge security risk to other resources. Imagine what happens if the code from one overlay company is allowlisted in a browser to allow it to run across origin. One day, seeing that this hypothetical overlay is a high value target because it gets to run across origins, an international criminal organization decides to hack this overlay vendor and embed malicious script into the overlay. Now, every time a credit card is entered inside an `iframe origin, this script would be capable of steeling this information. however, these tools not only can't access and fix these embeded tools, they present a security threat to the sites they are trying to fix, even for all the millions of users who do not need them. Imagine there is an accessibility overlay named helloworld. helloworld is used by many major brands including goodguy.com, sweatshirts.com, bobsemail.net, etc. Some of these sites are high value targets, processing personally identifiable information for customers, such as addresses, photos, credit card information, familial relations, etc. Now, imagine that helloworld, being installed on each of these sites is fetched every time the page loads, which is necessary to give customers of each of these products helloworld's a11y fixes. Even though helloworld is cautious of security best practices and its customers all use subresource integrity checks on helloworlds script tags, helloworld needs to be constantly updated with new accessibility remediations. Since helloworld needs these new accessibility checks to be run when the page loads, these checks cannot be included in the subresource checks provided by the first party sites, because helloworld downloads lists of remediations to apply to the site once it loads, and applies real changes to elements on the page to make them accessible as those elements appear on the site. However, one day, helloworld is hacked, and the accessibility checks are secretly modified to inject new script tags into sites processing certain high value information. Additionally, event handlers are covertly added by the unknowing helloworld's remediations that steel user data. All of this happens in the background as part of accessibility overlay remediations. Additionally, some sites have information in the DOM that is not yet visible, like a users stored contact information, which the site fetches in the background, so it is ready when the time comes to actually use such information. This information can be stolen by accessibility remediations without any modification to the visible page. Not a single one of these vulnerabilities is present in installed assistive technologies, because installed technologies do not run on hundreds of thousands or millions of computers that do not need them.
Accessibility overlays are misplaced and don't help disabled users effectively
Additionally, operating systems allow tools for a disabled user to always run, and start when the system starts. The accessibility overlays included on sites are only available for individual sites. Webpages generally are much slower at doing most AI tasks, and are generally not going to be designed to do computer vision tasks, robust synchronized highlighting, etc. These are tasks where having access to the features of operating systems that are directly running on hardware without as many restrictions are desired. Some of these features are simply more versatile on the actual operating system, where they can use as much of the screen as they want and are able to be installed once instead of haphazardly applied on random sites, only to not be available to other sites. An installed assistive technology has none of these restrictions. overlays must try to make everybody happy. There are disabilities that require fixes that then break the experience for someone with other types of disabilities. For example, some people with low vision like higher contrast and annimations that make new elements appearing on the page very obvious. They also like the cursor to blink so that it is easier for them to find. However people with certain cognitive impairments like ADHD sometimes get distracted by these remediations and prefer their own techniques like reduced motion, no animations, no blinking, etc. Installed technologies know what the user wants because the user or a users trusted trainer installed them. In addition to this, installed technologies do not deal with sandboxes and can do much more with the users system. they can grab screenshots of the page to do AI, work directly with the hardware to prevent flashing, have very accurate speech output that can be synchronized with the computers graphics so it can highlight things anywhere on screen, scroll text, control the mouse pointer and keyboard, zoom in on specific regions, install its own drivers, prevent the user from focusing on more than one thing at a time, etc. An installed assistive technology is also going to be available for the user on any site the user desires, not just on sites with the overlay. Since installed tools are not applied by random sites, they can persist user settings, and never require the user to activate them on individual sites. Also, installed assistive technologies are not bound by the security policies of individual sites, so they can freely interact with third-party content. They are installed once, trusted at install time, and only get installed by users who are disabled, not millions of other people thus they do not present a clear and present danger to every user of the sites installing overlays.
Overlays: annoying, dangerous, misplaced
Overlays are very annoying because the enhancements cannot be used by the user on every page, and the web becomes a patchwork of different user experiences. Overlays are dangerous because they break the experience of disabled users, wasting incredibly important time, and bother the user to activate them. Additionally, they modify the page for every single user, opening every single user of such sites up to attacks from a third party. Overlays are misplaced because native, installed technologies can do everything overlays can do, and then some, and they are faster, more secure, and work across sites and origins. When building technical solutions for people with disabilities, accessibility overlays are no one stop shop for accessibility fixes because they are fatally misplaced in the assistive technology stack, and present very real security and privacy threats to millions of unsuspecting customers. They also DO NOT STOP YOU FROM BEING SUED!!