Web App Accessibility (feat. React)

Roles, States and Properties

Marcy Sutton Todd

Marcy Sutton Todd

Principle Studios
Web App Accessibility (feat. React)

Check out a free preview of the full Web App Accessibility (feat. React) course

The "Roles, States and Properties" Lesson is part of the full, Web App Accessibility (feat. React) course featured in this preview video. Here's what you'd learn in this lesson:

Marcy explains that roles, states, and properties are the building blocks of ARIA. Accessible names and descriptions are also critical for giving clear instructions to users. Some elements have implicit names and descriptions. Other elements will rely on aria-labeledby and aria-describedby to indicate where the name and description are provided.

Preview
Close

Transcript from the "Roles, States and Properties" Lesson

[00:00:00]
>> Roles, States, and Properties, these are the building blocks of ARIA. So all of the attributes that are defined in the ARIA specification are roles, states, or properties, such as role-button or aria-hidden of true. So roles are pretty straightforward in that they are, what does the thing do?

[00:00:23]
Is it a button? Is it a checkbox? So, as I mentioned, the button element has an implicit role of button. The role of button will bolt it on, and in the accessibility tree's view, that's seamless. It's pretty well supported, I mean, I think you can do that pretty reliably.

[00:00:46]
But div role="button" is not the whole picture, so that's why we say use button first. So, why would you even use that? It'd be like if for some reason you're building a custom component, and you can't use HTML. I mean, it better be a compelling reason, but there's so many constraints that we deal with in the real world, that I'm sure it's come up.

[00:01:08]
I mean, it could be that you have really annoying old styling that you can't get rid of or something. That's some technical debt that I think would be worth facing, but sometimes we have constraints. So, I can think of another example. I worked on, it was actually a desktop application that output widgets.

[00:01:32]
So it was outputting web widgets that you could embed, and it exported divs for buttons. And the fix in the actual desktop software application to output a button element was non-trivial. I wasn't like, hey, I'm just gonna go in and swap that element out. No, it was old back-end code to generate button elements.

[00:01:58]
So, yeah, we've definitely put an issue in the backlog to do that work. But in the meantime, are we just gonna let button elements be divs? No, I bolted on a button role, and tab index, and a keyboard event, and did the whole song and dance. Well, we kind of did both things, so that might be the solution.

[00:02:17]
If for some reason you're like, we can't use buttons right now. We are doing the work to upgrade our infrastructure so that we can. But in the meantime, maybe you bolt on a button role and all of the other parts. So when you're checking support for an ARIA role, state, or property, or you're wanting to use them, you should check support.

[00:02:39]
So for something like aria-autocomplete or aria-drag, where you're like, isn't there an ARIA attribute for x or y that I saw on ARIA spec or I remembered at one time? It's good to do some research on it. So the first site I would recommend is called Accessibility Support, or a11ysupport.io.

[00:03:02]
This is a community effort to, basically, crowdsource, it's like a caniuse.com for ARIA attributes. So I think the example I had was aria-autocomplete. Yikes, that's a no-go. [LAUGH] Is it supported across the board as either none or some partial support? So I'd say, sorry, aria-autocomplete attribute, that's just not gonna happen.

[00:03:30]
What would be another one? I guess, aria-drag, I don't think that's a thing. aria-dropeffect, yeah, that one's not documented, and probably not supported. Whoa, I'm surprised about aria-hidden, that's actually pretty well supported, but there's no data on it. So that's still kind of interesting. Let's see, what'd be another one?

[00:03:58]
aria-label, all green, all good, supported, pretty reliable. You have to use aria-label on the right role. You can't put it onto a div, but that's not a support issue, that's just a technical requirement. And it's interesting they put screen reader support, voice control support, aria-labelledby. So this is some really helpful data.

[00:04:26]
Another one I've used this for is aria-expanded or aria-haspopup. So some of these things that we put on custom little dropdowns and things. Support's pretty good, but we can go in and read more. What are the things that it's not passing? Simple trues or false seem pretty good, aside from Narrator, Orca, which is Linux or Android, TalkBack.

[00:04:57]
I could go test in some of those if I was really concerned. So I'm talking about how to prioritize. This is one direction I could go in to say, all right, I wanna use this ARIA attribute to communicate the state of this component. I looked it up on Accessibility Support IO, and it looked green across the board, except for Narrator and Edge.

[00:05:18]
I'm gonna go test over there and see what happens. So that's pretty cool. I mean, you should test it elsewhere too, but this is kind of helpful data to digest and apply. So a11support.io, and they are community-driven, so I'm sure they would love contributions. And then testing it in screen readers, cuz that's where the impact is really going to be felt, is in assistive technology.

[00:05:46]
And that's also why it gets forgotten [LAUGH] or screwed up, is that I think developers, it's so easy to add ARIA, but then the testing step gets missed. So we want to make sure we're testing it, or just don't include it at all. I learned that kind of early on in my career, that I could make it a lot worse without realizing it.

[00:06:08]
So, yeah, ARIA should just kind of accept or remember that it should come with a bit of caution [LAUGH] or some testing time on your calendar. And then you can read up on mailing lists like the ARIA GitHub. The NVDA GitHub is really great, that's where they develop the Windows screen reader, NVDA, it's open source.

[00:06:31]
It is a treasure trove of information over there, especially for Windows issues. That if you're primarily a Mac developer, and you start to test on Windows, you can dispel some misconceptions just by reading the NVDA GitHub. Cuz somebody's probably had the same question as you, and you can go and read, and it is very helpful.

[00:06:53]
And then the WebAIM email discussion list, they have decades, I wanna say. I don't know how many years of archives, but they have email archives from a very long time ago that have discussions from people who work on browsers, work on screen readers. The accessibility community includes people who developed all of these specs and all of these tools.

[00:07:17]
It's really cool that there's answers from people that are so informed and instrumental. So you can use ARIA in your CSS selectors. It's a pretty cool technique to do, I guess, depending on how your styling is generated. But like any attribute selector, you can match your CSS to certain ARIA.

[00:07:42]
So for example, if I have a custom role of checkbox, sure, I could add a class or an ID or something. I could also just match it based on whether it has a role. I've done this when I need to differentiate certain inputs from other inputs, I'll end up using these attribute selectors.

[00:08:02]
But the ARIA ones also, I could style a disabled checkbox that way. Increasingly, a lot of codebases are using things like Tailwind, so you might not have these types of selectors. But Tailwind does a pretty good job of incorporating accessibility into what they're doing. Love it or hate it, they are at least making it possible for us to create similar experiences.

[00:08:31]
I didn't ever think I would be a Tailwind person, by the way, just a little side note, but it's been kind of awesome. It does get in my way, though. [LAUGH] Okay, so another example could be styling off of aria-expanded. That's another one of those states. If it's true or false, you can change how it's styled, question?

[00:08:51]
>> What about hidden anchor elements for screen readers, like skip to main content and skip navigation?
>> Yes, so the question was about skip links. We are going to talk about skip links in the next section. So, with those, we actually don't want them to be hidden. We wanna make them usable by sighted keyboard users, too.

[00:09:15]
So I think there used to be an approach to skip links where we would put visually hidden on them for some reason. And let's just get that out of there, no more of that. [LAUGH] I don't know where that came from, but skip links are super useful when you can see the screen and you wanna skip around.

[00:09:34]
If you can't use a mouse, we actually would benefit from some skip links on these slides. So, yeah, we wanna make them visible, but we will talk about skip links a little bit later on. All right, so accessible names and descriptions. ARIA brings with it a pretty foundational concept here, and we've already seen some of it.

[00:09:57]
Accessible names apply to links, buttons, form controls, images, tables, field sets, legends. Anything that has what we call a label, quote unquote, has a technical term of accessible name. So if you hear that, that's what that is. It's basically the label for something. And only certain elements can be labeled.

[00:10:21]
You can't put aria-label on a div unless it has a certain role on it, but that's what that concept is. There's also the concept of an accessible description. That if something has a label and a title, the title will be read kind of after the initial text, after a bit of a delay.

[00:10:39]
And that's what's called an accessible description. Title will do it, aria-describedby will do it. They are configurable on the screen reader, though, so you don't wanna count on descriptions always being there. So aria-label, aria-labelledby, aria-describedby, you can label things, and we've seen some of this already. But I can bolt on a label pretty easily.

[00:11:05]
The risk with aria-label sometimes, and I saw this in a codebase recently, is people set it and then they forget it, and it's not relevant text anymore. So I have a slight preference for aria-labelledby, cuz it will just always stay up to date with whatever. If this All About Wombats heading is visible, and it gets out of date, that'll probably get fixed.

[00:11:26]
But then the accessibility connection is still there. It's just gonna programmatically point to that. So I think that's pretty awesome. And then aria-describedby, it's very similar to labelledby. It just creates that description instead of a name. So as we saw in the Chrome DevTools, that will show us which thing wins.

[00:11:51]
So when we have multiple, this tiny screenshot has aria-label, it has title, placeholder, maybe more than one title. I'm not really sure what's happening there, but we can see the description is helper text. The name is text on this very generic example. But that tool is excellent for helping you see which thing wins, because something has to win.

[00:12:18]
And in the enterprise workshop, also, we are going to dive way deeper into this topic, gets pretty geeky.

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