In this first video, I explain the Web Content Accessibility Guidelines (WCAG) 2.
In this episode, I’ll explain the structure to the Web Content Accessibility Guidelines — WCAG — and how you can start following their requirements.
My name is Eric Eggert and I work in Web Accessibility for over 10 years. You can follow me as @yatil on social media.
Now, what is WCAG?
The Web Content Accessibility Guidelines are a set of principles, guidelines and success criteria that lead you to accessible web content.
They are a web standard published by W3C, the World Wide Web Consortium, and with every web standard the assumption is that web content creators adopt it into their practices.
Version 1 was published in 1999, so over 20 years ago, and Version 2 in 2008. It was refreshed in 2018 with WCAG 2.1.
What’s the difference between WCAG versions, you ask?
Version 2.0 was a complete rewrite with new principles and a new structure. It completely replaces WCAG 1.0 which was technically not holding up anymore.
WCAG 2.0 is agnostic to technology which gave it a longer shelf-life out of the box. And it is the basis for accessibility today.
2.1 expanded on WCAG 2.0 by adding new criteria but without removing or changing any of the 2.0 guidelines. Think of 2.1 as an extension of WCAG 2.0.
WCAG 2.2, which is supposed to be coming out soon, basically does the same thing with probably one exception. Subscribe to this channel and click the bell icon to get notified about new videos, including a WCAG 2.2 introduction once it is ready.
When I talk about WCAG in the future, you can always assume WCAG 2 and I will say the specific version where necessary.
That also means that if you conform to WCAG 2.1, you automatically conform to WCAG 2.0. — How neat! — More about conformance in a bit.
Let's talk about the structure of WCAG 2.
The main — normative — WCAG document has three levels of guidance:
Basic qualities that every website needs to have when it comes to accessibility.
Follow the guidelines when planning and designing your website and application to make sure you’re on the right track.
Verify your work by using success criteria to see if you have been successful following the guidelines and principles.
Sidebar: Normative information is information that is the confirmed standard as published by the W3C and not additional explaining information.
On the first level, four high-level principles are defined, that you have to keep on your mind:
Information and user interface components must be presentable to users in ways they can perceive.
This principle makes sure that disabled people can see the content or have alternatives available in case they need them. It covers making images perceivable through alternative text and videos through captions and audio descriptions.
User interface components and navigation must be operable.
This principle allows users to use their preferred technology to operate the website or web application, for example many users can’t use a mouse, either because they are using a screen reader or a refreshable braille display to interact with a website. Others might have repetitive strain injury (RSI) and just be temporally unable to use a pointing device.
Information and the operation of user interface must be understandable.
This principle is a combination of making sure that the content is easy to understand and that you can interact with the website or application in an understandable way. For example, this principle covers specifying the language of the page and parts of text and also assisting users when filling out forms.
Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
This is probably the most technical principle. It underlines how important good code is for accessibility. If your code is buggy or components are used wrongly, the technology used by users might not be able to interpret the information the way you and users want them to.
The Guidelines are situated underneath the principles and give more specific advice for different situations.
Principle “1. Perceivable” has four guidelines:
1.1 Text Alternatives
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
Whenever content is on the page that is useful or essential for the understanding of the whole page or view, an alternative in text form must be provided. That alternative can be used in different contexts.
1.2 Time-based Media
Provide alternatives for time-based media.
Time-based media is WCAG language for (mostly) audios and videos. Similar to “text alternatives”, this ensures that people with different disabilities have access to the media content. For example, this guideline requires captions, to enable access for people who cannot hear narration, and audio descriptions, which enable access for people who are unable to see a video.
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
This guideline prepares content to be used out of the context or styled and viewed differently. Here’s where semantic markup comes into play. It also means allowing users to use their devices in any orientation.
Make it easier for users to see and hear content including separating foreground from background.
Avoid the use of color alone or low contrast colors for text, information, and UI elements. Allow resizing of text and changing the viewport, for example by implementing a responsive design.
The second principle, Operable, has 5 guidelines:
2.1 Keyboard Accessible
Make all functionality available from a keyboard.
This is important as many technologies disabled people use are using keyboard commands to navigate around, even as the users are using joysticks or other input methods.
2.2 Enough Time
Provide users enough time to read and use content.
Avoid introducing arbitrary time limits and let users take as much time as they need. If there’s a requirement to restrict the time for a certain task — for example for security reasons — the user must be informed and given a way to extend the timeout.
2.3 Seizures and Physical Reactions
Do not design content in a way that is known to cause seizures or physical reactions.
This guideline targets flashing content and motion animation.
Note that this guideline was extended to cover physical reactions with WCAG 2.1, you might find the old wording, which only talks about seizures, occasionally.
Provide ways to help users navigate, find content, and determine where they are.
Examples of requirements that come from this guideline are the ability to bypass blocks of content, having proper page titles, and proper keyboard focus and a visible focus outline.
2.5 Input Modalities
Make it easier for users to operate functionality through various inputs beyond keyboard.
New in WCAG 2.1, this guideline expands interaction with the page or application when the keyboard is not used. For example, websites and applications must provide an alternative to pinch and zoom gestures you use two pointers/fingers for.
Principle 3, Understandable, has 3 guidelines:
Make text content readable and understandable.
This guideline covers languages and language transitions, the explanation of unknown words and abbreviations, reading level, and pronunciation.
Make Web pages appear and operate in predictable ways.
The guidance in this guideline makes sure that users are not surprised by the things that happen on the website and also that common elements look the same.
3.3 Input Assistance
Help users avoid and correct mistakes.
This guideline advises to label your form fields in a useful way, identify errors and provide suggestions on how to prevent errors in the first place.
The last principle, Robust, has only one guideline:
Maximize compatibility with current and future user agents, including assistive technologies.
Write conforming HTML code, make sure that the names, roles, and statuses of UI elements are clear.
I won’t go into success criteria this time — subscribe and click the bell to get a notification when I do — but remember that these build the ruleset to see if you have met the minimum requirements of the guidelines.
You should always aim to exceed these success criteria.
Techniques & Understanding
When you come across WCAG, you will quickly stumble over techniques and understanding documents. They are linked right from the specification!
Note that those documents are non-normative documents, they can help you to understand WCAG but their guidance does not necessary mean you meet WCAG. The techniques are a collection of examples of how to meet a success criterion, either narrowly — WCAG calls this “sufficient technique” — or as a best practice. WCAG calls this “advisory technique”.
Let’s talk about “Conformance” & “Conformance Levels”
These phrases are often used when people talk about web accessibility, especially in association with WCAG and lawsuits.
Conformance determines that the website follows all guidelines in WCAG and all applicable success criteria are met. It is usually used in the testing process to have something “firm” or absolute to test against. However, there’s always some room for interpretation.
WCAG success criteria can have one of three levels — A, Double-A, Triple-A — and to reach that conformance non of your page can violate any success criteria at that level.
The lowest level, A, ensures basic accessibility. If you reach this level, you are not actively excluding most disabled people.
The second level, Double-A, ensures accessibility for most people with disabilities. This is the level most laws and policies demand. To reach it, you need to confirm to all success criteria that are level A and Double-A.
The third level, Triple-A, are what I call “stretch goals”. These are either niche or otherwise hard to achieve but depending on your website it can make a lot of sense to offer features that fall into this conformance level.
So, that was an overview on the principles and guidelines of WCAG as well as a look into conformance.
Stay tuned to learn more on different success criteria and generally about web accessibility on my channel. Make sure to click subscribe and hit the bell icon to not miss anything. And of course you can support me on Patreon at patreon.com/yatil or follow me at twitter.com/yatil.