For nearly twenty years, the community of people working on disability related issues involving technology have worked very hard to create a set of standards, guidelines and best practices for accessibility. This article intends to explore the history of why the rich set of standards we now have available to developers had to be created and why it is essential that standards based, objective measures are the only way to reliably measure the accessibility of a device, an app, web site or an operating system.
It’s Not Just About Blind Users
This article was motivated by a tweet I received from one of my Twitter friends. I had stated that universal accessibility means including people with all disabilities, not just we blinks. His response, “why do i when i look at a phone or computer should i care about other disabilities? like motor impairment…” startled me. He, a blind person, was stating boldly that if technology works for him with a screen reader, that it didn’t matter if it also works with access technology designed for people with disabilities unrelated to vision. Following his logic, all mainstream web developers should probably just ignore the accessibility standards altogether as, if we blind people don’t care about people with other disabilities, why should any web developer care about people with any disability, blind or otherwise?
As far as I can tell, all technological accessibility standards of which I am aware are designed to provide access to people with as many different disabilities as possible. Hence, a standards based approach to accessibility solves not just problems encountered by people with vision impairment but allows for access technology designed for every imaginable disability to function successfully.
Fifteen or so years ago, when the Internet was truly the wild west, accessibility was handled on a site by site, AT by AT basis. Web sites that used mostly text and stuck to standard controls were, more or less, accessible; those that were more visually appealing were rarely so. The world is dominated by sighted people who like looking at pretty things and highly visually oriented web design became the norm so accessibility of web content had to be invented.
Screen readers like JAWS and a nifty Internet accessibility tool from IBM called Home Page Reader (HPR) started tackling the problem of delivering the Internet to people with vision impairment. GW Micro used the strategy of gathering its web information using the Microsoft Active Accessibility (MSAA) API, which, as we’ll see, wasn’t yet up to the task of supplying a screen reader with everything it needed to provide to its users. JAWS, Window-Eyes and the popular low vision tool, ZoomText all also used different heuristics for gathering information from a web browser that were as non-standard and as proprietary as proprietary can be. In the blindness/low vision space alone, chaos dominated the accessibility field.
The Invention of the Virtual Buffer
While GW Micro chose to stick with the MSAA approach to web accessibility, the teams at Freedom Scientific and IBM took JAWS and HPR in a radically different direction. With the release of JAWS 3.31, the world of blind computer users were introduced to the virtual buffer, now the standard way of delivering web content in all Windows based screen readers.
[Just a definition: the term “virtual buffer” was coined by Eric Damery, Glen Gordon and me in a meeting at FS in the months immediately prior to the 3.31 release. Our definition of the term was, “a buffer with no on screen components that a user could read using arrow keys like in a word processor, activate links and do a few other things necessary then for JAWS to provide superior access to the Internet.” In the years since, though, only when speaking to friends who work on or use the Orca screen reader on the Gnome desktop, I’ve heard a modified definition of “virtual buffer” that adds a component of preprocessing done by a screen reader to the data before it is placed into the buffer to be read by the user. As it is very true that both JAWS and HPR did, indeed, include augmentations to the text as well as including workarounds to force some information to be readable when it was far from accessible in a standard manner, the term “virtual buffer” with both definitions apply.]
The teams working on JAWS at FS and on HPR at IBM came to an identical conclusion simultaneously. If we want to provide a rich web browsing experience to blind computer users, if we hope to follow the web User Agent Guidelines (UAG), we cannot use MSAA to gather the data as MSAA didn’t support most of the elements needed to comply with the UAG. At FS, we solved the problem by using the VBA interface to Internet Explorer and ask it to give us all of the HTML it was using to display the page on screen. JAWS then, as if it was a mini-browser built into a screen reader, would parse the HTML itself, add words like “link” and the like and place the user into a “virtual buffer” that could be navigated like a word processing document. IBM would follow about six months later with a very similar solution in HPR.
Virtual Buffer Workarounds
Both FS and IBM took the approaches we chose in order to provide the best possible experience to blind users who wanted to use the Internet. Neither team should ever apologize for what we did as, if we had waited for standards to emerge, our users would have had no more than a tiny fraction of what we could provide through what, in retrospect, were truly ugly, kludgerous hacks. In our quest to make an excellent experience for ourselves (both the JAWS and HPR teams were filled with actual users, something GW Micro couldn’t boast), our users, our customers and to set a bar for what “excellent” meant for accessibility to blind users of the Internet meant, we broke every rule in the book and, to this day, I’m proud of that work.
Unfortunately, there was, as is often the case, unintended negative consequences of our having taken the law into our own hands. Specifically, a lie started to spread around the community of people interested in web accessibility and I was one of the people who promoted the great falsehood, “A site is accessible if it works with JAWS.”
JAWS was, without a doubt, the gold standard for accessibility for people with profound to total vision impairment and, indeed, regarding standards, JAWS and HPR could boast a score of greater than 90% when tested against the user agent guidelines while Window-Eyes and the Dolphin products scored forty precent and below so we were “standards compliant” in that regard. We were not, however, compliant with the web content guidelines and all of the razzmatazz that we did behind the scenes to make non-compliant content appear to our users in an accessible manner made JAWS a terrible testing tool for all but one case: testing if something was compatible with JAWS. In those days, a web site could claim it was “accessible” if they tested it with JAWS and it worked but users of Window-Eyes, ZoomText, the Dolphin products and access technology designed for disabilities other than blindness were screwed.
The Testing Against JAWS Hangover
A decade ago, when JAWS was the king and truly set the standard for accessibility on the web for blind users, the statement that something was “accessible if it worked with JAWS,” while untrue, did hold some credibility. By 2004, JAWS was holding a monopoly marketshare and, as the other screen readers were far behind in standards compliance, was also the one blindness related product that one could use to exercise the standards fully. I don’t know if it’s still there but FS then published an HTML document we wrote with a title like “The HTML Challenge” that one could load into their favorite browser with their favorite screen reader to see just how much of the standard was exposed to them. Of course, users who tried the challenge with JAWS or Home Page Reader got terrific results; those who tried it with Window-Eyes, HAL and other screen readers were sadly disappointed with the product they chose.
Thus, for good reasons a decade ago, the practice of testing web content against JAWS became a practice used at many web development shops that care about accessibility. Unfortunately, today, it is both unnecessary to test with JAWS but, even worse, JAWS is no longer the screen reader most compliant with web standards like WCAG 2.0 and WAI/Aria. Today, the top screen reader regarding standards compliance is NVDA, a FLOSS screen reader for Windows.
This does not, however, mean that testing against NVDA is a guarantee of standards compliance either. Remember, testing against a screen reader will only provide you with results apropos to screen reader users and will ignore important aspects of the standards that are meaningless to people with vision impairment.
One really important item in WCAG is the regulations on the rate with which something can “flicker” on the screen. Obviously, NVDA, JAWS or any other screen reader wouldn’t monitor if something is flashing on and off, blind users wouldn’t care but some people with epilepsy can have a seizure triggered by an object on the screen flickering at a specific number of hertz. In some cases, such seizures can cause permanent brain damage so this is a really important part of the accessibility standards that one would miss if they only test against a screen reader.
If Not With JAWS, How Can We Test?
There are a number of good automated accessibility testing tools out there and I’m (as part of a new project I’m doing on another blog) working to build a web page filled with pointers to such resources. As I’ve just started creating a catalogue of such tools and haven’t had the time to see which are current, which are free, no cost or come with a hefty price tag and which are accessible (I’m not going to promote an accessibility tool that a PWD cannot also use), I haven’t such a list to post publicly yet. I am told that the Internet Explorer accessibility plug-in from The Paciello Group is very good but I can’t vouch for it myself. I’m sure if you google “web accessibility test remediation tool” you will find some other good ones as well.
Now, Standards Exist
As I wrote above, fifteen years ago, AT developers had to hack their way through web accessibility; today, that is no longer true. Today, we have standards like the Web Content Accessibility Guidelines 2.0 (WCAG), WAI/Aria for web apps and, most recently, the BBC Mobile Checklist for device accessibility. There is no reason that any technology in 2014 is not fully compliant already as none of these standards contain any difficult engineering. Some of the aspects of making a web app accessible can be tricky but if you’re an accomplished enough a developer to be making a complex web app, I’m highly confident that you can figure out the WAI/Aria part as well.
A Call For Universal Accessibility
Atop this article, I mention the problem that can arise when blind people decide that we’re “special” and agree to leave behind people with other disabilities as if they didn’t matter. If we make the argument, “it works for me” and walk away from other groups who benefit from standards based accessibility, we are cutting our own throats. The reason that the web is more accessible today than ever before is because an increasingly large number of web sites are choosing to be compatible with standards and guidelines for accessibility. If we, as consumers of access technology eschew standards in favor of our own selfish desires, we are endorsing bad accessibility for ourselves as well.
If you want to make sure that your web site is accessible, please do so in a manner that is based in the standards and don’t just test with a screen reader. Testing with a screen reader is a good way to ensure that you’ve gotten most things right but, unless you’ve tested against the standard itself, you may accidentally trigger a seizure somewhere by accident.
If you are a consumer of access technology, whether blind or otherwise, insist that your AT be as standards compliant as possible so you can enjoy the excellent accessibility available in programs like Microsoft Office Online.
If you are a person with a disability, please try to stand together with those of us who endorse universal design as the only appropriate route to universal accessibility. The route to universal design on the Internet is through standards compliance, whether accessibility related or not. If we, as blind people, ignore the needs of those with other disabilities, we are simply begging the mainstream to ignore our needs as well.
Pratik Patel says
thank you, Chris, for these excellentthoughts. I’m glad that blind people are finally beginning to recognize the importance of standards. As you saw from my “Android is not accessible post,” I firmly believe that blind people are not the be all and end all of the accessiiblity world. We get the most predominant amount of attention. Accessibility is one case where attention to universal accessibility will not be detrimental to accessibility for the blind.
Birkir Gunnarsson says
Excellent blog, as a number of others you have written.
As a blind web accessibility tester myself, I almost obsess over testing for things outside of the screen reader space, though it is certainly challenging at times.
I am collecting information and tools for thorough standards-based accessibility testing for blind web accessibility testers, something I want to publish as a webpage. I already have some truly awesome folks providing some input, (Bryan Garaventa, Leonie Wattson and others) I may have some of the info you are looking for re accessible tools and techniques. I am even working on a series of blog posts about how we can most efficiently borrow a set of eyes to carry out tests that automated tools are unable to provide us and we are unable to carry out properly. A pair of eyes is a valuable and sometimes expensive commodity, so if we know precisely how best to use them, it is a great thing (and, yes, they usually come with a person so the approach has to be slightly different based on their backgrounds and experience, but I think we can narrow testing down to a couple of simple and intuitive set of procedures they can carry out without too much in-depth knowledge of accessibility standards).
so feel free to be in touch. My work is somewhat delayed at present due to work engagements and the family moving, but in June and July I really intend to kick this work into gear. Keep up the good posts!
brandon armstrong says
so according to you and your miss guided logic we as blind users should test web accessibility with other tools other then a screen reader? as for the phone basing it on does it have things for motor impairment your out of your mind and need a brain check. I do care about them, but why should i base my decision on whether a phone can do things for motor impaired, when I know they don’t base their decisions on how well a phone works whether with voiceover or talkback?
I recently ran into your blog ow! having known your name from FS and mutual acquaintances related to a11y and the CSUN annual tech and disabilities conference in San Diego. I was wondering if you could speak a little (or guide me to where you may have already talked about) the way that accessibility and scripting is being taught in colleges and universities. In order for something to become accepted as universal, it almost needs to be accepted as normal first. Architecture and engineering students are learning about ramps as a normal part of their classes. Do you know if computer science or engineering students may be required to take at least one human computer interaction (HCI) class where they are taught what to consider for a user who does not interact with the computer using sight, or maybe fine motor control, etc?
I am asking this genuinely; as a graduate student in an entirely different subject, with full vision, I use one hand to type, and have attended the CSUN conference in my hometown now twice to see what is new with WCAG etc. I am still hearing that university students seeking to go into computer fields are still not required to take any HCI classes whether they are in a 2 year or 4 year program. Last year I helped with the State Dept Office of e-Diplomacy to assess the percentage of federal websites that are considered accessible by standards, and depending on the agency, more than half were not up to standard. The excuse I heard most was that the contractors who created the sites were not fully aware of the requirements, or just did an automated test and called it a day, or lied about compliance and the agency winked and brushed it aside.
When I tried to approach the HCI and computer faculty at my school they did not respond. Even the Office of Students with Disabilities is hard to reach here though.
Do you have any comments? What requirements would you put in place for programming-related students?