Speaker 1: Hey, everybody, what's up? It's Rob Dodson. Welcome back to the A11ycasts show. So today, I thought it'd be fun to go through my process for doing a simple accessibility audit. A lot of times, I have teammates or even third-party partners who reach out and they say, hey, I've got this site that I've built. I'm not deeply familiar with accessibility, so can you give it just a once-over and let me know if there's any sort of major gotchas I should be looking out for? So I wanted to cover my process today. This is not an exhaustive review or anything, but this is generally the stuff that you can do to find some obvious high-level issues. So following over here to my laptop, usually, the first thing that I do on any website, and I'm going to use WebAIM as an example here. WebAIM is an awesome site for web accessibility. Usually, one of the first things I do on any website is I want to ensure that I can navigate using the Tab key on my keyboard and that there are discernible focus styles as I move around the page. So in the case of WebAIM, if I start tabbing through here, you'll actually see the first thing that it does, the very first time I hit Tab, I get this thing called a skip link up here in the top left-hand corner. Skip links are super useful on sites where you might have heavy navigation. You want to let the user skip immediately down to the main content. So WebAIM implements a skip link. Some other sites like GitHub have skip links. If you actually go to GitHub and hit Tab, you might notice it says, like, jump to your repositories or whatever. So skip link is kind of a cool thing to look out for. But then as I'm tabbing around the page, I want to make sure that I see a focus ring on different elements on the page. Now, WebAIM actually does a cool thing here where they animate their focus ring. So you can even see it moving across the screen, which is pretty cool. They highlight their focus states. This is just about the best tab focus behavior I think I've ever seen, really. But I just tab through the site, and I make sure that I can reach everything that is interactive using the Tab key on my keyboard. So that's step one, tab through your experience. So the other thing that I like to look out for is, as I'm tabbing around the page, I want to make sure that there's no off-screen content that can accidentally be focused. So follow me over here. I've got this Material Design Lite template site that the team has created. And notice that it has this sidebar over here. And as I'm tabbing, focus moves into that sidebar. Now, let's say I shrink the page a little bit. So it's totally possible that someone could have their browser this size on their desktop. And let's try and tab through this now. So I tab through this. My focus is over here on the top right in that search field. Now it's on that button. Now, as I'm pressing Tab, though, we don't see the focus indicator. It's as if it has disappeared. And we keep tabbing, we keep tabbing. And eventually, it's going to show back up. Did you see it down here at this Read More button? So what was going on there? Well, if we expand again, we can see that actually what was happening was focus was hidden in these offscreen fields. It was over here in our side nav. And so I see this on a lot of websites. And this can trip up anybody who's using a keyboard to navigate. And it can trip up mobile screen readers because you have something offscreen, but it's still in the tab water. It's still focusable. So a screen reader might travel into those offscreen elements. You might have dialogues offscreen. You might have side nav offscreen. And you don't actually want the user to be clicking on those during that current state. So that's another thing that I look out for. I want to make sure that people are disabling offscreen interactive content, making sure it's removed from the tab order. The next thing that I look for is I want to make sure that I can do a simple navigation of the page using a screen reader. So for this demo, I'm going to use the Shop app by the Polymer team. This is a pretty cool site that I worked with that team a lot to try and make sure that this was a good accessible experience. So in the previous few episodes, we covered how to use NVDA. We covered how to use VoiceOver on a Mac. I really recommend all web developers familiarize themselves with the basics of at least one screen reader just so they can quickly move through a page, kind of like what we were doing with the Tab key. And this is just sort of like a sanity check to make sure the screen reader can actually land on controls and they're announcing things that they should. So let me turn on VoiceOver. And I'll kind of move through this page quickly to show you what I mean by that. All right. So I'm just going to use the VO keys to kind of quickly move through some interactive stuff.

Speaker 2: Visited link, shop home, link, shopping cart, zero items, link, men's outerwear, link, ladies' outerwear, link, men's t-shirts.

Speaker 1: I might try and move down to the main section. I want to land on an image, right? And I want to make sure that that image has alt text. That's really important. A lot of websites, especially like e-commerce sites and things like that, you'll move through. And because they haven't provided alt text for any of the images, it'll oftentimes just read like the file name for an image. So that's another thing that I often look out for as I'm going through this phase. Did the person building the site use proper alt attributes? I also want to make sure that if there are custom controls, like buttons and things like that, that have been implemented using either custom elements or using like divs with a bunch of JavaScript, that those are interactive with the screen reader.

Speaker 2: COMPUTERIZED VOICE OVER MESSAGE MEN'S HEADING LEVEL 5 SIZE M SIZE COLLAPSED POP-UP BUTTON

Speaker 1: OK. So we're on this dropdown. It says Size Collapsed Pop-Up Button. Let's try and use VoiceOver to interact with this. So I'll click on it. OK. It's reading me the number of items. And now I want to use just like my regular arrow keys to move around inside of this control. So up, down, right, left, right, things like that. So go down to extra large, hit Enter. OK. That's something that I look for. Any custom control is working as I would expect with the keyboard. The other thing I know about this site is when I add something to the cart, it's going to sort of add like a little sort of modal pop-up type thing that'll show up on screen. And so I want to make sure that the screen reader user is notified of that, possibly by moving their focus into that item. So let's do that.

Speaker 2: SCREEN READER 1 S Menu Item. Stop Interact Quantity. Head up Fit List, Bullet, and Add This Item to Cart button. Press Item Added to the Cart. Added to cart. Four items interact with Added to Cart. View Cart. Check out Close Dialog. VoiceOver off.

Speaker 1: So you can see that when the item was added to the cart, the screen reader focus was directed into that thing that just slid out on screen. So I know the way the Polymer team is doing this, if I recall, is they've got something in there with a tab index of negative 1. And they're focusing that element just to direct our focus. So that's another thing that I watch out for, making sure if something is being dynamically added to the page, that focus is directed to it. So that's a quick pass that we can do with the screen reader. The next thing that I do is I try and check the page structure. So I want to make sure that the page is using appropriate headings and that there are appropriate landmark roles or landmark elements on the page, because those help with screen reader navigation as well. So let's look at something like Wikipedia, which does a really good job of this. So I'll turn on my screen reader.

Speaker 2: VoiceOver on Google, Wikipedia, HTML.

Speaker 1: And what I often do is I just open the rotor inside of VoiceOver. In NVDA, there's the, I think it's called the Web Elements thing. I think we showed it off in the last episode. But basically, it'll give you kind of an outline of the page. In VoiceOver, you can open it by using Control-Alt or Control Option-U.

Speaker 2: Landmarks menu. Tables menu.

Speaker 1: And just hitting left and right to move through.

Speaker 2: Form control headings menu.

Speaker 1: All right. So we can see all the headings on the page. We can see that they're doing a really good job of using H1, H2, H3, going all the way through the hierarchy of headings. They're not just mixing and matching H tags based on the size that they are, which I see a lot of developers do, which can generate kind of like a broken document outline for the screen reader. I want to make sure that when they're using heading tags, they're using it to basically build the skeleton of the page. So we can, heading level one, Google, move through this content in sort of a logical way.

Speaker 2: So if I wanted to jump down to this section,

Speaker 1: I can easily do so. The other thing that I look for, again, is landmark elements. So let's go back and look at WebAIM. So WebAIM does a really good job of using landmark elements on their site. So again, I open my WebRotor.

Speaker 2: Headings menu. Links menu. Window spot. Landmarks. No item. Landmarks menu.

Speaker 1: I look for landmarks. And here we can see that there's things like banner, navigation, search, main. So if I wanted to bypass all the navigation and get right to the main content, I can do that.

Speaker 2: Banner. Navigate. Search. Main. Link. Design. VoiceOver off.

Speaker 1: So that's another thing I look for. There are sites out there which really don't include many landmark elements at all. And again, that's sort of an efficiency feature that you can very easily add in. Use main tags. Use nav tags. Or use role attributes to create those landmarks. So users who use screen readers can just navigate around a lot faster fashion. So that covers focus. That covers basics of screen readers. That covers headings and landmarks. The next thing I check for is color and contrast. I want to make sure that someone who might have a low vision impairment is going to be able to discern the text on the page. So again, looking at a site like Material Design Lite, this is a really attractive website. But there are areas where I think some of the text could be a little low contrast and maybe a little difficult to read. So there's a really great Chrome extension that you can install. On the Chrome Web Store, we can look for axe extension. So axe, like a chopping axe, right? So this is by Deque Systems. And basically, this is a simple extension that you can add to Chrome which will sort of run an audit against the page and flag a number of accessibility issues. But one of those is color and contrast. So on this site, I can just open my DevTools after I've installed that audit. You can see it's right here in my DevTools panel. And there's this big Analyze button. So I click on that, and it goes through, it looks at the page, and it can tell me right here that there are some elements which need better contrast. So I click on that, and it'll actually give me kind of like a path to reach that element in CSS. I can actually even click on it, and it'll highlight that element in the DevTools for me. So in this case, for instance, this might be a little hard to see, but maybe I'll try and boost the page a bit. You can tell that these footer links down here, right? Where it says, right under this GitHub logo, these are low-contrast text that the audit has highlighted for me. So that's something that we can watch out for. There's another extension, the Chrome Accessibility DevTools extension. Here we go. So we'll include a link to this as well. It does very similar stuff to the Axe extension. But one of the nice things that this extension does is when you highlight something that is low contrast, it'll actually give you a color suggestion. So it could be like, maybe if you make the links this different hex value, you'll be able to meet the WCAG minimum. So let's see. If we actually highlight these guys right here, and in our DevTools, I'm going to go to where it says Accessibility Properties. And see right here, it lists this warning for contrast ratio, and I can actually click these color values. And it's very subtle, because this one's actually almost perfect, but it's not quite. Clicking these little swatches will actually change the text value on sites. And it'll apply an inline style for you, and that way you can see what a better alternative color would be. The last thing that I try to do after I've done all of this is I try to recommend that whoever is building this site integrate some accessibility regression testing into their build process. Again, if we go to GitHub and we look up Axe Core, so this is the library that powers that Axe extension. But you can also use this library as part of your build process, right? So as you're running your automated test, you can have a sample page. You can have Axe Core look at that page and flag any accessibility audits. And those could then cause your test to fail, at which point you know you've got to go back and you've got to fix those issues. So we covered a lot, but this is basically how I do my accessibility audits. It's by no means exhaustive, but on many of the websites out there, this is how you'll catch some of the major issues that folks need to work on that can take their experience totally broken to at least a decent baseline experience for folks. If you have any questions, as always, you can leave them for me down in the comments. Otherwise, you can contact me on a social network of your choosing. As always, thank you so much for watching. See ya. Hey, if you enjoyed this episode of A11ycast, you can always catch more over in our playlist. Or click the little Subscribe button and you'll get an email notification whenever we launch new stuff on the channel. As always, thanks for watching.