 Hello. I'm Cynthia Shelley, Lead Program Manager for Accessibility on Chrome and Chrome OS. Today, I'm going to show you how to use the new full page accessibility tree in Chrome Dev Tools to debug accessibility in your web applications. To debug accessibility, you need to do two things. You need to find accessibility bugs and you need to fix them. There's a lot more of it goes into accessibility from design to coding standards to user testing. But right now, we're talking about one small piece of the process, how to find bugs, figure out what's causing them, and fix them. There are many automated tools to help you find accessibility bugs. Chrome Dev Tools includes an accessibility audit as part of Lighthouse. It's built right in, so you don't need to buy or download anything. It's optimized to reduce false positives, so there won't be a lot of noise in your results. And it provides links to developer docs that help you understand the error and some common approaches to fixing it. The screenshot here shows the results of a test, including controls that are missing accessible names, more on that later, and an image with no alternative or alt text to describe the image to users who can't see it. That's one of the most common accessibility bugs. It's important to note that automated accessibility checkers only find a subset of the issues on a page. It can give you a good idea of the accessibility state of a page. A poor score here indicates that the developer didn't follow best practices and likely has other bugs too. Fixing these issues doesn't mean that the page is ready to go, but it's a good place to start. You'll also need to test manually with screen readers and other assistive technology. Most automated tools don't test interaction like, what happens when I activate this button? Can my screen reader find the menu it opens? And they can't tell you if it makes sense. For example, a tool can tell you that the alt attribute is missing or empty. The screenshot in the last slide did just that. But it can't tell you if the words in that attribute describe the meaning of the image and its function in the page. Or if I tab through a page, it can't tell you if that order makes sense. Now we'll do a demo showing how Chrome DevTools makes it easier to find and fix accessibility bugs. First, we'll run a Lighthouse accessibility audit. Then we'll do some manual testing using ChromeVox, the screen reader built into Chrome OS, to explore a complex issue found by the tool. This is FriendPer, an example website we created with some known accessibility bugs. First, we'll run an accessibility audit with Lighthouse, which is built into the Chrome DevTools. So open up the Chrome DevTools. On my Chromebook, I use Control-Shift-I. On Mac, it's Option-Command-I, and on Windows, it's F12. I've got it all set up to run an accessibility report now. I click Generate Report, and it will take a few seconds to examine the web page for known accessibility errors. Then it shows the score for this site, 82, yellow. Not the worst, but not great either. And it shows the errors that it's found. It won't find everything, and we'll do some manual interactive testing in a minute. But it found quite a few things. Here's a classic accessibility error. Image elements do not have alt attributes. Missing alt text. These adorable baby goats don't have the text describing them to screen reader users, users who can't see the picture. This next one's a little more complex. But the tool still was able to tell us something is wrong here. It says, aria toggle fields do not have accessible names. OK, so what's an aria toggle field? Why does it need a name? And what does that have to do with pictures of cats? I mean, OK, everything has to do with pictures of cats. aria is a set of attributes that allows web developers to add extra accessibility information beyond what's built into HTML elements. This site must be using aria. OK, but why toggle field? Let's see if we can figure out what this thing is for. It says, share with, above the pictures. And above that is a text box that says, what are you meowing about? This is a social media site, and I think we're supposed to be able to select which of our kitty friends we want to meow at today. We can choose more than one. So functionally, it's a multiple selection control, or a set of checkboxes or toggle buttons. That's why toggle, so aria toggle field. And it's an interactive control. Interactive controls all need accessible names so that users with assistive technology, like screen readers, can tell what the control is for. So Lighthouse has found a problem, but why is it a problem? A little bit of manual testing can show us. So I'm going to try it with a screen reader. And first, I'm going to close dev tools so we get an experience similar to what end users have. I'm on a Chromebook, so I'm going to use our built-in screen reader, Chromebox. If you're on a Chromebook, you can turn it on with Control Alt Z. There are screen readers for all major operating systems. Check your system docs for info about how to enable yours. So let's look at those aria toggle fields. Chromebox Spoke Volume, slider, 75%. Chromebox Spoken Feedback is ready. Friend pour. With Chromebox, you use search plus arrow keys to navigate around the content, including content you can't reach with just the tab key. The orange box shows Chromebox focus. Friend pour. Complete what are, share, checkbox, checked. Press search plus space to toggle. Checkbox, not checked. Press search plus space to toggle. Checkbox, not checked. Press search plus space to toggle. Chromebox is reading them as checkbox. The first one is checked, and the other two are not checked. Checkbox is what's exposed to the user, letting them know that they can select multiple items. Checkboxes and toggles are functionally equivalent, but checkbox is more familiar to screen reader users. Okay, so that makes sense. But it's not saying a name for them. That's weird. The names are right below the pictures. Even if I move Chromebox cursor onto the text, it doesn't get right out loud. So this is clearly not the right behavior. A Chromebox user who can't see the screen will not be able to tell us which friends will get the message. That could be awkward on a social media site. That's a quick example of finding bugs with Lighthouse and with manual testing. Okay, so once you've found a bug, how do you figure out what the problem is and how do you fix it? Before we start debugging, let's talk for a minute about how web accessibility works. Chromebox gets its information from something called the accessibility tree. The accessibility tree is a tree of accessibility objects that represent the content of the web page. It's based on the DOM, but simplified to remove nodes with no semantic content. The buttons and headings are there, but spans and divs that are only for styling aren't there. This example is a simple form. The form element becomes the section in the accessibility tree. The H2 type of cat is the first heading. There are two radio buttons, tuxedo, like my cat, and tabby. Those names come from the label elements. There's another heading, name your cat, and that's the other H2, and a text box called cat's name, which comes from the input. These trees, the DOM and the accessibility tree, represent the same thing in a slightly different way. Understanding this makes debugging accessibility issues a lot easier. Okay, let's fix this bug. First, let's turn on the full page accessibility tree. Open DevTools. On my Chromebook, I use control shift I, and on Mac, it's command option I. On Windows, it's F12. Go to the accessibility pane in the elements panel and check enable full page accessibility tree. You'll need to reload DevTools. A blue button will appear at the top, and once you've done that, go to the elements panel. You'll find a new button to switch to accessibility tree view. You can toggle between accessibility tree view and the DOM tree view with this button. Now we'll figure out what caused those bugs we saw before and what we need to do to fix them. Okay, now we're ready to go back to friend purr and figure out what's causing this strange behavior. I've got my full page accessibility tree up, and I also have the accessibility panel up to show more detail. First, I'm going to select our Dutch's picture and see if I can figure out how it works. In the accessibility tree, it shows up as a checkbox, which is what Chromebox said too. That makes sense. Next to a checkbox role though, there's an empty string. Why doesn't it have a name? Let's look at the accessibility panel. Here we have aria attributes. Those are the attributes the developer added to the DOM and competed properties. Those are the state the element has after all the different algorithms have been run. Looking in the accessibility panel, we see that Dutchess has the aria labeled by attribute pointing to an element with the ID of label one. It shows up in the computed properties too. If the ID were invalid, it would be crossed out in the computed properties. This seems like it should work. That's weird. In the computed properties, we can click on the label ID and it will take us to that element. This is really useful for understanding how the elements are connected together. The accessibility tree has many secondary relationships that aren't always obvious when looking at the DOM. Label one has the role of label text. That makes sense. And it's highlighting the text Dutchess under her picture. The text is right there. We saw that the reference worked when we followed it in the dev tools. Why doesn't this work? I'll try to expand the label text. Nope, no children. Okay, now we need to go over to the DOM to see what's happening. The same button we clicked to switch to the accessibility tree will toggle us back to the DOM. One really nice thing is that it keeps our place when we switch back and forth. We're still on the Dutchess label. Only now we're looking at it in the DOM. Here, we can expand the label element and see what's inside of it. Look, there's a span in there. It has aria-hidden true on it. Remember earlier when we talked about how the accessibility tree doesn't include every DOM node? aria-hidden equals true explicitly tells Chrome to leave that node and all of its children out of the accessibility tree, even if they'd normally be there. It even says in the computed properties, accessibility node is not exposed. Element is aria-hidden. If we switch back to the accessibility tree for a second, while we have this selected, we'll see that there are now two nodes showing up under the label text that are grayed out and say ignored. Let's switch back to the DOM again and test our theory. We can double click on true and change it to false. False is the default for aria-hidden. So when you go to fix this bug for real, you may want to remove the attribute entirely. Both the tree and the panel are live. Changes in the DOM will be reflected here too. That's especially useful when debugging something that involves a lot of user interaction. So we can switch back to the accessibility tree and see if this worked. Okay, so there's a static text element with a string duchess inside the label text. That looks promising. And if we go up to our duchess profile picture checkbox, it has the word duchess under it. It's there too. And it shows up in the accessibility tree, checkbox duchess, focusable equals true. It's even in the computed properties, name duchess. So that seems like it's working. Let's try it with ChromeVox to see if it's really fixed. So first I'll close the dev tools to emulate typical user experience. Even with the panel closed, it keeps our edit of a DOM in place so we can test them with ChromeVox. I'll launch ChromeVox with control-alt-z and use search-write arrow to move to duchess. ChromeVox spoke volume, slider, 75%. ChromeVox spoken feedback is ready. Friend poor, friend poor, profile feed, search, search, prof, Jane complete, what are you, share with ellipsis, duchess, checkbox, checked. Press search plus space to toggle. It said the name, the fix worked. If I keep doing search-write arrow, we'll also see that the text duchess underneath the picture is no longer separately focused, while Barely Oz and Maria's text is. Checkbox, not check, checkbox, not checked. Press search plus space to toggle. That's because ChromeVox knows that the text is a label for the image checkbox and is smart enough to treat them as a single control. There are a few use cases for Aria Hidden, but it's also the cause of a lot of bugs, like this one. If you find yourself wanting to use it in your code, think about whether there's a different way to achieve your goals. Of course, editing the DOM only fixes the bug on my browser and only until I refresh the page. Now that we know what the problem is, we need to go into the source for the page and fix it there. And we should have some real users who use screen readers and other AT all day long try it out before we declare it really fixed. Debugging accessibility isn't much different than debugging anything else. You still have to find bugs and you still have to fix them. With the new full-page accessibility tree in Chrome DevTools, it's now a lot easier to track down accessibility bugs. You can see the accessibility tree for the whole page, how it relates to the DOM and easily switch between them. Thank you for joining us today. You can find out more about the accessibility features in Chrome DevTools, including the full-page accessibility tree and Lighthouse accessibility audits, on the Chrome Developers blog and on web.dev. You can learn more about accessibility at Google on the keyword blog and at google.com slash accessibility. And you can follow us on Twitter at Google access, all one word. Thank you and enjoy the rest of I.O.