Web Content Accessibility Guidelines — What is WCAG Compliance?
Jan 7, 2020
WCAG 2.2 was released in October 2023. To learn more, please view our WCAG 2.2 AA Summary & Checklist for Website Owners.
Summary: Learn about the Web Content Accessibility Guidelines, the different versions and levels, requirements for WCAG Compliance (a misnomer for WCAG conformance), and why websites should be accessible.
The Web Content Accessibility Guidelines (WCAG) are an important asset for businesses, organizations, and other entities who want to make their digital content accessible to all people. Just like the name states, WCAG is a detailed set of technical guidelines explaining how you can make your website, app, or other digital properties accessible to people with various kinds of disabilities.
The guidelines specify what to look for when designing or reviewing a website, application, or digital document for accessibility barriers. Most importantly, WCAG conformance—sometimes inaccurately referred to as WCAG compliance—means your business is meeting WCAG standards, which are a common standard adopted by international, federal, state, or local anti-discrimination and accessibility legislation. And while WCAG itself is not legislation, it is the universally accepted standard for web accessibility around the world.
WCAG compliance vs. conformance
Compliance is an important term in the world of web accessibility, since there are several laws—from the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act of 1973, in the U.S., and many other pieces of legislation—that require compliance. For this reason, many people also wonder how to achieve WCAG compliance.
But there’s a crucial difference between WCAG and laws regulating digital accessibility. WCAG is not itself a piece of legislation, so there is technically no such thing as WCAG compliance. Instead, the success criteria included in WCAG are designed to help website owners achieve the level of accessibility that is required by laws such as ADA, Section 508, and the Accessibility for Ontarians with Disabilities Act (AODA). So, put simply, WCAG conformance is the global gold standard for web accessibility and is considered a best practice for compliance.
What does WCAG cover?
WCAG offers an extensive list of guidelines on making web content more accessible to a wider range of people, including people with disabilities. When these guidelines are not followed, the way a site or app was created can include barriers that prevent people from using digital platforms, preventing effective communication with them. Unless these barriers directly affect you, you might have an extremely difficult time knowing they exist. That’s where WCAG comes in.
The guidelines include a wealth of success criteria for making a digital experience accessible and following best practices for compliance with anti-discrimination legislation. The following are just some examples of what WCAG addresses:
- Pre-recorded and live video with audio content needs to have captions for those who are deaf or hard of hearing, or who process information better by reading.
- Pre-recorded audio content files need to have a written transcript. This is also helpful for people who want to listen to an audio file, but can’t turn their sound on, or are in a noisy environment.
- Non-decorative images, including those used for an image button or link, must contain descriptive alternative text (alt-text) so people who are blind or have low vision have an appropriate description of the image. Alt-text, when accessible without assistive technology, can also help anyone better understand the contents of an image. On-page text must be resizable without causing items on the page to be cut off or missing displays, so people with low vision can magnify content and have an easier time reading.
- All timed functions such as form-entry tasks need to exist without a time limit or include an extended, extra time limit so people who need more time to fill out forms have the time they need.
- Components that exist across multiple web pages, like navigation, headers, footers, and sidebars, must consistently appear in the same places across a website so people always know where to find them, regardless of what page they’re on. For example, your sidebar can’t change from left to right depending on the page. The navigation can’t go from being anchored to the top to appearing on the bottom.
- Users must be able to navigate your website without the use of a mouse. For example, users should be able to use the “tab” button on a keyboard to progress through content on a given page. This is useful for people with motor disabilities, and many other individuals, including someone who may be dealing with an injury to their dominant arm or hand.
- All web pages must use proper heading-level structure so people using screen readers, especially people who are blind or have low vision, can easily understand how the page is organized.
Designers, developers, and authors creating web experiences need to keep these guidelines, and the barriers they prevent, in mind when designing and coding digital experiences.
Universally accepted standards
What’s special about WCAG is that it’s developed by a working group of stakeholders, including experts, regulators, academics, and business people from around the world The international community that develops the WCAG compliance (i.e., conformance) guidelines is called the Web Accessibility Initiative of the World Wide Web Consortium, or W3C. This group of staff, member organizations, and public members from all over the globe combine their expertise and energy to create these and other important standards for the web.
Versions of WCAG
WCAG exists in four versions: 1.0, 2.0, 2.1, and 2.2 (currently in draft form). The guidelines are regularly updated to keep pace with changes in technology. The first version of WCAG, known as WCAG 1.0, was released in 1999, and is no longer recommended for use. A later version, WCAG 2.0, came out in 2008, and for ten years it was the most up-to-date and most universally accepted set of web accessibility guidelines available. In June 2018, the W3C released WCAG 2.1, which builds upon the guidelines in 2.0, including additional information about newer technologies, and addresses a broader range of disability-related needs. We anticipate the release of WCAG 2.2 in 2023, though these standards are already available in draft form.
Why has so much changed since WCAG 1.0 ? In the fast-moving world of technology, a lot can change very quickly. By the time WCAG 1.0 was released, programmers were developing websites in new and different ways. That’s just one reason why an update was needed; version 2.0 takes into account more advanced technologies that aren’t covered by WCAG 1.0. WCAG 2.0 was created in a technology-agnostic way that allows authors to meet the standards using different techniques, allowing for flexibility. WCAG 2.1 built on 2.0 addressing how web content is consumed on touchscreen devices, different sized and orientation screens, and devices with sensors (like a mobile device).
Here are a few of the other key differences between the versions:
- The 2.0 and 2.1 versions reflect efforts to harmonize web accessibility standards that are already in place around the world.
- Versions 2.0 and 2.1 improve understanding. For example, they include concrete examples to illustrate how the guidelines apply in the wild, such as supporting techniques and typical accessibility errors that web designers make, along with other resources and supporting materials.
- 2.1 expands the guidance provided in 2.0 to include more provisions for people with low vision and cognitive and learning disabilities, helping organizations to improve inclusion and better serve a wider audience with 17 new requirements.
It’s important to note that content that conforms to WCAG 2.1 also conforms to WCAG 2.0. (in other words, each version is “backwards compatible”). Therefore, a website that meets WCAG 2.1 should meet the requirements of policies that reference WCAG 2.0.
To put it another way: If you want to meet both WCAG 2.0 and WCAG 2.1, you can use the 2.1 resources and you don’t need to bother looking at 2.0. The W3C encourages you to use the most recent version of WCAG when developing or updating content or accessibility policies.
The guidelines are divided up into three levels of conformance: A, AA, and AAA. Each level builds on the previous level like a pyramid. So, in order to meet Level AA you must meet all of Level A and in order to meet Level AAA you must meet all of Level AA.
- WCAG Level A: This level represents the base level of conformance. Level A criteria affect the broadest group with the most benefits and are essential. But, with the base level of support, some barriers will still exist which impact certain groups of users.
- WCAG Level AA: This level is the most common target conformance level, often adopted in regulations or negotiated in legal settlements. The criteria at this level establish a level of accessibility which works for more users, including those who use assistive technology.
- WCAG Level AAA: This is the highest conformance level achievable, meaning it covers the success criteria of all three levels. However, as we’ve explained in a separate blog, level AAA is not applicable or realistic in all situations. Some organizations may choose to adopt specific criteria at this level.
What a difference WCAG makes
When your organization’s website follows WCAG’s broadly accepted web accessibility standards, you are ensuring that people with a variety of disabilities, who may be using multiple different assistive technologies, are able to make full and independent use of your site.
Take, for example, the experience of someone who is blind and relying on a screen reader to read the text on a website aloud. Imagine that this user lands on the homepage of a restaurant, when suddenly, loud jazz music starts playing, and they can’t hear the speech output from their screen reader. They could turn down their computer’s volume, but that would also lower the volume of their screen reader—not helpful!
Giving the user flexibility to control audio that plays automatically, a WCAG requirement, not only allows the user of a screen reader to review the site with text-to-speech but also allows all users control of the experience when they are in situations where they need to be quiet. That means a more comfortable, efficient user experience for the individual web user, and most likely, a retained customer for the restaurant.
Another requirement is that links communicate their purpose. This way, a user does not have to click on a link, wait for the page to load and use their assistive technology to read parts of that page”¦ before they have any idea what the link actually leads to.
In addition, WCAG requires that websites provide text alternatives for non-text content as well as captions and other alternatives for multimedia. These features are necessary for users who are deaf or hard of hearing with hearing impairments to be able to access and enjoy content like videos or podcasts. While this should be obvious, the reality is that before the existence of digital accessibility laws and guidelines, plenty of websites looked over this important issue.
These are just a few of the many accessibility considerations that WCAG makes plain for web content owners. So, how do organizations actually go about conforming with these criteria? Keep reading to learn more.
Conforming to WCAG criteria
Understanding the importance of WCAG is the first step to creating a more accessible online experience for all. The next step is taking actions to ensure your web content conforms to the latest version of WCAG. This begins with an accessibility audit that will reveal your organization’s current state of accessibility. From there, an organization can use the insights from its audit to make improvements in line with WCAG criteria to improve usability and accessibility for everyone.
Performing an accessibility audit can be complex. While automated tools can help, they provide an incomplete picture of a website’s accessibility level. The best approach is to use a combination of automated and manual testing. If this task seems overwhelming, an accessibility partner can make the path clear, reduce the complexity with the task, and guide you in prioritizing efforts. Not only can they arm you with a detailed WCAG checklist and walk you through automated and manual testing, but they can also provide guidance as you implement the changes that will bring your web content into conformance with WCAG.
Find out how our Accessibility-as-a-Service platform can help you ensure WCAG conformance, and put you on the path to compliance with disability regulations, by connecting with our team today.