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. Aggressively annoying users to activate them, the overlays often disrupt users, while failing to remediate any accessibility challenges the users may have, and failing to educate developers and other website stakeholders of their inaccessible practices. These products start as soon as the webpage is loaded, and scan the page for known accessibility issues, applying supposed fixes for millions of users who don't need the fixes. By applying the fixes for everyone, these tools expose millions of website users who do not need them to security vulnerabilities and performance issues. As any tech in the web layer does, these tools have no access to operating system functions, and cannot be installed across the entire web. These tools cannot adequately fix the experience for users with complex impairments, and are ineffective at best even as even temporary solutions.
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 info is not presented to websites, since most people with disabilities don't want websites finding out and tracking protected disability status. 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 annoying 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
Imagine you have to deal with a natural disaster in your local area. You are trying to read reports that are occurring in Realtime, and a fire is rapidly 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 crucial information about the fire occurring 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 heading 1 you were using is now gone for some reason, as part of a "ai generated fix." 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. These annoyances have become so disruptive to some screen reader users that extensions have been created to block the network resources of various accessibility overlay. That's right, these companies product do such a bad job at helping the users they claim to help that users are resorting to blocking those products from working.
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 somehow permitted to be allow listed 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, defeating one of the most powerful security primitives on the web. however, these tools not only can't access and fix these embedded 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 fixme.inc . fixme.inc 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 fixme.inc , 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 accessibility fixes identified by fixme.inc . Even though fixme.inc is cautious of security best practices and its customers all use sub resource integrity checks on fixme.inc 's script tags, fixme.inc needs to be constantly updated with new accessibility remediations. Since fixme.inc needs these new accessibility checks to be run when the page loads, these checks cannot be included in the sub resource checks provided by the first party sites. If this were the case, the integrity hash would need to be updated every time new fixes were added, which would be a huge burden on the website developers. Given that fixme.inc applies real changes to elements on the page to make them accessible as those elements appear on the site, these dynamic updates that are applied have quite a bit of power. Imagine, one day, fixme.inc 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 new malicious fixme.inc remediations that steel user data. All of this happens in the background as part of accessibility overlay remediations and the user has no idea this is happening. Additionally, some sites preload 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. Accessibility overlays can see anything in the webpage, even things that aren't visible yet, if they are physically on the page. Not a single one of these vulnerabilities is present in installed assistive technologies, because installed assistive technologies do not run on hundreds of thousands or millions of computers that do not need them. Simply put, the attack surface of an installed assistive technology, even a web extension or user script, is simply only limited to the users who have installed it.
Accessibility overlays are misplaced and don't effectively help disabled users
Operating systems allow tools for a disabled user to always run, and start when the system starts. Meanwhile, The accessibility overlays included on sites are only available for individual sites. They don't migrate with the user, presenting an interface that users always have. 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 animations that make the location of new elements appearing on the page very obvious. Some also might 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. There are even people with severe forms of epilepsy that really don't want things blinking, spinning, etc. as a matter of personal safety. Installed technologies know what the user wants because the user or a user's trusted trainer installed them, set them up, and customized 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. Being present for everyone, they increase the attack surface for potential vulnerabilities to every user of the web page, even users who do not benefit from the remediations. Overlays are misplaced because native, installed technologies can do everything overlays can do, better than a web page can, and then some, and they are faster, more secure, and work across sites and origins. They also target specific users who want them, rather than overlays in the web layer, which target millions of unsuspecting users who need no extra fixes.
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!!