Bolt-on Accessibility – 5 gears in reverse

Many organizations first encounter accessibility as a risk to be managed. They may hear of drive-by lawsuits, bad press, and inflated costs. They are the prime target for products that promise to address all these concerns and more, just by adding a single line of code to a site.

However, these add-on solutions not only fail to help, they can increase the very risk (and cost) an organization is trying to avoid.

The Promise

Accessibility plug-ins such as those provided by accessiBe, User1st or Userway make explicit or implicit claims. Specifically that the risk associated with compliance to accessibility laws will be mitigated quickly and simply:

  • Automatic AI Solution for Web Accessibility & Compliance with WCAG 2.1 AA Level and US Section 508, Americans with Disabilities Act (ADA) and European Union Standard EN 30154
  • the only solution that ensures full accessibility compliance at any given time
  • keeping your digital assets fully compliant with WCAG 2.0 AA standard, ADA and Section 508 guidelines
  • Avoid Legal Exposure
  • Give your users a robust experience and implement it now.
  • Install our single line of JS code
    Automatic. Simple. Affordable.
  • Make your website accessible in minutes
  • Doesn’t require modification to the source code of digital content or applications. It corrects 99% of HTML errors.

The Reality

Yes, these tools have a lower up-front cost than investing in development of more usable/accessible user interfaces. Yes, the installation may be relatively simple and quick. However, the result may still be far off from a truly accessible experience for a site’s visitors, contrary to the developers’ lofty claims.

Fundamental issues that can’t be fixed

If a site currently has fundamental accessibility problems – such as missing alternative text for images, missing structural markup that correctly and semantically identifies page elements (headings, lists, labels/names for form controls), incorrectly implemented interactive widgets and controls that cannot be operated correctly with a keyboard and/or assistive technologies – bolt-on solutions won’t be the answer, and they won’t automagically fix these underlying issues.

As an example, one tool currently implemented on a large web technology site provides automated (AI driven) text alternatives for images used as the sole content of links.

Without the tool enabled, the image fails WCAG 2.1 – 1.1.1 non text content (no alt attribute)
<a href="..."><img src="https://d2sis3lil8ndrq.cloudnt.net/books/9718385b-ee01-4704-945f-67d1c203e359_medium.png"></a>
With the tool enabled, the image arguably still fails WCAG 2.1 – 1.1.1 non text content (alt attribute with overly verbose text, the first 60 characters are generic terms that do not provide any useful information in context)
<a href="..."><img src="https://d2sis3lil8ndrq.cloudfront.net/books/9718385b-ee01-4704-945f-67d1c203e359_medium.png" alt="Image contains: Illustration, Vector, Flower, Nature, Abstract. Image Text: ECMAScript Cookbook Over 70 recipes to help you learn the new ECMAScript ( ES6 / ESB ) features and solve common JavaScript problems Packt By Ross Harrison"></a>

On sites with a multitude of these sorts of issues, the result will be a large number of verbose and incomprehensible links.

A screen reader’s “Links” dialog, with most links identified by overly long machine-generated text alternatives
A screen reader's links dialog, displaying 20+ links with the visible link text being 50+ characters of text that does not convey information about the link target.

The context in which an image is used dictates what an appropriate text alternative is for the image. The example above is one of many on the web tech site where the images are the sole content of links, this results in the links having overly verbose and largely inappropriate link text for screen reader users. The primary purpose of an img alt attribute when the image is the sole content of a link is to provide a brief description of the link target…

When an image is the only content of a link, the text alternative for the image describes the unique function of the link.

source: WCAG 2.1 technique: Providing link text that describes the purpose of a link for anchor elements

When an a element that is a hyperlink, or a button element, has no text content but contains one or more images, include text in the alt attribute(s) that together convey the purpose of the link or button.

source: HTML5 Requirements for providing text to act as an alternative for images

While the use of automatically generated alternative text for images is certainly “better than nothing”, it is clear that this approach only tries to mask the more fundamental problem (an image lacking any sort of alternative text). This approach may be a form of last-ditch error correction, but it is not an appropriate approach that can simply be relied on as an alternative to correctly custom-written and implemented text alternatives.

Accessibility plug-in functionality simply replicates built-in browser/operating system and assistive technology accessibility features

Many of the features present in these tools are already provided (more robustly) in Browsers, operating systems (OS) and assistive technology.  They provide a large range of features to provide users with the ability to modify user interfaces to suit their own needs:

Many users require these features not for only one website or application, but for most of the time they use computers. Different custom sets of features provided by individual sites can negate the usefulness of the browser/OS/assistive technology features they already use, degrading their user experience. In most cases, the sustainable approach for a site is to ensure that it works correctly with existing functionality already available to all users, and to adapt to their existing settings and preferences…not to introduce its own set of bespoke controls.

The tools themselves can introduce new problems

In many cases, the accessibility ‘improvement’ features bring their own accessibility barriers for users. It is very easy to discover that new accessibility compliance issues are introduced using their features. These still need to be addressed.

Fail to adequately address issues they purport to fix

With keyboard features enabled links menus stay open after user navigates past them
Navigation menus stay displayed after they no longer have focus, obscuring both the previous menus and the content beneath the menus.
Using a content zoom feature results in text becoming obscured
When the text sized is increased text becomes obscured.
Scaling content to 200%, using a plug-in feature, on the products’ own site causes content to be obscured and the UI to become unusable. The UI is partially off-screen and cannot be accessed
The accessibility plugin UI is partially hidden off screen, as is the web site content, the content cannot be accessed as there is no means to scroll.
Another inaccessible content zooming feature causes content to be obscured by the feature buttons and labels
The plug-in zoom feature UI, obscures content as a users scrolls through the content.
Using a line-height increase feature results in text overlapping, becoming unreadable
Text overlaps to the point that it is very difficult to read.

Present additional complexity for users

One of the plug-ins presents the user with 75+ controls in addition to the UI of the standard web site. This is an unnecessary burden on users with a range of disabilities.

An illustration of all the additional “tab stops” introduced by one of the plug-ins

The plugin UI is displayed with numbers indicating each tab stop and lines indication the focus order path.

Introduce markup with incorrect or absent semantics

A mark of these plugins is their poor use of HTML/ARIA semantics to represent the user interface, for example: an onscreen keyboard is presented as a textbox to screen reader users, a user interface is represented as a menu but the expected interaction behavior is missing. Dialogs are not represented as dialogs to screen reader users. The apparent inability of the product producers to implement web technologies (HTML, ARIA, JavaScript and CSS) correctly in their own products, even on their own sites, does not offer much confidence in their claims that they can make your site accessible and compliant with WCAG, the ADA or any other standards or laws designed to make the web more usable for people with disabilities.

Conclusion

While most plug-in solution promise a simple “set it and forget it” solution to the risk associated with compliance to accessibility laws, the reality is that not only is the risk not reduced, the risk may be increased because there is evidence the organization recognized accessibility issues and chose to go with a solution that did not address them.

Following on that, the cost is not reduced because in addition to the money spent on an ineffective solution, an organization may find it has to hire consultants, train staff, and maybe, in a worst case, obtain legal help.

These limitations are not unknown to the vendors. At some level they are aware what they offer cannot compete with correct coding practices. They may leave comments on posts critical of them, but when challenged with specific issues they go silent.

These tools fail to live up to their claims and crucially they can add barriers to access for users with disabilities that rely upon their operating system, browser and/or assistive technology accessibility features to use the web. Whether these tools reduce a company’s exposure to accessibility lawsuits is an open question, but this brief look at their features suggests they will not. If a website or application is built supporting Web Standards, they can be used by all without the need for companies to add additional complexity from 3rd party vendors.

Thanks to Adrian Roselli and Patrick H. Lauke, my friends and colleagues, for their help with this article.

Categories: Development
Tags: ,

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

Great advice, as always.

Guy Hickling says:

In the UK we have a law called the Trade Descriptions Act, which stops manufacturers, retailers and service industry providers from misleading consumers about what they are spending their money on. I imagine America has similar laws at both federal and state level. If so, it seems to me that the two of the three quick-fix suppliers you mention above, that are based in the US, are playing with fire! It only needs one of their customers to find out in a subsequent ADA court case that the tool they bought on trust hasn’t given them any immunity at all from the law. Said customer will come hunting for heads!

Paul Sandwell says:

Excellent article Steve! I completely agree with the point on the plug-ins just replicating already existing assistive technology accessibility features, I’ve tried explaining this point before to a designer on a project before, and sadly they just didn’t understand my point. Glad to see I wasn’t the crazy one!