Web accessibility overlay tools: lies and gum balls

Note: the name of the article “lies and gum balls” is based on a French play on words with the expression “mystery and gum ball” (“mystère et boule de gomme” in French) which means that something is very mysterious.

You may have seen websites with buttons called “Accessibility” or with an icon of a person in a wheelchair or an icon based on the Vitruvian man. Or, yet again, you may have never noticed them because they are sometimes quite hidden. We will call them here “accessibility overlays”.

When you click on one of these buttons, it generally opens a panel with a lot of options to, amongst other things, customise the website’s appearance: increasing text colour contrasts, increasing font size or line height, stopping animations, etc.

Icon of a person in a wheelchair commonly used to represent disability. (Source of the icon)

Icon based on Vitruvian man used to represent accessibility. This icon is from the GNOME project. (Source of the icon)

On the web, these buttons are becoming more and more present. They are said to be “web accessibility solutions” or “digital accessibility solutions” that make websites accessible. Sometimes, the companies publishing these tools even say that this will make the websites compliant with the RGAA (Référentiel Général d’Amélioration de l’Accessibilité, the French accessibility reference) or the WCAG (Web Content Accessibility Guidelines, the international standard) at AA level (double A, the legal level expected in European and French legislation in particular).

While these tools can sometimes improve the user-friendliness of certain websites or help you comply with certain accessibility criteria (on this subject, you can read my article “Text colour contrasts (Part 3): the contrast improvement mechanism” on Tanaguru’s blog), the way they are deployed and sold raises questions. Moreover, sometimes it adds new accessibility or usability issues to the website. Sometimes it doesn’t fix anything at all because it doesn’t work completely.

There’s a lot of blame on these tools. Some people need arguments, sources when it is suggested to them to install this kind of tools instead of implementing a global accessibility approach for a website. I think it is therefore necessary to take stock of the subject to know where we go.

Why accessibility overlay tools exist?

Web accessibility overlay tools exist and are very fashionable because:

WCAG rules can be very (too much?) permissive by allowing the use of mechanisms to meet some criteria such as the one about contrasts.
The first version of the WCAG was published in 1999. However, it is still not possible to ensure that designers produce accessibility-compliant mock-ups and that developers produce accessibility-compliant code. Accessibility is only just beginning to be included into training courses for web professions – and even then, at this stage, we are only talking about raising awareness on the subject when it should be an integral part of every discipline taught.
Because websites are not designed in an accessible way from the start, the correction towards accessibility is expensive. Because people who create websites are not trained on accessibility, designing accessible from the start is also expensive.
For the same preceding reasons, creating a website that is accessible to people with disabilities and complies with accessibility rules may therefore take a little longer than we would like.

In response to this, some companies have found a trick: creating tools that promise to make websites accessible or even compliant with accessibility rules (and therefore with the law) in just one click. One line of code and it’s all good. Of course, it’s a dream come true. And it’s only a dream.

What is wrong with these web accessibility overlay tools?

1. The lies and the unsaid, a lack of ethics

– So, I click here and bingo! It makes a website accessible? Magic!!!

Colourful gum balls — Gum balls, colourful like an accessibility overlay tool, but it’s sticky and it’s very sweet… (Photo by Freepik)

– Ahem, actually, no! It’s funny, when I activate the high contrast mode, there are colours that don’t change and remain as orange text on a white background!
– Here, when I increase the font size, the texts are coming out of the container and are overlapping. Oh, but these aren’t getting bigger!
– Argh! Why isn’t the keyboard navigation working?! Noooo! They blocked keyboard navigation to force me to use their tool by clicking this button to activate keyboard navigation! A little bit more and they blocked my mouse pointer to ask me if I want to activate mouse navigation! Oh dear! Now I focus on headings that are not even clickable!
– Ah! But when I ask to stop animations, it doesn’t stop the carousel which turns automatically without ever stopping!
– What the hell are these tools? We are promised unicorns that fart rainbows and all we get are gum bubbles that explode in our faces!

Voilà, that’s me talking in my head while I’m testing web accessibility overlay tools. The results aren’t so great, are they?

Many companies publishing accessibility overlay tools lie to sell their product. Lies are often displayed very proudly on the sales website, are conveyed via advertising videos or in sales speeches. All this is misleading publicity. Sometimes the messages are more subtle. Some companies make sure to turn their sentences well in their communication. Thus, people who know nothing about it think that these tools actually make websites accessible and compliant and think that, therefore, they will not need to modify the source code of their website. Sometimes, these companies let journalists talk rubbish about their tool. Thus, it is these journalists who convey the false information, which serve the brand. And the brand does not contradict them. Anything seems good for business. But, on the other hand, if all the journalists say the same nonsense, couldn’t it be because they are told nonsense or because the brand is misinforming them?

It is a lie to say that these tools can make a website accessible, because while a tool may indeed improve navigation for some people with certain disabilities, it will never be able to cover all needs for all disabilities (which have different forms and degrees). For example, many accessibility criteria are about relevance. How could these tools alone judge the relevance of a link label, a form field label, a button label, a heading, the alternative of an image, etc.? How could they make a component, that only works with mouse, work with keyboard because it is made without button but with <div> (an HTML element that is not compatible with keyboard navigation)? The tools must start by guessing that these <div>s are indeed buttons and then the behaviour must be transcribed with the right status for a person using a screen reader (example: for a button opening an accordion, the button must say whether the accordion is open or closed).

Fun fact: once, I was on the “Accessibility” page of a website that had a legal obligation to make it accessible to people with disabilities. And, what do I see? This page was promoting an accessibility overlay. Apparently, the company thought it was a magical tool. It wrote that its website was accessible thanks to this tool and, accessible to all types of disabilities. There was a small list of disabilities that included deafness. Beside this list, I found a video advertising the tool: not subtitled and therefore inaccessible to deaf and hard of hearing people. The evidence is there under the company’s eyes. But the company’s lack of knowledge about accessibility and the dishonesty of the company selling the tool, which does not clearly explain things to them, make this kind of situation exist.

So, as you have understood, accessibility and compliance with accessibility rules at level AA (double A) cannot be fully achieved with these tools.

Moreover, for an organisation obligated by the French law (article 47 of the Act No. 2005-102), an accessibility overlay will never allow a website to comply with that Act. Indeed, the law requires the following points:

Publication of the accessibility statement for the website (French documentation);
Publication of the multi-year plan defined to make the organisation’s website accessible (French documentation) as well as the action plan for the current year. This multi-year plan cannot exceed three years;
Publication of the level of compliance to the RGAA on the home page (French documentation).

Therefore, this involves carrying out a compliance audit of the website based on a representative sample of the website’s pages (French documentation). Afterwards, it will be necessary to take the necessary steps to make the website accessible and to comply with its multi-year plan, at the risk of having complaints from users for inaccessibility of the website.

I also read that these tools would help for Search Engine Optimization (SEO). This is also false because when we say that respecting the accessibility rules can improve SEO, it is when we respect the rules in the HTML code, especially concerning the relevance of the <title> element or the headings structure in the content. Accessibility overlay tools can’t do this properly (or can’t do it at all) and therefore can’t improve SEO.

2. Features that don’t always work

My little monologue in the previous chapter showed you that these tools can’t make websites compliant because sometimes, it doesn’t work the way we want it to. As they are mostly added on websites that do not comply with accessibility rules, this happens very frequently.

I invite you to go and see the website of these companies that create these tools and to test their accessibility overlay directly on their website: activate the high contrast mode, increase the font size, etc. You will often see elements on the website where the text becomes unreadable.

If it works rather well on these companies’ websites, go and find the websites of their client companies to test.

3. Adding new accessibility issues to websites

Not only all the features of these tools don’t always work, but they can also add new accessibility problems to the websites.

This is the problem when people make accessibility tools without having bothered to be trained on the subject. They think they can solve problems but they are creating new ones. I’m not saying that they don’t want to do the right thing, but, in fact, accessibility is not as simple as we would like to believe.

Among the most common problems are the misuse of ARIA or the use of icon-buttons without a label inside, so when you disable style sheets, you can’t see the button anymore (I wrote an article (in French) on how to do it right, by the way). I also encountered one of these tools that is totally unusable with keyboard it-self even though it has a “Keyboard Navigation” feature; it’s totally confusing.

If you want to use an accessibility overlay tool, ask third party experts to ensure that it is accessible. What an irony to sell a tool by saying that it makes websites accessible when it isn’t accessible itself!

4. Lack of overall ergonomics and the learning phase

Accessibility overlay tools have presentation and features that are sometimes quite similar to each other but that are also sometimes completely different. There are differences that are already enough to make it impossible to identify or find them on the web page.

Sometimes it is a button in the header of the website, clearly visible. Sometimes it is hidden in the footer. Sometimes it is a sticky button on the left, right, bottom, middle of the web page, it depends. Sometimes there isn’t even a button because the tool is configured on the brand’s website and you arrive on the already configured website without realizing it (so you don’t always understand why the website is all broken…). Sometimes it’s an icon with a person in a wheelchair, which makes identification difficult because persons with a cognitive disability, for example, will not really recognize themselves in it. Sometimes it is an icon of a simplified Vitruvian man; in which it is also difficult to identify oneself. Sometimes it’s the brand logo, so if you don’t know the tool, it’s impossible to know what’s behind it. Sometimes the button is called “Accessibility”, but that may mean anything for everyone either.

You have to realize that there are people who have one or more disabilities and don’t know it (or not yet). It’s quite common to have a diagnosis of cognitive impairment in adulthood, for example. Therefore, identifying oneself in an icon or a word related to disability or accessibility is not possible for these people whereas they may also need to customise the website’s appearance to better read information, for example.

Once the button has been found and understood, people still have to learn how to use the tool. Since there are many different ones, it’s a new learning curve each time. I can imagine that you can spend even more time configuring them than actually finding the information you were looking for.

I would be curious to see the independent results of user tests of these different tools.

5. Limited utility

Web accessibility overlay tools have limited utility.

On one hand, they cannot cover the needs of all disabled people for all types of disabilities. For example, they don’t cover the needs for deaf and hard of hearing people because they don’t subtitle videos (and if they did, it wouldn’t be 100% satisfactory since to this day, automatic subtitles still need to be corrected humanly). These tools also do not cover the needs of blind people because they do not know how to make elements relevant when they are not, or how to make scripts accessible to screen readers.

On the other hand, on individual websites, they offer means of compensation, but this does not solve anything: people will still have to go through their operating system and browser, or even a search engine before arriving on the website with the overlay tool. So how were they able to get there without a dedicated tool? If the companies making these tools really cared about people with disabilities, they would make tools that can be used on all websites (or even on all computer software) and not only on websites that have paid for their “solution”, which is not really one.

It sometimes covers needs that could be covered by more global solutions and therefore benefit users all the time. Instead of promoting these much better tools and making them even better, we reinvent the wheel. For example, some of the accessibility overlay tools have screen reader functionality while software’s exist and thankfully do work for the whole computer.

The way these tools are sold is proof that people with disabilities are being laughed at and that it’s just a matter of business: not only are the arguments dishonest, but if they really wanted to solve access difficulties for some users, they would create browser add-ons or software / applications and not widgets that every website has to pay for and install. And, of course, these would have to be promoted so that people who need them would know about them and use them.

As for myself, carousels that run in a loop, animated GIFs, animations of all kinds prevent me from reading websites content because it distracts me. We see them everywhere but they propose as a solution to only fix this problem in the websites that use these widgets? That’s not how it should work! I need to be able to stop animations everywhere! Websites must fix this problem individually but let’s be realistic, the web is not accessible (see the WebAIM study on the accessibility of a million websites). People who make websites don’t know about accessibility or don’t care at all. It is therefore in the browser that I, as a user, would like to be able to act, for lack of anything better. Besides, when I come across articles with animated content everywhere, I don’t take time to look for a “Stop” button hidden I don’t know where in the website: I just leave.

6. What about privacy?

What about privacy with these tools? How do these tools that save profiles in cookies or local storage work? Concerning the paid tools, there is data that goes to the tool’s company (it can be seen when the uBlock Origin add-on is installed on the browser to block ads and others). This makes it a third party tool that collects data from users; and, very often, without their consent since the GDPR (General Data Protection Regulation) is still not respected (another law that companies don’t care about!).

Moreover, if you are concerned about your privacy and you block third-party cookies, some tools will not work. So rather than totally disabling this blocking tool, you would need to know how to put the tool’s domain on a white list; which is not really simple.

Tracking is a bit like chewing gum stuck to your shoe: it’s hard to get rid of it. In the case of these overlay tools, it is all the more annoying when, in order to use it, you give the name of your illness or disability when you would rather for it to remain confidential. And what is this information associated with? As we know, when it is a question of statistics, companies tend to collect much more information than necessary. It is therefore more than legitimate to ask the question and expect clear and precise answers.

When working in the web accessibility sector, we hear a lot of the question “and how many people are concerned?” to need a monetary justification to do the work of making websites accessible. How many people do you have to leave out before you can make your website accessible? Is it normal to erect barriers and leave people without a solution to get over them? Why should barriers be erected in the first place? Yes, they are companies and they have to generate sales, to bring in money and spend it as little as possible. But in these companies there are human beings who should have a conscience. Needing to know how many disabled people visit a website to justify making it accessible is anything but ethical.

We don’t need to know how many disabled people and with what kind of disability consult our websites to improve them because we have laws to respect, because we have established accessibility rules that are an international standard (WCAG) to follow, because, in addition to – and after ensuring compliance, we can carry out user tests with disabled people, because we have to give (accessible!) means of contact in case of difficulty in navigating the website. And, if we knew what type of disability this or that user has, what would we do with that information anyway? We are already installing accessibility overlay tools that can track people with disabilities, and yet we don’t do anything more to natively improve the accessibility of websites. So why track?

7. A possible impact on security and performance

Accessibility overlays use scripts to work. These scripts are not always hosted locally (especially for paid and proprietary tools) and remain, in this case, on the domain of the company publishing the tool. As a consequence, they could be hacked and the websites implementing these tools would also be impacted.

Similarly, if these tools have performance defects or if the server where they are hosted becomes unavailable at a given time, this may impact the websites that integrate them. This has already been seen when Facebook’s servers went down: the websites that had implemented the “Like” button were experiencing major availability problems.

In short, like any script on a third party server that you implement on your website, you’re inserting a vulnerability there.

And I’m laughing as, at right after I wrote this, I was told last week, that one of the accessibility overlay tools actually encountered a problem (on its server, as it appears) that made users of all websites with the tool installed download a document without extension that was, in fact, a PHP file.

What is the real solution to make websites accessible and compliant with accessibility rules?

Be trained in digital accessibility so as not to be fooled and / or to get the required skills to implement it (the type of training will depend on your profession) and train all the people who will be involved in projects realisation;
When you’re doing a project from scratch:
1. Be guided to know what needs and rules you will have to integrate in your project (in the requirements, in the specifications, etc.) and to choose the right service provider;
2. Take accessibility into account from the requirements stage of the project;
3. Plan the budget;
4. Create ergonomic and graphic mock-ups while respecting accessibility rules;
5. Integrate and develop while respecting the rules;
6. Check the conformity of the mock-ups, then of the developments;
7. Integrate the basic accessibility tests in the test scenarios (keyboard navigation, code validator, etc.);
8. Have an audit carried out and fix the reported bugs (there shouldn’t be many if you have followed the previous steps!);
9. Continue to train new people arriving on the project, to test even after the production release. Accessibility must follow the life cycle of a project; it does not stop at production release.
When the project already exists:
- Define your budget: don’t waste it on web accessibility overlays that won’t make a website compliant or accessible to all people with disabilities. In case of a small budget, define what could be fixed according to this; this can help to remove the most important barriers in a first step. Establish an action plan, a multi-year plan. Sometimes it takes some time, but it is a subject to be taken seriously.
- Quickly check that your website does not contain the most obvious problems and have them fixed;
- Get help to make your website fully accessible.
Write a page explaining your accessibility policy:
- Do not say that the website complies with the rules if it is not true, nor if you have not had an accessibility audit carried out: say that you are doing your best (if it is true) and specify the actions taken and those to come. Give a means of contact (accessible, of course!) in case of problems. Many websites related to disability lie by writing in their “Accessibility” page that they are accessible and compliant. What’s the point of lying to people who are going to realize that this is not the case anyway?
- When you go all the way through the accessibility process, you draw up an accessibility statement that you publish with a multi-year compliance plan (up to 3 years) and with the action plan for the current year. These pages are generally not written without the assistance of experts in digital accessibility.
  - If you are within the scope of the RGAA, this French page about accessibility obligations details how to comply with the law (if you are a concerned organisation) and gives the keys to write an accessibility statement and a multi-year plan.
  - If you are within the scope of the WCAG, the set of pages “Developing an Accessibility Statement” explains why and how to write an accessibility statement, provides a generator and examples.
Finally, if you really want to put one of these accessibility overlay tools on your website:
- Make sure that all the options of the tool work with your website (yes, this increases the testing load quite considerably depending on the number of features available in the tool);
- Make sure that the tool does not add accessibility problems to your website (an independent audit of the tool will be necessary);
- Ask yourself, as needed, if a free, open-source tool that you can install on your own server, or even a less unnecessarily complicated tool would not be sufficient.

The key is: get trained and have accessibility experts to guide you. Even after training, you don’t master the subject completely. You always discover unknown situations, not seen in training and that you don’t know how to deal. As a group and with experience, you can do it better.

Some resources to guide you towards accessibility

The French organisation called DINUM has published some online guides specific to the professions. Here are two of them:
- A RGAA 3 guide for project managers (in French). It is not up to date because the RGAA is now in version 4 but there are some keys that could be useful.
- A RGAA 3 guide for decision-makers (in French). It is not up to date either, but some contents are still relevant.
The set of pages “Planning and Managing Web Accessibility” of the WAI (Web Accessibility Initiative, which publishes the WCAG).
There are a number of other French guides that I gathered on my wiki.

Conclusion

Accessibility overlay tools will not make your websites accessible to people with disabilities or make them compliant with current regulations. Don’t believe what the websites of these tools and their vendors say. They are not accessibility solutions, they are assistive technologies. Assistive technologies do not make digital technologies accessible. They help to access it according to very specific needs and, if the base structure is not accessible, these assistive technologies do not work.

It would be great if websites could be made accessible in one click. Yes, I would have to do something else in my job, but that wouldn’t be a problem. It’s not the case. Accessibility experts still have a lot of work to do.

As a user who needs accessibility, what I expect is not just another “accessibility” button on every website I visit: it’s a website that complies with WCAG rules at the minimum AA level so that all the mechanisms I could use in my browser to customise my navigation could work. For example, good luck to enlarge the font size in a website that has fixed heights for its elements. What I need is a browser add-on with options that I can choose at my convenience without having to disclose what disorder, disability or illness I may have. A browser add-on where my usage is not tracked since I’m the only one who needs this information.

In the meantime, I share on this page of my wiki the assistive technologies that I use daily or from time to time depending on my needs (in French). It’s just in case it could be useful to others because I believe that we need to improve the knowledge of these tools (which are not magical either!). Many people need them and don’t know them. I’m sure there are some that could help me and that I don’t know yet. These tools can be used on any web page and that’s where their strength lies.

I think that instead of reinventing the wheel each time, we should improve what exists and promote it so that people know it exists.

Anyway, interface customisation tools are complementary to the work of implementing proper accessibility in graphic design and source code of a website but never they are replacements. Without proper accessibility, these tools do not work well. Without proper accessibility, disabled people will always be handicapped by the inaccessibility of websites. It is an aberration to sell these tools by opposing them to the work of making websites accessible. Yes, it’s cheaper but it’s because it’s not the same thing at all. Magic doesn’t exist. If it’s too good to be true, it’s probably not true.