A Short History of Accessibility Guidelines

These last few weeks, I’ve been rereading the Web Content Accessibility Guidelines (WCAG). I’ve always found this document ¹⁾”Web Content Accessibility Guidelines (WCAG) 2.1″ – https://www.w3.org/TR/WCAG21/ a bit daunting – it’s around 80 sides of A4, and about half of that is just terminology! There’s even a document²⁾”Understanding WCAG 2.0″ – https://www.w3.org/TR/UNDERSTANDING-WCAG20/, which is a guide to the guidelines, which I feel speaks for itself…

I have mixed feelings about accessibility guidelines. If you build software for everyone, guidelines can help you understand the technology and avoid some of the common pitfalls. But often, they’re a cheap alternative to a real co-design process, a seal of approval (“We’re WCAG compliant!”), or an engineering checklist applied far too late in the project.

This article will be the first in a series about accessibility guidelines. I’ll try to understand what they offer, where they fall down, and what their place is in Passio’s practice. Today I’ll be writing about the history and evolution of accessibility guidelines. We’ll start with an awesome speech from a couple decades ago.

Vint Cerf – The Internet is for Everyone

In 1999 Vint Cerf (one of the “Founding Fathers” of the internet) gave a speech to the Computers, Freedom and Privacy Conference, titled “The Internet is for Everyone”³⁾”The Internet is for Everyone” – https://www.internetsociety.org/news/speeches/2011/the-internet-is-for-everyone/. He described how the internet had evolved since 1988, and what it could one day become. He even gave plans for an “interplanetary system of internets”! Vint listed ways the internet could fail to meet its incredible promise: financial and technical costs, regulation, privacy concerns etc. He emphasised a sense of responsibility – the important roles that authors and users could play in protecting the potential of this world-changing technology.

Most importantly, Vint acknowledged several groups of people at risk of being left behind: young people at risk of exposure to inappropriate content, citizens of countries where governments restricted access. One passage in particular stood out to me:

“The Internet is for everyone – but it won’t be if it is too complex to be used easily by everyone. Let us dedicate ourselves to the task of simplifying Internet’s interfaces…”

Vint Cerf – “The Internet is for Everyone”⁴⁾”The Internet is for Everyone” – https://www.internetsociety.org/news/speeches/2011/the-internet-is-for-everyone/

It’s possible he was just trying to warn us about hamburger menus and websites that hijack your scrolling. But I believe Vint was making a more general point about accessibility: the internet isn’t “for everyone” until it works for everyone.

I didn’t know it when I first read this speech, but Vint has a long-standing hearing impairment caused by a 1940s treatment for babies born prematurely⁵⁾”Vint Cerf on accessibility, the cello and noisy hearing aids” – https://www.blog.google/inside-google/googlers/vint-cerf-accessibility-cello-and-noisy-hearing-aids/. I’ve also read that Vint was driven to invent the communication protocols that power the internet largely because he was frustrated at his difficulties communicating with fellow researchers. Personally I can’t think of a better origin story for the internet.

Gregg Venderheiden – The Trace Center

4 years before Vint’s speech, Gregg Venderheiden wrote the first accessibility guidelines for the web – “Design of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities – Strategies for Today and Tomorrow” (1995)⁶⁾”Design of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities – Strategies for Today and Tomorrow” – https://trace.umd.edu/publications/design-html-mosaic-pages-increase-their-accessibility-users-disabilities-strategies.

By this point, Gregg had been working in accessibility for about 20 years. In 1971 a student at the University of Wisconsin asked for his support in helping a 12-year old with cerebral palsy to communicate in classes⁷⁾”A journey through early augmentative communication and computer access” – https://www.rehab.research.va.gov/jour/02/39/6/sup/vanderheiden.html. My favourite thing about Gregg is that he’s super humble about how and why he got into accessibility:

“Some people enter this field through an early decision to dedicate and serve. I was tricked… When I suggested some approaches to solving the boy’s communication problems, he talked me into walking out of my job in the middle of the day and going to the school, “just quickly, so I could show him what I meant, because he didn’t understand.”

Gregg went on to establish the Trace Center, with an initial focus on “augmentative communications”. Over time, they aimed to make off-the-shelf electronic equipment more accessible to people with disabilities⁸⁾”Restricted Access: Media, Disability, and the Politics of Participation” – p89. The Trace Center developed many of the accessibility features in major operating systems (e.g Screen Magnifier in Mac OS)⁹⁾”History” – https://trace.umd.edu/about-trace/history.

In his article, Gregg wrote about Mosaic (the first web browser) and the features of HTML which were likely to cause accessibility problems. For example, the alt attribute had just been added to <img> tags in the HTML 2.0 spec (released that very same year)¹⁰⁾”The Origin of the IMG Tag” – https://thehistoryoftheweb.com/the-origin-of-the-img-tag/ and most browsers didn’t support it. Gregg knew the long-term solution was to reach full support for this feature across all browsers, but was able to suggest engineering workarounds in the meantime:

• ensure that images containing inline links also included a text summary of the content
• author separate HTML documents which provide content in visual and text form, and let the user choose between them
• a “high-tech” alternative to the strategy above – generate the HTML on-the-fly using server-side rendering (a cutting-edge concept at the time)

Reading Strategies in 2019, it’s clear that Gregg had a pretty challenging job to do: the HTML specification was still in its early stages and browser compatibility was far, far less consistent than today. In many cases, his expertise let him predict how the platform might evolve, and what solutions would become available to future developers.

The “Unified” Guidelines

Over the next few years, the Trace Center began to compile some 38 accessibility guidelines from around the web, gradually forming the “Unified Web Site Accessibility Guidelines” in 1998.¹¹⁾”Central Reference Document – Version 8: Unified Web Site Accessibility Guidelines” – https://trace.umd.edu/publications/central-reference-document-version-8-unified-web-site-accessibility-guidelines Like Gregg’s Strategies, the Unified Guidelines focus mostly on accessibility concerns with the HTML specification itself.

One significant change with the Unified guidelines is that the Trace Center rated guidelines as required or recommended depending on whether they were essential to access information on a page.

The World-Wide-Web Consortium (W3C), (founded several years earlier by Tim Berners Lee), increasingly took responsibility for guidelines around web accessibility. This meant The Unified Guidelines would go on to become the foundation of the first version of the Web Content Accessibility Guidelines.

World Wide Web Consortium (W3C) – WCAG 1.0

WCAG 1.0¹²⁾”Web Content Accessibility Guidelines 1.0″ – https://www.w3.org/TR/WAI-WEBCONTENT/, completed in 1999, had two broad approaches for considering accessible design:

1. Graceful transformation – because web pages can be viewed on many devices by users with varied needs, our content and functionality should adapt to these different contexts
2. Content should be understandable and navigable – different navigation options will be apparent or available for different users with different needs, so attention should be paid to making this work for everyone

Instead of simply listing HTML components and their issues, WCAG 1.0 was conceptually structured, using guidelines, checkpoints, priorities, and conformance levels to frame thinking around accessibility.

• 14 broad guidelines for accessible design e.g “2. Don’t rely on color alone”
• 1 or more practical checkpoints corresponding to each guideline
• A priority for each checkpoint, measuring its impact on how various groups could access information in the document
• 3 conformance levels for measuring a site’s accessibility level, based on which checkpoints a website conforms to

Themes Over Time

One (predictable) thing I noticed while reading through all these documents is that their scope and complexity has evolved alongside the technologies they describe. Since Gregg’s Strategies in 1995, HTML has been through 3 major revisions, entire web browsers have come and gone, we have a whole range of new devices for consuming web content.

These changes means that software engineers need to work harder (and incidentally read a lot more) to understand the platforms and audiences they build for. Thus, in recent accessibility publications (e.g WCAG 2.0), more focus has gone into making the key recommendations easier to understand and implement.

It’s also interesting to note that, over time, these documents have gradually evolved from technical discussions about specific shortcomings with the technology into ones which focus on the entire process of designing and building accessible content. For example, WCAG 2.0 recommends avoiding jargon, that navigation behaves consistently, and that user input in forms is validated.

Lastly, it feels significant that in more recent guidelines, the documents are clearly designed to provide a framework for auditing a website’s compliance to a set accessibility standards. These standards can even provide the basis for law (for example, the European Union directive 2016/2102, which requires public sector bodies to comply to WCAG 2.1 Level AA).

While this perspective means that these guidelines can be used as a lever to lift the standard of accessibility on the web, it also pushes designers and developers to see guidelines not as an opportunity to better understand the technology and their users, but primarily as a test they either pass or fail. As with all metrics, it’s important to understand exactly why you’re putting faith in them before you put them in charge!