A few months ago, I received an unusual call from Christopher Lee and Mark McCusker at the International Association of Accessibility Professionals (IAAP). They asked me to work as a consultant for them in two areas—helping develop a grievance process and creating a roadmap for addressing overlays. I offered to do this work as a volunteer, but Chris mentioned that he preferred to have it done as paid consultancy. So, I took the work but offered IAAP the same rate that I charged my cousin when he was targeted in a web accessibility lawsuit.
This post puts together some of my thoughts on overlays—and my ideas on a set of industry best practices. My goal is to get disability advocates, accessibility professionals, and industry on the same page and allow us to work harmoniously to achieve our common goal—improving the world for people with disabilities.
If you have feedback on what I’m writing here, please direct them to my email address (ken.nakata@convergeaccessibility.com). PLEASE DO NOT COMMENT on this post directly. Overlays are already a delicate topic with strong opinions on both sides and starting a flame war helps absolutely no one.
What is an Overlay?
First, let me proffer a definition of what we’re talking about. I define an “overlay” as the following,
An overlay is a set of code (usually written in JavaScript) that changes the user interface of web content (1) from what was written by the web developer and (2) in a manner that alters the UI experienced by the user.
The important point to an overlay is an actual change in the UI—not simply an addition to the UI. For instance, customers may load images of themselves enjoying a company’s products in exotic locations. The company then uses a plug-in to automatically load those images onto their website. In that case, the plug-in is not an overlay because it’s not altering the underlying code; instead it is adding to the code.
The overlays that most of us are familiar with are designed to affect or improve the accessibility of a web site. For instance, they can use artificial intelligence to add alt attributes to <IMG> elements when the web developer failed to include an alt attribute. Or, they can be used to add structure to a data table if the developer failed to include table header cell markup and scope attributes to the table header cells.
Most (but not all) overlays include a control panel that lets end-users adjust various settings (such as font size, color contrast, etc.) to meet their needs. Some even include a basic screen reader that can be turned on or off.
Like it or Not, Overlays are Here to Stay
Like any disruptive technology, overlays have created a huge controversy in the accessibility community. Many overlay producers made (and some continue to make) outrageous claims about how their products guarantee full compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 A/AA or the Americans with Disabilities Act (ADA). While many overlay producers responded by tempering their marketing and sales materials, the damage was already done—and now some disability advocates have good reason to feel that overlays will never be an acceptable solution for accessibility.
To an old-timer like me, this divide reminds me of the early battles over portable document format (.pdf) documents. Back in the 1990’s, .pdf’s were popping up everywhere yet Adobe was slow to develop and promote a good accessibility solution for .pdf documents. Most blind users I knew back then loathed .pdf’s and many said that, no matter what Adobe promised, .pdf’s would never be an acceptable solution. Fast forward two decades and now it’s hard to find those same critics. Yes, .pdf accessibility isn’t as easy as we’d like it to be but the technology and services are clearly there for organizations to make .pdf’s fully accessible. Instead of calling for .pdf’s to be banned, advocates now call for them to be made accessible in exactly the same way that they call for web pages and other technologies to be made accessible. In short, the community of disability advocates and professionals have made peace with .pdf’s.
I’m confident that, in much less than two decades, we’ll also make peace with the overlays. I suggest this will happen for a number of reasons.
- Too much inaccessible content. The practical reality is that we will never be able to fix every web page out there. Yes, we absolutely must train designers and developers how to get things right. Yes, we should test content constantly. But there is simply no way that we can fix everything.
- Technology only improves. Artificial intelligence and technology only get better and more accurate over time. There are a plenty of laughable examples of how bad AI can mess up alternative text with some implementations of overlays. But that only says that today’s overlays are not a silver bullet; it says nothing about where the technology is going and what it will be able to do someday.
- Not all users are experts. Most disability advocates focus on the needs of people who are experts at using their assistive technology. Yet the world is getting older and many of today’s (and tomorrow’s) people with disabilities won’t be able to use complicated screen readers or screen magnifiers. For these people, overlays may be their only alternative for accessible content.
A Nagging Concern: Free Riders and a Slippery Slope
Initially, I was opposed to overlays. It just seemed ridiculous that a company could pay $200 a year and have all their accessibility problems disappear. A cynical observer might conclude that, as a consultant, my livelihood was threatened by the easy solution that overlays offer. Honestly, however, being an accessibility consultant is not a path to getting rich—and my concerns about overlays was far deeper.
As I thought about it more, I realized that my big concern was that, if accessibility was automated, then designers and developers wouldn’t focus on accessibility in the first place. After all, we’ve told web designers and developers for years to think about the impact of their design on people with disabilities. We’ve told them for years to include the right alternative text for their images. If people believed that a $200 overlay could magically fix accessibility problems, then even well-meaning designers and developers would have little incentive to build accessibility into their creations. That kind of solution would only reward the people who have opposed accessibility from the beginning. And if designers and developers were suddenly unburdened of any responsibility for good accessible design, wouldn’t that just lead them to create far worse designs that even the latest generation of AI couldn’t take care of?
Along with a lot of other accessibility professionals, I've spent my entire career trying to get people to care about accessibility. The cynical observer is correct that overlays are a threat to consultants working in this field. But that threat isn't because overlays will replace us. Instead, the threat is because overlays will sideline accessibility. I think this is a very real emotional concern that overlay companies need to keep in mind.
Making Peace with Overlays
Some readers may be thinking right now that I should try to renegotiate a much higher rate for this project, as getting in the middle of this fight is going to be long and deeply unpleasant.
Of course, the doomsday scenario I described above doesn't have to be a battle between consultants and overlays. Instead, overlays can work perfectly harmoniously with more traditional accessibility products and services. For instance, imagine the following scenario.
- A customer hires a consultant because their custom-built website is inaccessible.
- The consultant notes that a tab panel on a website is inaccessible because it fails to identify name, role, and value (WCAG 4.1.2)-- and she recommends using ARIA to make that tab panel accessible.
- The developers can then fix that panel. They can also scan the site to identify where the same code appears in their website and fix those problems as well.
- An overlay is programmed to spot and fix similar matches that don't exactly match the original tab panel. As it does so, it notifies the developers that this bug also needs to be put in the queue for remediation. Before the developers can fix the problem, however, the overlay still does a good job at making the inaccessible tab panel accessible to end users.
I think that we can make a lot of progress if we can establish some industry best practices that recognize the limitations of technology, foster more transparency, and encourages good web design.
A Rough Set of Best Practices
The following set of best practices is offered as a “straw man.” I can’t really even call this a “first draft.” As I mentioned, if you’re interested in offering your feedback or opinions, please reach me directly at my email address, ken.nakata@convergeaccessibility.com.
I believe that the controversy involving overlays comes down to two equally important halves—the technical and the non-technical. The IAAP is the leading professional body for the digital accessibility profession and so it makes sense that it leads the efforts for non-technical requirements. The technical requirements below are offered only as an interim solution.
[CORRECTION: An earlier version of this blog post included inaccurate information about W3C work. It was corrected on June 23, 2022]Technical Requirements
Follow W3C
If at some point W3C takes on work on technical recommendations for overlays, follow their lead. In the meantime, follow the best practices outlined below.
[Correction: An earlier version of this blog post included inaccurate information about W3C work. It was corrected on June 23, 2022]
Dismissibility and non-interference
If an overlay has an overlay panel, make the panel easy to dismiss for assistive technology users (such as screen reader users) and for keyboard only users. Alternatively, don’t interfere with the screen reader and other assistive technology experiences.
Do not automatically apply settings
Using an overlay should be a user choice and should not be invoked automatically. Also, overlays should not be applied based on user behavior (e.g., starting a “screen reader” mode simply because the user hits tab repeatedly).
Do not trigger updates to page content when an accessibility scanner is detected
Content owners need to verify accessibility of content without the effects of an overlay. Triggering an overlay may obfuscate their testing.
Accessible
If an overlay uses an overlay panel, make sure that the controls in that panel are accessible and conform with WCAG 2.1 A/AA. Also, ensure that overlay panels follow standard navigation for controls—or disclose up front the manner in which users should navigate and operate those controls.
Document Fixes
If possible, provide a mechanism that identifies code level changes that are made by the overlay. This helps educate developers in avoiding future accessibility problems and also makes it easier to identify automated fixes that are applied incorrectly.
Non-Technical Requirements
Transparency (WCAG)
Be clear to customers which WCAG requirements are being automatically addressed, which ones require the overlay customers to fix, and which ones are not being fixed (or identified at all). Disclose the type of non-standard HTML content or controls that is covered by the overlay, AI, and/or manual remediation services (i.e., switches, tabs, etc.)
Transparency (Customers)
Don’t promise full compliance with the ADA or WCAG unless you mean it and can prove it. Instead, give users honest advice about the limitations of your solutions and additional steps they should take for legal or technical compliance.
Transparency (End Users)
Provide a simple non-technical explanation for end users—including end users who use assistive technology—about what is being fixed and what is not being fixed.
End-User Feedback
Provide a mechanism to solicit accessibility feedback on any page when an overlay is deployed—including information about the specific problem and identifying information (e.g., email address) only if the end-user requests it.
Got Feedback?
Like I said, this is only the start of the discussion. Do you like it or do you hate it? Is there something missing or needing further elaboration? Let me know what you think by sending me an email at ken.nakata@convergeaccessibility.com.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “Best Practices for Overlays”