Setting Names and Descriptions

regions, that was pretty straightforward. Naming user interface elements is super important for

accessibility because, I mean, it's great to know that there is a button there, but you also need to

know what happens when you press that button, right? So that's why we need names. Save, close,

all these good button names. And there are a couple of ways to do that. There are also

descriptions, which are basically like the little brother or sister of the names, which is basically

secondary information for the user interface elements. And we get to that. And it's important

to know that ARIA is not the only way to set the name of an element. The name of the element can be

determined by a variety of things and I will not go into all of them. There's a whole another

specification for that. If you want to read up on the ARIA name calculation, you can do that,

but you should not. You should not. So if we have a button that is named save,

then the button has the text save on it and also the accessible name of the button is save. So

So, no aria to be seen here.

But the accessible name can also come from other elements.

For example, if you have two text nodes inside of the button or you have like a span in there or something like that, that all counts and will be combined to the name of the button.

Or if you have an image of a disk inside of the button with the alternative text save, then the save will be used in the accessible name calculation.

Look it up if you want to. Don't do it.

Will be used as the name, as the accessible name of the button too.

And then there's two ways to do it for using ARIA.

And these you can use when you are in a situation where you can't easily change the text inside of the button.

So, for example, if you have just an X or times sign inside of the button as the visual label and you want to name it close for screen reader users, then you can use the ARIA label close and this will work.

And will be announced in the screen reader as close button.

And that's it.

Like there's no indication that there's something else inside of the button.

And then you can also use aria-labeled by with two L's.

That's important.

And that basically references another element.

So in this case, let's assume I have a lot of buttons that have a close label.

and I only want to change it once, if I do, for example, an update or add a second language,

then I can use a span. Actually, the element doesn't really matter here, but use id close

label and say it's close and then button aria-labeled by a close label. And that basically

references this id and takes the text inside of the span and put that as the aria-label.

And so the accessible name of this button is also close.

And yeah, there are good use cases for this.

But it's not like you're doing this all the time.

This is actually, especially this example is relatively rare.

The analog goes for description.

So in this case, we have a close name.

The name is close and there's an ARIA described by closed desk and then a span with the ID closed desk for closed description.

It says back to start.

So in this case, this would be announced as close button back to start.

So there's always a little bit like a pause there.

And then at the end, there is the description that can help you to to give additional information to people using screen readers.

There is a relatively new aria-described attribute in aria 1.2, but the support is not super good,

so I didn't put that on its own slide. Maybe in a couple of months or in a year or something like

that ARIA described is good enough. And then you can name regions. So in contrast to interactive

elements, labels do not override the content when used with regions. I think that's an important

point that I didn't make super clear here. If we go back to here, this label completely replaces

the X in here. There could be anything inside this button. It could be open. It could be,

I don't know, hello. It could be anything. Screen reader users would only see the close

label. So ARIA label in this instance overrides the content. If you're naming regions, that would

be awfully inconvenient because we want to name the region and then you want to interact with

individual things inside of that region. So in this case, we have a main navigation that is labeled.

So, and this goes for all landmark roles and most of those grouping roles that I've shown.

That's not, not really, it's not really depending on the type of role.

when this is overwriting or not.

So this is a little bit harder to figure out.

But in general, for landmarks, this is the use case.

You have a nav, aria-label equals main,

and then you have content inside of that that's untouched by the aria-label,

and then you have closing nav.

And this will be announced as main navigation.

And that's basically it.

So navigation because of the role, and then main,

because that is the name of the region.

And so you can use aria-label, aria-label-by,

same way to label those regions pretty easily.

If you don't label landmark regions, they will just show up as navigation and you don't have any specific labeling, which is fine.

And you also don't need to write main navigation because navigation as the role is already read.

So, you know, don't bother with it.