Accessibility is My Favorite Part of the Platform – Google I/O 2016
All right. That is my cue. Thank you all for
coming out this morning. I want to wish you, first of
all, a happy Global Accessibility Awareness Day. It just so happens that May
19th is the official Global Accessibility Awareness Day. So very cool of you all
to be here for that. So yeah, if you’re
tweeting during the talk or whatever use
the GAAD hashtag. That would be very awesome. Also, before I
get into things, I do want to point
out, because I know this is being
recorded on YouTube and sometimes folks
don’t always make it to the end of a long video,
that everything that we’re talking about
today is also going to be part of a Udacity course. So you can go check
this out as well. So all the topics I’m
covering today, in brief, will be covered in that course
over a multi-week period, doing a very deep dive
on a lot of these things, and giving a lot more practical
advice on building accessibility into
your applications. So definitely go check that out. Now I want to start
by just telling a story. So about a month ago, it was
April, and, like many of you, I was doing my taxes.
And it was awesome, right? Didn’t you guys love it? It was great, right? No. It sucked. So doing your taxes is like
a really, in the US at least, it’s a frustrating,
horrible experience. Because you have these amazing
tax forms– I don’t know, how many of you have
ever actually filled out an actual tax form? Have you ever had to do that? Yeah. Like you kind of go off the
road with your tax software and suddenly you end up having
to fill out a real form. And these tax
forms are horrible. Because there’s no
real hierarchy, right? There’s no, like, I don’t
know if I’m going off-road or if I’m in some
place I shouldn’t be or if I’m messing up
or anything like that. And I kind of think of the tax
form as like my interface to the IRS, right?
OK. And so my goal is very simple,
right, I want to pay my taxes. But their interface is
like totally blocking me. And eventually, if you’ve
gone through this process, you reach this point where
you’re just like, oh my god. I just want to
give you my money. Like I don’t– I don’t
want to, you know– I want you to think
about that feeling. OK. Because it sounds
like many of you have felt that feeling before. It doesn’t necessarily
have to be taxed, but it could be trying
to book a hotel room or something and the
website’s just not doing it for you, something like that.
But hold on to that
the feeling of frustration that you have felt before. OK. Now, for many of us, that’s
just an occasional thing, right, it occurs during tax time
or something like that. But for a lot of our
users, especially anybody with a
disability or impairment, this can be a recurring
theme as they’re trying to interact
with websites that just haven’t been programmed
with accessibility in mind. So for that reason,
I, personally, really like working
on accessibility, because I like feeling like
I’m actively removing some of that anxiety and
frustration from the universe and people’s lives. To me, that is super,
super motivating. But there are a bunch
of other reasons why I think accessibility
is extremely important, and everyone should
by prioritizing it in their applications.
Now, of course, there are
obvious legal reasons and potential missed
sales opportunities, those are very important. But I don’t think
that that is what motivates a lot of developers. So instead, I think there
are these three other things, which, to me, I think
are super exciting when I think about accessibility work. The first is just that this
is a big, greenfield space. And what I mean by that is
that accessibility is under-served in the platform,
meaning there’s a lot of room for developers
to come in and build cool new tools and cool new
libraries to write blog posts and get their name out there as
thought leaders in this space. So if you like working
on interesting, technical problems, accessibility is
one of those areas where you can sink
your teeth into it and do some awesome work.
Another is just that
accessibility work benefits everyone. The chances are very
good that pretty much all of us in this room are
going to experience some form of disability in our
lifetimes, if not right now, then as we age, as our
eyesight degrades, our hearing degrades, our motor impairment
degrades, all of these things. So all of us are
going to want to use our computers and our
phones when that happens.
And we’re going to be happy
that accessibility work has been done on those platforms
when we reach that point. Also, disability
can be situational. It can be temporary, right? I’m sure many of you were
outside the other day perhaps trying to use your
phone in very bright sunlight, and it can be very
difficult to read, maybe you needed a little
additional contrast on the screen or
something like that.
So disability can affect us
in temporary ways as well. Finally, and for me this
is what is most important and gets back to that earlier
point, when my users are using my application, I want them
to feel confident in the actions that
they are taking. So filing your taxes, booking
a plane ticket, and booking a hotel room, are not things that
you want to get wrong, right? And so fundamentally, I just
think that good accessibility equals good user experience. Working on
accessibility is going to expose things
in your application that you have overlooked. Because it’s going to force
you to step outside of yourself and work with your app from
a different perspective.
And when you do
that, you’re just going to end up with a better,
the more polished product that is ultimately usable
for more users. And so when I tell this
to a lot of developers, they’re like, yeah,
dude. I 100% agree. But they find working on
accessibility to be difficult. As web developers,
I think many of us have– we know bits and pieces
of how accessibility works, right, but in general, we have
this Swiss cheese understanding of the platform
as a whole and how it all kind of fits together.
So as web developers, we
need a more solid foundation in our understanding
of accessibility. And once you remove that
mystery, then working on accessibility becomes much
more fun, much more exciting, because you don’t feel
like you’re guessing, or you’re just
making stuff up, you know that you’re
headed in the right direction. So that’s what I want
to talk about today. I want to talk about how we set
a good foundation for ourselves as web developers
with accessibility. And I also want to cover some
practical advice, some stuff that you can use every day
in your applications right now to start improving
their accessibility of them. So I’m going to split this
talk into three sections. The first is just
looking at the diversity of users that are
out there, looking at the accessibility
topics that affect them.
And then I want to move
on to the two big areas that I see many web
developers struggling with, which are focus and
proper semantics. But I want to start just by
understanding who our users are and the range of accessibility
topics that affect them. Now I’m going to focus on people
with permanent disabilities in the section. But again, I want to reiterate
that accessibility does affect all of us. If you are trying to use
your phone one-handed while you are holding
a screaming baby, then you are temporarily
or situationally impaired.
And it
makes no difference if you’re holding
something in one arm and trying to use
your phone one-handed or if you have a
motor impairment and are paralyzed on one
side of your body, again, it nets out to be the same thing. So I just want to get
some stats out there because I feel like these
are pretty interesting. According to the World Health
In organizations, about 15% of the world’s population lives
with some form of disability. And to put that
into perspective, we’re talking about
around 1 billion people across the globe, right? So a not an insignificant size. And we can roughly split this
into about four categories. Those disabilities
and impairments affect the visual senses,
those affecting motor and dexterity, auditory
senses, and cognitive senses. I want to go through each
of these individually, starting with visual impairment. So visual impairment
spans a broad range.
You can have users who are
completely blind to those who have limited or low vision. Users who have no vision may
be using a screen reader device to access the page. So this is TalkBack on Android. Or they might be using a
similar Braille reading device to access the
content of the page. Users with limited
or low vision may be using screen magnification,
though they might also choose to use a screen reader. Or they might use a
high contrast mode in the browser to switch
the background color and increase the legibility
of the text on the screen. Users with motor
impairment, this could span a group of folks
who maybe have even just like a wrist injury, a
broken arm, repetitive stress injury, something
like carpal tunnel, and they prefer not to
use a mouse, all the way to folks who might
have physical paralysis or limited range of motion
with some part of their body. So these users
may use head or eye tracking to navigate the page. This is an example of a
program called Dasher, which combines a
head-tracking camera to allow someone to type.
These users may also use their
keyboard primarily to navigate. They may use a discrete switch
device, as you’re seeing here. Or they may also use voice
control to navigate the page. For auditory
impairment, this group ranges from those who are
completely deaf to those who are hard of hearing. So I’m personally in the
hard-of-hearing camp. I’m about 90% deaf
on my left-hand side. And so for this
group of users, it’s important to make
sure that we’re not relying solely on sound
to convey information in our applications.
So we’ve got captioning. We’ve got transcripts. If we’re playing sound in the
background that was providing some sort of visual
indicator to let the person know that that is happening. And finally, for
cognitive impairment, this is a really broad range
encompassing everything from ADHD, dyslexia, and autism,
just to name a few items. And for these users,
the accommodations are extremely diverse. But we do find some overlap
with things– with things like zoom functionality
and making it easier to read the page and
minimizing distraction.
So this is an example
of a Chrome extension for someone with dyslexia. And what it does is it applies
color gradients to the page to aid in the reading order
and make sure that they can read linearly. So these are the
four major categories that we need to
keep in mind when we’re thinking
about accessibility in our applications. But because accessibility
is so broad and the users it’s just like so diverse,
it’s really helpful to have a guide to lead
us on our journey here. And we find that in the form of
the Web Content Accessibility Guidelines 2.0, or WCAG 2.0. So this is a set
of best practices that have been put together
by accessibility experts to try and
define what it means for something to be accessible.
And the WCAG is
extremely comprehensive, but it can also be overwhelming. So it’s a very
large spec document. And for a lot of developers,
they open that up and they’re just like, uh. And their face melts. And they’re like, no,
no, don’t want it, right? So to help mitigate
this, the WebAIM group has distilled
the WCAG down into this easy-to-follow
checklist called the WebAIM checklist for WCAG 2.0. So the nice thing about
this is it is specifically geared towards web content. And now if you were watching
that previous section you were sort of
wondering like, wow, how am I going to cater to that
diverse range of users and all these different
assistive technologies? I think a
great starting point is to just nail this checklist. And what I think is a
good personal strategy is to figure out what the
primary user journeys are in your application. If creating a new account is
an important journey that you want every
user to be able to complete, then go through all of
the steps of that process and make sure that you can
check off the relevant checklist items so you can ensure that
that user has an accessible journey that they can complete.
And then do that
over and over again for the primary actions
in your application. And you want to
incorporate this work into not just the
development phase, but also, obviously, the design
phase, the planning phase, make sure that all
of your stakeholders are brought into this. So with that checklist
in hand, we’re now ready to start
exploring some of the nuts and bolts functionality
that we’re going to need to add
to our application to make sure we can
build those experiences. And I want to start
by looking at Focus. And like
what does it mean for something to have Focus? When we talk about Focus
in the platform, really, what are we getting at there? And Focus is one of these
underlying bedrock key things in inaccessibility.
And in a nutshell, what
we’re talking about is Focus just helps
determine where keyboard events go on the page. OK. That is the main takeaway here. Focus determines where your
keyboard events go on the page. So if I go over and I
click on this text field. I get this indicator to let
me know that it’s focused. And as I’m typing
keys on my keyboard, right, all those key events are
directed right at that field. And then it knows to display
the keys that I’ve typed. Now some users drive
their computers entirely with the keyboard or
with some other discrete input device like a switch control
as I showed earlier.
And so for these users,
it’s their primary means of reaching
everything on screen. And we must have a good experience
with Focus and Tab that are in our application. Now to move Focus
around the screen, if you’re using a
keyboard, you can use either Tab or Shift-Tab. And the ordering that the items
in your application get focused on is known as, creatively
enough, the tab order.
Now the tab order is based
on the position of your element in the DOM, right, so
how you write your HTML. And this is great
because it means you don’t have to
go in and explicitly tell the platform,
OK, focus this thing, and then focus this thing, and
then fix this thing, right? You don’t have to
programmatically do that. It just does it for you. It is just inferred based on the
order in which you wrote your HTML. But right away, we get
to a potential gotcha. Because the DOM order
is so important, it’s possible though that we
could reposition our elements on screen using
something like CSS without changing the DOM order. And then that can lead
to all sorts of kind of weirdness for our users. So I’ll show you an example. Here I’ve got a little bit
of HTML, just a few buttons. And then you can see
the output over there on the right-hand side. OK. So I’m going to just tab
through this quickly. So I hit Tab, right,
and focus on my first button. I hit Tab again, focus
the second, Tab again, focuses the last, right.
So far, so good. No surprises. So now I’m going to add
a little bit of CSS. I’m going to change
that first button so it has a little inline style
so it’s floated to the right. Now visually, I have updated
the layout and appearance of those buttons
on the screen now. But I have not at all affected
their position in the DOM. So let’s look at what happens
when I tab through this now. OK. Well, we start at the end. And then go back
to the beginning. And then we go to the middle. That’s kind of weird. Here’s an example of
a site that I built. And you can see this in a
more real-world use case. So I start tabbing through. It starts way over there. Now we’re going back
through the navigation.
It’s going to jump to
the bottom of the page because I have something
positioned. It’s going to jump back
up to the page, right? So you’re kind of like bouncing
around the page like a pinball. And I see this on
websites all the time. Like go to a website today and
just try and tab through it. And you’ll see that Focus
jumps around, sometimes it just disappears for a while. And it’s like, I don’t
know where it went. And then it comes back, right? So the main thing
here is just to make sure if you’re changing the
visual position of something that you’re also updating
its position in the DOM. Don’t fight the platform here. It’s trying to help
you out actually. It’s trying to infer
your tab order for you so you don’t have to
write a bunch of code to tell it what order you
want things to focus in. But that means that you’ve
got to play along with that.
And if you want to move
something visually later in the document, move it
later in the DOM as well. And as a best practice make
sure that you’re just tabbing through your site occasionally. If you haven’t done it,
if you work on a big site and you haven’t tabbed
through it recently or ever, maybe sit down and do that. It can be a feeling
hurting experience. But it is an important useful
thing that everyone does. OK. So we talked a little bit
about what can be focused on. I want to move on now to just
talking about really like– or we talked about
what focus means. I won’t talk about
what can be focused on and really what
should be focused on. So many of the native elements
that you’re familiar with are all implicitly focusable,
meaning any sort of control that a user could interact
with or provide some input to, so like button input, and select,
these are all implicitly focusable, meaning they
get naturally inserted in the tab order.
So I don’t have to do any work. The user can just
press the Tab key and it’ll focus
them, which is great. But not all elements
are focusable. So, for instance, this header,
this paragraph of text, this image of this cat,
these are not focusable. These are not
implicitly inserted in the tab order or
anything like that. And because there’s no need
to focus on something if a user cannot interact
with it in any way. So now this– something
that comes up a lot is people get worried that a
user with a visual impairment might miss an important heading
or an important piece of text or something like that,
so they make it focusable.
But, again, there’s
no need to do that. Those users have tools
like screen readers, and the screen readers’ sole
job is to read headings, it’s to read text,
and make sure that the user gets
all that content. So again, you don’t need
to make something focusable if it’s not interactive. And this now presents
another interesting gotcha that I see a lot. Because generic elements are
not focusable by default, then we can end up in
this weird situation where here I’ve got
some more buttons. And I’m going to replace
that center button with this very
fancy-looking button that I’ve created using a div.
But again, this is a
generic element, right? There’s nothing implicitly
focusable about it. And so as the user
tabbing through the page, it focuses on the first item. You tab again and we just
jumped right past that button. So if that button was your
“give me money button” or “sign up for a new
account” button, then a user who is using a keyboard
or a switch device, they’re effectively
cut off from that because that item is not
inserted in the tab order. So an easy way to fix this is just
to use the proper element, right? Use a button tag here. We’re going to get implicitly
inserted in the tab order. You can style button
elements very easily. And now as the user is tabbing
through this experience, they’ll just land
on that button, and we don’t have to do
a bunch of extra work.
An interesting bonus of
using the button element is if you give a button
element a one-click handler, and a user lands
on it and presses either Enter or Space Bar, it
will run the one-click handler. If however, you have a DIV
that you’ve made focusable– and I’ll explain how to do
that a little bit later– but if you have a DIV and you
give it a one-click handler, and the user focuses it, and
If they press Enter or Space, nothing’s going to happen. Because there’s a little
bit of browser magic that actually makes sure
that the oneclick gets to run with your button. So that means
you’re going to have to add the key down
handler to your DIV button.
It means you’re going to have
to check which key was pressed when they hit the button. There’s no real upside to it. So again, don’t fight
the platform here. The platform is
trying to give you some accessibility for free. That’s why these elements exist. That’s why they’re implicitly
inserted in the tab order, right? So use the native
elements whenever you can. But I realize there are
times when there’s just not a native analog to what
you’re trying to build, or maybe the native
element is just too difficult and
frustrating to style. So there will be times when you
need to go off-road and build your custom components.
And when you’re doing that,
it’s important to make sure that you’re adding back
in that keyboard support for those users who rely on it. Now to do this, we can use
the tab index attribute. And the tab index
attribute just helps us configure the
focus ability of our elements. And it takes a range of values. So tab index of 0 means that
the element will be inserted into the natural tab order. And it also means
that the element will be programmatically
focusable if we call it its focus method. So here’s another one
of these fancy buttons that no one can
interact with just yet. So give it a tab index of 0. Now, the user can very
easily just press the Tab key and focus it. OK. So far, so good. A tab index of negative 1 means
that the element will not be in the natural tab order.
So the user can’t Tab
or Shift-Tab to it. But we can still
programmatically focus it by calling it its focus method. And this can be useful if you
need to temporarily disable an interactive control, or for a
technique called “roving focus” or “roving tab index.” So if you’re building a
very complex component, this technique can
be super useful. So let’s say I have
this list here, and maybe I have like
100 items in this list. And I wouldn’t want
my user to have to tab through every single
one of those items just to move past the list. So I want to treat the entire
list as one big tab stop. So they can just land on it. They can use the up
and down arrow keys if they want to
interact with them. But they should be able to
tab out of it if they need to. And so to do this, I’m going
to set the tab index to negative 1 on all the elements
except for the one that I think is currently active
or currently selected.
And then, when the user
does focus on this item, they’re going to land right
on the active one. And if they press the down
arrow key, I can listen for that and say, all right. Now I’m going to move
my tab index down. So I’ll set the next item to
tab index 0, the previous one to tab index negative 1, and
I’ll call it its focus method. So this way if the user
tabs out of the control, they tab back in, they’re going
to land right on that last item that they interacted with. But if they need to, again,
they can just quickly tab out and they don’t have to tab
through every single item on our huge list. So this is a, really,
really useful technique if you’re building
complex components. Lastly, you can have a tab index
value greater than 0.
You can have a tab index value
of like 5, 10, whatever. And this is going
to take that element and jump in front
of everything else that’s in the natural tab order. So, in general, this is
considered an anti-pattern because it’s very easy to tie
yourself in knots with this and end up with,
again, crazy focus jumping all around the page. It’s also a little
strange for someone who’s using a screen reader. A screen reader user
tends to navigate the DOM in kind of a linear fashion. And you’ve got
these elements that don’t comply with
that at all and are trying to exist in
different tab orders.
So I wanted to put this
here for completeness so that you know the tab index
greater than 0 is a thing. But in general, it’s
an anti-pattern, you probably never
want to do it. OK. So I showed that complex control
a second ago, that list thing. And one of the
questions that come up a lot is like, OK, I’m
building this complex control, but what are all of the things
that I need to add to it to add proper keyboard support? What happens when the user
presses Escape or up or down, what’s the expectation? What do users want from me here? And so to help with this,
there is this amazing document called the ARIA Authoring
Best Practices Guide.
And I’m going to talk about ARIA
more later on in the session, but this is such
a useful document. I wanted to put
it in here early. And what it does is
list patterns like UI patterns on one side,
so combo box, button, checkbox, whatever. And you can click
on those and then it will take you to a
section that just tells you all of the keyboard support
that that kind of control needs to have. This is what–
this is what users expect when they interact with
a dialog or something like that. So this is a super useful guide
to just answer and clear up any of those questions
that you might have when you’re
trying to figure out what support I need to add.
Now you might look
at this and be like, OK, well that’s like a
non-trivial amount of work, right? And again, as I said
before, good accessibility equals good UX. And so that means that
the controls that we build need to have robust,
polished keyboard support. So it can be a lot
of work at times. And if I’m doing all
this work, then I want to think to myself, how
do I get the maximum amount of mileage out of this? And what I think is kind of a
good approach is once you’ve done all this work with the
component that you’re building, consider extending the platform
and then turning that widget into a Web Component.
And the nice thing
here is you’ve now encoded all these
useful keyboard patterns into a
the reusable component that you should be able
to use in any context, in any sort of
framework or library, or anything that can just
work normally with the DOM. So this is a nice place to just
extend things and get something that you can take with
you on to future projects.
This is an area where in
particular the Polymer team has spent a lot of time over
the past year making sure that the components
that they build comply with those
ARIA design patterns. So a good example of
that is the modal window. So the modal window
in accessibility is like the boss
battle that you reach at the end of accessibility. Because they’re super,
super hard to program in an accessible fashion. I’ll walk you through
a scenario here. So let’s say you have
a modal window, right? You’ve just made a
little DIV thing. And you don’t want
the user to be able to click on the background,
so a lot of developers will put a little
overlay behind it. All right. Cool. Problem solved. Let’s look at what it looks
like when someone goes through this using a keyboard. So they press the Tab key,
and they focus on the first item. Tab key and they
focused on the next item. And they press Tab
again, uh-oh, it just went right behind the overly.
It just focused on the
next focusable element in my document. Because it doesn’t care that
there’s an overlay there. It doesn’t– that does not
affect the tab order at all. And so what you need is a
temporary focus trap inside of that modal, right? And this is not always a
trivial amount of code to write. So this is the code that I wrote
recently for my modal focus trap thing, right? And I don’t want to write that
over and over and over again in all of my projects. OK. So this is a place
where I would love if there is a preexisting Web
The component that I could just take off the shelf did all
those good behaviors for me. So the Polymer team
spent a lot of time working on this when
they created their paper dialogue element. So this element, if you give it
just this modal attribute, just that one thing,
there is a signal to say, hey, when the modal is
open, trap the keyboard focus.
OK. So I don’t have to deal with
any of that code anymore, which is awesome. Also, when the modal is open,
move focus into the modal, so that my user knows, like
hey, a modal window just opened. Because if I’m using
a screen reader and a modal window pops on
the screen, I need some indicator, I need something to tell me
that that thing exists now. So move focus into it. That’s what the autofocus
attribute will do. There are attributes for
confirming or dismissing the modal, which are very handy.
And then I love this
attribute right here, which is when the
model gets closed, it’s going to restore focus
to whatever was the previously focused item in the document. So now the user has that
continued continuity with their experience. So this is a great example of
taking all those accessibility best practices and putting them
together into a Web Component. You can see that in action here. So I’m just going to
open this paper dialog. And as I’m hitting
my Tab key, it’s trapping focus now,
so I’m not escaping to the back of the page. And I can just
hit Enter or Space on this button to just
close it and restore it to the document. It’s awesome.
OK. So we talked a lot about focus. I’ve got to shift gears now
and talk about semantics. So when I think about
semantics two questions come to mind. And the first is,
what does it mean when we talk about good semantics? And the second is, how do good
semantics benefit our users? And to answer
these questions, it helps to think about
this idea of affordances. So affordances offer or
afford a person an opportunity to perform some action. A teapot is a
really good example. So a teapot just based
on its physical design has all sorts of
affordances built into it. It has a handle. And because I’ve seen other
things with handles before, I know that I can pick that
thing up and probably operate it and tilt it based
on that handle. So the handle, the little lid
on the top, the spout, these are all visual affordances
that tell me how this thing’s going to work. I don’t need someone
to explain to me how a teapot works, right? When it comes to a
graphical user interface, we still have affordances but
now they’re more metaphorical.
So a button is a good example. You might take a
button and you might try to make it look like a
real-world button, something that someone might
Click on it, so you give it a drop
shadow, and like a border, you make it look
kind of 3D, right? So these are all
visual affordances that you’re adding
back in so, the user can infer how to use the UI. But for a user who
can’t see the screen, they’re going to miss out on
all of these visual affordances.
So we need to make sure that
the information that we’re trying to express
with these elements is expressed in a way
that’s flexible enough that assistive technology
can pick up on it and create an alternative
interface for our users. And so we refer to
this as expressing the semantics of the element. So to give you an
For example, here I’ve got a select element
with a label. And this is going to produce
a visual UI, right, which is full of its affordances.
But because I’ve used
semantically rich elements, it’s also able to produce an
audio UI for someone who’s using a screen reader. And generally speaking,
for most of the elements in your application, you can
expect the four crucial pieces of semantic information
to be there. The elements should have a role. So our select element has
the role of a pop-up button if you’re using the screen
reader voiceover on a Mac. It has a name. And when I say that,
I mean the label if you want to think
of it that way. Like what– if a screen reader
were to land on this thing, how would it say its
name or its label? So I’m not talking about the
HTML name attribute, but just the associated
text with the control.
It could optionally
have a state, not everything has a
state but some things do. And it could optionally
have a value. So what’s happening here is
when we write HTML, two things get produced, right? We get the DOM. And then from
that, we get a GUI. And we get an
accessibility tree, which is a collection
of all those semantics. That accessibility tree
then gets handed off to assistive technology,
so something like a screen reader, which is then able to
produce a secondary interface for our user. So it can announce,
hey, this is the element that you’re interacting with. So under the hood, this
is what’s happening. And this is why it’s
really important to make sure we have
these good rich semantics in our applications. So just like we saw with
focus, native elements have implicit semantics. So if you are using an input
with a type equals password, and you focus it using
the voiceover on a Mac, it’s just going to go
ahead and announce that it’s secure edit text, right?
So I didn’t have to
add anything there. These are just all built
into the native controls. And just like we
saw with focus, when we try to bolt functionality
onto non-semantic elements, like a DIV, then
we’re going to end up missing out on all
of these goodies that the browser is trying
to give us for free. So here is another one of
these fancy DIV buttons. And I’ve added tabindex,
right, so it’s focusable. But, to a screen reader, a DIV
is just a generic container, right? It’s not– there’s
nothing about it that says that it’s interactive. So when the user lands on it,
if they’re using voiceover, it’s just going to say,
group, group of what? I don’t know. Like is this– I don’t know
what to do with this thing. So again, this is
another place where we want to make sure we’re
not fighting the platform.
Whenever possible, we want
to use native elements because we’re going to get
these freebie semantics. And by the way, just as
an aside, at this point, none of you are ever again
going to write a DIV button. If anyone writes a DIV
button after this talk, I have failed. Yeah. There’s no upside to it. But I get it, there
are times when you have to build something
that, again, there’s no native analog for it, right? You’ve got to go off-road. You’ve got to make your
component, right? And when you’re doing that,
just like we saw with keyboard focus, we want to make
sure that we’re adding back in those proper semantics. So we’re going to do this
using the Web Accessibility Initiatives Accessible Rich
Internet Applications spec, or ARIA– there are a lot of
acronyms in accessibility. So what ARIA does is
it lets you do surgery on the accessibility
tree, right?
It lets you add
attributes to elements. And those elements
then modify– or sorry, those attributes then modify
the semantics of those elements. Now an important
thing to remember here is that semantics is the
only thing that ARIA changes. ARIA does not and cannot affect
the behavior of your element. So this is, for me, this was one
of those Swiss cheese moments that I referred to
earlier, kind of like a hole in my
understanding of the platform.
So I used to think
if I just added a role, a button, and spam some
ARIA attributes on a thing, it would just become
keyboard focusable. It would just like magically
work with the keyboard, right? That is not the case. All it does is update
semantics, which is a really important
thing to understand. So that means if
you are adding ARIA, you still need to go do
your tabindex work, and you still need to make sure
you’re adding those keyboard support things as well.
OK. So I’m going to walk
through an example here. This is a custom element
that I was working on. It was a checkbox. And you can see what
it renders over there. And in this little
box down here, I’m going to put what the
screen reader announces when I interact with this thing. Now right now, this thing is
so semantically uninteresting, that if I were to land
on that checkbox element, then voiceover on a Mac would
just say nothing. It would be like, this
is nothing to me. I do care not about this tag. OK. So I’ve got to figure
out how I add the right semantics to this. And you could go look
at the ARIA spec, which comes with this very
helpful diagram, or, what I would recommend, is
to go back to that ARIA design patterns doc, that I
was showing earlier, find the control
that you’re building, and then this will
take you to– so since we’re
building a checkbox, we can go to section 2.7.
And it’ll
show you here– there’s a whole column,
if we scroll down, dedicated to these are the right
roles and states and things that you need to
add to your element, and here’s when you
need to add them. OK. So this tells me I need
a role of the checkbox. I need to provide
an accessible label. I need to set ARIA
checked to true or false depending on our state. Right up there.
OK. So that’s what
we’re going to do. So I’m going to go
back to my checkbox. And the first thing
I’ll do is I’ll give it the role of the checkbox. And then I can see in my
little box down there, now my screen reader
is just going to say, Ah, this is a checkbox
and it’s unchecked, right? It’s inferred that it’s
unchecked based on the role. And in the world
of ARIA, the role is the most
important attribute. OK. Everything falls
out of the role.
Many ARIA
attributes don’t even work if they are not
paired with the correct role. So the first thing
I’m going to do is nail that role, and make sure
you get the right one up there. Now, if you’re looking
at the checkbox, you can see that well,
it is checked. So I need to tell this
thing that we’re currently in that state. So an ARIA checked
attribute of true. Now here we see kind of an
interesting quirk of ARIA.
Some HTML attributes
or many HTML attributes are Boolean attributes,
meaning that just putting the attribute on the element
will imply that it is true. OK. With ARIA, you always
have to pass a text value of true or false as a string. I think it’s one
of the– it’s one of the only places where
you have to do this. So this is just sort of an
interesting quirk of ARIA. So you always have to
give it a literal string of true or false. Now the next thing
the doc told us to do was to give it a label. And labeling is super important
in the world of accessibility. And there are two main ways
that we can go about it. There’s the
aria-label attribute. And this is just a string
that we can just apply right to the label itself. So a good example of
when we would use this is on something like a hamburger
button on your responsive website, right? Like you might not
have– you might not have any text around
that button so there’s no sort of label to
associate with it.
But if a user lands
on this button, the voiceover is just
going to say, but. OK. Button for what? Like, send my social
security number? What is this button? So I need to give it
some kind of label. And I can use
aria-label to do that. So now I can say Main
Menu button, right? Very easy, very nice technique. It’s important to note too
that the aria-label will override any other label or
text that you have associated with an element. So if it’s– if you’ve got a
button and you’ve got some text inside of there and you
give it an aria-label, the only thing that will
be announced will be that aria-label. Similarly, we have another
thing called aria-labeled by. And this lets us
associate another element with our label.
So it’s similar to
using the native label tag that many of you
are familiar with, except for the label
element only really works with a few things, a few
inputs, and other controls, whereas aria-labeled by can be
applied to pretty much any HTML element. And the cool thing
about it is it composes. So it can have multiple
things that we’re referencing that we
can use to build up a complex label for our element. So in this case I’ve
got a Shop Now button. And when the user lands on it,
it just says, Shop Now button. OK. Well, shop now for what? Shop now for hats, shop
now for sunglasses, right? I want to associate it
with that piece of text right up above it. So I can put two IDs
into my aria-labeled by field. I can put that label’s ID in
there, as well as the ID of the button itself. It can self-reference. And now, we’ve composed
together a bigger label of men’s outerwear,
shop, button. So this is what I want
to use for my checkbox. So I’ve got this little
associated span down here.
And I’m going to use
aria-labeled by and refer to that span by its ID. And now we can see that our
outcome is the Sign Up checked checkbox,
which is awesome. Now there are a few ways to
verify that the work that we’ve done here is correct. You can either learn
a screen reader, which I would
recommend everyone do. It takes about 20 minutes. You’ve got a free one on the
Mac in the form of voiceover. And if you go to your
System Preferences there’s even a tutorial
that it’ll just walk you through voiceover,
which is awesome. And on Windows, you have
NVDA, which is also free. So pick one of those up. Check the work
that you’re doing. But if you’re on
a big application, it can be a little
frustrating to have to tab through or navigate
through the entire page with a screen reader every time
you want to verify your work.
So I’d also recommend you check
out the Chrome Accessibility DevTools Extension. So this is available
on the Chrome store. This was created by my
teammate, Alice Boxhall. And it’s an extension
that is going to let you inspect your element’s
accessible properties, the same way that
you would inspect CSS or anything else
associated with an element. So I’ll give you
a little example. So here’s our Sign Up button. And I’m going to open
my Elements panel. And I can
find it in the DOM. And then I can go look
where normally there are styles and other things, I have
this Accessibility Properties tab that I can open up.
And now I can see the
role, the element that is providing my labeled by value. I can see, down there
where it says Text, I can see the
computed name or label that will be announced
for this thing, right? So I get all this
information for free. And this way, I can
just very easily go through and inspect
my app to make sure that I’m doing the correct work. Now just like we
saw with focus, this can become a non-trivial
amount of effort, getting all these
attributes right. And so, again, this
is another area where you might consider turning
this work into Web Components. And so the Polymer
team has been looking at that
aria-authoring guide. And they build loads
of controls, right? And as well as having
good keyboard support, these controls also all
apply the correct ARIA roles, and correct ARIA
states and values when they should at
the correct time.
And so a good example
of this is the site that the team has been
working on called Shop. So I like this because I
think it’s– it shows that you can use bleeding edge
technology like Web Components, without having to sacrifice on
good semantics or anything like that. So you can
see my screen reader running down here in the corner. I’m going to navigate
through the shop site. And you’ll see that
it’s announcing all this semantically rich
information to the user, right? It’s telling them the
control that they’re on and how to work with it, right?
It’s a pop-up button. They can pick their sizes. Well, you’re also seeing good
keyboard focus management. So as I click Add
to Cart, now I’m moved up into that dialog
that just opened up so the user didn’t have to
furiously search for it. So this is like, again, I
like this project. It’s up on GitHub today
at Polymer/shop on GitHub. Go check this out. Please, if you find
accessibility issues, file them. Because we want to
make this a model showpiece of using Web
Components and accessibility to produce a
great final product. OK. Wrap up. We covered three
major areas today. The first is to make
sure that you understand the diverse range
of users that are out there, learn the WCAG,
familiarize yourself with the WebAIM
checklist, figure out what your primary user journeys
are in your application, and make sure that
you can check off the relevant checklist
items that relate to those. You also to make sure that all
of your interactive controls can be reached
with the keyboard.
So use native elements
whenever possible, because they’re going to
get implicitly inserted in the tab order. But if you need to
go off-road, you need to create
your controls, make sure you add that keyboard
support back in using tab index. Similarly, we want to
make sure that we’re offering good affordances. So use native
elements when you can because you get rich
semantics for screen readers. And if you need to go off-road,
take a look at the ARIA design patterns doc and
make sure you’re applying the correct
ARIA attributes. The main takeaway that
I would like all of you to leave with, is there’s
one mantra that you can have in your head
good accessibility is good UX. OK. Take this back to your team. Scream this in your meetings. When you work on accessibility,
right, through every step of your process,
what you’re doing is you’re making sure that the
final product that you produce is significantly more polished
and that more users can access and enjoy your experience.
OK. I’d also ask you to go
check out this course if you’ve been
interested in the things we’ve been talking about today. This is a multi-week
a course that goes way deeper on all
the things that I’ve been showing this afternoon. Also, there are a few more
accessibility sessions here at I/O. So this evening
at 5:00 PM in Hercules there will be one. There’s one tomorrow at
11:00 AM in Ursa Minor. Also, go check out the sandbox,
the Access & Empathy sandbox. They always have the
coolest stuff every I/O, because they’re showing off all
the cool new future assistive technology. It is always my
favorite sandbox, so be sure to go find
them and check that out. Lastly, thank you so much
for joining me this morning. And I hope you enjoy
the rest of I/O. [APPLAUSE] [MUSIC PLAYING].
