Episode 009: WCAG Success Criteria You May Not Be Meeting

You've likely heard about color contrast, but there's a lot more to accessibility than that. Claire and Steph will also review the upcoming update to the color contrast model, content reflow, touch/target size, and visible focus.

Check out the Episode 009 Notes: Common Accessibility/WCAG Failures

Transcript#

Claire:

Hi.

Steph:

Hey,

Claire:

I'm Claire

Steph:

and I'm Steph.

Claire:

And this is Word Wrap.

In this episode of Word Wrap we're going to talk about part two of our accessibility mini series. And this part is going to talk about the web content accessibility guidelines or WCAG success criteria that you may not be meeting.

First, let's talk about a little bit of definition. The WCAG or web content accessibility guidelines have been developed by individuals and organizations around the world with a goal of providing a single shared standard of, for web content accessibility that meets the needs of individuals, organizations, and governments internationally. The WCAG documents explain how to make web content more accessible to people with disabilities.

So what does that mean? That means these are broadly applicable to current and future web technologies in order to help developers create experiences that are accessible. These are merely guidance principles. And then the success criteria are specific examples that you should be meeting in order to actually meet the guidelines.

Just because you meet an accessibility guideline does not mean you get to skip user testing.

Criteria are backwards compatible, meaning that if you are talking about what WCAG 2.2, you also meet WCAG 2, which is important because some countries have legislation based upon a particular WCAG level. So in this episode, we're going to talk about specific success criteria, and kind of how that relates to web development in general.

First off is color contrast. Briefly mentioned this in an episode, actually episode five, if you want to look for it. And we mentioned that the algorithm to calculate that is actually under review and it actually still is under review. The new formula is actually called advanced perceptual contrast algorithm which is more context dependent. So it is currently available in Edge and Chrome as of version 89. And we'll put some release notes into the show notes to talk about, uh, what that really kind of means.

Steph

So what is the difference between the new and the old version? Well, specifically when it talks about being context dependent, that means that instead of kind of this sort of binary that we had with the current calculation where you either pass or don't based on a unified algorithm that strictly looked at the foreground color versus the background color. Where it cared about font, weight, and size, but didn't care about the perceived contrast. And that's the biggest difference. So when I've talked about contrast before I've been personally criticized, even though I was citing the current guidelines, because folks like to bring up white text on orange or white text on blue. And perceptually yes, it could be argued those meet an acceptable level of contrast, but those will fail often for the current algorithm.

But now with the new APCA some of those will actually pass. And that's because we're looking at perceived contrast. So this means comparing the not just text, font weight, and size, but also what is the overall context that that's being viewed at? And it takes into account ambient light, your surroundings and the intended purpose of that text or that UI element.

So, um, sometimes gray text on black will be difficult to read. But the same exact values in reverse, maybe easier to read. And that's, you know, it's still going to continue to be dependent per person there. But it's going to better account for some of those combinations based on their perceived contrast, rather than strictly their calculated algorithmic contrast, according to the current formula.

Now these are, as we mentioned in Chrome and Edge as of version 89, that means means that there are dev tools, color pickers are updated to reflect those. They are not officially in WCAG spec, but they are likely to be in WCAG version 3 which is still a couple years out from being finalized. So keep that in mind, it's something to aim for, but in terms of compliance, you'll still want to meet the current color contrast guidelines.

Claire

To give a personal anecdote to the color contrast, and just the kind of perception that we talk about here. Um, I actually just got a debit card recently, um, that is bright orange. With white text on it. Now the white text is the actual like card number and like my name and stuff like that. And you can see it okay in bright light settings. But anything like less than sunlight, it's pretty hard to read it. And granted, this is a physical card, not something that's on a screen. But this goes beyond just the web, and this is something that, you know, you will be able to see more and more, once you start thinking about it. You know, I invite you to look at like graphics on television. They're terrible, absolutely terrible. So color contrast is all around us and it, and you know, many different variations and stuff.

And this is just trying to get a little bit closer to a like calculated value of what we see in our world in general.

So another success criteria is content reflow, which is basically checking sites, uh, with issues with the zoom. Not the video conferencing app. Um, but zooming on your browser and checking to make sure that things, uh, fit appropriately.

So talking about like things overlapping each other elements, kind of just getting out of place. This kind of sounds like something that might just be, you know, something that just comes about like good design and good responsive design, but it also has an accessibility implication too. Because let's say you have a big monitor. Let's say that the it's a, it's a full HD monitor, but you have the zoom up to 200%. You're basically looking at the size of viewport size of an iPad at that point and things need to reflow properly. So it might not even just be an accessibility thing. It's more just like good checking of responsive design and stuff.

Steph

Yeah, so the reflow here also, um, 200 is definitely a checkpoint. Um, the 1.4.10 is the specific success criteria for this one. And it's going to note 400% because at 400% zoom on a viewport that has a width of 1,280 pixels, you are going to encounter a similar viewport resolution as is triggered for a device with 320 CSS pixels.

Important to note here is that we're talking about desktop zoom. So your typical checking that you might be doing for responsive design is going to be at a different aspect ratio than is triggered when you have a desktop viewport at 400%, because now you're talking about a wide viewport with a short height.

And so for example, items that can go very wrong in this aspect ratio are, if you are using sticky navigation. That sticky navigation may now be taking up to a half of the viewport height. Um, and this is tricky because we have no - currently have no zoom media query available. So, you know, you could argue that maybe you should drop sticky navigation entirely. Um, and that's a difficult choice to make because maybe there is a very valid reason that you have that when your intention is that that be used for mobile users. So it's something to keep in mind.

Um, modern CSS gives us a few different ways to handle, to try to handle this. We can listen more to viewport units and viewport height for example. We can use some calculation functions like min and max to set min and max values rather than using hard pixel values and have those based on viewport units instead. There are several ways to attack this. And it's something that I certainly didn't know about at all until about a year ago. So it's one I'm kind of become passionate about sharing about, because it can be so incredibly critical for users that require this zoom level, but it's a different way to think about how you're doing your responsive testing because of that changed aspect ratio.

Claire

The next success criteria is touch or pointer target size, which if you're keeping track at home is 2.5.5. And this basically says interactive elements need to be 44 by 44 pixels. We usually think about this as just mobile, but WCAG 2.2 also adds this for pointer target sizing as well.

Steph

Yeah. So what does this look like in a practical scenario? So top of the list would be site navigation. So as you have a series of links, you know, most of the time you're going to probably meet this in width, but you may not meet it in height.

Now that was partly why the pointer target spacing was added because while your text link may not have the height of 44 pixels for your navigation, um, you can still allow that by using spacing properties. So you can essentially increase the target size, um, even if it's not the computed size of specifically that link.

And that also has to do with making sure that, for example, if you're using icon buttons, you know, maybe the physical or the, the visual representation of the icon might not be 44 pixels, but making sure that it has a target area that at least meets 44 pixels. Or a clearance space around it that allows it a 44 pixel space.

Now you may be thinking that, wait, I know that device density, pixel density is different and that's right. That's why 44 pixels was chosen as a estimate. There are often scenarios where you would want to explicitly make those touch targets larger as we kind of already listed. So it is definitely a minimum criteria, um, but one that can be missed easily.

If you are a kind of, maybe you have a series of action buttons, you know, so being mindful that your 24 pixel icons with six pixels in between spacing may look nice, but you're not going to meet that criteria. And again, this is for both touch and pointers, so where pointer, maybe a mouse pointer, but it also might be a stylus.

You know, thinking again, there's multiple ways that users are going to interact with your interface. And so typically if you want them to perform an action, you should make that as easy as possible for them. So that's really what this criteria is about.

Claire

Yeah. And we've all been on websites that are terrible to use on mobile. So think about that as the empathy part.

So the next item, I think the last item we're going to talk about today in this episode is visible focus, which let's be honest. If you get anything from this episode, think about visible focus. Remember to tab through your current project and fix any place that you lose, visible focus or, you know, to get focus trapped within other elements.

General rule of thumb: don't remove outlines on focus without providing an alternative style. So what that means is outline: zero. Don't do it. Don't do it unless you're going to add something else to replace it. If you allow the browsers focus state ensure it isn't cut off. So like, you know, we've all seen those focus states where it's like kind of jagged edges and stuff like that. Yeah, you can probably fix that with padding and you know, different calculations and stuff, but, um, it needs to be visible against the background and or the imagery behind it. So if you have like a header image and you've got buttons above it, like let's say a menu or something above it. You need to be able to see that box or that, that focus state above that. And clearly. It needs to hit that, that contrast ratio that we talked about, um, uh, previously.

Steph

So the current focus guidelines kind of gave an either or scenario where you could add a border or change the color contrast. And oftentimes a pitfall is focusing too much on one or the other.

Well, WCAG 2.2, which is in draft, um, but nearing being finalized and published - is updating those visible focus guidelines. So a critical thing about this is that you must meet all of the criteria for not just contrast, but also a minimum indicator. So. This can get a little confusing. We'll definitely drop this in the show notes, but one of the things that stood out to me is that there is a focus indication area that's greater or equal to one CSS pixel border or has a thickness of at least eight CSS pixels along the shortest side. So in other words, you know, the writers of these success criteria are aware that there is a lot of ways to visually present content. And so they're trying to give you a little bit of an option here on how to treat this focus state.

So if you're using the native browser outline, you're going to get this for free because it's going to place a outline around the entire element. So in other words, a border. That is at least one pixel, most you'll see are two. And you'll also see in some browsers are starting to use kind of a double outline where they have a lighter border and a darker border, so that it helps to attempt to guarantee contrast no matter what that element is over.

So again, you get that for free, but if you're going to do it yourself, you need to have at least a one pixel border or an eight pixel border on at least one side. And in addition to that, you also need to do the contrast. So this needs to be at least a 3:1 contrast with the unfocused state. And depending on the interactive control that you're working with, this can mean different things. So for a text link, you know, you're going to have at least 3:1 contrast with just the text color that you're concerned about. If you're worried about buttons, then you're also going to be updating the button focus background. It has to have a 3:1 with its default background. And both of those backgrounds have to have a 3:1 with whatever the buttons placed against.

So you have all these vectors of contrast that you are required to meet. And so there's few different ways to do that. Maybe background color is not the choice. Maybe you're adding a border in addition. So, you know, some of these may require a little bit of a flex in the way that you normally think about applying focus.

So that's why it's always good to have kind of WCAG handy. I mean, all of this is searchable. A criticism sometimes that is not the most readable and that's something they're, they're working on with the newer uh WCAG 3 guidelines, but some of these things like focus state, contrast, keyboard accessibility, there's a lot of reading material about that. And it's the type of things that impact every application, regardless of - every website - regardless of what the content is, who your users are and what they're trying to do there.

A really great reference that I frequent multiple times a week, um, is called the WAI-ARIA authoring practices. And again, we'll drop this link in our show notes and the transcript. But this actually gives you demos that meet WCAG criteria for common scenarios. So in the previous episode, we've talked about dropdown menus, for example. So you can actually get the semantic HTML, learn about what ARIA roles are necessary. Learn about what JavaScript and actually get the JavaScript that you need to ensure keyword accessibility. So that's definitely worth bookmarking because as you research things, you're going to find different opinions. And a lot of times those will have to do with maybe the visual presentation, or maybe they'll talk to you about actually implementing that in a specific framework.

But the authoring practices help guide you to ensure that whatever solution you choose, that's the core minimum requirements that you need in order to have the best chance of making an accessible solution.

Now there are a lot of success criteria and we only hit a few of them today. Um, the goal for today was to hit some that maybe you hadn't otherwise encountered and, you know, beyond color contrast. And of course the main point of that one was letting you know about the updated algorithm that's coming. So between this episode and the previous one, we definitely hope you have a lot of takeaways to help you improve the accessibility of your projects.

Claire

Yeah. And again, be sure to ask any questions that you have. Uh, tweet us @WordWrapShow, um, and we'll try and help you if we can, or we'll talk about it in a different podcast episode and yeah, maybe there'll be a part three. Maybe there won't who knows. We'll see, see you next time.

Steph

Thanks for joining us on another episode of Word Wrap. Be sure to subscribe on your favorite platform, or pick up the RSS feed on wordwrap.dev. You can also catch us as @wordwrapshow on Twitter. Until next time!

Review the Episode 009 Notes: Common Accessibility/WCAG Failures