by Steve Decker

(Editors' note: Steve Decker is a lead accessibility consultant for Target, a father of three, a member of our Metro chapter, and a person who thinks carefully about the issues that affect us as blind people. He gave this presentation at the 2021 Annual Convention)

I’m a lead accessibility consultant for target.com, so I bring this today as my background and experience. All views I express today are my own.

Before I explain what an overlay is, and why you should care, I want to share my experience making accessible websites. The process of making something accessible can look very different depending on the size of the organization, the complexity of the project, and the knowledge of the team, so this is just my experience.

For me, accessibility begins by talking with designers. Some specialize in defining the full experience of completing a task. They decide things like whether you should fill out one long form, or several shorter ones, each on their own page. Other designers decide what all the little pieces that make up an experience look like. They choose the color, shape, and size of buttons, text, and much more. As an accessibility consultant, I make sure they remember to check that there is adequate color contrast between various parts, that they decide what heading levels we’ll use, that if something behaves like a button it looks like one, and a lot more. Without accessible designs, the folks who write the code that brings the website to life can’t make it fully accessible.

Next, I talk with developers, sometimes called engineers. I remind them to ensure that anything designed to look like a button be coded as a button, and I make sure they understand how screen readers should speak it.

Finally, I test what has been built using screen readers, other tools, and often, alongside sighted colleagues. We test what was built in what is essentially a sandbox or playground site. This allows us to find bugs, share them with the team, and verify that they’re fixed before the experience goes live to the web where you can see it.

The key here is that accessibility is built in to all phases of the process, and that it has become part of our company culture. I don’t need to constantly teach designers and developers the basics because everyone around us reinforces why it’s important and how to achieve it.

I want to talk briefly about the role of automation in accessibility. Many websites rely on automated testing to catch some accessibility issues. To oversimplify a bit, automated testing is when a computer scans the code of part or all of a website, checking that site against a set of rules, in this case accessibility rules. Automated testing can find issues like images with no alt text, the code that tells a screen reader what the image looks like. The testing tool then gives a report to developers with issues it finds and recommendations of other things to check. Generally, though, it can’t know if the image missing alt text is decorative, or if it’s a picture of artwork. How an image should be described is highly subjective, depending on the context. The vendors of automated testing tools will claim their tools can spot as many as 58% of errors. Many of us working in accessibility would put that number no higher than 40%, and often it’s lower. Note though, that no one claims their tool can catch 100% of issues.

So what is an overlay? In this context, an overlay has two meanings. First, an overlay is code that, while scanning the site for issues, can actually modify the code that reaches your computer, and can change it, trying to fix the issues it finds. Going back to the example of an unlabeled image, the overlay will guess how it should be described. It may guess it’s a logo and say “logo” or it may use nearby text and guess that that text is related to the image.

Second, an overlay often takes the form of a set of controls that literally overlay, or visually sit on top of part of the page you visit. Often, you can choose what disability you have and the site will be modified accordingly. If you choose “visually impaired” you may get higher contrast and simpler colors. If you choose “blind” more labels, headings, and other enhancements for screen readers may be added. If you are sensitive to motion, animations that move, blink, or flash, may be turned off.

Historically, overlays have been around for decades, but what they claim to be able to do has changed a lot over time. Initially, they may have just let you change font size or color. Some may have tried to add the ability to make some things speak, for those who don’t have a screen reader. Within the past decade, overlays made by accessibility consulting companies selling automated testing tools have marketed overlays for temporary usage while a company learns how to do accessibility and takes time to update their site. In the last few years, there has been an explosion of companies selling overlays at extremely low prices (think $50 per month) that claim to “fix your accessibility issues” and “make your website compliant with just a single line of code.” Some of these overlays have created new barriers for blind users, and have even been mentioned in several lawsuits where companies thought they provided protection. Judges are deciding they do not. In examining some of these overlays, I and others have found accessibility issues with the controls used to operate the overlay. This begs the question: If your own tool isn’t fully accessible, how can it make someone else’s website accessible? Many of these newer overlays detect that I’m running a screen reader and offer me a “screen reader mode” automatically. This has interesting implications. Are they changing anything before I activate screen reader mode? How do I know if I’ll like it better, and can I turn it off if I don’t? Some overlays don’t identify themselves. To whom do I complain or share feedback? In the summer of 2021, the issue became so prominent that the Federation passed not one, but two resolutions pertaining to them, and it revoked the sponsorship of one overlay vendor. Disabled people and accessibility advocates, some of whom are Federationists were cited in an NBC news story as well, pushing back against the false claims and promises of these newer overlay vendors.

One of the key points mentioned in the first of the resolutions is the fact that overlay manufacturers have not engaged with the blind community, and I would add that they haven’t engaged with the community of accessibility professionals, many of whom are blind. In fact, some have claimed we who are accessibility consultants are just protecting our job security, and that we aren’t really needed. Needless to say, they have a very different philosophy on accessibility than the National Federation of the Blind.

As Federation leaders from Anil Lewis to President Riccobono have noted, accessibility happens when companies enculturate it in to their organizations, just the way I described at the start. Our philosophy is that, if you’re going to build something that affects blind people, and especially if it’s designed specifically to help blind people, you’d better consult us. We are the voice of the nation’s blind.

Let me illustrate some contrasting examples of technology that changes what we encounter, in an attempt to increase accessibility. Jaws for Windows, a tool we’ve used for decades to live the lives we want, reads the code of a web page and presents it in an altered state. It adds text like “list of 3 items” and “list end.” Other screen readers such as NVDA have done similar things. Apple has, for years, developed accessibility features, and they continue to do so. Most recently, they’ve begun to use artificial intelligence (AI) to try to describe images, and to detect text. This might let you read a picture of a flier or an online restaurant menu. Indeed, Microsoft, Google, and Amazon are doing similar work. Apple also has a screen recognition mode in iOS that tries to interpret apps that developers haven’t coded to be accessible.

How is this different from what this new crop of website overlays is doing? First, in all cases, tools from Apple, Microsoft, Freedom Scientific and others are tools we choose to use, and tools we control. We can turn features on and off at will, and the companies publish documentation, podcasts, blogs and more about how these features work. Additionally, none of these companies claim that features which alter the content of the web we experience will guarantee compliance with accessibility guidelines, and they certainly don’t claim anyone is immune from lawsuits just by installing these products. TO the contrary, these companies all know, and publicly acknowledge that their tools can only do so much. Anyone building a website or app must also design and code it to be accessible, and to be compatible with assistive technology.

Finally, and of equal importance, all of these companies engage with blind people. They attend conferences, conduct research with users, and hire blind people, many of whom are members of our organization. They do this because they recognize that when you’re building things blind people will use, it only makes sense to include blind people in the process, from design through development to testing.

These companies like to tout their new features, and sometimes they introduce bugs, they fall short, or are otherwise not perfect. However, from Apple to Amazon, they know that their work is never done, that their products must continue to evolve and improve, and that blind people must have seats at the table.

Technology has evolved rapidly, and it’s been accelerated by the pandemic. AI is indeed now able to do things it couldn’t just a few years ago, and it will continue to improve. I and many others, are not opposed to tools that try, with varying degrees of success, to improve our digital experience, and even to eliminate barriers, so we don’t always need to wait for website owners to fix their sites. After all, as Tom Petty reminds us, the waiting is the hardest part. However, this technology must be guided by a philosophy that places people with disabilities, and that certainly includes blind people, at the center. This philosophy must put us in the driver’s seat, giving us control of the features and tools we choose to use. Apple’s screen recognition feature can be easily toggled off if a user finds it doesn’t work. Jaws lets you choose if each item is displayed on a separate line, or exactly how it is on screen, meaning that 3 links may read on one line. This philosophy must be one of honesty. If a site or an overlay is tracking me, I want to know about it. Indeed, in many jurisdictions, this is the law. Additionally, if I have a problem with a feature, I want to know who I should talk to about it. Finally, if an overlay is actively harming people, causing issues in a site that didn’t exist before, preventing them from paying their rent, or using a website, and these are thoroughly documented, you need to fix the issue at once, or the overlay should be removed. Just as important, the controls that operate an overlay must themselves be fully accessible. Imagine if, when you tried to change a setting in Jaws, you found unlabeled buttons, or you found that, while the settings were visually on the screen, you couldn’t easily find them with a keyboard.

In closing, I recognize the importance of technology in my life. It’s why I have the job I do. It erects barriers and it opens doors. Often, the solution to a digital barrier lies in the technology itself. I’m excited for any tool that makes the digital world more accessible, and I’m open-minded that tools will evolve. Things that didn’t work in the past may in the future. Above all though, I know that the best way to make the world a more accessible place is to work with the National Federation of the Blind.