The Evolution of Web Accessibility

If you are interested in knowing about the history behind WCAG, 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.

2015: HTML5 & WAI ARIA

Today we have a number of new additions to the collection of accessibility standards with the introduction of specifications such as WAI-ARIA (Accessible Rich Internet Applications). WAI-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 WAI-ARIA in unit 8, but for now know that it is perhaps the most significant accessibility technology to emerge in recent years.

2018: WCAG 2.1 and Project Silver

When WCAG 2.0 was introduced in 2008, the iPhone had only just been released the year before, and it would not be until 2009 that it would be usable by blind individuals. WCAG 2.0 provided little guidance on developing accessible content to be accessed through mobile devices.

WCAG 2.1 is intended to fill that gap, producing guidelines to help developers comply with accessibility guidelines when developing mobile web and responsive designs for web content, among other things. WCAG 2.1 was released in June of 2018, adding one new guideline, and 17 new success criteria.

Recent Article by Scott Hollier, on changes in WCAG 2.1: WCAG 2.1: Reflections on the New Guidelines and Success Criteria.

In parallel with WCAG 2.1, project Silver has also been launched. Silver is the code name for WCAG 3.0. The focus of Silver is on integrating accessibility standards into the emerging Internet of Things (IoT). With everything from refrigerators, to home climate control systems, to security monitoring now connecting to the Internet, Silver is being developed to ensure these emerging technologies are accessible to everyone.

Why Silver? Silver’s element symbol is Ag, which represents Accessibility Guidelines.