 Hey everybody, what's up? It's Rob Dutson. Welcome back to the Alicast Show. So today we're going to be talking about ARIA, what it is, and how you can use it to make non-accessible controls accessible. Now so far, I've sort of strongly encouraged using native elements whenever you can in your applications because they give you focus, and keyboard support, and built-in semantics, essentially for free. So for instance, I've got this input here wrapped in a label. And that's going to produce a visual UI, like the one that you're seeing here, this radio button. But that's also going to create a spoken UI based on the built-in semantics of those native HTML tags. Now if you're not quite sure how all of that happened or why those semantics matter, be sure to check out our previous episode on semantics. I'll include a link down in the show notes, and we can also maybe drop in an annotation up here for you to click on. It's good just to have some background on how semantics work and why those are important in the first place. Now this is all good and everything, but there are instances where a simple layout in native HTML just aren't going to cut it. And so to handle these situations, we have the Web Accessibility Initiative, Accessible Rich Internet Applications spec, which is a bit of a mouthful, so you oftentimes see this referred to as why aria, or maybe just aria. So aria works by allowing you to specify attributes on elements, which then modify the way those elements are translated into the accessibility tree. So let's take a look at a really basic example just to show how this works. So if you create a plain checkbox, a screen reader is going to announce it as a checkbox. It'll tell you it's label if it has one, like we do in this case, where it says receive promotional offers. And it'll also tell you the state of the checkbox, whether it's checked or not. But let's say you're in a situation where, for whatever reason, you need to implement your own checkbox using something like a div. Maybe you need to style it in a really special way. So in this case, we've got a div checkbox we've created here, and the screen reader is going to give the user really no indication that this element is meant to be a checkbox. It might announce the text inside of the div there, but it's not going to tell you the role of the elements. Not going to say it's a checkbox. And it's also not going to tell you the state. So a sighted user is going to be able to see these visual cues, and they'll be able to figure out that this is a checkbox. But nothing is going to be announced to our screen reader users, and that's a really big problem. So using aria, we can actually tell the screen reader about this extra information. Here up at the top, I've got some custom checkboxes just created using divs down at the bottom. I've got some checkboxes using the native input element. So using voiceover, let's see how these are announced differently. Voiceover on Chrome, custom checkboxes in custom checked TimTems group with three items. Mint slices group with two items. Heading TimTems, checked checkbox. Mint slices unchecked checkbox, voiceover off. So you see there that the div elements just are announced as groups. It doesn't indicate to the user in any way that these are checkboxes, whereas the native element, it indicates it's a checkbox, and it tells you the state, whether it's checked or not. So let's see if we can add some aria to improve upon this. So over in my dev tools, I will select these checkbox elements. And I'm going to start off by just giving them a roll of checkbox. And I'm also going to give them a state of aria checked of either true or false, depending on the actual state of the element there. So let's say roll checkbox for this other one. aria checked equals false. And let's try it again using the stream reader. Voiceover on drop in custom checkboxes, TimTems, checked checkbox, Mint slices, unchecked checkbox, voiceover off. So adding that roll and aria checked attribute causes the node in the accessibility tree to actually have the desired roll and state without changing anything else about the node's appearance or its behavior, which is pretty awesome. We're just adding in additional semantics using aria. So in terms of the accessibility tree, what aria does is it really allows you to sort of do like tree surgery. So you take the accessibility tree as generated by plain HTML. You add aria to that. And now you get a different accessibility tree. And it may be subtly different. Or it could be radically different depending on what attributes you use. However, keep in mind that this is really the only thing that aria changes. It doesn't change anything about how the element behaves on the page. So for instance, it's not going to suddenly make your element focusable. It's not going to add keyboard event listeners for you or anything like that. aria does not change behavior in any way. It really only is for adding in additional semantics. So if you're making a custom control, it's really on you to make sure you go back and you also add in that keyboard support. So you're kind of maintaining that consistent experience for your users. So now that you understand more about what aria is and kind of some of the basics of how it works, I want to cover some of the things that aria will let us do in our applications. As we saw in that checkbox example, aria can add semantics to an element where no native semantics already exists. So for instance, you take a div element. It has no built-in semantics. But we can use aria to give it a role. We can use aria to give it a check state, for instance. Build a custom checkbox or radio button or something like that. aria can also be used to modify existing element semantics. So for instance, let's say I've got a button element that I want to actually turn into more of a toggle button. So I can on, off, switch type of control. I can give it a role of switch. I can give it an aria check state of true or false. And now I've sort of modified the semantics of this control. And now it's more of an even more specific kind of thing. It's like a toggle button, right? It's a switch button. It's important to note here, though, that the switch role is part of the newer aria 1.1 spec. So as I'm recording this, there's probably a number of assistive technologies which do not support this role just yet. Just like all web standards, aria is constantly evolving and advancing to try and keep pace with new UI patterns. So that's something important to realize as well, right? If you come across an aria role, you also want to check for the support of that role in assistive technology to make sure it's widely supported and that you can use it. Another thing aria can do is it can express semantics and UI patterns, which really don't already exist in HTML. And I think this is where aria kind of comes into its own. aria basically will let you create accessible widgets, which are not possible using plain HTML. To give you an example, here is like a tree widget component, OK? And we can take an unordered list and add aria roles of tree, tree item, and group, and add an aria expanded attribute to a few of those children. And now we're expressing the more rich semantics of this tree element. And again, there's no tree tag in native HTML. So it's something that we wouldn't be able to build otherwise without aria, which is really important. Another thing we can do, and as we saw this in our previous episode on labeling, aria can add extra labeling and descriptive text to an element to give that element an accessible name. So for example, if you have an image-only button, which doesn't use an actual image element so you don't have access to an alt attribute or anything like that to put alternative text on it, you can still use aria, you can use aria-label, to give that element its own accessible name. And that way you can have it be announced properly by a stream reader to those users. Aria can also express semantic relationships between elements, which go beyond just like standard DOM parent child sibling relationships. So for example, a more complex relationship is something like this element controls that element over there, even if they're not like direct parent child or anything. So in this case right here, I've got a button, which controls whether a particular part of the page is visible or hidden. And it does this in the form of kind of a disclosure widget. You can see here where it says Advanced Settings. We've specified using aria controls, and it's actually controlling this group of elements down here for these Advanced Settings checkboxes. So even though they're not parent child, they're actually sort of like siblings. We can create this new relationship, indicating this element over here controls that element over there, which is really cool. And finally, aria can make parts of the page live, so they can inform assistive technology right away when something changes. And we saw this in our previous episode on building alerts. So we add roll equals alert to some element. We drop some new content into it, and then it's going to announce that immediately through assistive technology to the user. So aria gives you a lot of tools to make sure the experiences you build are semantically rich and can be easily understood by assistive technology. Now, we're definitely going to be diving into this topic more in the future, but that about covers it for today. So if you have any questions, you can always leave them for me down below in the comments, or you can hit me up on a social network of your choosing. As always, thank you so much for watching, and I'll see you next time. Hey, if you enjoyed this episode of AliCast, 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.