Coming soon: Google and PwC share best practices on inclusive customer experience. Register now!
Picture of legal mallet and screenshots of website pages

On September 17, San Francisco’s Lighthouse for the Blind filed suit against a major HR software and services provider for products and services that are inaccessible to blind employees. The defendant also happens to be a customer of an accessibility overlay provider. As Sheri Byrne-Haber outlines in her article this past week, it could have broader implications on similar types of solutions and the accessibility market in general.

While it will likely take some time for the wider ramifications of the lawsuit to play out, this further backs our position that widgets and other overlay-based solutions are not credible nor sufficient approaches for digital accessibility for a wide variety of reasons. There is no fully automated way to ensure accessibility for your site or app – despite what the odd search or banner ad you see on the web may otherwise claim.

Dubious Solutions: A Recap

As I’ve written about before, there is no replacement for fixing actual code to make a website accessible. To many, these “shortcut” solutions may seem very appealing as an easier, quicker route to compliance. These approaches, however, will always leave you open to some element of risk. As a recap, these solutions come in two main forms:

  1. Widgets, or add-on Accessibility ‘menus’ for your site, where users select options based on their disability ‘needs’ or ‘profile’. Content is altered and fixes are overlaid using heuristics-based features that are limited in what they can do.
  2. Accessibility overlays, which are just concerned with adding fixes on top of the site (or as part of an alternative site) via JavaScript with no impact on the actual code. There’s usually some element of manual services added or integrated in a model with automated tools. So, Solution Engineers of some sort will write manual fixes to additional issues they’ve found that cannot be addressed using just automated tools.

In the case of this lawsuit, it appears the vendor offered both approaches in one integrated model: overlay services along with a user-facing widget or ‘toolbar,’ and a slew of other support features as part of a certification offering (at least according to the public statement on the Defendant’s website). While this can seem like the best of both worlds, there’s still no actual fixes to the code and usually means there’s no intention of ever training up their internal teams, changing their process, or changing the way they develop, design, or build digital content. This is echoed in page 25 of the complaint, “Despite [the Defendant’s] knowledge that a piecemeal approach to resolving these barriers does not result in an accessible product, Defendants have refused to take a systemic approach to remedy the underlying accessibility design flaws.”

The Fallacy of ‘Add-On Accessibility’

With such a ‘bolt-on’ approach to accessibility, an organization will continue to design and develop the same way which means more issues will continue to proliferate, always introducing some new element of risk. This means that a ‘cheaper’ overlay services model quickly becomes more expensive to account for intensive, regular maintenance (or issues go unaddressed). Fixes are not just needed for the new issues that appear but also to cover existing ones that were already “fixed” until the underlying code changed in some way.

These changes can come frequently since digital properties typically involve contributions from many different individuals, roles, or functions – whether its formal releases, planned updates, new redesigns, or even just small day-to-day changes in content on individual pages. Without training, structure, and accountability, there’s too much opportunity to continuously reintroduce new risk.

It’s just not a practical approach. Not to mention one with some serious privacy and security concerns. Plus, if a customer ever abandons this model or leaves the vendor then they would also lose the overlay fixes as well and that would effectively leave them at square one.

As an important aside, there’s already some serious litigation going on within this space – one vendor suing another over patent infringement – to add to the already murky nature of these solutions. Good reasons continue to pile up for why one should not consider these solution categories.

In addition to the reasons mentioned above, here is a demonstrable example of a lawsuit being brought against a customer using this overlay services model with a user-facing widget and having a ‘certification’ from the vendor within their public statement to boot. [Read more on why you should be wary of certifications from these types of vendors]

The Bottom Line

This lawsuit is not likely to be resolved quickly. As Sheri notes in her aforementioned post: “San Francisco Lighthouse for the Blind, the plaintiff, is not a hit-and-run plaintiff. They file meaningful litigation, typically after attempting to work with the defendant to resolve the issue.”

This suit is an important reminder that accessibility is about the experience of people. So even if you can take care of a great number of issues automatically, it is still critical to evaluate for an accessible user experience overall, and to ensure effective communication under the ADA. Ask yourself, can people navigate your website and accomplish the things they would expect to be able to do with screen readers, other assistive technology, or just using a keyboard?

All of this reinforces our recommendations to avoid these solution categories and instead focus on creating and maintaining accessible code to ensure accessible experiences. For more information read, ‘Is Deploying an Accessibility Overlay or Widget Better Than Doing Nothing?’ or other articles from my Linkedin series. We also have an ADA Compliance eBook with a compliance framework that outlines the actions and policies organizations should take.

Originally published on Linkedin.