By Amy Mason

Accessing mainstream technology as a blind person has often been a story of Wild-West-style intuition, inventiveness, and sheer stubborn resolve. Take my story as an example. I didn’t start dealing with access technology until I was in high school. (No, I will not tell you when that was, but I will tell you that my first version of JAWS was 3.0. Feel free to do the research… and the math.) This was shortly after screen readers had begun to support the new Windows 95/98 environment. Accessing the desktop and programs like the Microsoft Office Suite was the very edge of the accessibility frontier.

I had only one afternoon of training, with my rehab counselor showing me the commands for moving the cursor on the number pad. I remember having to do archaic tasks, like going into the office file folder to remove Clippy by hand, lest he corrupt the information my screen reader needed to provide me. I remember how difficult just getting the computer to read the basics was. I remember having to stop and restart JAWS, Word, or the whole computer because it couldn’t review what I had written. It was next to impossible to get Excel to read anything at all, and the web wasn’t what we know today. Getting access to the ability to jump by headings was a revelation when it came out a few years later in JAWS (I want to say, 6… but don’t quote me on that). 

I will admit, part of my difficulty was my own lack of training, but a much larger part of the challenge we early Windows users faced was the lack of built-in accessibility hooks in Windows itself. JAWS and other screen readers were actually hacking and working around the operating system, rather than working with it. For instance, mirror drivers were pieces of software that JAWS created to scrape information directly from the video driver to process on-screen information not provided by the software it was trying to read. 

Think of this like the difference between using a GPS yourself to fill in information on a route you know and having someone in a hot air balloon relay instructions from a distance, while their GPS occasionally loses signal or they lose sight of you. In the first case, you and the technology are on the same page. There may be occasional  dropped signals, but for the most part it has the information it needs to give you what you need. Whereas the person with the GPS at a bit of a distance has a much higher chance of losing track of you and on not having the most up-to-date information on your location or what’s going on. You have an extra layer of interference between you and the directions you need—quite a bit more frustration.

In many ways, we have moved past those bad old days. Operating systems, programing languages, and websites, for the most part, can be built with hooks that the screen reader can grab to give us accurate information about our digital surroundings, not just best-guess reckoning. Accessibility for folks with other disabilities has also come a long way.

That said, we have a problem. The tools to build web and software accessibly are there, but many businesses and developers don’t know the importance of accessibility, much less how to implement it in their software. Without clear guidance and government regulations, we live in a different sort of Wild West of access. No one seems to agree on whether or not, and how, accessibility should be implemented. There have been strategic court cases from organizations like the National Federation of the Blind (NFB) that have moved our cause further, but there have also been a lot of junk click-by lawsuits that could put accessibility-as-a-standard-practice back for years. There are also a lot of folks claiming “quick and easy” accessibility fixes that don’t deliver. Without good standards and regulations, these snake-oil peddlers have a much easier time getting away with their grift, hurting the cause of access even further. We have the Web Content Accessibility Guidelines, which are fantastic, but without regulatory backing and technical assistance, many businesses will find reasons to not attempt to meet them.  

This is why the Websites and Software Applications Accessibility Act is so vital. With this act, we can create the hooks that are needed to make accessibility more seamless on the regulatory front. We have had the technical tools for quite some time now, but the regulations outlined in this legislation would provide clear guidance on how and why to use them. The NFB continues to push forward into the wildest corners of the accessibility frontier, and that won’t change. But websites, desktop, and mobile applications are all known territory, and it’s time for a little law and order in this accessibility town.