Join Natalie and Natalie for the second episode of the AAArdvark Accessibility Podcast, where they go over the structure of WCAG, what it’s used for, and who uses it.
Natalie Garza: Hello and welcome to the AAArdvark Accessibility Podcast. Welcome my guest today, Natalie, web accessibility expert.
Natalie MacLees: And my host is Natalie, an accessibility novice.
Natalie Garza: Thank you for joining us today. This is our second episode, where we’re going to go into detail, down to the nitty-gritty, about what WCAG is. We’re going to explain what it is, how it’s structured, who uses it, and go over some last details not many people know about. Stick around for the end of this podcast to learn everything there is about WCAG.
Alright, Natalie, let’s kick us off. What is WCAG? What does this acronym stand for?
Natalie MacLees: It stands for the Web Content Accessibility Guidelines, and it’s a set of guidelines that let us know how we can make content online accessible so that it will work with people’s assistive technology and browsers.
Natalie Garza: And who even develops and maintains this?
Natalie MacLees: A secret group. No. It’s the Web Accessibility Initiative, which is part of the W3C, that oversees all of the standards for the internet.
Natalie Garza: So not the secret society of the Illuminati at the Denver airport. Thank you.
Natalie MacLees: No, unfortunately not. That would be so much more interesting.
Natalie Garza: Now let’s go into why it’s confusing for a lot of people. Because when I first started learning about WCAG, I was incredibly confused. I didn’t know where to look. Nowhere really lays out how to use this.
Natalie MacLees: Yeah, yeah. I remember you were really struggling at first to understand how it was organized, how it was set up, how it was structured, right? Yeah, it’s pretty confusing. You know, we have a committee who’s designing it. So the members on the WAI are just different representatives from the tech industry who get together to write the WCAG guidelines.
So you have a committee, first of all, of people who don’t work together full-time, they work for other companies, and they’re just coming together. They’re not necessarily trained in data structures, how to design a data schema. So that’s another challenge that they’re up against.
They have some pretty strict rules around maintaining backward compatibility and not being able to change numbers or update existing rules. So when they realize something needs to be added, it has to be added as a whole new rule, and things can’t be renumbered, right? So we have to know if I talk to you about 1.3.4, that’s the same. It doesn’t matter if it’s, if that happened in 2004 or 2014 or 2024, 1.3.4 has to be the same rule.
So they have that, that they’re up against. And obviously technology changes all the time. Browsers change all the time, but WCAG has to stay the same. So it’s a real challenge to try to kind of maintain that and stay on top of it, but keep it relevant.
Natalie Garza: And could you go over some of the information that gets posted on WCAG?
Natalie MacLees: Yeah, what do you mean?
Natalie Garza: I mean, like, whenever they’re writing these, like, who are they really targeting, and why is it so hard to read?
Natalie MacLees: Sure.
They are definitely targeting very technical implementers of the accessibility rules. Um, because you pretty much have to be a developer to go in and understand what they’ve written about, you know, what is 1.3.4? And how do I tell if what I have done is passing it or not? And if it’s not, what do I need to do to get it there?
It’s very technical and very dense. And difficult to understand if you don’t have a really good knowledge of how HTML and CSS and JavaScript all work together to try to figure out what those rules mean and how you would go about using them.
Natalie Garza: What is WCAG used for?
Natalie MacLees: It is used as the measuring stick for accessibility. So that’s how you tell if you’ve built something to be accessible, is does it meet this set of principles? You know, it’s the beginning of that. Um, how can I tell if my website is accessible? Well, you check and you see, does it follow these, the set of rules? Does it meet all of these guidelines?
Natalie Garza: Right, so it’s either a yes or no. You are or you aren’t. True.
Natalie MacLees: Well, if you go by that yardstick, everything is a no, because there’s no such thing as something that’s 100% accessible.
Natalie Garza: True. We’ll come back to that later.
Okay.
Alright, so, with all that said, we’re here to explain it. We’re gonna break down the structure and go over how to understand WCAG. So, Natalie, do you want to start with the organization?
Natalie MacLees: Sure.
So you have a whole set of success criteria, which are the individual rules that you need to meet, which are things like your images have to have alt text or some kind of text alternative. So somebody who can’t see your image for whatever reason can still understand why that image is on the page and what’s in the image, what the context for the image is.
And all of that, another success criteria would be color contrast. Is there enough contrast between your foreground and background color? You can’t put really dark gray text on a black background, for example, because nobody’s going to be able to see that. So that’s another example of a success criteria.
The success criteria are then gathered up, the ones that are related to one another. Those are gathered up into a set of guidelines. So now we have them in groups of guidelines. So an example of a guideline would be just distinguishable, like, and that has to do with the color contrast. How big is the text?
Can I resize the text? Have I used a color alone for distinguishing two things from one another? So if I have, for example, if I had a list of foods and I wanted to say which ones I liked and which ones I didn’t, I can’t just put the ones I like in green and the ones I don’t in red, because if somebody can’t perceive green and red, they don’t have that information.
They can’t get that information. And also a screen reader isn’t going to read out what color text is presented in. So I have to have another way. Right. So I have to put it like maybe in parentheses at the end of each item, like, or dislike so that that data is available in another way. It’s okay to still use color, but you can’t use color by itself.
So that’s, that’s another success criteria. So like that one and text resizing and which other one did I just say? Oh, color contrast. Would all be gathered up into a, um, into a guideline called distinguishable. And then all of the guidelines get gathered up into another bigger bucket that are the principles.
We have four main principles in WCAG and they spell a word, so it’s very nice, POUR:
- Perceivable: Can people perceive this content with whatever capacity they have?
- Operable: Does it work? Can they actually open your dropdown menus, make different selections on your form fields, and so on?
- Understandable: Can we understand how this website works? That’s where accessibility overlaps with usability.
- Robust: Does it hold up? Does it work across new browsers, devices, and assistive tech combinations?
Natalie Garza: I remember I had a misconception that I thought each principle corresponded to a specific set of disabilities.
Natalie MacLees: Yeah, no, they all apply to everybody.
Natalie Garza: Yes.
Natalie MacLees: So it’s a mix of things. For example, perceivable isn’t just about people who are blind. It also applies to people who are deaf, colorblind, or have other disabilities that impact their ability to perceive content on a webpage.
If you don’t have hearing, you can’t hear the audio track of a video or any alert sounds in an application. You’ll need an alternative. Someone who is both deaf and blind should still be able to use your website by hooking up a refreshable braille display. Everything should be coded correctly so that they can still navigate the website and understand the content.
Similarly, someone with color blindness should be able to read and understand the website even if they can’t distinguish colors. All of this falls under the perceivable principle.
Natalie Garza: Let’s go over the success criteria in terms of how to meet them.
Natalie MacLees: The articles are not super user-friendly to understand. It takes some getting used to. The WAI website outlines every principle, guideline, and success criterion and tells you how to meet them.
They provide two types of techniques:
- Sufficient techniques: These are enough to meet the success criterion.
- Advisory techniques: These are best practices that aren’t required to pass but would improve accessibility.
The guidelines get very technical, diving into things like exact settings for CSS, HTML, or JavaScript. If you’re not a coder, it might be hard to understand them, so you’d need to hire someone you trust or learn it yourself.
Natalie Garza: Do you want to go over the failures too?
Natalie MacLees: Oh yeah. Each success criterion has failures, but they don’t cover every possible way something can fail. For example, a success criterion might list three possible failures, but there could be 10 more ways to fail it. Not all criteria even have failures listed. That lack of comprehensiveness can be frustrating.
Natalie Garza: Yes. Very frustrating. Alright, so to stack onto that, we have the different buckets to organize the WCAG success criteria. Each one has techniques, failures, sufficient techniques, and advisory techniques. Now let’s go over the next layer: levels of compliance.
Natalie MacLees: Yes, there are three levels of compliance in WCAG:
- A: This is the bare minimum you can do to even say you tried to make something accessible.
- AA: This is the standard. Most countries, states, and municipalities base their accessibility laws on WCAG AA. When people say “accessible website,” they typically mean WCAG AA compliance.
- AAA: This is the highest level of compliance, making the most accommodations for the widest range of people. It’s hard to achieve due to the number of rules and sometimes conflicting requirements.
Even the WAI themselves don’t recommend trying to meet 100% AAA compliance because of the development burden and cost.
Natalie Garza: I remember when I first learned about this, I thought AAA compliance was the hardest level to implement.
Natalie MacLees: That’s not true. Some level A rules are actually very challenging, and some AAA rules are pretty easy. The levels aren’t based on difficulty—they’re based on what users need to navigate the website.
Natalie Garza: Just for the audience, how many success criteria exist in the latest release of WCAG?
Natalie MacLees: Oh, I actually don’t know the answer to that. I think it’s around 60.
Natalie Garza: Okay, we’ll be right back.
Natalie MacLees: Oh, geez. I was way wrong. There are 87.
Natalie Garza: Okay, cut. We’re back. Let’s go over the success criteria really quick to give the audience a little understanding of how many there are.
Natalie MacLees: Alright. In WCAG 2.2, there are 78 total success criteria across all levels. Of those, 26 are AAA only, meaning you don’t need to implement them for AA compliance. The remaining 52 cover levels A and AA.
Natalie Garza: So if you need to meet AA compliance, you’d have to go through all 52 and ensure you’re meeting the rules.
Natalie MacLees: Yes, you have to implement at least one sufficient technique for each criterion for all relevant content on your website.
Natalie Garza: So there you go, you guys. That’s how WCAG is structured—many layers, like an onion. We hope that gave you a better understanding.
We’ve gotta move this along. So, who uses WCAG? Just a really quick overview.
Natalie MacLees: Anybody working in web accessibility uses WCAG. Designers and developers use it to build websites. Accessibility professionals use it to test or remediate websites. Lawmakers use it to define accessibility requirements in laws. Anyone who wants to implement or understand web accessibility starts with WCAG.
Natalie Garza: Perfect. Now, I know we told the audience you had something to share—something a lot of people misunderstand about WCAG. Do you want to go over it?
Natalie MacLees: Sure. People often think that if a website is 100% compliant with WCAG AA, it’s fully accessible. That’s not true. Even AAA compliance doesn’t guarantee 100% accessibility. There are always additional things you can do to make your website friendlier for users.
Natalie Garza: Mm-hmm. Until you have the actual users who really depend on it test it, right?
Natalie MacLees: Yes, you have to have real users test it. Can they get to everything? Can they use everything? Can they find and understand all your content, videos, and audio? That’s the real test.
Natalie Garza: Ha ha ha. Well, that pretty much wraps up everything. Where can we learn about WCAG? Where can we get more information?
Natalie MacLees: If you’re technically minded, you can check out the WCAG guidelines published by the WAI. A quick web search should bring them up.
For a more user-friendly approach, you can go to AAArdvark and scan your homepage for free. You’ll get helpful, user-friendly information about accessibility issues and how to fix them.
Natalie Garza: And you can filter all your scan results by WCAG success criteria. That’s a new feature, right?
Natalie MacLees: Yes, it is.
Natalie Garza: Thank you, Natalie, for going over everything we needed to know about WCAG. Maybe not everything, but a good chunk of it that’s kind of hard to find.
Like and subscribe to the AAArdvark Accessibility Podcast. We’ll see you guys next time for a new exciting podcast on another topic.
Natalie MacLees: What will it be? I don’t know.
Natalie Garza: Find out next time when we post again.
