Standards Are Important

Introduction

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.

Some History

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.

Conclusions

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.