Semantic HTML

[00:00:00]
>> Speaker 1: So we'll move on to the next subsection of Screen Readers, which is semantic HTML. How many people have heard this term before? I feel like it gets thrown around quite a bit, but it's a little bit fuzzy. So we're gonna try to kind of describe it and explain specifically why it's important and what it means.

[00:00:14]
Because I don't have strong feelings about using all the great new HTML5 elements, I have strong feelings about providing really good experiences. And so we're gonna kind of focus on what actually is going to be really helpful for people. So some elements that we have in HTML have semantic meaning but no special functionality, right?

[00:00:33]
So they don't do anything different, but they do have semantic meaning. And examples here are like header, footer and aside. If you have div's or if you have these, they don't do anything differently, but they present differently. And so these are important not because of some kind of interaction, but because of using assistive technology like screen readers.

[00:00:51]
They provide this really nice content that the screen reader can help with, where it can say, hey, there's a new section here that's got this in it, as opposed to just reading div after div. So these are not only nice because they have meaning for other developers, but they're nice for screen readers because the screen reader can help the user understand that they're in the header, that they're in the footer, that they're in a section.

[00:01:14]
Other elements provide a ton of built in functionality. So this was something that kind of blew my mind when I started working with accessibility is I always thought about HTML and then I thought about HTML in this abstract concept of spans are inline and div's are block or things like this.

[00:01:31]
I know they render a little bit differently, but ultimately they're just these tags. But then when you think about it, there's some HTML elements that provide a ton of functionality to them. We have all these new input type, email and it controls what keyboard comes up and it does validation and it does, when you really think about it, if you were at a job and that job had tied you to some super old browser, like some 12 year old browser or something like that.

[00:01:57]
And then your task was to implement a dropdown button or something like that, or an email validated input select, there's a lot of work there. You'd have to write a substantial amount of JavaScript and there's keyboard shortcuts and the way it behaves with the escape button and is it tabable and where does it come in in the tab order and turn on a screen reader and how does it read?

[00:02:19]
How do you tell the user that there's a list here and how many items are in the list. And you can start thinking about the amount of JavaScript you would write for this, let alone a date picker or a color picker, which could get just enormous, so it's a lot.

[00:02:29]
So we've got these set of semantic elements which help the screen reader but don't add functionality. And then we've got these highly functional elements here and, and one of the big traps that people fall into is, and I imagine a lot of us have seen this, is that UI or design will want, will not like the look of one of these elements.

[00:02:50]
And so they will task us as developers with building our own checkbox or our own button or something like that that looks the way that we want it to. And it can be very easy to forget all the important stuff that kind of gets us there. For semantic markup to be Level A compliant, we need to use semantic markup, like lists, to designate things, H1s, to designate our headers, our regions.

[00:03:14]
This is stuff that we often know intuitively as developers who do a lot of HTML, but it's kind of cool to see written down. Tables should only be used for tabular data. Text labels should accompany form elements, basically using the tools available to you. And we'll get into it with a screen reader exercise that if you label your form elements, it can be very difficult to fill out a form.

[00:03:36]
And then another thing is this reading and navigation order must be logical and intuitive. So again, I think things that a lot of us do as engineers, starting with an H1 and then the subsections are H2s, things like that. But really understanding the importance of doing it for accessibility because when you have the screen reader on and you say read me all the top level items, it's really only going to read the things that are in those header tags.

[00:03:57]
It's not going to read something that you've used CSS to make large and bold, but doesn't have an appropriate tag to it. Form labels in general can be really confusing, forms in general can be very confusing for screen reader users. There's lots of different ways which we'll get into to label forms and choosing whichever one you want is completely fine.

[00:04:16]
But the thing that is very bad is if you don't have any type of label, then you will literally just be giving screen reader users this input blank as they're supposed to fill out their first name, their last name, their credit card information, things like that. So it can be really almost impossible to use without some kind of labeling.

[00:04:33]
An anti pattern, and I see this quite often is using visual labels so a sighted user can see the context. We all do this at the very minimum that will put some kind of visual label, first name text, last name text. Because if we didn't have that, then sighted users wouldn't be able to fill out the form either.

[00:04:51]
But these aren't the correct tags, this isn't semantic HTML. And it is really important for screen reader users because as we visually can see, these are associated with each other. A screen reader user will hit tab and they'll go directly to the input box, skipping over that paragraph tag.

[00:05:09]
And all their experience will be is input text blank, input text blank, input password blank. That's all they'll get, so they'll have no idea that they want first name, last name or first name email. They'll have no concept there. And so this is all that they'll see. So one way that we can do this better is we can use HTML labels.

[00:05:26]
So this is the kind of oldest way that we've had to label these things. You can have your inputs with an ID and then your labels with a for attribute. And that will tie those things together, right? And so they will have first name text blank as opposed to input text blank.

[00:05:42]
This can provide some issues because now maybe you don't like the way that the label looks or maybe you already have some design stuff going on. So you've got great ways to deal with that as well, but I wanted to talk about a few other ways to label these things.

[00:05:55]
So yeah, now it'll read first name edit text blank as opposed to before it was reading edittext blank. So much, much better, all right, cool. So that's HTML labels, and then we have another option that we can use which is implicit HTML labels. So instead of using this label for and the ID concept, we can kind of do the same thing by wrapping the input with or without an ID inside label tags.

[00:06:17]
So you can use a self closing label tag like this, or you can use a closed label tag like this and match their IDs with their fours. Or you can use a label tag like this and just put the ID or the input inside of them. So those will both kind of accomplish the same thing here.

[00:06:34]
So limitations with the label tag. So the label tag only works with what the HTML spec defines as labelable elements. So that's like button, input, keygen, meter output, progress, select, text area. So if you're building a more robust application that doesn't use one of these labelable elements, you can kind of get yourself into some trouble here.

[00:06:52]
And again, this is where things like the ARIA spec come into play. So the ARIA spec gives you this ARIA label property and you can apply that to any element you want. So it's kind of an either or choice that you have, you could just use ARIA labels, they'll work the same way with screen readers, or you can use the label element for HTML labelable.

[00:07:11]
And if you're ever working on something like, I don't know, like a video game or a really robust screen, and you just need to label something that is not labelable, you can do that simply with the ARIA label property.
>> Speaker 1: Yeah, talking about the ARIA label and the label itself, which one has precedence?

[00:07:28]
>> Speaker 1: Yeah, that's a great question. So if you were to have an element like this, this label 4, and then on the input you were to put the ARIA labeled by the ARIA specification bit will take precedent over the HTML specific specification. So if you had label for first and this said first name, and then you had input ARIA labeled by my first name or your first name, it would just read the your first name and it wouldn't read the label itself.

[00:07:53]
These ARIA label elements, and they work the same way, you just pass in a string and then the screen reader will read that before it reads the actual content of the element.