Accessible Form Field Labels

[00:00:00]
>> So, labels are really interesting, again easy but big impact. So, form fields are an area where I see accessibility problems all the time, they can be really confusing for screen reader users. And there's a lot of different ways that we can fix this, which is cool. So, this is a pattern that I see very often in HTML, I'll see a form and it got some inputs and a submit.

[00:00:22]
But it is labeled by these paragraph tags and so for sighted users this looks pretty good to me I mean, I'm not a designer, it's not very beautiful but you know first name and you put in your first name, last name, you put in your last name, put in a password and then hit submit.

[00:00:37]
So the problem again, if we go ahead and we open up the screen reader again. All right, So here's voiceover [INAUDIBLE] And we start tabbing through you can see what it's reading is just edit text blank, edit text blank, secure edit text blank. So, I have no idea what it is that I'm supposed to be putting into these form fields and it becomes very difficult if not impossible to use.

[00:01:02]
And so instead of using these paragraph tags, HTML provides these label tags and these will fix the problem immediately for us. So, you can give your inputs and ID and then you can use label and has this four attribute and you put in the same ID. And so this form will look Identical first name, last name, password.

[00:01:22]
But again, if we were to go ahead and use the screen reader now, it will [LAUGH] I guess it didn't get actually. If we go ahead and use the screen reader now, It will actually go through and read out the main tab through here. So, this is the one that's visual only edit text blank, edit text blank, edit text blank and then we go to these ones with the labels.

[00:01:43]
And now the labels are saying first name, edit text, last name, edit text, password, secure edit text. And so you can see just moving from those paragraph tabs to the labels fixes this immediately. Labels also are kinda cool because they can be used explicitly, which is this for attribute or they can be used implicitly, which is to say they can wrap an input and they'll automatically be assigned to it.

[00:02:08]
So, you can have like an empty label tag with any text you want in here and then the input inside, so these are totally equivalent as far as how they'll read for screen readers, so whatever your style preferences there. So, label tags perfect for almost everything. There's one exception which is that, there are only certain elements that can be labelled, so like buttons, inputs, meters, outputs, all these things.

[00:02:34]
If you ever run into a situation where you need something labeled that is not one of these elements for any reason, this is where Arial comes in. And so, I have a whole section on Arial later but just for now, know that Aria has this Aria label property which can be added to any element, div, span paragraph, images, anything and this will give it a label div aria label and then the screen reader will read out that label when that has focus.

[00:03:02]
So for the most part, labels are perfect, they do kinda everything you would need to in certain situations like complex apps or whatever. If you end up with a div or h1 or you have something like that needs a label, always use Arial label for that. Should a label exist but be visually hidden if there's no reason to see it?

[00:03:19]
Absolutely. And this comes up a lot with designs, right? Like a form with placeholders in them and no labels on them. But you know for accessibility that you need a label, so that a screen reader reads it, absolutely, that's the way to do it. Add labels, give them a class of visually hidden which are gonna look at in the next section, and then it'll be hidden from the screen but they'll show up on screen later.

[00:03:39]
That's a great question.
>> Also, if the input is a child of the label, is four still required?
>> It is not, no if the input is a child of the label, you don't need four at all. So, you can just do these blank labels, any text and then this doesn't actually even need the ID, it could just be an input type text at this point.

[00:03:59]
So yeah, no, for if you wrap it, if you don't wrap it then you wanna do the four. When are Arial labelled elements read by screen readers? So that is tricky because in our div example, this is great, it has a label except divs aren't read by screen readers, right, because they are not something read out loud.

[00:04:15]
So, if in these situations it would really be and we'll get into it in the next section. But if you take an element and you add the ability for it to be focused, like for a good example would be like, have you ever seen those sites where you can link directly to one of the h2 or h3, so you can like a blog posts but a certain section of the blog posts that you want to link to?

[00:04:36]
So they do that by allowing you to focus on the h2 h3, h4, whatever, which normally you aren't able to focus those. So in that sense, when it's focusable, which we'll get into the tab index, that's when you would add a label to it, otherwise you're right, it won't read the label because you can't ever focus that item.

[00:04:53]
Cool, so yeah, this is something that we've talked about a little bit already. Sometimes you just need to communicate with a screen reader and you don't want it to show up on the actual website. And so the way that we do that there's a number of ways you can do it in CSS but the idea is that you add a visually hidden class.

[00:05:09]
And so, this one just absolutely position something and then sends it off the screen is simply all that it does. I think I got this one from Twitter Bootstrap. But there's a number of ways you can do it but I would recommend in your code base, just adding a shared class for visually hidden and then putting it anywhere.

[00:05:26]
So an anecdote that I like here, and I mentioned it a little bit earlier. So when I was at Twitter, we came up with all these great keyboard shortcuts like two key character shortcuts for like, make a new tweet or reply or follow a user or search something like that.

[00:05:40]
And then we're like well, how do we surface all these great shortcuts, right? Like, it's cool that we have them, but how do we let users know? And so our accessibility lead, he came up with this really clever thing where he took a div and he put some text in it and said, hey, we have all these great keyboard shortcuts, if you wanna check them out, hit the question mark button.

[00:06:02]
And he added a class of visually hidden to that div and then he used JavaScript to prepend that div to the entire document on twitter.com. So, when you very first hit twitter.com, the first thing that a screen reader would see was this thing. So, it had the experience of the screen reader was like being communicated with, right, like you would load twitter.com, you would never see this thing.

[00:06:20]
But if you loaded it with a screen reader before it even read like the home nav, it would say, hey, if you're using a screen reader, check out this thing, hit question mark, and we'll show you all these cool keyboard shortcuts. So, there's some kind of neat ways that you can think about making some content making a visually hidden, sticking in at the beginning of the document and then you have a way of communicating directly with screen reader users and non screen reader users will never see it