[MUSIC PLAYING] ROB DODSON: Hey there, folks. What's up? It's Rob. Welcome back to
the A11ycasts 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 to my laptop. I've got some slides
I want to show you. And 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, like, 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, right? You can just sort of intuit
it based on its design. And so when we create our
own sort of 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, an 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 this is
going to do is it's going to generate a
visual UI for my user that has kind of those
built-in visual affordances for a drop-down. But it's also going to generate
a sort of separate sort of more semantic UI that 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 role. And so in the case
of a select element, its role is actually
a pop-up button. And the role kind
of defines, like, 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 this 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. You know, a text
input field could also have a value for whatever text
you've typed on the 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. And that accessibility
tree then gets handed off to assistive technology,
like a screen reader, like voiceover, or like NVDA. 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. So 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 will
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 you know, 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 it'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 writing
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
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 just 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 drop-downs, et cetera. And so what I want
to do is inspect these elements using the
new accessibility dev tools. So because this
is an experiment, I'm going to go over to my
settings for my dev tools. 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, you know, quirky at times. These are still a
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 dev tools and open them again
just to restart them. And now I'm going to inspect--
I've got this Select field down here. I'll go 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 could see that the
role for the Select element is combo box. 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 was 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 and I switch to
"Aisle seat," one of the quirks right now is that you've got
to inspect another element, and then you can go back
and inspect this one. And now we'll see that
the value here has changed to "Aisle seat" 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'll 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 you know, again, you can
check out some other elements here. I've got an input tag. You can see its
current check value. It's true. You 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 @RobDodson, or
+RobDodson on the G+. As always, thank you
so much for watching, and I'll see you next time. [MUSIC PLAYING]
Not my content.
It can also help with SEO and full-text search.
Fantastic, I've been trying to find out a way to easily test how accessible my websites are. I wondered how long before Google started baking accessibility tools into the dev tools.
I love the idea of the accessibility tools. Obviously it's not as powerful as going through a smoketest with a screen reader, but it's a happy middle ground between that and reading the code to understand your gaps.
That said, I can't believe there isn't a live update of the accessibility panel yet. You have to inspect another element, then reinspect the one you were just on. Get your shit together google.