 Hey there, folks. What's up? It's Rob. Welcome back to The AliCast Show. So I know that today I promised I was going to do a video on NVDA, and I'm still working on that video actually. My PC laptop is in the mail. But before doing that, since we've got a little break right here, I thought it'd be cool to talk about this idea of semantics and really why semantics matter in accessibility and how they affect screen readers. And so in order to understand why semantics are important, it's first good to understand this idea of affordances. So follow me over here in my laptop. I've got some slides I want to show you. Basically, an affordance, when we talk about that, what we're saying is an affordance is something that offers a person an opportunity to perform an action with some sort of physical object. And so a good example that we often use is a teapot. So a teapot is kind of cool because just based on its physical design, it kind of instructs you in the ways that you should interact with it. So a teapot has a handle. And because you've seen other things with handles, you kind of know that you could go up to a teapot and pick it up by that handle. And then it's also got a spout. And that kind of indicates that you would tilt it and things would come out of the spout. So both the handle and the spout are affordances. No one has to explain to you how a teapot works. You can just sort of intuit it based on its design. And so when we create our own graphical user interfaces, things like buttons and controls and things like that, we try and add back in those affordances as well. But we do it visually. So for instance, a affordance in your website for a button, you might make it look kind of 3D, right? You might give it a little drop shadow. You might make it look like a real world button to indicate, hey, this is a button. This is something you should go up and press. And so the way that we do that is through our markup. And the affordances that we're sort of expressing through our element are often referred to as expressing the element's semantics. So I'll give you an example here. I've got a little bit of code here. I've got a label element with a select tag inside of it. And what it's going to do is it's going to generate a visual UI for my user, right? That has kind of those built-in visual affordances for a dropdown. But it's also going to generate a sort of separate, sort of more semantic UI that's something like a screen reader could then turn into an audio UI for a user who is unable to see the screen. And so generally speaking, for every element that you create in HTML, there's a few semantic properties that it's going to have. An element is going to have a roll. And so in the case of a select element, its roll is actually a pop-up button. And the roll kind of defines how someone might use this control. An element is also going to have a semantic name. And when I say name, I know there's a built-in name attribute in HTML that you use for submitting things to forms. But we're not quite talking about that sort of name instead, think of the name as kind of more like the label for the control, if you will. So in this case, I actually have an actual label element that is associated with the select tag. So the name that it generates is preferred seat type. An element could also have a state. So a select element, for instance, is going to have a state of expanded or collapsed. Not every element has a state, but some do. So that's additional semantic information. And an element can also have a value. So again, not all elements have values. But again, in the case of a select element, here it's got a value of no preference for whatever is our currently selected item. A text input field could also have a value for whatever text you've typed on screen. And so what happens when you are adding all these semantic HTML elements to your page is the browser is going to do two things. It's going to generate a visible graphical user interface. And it's also going to take all that semantic information and create what's called the accessibility tree. So from your HTML, you're really generating two things. That accessibility tree then gets handed off to assistive technology, like a screen reader, like voiceover or like in VDA. That screen reader, that assistive technology, then takes the information that it gets from the tree, and it generates a spoken UI for the user. And then if the user takes some action, it can actually reflect that back through assistive technology and update the accessibility tree. Now, some elements have implicit semantics. So for instance, when we talk about an input password field or the native button element or a select element, these will have implicit semantics. They're actually built into the tags themselves, and the browser knows how to understand them. So an input password field is going to, when you land on it with a screen reader, it'll announce itself as secure edit text in something like voiceover. So that's the implicit semantic that that element has. But not all elements have super useful semantics. So for instance, if you have something like a div that you're trying to turn into a button, well, a div semantically is just a generic grouping element. And there's nothing about it that says it's interactive or anything like that. And so when a screen reader lands on that element, it's actually just going to say that it's a group. So it's not going to tell somebody that's a button or anything like that. And so when people talk about semantics and why they're so important for accessibility, this is really why, because the semantics let us express the affordances that the elements offer. And then that instructs a screen reader how to announce that to the user and say, hey, this is a button that you can interact with. Or maybe this is just a generic grouping thing. And maybe you don't need to do anything with it. So if you're running your own code, then how do you figure out what your semantics are? How do you check that you're doing things the right way? And there's really like two options here. The first is you can go through and you can use your site using a screen reader. And that's going to help you verify that you've created a good semantically rich experience. But it can also be sort of tedious inspecting everything on the page with a screen reader. And sometimes you might want a useful tool to help you out in that process. And so recently what we've been working on on the Chrome team, my teammate, Alice Boxhall, has been pioneering this work, is a set of accessibility tools that are actually built into the Chrome developer tools in the browser itself. So I want to show those off. They're still in an experimental phase, but I want to show them off just so you can maybe start messing around with these in some of your own projects. So follow me over here. And this is sort of like a form that Alice and I built for one of our courses on accessibility. It's sort of a typical form, something you might use to like book a ticket for a website, or for an airplane, or something like that. And what I want to do here is the first thing I need to do, because this example actually only works with the keyboard. We wanted to make sure people couldn't cheat and use their mouse or anything. We've got this click stealer thing. So I'm actually going to delete this so we can actually use our mouse on this form. And you can see there's a bunch of native controls here. I've got radio buttons and input fields and dropdowns, et cetera. And so what I want to do is inspect these elements using the new accessibility DevTools. So because this is an experiment, I'm going to go over to my settings for my DevTools. I'll go to the Experiments option. And then right here we've got Accessibility Inspection, which I'm going to check. Now again, word of warning, it says it right here too. These are experimental, so they might break, they might not be bug-free, they might not perform always as you would expect. So keep that in mind if you're using these tools and it seems quirky at times. These are still work in progress. But I'm going to turn this on because it's pretty cool to play around with. And then I've got to close my DevTools and open them again just to restart them. And now I'm going to inspect. I've got the select field down here. I'll go and inspect that. And in my Elements Inspector, over here where you've got styles and DOM breakpoints, now there's a new tab called Accessibility. So I click on that and check out all this information that I'm now getting for this select element. So I can see its role, for instance. Remember when I went through and I said every element has a role, name, value, and state? Well, here we're going to get all of that information. So I can see that the role for the select element is ComboBox. I can see the name that would be spoken by something like a screen reader is Preferred Seat Type. And so that's based on this current value here. And you can actually see how these things are generated. You can see if they were generated by ARIA labels or if there's an associated label or something like that, which is really cool. You can see the state for the element. So I can see that it's currently expanded false. It's not open at the moment. And I can also see the value for it, which right now is set to just no preference. So if I go in, I switch to ILCT. One of the quirks right now is that you've got to inspect another element. And you can go back and inspect this one. Now we'll see that the value here has changed to ILCT as well. So now I know that the semantics for this element are good. And I can expect that when the accessibility tree is generated by the browser, this is the information that it will pass along. So again, if you're building an application and you're working on some custom controls and you just want to verify that they do the things that you expect or you would like for them to announce in the accessibility tree, this can be a really, really useful tool. And again, you can check out some other elements here. An input tag and see its current check value, right? It's true. Go in and inspect the elements that are labeled by label elements and see if that affects the name that is actually announced by a screen reader because that can be one of those things that's sort of tedious to check yourself. So a lot of really useful stuff that you get out of this one little accessibility inspector. Now I'm going to cover this some more in some future episodes. We'll probably just start using it as a matter of course as we're building accessible components. But I wanted you to see this. And I also wanted you to understand semantics a little bit better as we continue talking about screen readers. So thank you so much for watching today. If you have questions, you can always leave them for me in the comments below. Or you can reach me on a social network of your choosing. I'm at sign rob.son or plus rob.son on the G pluses. As always, thank you so much for watching. And I'll see you next time.