Article Summary
Web Content Accessibility Guidelines (WCAG) were created in 1999. On May 5, 2019, WCAG turned 20 years old. We wanted to look back at those 20 years. WCAG 1.0 was created by 5 accessibility groups. These groups wrote WCAG as part of a Web Accessibility Initiative. It showed people how to make accessible web content. This was a big help for content writers and developers. WCAG 2.0 was released in 2008. WCAG 2.0 introduced a simpler structure with new guidelines and checkpoints for success. It also included two themes of accessible design. In 2018, WCAG 2.1 was released. It expanded guidelines to improve accessibility for 3 groups. It also added some new success criteria. WCAG continues to improve website accessibility, even after 20 years.
20 years ago, on May 5, 1999, the World Wide Web Consortium (W3C), announced the first edition of the Web Content Accessibility Guidelines (WCAG). The guidelines have been updated over the years, but we wanted to look back at the way that they changed the landscape for website accessibility, and say Happy Birthday WCAG!
The World Wide Web Consortium (W3C)
WCAG 1.0 was created by the W3C as a part of their Web Accessibility Initiative (WAI). This initiative was (and still is!) a partnership between organizations around the world. They worked on web accessibility through 5 activities:
- Ensuring that core technologies of the Web support accessibility.
- Developing guidelines for Web content, user agents, and authoring tools.
- Developing evaluation and repair tools for accessibility.
- Conducting education and outreach.
- Tracking research and development that can affect future accessibility of the Web.
The W3C was created to “lead the Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability.” It is run by organizations around the world, including the MIT Laboratory for Computer Science, the National Institute for Research in Computer Science and Control (INRIA) in France (now named the National Institute for Research in Digital Science and Technology), and Keio University in Japan.
How WCAG 1.0 Changed Accessible Web Content
The publication of WCAG 1.0 was a significant moment for individuals with disabilities and advocates of accessibility. Previous web content authors and developers had no guidelines for creating accessible content. This made it difficult to establish an accessibility standard, and creators were able to follow their own individual processes and preferences.
But don’t be mislead, WCAG didn’t take away a content author or developer’s creative processes and preferences. Instead, it provided them with a list of guidelines to be used for more accessible web content. For example, it was recommended that video content have closed captions, and images have alternative text.
WCAG 1.0 had two themes for creating accessible web content, along with 14 guidelines, which were “associated with one or more checkpoints” that described how each guideline was to be applied to the web content. It was the goal of the W3C to “ensure that all kinds of Web sites, including multimedia, work well for all users.”
WCAG 1.0 vs. WCAG 2.0
In the 20 years since its creation, WCAG has been updated twice. The first update, WCAG 2.0 was published in December of 2008. Here are some of the differences between the two.
While WCAG 1.0 gave a broad overview of inaccessibility issues discussed examples of accessible web content, such as captions for auditory impairment or alternative text for visual impairment, it did not give callouts to specific disabilities. WCAG 2.0, however, mentioned “visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.” It also included the issue of web accessibility for older individuals.
Additionally, the structure of the guidelines between WCAG 1.0 and WCAG saw some big changes. WCAG 1.0 had two “themes” of accessible design: ensuring graceful transformation, and making content understandable and navigable. It also followed a simpler structure, with 14 guidelines for accessibility that each had a checkpoint to ensure they were being met.
Rather than continuing with this theme structure, WCAG 2.0 implemented Layers of Guidance. These layers began with four overall principles for accessible web design: perceivable, operable, understandable, and robust (also known as POUR.). WCAG 2.0’s four principles informed its 12 guidelines, which were each assigned success criteria, instead of checkpoints.
WCAG 2.1
After WCAG 2.0 came WCAG 2.1. WCAG 2.1 was released on June 5, 2018. WCAG 2.1 used the already existing Layers of Guidance structure from WCAG 2.0, but expanded it in a few areas. The goal of these updated guidelines was to improve accessibility for three different groups:
- Users with low vision
- Users with cognitive or learning disabilities
- Users with disabilities on mobile devices
In order to do so, WCAG includes 17 new success criteria and definitions to support them, guidelines to organize them, and some additions to the conformance section.
Happy Birthday WCAG!
WCAG’s publication was historic. But with the ever-changing landscape of the web, how do we continue to celebrate it and use it on our own web content?
Well, it’s important to note that even the latest updates to WCAG will not address the needs of individuals with all types, degrees, and combinations of disabilities. In fact, it’s unlikely that any list of guidelines would ever be able to do so. However, as human evolution and technology change throughout time, the W3C will continue to work to find solutions for creating accessible web content everywhere possible.
In the meantime, there are still a few things we as individual web content authors and developers can do:
- Follow the four principles of POUR when creating web content
- Implement WCAG 2.1 on our websites and applications, following the guidelines and testing the success criteria
- Continue to ask questions and seek out advice when working to create accessible web content
- Say Happy Birthday WCAG!
With W3C’s guidelines and the collaboration of web developers, accessibility advocates, and individuals with disabilities, we can continue on a path to create web content for all.
