This course has been updated! We now recommend you take the Website Accessibility, v2 course.

Check out a free preview of the full Website Accessibility course:
The "Label and ARIA Labels" Lesson is part of the full, Website Accessibility course featured in this preview video. Here's what you'd learn in this lesson:

Jon reviews how to effectively use labels for HTML forms to let screen readers to describe form fields for users.

Get Unlimited Access Now

Transcript from the "Label and ARIA Labels" Lesson

[00:00:00]
>> Jon: So another thing as we're getting into screen readers. Labels for forms. This is another, one of the things that's a bummer, is that accessibility almost never gets taught alongside HTML when you're learning it in the first place. And so it leaves you with some weird stuff. I remember learning about form labels.

[00:00:17] And being like, well why would I want that? Especially if you learn now, where there's cool placeholders, where it's like you get a placeholder and it disappears as you're typing. But labels are really important for screen readers, even if you visually hide them because you like your placeholder, something like that.

[00:00:33] It's really important to have a label that describes the field, so that as a user is tabbing through, they know what they're supposed to do there. So this is a simple example. You can do label for and then you put the idea of the thing it's labeling and then any string of text in there.

[00:00:47] So as the user tabs into it, it'll say.
>> Jon: That's a terrible label. It'll say click me. It should say something like enter your username, right? And then you could have an input type text for them to enter their username. So whatever you want the screen reader to announce to the user, that's what goes on the label and if you don't like the UI of the label, it's fine to visually hide it but they still should be there.

[00:01:10]
>> Speaker 2: Ben is asking are there ways to do automated testing of what a screen reader could read or how it would navigate?
>> Jon: So at the end we'll cover some automated testing stuff, there's not an API to detect screen reader usage. There's no way to do that kind of stuff, but there are, just using code analysis, there are some really great tools that will cover for automated testing that'll spot these things for you and help you avoid them.

[00:01:37] And a lot of them can be plugged into your CI job or whatever. So, yeah, we'll definitely cover a bunch of that stuff, there's some really great stuff out there. Cool, so another option is this concept of aria-labelledby. So aria-labelledby, I say labeled by, you can think of it as just kinda the opposite of label, so label is for an element and then an element could be labeled by another element, right?

[00:02:03] So here in this example we've got a regular div and then we have aria-labelledby name and so, there's a couple of cool things that I wanted to point out here. One, with aria-labelledby, you can pass in multiple elements, which is really cool. So you can see that the input type text, this first one here, it is the name field, which is important.

[00:02:27] But it also belongs to a section of the form called your billing address. So, if you have, this is a good example, if you have a different billing and shipping address it's nice to communicate to the user which name they're entering, is it the buyer's name or where it's going?

[00:02:42] So, you can pass in multiple elements, which can give you some really great context, like billing address name, billing address, address, something like that, as opposed to name, address. Another thing that's worth mentioning here, is using aria-labelledby can kind of get you away from having to necessarily use that label element, cuz now you can have your paragraph, or your div, or whatever you want, visually.

[00:03:06] And still define that relationship. Mostly I think I use aria-labelledby for the multiple elements. I just find that really helpful when you have forms that are broken into sections. Okay so again more things off our nice check list. Form elements. Lets see, required form elements or form elements that require a specific format need to provide that within the label.

[00:03:30] So again, if you have to fill it out or if you have to fill it out in a certain way, like a date that has to be month month / year year / whatever. However we do it in America, that both of those things need to be in the label.

[00:03:44] That is a required field in how you fill it out. That's Level 8 compliance. And also, yeah, just generally labels, queues, and instructions for any required interactive element. So this, we kinda talked about this a little bit before, but just the ideas, instead of jus having this endless list of input type text or whatever, you give it labels.

[00:04:04] So they know what's supposed to go in there, you can do labelledby stuff to give more instruction, like how to fill it out or specifically is it for billing or shipping, things like that. So pretty easy, just adding some more HTML turns it into a really robust application where, as you're listening to a screen reader, it's telling you everything you need to fill out these forms.

[00:04:23] Cool, so just.
>> Speaker 2: Comment?
>> Jon: Yeah, comment.
>> Speaker 2: Comment from Drew, one nice bonus of using actual labels is that clicking the label focuses the corresponding field.
>> Jon: Yes, is that not true with regular labels? I thought that was true with both.
>> Speaker 3: If you just use a div it wouldn't.

[00:04:40]
>> Jon: No, no, but a div won't actually label. Okay, yeah, so I guess there's three approaches. So one, which is a bad approach, would be div, enter your name. And then input type text. That would be a bad approach, because it's not very clear that they're related to each other.

[00:04:54] A good approach would either be div, or I'm sorry, scratch that. Label for name, enter your name, and then div ID name or input ID name. So that would work. And then conversely, you could do the opposite. Or you could do a div, with enter your name. And then you could do input ARIA labeled by a div.

[00:05:14] But with a label, clicking on the label should send you into the form, into the input element. But I think the trap is only when you have them next to each other, but they don't have a defined relationship. That's where you can get into some trouble, where they are one after another but they're not connected.

[00:05:31]
>> Speaker 2: Another question from Ben.
>> Jon: Yeah.
>> Speaker 2: For things like some help text on a field, would it make sense to include it in the label?
>> Jon: Yeah, that can get kind of interesting. So yeah, I think, there's a few different things. Because sometimes you have a ton of stuff, a ton of information about a certain thing.

[00:05:48] So I think that whether or not it's required and also a format issue, how to fill something in, would be really good additions there. I think you might get into a little bit more of a different approach if you have, sometimes there's this like help text that are like, why is this required?

[00:06:06] And it's, all businesses in this state need to, you know what I mean, something like that. In which since I think a label wouldn't be the thing, but you probably want something tabbable there that you could interact with. So I think it a little bit draws the line, labels are really specific for that input.

[00:06:22] If it's general help text about, why fill out this form or something like that. I'd probably keep that as a separate element.
>> Speaker 2: This is from me. [LAUGH]
>> Jon: [LAUGH]
>> Speaker 2: Is there something you could do, for example, when that area gets focused, and then display that sort of thing?

[00:06:35]
>> Jon: Yeah, so yeah, you could do all sorts of cool stuff like that. So you could have an on-focus event on your thing that could maybe even let users, for more information, hit this, you could also just have a tabable element before or after it. Probably before it, that was like you're about to have to fill out this thing.

[00:06:54] Yeah, and again the user should be able to access, the same amount of stuff, whether they're sided or not. But it's a little bit up to you, cuz I think the only thing you'd wanna worry about, is you don't want a user to have to listen to three paragraphs of not necessary talking, just to enter their name.

[00:07:11] You know what I mean, so that's where it might get a little bit tricky if it's not required text.
>> Speaker 4: I would also recommend the using potentially the ARIA described by attributes.
>> Jon: Yeah.
>> Speaker 4: So where you talked about maybe a piece of text to follow the form element.

[00:07:25] You could use that to associate it with the form element, such that the screen reader will read the label first, and there'll be a pause, and then they'll hear the described by content.
>> Jon: Yeah, that's great, yeah, so again, and yeah, I think we'll be covering that in a few slides.

[00:07:39] But yeah, you can also use the described by for after, so yeah, that might be a really good approach to it as well.