ARIA Name Computation

[00:00:00]
>> So let's transition to some ARIA. So we're kind of layering on top of some of the basics here to get more advanced. So with ARIA, the first kind of concept that I want you to know about is accessible name computation. Which we've already talked about a little bit with images inside of links and buttons and ARIA labels, form labels.

[00:00:24]
And so within ARIA, which is a specification for a standard set of attributes for accessibility, there is this big concept that has an impact on HTML markup and it's called accessible naming. And names apply to form controls, links and buttons, section elements even. So I mentioned earlier that section and nav landmarks that are repeated a lot.

[00:00:53]
You can give those names and then in a screen reader, it's easier to tell them apart. Like is that section for the personal information section or is that for my communication preferences like what is that section for? Or a nav? Is it our main nav is that our social links?

[00:01:09]
Like what nav is that? Those names with aria-label or aria-labeledby our super helpful, tables have names, figures, field sets and legends and so that like it's this programmatic way of exposing the name of something. But div elements do not, so if you put an aria-label on a div, Axe will complain at you because that role doesn't allow it to be named.

[00:01:38]
So there's multiple ways to name something, depending on what its role is, text content, if you have a label element with text in it, that will become its accessible name for an input when they're paired. Aria-label, you can put right on an interactive element or a landmark. Aria-labelledby, and aria-labelledby is really great because you can point to an ID of another element, and it will grab the text from that, even if it's hidden, even if it has display none, which is kind of interesting.

[00:02:10]
But that means you can reuse content that is visible and not risk it getting out of date. And so there's a lot of intricacies in here. So how does this even work? Because when you have multiple things on an element, something has to win. So which one wins?

[00:02:31]
Well, there is a document, a specification called the accessible name and description computation specification, very geeky, and they standardize this. So that browsers have at least some consistency cross-platform and it's not absolute chaos trying to understand which thing's gonna win. So I have an example of an implicit label wrapping an input.

[00:02:56]
So zip code is label text. The input also has an ARIA label of zip-code which kind of makes me think it might have been a typo. They didn't really know what an aria label was doing. It also has a placeholder, for a sample zip code and a title attribute.

[00:03:15]
So that's a lot of things. Fortunately, the Chrome dev tools, we can sort out which thing wins. So it's not a mystery. But this process of the algorithm in the browser and the accessibility APIs on your computer or your phone, they follow this standard. So at least you know it's repeatable.

[00:03:38]
There's some order here. [LAUGH] Thank goodness. [LAUGH] So it, I've read through the thing. So it goes like this, for non-hidden elements that allow naming, it goes aria-label-by, then aria-label, then title and placeholder, cuz they added those in when they saw enough people were skipping names, like, there's a title and a placeholder on it, better than nothing.

[00:04:02]
So those are in there now. And then it will go to a label element, and then certain child controls, and then text content, if I read that correctly. Fair warning, that was my interpretation of it. But I mean, how we follow the spec is less important than like, what are we hearing in a screen reader?

[00:04:23]
And like Chrome DevTools, well, we can rely on that to tell us. I mostly just wanted you to know that this exists. This isn't just like, pull it out of thin air, it is pretty interesting that they've standardized that. So, yeah, if you're hearing differences cross platform, they're more likely related to things like roles.

[00:04:45]
There are some definite differences there. But in terms of which thing wins for a label, it should be pretty static, pretty standard. So what are accessible descriptions? We heard about names, and those are always announced. Names are always announced in a screen reader, whereas Descriptions are optional. They may be read out in a screen reader after the fact.

[00:05:07]
There's a slight delay. But they're configurable, so users might opt out of descriptions. So, you don't wanna rely on a description with things like aria-describedby. It works just like aria-labeledby, except it creates a description, points to an ID on another element. And title is the one that you have a little mouse tool tip thing that pops up only for mouse users.

[00:05:33]
Title will act as a description if there's already label, like if there's already an accessible name, title will become a description. But you can't always count on those. So just know that those also exist. If you're trying to figure out which attributes to use and you wanna make sure you incorporate some of the helpful information for users, just know that description may or may not be announced.

[00:05:59]
So you don't wanna rely on it for anything important. It's like helpful stuff that's like nice to have, but not like the critical information, but with these attributes, especially ARIA label, and I mean, ARIA label buys better for this, but we wanna prefer visible text whenever possible. So I think there's sometimes a tendency for developers to slap an ARIA-label on something and call it good.

[00:06:25]
But that text usually isn't visible. We don't wanna be repetitive either. So if the text, like say you've got a heading or something on the page already, you can use aria-labelledby to make the connection to use that as an accessible name, but then that visible text won't get outdated.

[00:06:45]
And you're reusing something that's already on the page. And there is a CAG success criterion related to this called label and name. It's basically to make sure that your ARIA labels don't get out of sync with what's on screen, because it can be super confusing if something's labeled programmatically one way, but visually it says something else.

[00:07:07]
So that's why we prefer visible text. And here is the Chrome Devtools accessibility inspector. Make this a little bit bigger, showing a button. And we've seen this a few times already. But you can see in the computer properties when there is a label, I guess I'm in the image.

[00:07:29]
I'm focused on the SVG within the button, but when you're on an element that has accessible name, like, I guess contenders, [LAUGH] It'll show you kinda which one won by crossing it out, crossing the ones out that aren't applying, question?
>> The user has a description turned off, will they still be alerted of the presence of ARIA described by, so they can hear it if they want to?

[00:07:56]
>> You can hear it if you want to I believe, there's probably a key command I think it just depends on the user's settings. Yeah.
>> Is the ARIA label necessary when the same string, for example the zip code, is also in the label? Or can I remove the ARIA stuff when I have a label?

[00:08:15]
>> You can remove it. Yeah, so if you already have a label, use that. So ARIA label, we don't want it to be the first thing we choose, it's a way to just directly apply an accessible name, but like how we talked about using HTML first, if it's a form control, you definitely wanna try and use visible label text first.

[00:08:38]
Or text content, like in a button. If it has text in it, we should let that'll just be the accessible name, text content was further down the list of choices but when there's nothing else to out compete, text content it will win as the accessible name so like that's why a button that has text in it, that'll work fine.

[00:08:58]
So opt for that first And then you can start considering ARIA if you need to.