 So I'm Joe Dalson. I'm here to talk to you about aria roles states and properties and that sounds so Amazingly sexy. I can see that you're enthused already The thing is it's actually an incredibly important and incredibly valuable and not nearly as hard as it sounds in most applications But it's really cool. What aria stands for is accessible rich internet applications. I'm going back to that sexy stuff What that means? It's a way of taking Dynamic interactions in the browser such as what you do with JavaScript and HTML and making them accessible Making that information available to assistive technology such as screen readers right now It is in fact only of any practical use in screen readers But the idea is that it's a semantic meta language that can be communicated to any assistive technology or in fact any technology at All one possible application is simply to make this information Something that's present in the browser for somebody to just look at The nature of aria is that it's a group of properties that you can attach to an HTML element to give it more meaning It uses a set of special HTML attributes that cover three basic concepts roles Which tell you what this element is and what function it's supposed to serve in this page Sometimes that's obvious. Sometimes it's more difficult States these are going to tell you how you are interacting with this element Properties give an element special characteristics and relate it to other documents And then you can use CSS and JavaScript to make these various items relate to each other for a richer experience Let's look at some actual examples What's a role a? Role is asking one key question. What am I? Sometimes That's an implicit thing Implicit roles are those that are attached to known elements parts of the HTML specification like it an H1 heading like a button like an input Explicit roles are ones you've you've specially defined for that element So this has an implicit role H1 what it has a role of Heading and then an attribute that defines its characteristic with aria level one That's great. You don't need any of that code because it's an H1 and it already knows what it is And all of the assistive technology knows this as well. But what if you want to create something like a tab panel? You're gonna mostly do that with divs and list items You've got a set of list items that connect your controls to your panels, but a tab panel doesn't exist in HTML Tab panel doesn't mean anything Using aria you can give it the role of tab panel This is going to specifically apply to the panel, which is where your content is displayed It's separate from the content which is actually triggering that But this means that when a user with assistive technology such as a screen reader arrives at this tool They understand what it is and how they can be expected to interact with it Now telling that user. It's a tab panel doesn't automatically make it work with tabs Those are going to be dependent on your JavaScript and your CSS but For a user who can't see this very obvious layout It's a great tool to be told by their screen reader. Oh This is a tabbed interface Great now. I know how to orient myself in this content So when you're using roles You need to be really careful about how you use them When I mentioned that tab panel concept the reason you add the role is because tab panel doesn't exist in HTML But if you have an element that does exist in HTML You don't ever need to specify the role it might be redundant and these are all examples that I've seen in real life You might have an h1 with a role of heading and aria level equals one. Well, that's just pointless You've added a bunch of extra craft into your HTML. You've made it harder to read harder to understand and You've added nothing You might be trying to replace an element with another one You might be using a paragraph, but you're calling it a heading and you're giving it level one Well, why did you do that? You've got an h1 We do maybe you're modifying it you've suddenly decided to take this h1, but let's claim for assistive technology that it's a level two You've got an h2 you could do that that seems like a much more logical approach to me But nonetheless I see this all the time Because people have absorbed the concept of aria as something that improves accessibility and that is only partially true What aria does is it enhances semantics? So it gives more meaning to content However, if you give it meaning that's a lie or is irrelevant or is substituting the original meaning What you're actually creating is confusion It makes yourselves and amongst everybody who looks at your car your your code and everybody who uses your site So don't do that. If you've got it use it. There are a lot of great semantic elements in HTML Some of them when they're relatively new you look at an element such as the nav element or the main element They're new not all browsers not all assistive technologies are Communicating communicating that information from the browser to the assistive technology Maybe you want to put role equals main on your main element That's an edge case. You're touching on a small number of Software interactions that may or may not come up But it is valid because main is a relatively new element if you're working with an h1 that is not a new element now sometimes People trying to do things with Interactions and roles because there's these roles like checkbox and you know Maybe you what you want is to create a really fancy checkbox that has three states instead of just two well You can do that you can put role equals checkbox on your div What you've done is created a div that claims it's a checkbox It doesn't act like a checkbox for assistive technology It doesn't respond to the keyboard It might look like a checkbox because you've designed it and styled it that way, but it doesn't work that way so While you can do this you're going to want to almost always avoid it If you do this you have to write a lot of extra JavaScript to handle the native keyboard Interactions that a checkbox already has So let's talk about states State is all about what am I doing right now if you look at a button you see this all the time when word press It's a button that controls a menu toggle you use it to open and close a menu perhaps in a responsive mode Now what this doesn't tell you is whether or not That menu is open You've just got a menu a button. It says that it toggles the menu You don't know whether you need to activate this or not, but aria includes state information So if you add the attribute aria expanded equals true Obviously you add that when it's true Then somebody arriving at this toggle immediately knows whether or not the menu is available to them right now That can be a major issue Especially when the content is not organized in a linear fashion Some sites you might see that the button is immediately before the menu So, you know, it's not too critical. You just tab forward you discover you don't have the menu So, you know, oh, well, I better open that But what if it's not What if the menu has actually been located in the footer of the site and they just bring it into view when you click the toggle? Well It's gonna be really hard to discover whether or not that's available If you want to style that you want to act on that What I usually see people doing is adding a class and that class says something like dot open Well, you don't really need to do that You can actually take advantage of these aria attributes and toggle your styles based on them And you don't actually even need to be able to find What item you're going to work with because you can Use additional attributes to grab that in the JavaScript and this is where we get to properties Who am I related to and what do you need to know about me? So we've got that button Now we're gonna tell you what it controls So this takes the ID of the target So now this button knows not only that it's open But exactly what it is opening and you can grab that in your JavaScript and use that directly You have no need to try and add additional data attributes or manipulate that information in another way You can go even farther and decide this aria this button needs more information I'm only gonna display menu because that's all I want most people to see and for sighted users That's generally going to be enough But for non sighted users, maybe you want that to give more information So it says close main navigation menu when it's open and maybe it just says open when it's not This is an option you have very readily available to you an aria label Substitutes the text of that button so that it will be read something else to assistive technology This should be used with caution So what do you need to know about me has some very interesting attributes? Aria label is one. I just talked about aria live is highly valuable Our alive is critical to any kind of dynamic content is what aria live tells a screen reader Is that this is an area of the page that might change the way a screen reader works? Is it loads in the entire DOM and? Allows somebody to navigate it, but if the dog if the DOM changes as the result of a JavaScript request It doesn't need it doesn't know that However, if you wrap a region in an aria live attribute with either a value of polite or assertive Then it knows this is a region. It should monitor for changes and it will in an announce that something has changed This is absolutely critical to any JavaScript driven dynamic content without it what a screen reader gets is silence resounding silence Whom I related to its controls it could be a description could be labeled by owns in summary If you can use a native element use the native element If you're creating some kind of non-native HTML control You're gonna have to add your own keyboard hand or handlers. So be prepared for that If you have a current state you can make that explicit and do that You need to make relationships between what you have and what it controls explicit You need to make sure every control has a clear name. Thank you very much