 Hey, there, polycasters. Rob here. Welcome back to the show. So today we're going to be continuing our series on accessibility by talking about screen readers and making sure that the elements we create have the right semantics to be announced properly by those screen readers. Semantics is a pretty important concept in web development. But sometimes you've got to wonder, why is it important? And really, who does it benefit when I use good, semantically rich elements? And so I want to do a quick demo here using a screen reader so you understand the importance of this topic. So over in the browser, I've just got a native checkbox element. I'm going to start up the screen reader that comes built in on my computer. So if you're on a Mac, there's a built-in screen reader called VoiceOver, which you can turn on with command F5. If you're on Windows, you have to download a screen reader. There's a free one called NVDA, or there's another one called JAWS, which you can use. Or there's even a Chrome extension called Chromebox, which you can install. And that's actually a browser-run screen reader. But over here on my Mac, I'm going to use VoiceOver. I'll turn on the screen reader. VoiceOver on Chrome. JS bin window. And I'm going to navigate over to this checkbox. Unchecked checkbox. And you can see that when I do that, the checkbox was announced as a unchecked checkbox, right? Because it's a nice, semantic, rich element. I've used the correct input tag here. Now let's look at what happens when we try to do that with the custom element that we created in the last episode. So I'm going to turn on my screen reader and focus this item. VoiceOver on Chrome. Dash group. And you see that the screen reader just announced it as group. And that's because, as I mentioned before, when we create a custom element, we're basically extending the HTML language. We're creating something that has never existed before. And that means that it doesn't have any built-in semantics. To the browser, a custom element is really no different from a span or a div. So there's nothing that instructs it or instructs our users that it needs to be clicked upon. So how do we add the appropriate semantics to our element so that users who actually rely on screen readers can interact with them? There's a few ways that you could go about this. You could, of course, just go and start reading through a bunch of specifications. But if you want to get started right away, what I'd recommend is checking out that ARIA authoring practices guide that we looked at in the previous episode. So I'm going to go over there, and I'm going to look for the pattern that I'm building, which, in this case, is a checkbox. So we'll go to the ARIA authoring practices guide. We'll go over to the sidebar and look for a checkbox. And along with the keyboard interaction support that we need to add, you can also see that there's a section here on what it calls ARIA roles, states, and properties. So ARIA, if you've never heard of it before, stands for Accessible Rich Internet Applications. It's basically a set of attributes that you can apply to an element to kind of do surgery on the accessibility tree and actually add in additional semantics. So if we look at the guidance here on the authoring practices guide, it tells us that our checkbox needs to have a role of checkbox, that it needs to have an accessible label. And we'll actually cover this in the next episode. And that our checkbox, when checked, needs to have ARIA checked set to true. And when it's unchecked, it needs to have ARIA checked set to false. And there's a few other items in here about building mixed checkboxes and things like that. We're not going to cover any of that in this series. But for today, what we can do is we can make sure that we get the appropriate role and the appropriate checked states. So let's switch back over to our code editor. And if you recall in the last episode, I used this host attributes property in order to have my tag sort of self-apply a tabindex attribute. And we can use this same property to self-apply the appropriate role. So along with tabindex, we're going to ask this element to apply a role of checkbox. And if we actually switch back to Chrome and refresh the page, we can open our dev tools. We can verify that the element is now applying that role. So we see role equals checkbox. And let's use our screen reader and see what it announces now. Voice over on Chrome, unchecked checkbox. So you can see now that the screen reader is announcing that this is an unchecked checkbox. It's actually even inferring that it's unchecked because of the role that we've applied. In the world of ARIA, the role is kind of like the most important attribute. It is the thing that you absolutely want to make sure that you get right. There's a lot of ARIA attributes which don't even work if they are not paired with the appropriate role. So already we've done kind of the 80% thing. We've gotten the correct role, which is great. The next thing we've got to do is add those ARIA check states when we toggle our checkbox. So going back to our code editor, if you remember I have this checked property that we're toggling on and off whenever the user either clicks on the element or hits space bar. So what we can do is we're gonna add an observer to this property and I'll call my observer function checkChanged. And then I'll add a little bit of additional space down here. So you can see things. I'll define a checkChange function. And I'm just gonna paste that in here. So what we're saying is we're gonna call setAttribute. We're gonna set the aria checkedAttribute and we're gonna set it to whatever the value of this.checked is. And remember we're sort of toggling that value inside of our onTap handler that gets run when someone clicks on it with a mouse or hits space bar. Now calling setAttribute in this way is going to serialize the value of this.checked to a string, which is important. In ARIA whenever you set a true or false value you actually have to do it as an actual sort of literal string of true or false, which is kind of an interesting quirk of ARIA. So that part looks good. The last thing that I wanna do is sort of change how this thing is styled. Now if you remember in the last episode we had this host selector for the checked attribute and that's how we actually figured out when we wanted to apply our check mark. But something that can be nice to do is rather than rely on a class or some sort of random made up attribute that we've created in this case, we could actually rely on the state of the ARIA value. So I'm gonna say anytime ARIA checked is set to true that is when we should apply our check box. The cool thing here is we're now creating sort of a symbiotic relationship between our ARIA attribute and the actual visual state of the element. And we can use that to verify that ARIA is working appropriately. So let's go back to Chrome. We'll open up our dev tools. We can see that ARIA checked is starting out as false. I hit tab and select this element. We can see that that then toggles to true along with the checked attribute being applied. And we can see that the appropriate check mark style is showing up. And the last thing I wanna do is just try this out with my screen reader. So I'll uncheck the check box, turn on my screen reader. Voice over on Chrome, that unchecked check box. Initially it says it's an unchecked check box when we hit space bar. Checked check box. Now it updates the state to a check check box. So now we've created a nice accessible check box that works well for the keyboard. It works well for screen readers. The last thing that we need to do is add labeling, but I'm gonna save that for the next episode. Now, if you have any questions about what we covered today, please be sure to leave them down in the comments below. Or as always, you can hit me up on a social network of your choosing at hashtag askpalmer. Thank you so much for watching. I'll see you next time.