Accessibility, Compliance, User Experience

There is no Magic Wand: Plugins won’t fix accessibility

Written by  J. Hogue

Digital accessibility is a difficult thing to get right. It’s important to do, it’s the law, and it’s just plain hard work. There is no magic solution. Wouldn’t it be nice, though?

This wish of “what if there was a product I could buy and just bolt on top of my existing website that could do all the work of making my codebase accessible to people of all abilities” is so enticing to dream about. Wouldn’t it be great? Of course it would. These products exist on the market right now, but they should be avoided. They do not fix accessibility issues.

What is an accessibility plug-in?

A plug-in or an “accessibility overlay” is an outside service that provides a tool that can be added to any website. Often added as “one line of code” for every page, an interface is added to where a visitor can control font size, color contrast, or access the page’s headlines, links, and so forth. Most often these services are Javascript-based, and they are used to morph inaccessible code into something accessible. At least, that is the intent.

The problems with accessibility plug-ins

Its tempting to think that more technology can fix our problems with technology. Unfortunately, it is not that simple. These tools have problems with accessibility at a fundamental philosophical level in addition to their technological shortcomings.

They enforce a “separate but equal” mentality

This is the fundamental philosophical difference that overlays promote. The ADA has its roots in physical store locations. To have an accessible building, it is not acceptable to have a front door that leads directly to the main lobby but an accessible wheelchair ramp in the back of the building that leads through the loading dock and then into the lobby. That’s not an equal experience, and the law has been clear on this point.1

When it comes to digital properties, the idea is similar — your site should be accessible by default. Every visitor to your site needs to use the same front door. If the front door is only useful once I get past the two steps outside of it, that’s not an equal and accessible experience.

An overlay tool gives a visitor options to change font size, color contrast, and so on, but they are not the default state of the site. If a site has low contrast by default2, the site owner should not expect visitors that require the minimum contrast to change it on their own. That’s like expecting someone who needs to use a handrail down a flight of stairs to install one for themselves. A site that is accessible only when an outside piece of software is turned on violates the ADA and standing US law.

A similar example of this “equal access” idea can be found in the Robles vs. Dominos Pizza case3, ongoing. A blind customer sued Dominos because their website and mobile App could not be used by screen reader software. Dominos’ argument was that the blind customer could call and place an order over the phone. The plaintiff counters that if sighted people can use a mobile App to order, why can’t a non-sighted person? The courts have agreed.

Not all accessibility issues can be detected by automation

As a professional in this field, I rely on automated tools to help find accessibility issues. Our team has a suite of tools that we use to scan a page’s code and highlight issues. But these tools only find up to 70%4 of the problems that might be present, and they can be rife with false positives and false negatives. They need a human who understands the criteria and goals of accessibility as well as the code to make a proper determination.

These accessibility plug-ins claim that not only can they detect all the accessibility problems that there could possibly be (they simply can’t), but they can also fix those problems, too. Luckily for them, if their tool can’t detect the problem, it does not have to fix it. Unfortunately, that leaves your visitors out in the cold.

Further, each case of non-conformance to the rules outlined by WCAG requires the evaluation of the interface goals and the context. The rules are open to interpretation and multiple ways to solve a single interface problem because there are too many use cases to consider. A human is needed to evaluate the proper way to conform to the guidelines. So far, automated tools are not smart enough to do this.

They try to replace tools that already exist

I’m savvy enough to know my way around a screen reader tool and I will often use only a keyboard as a way to quickly test how inclusive a web page might be. When I use my keyboard on a site that has one of these plug-ins present, it will interrupt my keyboard tabbing and force me to use the tool’s built-in keyboard functionality. This enhancement is not the same as the native keyboard, which I already know how to use. It does the same thing when it detects you are using a screenreader.

It’s like a store forcing people who use wheelchairs to get out of the one they use all the time and into one that the store provides. The controls are in the wrong place, the seat doesn’t quite fit, and it’s missing a feature or two. Why provide a different tool than the one people already have?

A web user who needs contrast to be higher or fonts to be larger than normal will adjust their web browser so they can have a consistent experience from one site to another. This is what browsers do well already. If a site is coded properly, it will adhere to these preferences. This is how HTML works with just a little forethought. These extra tools try to add features that already exist and do not give someone a consistent experience from one site to another.

Don’t just take my word for it, though. I know a few things about using a screen reader, but I don’t use one every day. Read an article by Robert Kingett, a blind user, who is frequently an expert witness in accessibility lawsuits.

They simply do not work

That seems like a bold claim, but it’s not. Many people have said the same thing, many people with more experience than I. Here are some highlights:

Karl Groves investigates a popular overlay service with a simple test for image “alt” text. Its a half hour long video, so here are the highlights:

  • Images without accessible descriptions (“alt” text) are one of the largest problems on the web
  • He feeds the sites of brand names that a tool lists on its website as clients to his testing tool. He restricts the tool to ONLY detect images without alt tags
  • Each site is tested up to 50 pages. Some of the results were not only bad, they were horrendous. One site returned more than 2,000 errors. Remember, this was testing only ONE criterion in WCAG’s list of 74.
  • The “AI” could not tell that an image of an arrow used as a control was an arrow. It had no alt text, so it failed. This means a non-sighted user would not know how to use the action it controlled. Further, images of products had no alt text content and no meaningful description. Products that presumably the brand wants to sell were invisible to a blind user

Adrian Roselli writes a scathing review of one overlay called accessiBe Will Get You Sued.

He has found several examples of lawsuits involving companies using accessibility tools and how those tools have failed to provide an accessible experience.

If you have a little time and some aptitude with an accessibility code checker, simply test a few pages from the client websites these tools sat they are being used. I’ve done it and have found at least one error per page on many occasions.

More examples can be found in our list of resources at the end of this article.

Accessibility sales copy vs. their terms of service

We’ve heard the term “buyer beware.” It is especially true when claims are just too good and its certainly true when it comes to these tools. If your company is in the market for one of these products that promises a quick fix, please make sure to read the terms of service.

Most of them have language like these examples, which should raise red flags.

Only compatible with approved browsers

Yes, these tools have a compatibility chart. While digital product developers such as ourselves work hard to make websites compliant with as many users and browsers as possible, these products draw a hard line in the sand:

The [product name] is only compatible for use by users on the following operating systems and browsers: Chrome, Firefox, Safari, Microsoft Edge, Internet Explorer 11, Android 8, and iOS10.

That’s a pretty good list, don’t get me wrong. But take a look at your own site analytics and tally up the users of browsers that are not on that list. The number of visitors this tool will not help might be higher than you expect.

The site shall have no errors

This is an interesting one. Sales copy promises that their product will fix all compliance and conformance issues, but the terms of service state that the site should be free of errors before their product is installed:

The functionality of the [product name] requires that the Licensee Website in which they are embedded be websites based solely on HTML files and tags, and that the source code be written according to the Standard of the World Wide Web Consortium (“W3C”), without any errors or validation warning in W3C’s troubleshooting inspections;

It seems as though their “automated, state-of-the-art AI technology” is not so state-of-the-art. Again, their bold claims are too good to be true.

Video, Audio, and PDF files will not be made accessible

This is a huge deal-breaker. Making time-based media files accessible is core to the WCAG 2.0 and 2.1 standards. Rich media needs to be available and accessible to all users.

If your site leverages audio or video files, it needs to conform with WCAG 1.2.1: Time-based Media, Audo-only and Video-only (Prerecorded){:target=”_blank” title=”Opens in a new window” rel=”noopener noreferrer”}, which states that a text alternatives for video or audio must be provided. For video, someone who is blind needs a text version that a screen reader will read out loud to them. And for someone who is deaf, both video or audio needs a written transcript for them to read. These tools fail to provide that.

PDF files can have their own host of accessibility problems if they were not created properly. These tools will not remediate PDFs that your site hosts and link to for visitors to download — therefore, your site’s contents are not accessible and your visitors suffer.

Their terms make the sales pitch clear

Finally, their terms state clearly what their sales copy does not — that these services alone do not fullfill the requirements of the law. Your site and your users will still be vulnerable to non-accessible content. This language states it better than I can (emphasis mine):

…it is possible that, for reasons arising from the Licensee Website and/or changes and updates that may be performed, from time to time, by the Licensee and/or their representatives on the Licensee Website and/or for other reasons beyond the control of the Company, the Licensee Website may not be substantially accessible at any given time.

The Licensee is aware that the installation of the [product name] cannot guarantee that claims will not arise, and that embedding the [product name] in the Licensee Website does not, on its own, fulfill all of the requirements of applicable law in respect of website accessibility. The Company does not undertake that the Licensee Website will be 100% accessible at any given moment, owing to factors such as Licensee changes made to the Licensee Website, issues originating in the Licensee Website and /or limitations stemming from technological reasons. The Licensee irrevocably waives any claims against the Company from any liability, legal or otherwise, and that it shall assert no claims against the Company in this regard (including in relation to any Claims Support Services, if provided).

That last line also makes it clear that a user of one of these plugin products will have no legal recourse if the product fails to deliver on its promises. We can’t state “buyer beware” enough.

Humans can fix Human Interface Problems

Accessibility is hard. Talking about it is hard, understanding it is hard. Remembering that they extra effort required is totally worth it can also be hard. These are not easy problems to solve.

HTML gives us a fantastic foundation. It was written with accessibility in mind from the very beginning — after all, Time Berners Lee has said the same basic thing over and over again:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.5

But HTML and CSS and Javascript can be used in lazy ways too easily. There is no set of tools that can prevent people from writing bad code and creating unusable websites. Humans make the problems, therefore humans need to fix the problems. When it comes to accessibility, there is no magic wand. Only people who have made it their mission to squash bad code.

Resources, references, and required reading:

  1. 42 U.S. Code § 12182. Prohibition of discrimination by public accommodations, (iii) Separate benefit: It shall be discriminatory to provide an individual or class of individuals, on the basis of a disability or disabilities of such individual or class, directly, or through contractual, licensing, or other arrangements with a good, service, facility, privilege, advantage, or accommodation that is different or separate from that provided to other individuals, unless such action is necessary to provide the individual or class of individuals with a good, service, facility, privilege, advantage, or accommodation, or other opportunity that is as effective as that provided to others. ↩
  2. A violation of WCAG 1.4.3 Contrast: The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 ↩
  3. U.S. Supreme Court Will Not Hear Domino’s Pizza Web and Mobile Accessibility Case, Disability:in October 7, 2019. ↩
  4. The UK.gov team tested 10 automated tools and found that 29% of their 143 expected errors were not detected by any of them — 42 were consistently missed. What we found when we tested tools on the world’s least-accessible webpage, February 24, 2017 ↩
  5. Compiled by Wikiquote. ↩
  6. In which the presenter goes through many of the same points that we have outlined. Participants ask if it is possible that so-called “drive-by” litigation individuals or firms of lawyers, knowing that these tools do not work, target the clients of these tools for litigation. There is no proof one way or the other here, but it is an interesting question. ↩

Relates Posts

ARTICLE AUTHOR

More about this author

J. Hogue

Director, Design & User Experience

I have over 20 years of experience in design and user experience. As Director of Design & UX, I lead a team of digital platform experts with strategic thinking, cutting-edge UX practices, and visual design. I am passionate about solving complex business problems by asking smart questions, probing assumptions, and envisioning an entire ecosystem to map ideal future states and the next steps to get there. I love to use psychology, authentic content, and fantastically unique visuals to deliver impact, authority, and trust. I have been a business owner and real-estate developer, so I know what is like to run a business and communicate a value proposition to customers. I find that honest and open communication, a willingness to ask questions, and an empathy towards individual points of view are the keys to successful creative solutions.

I live and work in Providence, RI, and love this post-industrial city so much that I maintain ArtInRuins.com, a documentation project about the history and evolution of the local built environment. I help to raise two amazing girls alongside my equally strong and creative wife and partner.