A11y Treats - Labels & Roles

Welcome to Syntax. On this Monday, hasty treat, we're going to be talking accessibility, and we're gonna be talking specifically about labels and roles. What's the difference between labels and roles? When do you need them? When do you not need them? What is the general reason that we have them? My name is Scott Tolinski. I'm a developer from Denver, but today, I'm hanging out In my childhood bedroom in Michigan.

So if you notice any background noise, maybe it's kids running around for Thanksgiving or any of that stuff. But, with me as always is Wes Bos. How's it going Wes? Hey, pretty good. I'm excited to talk more about accessibility.

Last couple episodes we did on this stuff were pretty well received.

So we're gonna dive into ARIA roles and labels today. Yeah. And I think pretty well received is selling them a bit short. They were very well received. In fact Oh, yeah. High price.

So, before we get going, let's talk a little bit about, something that your applications might need beyond accessibility roles would be the Error and exception handling and tracking with Sentry. So head on over to Sentry dot io if you read any application that anybody's using. That way you can make sure that your applications errors are swallowed up and then given to you in a nice lovely table that you can see and fix. Okay.

The Accessibility.

So ARIA. West, do you know what ARIA stands for? Because that is an acronym.

I don't.

It stands for accessible rich Internet applications. K? Nothing too crazy. And, honestly, you probably don't even need to know that. But ARIA is basically these are the anytime you see the word ARIA, your brain should be Getting into the land of these are tools to help assisted tech assistive tech and screen readers to understand your website. And This could be many different things, but the 2 that we're gonna be covering specifically today are ARIA label and roles or role, the role attribute.

What's interesting about these, and we had a little bit of discussion before this episode is, it's ARIA hyphen label, but it's just role Even though you will often see people refer to role as ARIA roles.

So these things both exist as attributes on HTML for a specific purpose in describing your code. However, they're very different.

So aria label is for, again, screen readers and assistive tech to understand the purpose of an element on your page. K? It's the purpose of the element.

It's a descriptive label that, will define More than what the content itself can define.

I think, an interesting example for this Is that let's say you have a button and that button value is just send.

What does the word send tell you? Yeah. Yeah.

It's true, especially when you're in that context. Send what? So putting in or even, you're not even a send. You put a little paper airplane icon inside of that thing, because that's what the design calls for. And that's totally fine.

But if somebody, a screen reader, Jeff. Sort of reads that thing, and it just says paper airplane.

What does that mean? Yeah. Or even worse, nothing. Yeah. Classic cafe menu.

Who knows? Right? Yeah. So then what you can do is you can define On the element, an ARIA hyphen label and then a string of which let's say the send example could be send email, Something that gives somebody who's unable to fully see or read that symbol as the way it is.

Context. What the heck this thing is actually doing? Why it exists? And, you know, this be one of those areas where designers, They could have their co or they have their design. They present you to their design, and the accessibility people can say, shoot. That that Send with the airplane button isn't descriptive enough for screen readers. Well, luckily, we have these properties to be able to fix this for us, I e, the ARIA label. So it gives context to generic items or nondescriptive items in a way that allows us to fully understand what the heck these things are. So that way, again, screen readers, assistive tech read it out loud. They they hit that element, Or perhaps they label it or something like that. You could see it very clearly exactly or hear it what's going on.

Sometimes you can also use these labels just to add better context to your application as well. You can reuse those labels to throw in a tooltip, throw in a title And if you Hover over top of the button, you could show that to the user to give them a little bit more context. Like, what does this button do All the time I work on applications and there's random buttons. I'm like, I have no idea what this little washing machine icon actually is. And If you hover over top of it, you get a little bit more context for what that is. So it's not just like if you're going through the work of Having to create these additional labels, maybe also figure out how you can show it to

other users that maybe aren't using assistive tech as well. I gotta say that is a huge pet peeve of mine, especially in application interface.

Stuff. I forget what app I was using. It was something I I wish I would have written this down because it wasn't a web app. It was a normal app, and it was my 1st time using this app. And on the top bar is a row of icons that honestly could have meant literally anything to me at that point because this is my 1st time using this application.

And I hovered my little mouse cursor over the icon waiting for that tooltip to pop up for it to tell me what it did. Nothing.

And there's no label. There's nothing descriptive about it. It's just you're on your own here. So, yeah, those kind of things are very important to give your users the context there.

Next one here is the aria Sorry. Hold on one sec. I I have a question, and, and maybe you can tell me this or we can research it is, Like, what's the difference between a title on a button and an ARIA label? That's actually a good question. Let's look it up. Never use Tidal for anything. No? Yeah. Oh, because because Tidal is what shows up in the little tooltip The tooltip. When you hover over top of, something. And the answer I've gotten a couple of times is put both right. Yeah. Because the title is for the tooltip specifically the title is for the tooltip and that. But then I've always thought, like, isn't isn't title enough, you know, and apparently screen readers don't necessarily read the title On that. So you should throw an ARIA label on it, which is why I said, like sometimes you just need to duplicate it, which is really nice when you're using a framework

Not just straight up coding HTML because you could just use the same string twice. Oh, yeah. You don't have to hand put that string. Look at me saying that I, abhor when people don't have labels, and then I said moments after that that I never use title.

Yeah. Probably because I don't design a lot of it. I don't design a lot of interfaces like that. I do websites. So well, here in

On the Syntax website, there were some buttons that did some scary stuff like import something or nuke like it basically. And I had to, like, message you and say, like, if I click this. What happens? You know, and it would be nice to hover over top of it and give a little bit more context as to this will import all shows but not drop any existing data.

Yeah. In fact, even the the the titling of those buttons was awful. But it was also just because I was the only one using them, and I knew they did. I was and then you you run-in that classic problem of Got lots of somebody somebody else walks into the control room, and they're like, None of these labels make any sense.

The, sync all episodes button doesn't actually sync all episodes. Imagine that. One more One thing I want to add here, and this was some feedback or a question that we got from the last accessibility episode we did is someone said, Are you really gonna get sued if your website is inaccessible? You know, like, is there actually things that are going to happen, which is like not a great attitude towards this type of stuff. Right. Donica. If people think like, are accessible people really coming to my website? Yes, absolutely.

But yeah, there's lots of examples, and I think you should Really get up to speed with if you are a web developer, you should be up to speed with what the accessibility laws are in your country.

In Canada. I think it's something like 50 employees or more, and your website must be accessible and you can get in trouble.

I did a quick search and there there is several, lawsuits that have happened over the years with Mostly larger companies. Domino Pizza is one of them, where parts of their website or application are inaccessible, And therefore, you get in trouble. It's it's the same thing with the building, right? Like, if you have a building that is being built and someone with a wheelchair can't get into it. Like new buildings have to be built built to a specific spec so people can Use them. Right? And it's the same thing with websites. Yeah. Just imagine you're in a wheelchair,

and the building only has stairs. Yeah. You would be Really upset if you could not get into this building that you needed to get into. I would really like to have somebody

there's there's a guy Probably 10 years ago now, and it still sticks in my mind. I've told the story a couple of times.

His name was Jenison, and he was at a conference and he showed you how he uses his iPhone being blind.

And it was amazing because he didn't. He gets the best battery life. Screen was totally off, right? I would love to just see a couple Like screen, maybe we'll do this once we roll out the video version of Syntax. Like what does it look like for someone who is 100% blind using a website, someone who is partially blind, someone who needs like all of the different disabilities where you might want to consider.

And I would love to like see like how does somebody navigate an actual website and like what are some of the common things like posting to LinkedIn, posting to Twitter, trying to go to a website to find the address or the phone number for some takeout.

What would that look like? So I'm gonna put that on the the list of something to do once we hit video. Yeah. Totally. Yeah. I I think that that would be really good. And one thing that, you know, add on to this conversation that I've always heard that there is no, like, disabled. There's only, like, temporarily abled. As in All of us are temporarily abled, and we all will become disabled at some point in our lives for various reasons. Mhmm. And we've talked about this before and, like, What even

Situational.

Yeah. Situational disabilities could even exist or even, you know, you get older and things change, your vision Changes your hearing changes, those types of things. So, you know, just have some empathy here, folks. It's not about you. It's about other people. Right? So okay. Let's talk about roles now, which is an interesting thing that they're often referred to as ARIA roles. So what is the difference between a role and a label? Well, a role is describing essentially what the element itself represents. It's a button.

It's a tooltip. It's a tab. It's what it is. Right? Mhmm. And the label is all about what This thing does for the user. It's a send email.

It's a submit post. It's describing the actual thing that it is to the user instead of maybe perhaps the element Or the user interface aspect of it, which is what a role does. So roles are interesting.

And in fact, the the big thing about roles inside of HTML.

And this has changed a lot with the addition of more HTML elements is that almost Always nowadays, you're going to want to use the semantic HTML element before even considering a role.

K. Because a role is kind of an escape hatch to not using the correct HTML element.

And the further we get into HTML, the more HTML elements exist that are almost copies of what Was existing as roles before. We now have a search element. Did you know that, Wes? Really?

Really. Like, not a input type of search? No. Just search. But a search element in HTML? Yes. In HTML. Oh, the generic search element.

Oh, that's nice. So it's an element that will wrap a form tag and allow you to oh, that's kind of nice.

I like that a lot because that's that's like the first part of accessibility is just use the built in HTML elements

that were given And don't put divs everywhere. That's actually very correct. So when people push back on using divs, it's almost always because, Hopefully, there is a correct HTML element out there to do what you're looking to do Mhmm. Whether that is button, whether that is things like search, and there isn't always, which is where roles come in. They, provide that structural description of what's going on.

And you can use man, there's a whole bunch of different types of roles. So There's 6 different types of roles, abstract roles, document structure roles, landmark roles, live region roles, widget roles, and window roles. And I you know, the these things are important to get into the nuance. So I've list I posted a link to the Ally Project that has a great blog post Breaking these down. But at the end of the day, again, always think that you you wanna use the correct HTML element first. And then once you get into a situation where there is no HTML element to describe the thing you're doing with tabs or something like that, then you're going to be reaching for a role. Yeah. They can also be used

in some cases for whatever reason, whether it's framework limitations or I don't even know why, but it seems like Google and Facebook, they're div soup. They use they use divs for absolutely everything.

And if you go to just do a quick Google search, there's a little button, you know, like search by image on Google, and in the search bar, I was like, all right, well, what's this? This is clearly a button where you click it and it performs an action inside the application. Right. And guess what it is? It's a Div.

And then on that div has both an ARIA label search by image. And then it also has a role, which is a button. That's probably the most common thing where somebody is using a div to wrap.

Some content, and it needs to be presented as a button to the browser. And then they also have to put a Habit x on that so you can focus it. So like it seems crazy to have to add all that extra properties to a div and not just use a button. And there's probably some sort of compatibility, like higher level thing where they have like nested components and everything is rendered to a div.

But I'm very curious for anyone who does work at one of these large companies why everything is always a dev. Yeah. And it could be you know, I don't know when

HTML five introduced the ability to wrap, like, anchor tags around block level items and stuff like that. So there might be some nuance there in terms of when some of these things were added.

Really quick about I mentioned that there was those 6 different types of roles.

Number 1, abstract roles.

It says do not use them. They're basically, their abstract roles are only intended for use by browsers to help and organize and streamline a document. They should not be used by developers, so ignore those. Document structure roles are used to provide structural description for a section of content.

So you could think of it as like a toolbar.

Right? That is a section of the content. It's the toolbar.

There's also landmark roles. They identify content areas within a page. You can think of that as, like, Header, aside, footer, those types of things. Nav, like, live region roles. Live regions could be something like an alert For a toast or a pop up, the, the most common used live region role is alert.

There's and you're gonna wanna look up the MDN docs For all of the list of roles, and in fact, MDN is really good because it will say, specifically on MDN, hey. Don't use this one. Use the search element instead. Right? There's also widget roles. Widget roles are used to describe common interactive patterns like, tab panel, tab list, those types of things like I mentioned. There's no HTML element for those, so that makes sense.

And then window roles, which are things like an alert dialogue and a dialogue.

So you'll wanna look up all of the different available types of roles. It's really, like, Gonna get too much into mouth coding to just list them all in here. But, again, we'll have some links available to you that shows you which ones to use where and whatever. At the end of the day, stuff. If you're if you're using a non non semantic HTML element to to do something or to define an area of something, You have a button, or you have a button that's a div. Yeah. You're gonna have to put a a tab order on that like Westside. You're gonna have to do a roll of button. You're gonna have to handle those clicks and all that stuff correctly.

And and I actually blame front end frameworks for this one because they make it so easy to add on click events to gosh darn anything.

Oh, I just got a div. I'm gonna throw an on click function on this and React's gonna do it for me. Right? The ESLint

accessibility plug in is well worth installing in your project.

In fact, it comes standard in my ESLint just because like no one is is like intentionally going out there and being like, you know what, screw these people, you know, like I'm going to make an inaccessible website, but you accidentally do something or what would happen if we click that type of thing? And then before you know it, oops, you actually did something which is inaccessible and the amount of stuff that gets caught by a linter As you're coding it, and it's usually just a quick fix to actually do the right thing rather than you having to perform some sort of big review of your website after the fact. It's just catch it right away,

while you're coding. Yeah. Totally. It's one of those areas where linters, any of those things can just come up majorly clutch. In fact, I love that By default, SvelteKit will bother the life out of you if you mess up that whatsoever.

Yeah.

You know what's one thing I noticed when we were doing Sveltekit is I couldn't put was it a component or a div inside of a link? Like it it just like would not allow me to do it. I think it was probably a component because there's a possibility that That component could have another link inside of it. You know, you could do some some bad stuff. Interesting. Yeah, I forget I forget exactly what it was. But there's a couple situations where I'm like, I'll just wrap this entire thing in an anchor tag because I want the whole thing to be clickable.

And It wasn't allowing me to do it. So that's another use case for roles as well is where you literally you can't do it. So you have to over Override it with an ARIA role and say, Okay, I know I shouldn't be using a div or whatever here, but I need to. So let me make it right that the browser understands what it is. Yeah.

One last thing before we get into labeled by, is stuff. I saw a really nice little sentence that says, no ARIA is better than bad ARIA. So if you put a bad role on something, Like, a role that does not apply correctly. You're doing more harm than good there. So just take care with your roles and do it well. Right? Last thing I wanted to get into here before I talk really quick about testing your code in various ways is the aria labeled by, Which I thought was interesting. I probably should've covered this when we talked about label. But ARIA hyphen labeled by is a property that allows you to specify an ID, the And that ID will then look for an HTML element with an ID and then use the contents of that element as the label.

And this is interesting.

ARIA labeled by has the highest precedence when it calculates accessible names. So if you have a label and a labeled by, it will use the labeled by value. So just a just a heads up in case you have some Wonky code that would have both of these. But this gives you the opportunity to perhaps label something with the contents of something else. And just in case, that that's a a situation you find yourself in, I I'd never heard of labeled by before researching for this episode. So If you find that interesting, I think that's a neat little trick. Not something I've used before. This is you're going to need this now that we're moving into using CSS Has

because in especially with like a checkbox, if you have a checkbox and You want someone to check it like the UI for checking it is in a different spot than what it describes is going on.

You can just associate those 2 things together with an ARIA label vibe like visually it might might make sense to you. But if the checkbox is not in the same label as the thing that is describing it. Then those are essentially 2 different checkboxes.

So That is a super handy thing to have word. If you wanna check your code for this stuff,

wave.web just aim.org will have a link. It's a free little tool you can drop your URL in. There's a lot of tools. You can just go online, Google accessibility checkers or, ARIA role, ARIA label checkers. There's a lot of them out there. One thing that we mention anytime we talk about this stuff is Polypane is an app. It's not free, But it's a browser That's well worth it.

Developer tool. Yeah. It's well worth it. I use this thing, like, nonstop when working on the new syntax site, and it will give you not only we talked about this in the headings episode where it'll give you a complete Listing in hierarchy of your headings, but it will run all of these accessibility checks. It will tell you what's missing labels. It will tell you what's missing roles, And it does so in a really lovely way. So polypane, well worth the money there. Polypane.app.

I'll have a link for that in the episode. I always hate when people talk about how worth something is. And they don't say how much it is. So the individual is about $10 US per month And it gets cheaper as you get into like business and enterprise license words.

Yeah. We should get some referral cash for Polypane. How much I talk about it on here.

Alright. I think that's it. Thanks for tuning in. If you would like us to talk anything else, actually, 1 show I really want to talk about is When something changes and you have to announce that something has changed so I was doing a drag and drop example in my upcoming TypeScript course. And you have different states like when you're in editing state and then when you drop And you need to tell the user, Okay, I've I have put that item called eggs at number 2 in your list, you know, and you have to announce that there is a change.

I think that would probably be A good episode is diving into all of the different ARIA attributes for announcing when things change on the page because it's one thing to make like a website and a web app that you submit forms and whatnot. But it's another thing to get into custom interaction.

Now you're starting to get into some really hairy stuff, and most of that is like React Aria is miles ahead with a lot of that stuff making very common UI stuff accessible.

But if you're building your own custom UI, like maybe a flight planner or something like that, you got got to really start thinking about, okay, this is a really cool UI, but how do you also make it keyboard accessible and be accessible so your users can

tab through it and use it with a screen reader. Yeah. And if you're out there and you have stuff. Aspects of accessibility that is a mystery to you that you would like us to dive further into, we would love to hear all about the thoughts and questions and concerns. If you have anything in addition to add to this episode, thoughts on roles or labels, things that we didn't hit, or things that you think could be elaborated on, please let us know. We are on Twitter. We are on all of the spots, and we will retweet you or any of that. I was just looking at my code base, and it's Aria live equals polite.

And that there's different levels of of like how assertive you want to be when you want to announce a change on the page.

Light. So nice. Speaking of, this is totally off topic, but there was a Gen z guide to emoji in the century Notion West that I recommend you check out. It's very funny because they'll be like the normal smiley face, And then it has tone passive aggressive. And I was like, what? This Gen z finds that to be passive aggressive? Oh, no. Oh, yeah.

That's great. Alright. Thanks, everybody, for ding in. Catch you later. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.