ALICE BOXHALL: Hi,
my name is Boxhall.
I'm a developer on the
Chrome accessibility team.
I have a bit of a cold,
so I'm sorry if I'm
a little hoarse here.
That's cool.
I didn't need to use my slides.
So I'll get into the guts
of my talk in a second,
but I just really like this
definition of accessibility
that you can find on
good old Wikipedia.
Accessibility is the degree
to which a product, device,
service, or environment is
available to as many people as
possible.
And what I like about this is
it doesn't make any reference
to ability or disability.
It includes people
who are in a hurry.
It includes people who
are using a mobile device.
It includes people who find
small click targets really,
really irritating.
And to make it more
explicit, I think
that accessibility actually
implies multi-device
because you're making your
product accessible to people
in a wide variety of situations
and for a wide variety
of backgrounds.
So today I'm going to talk
about what inaccessibility looks
like, so the types of
patterns and things
that are going to make your site
inaccessible to various groups
of people.
I'm going to introduce
screen readers.
If anyone has never
experienced a screen reader,
I'm going to give
a demo and explain
how you can try out a
screen reader yourself.
I'll talk about what
you can do to improve
the accessibility
of your site, how
to assess the
accessibility of your site,
and then I'll have some links
at the end for more information.
So what does
inaccessibility look like?
What constitutes
inaccessibility?
Well, here's a good example.
Anyone seen this on a mobile
device or even their computer?
Yeah?
It sucks, right?
So this is what it's like when
you cannot access something.
So different users are going
to require different things,
obviously.
So we have a bunch
of different groups
that we need to
consider, low vision,
hearing impaired or deaf,
low motor abilities.
So this is someone-- it can
range from having a tremor
or having poor
motor control, right
through to having no use
of your hands at all.
Screen reader or
braille display user.
So this could-- I'll get
more into that later.
And voice control user.
So this is the extreme end
of lack of motor ability.
And in almost all
cases, accommodating
these needs improves the
experience for everybody.
So who are the users that
we're addressing here?
So 9.2% of the adult
population of the US--
more in developing countries--
have some vision trouble.
So the way that you address
this is very simple.
Avoid low contrast
text because really,
who likes reading low
contrast text anyway?
Avoid relying on color
alone for communication.
Make sure that the
text is resizable.
And as you saw in the
mobile talk earlier,
that's really useful anyway.
Provide text alternatives
to visual media.
And again, this is
really useful if, say,
you don't want to watch a video
to get the only documentation
for that dev tool you'd
really like to use.
So 36.4 million adults in
the US have at least one
complex activity limitation.
So this is motor control.
This type of person
may not be able to use
a mouse, for example, or
may have significant trouble
accessing small click targets.
So provide large click targets.
Label your radio buttons.
If I need to use one more form
where the radio buttons aren't
labeled, and I have to click
on that tiny, tiny circle,
I may actually flip my table.
Ensure your site can be
used with the keyboard only.
And this is something
that I'm going
to return to time and time
again because this will actually
get you a really
long way to making
your site accessible for
the broadest range of users.
So screen reader
and braille users
are a much smaller number.
From the point of view
of the web author,
you guys, these groups are
largely interchangeable,
even though the way
they access the page
is going to be slightly
different, especially
in the case of
screen reader users.
They may or may not
actually be blind.
They may have another impairment
such as dyslexia or a learning
disability.
They may not be able to read.
They may not be able to
read the target language.
They may be temporarily
unable to read,
such as recovering from laser
surgery, such as getting
motion sick, that kind of thing.
But by and large, the thing
to remember with these users
is without assisted
technology, they're
not going to be able to
access the site at all.
So this is the Flash situation.
All right.
So screen readers.
The way that a user
with a screen reader
is going to be interacting with
a device-- the screen reader
or braille display
is going to translate
the interface of a site
into text or speech.
So in this case, we can
imagine the interface has
a Cancel button
and an OK button.
It's going to read
out, Cancel button.
The user is going to then
hit a keyboard shortcut.
And so with desktop
screen readers,
there are literally hundreds
of keyboard shortcuts
to make navigating
really, really efficient.
So they're going to go
to the next control.
It reads out, OK button.
Then they hit another
keyboard shortcut
to send a click command.
So instead of using
the mouse, they're
going to be interacting
by the screen reader.
And then it's going to tell
them that the button's being
clicked.
All right.
So I have-- this is a
demo of ChromeVox, which
is a screen reader for
Chrome and Chrome OS.
It's built into
Chrome OS, and I'll
get to how to use
it in a minute.
But I'll just show
you this first.
[VIDEO PLAYBACK]
-Home, list item.
Sessions, link list item.
Schedule, link
visited list item.
Clicked.
Chrome Dev Summit
2013 navigation list
with three items.
Find in page, enter.
Multi-device
accessibility link visit.
Press Enter to accept or exit.
Find in page.
Chrome Dev Summit 2013 tab.
[END VIDEO PLAYBACK]
ALICE BOXHALL: All right.
So that was just me going
through the Chrome Dev Summit
site earlier with ChromeVox
and finding my orientation.
All right.
So ChromeVox is built
specifically for the web.
It's built in on Chrome OS.
You can activate it
any time on Chrome OS.
And the really
nice feature of it
is that it's really easy
to use for sighted users.
A lot of screen readers
that are dedicated
for use by blind
people don't have
any kind of visual feedback.
They're really difficult to
learn the keyboard shortcuts
for.
You really need a
lot of training.
But ChromeVox can be
picked up by a beginner
in about a minute.
All right.
So my estimate is 30 seconds.
There's probably a
bit of [INAUDIBLE].
So as I said, keyboard shortcuts
really drive screen readers.
So we have a set of modifier
keys we can refer to as cvox.
You can configure it.
It defaults to Control
Alt on Windows an Linux,
Control Command on OS X, and
Search Shift on Chrome OS.
And in Chrome OS, you can
turn it on at any time
or turn it off with Control
Alt Z. Z And ChromeVox A,
A will temporarily turn the
ChromeVox feedback on or off
if you have the extension
installed in Chrome.
So the way you
actually use it-- this
is the way I will test
things for accessibility
as an extremely novice
screen reader user.
So use the ChromeVox
keys and up and down
to navigate through the page.
So this is what I was doing
in the demo a minute ago.
ChromeVox Space
will force a click,
so that this is how
you click things
when you don't have a mouse.
Control by itself will make
ChromeVox stop talking.
And if anyone's curious what
the search command I used,
it's actually ChromeVox
forward slash.
So on mobile devices, the
story's a little bit different.
Obviously, you're not
going to have a keyboard.
You're not going to have all
these hundreds of keyboard
shortcuts.
But what you do have
is a touch screen.
So what they will do
is use their finger
to touch the screen
and explore--
[DING]
OK.
Explore the screen,
and it will read out
whatever they have touched.
So in this case, we
can imagine a user
exploring the same interface.
[DING]
I really don't
know that sound is.
Sorry.
Exploring the interface,
finding a button, an OK button
and a Cancel button.
And this time, they've
clicked the Cancel button.
So TalkBack is built in
on all Android devices.
You can turn it on from
the accessibility settings
if you want to try it out.
So then you'll get
a short tutorial
on how to use the
touch exploration
feature like I was
just talking about.
So yeah.
And in this case,
double tapping will
send-- I think it's
actually a click event,
but it may as well
be a touch event.
And that'll allow the user to
actually interact with things.
On Android, you also
have BrailleBack.
This needs to be installed
from the Play store.
But that will allow
the Android device
to pair with a braille device.
So what I've shown
here is looking
at the Chrome Dev Summit
site using BrailleBack
and with the on
screen braille display
to simulate what the
braille device will display.
So you can see that it's pretty
similar to the spoken feedback,
except it will have all these
abbreviations so that it can
fit more information
into a shorter space.
All right.
So what can you
actually do to improve
the accessibility of your site?
Start off with the design.
Design with diverse
users in mind.
So when you're looking at how
to create your interactions,
think about how a
keyboard only user
will interact with your app.
Don't assume that
someone's going
to be able to perform
a hover interaction.
And in fact, someone on
a phone is probably not
going to be able to perform
a hover interaction either.
How is a screen
reader user going
to interact with your site?
So this means you need to
think about what the text
alternative, what the
label is for everything.
What's going to be
read out when you
focused on a particular element?
Is it just going to say, div?
Do you have images
will all of the text?
That kind of thing.
And finally, how adaptable
is your interface?
If something is viewed via
some kind of assistive device
or viewed maybe by a text only
device, is it going to work?
Or is it just going
to fail horribly?
So again, ensure that you
have a good keyboard only user
experience.
And what does this
actually look like?
Firstly, I shouldn't
need to say this.
But use standard widgets
wherever possible.
They come with built
in keyboard handling.
So the Polymer talk
yesterday went a bit
into what you get for free
with standard elements.
Use or extend good
custom elements
with built in keyboard controls.
So when you can't
use standard widgets,
or you want something
that looks a bit different
or behaves a bit differently,
use good custom elements
or write your own
good custom elements
with keyboard handling.
So I'll get into
what you need to do
to rollout yourself in a minute.
All right.
So if you're writing
your own elements,
whether you're using
custom elements
or whether you're just writing
something from scratch,
use tabindex.
That'll make things focusable.
So if you have something
which is a click target
but isn't focusable,
screen reader
may actually have
difficulties using it.
Plus, someone
who's keyboard only
will never be able to use it.
I assume you all know
how to use tabindex,
so I won't get into that.
And handle keyboard
events wherever
you handle click
or touch events.
And if you want to know
which keys to listen for,
follow established user
experience patterns
for the platform that
you're targeting.
All right.
This is something we may
not necessarily think of,
but it's actually
really irritating
if you're trying to use
an app keyboard only.
Manage focus.
So make sure that focus
is in a sensible order
with the tabindex property.
Make focus visible.
So don't make your user play
find-the-focused-element.
So what does that
game look like?
It looks like this.
And I'm sorry to pick on Gmail.
It's just that I use
Gmail all the time,
and this really bugs me.
Where's the focus here?
You can see it if
you really squint.
It's actually right there.
If you're showing a pop up
or a modal dialog and so on,
move focus within the
pop up when your open it.
So call focus from JavaScript.
And move focus
back to the element
that triggered the
pop up on close.
So I've clicked my focused
element, or I pressed Enter.
And it showed a pop up.
So that's good.
It had keyboard handling.
Now where's the focus?
It is actually in the pop up.
So that's cool.
However, now when
I close the pop up,
it goes to a random
location in Gmail
that I haven't actually figured
out what the logic is yet.
OK.
Next step, express the
semantics of your interface.
So as I keep saying,
use standard widgets
wherever possible
because they're
going to have the
semantics built in.
Or use well written
custom elements
which are handling this for you.
And again, if you're writing
your own custom elements,
or you're writing
things from scratch,
use ARIA to express
the semantics.
All right.
So this is a
non-semantic interface.
It's a div that has
an onclick alert,
onclick F This is much better.
It's a bottom.
It still has an
onclick listener.
But it's going to actually
have a tabindex now.
It's going to respond
to keyboard events.
And we have a custom
element, sort of,
that we've given an ARIA role.
So that is now going to also be
presented to the screen reader
as a button.
But that's not really
the whole story.
You still need to make
it focusable and handle
key events.
So what's ARIA, this ARIA thing
that I keep talking about?
It stands for Accessible
Rich Internet Applications.
It's a W3C standard.
And it allows you to express
roles, states, and properties
for elements via
HTML attributes.
So we saw this role attribute,
that's an ARIA attribute.
So what that does-- the reason
I keep going on about semantics
is that screen readers
are all about semantics.
It's going to view a
modified version of the DOM
that just tells it
what the role and what
the text is for each element.
It's not interested in images.
It's not interested in layout.
And so we see here is
we've applied a role
to this div and an ARIA label,
which is an ARIA property.
And that gets rendered
to the screen reader
as an actual button
and allows the user
to interact with this as
if it was an actual button.
OK.
Thanks, Presently.
We have a native button.
And as we saw in the
Polymer talk yesterday,
this comes out
looking like a button.
And it comes out
indirect with a-- sorry,
with a JavaScript
DOM object, which
allows you access all
the attributes you
would expect for a button.
It also comes out with
an accessibility tree,
which is mangled
because reasons.
That tells the screen reader
that there's a button.
And it has a press state, an
on press state, and so on.
For custom elements, you need
to do a little more work.
So in this case, the
custom element author
has made it so that the custom
element will write these ARIA
role and attribute
when the custom
element is rendered to the page.
So then we end up with
a similar situation
as we do for native
elements, where
we have a visual rendering.
We have a DOM
object that lets us
access the attributes that we
want and interact with them
and get a good
developer experience
but also have an accessibility
tree, which makes sense
to a screen reader or
braille display user.
OK.
So how can you actually assess
the accessibility of your site?
Firstly, try it without a mouse.
Try it without a track pad.
I saw this great tweet
from someone saying,
the track pad on my MacBook
Air broke, and I'm on a plane.
To all site
developers everywhere,
please fix your accessibility.
Try out a screen reader.
The way you use a
screen reader will not
be the same as the way an
experienced screen reader user
uses it.
But it will give you an idea
of what things are labeled,
what things are accessible
via the screen reader,
when focus has gone horribly
wrong, that kind of thing.
It's worth just trying it out.
And you can also do
automated testing.
So there's this
extension for Chrome
called Accessibility
Developer Tools.
And it's also a
JavaScript library,
so you can use it in
your continuous testing.
And I'll give you a
demonstration of that.
All right.
It comes up in the Audits tab.
Yup.
It comes up in the Audits
tab of the developer tools.
So it just comes up here.
I've run it already on
this page obviously.
And it's come up with
a couple of-- well,
many errors for this page, a
couple I'd like to highlight.
So we have this here.
It says-- it's unfortunately
cropped by the page.
But it says, these elements are
focusable but either invisible
or obscured by another element.
So what's happened here is we
have focusable elements that
are behind this modal dialogue,
which for a screen reader user
are going to come up
as completely visible,
even though to a sighted user
they're obviously inaccessible.
It's going to be a really
confusing experience.
And what we want
to do is make sure
that everything that is
hidden behind this dialogue
has an ARIA attribute,
which will hide it
from a screen reader.
You possibly also want to set
the tabindex to negative 1
to make sure that it's
not part of the tab order.
And then here we have-- it
says text elements should
have a reasonable
contrast ratio.
So when I was talking
earlier about users
with low vision or
even just anyone
using a mobile device
in bright sunlight,
low contrast text
is a real pain.
And so I'll just demonstrate
a neat feature that it has,
which is that I can look at
this in the Elements panel.
And it'll actually come
up with suggestions
for colors I could use instead.
So yeah, slightly
darker and much darker.
And finally, so here--
one thing that's
always bugged me
about using ARIA
is that when you
write incorrect HTML5,
the DevTools is
going to tell you.
And it's going to
come up as an error.
When you write incorrect
ARIA, you really
have no feedback until you try
using it with a screen reader
and discover that
it doesn't work.
So here we have a progress bar.
And I'll show you what's
actually happened.
So I've tried to set
the value to 80%,
but it turns out
ARIA value now takes
a number instead of a string.
So when I try and view that
with ChromeVox-- actually, no.
I can't do that.
Anyway, when I try and
view that with ChromeVox,
it actually says,
progress not a number
percent, which is
really embarrassing.
So I can actually fix that.
And now it's telling
me that it's correct.
All right.
So just to sum up,
improving accessibility
will almost always improve
the experience for everyone.
Even when you're looking at
screen reader accessibility,
what you're doing is
expressing your interface
more semantically, which will
improve the maintainability
and testability of your code.
There are testing
tools that actually
look at the accessibility
tree in order
to create interaction tests.
Keep diverse users in mind
at all stages of development.
So when you're designing, when
you're building your interface,
when you're testing,
make sure that you're
testing the interactions
that anyone would use.
Have a good keyboard only story.
If you do one thing,
please do that.
Express your interface
semantically as well as
visually.
I think I've covered that.
Use automated and manual
accessibility testing.
So I demonstrated a bit of
how to do both of those.
And finally, listen
to your users.
If you have users filing
accessibility bugs,
follow up with them.
Figure out what's going wrong.
And finally, we have some links.
So a bunch of screen
readers that you can try.
I demonstrated ChromeVox.
There's also a screen
reader built into-- I
showed you some
screenshots of TalkBack.
There are screen readers built
into every Mac desktop and iOS
device, which is VoiceOver.
So you can use that as
well and a few other ones.
So these are all free.
A bunch of them are open source.
And so as much as we were
writing on the Web Content
Accessibility Guidelines,
actually worth a read.
The WAI-ARIA spec is there.
The accessibility developer
tools extension and library
are there.
You can also search
for them on Google.
They're pretty high up
in the search results.
And that's all I have.
Thanks a lot.
[APPLAUSE]
