Check out a free preview of the full Website Accessibility, v2 course

The "ARIA" Lesson is part of the full, Website Accessibility, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jon discusses different aria labels, roles, states, properties, CSS selectors, and how they can be used to provide more information to a screen reader. ARIA is a set of attributes that define ways to make web content and web applications more accessible to people with disabilities. Student questions regarding what happens when there are multiple aria-label or aria-describeby labels and when to use aria-autocomplete are also covered in this segment.


Transcript from the "ARIA" Lesson

>> Let's move into ARIA. So I linked here to the official ARIA documentation on MDN. So it stands for Accessible Rich Internet Applications. Again, I think one thing, I just love about accessibility and I always hesitate using this word, but it feels easy in some ways, where you get to learn this cool stuff.

And oftentimes, it's just adding attributes to HTML. It just feels very doable to me, like I feel like sometimes you learn a performance technique or a caching strategy. And you get all excited, and then you're like, okay, but how do I apply this to my application, right? Like things get complicated very quickly.

A lot of this stuff is really cool because I mean really a lot of the time, it is just going into your HTML or going into your JSX or whatever, and just adding some of these attributes. And then boom, you see this massive difference in how people interact with your site.

So this is the ARIA page, I would recommend kind of getting started with. We've already talked about some of these things, right? We've seen ARIA label, and we've seen role which are both part of ARIA, but there's a lot more to it. So let's cover that a little bit.

For those that like spec reading, there's also the W3 spec with ARIA. So all of these things are well-supported on browsers. All these things have official W3 support. You can kind of go through here and see all these different properties we were just talking about has pop up or hide something, keyboard shortcuts.

Like we've seen label, we'll get into a lot of these other ones pretty soon, expanded, all these different great things. So the spec is pretty cool, although when you click into them, it's very deep. So I know I don't often like mess around with that too much, but it's really cool to see.

So one thing I wanna talk about is labels. So we covered the label tag in HTML, and it's great. But we also covered the shortcoming, which is that it only works with labelable elements. And, so ARIA provides us with three different tools that we can use, all the two of them do the same thing.

For all this added context and this ties in great with the question about, should you add labels to links and things like that? So we have ARIA labeled by and ARIA described by, ARIA label and ARIA labeled by do the same exact thing. They add a label to something.

The difference is that the label is in line, right? So if I hop back over to the code ARIA label works like this. So you find the element that you want. You give it an ARIA label of anything that you want. The way that ARIA labelled by works, it's kind of like label with its four, or it's implicit, right?

Is that you could do like a div with an ID of foo, and you could be like this GitHub page for repository in the same thing. And then here, you could do ARIA labelled by, and then you would just link to that ID, so foo. So this is like very similar to, you can, I mean it's just kind of handy if you have a big old description, you maybe don't wanna put it in an attribute.

So you put it here, although you'd probably also then wanna do class equals visually hidden, right? If you're doing it here. Although, sometimes it works out really nicely where you have a big paragraph about what the button does. And then, you have your button, and it's just really nice to link the two of them together, but you have a lot of flexibility here.

So you can do an inline label, you can do a separate label with labeled by. And then lastly, you can do ARIA described by and this gets into some of the more complex situations. So, I have a question that I always get is like, what's the difference between labeled by and described by?

So the label is essential information about the thing, like what is the button? What does it do? Description can provide extended information that the user might need. So here's another example. We had that great question about what if you have a button, and he buttons submits a form, but after it submits the form, it does a redirect.

So we talk quickly about roles, which we'll get into next. The other thing that you could do is, you could label the button submit form. And then, you could described by the button, after this form submits you'll be redirected to the home page logged in something like that, right?

So even more ways that we can communicate with a screen reader. Any questions about labels and described by? Awesome. I will say for sure that it has been my job before to go into existing code bases and just add a bunch of labels and descriptions, which is like a pretty, nice and easy kind of going thing to do.

And then the feedback has been really stellar from people that rely on it. So again, it's like small changes that can have really big impact here, just kinda adding some labels and descriptions. Another thing that we've done is internationalized, the labels and descriptions, right? That's another cool thing.

So if you use some kind of internationalization library, instead of doing these inline labels, you can switch to labelled by and described by and just wrap it in your internationalization library get those strings translated. So that folks using screen readers who speak different languages can get access to all that information too.

>> Maybe this is a silly question, but when you have more than a couple of labels or described by they'll read from left to right?
>> Yeah, I see when you have a couple of labels are described by, as yeah, they'll read left to right or top to bottom like first come, first serve order for sure.

Awesome. So labels are a big part of ARIA, another part of ARIA are roles, states, and properties. And we've seen this a little bit already, but it's actually got a wide range of cool things that you can do. So we've seen this enroll equals button, right? So if you have a button, and you tab to add on a screen reader will say, hey, there's a button here.

If you have a div with class A button, it won't do that. But if you add role button, it's talking directly to the screen reader and saying, hey, this is a button, interact accordingly. Another one that we see, and again it's folks like in design always they hate the way checkboxes look.

This is like one of the most common accessibility things that I see is that folks have completely rebuilt their checkboxes out of like divs and spans with icons and things like that. Because they wanna slick animation, or they want just it to look very different than it does.

But often you lose a lot of that accessibility that comes built in with check boxes. So I think a lot of the best checkbox libraries built on top of real checkboxes, but if you're in a situation where you do not do that adding role equals checkbox to it will do a lot for users using screen readers.

I have a full list of all the roles and states and properties here. They're really cool. For the most part of the way I do this is when I have something that I has a little bit of context to it, I just come here to this MDN page and find the most similar thing like, is it a tree?

Like if you're doing code stuff like on the left sidebar? Is it a form? Does it navigate you somewhere? Is it a menu, just kinda adding these things or like a progress bar and a modal. Just adding these kinda roles where appropriate will just help the screen readers out here.

There's not a whole lot more to this, you just add role equals and then any one of these are totally valid, and support in a lot of browsers. One thing about roles is what they are, right? And, so those are these up here, like what structure or what composite roles they are, like this is a grid.

This is a list. This is a menu, is a link. Another thing that's really important is that ARIA support state. So ARIA support state like, checked, disabled, error message, expanded, hidden these kinds of things. These get a little bit more advanced, right? Because these aren't simply applying them to HTML, these are adding and removing them to HTML based on state, right?

So if you have a checkbox and when you click it, it expands the tree of things or whatever. Then, the checkbox you would need to use probably JavaScript to add an ARIA checked state on and off when it's checked or when it's not checked. Similarly, expanded or removing expanded, so they get a little bit more complicated, but I mean honestly, it's just like setting attributes and removing attributes with JavaScript is all it is there.

Or if you use like react or something like that in your render path if state is checked, you just render a different div, maybe with that ARIA elements, something like that. So these can be really useful for a lot of different things like just kind of helping users out with the current state of the application.

>> Sorry, two quick question with one of the widgets I'm seeing. Without autocomplete, I've seen that some browsers recommend to turn that off, or on given certain inputs.
>> Yeah, that's really interesting. Autocomplete can be a little bit tricky because right, so the question is about ARIA auto autocomplete, and when to turn it off, when it turn on, these different things.

It's really interesting, because autocompletes work slightly differently. A lot of times the JavaScript, but the way that I've seen it most often is like you said if suggestions are coming in from the servers to have that on, right? So people know that they can down arrow and up arrow through suggestions.

And if the suggestions array is empty, then remove the attribute too
>> Thanks.
>> Yeah, of course. What a great questions. Cool, so yeah, ARIA can do a lot of stuff. I think the roles and the labels are very easy, they're just adding them to existing HTML. The states and the properties can get a little bit trickier because they actually rely on your application state to toggle on and off.

So those ones can be a little harder. Again, I always wanna advocate for doing some is so much better than doing none. So if you're at work, and you're trying to get some budget for accessibility, like I think applying the 8020 kind of rule to it where you're like, hey, let's get in there, like label a bunch of stuff.

Make sure we're using the right tags, add some roles, like anything you can do is gonna make the experience so much better. As with most things in development, there's that long tail of stuff you could do to have it complete or perfect or something like that. So, I mean, the more you can do, the better obviously, but I really do think getting in here and kind of doing the 80% is great.

Another interesting thing with these, since they're data attributes is you can use them in CSS selectors as well. So we can kind of see here that you can do. I don't know if you've seen this before you use an arrow pointing to the right, and then you click on the thing, and it goes down, so it's kind of like a tree expanded.

So you can even do that if you apply the ARIA role to it, you can actually grab it with CSS and kind of change the thing. So they're just data selectors, so you can use them in CSS and vice versa. You can use the CSS to style them.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now