ARIA Attributes

Earlier in the course, ARIA and its capabilities were introduced. In this lesson, you'll expand upon that definition and look at the characteristics of ARIA attributes. You will examine why they are essential for accessibility, and explore a few attributes in their specific use cases. ARIA attributes can modify and element states and properties within the accessibility tree. More on states and properties in a minute, by the way. By doing this, these attributes provide additional information about the purpose and function of elements on a web page, allowing assistive technologies like screen readers to convey this information to users more accurately. HTML elements inherently have accessibility semantics built in. However, there are instances where certain components, such as autocomplete inputs and tabs, don't have native elements available. Even with a native element, custom styling may be needed to fit a company's design system requiring a custom build. These nuances highlight the importance of having tools to add the necessary semantics for accessibility when they are not present or when a custom component is required. That being said, with great power comes great responsibility, quote from Spider-Man if you remember, and the MDN documentation on ARIA states and properties has a great note on this topic that reads, ARIA only modifies accessibility tree, modifying how assistive technology presents the content to your users. ARIA does not change anything about an element's function or behavior. When not using semantic HTML elements for their intended purpose and default functionality, you must use JavaScript to manage behavior, focus and ARIA states. Long story short, this is just telling us that it is still our responsibility as developers to ensure that an element's promise behavior and functionality is delivered, and ARIA attributes are the tools you can leverage to keep this promise. So I wanted to dive deeper into some of the concepts I just mentioned. The first is that many HTML elements already have built in semantics. And if possible, it's best that you use native HTML elements. And one of the reasons is that if we look at the select element, for example, an element I'm sure you've seen a lot or used yourself, it comes with native semantics and functionality built in. And in this particular use case, let's say we were to focus on the select element by tapping into it, and then we press the down arrow, notice that the menu now opens up and presents us with a list of static options to choose from. And if we press the down arrow a couple of times and select an option, it selects the option that was highlighted and shows it in the input there. And if say we wanted to change the selection that we made, we press the down arrow again to open up the menu and then down arrow again, to select a different option, you kind of get press enter to select it, you get the process. But those keyboard functionalities are built in. We didn't have to do anything. They just came out of the box. And that's what native HTML element gives you. So when you, they are building a custom element and you need to make sure that if you're building something that needs to mimic the select element, that those functionalities are also included so that three meters and people using your element, your custom component, still get the same functionality. And that's how ARIA can be leveraged to kind of help you do that. So the next example that I will show is actually we'll go to the Google homepage where you've all seen this. And this search bar here is actually what would be categorized as an auto complete input. You know, you search, it makes a synchronous request, it presents you with results, that kind of thing. There's not a native HTML equivalent for this because the select element that we just saw is more for static options. But this we kind of want something to be a little bit more dynamic. So in here, let's go ahead. I'm going to search for ARIA and look that we get a couple results. And notice how the results are very, are kind of different. We have one that's just like a string of tags, one that has like a picture, you know, shows as ARIA on a grande, the name and then like a subtitle and all that. And so just this kind of different variations that you can kind of customize there. And then if you were to like hover over certain options, notice that now on the right hand side, we see a bigger picture of our underground day and then a description of her and then another picture and the name. So all these kinds of things, these are custom components that Google had to kind of engineers had to kind of incorporate. But you don't just want it to look like a component. You also want it to function like how it is if you were using a native component. And so if we were to actually go in and inspect this auto complete input, let's actually take a look and see what they're kind of doing under the hood. So if we go in and inspect the element, we'll actually see that ARIA attributes are being leveraged. See, it has a roll of combo box right now. There's an ARIA active descendant, ARIA auto complete, lots of ARIA attributes being used. This is a kind of a complex component to implement. So if we look here, the text area element is actually being used, but ARIA attributes are being applied to that element so that it represents the combo box roll. And so that the functionality works as one would expect if you were working with, say, like a native select or something like that. So just a real word example of how to kind of leverage ARIA attributes in the wild. So now we'll take a look at roles, states, and properties as promised. Together, they enhance ARIA's functionality and make it a powerful tool for web accessibility. First, we'll look at roles, which are core aspects of the ARIA system and represent a shorthand for defining a particular UI pattern. Roles achieve this by adding semantic meaning to the element that it's being applied to, which allows assistive technology to interpret the element in a way consistent with how the user expects a particular type of widget to work. Specific ARIA roles require corresponding ARIA states or properties, while some are only valid when combined with other roles. It should be noted that just adding a role does not make an element accessible. When a role is added to an element, the developer must ensure that they uphold the specifications that the role assumes and implement the pattern according to the ARIA authoring practices guide. So by default, many semantic elements have an implicit role assigned to them. For example, "Nav" has an implicit ARIA role of navigation. And if we look at, go back to the select element that we looked at earlier and scroll down to this technical summary section, which every element has, by the way, you can see that it has an implicit ARIA role defined here as "Cumble Box." And then there's some specifications about when it's a list box and "Adiata," but anyway, you can see that within the documentation, it outlines what is the implicit AR IA role. And to kind of kind of track this, let's look at a kind of more of a generic element like a span. And if you notice, there is no implicit ARIA role applied to it. So this is just kind of showing, comparing how specific some elements do have a role, signs them, and some don't. Now we'll take a look at states and properties, which are similar in that they both provide specific information about an element and are used to help define the roles of ARIA. While both are treated as ARIA pre-fixed markup attributes, they have subtle differences in their meaning. States typically consist of attributes that have a higher likelihood of frequent changes due to user interaction, while properties tend to include attributes that are less likely to change. While it is useful to know the difference between states and properties to understand the composition of attributes better, these differences are not significant enough to consistently distinguish between the two terms. Therefore, you will use the term attributes to refer to states and properties going forward. Okay, so to kind of provide some examples for this, let's look at the ARIA states and properties page on MDN. And on this page, there are periods of ARIA attributes. And you can see that they are categorized in different ways, and if you scroll down, there's just a ton of them. So we won't be able to cover all of them in this course, but this is just an example of all the ARIA attributes that you can leverage to help define the type of component you're trying to make. So let's take a look at one particular attribute, which is ARIA-checked. This is an example of state. This type of attribute may change regularly based on the rate of when a checkbox is checked. Unchecked. Obviously, there's a checkbox native HTML element. So if you can, please leverage that. But let's say for some reason you had to implement your own checkbox. If we look at an example here on the ARIA-optim practices guide and inspect the code, you will see that there is a role of checkbox and ARIA-checked is equal to false for that first item there in the list. And if we go ahead and check it, we'll see that ARIA-checked updates to true. And look at the second element, that's already true. If we go ahead and uncheck that, that comes false. So this is kind of an idea of an ARIA attribute that would be considered state. Like it's updated depending on, you know, the state of what's happening with that checkbox component. Now let's explore some ARIA attributes. The first ARIA attribute we 'll look at is ARIA-label, which provides a descriptive label for interactive elements that might not have any visible label text associated with them, or when you want to apply a label that differs from an element's default accessible name. A common use case for ARIA-label is to provide a label for an icon button that does not have any text associated with it. For example, a hamburger menu usually features an icon with three horizontal lines, indicating that clicking it will display a drop down menu. Since the icon doesn't include any text, an ARIA-label could be provided to the allow screen readers to announce the button's purpose. So let's take a look at an example here, and we're actually going to steal the example from the ARIA-label documentation right here. And if we go ahead and open up the play sandbox that MDN now provides, we can use an example taken here and look at what ARIA-label does. Let's copy the code here and let's go to the play environment and we'll paste it in and we see there's a little button with an X. And if we go in inspect, we will see that ARIA-label says close, because this is just an SVG, doesn't have any text associated with it. ARIA-label was applied and now the label of close has been applied. And if we go ahead and use your screen reader by pressing command F5, opening that up and click on the button, we'll see that the screen reader reads our close button. Without it, it would just read out button and something generic. And now that we've provided that ARIA-label person using system technology, you can have a little more context of what action the button will execute. The second attribute we look at is ARIA-labeled by, which is considered a relationship attribute as it creates a semantic relationship between elements on the page. It achieves this by associating an element with an accessible label by referencing the ID of another element that contains a label text. This attribute can be used to provide a label for an element that doesn't have one by default. When the user interacts with the element associated with the ARIA-labeled by attribute, the screen reader will announce the element's contents with the ID referenced by the attribute. ARIA-labeled by and ARIA-label both serve the purpose of providing an accessible label for interactive elements. However, it's important to note that ARIA-labeled by takes precedence over all the other labels for an element. Therefore, using both ARIA-label and ARIA-labeled by on the same element is unnecessary and potentially confusing. If I have a confusion, use one or the other, but not both. One way to distinguish between the two is that ARIA-label accepts a string of what will actually be read out as the label, while ARIA-labeled by accepts an ID or IDs that point to the element that contains the text that needs to be read. We'll take a look at an example here. We're actually going to scroll down and take an example that uses two IDs that we can see how that will get read out. We will copy the example here and then paste it over in our play environment. We'll notice that the ARIA-labeled by attribute references two IDs. One that's associated with the link, the ARIA- if we inspect that link and take a look at it in the accessibility dev tools, we'll see that the label is actually read more, "parachine ARIA-ouchy but you need to know." What it's doing is concatenating the text between the link and the header there to make a full phrase to describe that link. To see that in action with a screen reader, let's go ahead and open up voice over. With command F5 and we'll see that it reads the same label that we just saw in the dev tools there. Link, read more 13-RIA- which is read more, 13-RIA-ouchy but you need to know. So if let's say we didn't include ARIA-labeled by there, it would just say read more, which is a common thing that you'll see on the web. However, you could have, say you had a list of 10 articles, they would all say read more and there's not enough context to provide the technology of what they're actually clicking on. So by making it so that it says read more plus the heading, this provides more context so that if there are 10 links on the page, the person knows what they're navigating to. The third attribute we look at is ARIA-described by. This is also known as a relationship attribute and establishes semantic connections between elements on a web page. It links an element to an accessible description by referencing the ID of another element contained in the descriptive text. In contrast to ARIA-labeled by, this attribute can be used to provide supplementary information or contextual details for an element rather than solely a label. Okay, so let's take the example provided on the MDN page here and let's pivot back to our play environment like we have for other attributes and copy and paste that code over here. And notice we see a button now followed by some self-memory text and notice that the ARIA-described by attribute now points to the ID of the paragraph tag. And so if we inspect it and look at it in our accessibility dev tools, we will see that the description is items in the trash will be permanently removed after 30 days , which is the text that's contained in the paragraph tag. So some screen readers are kind of different with how they handle reading out descriptive text. But when it does read out that information, it would read out, move to trash, followed by, you know, that supplementary information to kind of provide a little more context. The last ARIA attribute we'll look at is ARIA -in-valid, which is used to indicate that user input for an element is incorrect. It is typically used on form elements such as input fields, select menus, and text areas. The value of ARIA-in-valid can be set to either true or false. One set to true indicates that the user input is invalid and the associated form element is invalid. One set to false indicates that the user input is valid. Additionally, the value of ARIA-in-valid can be set to grammar for grammatical errors and spelling for misspelled words. So we're going to go back to our play environment here, but this time we'll take an example from the manuscript. And so here we have a label for phone number, and we have the input, and the pattern is incorrect, I'm saying. We've marked it as ARIA-in- valid equals true. In a real-world experience, you would actually programmatically do this, not manually like I have it here, but just to prove the point, you know, say we have incorrect phone number entered. And I'm also going to add some CSS here by targeting ARIA-in-valid when it's equal to true. More on this in an upcoming lesson about CSS with ARIA attributes, by the way. So let's say we assign this maroon kind of reddish maroonish color. So now when ARIA-in-valid equals true, the text in that input is that color. So not only can you use ARIA-in-valid as a way to tell screen readers, as we can also use it for styling, and if we inspect the input element here and go to our accessibility dev tools, we'll see that the ARIA-in-valid attribute is marked as true. And if we open up our screen reader, again with the shortcut command F5, and focus in on that input, we'll see that it reads out, you know, 12345, insertion at end of text, phone number required invalid data. Again, it could kind of vary on your browser, I think, and you screen reader how this is read out, but it notifies the listener that, okay, this is invalid data, so that way they can make an action to improve it or whatever, but this is kind of how the ARIA-in-valid attribute can come into play when it's reading out the text or whatever content that it's referring to. ARIA attributes give developers a powerful tool to add more meaning and context to a web page, improving its accessibility. As you progress through this course, you will learn how to apply various accessibility methods, including utilizing ARIA attributes. In the upcoming module, you will explore additional accessibility techniques you can leverage using HTML, CSS, and JavaScript. [BLANK_AUDIO]