Intro to Web Accessibility Standards

Overview

This page will introduce you to the Web Content Accessibility Guidelines, which have been adopted as the most common standard in which to work towards for web accessibility and conformance. 

Web Content Accessibility Guidelines (WCAG)

WCAG 2.0

Though it is possible to conduct informal accessibility reviews with basic understanding of the types of barriers faced by people with disabilities and knowledge of the common elements in Web content that often produce barriers, a thorough, professional review requires a solid understanding of the W3C Web Content Accessibility Guidelines (WCAG 2.0, aka ISO/IEC 40500:2012 Links to an external site.).

WCAG 2.0 (pronounced “wuh-kag”) should be a key element of your Web Accessibility Auditing Toolkit. You should develop a basic understanding of WCAG 2.0 to start, then use it and its supporting documents as references while conducting your audits and build upon the basics as you go about auditing Web content.

Watch the following video for a brief overview of WCAG 2.0 (2:31).

10 Key Guidelines

The 10 Key Guidelines of WCAG 2.0 have been summarized in a downloadable PDF document. Download the 10 Key Guidelines document, and read through it to familiarize yourself with the manner in which WCAG 2.0 addresses the most common accessibility issues.

More About WCAG 2.0: The Evolution of Web Accessibility

If you are interested in knowing about the history behind WCAG 2.0, take a look at the timeline of milestones described below.

1995: Web Accessibility Begins

It was during the mid-1990s that Web accessibility awareness began to take hold, first mentioned by Tim Berners-Lee in his keynote speech at the 1994 Second International World Wide Web conference in Chicago. The Unified Web Site Accessibility Guidelines were compiled shortly after that at the TRACE Centre at the University of Wisconsin-Madison in 1995.  Version 8 of the Unified Web Site Accessibility Guidelines became the seed document for WCAG 1.0.

1999: WCAG 1.0 Released

It was not until 1999 that the first version of the Web Content Accessibility Guidelines (WCAG 1.0) was released by the W3C's Web Accessibility Initiative (WAI). This was a significant advancement in the promotion of an accessible Web. With WCAG 1.0 it was possible to assess accessibility based on a standard, without the need to use applications like JAWS. That standard was also used by assistive technology (AT) developers (of screen readers, for instance) to better understand how AT should interact with content on the Web. One could then judge accessibility based on what the WCAG specification suggested should be done. But, there were problems with WCAG 1.0 that slowed its adoption. These problems would be addressed with the release of WCAG 2.0.

2008: WCAG 2.0 Released

In 2008 WCAG 2.0 was released to address the shortcomings of its predecessor. One of the significant changes included technology independence. This meant that what might previously have been associated with a barrier in HTML content was now a barrier regardless of the technology used. For example, “...include alt text with images”, “alt” being an HTML attribute, became “...include text alternatives for visual content”, with no reference to the technology presenting the content. WCAG 2.0 addressed accessibility across a whole range of Web technologies, including things like Flash, Java, JavaScript, and other such technologies.

A second major change was the acceptance of JavaScript in WCAG 2.0 as a legitimate Web technology. With WCAG 1.0, developers had to create alternatives to JavaScript elements they may have added to create interactivity in their Web content. In other words, a website needed to operate with the same functionality if JavaScript was turned off in a user’s browser. This severely limited what developers could do while complying with WCAG 1.0 and became another contributing factor to the slow uptake of WCAG 1.0. With the release of WCAG 2.0 this restriction was lifted. It is no longer a requirement to create alternatives to scripted features, though it is still a requirement to make those features accessible – certainly doable for most JavaScript interactivity we see in today’s websites.

Since the release of WCAG 2.0, acceptance as a general guideline for developing accessible Web content has grown. Many jurisdictions around the world have legislation based on WCAG 2.0, such as Section 508 of the Rehabilitation Act and the Americans with Disabilities Act (ADA) in the US, the Equality Act in the UK, the Disability Discrimination Act in Australia, and here in Ontario, the Accessibility for Ontarians with Disabilities Act (AODA), to name just a few. All are based on WCAG 2.0 for their Web accessibility requirements.

2015: HTML5 & WAI ARIA

Today we have a number of new additions to the collection of accessibility standards with the introduction of specifications such WAI ARIA (Accessible Rich Internet Applications). ARIA is an extension of HTML5, that allows developers to add information about roles, states, and properties to custom features they might create using JavaScript, that would have previously been inaccessible to AT users. For example, a developer might wish to use a collection of <div> elements to create a form. This is certainly possible with some script added, but a <div> was never intended to be used as a form element or to be interactive for that matter. They have no role or states or properties that would indicate to an AT user they were in a form, unlike a <form> element in HTML which has all those semantic characteristics built in by default. ARIA now allows developers to assign a role=”form” to a <div> to identify it as a form. A <div> used to create a checkbox could now have a role=”checkbox” added, and aria-checked=”true” set to have its role and state (checked or not checked) announced to AT the same way the standard HTML form elements get announced. We’ll talk a bit more about ARIA in an upcoming lesson, but for now know that it is perhaps the most significant accessibility technology to emerge in recent years.

 

WCAG 2.1

This version was released June 2018. It does not replace 2.0 but added extra requirements for mobile device support, keyboard accessibility, content reflow for low vision, non-text contrast, text spacing, identify input purpose, persistent content on focus or on hover is dismissible (see the WCAG 2.1 Quick Reference Links to an external site.).

WCAG 2.1 is the current standard for WA State Policy #188 Links to an external site. and University of Washington Accessibility Policy Links to an external site. and UW Accessibility Guidelines Links to an external site.. It has been also included in UW Procurement Policies and Procedures. Links to an external site.

WCAG 2.2

Published October 5, 2023 adding more support for mobile devices in focus, dragging and target size, consistent help information, and input assistance. In addition, 4.1.1 Parsing success criteria Links to an external site. was removed that no longer applies to current technologies as it is satisfied with using HTML snd XML. See what is new in WCAG 2.2 Links to an external site..

Accessibility Guidelines 3.0

Also referred to as Silver, the temporary project name, is a new standard in progress, currently being developed. It will aim to be easier to understand, cover more needs, be more flexible, with a different structure and broader scope. See WCAG 3 Introduction Links to an external site..

Resources