Check out a free preview of the full Enterprise Web App Accessibility (feat. React) course:
The "How to Test UI Components for Accessibility" Lesson is part of the full, Enterprise Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy discusses the steps for testing UI components for accessibility. They cover topics such as using the keyboard to navigate, understanding when to use interactive elements, running browser extensions like axe or Accessibility Insights, checking for color contrast issues, zooming in to test reflow, using screen readers like VoiceOver or NVDA, checking for animations and motion, and ensuring the presence of captions and transcripts for media. The instructor also emphasizes the importance of regularly testing and fixing accessibility issues.

Get Unlimited Access Now

Transcript from the "How to Test UI Components for Accessibility" Lesson

>> All right, so let's test some UI components. Here are the steps, since I made made you all wait, [LAUGH]. We saw how to use the keyboard to tab through a page, that's always the first thing that I do. And since we talked about click events and wrapper elements, I wanna call out the not everything has to be interactive for screen reader.

[00:00:20] That's kind of a common pitfall or misconception. I'll see people who are like, really, I just learned about accessibility. I'm gonna put tabindex on everything cuz they don't quite understand how screen readers work, screen readers have other ways to navigate. Tab key is not the only way, you can navigate by headings, you can navigate to the next list, the next table, and those don't have to have tabindex on them.

[00:00:46] It's only for things that are interactive. Things that like a mouse user and a keyboard user should be able to reach and operate. Can you see where you are? Do you have a focus outline? For compound widgets like date picker, tab switchers, some more like desktop style menus that have full aria roles.

[00:01:07] Those are use cases for the arrow keys. We wanna run a browser extension like Axe or Accessibility Insights. We'll run some in a second. And test the heading structure, tools I like are the Web Developer toolbar, and one I just learned about called the headings map. I need to add it to this, it's great.

[00:01:26] And you could debug elements, I usually go between Axe and the DevTools. We want to zoom in. So, I mean, it's straight up, just like Command Plus or Control Plus, minus zoom in to at least 200%. See that everything reflows into one column. That is a WCAG success criterion, it's called reflow.

[00:01:47] Make sure your components are not broken. You don't wanna have to horizontally scroll or have half of a component be off-screen. If I click here and my toast is invisible, what happens then? Yeah, sound like you knew all about reflow now, [LAUGH]. Further down the list, much further down the list, I have tests with a screen reader like VoiceOver or NVDA, that can be a bit advanced with a learning curve.

[00:02:14] But we have some cheat sheets that are very helpful for that more in our accessible naming and aria section. And then, check for that animation in motion autoplaying, it kind of jumps out at you once you know to look for, it's like whoa this is moving, I thought I had reduced motion on all the time.

[00:02:32] Go check, yap that's not responding, so you know that's an issue that is also multiple success criteria around that one. And then make note of any missing media for any video, audio with spoken word. We need captions and transcripts, so that our deaf colleagues and users and friends can participate cuz it's pretty exclusionary to not have the ability to follow along when you can't hear.

[00:02:58] So sometimes, it might have been missed in the content strategy or something, if you if you notice that speak up because it's better to speak up then just let that go and never get those assets. All right, so let's do some testing and our goal, where this is some manual steps, we wanna bake as much of this into the code as possible, and we'll discuss later on automation.

[00:03:21] But kind of our first thing that we can do is evaluate with this workflow. So let's go do some testing. I'll actually go back over to Stripe and do this. So we tested with the keyboard. Let's run axe DevTools, which is a free browser extension for Chrome and Firefox.

[00:03:42] There's kind of these paid parts for guided testing. They have evolved these tools over time, they're really great. But the free scan all of my page thing is so solid, it's what I call my daily driver tool. I use it every day, pretty much. So I ran the page as rendered.

[00:04:02] So it's not gonna test that open mega menu, it's not gonna test modals. They ignore stuff that's hidden on purpose cuz it's not in a state that's ready. So you wanna run it again with those states. But this returned color contrast issues, and I'm gonna go over here and see, so there's best practices are turned off.

[00:04:23] If I turn that on, they have a way more issues, but best practices are not legally binding. There are things that we wanna fix, but the violations are like, if you're focused on compliance, do the violations first. It also tells you what standard they're meeting or aiming to help you with and that's WCAG 2.1 AA.

[00:04:46] There's also in here, so we have best practices, there's no guided issues being returned, but Axe does have this concept of needs review. I used to work on this tool, that's why I know so much about it. And so, yeah, they might have changed the way that needs review works, but a good example historically was the text colors over gradients.

[00:05:09] They would just like, if there's a background image, it just goes straight into needs review. I think those might be under the guided issues now, which is it might be in a totally different part of this. But you're at least gonna get things that are actionable. I can hit Highlight to see where it is on the screen, so that's helpful.

[00:05:28] I can also go down here to this Inspect element button and hop over to the DevTools element inspector. And that often, for color contrast, I can go over here and click on this little color picker. And in many cases, not all, it will give me this contrast ratio picker, so I can actually drag around, so it's a blue color over white.

[00:05:50] So if I make it slightly darker, I guess it, did it meet? Was it like just barely not meeting too?
>> 4.5, and you're at 4.4.
>> It was 4.44 when the expected ratio for that font size is 4.5 to 1, that's so close. So for that one, I could probably drag it, fiddle it, change it slightly, and no one will know.

[00:06:17] [LAUGH] I could probably get away with that in this case. But sometimes it's too different to be able to do that. So you can go through these results and fix all of these, fix as many as you can. Run this as often as you can. You'll find all kinds of things that you missed and weren't aware of.

[00:06:36] So this is essential. There's also Accessibility Insights, the FastPass runs axe-core as well, so it'll be really similar. The Ad hoc tools are totally worth checking out, I can turn on headings and it will show me what the heading levels are. So the last one I'll show you is the Web Developer Extension under, say, blue by that.

[00:07:04] So Web Developer Information, View Document Outline, will give me this overall picture. Everything's in H1. Nothing's important when everything's important. So there's no hierarchy here. Yeah, the practice for headings is there should be 1, H1 and then everything kind of flows under that, sometimes It's really hard to not have headings before your H1.

[00:07:30] That's difficult and hard to avoid, but in general we wanna try and create a content hierarchy like an outline in Word or Google Docs when you tab and like have an indentation and icons and that's what we can do with our headings. So at least there's some flow to it, that makes sense.

[00:07:48] There's some H2s. Nearly everything here is an H1, so this tells me that they did not test their heading levels. It's just hard to tell what's the most important thing when everything's the same importance.
>> Surprise that got by the SEO people. [LAUGH] I feel like the SEO people wouldn't like that either, [LAUGH].

>> Yeah, I mean things get missed. So that's why we need this regular process somewhere along the way. So, we looked at zooming. We're gonna look at screen readers in the next section, we've even seen some motion and that could be targeted with CSS kind of depending on how that motion is done.

[00:08:29] If it's done with JavaScript, you can target it with JavaScript matchMedia, or you can use CSS media queries and turn motion off, and so, yeah, that's kind of my basic steps. If you did the keyboard part and the browser extensions and zoom in, you could fix a lot of stuff.

[00:08:47] I bet that list of 1100 issues would have been a fraction of that. If we just do this regularly, cuz there's so many easy wins that we could do and it feels so good to cross stuff off lists, I gotta tell you, like it's satisfying. When you have all those results and you hit re-run scan and you see it drop down, you're like, I gotta get those.

[00:09:07] If you can get your team fired up about that, you're gonna smash some accessibility bugs, and that feels good.
>> Yeah, we crossed off 40 or 50 at a time by just adding alt text to the search results and stuff like that.
>> Yeah, and sometimes that's in a template like your landmarks.

[00:09:25] You might have multiple failures for something that are tied to a single component. So you can watch that dramatically drop because you targeted it at the source, like a component that gets reused, if you can fix it there, then you can stand back and watch those results come down, those failures come down.

[00:09:44] Is there a question?
>> Is it okay to use H1s as headings within sections? I've seen it both ways, only one per page versus one per section.
>> Great question. So, there was a, for a while they're a movement, I don't know if it ever became a standard or anything, but to allow you to have more than 1,H1, where you could have excerpts and they're supposed to be more portable.

[00:10:12] Unfortunately, they were never really implemented for assistive technology. So, for accessibility purposes, we say only 1, H1. And you try to go in order, H1, H2, H3, H4. And then once you've met H4, you can kind of skip around, but I would say having headings at all, that's gonna be the most helpful.

[00:10:33] Having some sort of a structure, like all H1s that, I've heard both sides from screen reader users. Some people are really bothered by it and blocked by it. For other people, it's not as big of an issue, but I think headings are, they're pretty foundational in WCAG, like the info and relationships criterion.

[00:10:56] I think there's some others that really target this type of semantic structure. So, if you're looking for compliance, it is something you need to do. And the more than 1, H1 thing was just never really, that ship never sailed. So, yeah, unfortunately, we haven't been able to do that.

[00:11:15] But that's why I mentioned that approach with react and context, you might be able to use some tooling to help you pick the right heading level in a design system or, I don't know, a web application with some innovation or creativity.