Debugging accessibility with Chrome DevTools

Key Takeaways

[Music] 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 that 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 friend per 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 dev tools on my chromebook i use ctrl 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'll 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 arya toggle fields do not have accessible names okay 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 okay everything has to do with pictures of cats so arya is a set of attributes that allows web developers to add extra accessibility information beyond what's built in to html elements this site must be using aria okay 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 check boxes 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 first i'm going to close devtools 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 chromevox if you're on a chromebook you can turn it on with ctrl 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 friendpor with chromevox 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 chromevox focus friend complete what are shared 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 check boxes 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 a text it doesn't get read 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 the 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 chromevox 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 dev tools on my chromebook i use ctrl 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 friendpur 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 duchess picture and see if i can figure out how it works in the accessibility tree it shows up as a checkbox which is what chromebook said too that makes sense next of 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 computed properties those are the state the element has after all the different algorithms have been run looking in the accessibility panel we see that duchess has the aria labeled by attribute pointing to an element with the id of label1 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 1 has the role of label text that makes sense and it's highlighting the text duchess 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 click 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 duchess 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 oh look there's a span in there and 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 dawn 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 check box 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 to a dom in place so we can test them with chromevox i'll launch chromevox with ctrl alt z and use search right arrow to move to duchess chromebox spoke volume slider 75 chromebox spoken feedback is ready friend for friend for profile feed cirque sir prof chain 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 right arrow we'll also see that the text duchess underneath the picture is no longer separately focused while barely jose and maria's text is check box not check check box 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 because 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'd 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 dev tools 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 baton and easily switch between them thank you for joining us today you can find out more about the accessibility features in chrome dev tools 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 accessibility and you can follow us on twitter at googleaccess all one word thank you and enjoy the rest of i o [Music] you