 Hey, everybody. What's up? It's Rob Dodson. Welcome back to the Alicast show. So today, I want to talk a little bit about the differences between states and properties in ARIA. So last episode, we kind of did an intro to ARIA. Today, I want to continue on with some of that stuff and talk about this idea of what differentiates a state from a property or an attribute. You'll see all of these things referred to in the various ARIA specs. So I want to help you understand when you're trying to build a custom control, what all those terms mean. So typically, what I do when I want to build any sort of widget is the first place I go is the ARIA Authoring Practices Guide. And I'll include a link to that down in the show notes. Basically, the ARIA Authoring Practices Guide, we've shown it off in a few of the previous episodes. I'll show it over here on my laptop. It's a really, really useful resource that lists over here on the left-hand side a bunch of UI widget patterns. And on the right-hand side, I'll have descriptions explaining all the sort of steps you need, the keyboard support, the ARIA states and rules that you need to have to support those elements. So for instance, if I go and I look at something like this radio group here, I can see that it's going to tell me what keyboard interaction we need to support. And if I scroll down a little bit, and here I'll zoom this up so it's maybe a bit easier to read, I scroll down to also show me the ARIA rules, states, and properties. So what does it mean when it says a state versus a property? In the world of ARIA, these two terms are oftentimes kind of like mentioned in the same sentence. But basically, you have an object. Objects have properties, something that describes kind of their essential nature. And then sometimes, you have properties that really define the state for that object. So to draw some differences here, for some elements, you might have ARIA multi-line. So this is a property that kind of describes the essential nature of an element. It could either be single line or multi-line. And properties are probably not going to change that often. And it's not true for all properties. Some properties like value properties and things like that, those might change kind of frequently. But most properties tend to be fairly static, whereas states are other kinds of properties that are expected to be a bit more dynamic. So for instance, if you're building a checkbox or something like that, you would expect ARIA checked to toggle between true and false pretty frequently. So how do you figure out then what states and properties and roles your element should support? Or really like the deeper definition for those, right? You can see them here in the ARIA all-thing practices guide. But what if you want to kind of dig under the surface a bit? Well, usually what I do is I start with the role. So in this case, if I'm looking at the radio group, it'll tell me that the radio group is going to have the role of radio group. And I can click on that. And that will actually take me over to the ARIA spec itself. And here I'll zoom out just a little bit so you can see some more. So the ARIA spec looks sometimes can be hard to tell these documents apart. It looks just like the ARIA all-thing practices guide because it has kind of that same all blue on white spec look that is so enjoyable to read. But the ARIA spec itself, very similar. But the one thing that I'm showing here now is kind of a deeper definition of the radio group role. Let's walk through this definition a little bit. This sort of table that you see here on the right is very, very common. You'll see it a lot in the ARIA spec. And it's helpful to understand how to interpret all of these things. So when we're looking at the radio group role, what it's telling us, first of all, is that this role inherits from some other kind of more abstract roles. So for instance, the radio group inherits from the select role. And you can actually click on this and you can kind of just walk these roles up the ladder to figure out who their parents are. So for instance, select inherits from composite and group. You can walk that up and you can see that group is inheriting from section and so on and so on. And as you're doing that, you can see the subclasses for those. And you can also see additional things like the kinds of properties that each of these roles contains. So let's go back to radio group and some of the other things we can see. Related concepts or related roles and things like that. So a list is sort of related to a radio group that are kind of similar. You can also see required elements that need to be within your elements. So for instance, in the case of a radio group, we are required to own radio children, right? And we can then go and explore that role. And then we can also get down here and we can see the supported states and properties. So again, remember, the states are gonna be kind of more dynamic and the properties will be sort of more essential to our actual nature. So in the case of the radio group, the two that it adds that are sort of unique are ARIA Read Only and ARIA Required, right? But it also has inherited states and properties and these are coming from those superclass roles or those parent roles. So things like ARIA Active Descendant, ARIA Busy, ARIA Controls, right? Those all come from those more abstract parents. And it means that, you know, when we're down here in this more focused child role, we can still take advantage of all of those, which is really cool. One of the things you may also often see in these tables, you're not seeing it here, but if we go and look at radio, you can see that there will also often be required states and properties. So in the case of a radio, the actual radio button itself, ARIA Checked is a required state. So you've got to have an ARIA Checked on all of your radio children. You need to be setting it to true or false. So let's look at some of these inherited states and properties then. So ARIA Active Descendant, okay? So what exactly is that? This is actually a really, really useful property. In a previous episode, we talked about tabindex and the roving tabindex technique. Maybe we can include a link to that up there or something. So roving tabindex we use to sort of manage focus inside of a complex component. ARIA Active Descendant essentially does a very similar thing. It allows us to tell the user, you know, which of our sort of children is currently focused or currently active, if you will. The primary difference is it doesn't require us to actually change the tabindex, actually move the focus throughout the composite control. Instead, we can leave focus on sort of the parent element and just dictate which child is currently the active descendant. In most cases, for instance, with like a screen reader like voiceover, it'll announce it the same either way. So it really comes down to which style you prefer for building your controls. So let's look at ARIA Active Descendant. I just kind of want to like show off how this works. So you can see that inherited properties and states work with these roles as well. So ARIA Active Descendant, as you can see here, very similar to tabindex. The primary difference is that it works by taking an ID reference to a child that should be sort of currently active. Let's go over here to this example that I've built. This is a little radio group that I've been working on. And let's see if I can kind of bump this up a little bit so you can make it easier to see. Hit the Enhance button. Okay, so we've got this dash radio group with a roll of radio group and this element, this outer element has a tabindex of zero. So focus will land on it. But what we're not going to do is actually focus the children. Instead, I've given each of these children an ID, so ID RB for radio button one, RB two, RB three. And what we're going to do is as focus is moving around or as we're sort of activating different children inside of this radio group, we'll use Active Descendant to tell the stream reader which one currently has focus, so to speak. Now keep in mind, we're not actually moving focus and you'll see this. You'll see that focus does not change. It always stays on that outer element. But for the stream reader's sake, it'll be announcing the different children as if they are focused. So the way we'll do this, here I'll turn on my stream reader so you can hear it. Voice over on Chrome 127.0, water selected radio. You heard the stream reader there. I've selected the first child, this water radio button. You can see that we have sort of this strange focus outline because of the way that I sort of styled the CSS for this element. I used like pseudo elements and things like that so our outline is just wrapping around the whole group. But what we didn't do, and if you can sort of see it over here in our markup, we did not change the tab index on any of the children. Instead, we added an ARIA Active Descendant attribute to the parent and we set it equal to the ID for that first child. And if I go and... Selected water radio. Soda selected rate coffee selected radio. Voice over off. As I'm hitting the up and down arrow keys, we're just updating the ARIA Active Descendant. So we're never using that roving tab index technique instead we just stick with ARIA Active Descendant. And again, it really comes down to stylistically which approach you want to use for your elements. Active Descendant's really good for things like autocomplete widgets where you need to keep focusing a text box so someone can keep typing. Well, you can also say, hey, here are some of the autocompletions down here below. Or you may just prefer to do all of your event delegation on some parent and not have to fiddle with every single child and set roles or set tab index on them either. So anyway, this is kind of just a brief overview of states and properties and I wanted to do this because I wanted to give you a better understanding of how to take an example in the ARIA Authoring Practices Guide and kind of walk it all the way through the ARIA spec to have a better deeper understanding of all of the sort of the properties that make up these really essential roles. So that about covers it for today. 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 there, thanks for watching this episode of AliCast. If you wanna catch more, we've got several over here in our playlist and if you wanna get notified whenever we launch new content, you can click the subscribe button which is probably appearing somewhere around here. As always, thanks for watching.