2024 started with a bang. Besides fireworks and firecracker bangs (please don’t use them by the way, both animals and humans may really suffer from them) I was shocked by the news of a veteran accessibility company announcing they will buy an accessibility overlay provider (even when they wrote negatively about overlays just recently).
I am not the only one to be negatively surprised, everybody that are interested in accessibility seems to be (mostly negatively in my opinion), but some of them also try to have an open mind about it. “Let’s wait and see”…
I don’t believe current overlay solutions work well enough as they often introduce new problems and only fix some parts that are sometimes even fixed automatically by assistive technology (I’ve seen some screen-readers can compensate for missing alternative text on icon buttons for example) or user agents (some browsers can for example add underline to all links as a feature and so on).
Although I am against current overlay solutions I challenge myself to give at least theoretical opportunities to some ideas behind them. In these fast moving tech times where practically all websites have issues, the idea of mass remediation can really be attractive. Provided I see they really have potential to benefit people with disabilities and are not just technology powered ableisms trying to solve compliance problems with fancy black box solutions.
In this post I try to reflect on the idea of accessibility overlay as a tool for accessibility specialist, as a middle-ware – layer between website and user, where automatic accessibility gets upgraded with human powered accessibility specialist and not left to pure algorithms.
Filling the gaps of automatic accessibility overlays with human remediation
After reading a lot of opinions, I wanted to decided to have an open mind as well and try to see the potentials of the future. I am technology optimistic, as a developer and accessibility specialist, I feel, it is kind of part of the job. Of course it should be when it benefits end users, especially people with disabilities. Making progress, fixing problems, improving things, simplifying, making things more effective and scalable is always on my agenda, at least.
Between the lines of the overlay provider acquisition, I could read something that made me think of a potential solution to fill in the gap of current accessibility overlays. What if they were an interface for human accessibility specialists to make changes on target website without going through the normal development cycle?
What if overlays were portals enabling accessibility specialists to manually fix accessibility of target websites, without changing the source?
Reflection on potential improvement of accessibility overlays.
It would technically be possible for a human accessibility specialist to first check all the potential errors found by automatic testing, computer vision, machine learning, large language models and other “artificial intelligence”. Then the specialist would decide and test if automatic fixes would really fix issues found. After automatic part would be done the specialist would also do a manual accessibility audit and try to make the needed remediation through the overlay – to fix (at least some of) the problems manually, directly on the site, via overlay. Overlay would remember the manual changes and apply them each time, on load. If content or template changed the specialist would be informed about that and would need to check the new situation. And so on.
A lot of things could be fixed like this, at least in theory (!). Maybe not the complex components, but basic stuff could be fixed with writing rules and code that would overwrite existing, problematic, front-end on the webpage. It is technically possible and a lot of tools already exist that can do changes to the webpage like this (remember A/B testing tools offered by Google and others?).
Currently I have only seen overlays that need user interaction to be active. For example click on the overlay activation button and then select that it needs to fix links, images, etc. Or maybe that I select low vision profile and then overlay applies it’s magic. That is commonly criticized by accessibility community and I guess that intentions of this new, human powered, generation of overlays would need to just apply all the fixes at load time, for all users, to make things theoretically more accessible.
Back from theory to practice – this kind of remediation comes with a price. Not only for paying for the overlay service (and for paying the accessibility specialist commanding it). The price is actually much higher when we think about it.
Overlay is still a third party script and as such it makes performance and user experience worse
I can imagine overlay re-writing problematic parts of the page, but in the case of classical JavaScript overlays this comes with some huge problems. Normally browsers parse the HTML and CSS and need to execute JavaScript before they can show the page. We then migrated to load JavaScript at the end, when page was rendered and lastly to load JavaScript asynchronously, to get even faster rendering times.
There are many different strategies, way beyond the scope of this post, but best practice is to run JavaScript at the end, asynchronously (opens in new window), not to block the rendering, where possible. It is also possible to run JavaScript as render blocking, meaning that browser needs to wait for JavaScript to load and execute before rendering (showing) the page. This is, as mentioned, normally unwanted due to performance of the page and user experience, but if our overlay needs to fix the accessibility issues it would need to do it like this or the whole page would possibly jump and change in front of the user. And that would mean very poor user experience and very poor technical SEO.
So JavaScript overlay applying accessibility fixes is technically doable, but will bring huge performance issues on the target page. Both people and bots will hate accessibility overlay applying fixes to the page on-the-fly. Waiting even more time for page to render is always a bad thing. If you have done a single technical search engine optimization (SEO) audit, you will for sure remember that render blocking is very high on the list of issues that need to be fixed. This means that such an overlay will degrade technical SEO immediately, not to talk about users. All users, including people with disabilities. And when we also add assistive technology into the situation it will make things even worse for users of assistive technologies.
And not to mention that things on the internet often brake. JavaScript costs a lot (YouTube video from Addy Osmani, opens in new window) to first be downloaded, then be interpreted and at the end make the changes required. When it is loaded and not blocked that is. A lot can go wrong with such solution; people can block third parties due to privacy concerns, a lot of times we don’t have the best internet connection, so overlay fixes may fail to be executed, bugs happen and overlay introduces another possibility to brake other things. Like all third party plug-ins overlays may even enable hackers access to target website and modify things when overlay provider is hacked.
Overlays are and will be limited, even if they bring human powered accessibility fixes
Rewriting problematic parts with help of automatic tools combined with human specialists is still very limited when we need to rely only on JavaScript. It is a bit easier to make a browser extension, as they allow much more control of the page (due to abuse this is less and less true), but requiring users to install a browser extension is often a show stopper for the product, as extensions can’t really be automatically installed and user needs to manually install them. Extensions also mean that each browser needs it’s own extension and are a big disadvantage to marketing of overlays that want exactly the opposite – that websites just work for everybody without installing anything.
Some parts of webpage can be improved with special case coding, but if we need to fix a more complex component we will quickly find lots of limitations and often show-stoppers. Some components allow to be controlled by outside scripts and some don’t allow it in an easy way. Some components may be done with technologies that don’t allow access to them from JavaScript context of the page (web components with shadow DOM), so they can be impossible to get modified and fixed by the overlay.
How could the overlay make captions work for videos if the video player doesn’t support captions in the first place is another viable question in the list of many.
Such remediations are also very fragile. Accessibility specialist fixing code via third party JavaScript could theoretically fix an issue that would re-appear the next day due to some dynamic, random changes on the site (for example element ID attribute value changed etc.).
Will need to wait and see, but it doesn’t look promising
All the arguments above can quickly get me back to my initial opinion that overlays are more trouble than worth. Even if they will become human powered they are limited in the technical possibilities of what can a third party really do to fix accessibility issues.
Maybe they plan to offer parallel experiences, taking content from original site, fix the problems and offer the content on a new URL, but that would still be very fragile and prone to introducing new issues when accessibility specialist will not have a lot of time to check, fix and validate fixes. And in that, dear reader, lies the main issue; we can’t trust automatic tools 100% and we need human specialists (and ideally people with disabilities) that needs to be compensated for their time. So why wouldn’t we just use the money to fix our source code, design and content and drop the third party?
To conclude – I still believe that awareness, knowledge, top to bottom support for accessibility and most importantly dialog with people with disabilities are the still the only sustainable ways to produce as accessible as possible products. Sure, automatic tools are playing much larger roles with every year, but it is still us humans that are needed. And will be for some time, still.
You’re absolutely right! It doesn’t look promising. What kind of solution is that anyway? Pay somebody to write bad code and than pay another guy to fix it!
Why not make it right in the first place?
Instead allowing developers to make shitty websites, we need a culture of quality.
What bothers me most: most people of the world can’t afford to buy a top notch iPhone every autumn and stick with pre-pre-used phones or buy themselves a brand new phone for 20 Bucks at Ali Baba – yes these exist. These people often don’t have an additional computer or something else, that calculates faster and very poor internet connection.
Now imagine if you have yet another (big) JavaScript on a website rewriting the whole code on a device like that.
By the way: the vast majority of human population earns less than 30$ per day. So we’re talking about billions of people!
I strongly recommend to watch Bruces talk “Whose web is it, anyway?” at axe-con 2023
https://brucelawson.co.uk/2023/whose-web-is-it-anyway-my-axe-con-talk/
Hi, Marc, thanks for your comment.
Totally agree with what you wrote, we all need to put more efforts in and actually shift the culture, so that the web will be more accessible, usable and sustainable.
And overlays, in my opinion, work against all three of them – they often make things even less accessible, they are not very usable and they are for sure not sustainable as we can conclude based on the added JavaScript burden.
Thanks, for the link, love what Bruce is doing for the web!