Josefine Schaefer 0:20 Hi everybody. Thank you so much for joining. For the next round, about 10 minutes, we’ll be talking about web accessibility testing and how you can do it directly in Chrome DevTools. My name is Josefine. I’m based in Hamburg, Germany, and I work as an accessibility engineer at Storyblok. I’m also a GDE for web tech, and this is kind of where it combined my passion for Chrome Dev Tools and accessibility testing. So since we just have 10 minutes, let’s dive right in. This is all about creating an accessible environment, right? And so because we have very little time and you’re watching this talk, I’m strongly assuming you’re already halfway convinced that accessibility testing is something that is very important, and basically our goal here should be to create as accessible experiences as possible for as many people as possible, right? Will we be 100% accessible for literally every single person, probably not, but we can work towards creating accessible environments. We can work towards lowering the threshold, creating equal or equal or opportunity, and making sure we can include as many people as possible with the product that we create. Why is this important? Well, first of all, accessibility, or access to information and communication technologies, is defined as a basic human right, as by the United Nations. And I feel like the conversation should stop there, right? We should all have equal access to anything possible. However, usually, when you’re talking to a manager, somebody you want to spend time or resources on, this is not enough, but it should be. It always helps to convince people, when you’re talking about all the many people they’re missing out on, or they could open up their services to, if they were accessible or this was included in the product. So it’s not only people with disabilities, it’s also literally anyone, right? So we’re all aging, we’re all getting older. There is also such thing as permanent like temporary and situational limitations, as opposed to permanent disabilities, right? So it could be, maybe you have an injury and your hand or your arm, maybe you are in a loud environment, you can turn up the volume, or maybe you have a cat in your hand and you can’t, you can’t use both hands, right? So there’s many different ways in which web accessibility can benefit you in all of these cases. And so beyond that, actually 15% of the global population experience some form of disability throughout their lifetime, right? And this is a very rough number. Of course, global data is so hard to come by, especially when it comes to something like this. So this is just a rough estimate by the World Health Organization, but this is a lot of also money that you’re missing out on if you have a product that is inaccessible, because these are all people that could potentially be using it, right? So these are just a few of the many reasons why it should be or you should care about web accessibility, and I have some resources linked in the end if you’re curious about anything else, and of course, I forgot to mention in the beginning, you can always reach out to me if you have any questions on Twitter, on LinkedIn, and I’m happy to try and support you there. All right, so we talked really briefly about why accessibility is important. Now let’s have a look at how we can test directly in the dev tools. So first of all, we could open up our our dev tools, and we have a lighthouse report that we could run there, right? You maybe have done it before for performance reasons or to figure out how your how your page is doing, and you can actually run the lighthouse report solely for accessibility purposes, right? And so it will give you an overview. This is working. Yeah, they will give you an overview of all the issues on your page. And then you can scroll down there with investigating the page of my employer, and we see we have a bunch of contrast ratio issues there. It’s also showing us all the audits that we passed and the items that we should manually be checking. And so there’s a whole overview of everything that was tested. And it can kind of give you some guidance on what has already been looked for automatically, and what could you investigate if you maybe. Like there’s a little bit more to go by. Just beware. You just saw that this page had a score of 97 which is great. However, good Lighthouse score is just the starting point right. So we want to make sure that we don’t use this as our sole endeavor, and testing, because a good score doesn’t mean that the page is fully accessible. It’s a good indication, sure, but you should always continue testing and make sure, because it’s an automated test that can miss some things, right? There’s a great article by Manuel matillovich linked in the end, also, which talks about how you could kind of hack your way to a perfect Lighthouse score. I do not recommend this, of course, but it’s good to know how it could work, right, just to see how not to do it and how this is very deceiving to have a good score. And then we could have a look at the accessibility pane so we can open this up by scrolling all the way to the right, depending on how you’ve got it signed, basically, and you can open up your accessibility pane. So this is like a whole section within the devtools that you can use for accessibility testing, and it has a bunch of different options in there to help you investigate for example, we can investigate ARIA attributes. So ARIA attributes are Accessible Rich Internet Applications. That’s what ARIA is short for, and ensures that screen readers have all the information that they need if you cannot get them with the native elements. For example, you can attach an aria attribute to kind of give some more context for assistive technology, for screen readers, etc. You can inspect those here. What kind of controls does it have? Is it selected? All of that will come up in your ARIA attributes. We can also use the accessibility pane to show the source order, so I can see in what order things would be displayed in my assistive technology. And here we see that we’re just going from top to bottom right, so the numbers indicate that the order. And sometimes you can also see that maybe an individual element is skipped in the tap order, in the source order, and maybe you’re not reaching them in the correct order. So this is super useful to visualize how you could how a screen reader, user, for example, or user of assistive technology, would perceive that we can also enable a full page accessibility tree, so that the subset of the DOM tree and it contains all the elements that are relevant or useful for displaying the page content to a screen reader, right? And it’s so there’s also a little toggle button here, with the little person standing there. Once you’ve enabled it, you can toggle between the two views, and then you will see it’s a little bit less information, less notes, because a lot of the stuff that we we do or we see in the DOM is also related to visual representation, right? And we don’t need that for the accessibility tree. So we see a bit of a reduced tree there, basically. And we can then inspect the individual elements. We see, for example, we have a link here with a text try for free. And so we see it’s also focusable. There’s also important information for a screen reader user or for web accessibility testing, and we can all use the accessibility tree for that. When we inspect individual elements, we can also see the color contrast ratio. This is the issue that goes wrong the most across all websites, basically. And we want an average of at least 4.5 for a double a standard. We can also see that here we got a little check mark, because here we’re passing the minimum requirement. And so this is really great to inspect to see the color contrast ratio, and just quickly on the go see if it’s sufficient. We can also get a full overview of all our colors in so if you go to more tools with the little three dots here, you can select More Tools, and then you can go to the CSS overview that is still in beta, but you can capture actually your entire page here. And what you will then get is an overview of the colors that you’re using, and you can see how you can, like, use them together also, and it gives you the color contrast issues. So we’ll say, like, Hey, okay, this text, this background. How does it work? Is it enough color contrast? Are we passing the different levels? And this is a really great overview to kind of see any issues that you may want to look into deeper on your page. And we can also show so go into like, showing the different rendering options actually. And we can scroll down a bit and you will see emulate vision deficiency in there. And like. Started with no emulation, but we can emulate different visual deficiencies, like, for example, blurred vision would look maybe something like this, and you can kind of see, are your outlines strong enough?

Will it be clear for somebody with a visual impairment, you could go ahead and reduce contrast to see your contrast requirements, how they are doing. We see the hours kind of disappearing in Google, and the outline is completely gone. And again, of course, this is great for people with visual impairments, but it’s also great if the sun is shining on your screen and you can or you need higher contrast, right? And then we can go through the different kinds of visual impairments to see here how that would look like. We can also reduce or simulate, prefers reduced motion to see, especially if you’re working with a lot of like animations or things that are moving around on your page, which is all fun and games. But we want to make sure that we have an option, or we enable people to deselect that if it makes them dizzy, gives them headaches or confuses them, should be an option to turn it off, and you can see what that would look like when you emulate the prefers reduced motion. And that was already it was a quick lightning round. Thank you so much for attending. As you see, there’s many ways to incorporate accessibility testing right there in Chrome with the dev tools. If you have any other ways of testing in Chrome, DevTools, let me know. I’m always curious to find out more, and I promised there was some resources in the end, so you can either scan this QR code or go to my link tree. Or, of course, if you have any questions or you’re curious to to chat, you can reach me on LinkedIn or on x. Thank you so much for joining.