Accessibility ≠ Overlay: the American Council of the Blind’s warning about overlays

This issue has been debated for years among developers, accessibility specialists and, especially, people with disabilities who use assistive technologies.

In 2021, the American Council of the Blind (ACB) adopted a resolution specifically devoted to this issue: Resolution 2021-09 — Website Overlays.

Its position deserves the attention of any company, developer or website owner considering this type of solution.

The American Council of the Blind is a U.S. organization formed and led by people who are blind or have low vision.

Its work includes defending the rights and equal opportunities of people with visual disabilities, including access to information and digital services.

That is why it is especially important to listen to what people who actually use screen readers, magnifiers and other assistive technologies have to say about tools that claim to improve their experience on the web.

On September 29, 2021, the Board of Directors of the American Council of the Blind adopted Resolution 2021-09, specifically addressing website overlays.

The resolution starts from a fundamental point: access to information on the Internet is essential for education, employment and social inclusion.

In response to barriers on inaccessible websites, companies have marketed solutions based on automation and artificial intelligence. These tools are often installed on an existing website through JavaScript and promise to detect or correct certain accessibility problems.

The problem arises when these technologies are presented as substitutes for a genuine accessibility strategy.

One of the most relevant aspects of the resolution is its rejection of creating a different experience specifically for users of assistive technologies.

ACB states that some overlays, even when intended to improve a website, can result in a separate and often inferior experience for people who are blind or have low vision.

Accessibility should not mean detecting that someone uses certain technology and giving them an alternative version. The goal should be for the same page, content and functionality to be usable by everyone.

ACB points to another important risk: an overlay can give a website owner the impression that their accessibility obligations have already been addressed.

Meanwhile, problems in the underlying code may remain: controls without appropriate semantics, unlabeled forms, components that cannot be operated by keyboard, poor focus management, or dynamic messages that a screen reader does not announce.

We therefore need to distinguish between adding accessibility features and making a digital product accessible. They are not necessarily the same thing.

The ACB resolution contains a fundamental idea: genuine accessibility requires proactive measures and an ongoing commitment to inclusion.

Accessibility begins with design and continues through development. It must be present in the HTML structure, components, keyboard interaction, focus management, forms, error messages and content.

Automated tools can be useful for detecting certain problems, but they do not completely replace human evaluation or testing with assistive technologies.

ACB calls for any technology created to help the blind community to include meaningful participation by people who are blind or have low vision.

If we develop a tool intended to improve the experience of screen-reader users, those users should participate in its design, development and evaluation, not only after the product is finished.

Accessibility is not simply about passing a technical checklist. It is about whether a person can actually use a product or service.

The ACB resolution does not reject technological innovation. The organization welcomes innovative solutions intended to combat inaccessibility on the Internet.

What it questions is treating a separate experience for assistive-technology users, or an overlay, as a superficial answer to a problem that requires structural and ongoing changes.

Artificial intelligence, automated tools and other technologies can help us find and fix problems. But they should be part of an accessibility process, not a substitute for it.

The presence of a floating accessibility button does not prove that a website is accessible.

The better question is: can a person with a disability actually use the website and complete the same tasks as anyone else?

Can they navigate and understand the structure? Can they complete and submit forms? Can they make a purchase? Can they understand error messages? Can they operate every control with a keyboard? Can they use their own assistive technology without interference?

ACB Resolution 2021-09 leaves us with a point that remains relevant: accessibility should not be a layer added at the end of a project.

It should be part of its design and development from the beginning.

Before installing a tool that promises to fix website accessibility automatically, it is worth asking:

Are we really removing accessibility barriers, or are we simply putting another layer on top of them?

American Council of the Blind — Resolution 2021-09: Website Overlays
Resolution adopted on September 29, 2021.

Read the original American Council of the Blind resolution

This article is part of the “Accessibility ≠ Overlay” series, where we examine positions from disability organizations, public bodies and accessibility specialists, as well as the technical limitations of overlays and other automated accessibility solutions.

Part 01 — American Council of the Blind: Website Overlays.
Next: the National Federation of the Blind and its position on accessibility overlays.