Tip:
Highlight text to annotate it
X
Mazzoni: We're here to talk to you today
about how to create accessible interactive web apps
using HTML5.
[female computer voice speaking indistinctly]
And you can hear that this talk
is going to be accessible.
We've got some speech turned on.
If you have any feedback, here's the link for feedback
and for hashtags if you'd like to blog about this.
So to start things off,
one way that you can make your web app accessible
is to keep things really simple.
Use basic HTML.
Very simple, easy-to-understand layouts.
And every time that the user wants to make a change,
you can reload the page by submitting a form.
Shearer: But, I mean, that sounds kinda boring.
We want to build web apps
that are interactive and dynamic
and fun for our users to use.
We want to build web apps that feel just like native apps.
And there's no reason
why these interactive dynamic web apps
can't be accessible to users with disabilities.
So who are the users that we're talking about
during this talk?
We're gonna be addressing three broad groups of users
during this talk.
Blind users, users with low vision,
and users who are motor-impaired
and can't use a mouse.
We're gonna be talking about these three groups of users
even though there are lots of other users
with different disabilities
that also affect how they'll use our apps
because at least for these three groups
we know something very valuable.
And that's exactly how they're going to access our page.
Users who are blind would use a screen-reading software
that describes the page using synthesized speech
or Braille output.
Users with low vision will use large fonts
or a screen magnifier,
which increases the size of the currently focused area
of the page.
And users who are motor-impaired
will generally use a special keyboard
or some kind of voice-control interface.
And these three groups of users
have one big thing in common,
and that's that none of them are gonna be using a mouse
to access your page.
So it's really important when we're building our apps
that we don't make that assumption,
that we don't assume that our users are using a mouse.
Because for these three groups of users,
that's just not the case.
And for these three groups of users
there really are no work-arounds.
If our web app doesn't work
with their assistive technology,
there's really not a whole lot of recourse for them.
So that's why it's important for us to get this right
the first time.
And in this talk we're gonna tell you
how you can do just that.
Mazzoni: So let me give you an overview
of what we're gonna be talking about during this session.
First we want to show you what we think
is a great accessible experience.
First of all, how it can go wrong,
and then how we think that experience can be really good.
Next we're gonna talk about the actual code,
how you can write your HTML and your JavaScript
to make things accessible like in our example.
And finally we're gonna be talking about
browser extensions and other tools and resources
that you as developers can use
to make accessible web apps.
So let's start off by talking about:
What is a great accessible experience?
Shearer: So I'm gonna jump in for a minute
and talk to you exactly how we're gonna be demoing
our apps and our code to you today.
Some of you might have noticed,
although this podium's hiding it,
I'm running this presentation on a Cr-48 Chrome notebook.
And one of the really great things about Chrome OS
and something that we announced at I/O
is that it includes a built-in screen reader
called ChromeVox that was developed
by Dominic and my team at Google.
ChromeVox is implemented as a Chrome extension,
which means that we wrote it in just JavaScript,
CSS, and HTML.
And as you can imagine, it was built for the web.
So we're gonna be using it
to do our demos for you today.
For those of you who aren't familiar
with how a screen reader works,
essentially I'm gonna be using keyboard commands
to move focus around the page
and explore both static text and interactive elements
with ChromeVox.
ChromeVox and other screen readers
work really well with web forms,
with static text and native HTML elements.
So I'm gonna demonstrate ChromeVox
on this embedded web form
in this slide for you right now.
The first thing I'm gonna do is unmute ChromeVox
'cause it's been running this entire time.
[female computerized voice reading screen]
So what I'm doing is I'm just using
the ChromeVox modifier keys shift and search
and using the arrow keys to move ChromeVox down
through the page.
I'm actually gonna activate the lens
to show you what ChromeVox is speaking
in case you can't hear it.
Mazzoni: 'Cause it's very hard to understand,
especially over speakers here.
female voice: Screen readers and magnifiers
allow the user to explore both static--
Here's an example web form to demonstrate.
Shearer: So I'm gonna enter the form,
and you can see how ChromeVox interacts
with interactive elements.
female voice: Enter your name. Editable text.
Red. Choose your favorite color. Combo box with ten.
Shearer: So I'm gonna choose my favorite color
using the arrow keys.
female voice: Orange, two of ten.
Yellow, three of ten.
Green, four of ten.
Submit button.
Having trouble? Click here for help, link.
Shearer: So that was great. ChromeVox jumped through--
It read to me the static text,
and it jumped into each of the focusable controls,
told me what the control was,
and told me how I could interact with it.
Mazzoni: I'm gonna jump in and say one more thing here,
which is that, for that people who have low-vision,
they might be using a tool called a magnifier,
which works in a very similar way.
Instead of listening to the speech
and the sound effects that you heard,
they're simply going to be looking
at a magnified version of one part of the page.
Kinda like the lens you see at the top.
So the experience is very similar.
The idea is you're focusing
on one part of the page at a time
and having it described to you
or magnified or enhanced in some way.
Shearer: And the great news here is that
if the web app you're building looks just like this form
then congratulations, your website will be accessible
and a user can use a screen reader
to go through all of your editable text and buttons.
But if your web app is maybe a little bit more exciting,
if it has a little bit more going on
and it's a little bit more complex,
then we do have to do some extra work
in order to give our users a good experience.
And that's what we're gonna talk to you about.
Mazzoni: So let's start by talking about a bad experience.
So in contrast to that form,
here's--this is certainly not a complex app,
but this is an app that uses
a few more interactive capabilities
that you find in just about every interactive
Web 2.0 app today.
So this is a little app we built called Snack Attack,
and the idea is simply you're gonna scroll through
these list of choices and vote on the ones
that are your favorite for hacking all night long.
So I'm gonna first demonstrate this
from the perspective that most web developers
would be thinking about,
which is someone who's using a mouse
and who is fully-sighted, able to see this page.
So I'm going to look at this page
and look through these choices.
And some coffee sounds really good right now
so I'm going to click on coffee.
And now a dialog box appeared.
Now as web developers,
we all know this isn't a native dialog box.
But it feels like a dialog box
because it appeared over top of the page.
Everything else was sort of dimmed.
And there's some controls for me to interact with.
So this is good. It wants me-- I see some stars.
And it looks like this is an opportunity
for me to rate this.
I'll give this four stars.
And there's a "vote" and a "cancel" button.
I click "vote."
Now it says "saving," and the dialog box disappears.
So so far this sounds like a great experience.
Now let's suppose that the only limitation I have
is that I'm unable to use a mouse.
Millions of people out there do all of their computer use
using only a keyboard.
They might even have some type of special assistive device
that simulates a keyboard.
So I'm just gonna press tab.
And as I press tab, you'll notice
that various focusable controls
on the page are being highlighted.
So let's try the exact same experience.
I go here to coffee, and I hit enter,
and the dialog box appears.
So far, so good.
Now let's say I wanna actually interact
with the dialog.
I'm gonna press tab again.
Hmm, nothing happened.
I'm gonna hit it again. Oh, this is terrible.
The focus is behind the dialog,
so this is a poor experience for me as a keyboard user.
But maybe if I'm clever and I keep pressing tab
or shift-tab in this case
I eventually find myself inside the dialog.
You'll notice now "vote" is focused.
So I'm inside the dialog,
but it's not a great experience for me.
But how 'bout the star rating gadget?
Can I interact with that?
Well, no, it just skips right past it.
So this page is basically inaccessible to me
as someone where my only limitation
is that I can't use a mouse.
Unfortunately it can be even worse than that.
So let's turn ChromeVox back on again.
And now I'm gonna interact with the same page
as a blind user.
female voice: Sign up, link.
About, link.
Contact us, link.
Mazzoni: We can turn on the lens
to see exactly what it's saying.
female voice: Pizza delivery, link.
Caffeinated soda, link.
Mazzoni: So let's suppose that I want to click
on one of these.
female voice: Click.
Mazzoni: So I just clicked on one of those links,
and the dialog box appeared.
But unfortunately nothing else was spoken,
nothing else was said.
So I don't have any idea, as a blind user,
what just happened.
A dialog box might have appeared.
Something could have happened.
It could have done something, but I don't know what happened.
If I were to continue to explore the page,
I might discover that there's some things on the page.
female voice: Cancel, button.
Mazzoni: I might discover that this cancel button
and this vote button weren't there before.
And I notice there's something here
that says "no rating."
So I might be able to infer
that there's some sort of ratings gadget.
But if I were to press a bunch of keys,
there would be no way for me to actually interact with it,
and I don't even know what type of gadget that is.
And one last thing--Oops.
Ha ha. Hit the wrong key. I'm sorry about that.
[female voice speaking rapidly]
One last thing is if I hit the "vote" button,
it doesn't say that it's been saving anything.
So this is the last problem with this experience.
So as you can see we have a lot of work to do
in order to make this experience accessible.
Let's mute everything here.
So what went wrong?
We had poor focus management.
We had an unusable custom control
that didn't have keyboard commands
for me to interact with.
And there was no explanation to the user
when things changed on the page,
like a dialog box appearing
or a saving message appearing.
Shearer: So what should have happened?
First of all, we should have been managing
our focus better.
We want the user to fill out the dialog.
So when the user clicks the button,
we should have thrown focus inside of that dialog
so that the user could then interact with it.
We should also have made sure
that focus stayed inside the dialog
so the user wouldn't accidentally
fall out of the dialog as they're exploring.
The second thing we need to do
is make sure that we could use the keyboard
to interact with our custom controls.
You saw that that star rating widget
didn't accept any keyboard input at all.
And so that's really bad for these users
that aren't using a mouse.
They're using the keyboard.
Controls need to be labeled for screen readers.
You saw that ChromeVox didn't even recognize
that that gadget was interactive at all.
So someone who's using ChromeVox
doesn't un--wouldn't be able to figure out
how to vote for a particular snack.
And the way that we can actually label our custom controls
is by using special markup,
and we'll go more into that later.
And finally, the user needs to be informed
when things change on the page.
There were two instances--
the first one, the dialog opened,
and the second when the word "saving" appeared--
that nothing was spoken by ChromeVox at all.
Those changes were happening outside
of the currently focused area.
And we can also add special markup
to let the user know
when those kinds of changes are happening.
Mazzoni: So let's take another look this time
with all those problems fixed
and see what the experience can look like
when we've made it accessible
to users with this type of assistive technology.
I'm gonna skip past the case of the keyboard-only user
because you can sort of imagine the experience
once you've seen the experience with the screen reader.
So let's turn--
female voice: HTML5. Sign up, link.
Mazzoni: So let's turn ChromeVox back on.
And I'm going to go through the exact same experience
and let's see what happens here.
female voice: About. Contact us.
Pizza-- Caffeinated soda, button.
Mazzoni: Okay, so now I've got something--
I've chosen the item I want to click on.
Let's see what happens when I click on this.
Actually I'll turn on the lens again
so you can see it hopefully.
Let's just listen this time what happens
when I click on something and enter dialog.
female voice: Please rate this snack.
The rating from zero, max five, slider.
Mazzoni: So what it said there was,
first of all it said "entering dialog."
And then it told us that we're on a slider.
Well, this is great.
So a slider is a control
that I'm already familiar with working with.
And so if I were on any slider normally,
I might use the arrow keys to interact with it.
And in fact this is gonna work great.
female voice: One star, eww gross.
Two stars--
Mazzoni: So just by pressing the arrows,
it's changing the value of the slider
and reading the new value to me,
and in addition to the value
also some sort of description for it.
So this is great.
Now let'*** the vote button
and see what happens here.
female voice: Click. Saving.
Mazzoni: So notice that it said "saving,"
which is great.
So basically everything that happened on this page
was--also had a great accessible experience
to go along with it.
And again this is nothing super fancy or complicated.
We want to show that this is something
that's not very mysterious
and it's not that hard to imagine.
With some simple changes, you can make sure
that all users can get the same great
interactive experience with your site.
female voice: [indistinct] HTML5.
Mazzoni: So let's go on to the second part here,
which is how to code accessible HTML5.
So as an overview,
there are four basic areas we wanna talk about
in order to create accessible HTML5.
First of all, we just want you to use
clean HTML and standard tags whenever possible.
This is just a good, solid foundation to build on.
Then the next step is to manage focus.
And then add keyboard handlers
for custom controls that need it.
And then finally once you have that experience as a baseline,
you can add ARIA,
which is a new HTML5 markup for screen readers.
We've found it works really well if you do it in that order.
Shearer: So the first step that you wanna think about
when you're developing an app
is clean HTML and standard tags.
And this might seem like really basic advice,
but it's really important for these users
who are basically navigating the page
by moving focus around.
Using CSS for layout,
making sure that your content and layout are separated,
and making sure that your DOM order is logical
means that you're writing cleaner HTML.
And cleaner HTML is actually more accessible HTML.
And so that's something that's important to remember.
The second thing that we wanna think about
is don't reinvent the wheel.
Don't use a generic div or span tag
when there's a native HTML tag
that's more appropriate.
There's a lot of benefits to using native HTML tags
that you don't get with generic divs or spans.
Mazzoni: And I think a lot of web developers
were in a habit-- a few years ago,
there were a lot of tags that weren't possible
to style fully with CSS.
But today you can style everything with CSS,
so there's no reason not to use the appropriate semantic tag.
Shearer: And native HTML tags have focus
and keyboard handling built in,
so it means that you don't have to go back
and add those later.
And screen readers are really good at identifying
native tags to users.
And users are very good at interacting with those tags.
So instead of doing extra work on a generic div or span,
using a native tag at the beginning
will save you down the road.
And the final thing you wanna think about
is labeling your images and form controls.
For an image, this means using an alt tag
with a text description of the image.
And for a form control, using the label tag.
This is really basic advice, as I said before.
But at the beginning of your app development process
is the time to do this.
Going back later after you have a fully mature app
is really a huge pain.
So it's better to do this as step one.
Once you've got your clean HTML,
you want to start thinking about focus.
Focus management is really important for these users.
And as I said before,
it's better to use a native HTML tag,
but often we do want to do more complex things
that you can get with a bunch of divs and spans
and onclick handlers, and that's fine.
But we really need to make sure
that those custom interactive controls that we're creating
are focusable.
Only link tags and native HTML tags
receive focus by default.
So any time we're creating a control
with a pile of divs and spans,
we need to make sure that we're making it focusable.
And the way that we do that is with tabindex.
I'm sure many of you already know how tabindex works.
We have a refresher for you up on the slide.
But the really important thing to remember
is just, if you're using a custom control,
make sure it's focusable.
Once you've done that, you want to start thinking
about how you can manage your focus.
And the way that you do that
is with the JavaScript focus method.
And you can also listen for focus events
to make sure that you're managing focus
after the user has started moving focus around the page.
We did that in the demo by placing focus
inside the dialog after it opened
and trapping focus inside the dialog
after the user was interacting with it.
Mazzoni: So once a control has focus,
you want to make sure that someone can interact
with that control using the keyboard
just as easily as someone can interact with it
using the mouse.
If you're not sure what keys to use,
sometimes the easiest thing to do
is just to try out the native control
that's most similar to the control
that you're simulating
and try a bunch of keys on your keyboard--
the arrow keys, page up, page down,
escape, enter, space-- and see what they do.
But there's plenty of resources online
on how to do this.
The important thing is that,
when you're testing out your app,
you should try unplugging your mouse
and see what happens as you interact with things
and make sure that a keyboard user
has the same experience.
And luckily this is very easy to do.
We've given an example here
where something that's clickable
can also be activated using the space bar
or the enter key.
Shearer: The important thing to remember there
is that, if you're listening for a click event,
it's a good idea to try and think about
listening for an enter event or a space event also.
Once you've gotten your clean HTML,
your focus, and your keyboard handling,
it's time to start thinking about ARIA.
And ARIA is markup that you add to your page
to identify those fancy custom controls you created
with divs and spans to a screen reader.
As I said before,
screen readers are really great with native tags,
like button,
but when you have a bunch of generic tags,
it's impossible for a screen reader
to figure out what you mean by that pile of divs.
You could be trying to build a button,
or you could be trying to build something
as complicated as a full menu interface.
So ARIA markup is the tags that you add to your HTML
in order to indicate to the screen reader
how they should identify that control to the user.
And there's two types of ARIA tags.
The first one is called the ARIA role attribute,
and you put that in your HTML
to indicate what the generic tag that you're using
is trying to be.
So in this example, we've got a div
that's acting as a button.
So we have the ARIA role equals button.
When a screen reader gets to that div,
it will say that this is a send button.
Roles are static, and you'd set these in your HTML
like you see here.
The other kind of ARIA property
is called an ARIA state or property.
ARIA states and properties add dynamic information
about the current state of an element.
So you see in this example we have a div
that we're using as a check box.
So we have the ARIA role equals check box on that div,
but we also have an ARIA state
called "aria-checked."
And this tells the screen reader
that not only is this div acting as a check box,
but this div is currently checked.
And so when the screen reader gets there,
it will say that this is a checked check box.
As you can imagine, ARIA states and properties are dynamic,
and so you'd want to update these in your JavaScript
as the control is being updated.
In this slide, I want to talk about
a more specific kind of ARIA tag,
and that's the ARIA Live Region tag.
We mentioned earlier that it's important
to identify to users
when things are changing on the page
maybe outside of the currently focused area.
When you have changes on a page
that are happening without a page refresh,
you can identify them to a screen reader
using Live Regions.
In this example you see that we have a span.
And this is actually taken from the example
that Dominic showed you
where you clicked the "vote" button
and it wrote the text "saving."
And we have an aria-live tag on this span.
And that tells the screen reader that,
when the screen reader gets to the span,
"Hey, this span is gonna receive updates.
"So you should keep an eye on this span
and speak any updates that happen to it."
And you saw that ChromeVox did that.
When he clicked "vote,"
ChromeVox actually said, "saving."
And so that tells the user extra information
that they wouldn't have known
if the ARIA Live tag wasn't there.
The value of the ARIA Live tag
is any number of different politeness levels.
And I'm not gonna go into too much detail
on politeness levels,
but the important thing to remember
is it actually is a way of controlling
how quickly the screen reader interrupts someone.
So we've set it here to be polite,
which means that ChromeVox is gonna wait
until it's finished speaking what it's currently speaking
before it interrupts the user and says "saving."
There are also certain ARIA roles
that are considered live by default.
Like in this example the ARIA role equals alert.
So it's just really important to kind of manage
the different regions on your page
that are changing without a page refresh,
and ARIA Live will help you do that.
Mazzoni: Okay, so we've given you a lot of ideas
and talked about a lot of technical details,
but there's nothing better than an actual example
to see how this works
and how--in many cases, how easy it is
to make things fully accessible.
So we've got a few examples we've prepared here,
and we're gonna start with a really simple one here.
We've got a custom button.
There are a lot of reasons why you might have
something on the page that doesn't look like a button
but it essentially acts like a button.
And just as a quick reminder,
what's going to happen
when we haven't had any accessible markup here,
I'm gonna turn ChromeVox back on here.
female voice: Send refresh.
Example one. Click on this button.
Send.
Mazzoni: So you notice when I got to the send button
with ChromeVox it just said "send."
It didn't say it was a button.
And in fact if I tried to click on it,
nothing would happen because it doesn't appear
to be any type of focusable control.
So let's make some changes here.
The first change we wanna make
is we want to add tabindex equals zero.
And just by making that change,
when I hit tab, now I can reach the send button.
Now you notice that screen readers
will be able to reach things even if they aren't focusable.
They just won't be able to interact with them.
Now someone can reach and interact with it.
But we're not quite done here,
because we haven't described this as a button.
So I'm gonna add the ARIA tag
role equals button.
Now let's turn ChromeVox back on.
female voice: Send, button.
Mazzoni: So now it describes it as a send button.
And in fact it's something that I can click on
and interact with using ChromeVox keys.
So really simple example.
What I haven't done here is a keyboard handler.
So that would be the last step you'd need to do,
is to handle the keyboard handler
for someone who's not using a screen reader
but can't use a mouse.
Shearer: So I'm gonna take the second example.
This is another button.
It's similar to the one Dominic just showed you.
We've made it using a div and some CSS styling.
And probably the first thing that we're gonna want to do
is also add tabindex and the ARIA role.
So I'm gonna do that now.
Tabindex is, as I said before, really important.
Anytime you're using a div or a span
to make a custom control,
you want to make sure you're setting tabindex.
And now I'm adding role equals button.
And let's see what ChromeVox does.
This button is a little bit more complicated,
so I'm gonna have to do some extra work here.
female voice: Example two, toggle button.
Toggle, button.
Shearer: So that's great. It said "toggle, button."
I'm gonna click on it.
female voice: Clicked.
Shearer: So it said "clicked."
That's awesome.
But you'll notice that the button
actually turned a different color,
and that's because, as you might have guessed,
this slide is called "Toggle button"
and this is a toggle button.
So when I move away from it,
it's gonna stay on.
female voice: Toggle, button.
Shearer: And when I moved ChromeVox back to it,
you'll notice that it just said "toggle, button."
There was no indication to me
that this button is currently pressed
and that it's gonna stay pressed.
So this is an example of a place
where you'd want to add an ARIA state,
a dynamic property that changes
based on whether the button is on or off.
And when I add that,
hopefully ChromeVox will start telling me
whether or not this button is on or off.
And so, as I said before,
we're gonna want to set these states
inside our JavaScript.
I have this function here called toggle,
and inside this first half of the if statement
I'm gonna set the attribute aria-pressed,
and I'm gonna set it to false
in this half.
And in the other half, I'm gonna set the attribute
to be true.
True.
And I'm also gonna initialize it inside the HTML
so that we can say that the default state of this button
is off.
False.
Okay, so let's try it out.
Hopefully things have improved a little bit.
Turning ChromeVox on.
Oops.
That is the next example.
Spoiler alert, okay.
female voice: Example two, toggle button.
Toggle. Button not pressed.
Shearer: Okay, so you heard that ChromeVox
actually gave me a little bit more information.
It said, "button not pressed."
So when I click the button, let's see what happens.
female voice: Pressed.
Shearer: So it says-- Instead of "clicked,"
it says "pressed."
So I'm pressing the button.
I'm gonna move away from it to the next link.
female voice: Refresh button.
Shearer: And now I'm gonna move back,
and let's see what happens.
female voice: Toggle, button pressed.
Shearer: So that's great.
It told me that the button was actually pressed.
So this means that now we have a button
that has a state that the screen reader will tell me
what the current state of this button is.
So it's building on a little bit
Dominic's first example.
Mazzoni: Let's do a couple more examples here.
Actually, the next one's yours.
Shearer: Oh, right. Oops.
This next example is also mine.
This is another button,
but you'll notice that we've used
a native button tag,
so I don't have to go through and add tabindex
and role again for the third time.
That would be a little bit overkill.
So we have this button.
And let's just see what happens
when I run ChromeVox on it.
female voice: Example three, status indicator.
Click to begin calculation.
Calculate, button.
Shearer: All right, I'm gonna press the button.
female voice: Clicked.
Shearer: So--and silence from ChromeVox.
So clearly this button is setting off
some kind of complicated calculation.
The text box below the button says that it's calculating,
and then about a second later it says that it's finished.
But ChromeVox was totally silent that entire time.
So I as a user have no idea
that anything happened at all.
And some of you might be guessing
that the way to fix this is by using ARIA Live Regions,
because this div with with the ID of status down there
is what's receiving these text updates.
So I'm gonna add the aria-live attribute.
I'm gonna set it to be polite,
because we don't want to be rude.
And let's see how ChromeVox does.
female voice: Click to begin--
Calculate, button.
Shearer: Okay, I'll click "calculate."
female voice: Clicked. Calculating.
Finished.
Shearer: Great, so this is awesome.
ChromeVox said that it was calculating,
and then it said it was finished.
So I as the user now have a better idea
of what's actually going on on this page.
Mazzoni: So you can see that with just a few simple changes
based on HTML standards
you can make some big changes to the user experience
that people get when they're using assistive technology.
Let's take a couple of other examples.
This one's a little bit more complicated,
but let's talk about how we made the star rating gadget
from the dialog earlier accessible.
You might recall that we decided
to make it into a slider
because that was sort of the closest control
that's already part of ARIA
that users are already familiar with
that sort of simulates what the experience
of working with this custom widget is like.
So I'm not even gonna show you the inaccessible experience
because without making any changes,
as you can imagine, this would be
completely inaccessible to a screen reader
or to a keyboard user.
So let's start making some changes here.
You know the first one is tabindex equals zero.
The second one here is role equals slider.
And just that change alone is gonna be enough
for ChromeVox to announce that it's a slider,
but that's not enough in order to describe
the current state of the control.
So the slider role in ARIA
comes with a bunch of extra attributes,
which I'm gonna add now.
ARIA value min equals zero.
ARIA value max equals five.
ARIA value now equals three.
And just to be a little bit more clear,
aria-valuetext equals three stars.
So instead of just saying
the value is three out of five,
we can give it a special label
and say three stars.
So we haven't made this interactive yet,
but let's go ahead and see exactly what happens.
female voice: Rate from one to five stars.
Three stars. Min zero, max five.
Slider.
Mazzoni: That came a little fast,
and if you didn't quite hear it,
it said that it was a slider.
It said there was a min zero, max five,
and that the current value is three.
Three stars.
So this is great.
Now the only other thing we need to do
is make this actually interactive
with the keyboard.
I went ahead and built the key handler earlier.
So I can just write return star key.
Shearer: You're outside of the tag.
Mazzoni: Oh, thanks. I'll fix that in a second.
And if I did this right...
Cool, now it's interactive.
female voice: Four stars. Min zero, max five.
Three stars. Min zero, max five.
Mazzoni: So notice that simply by adding
the keyboard handler support--
because this is properly marked up with ARIA
and because my keyboard handler modifies
the ARIA attributes dynamically,
the screen reader automatically does the right thing.
It speaks the new value when the control changes.
So that's the star rating gadget example.
And let's do one more, which is the pop-up dialog.
So you saw earlier that we had a dialog.
And the accessibility problem with the dialog--
I don't even need a screen reader to demonstrate this.
You start with a button,
and you click on the button and it opens a dialog,
but focus isn't inside the dialog.
So you saw how this is a bad experience
for just about all the users that we're considering here.
So the first change I'd like to make
is just to focus the "OK" button
when we enter the dialog.
A simple change like this
is gonna create a much better experience
for a keyboard-only user.
Now the initial focus is inside the dialog.
Now let's focus on the screen reader user.
And I'm gonna say role equals dialog
on the outer dialog element there.
And I'm gonna do one more thing here,
which is add aria-label.
This is optional,
but it'll create an even better experience.
We can call this a confirmation dialog.
So now let's turn on ChromeVox and see what happens.
female voice: Buy more printer ink, button.
Mazzoni: Okay, so "buy more printer ink, button."
Now I'm gonna click this and see what happens.
female voice: Entering dialog confirmation.
OK, button.
Mazzoni: Great, so this said, "entering dialog confirmation."
So now I know that I'm inside the dialog
and that I'm in an "OK" button.
So this is already a much better experience before.
There's only one more problem,
which is that it's possible for me to escape
outside the dialog.
female voice: Cancel, button.
Refresh, button.
Exiting dialog.
Mazzoni: So this isn't a terrible experience.
At least it told me that I exited the dialog.
But that isn't exactly the experience
that I would like to deliver for users as a developer.
I'd like to actually keep focus trapped inside the dialog
because I want the user to either press the "OK" button
or the "Cancel" button.
And so we can do that with just a little bit of JavaScript,
but it's a little more JavaScript
than I wanna type live,
and so I typed it ahead of time,
and I'm gonna paste it in here.
But essentially all it's doing
is adding some event listeners.
And if I pasted that in the right place...
great.
So what's happening now
is that even as I keep pressing tab,
it's keeping me inside the dialog.
And if I press shift-tab, it's going to keep me there.
You can see it flicker a little bit,
'cause what's happening is the browser's
allowing the focus to move outside the dialog.
I'm listening on the focus event
and just moving it right back inside.
And this is something that works for screen readers.
It works for people who are using the keyboard,
and this creates a much better experience.
One last--Whoo.
It really wants to keep things trapped inside the dialog.
Okay, one less compatibility note.
We've designed all of these examples
to work with not just ChromeVox and Chrome OS,
but all the examples we showed you
is standard HTML5.
It's part of the ARIA standard,
and it's part of just standard HTML5
and JavaScript that you've been using for a while.
And all these examples work across a variety of browsers
and popular screen readers and magnifiers.
We've listed some of them here on the page.
There are some platform differences,
but the good news is that a couple of years ago
this would have been difficult to deliver
to very many users.
And today the latest versions of browsers
and the latest versions of mini screen readers
already support everything you saw here,
and so you can deliver this great, accessible,
interactive experience from a single code base.
Shearer: So now that you've seen all of our different examples
and seen how we're using
the advice that we're giving today,
I just wanted to do a quick recap
of what we've said.
Number one, use clean HTML and standard tags.
Remember that clean HTML
is generally more accessible HTML.
And this is important to do first as opposed to later.
Number two, manage focus.
Make sure that your custom interactive elements,
your fancy divs and spans with onclick handlers
have tabindex on them
and that they can receive keyboard focus.
And this is--you can also then proactively manage your focus
by using the JavaScript focus method
and by listening to how the user
is trying to move focus around the page.
The third thing is making sure
that your controls are usable with the keyboard.
Add key handlers.
Make sure that a user doesn't have to have a mouse
in order to use your fancy slider widgets.
And finally add ARIA for screen readers.
And the good thing here
is that if you've already done the first three steps,
it should be easy to find the correct ARIA role
for the control that you're trying to build.
And if you can't find one that matches exactly,
find one that approximates the interaction style
that you want.
And make sure that you're updating your dynamic
states and properties.
And make sure that you're identifying your live regions
to the user.
Mazzoni: I have one more note that I'd like to make here,
which is that this is something
that didn't come up with ChromeVox
but is an issue with a few screen readers,
which is that some screen readers are modal.
And by modal all I mean is that the screen readers
have a mode where all of the keys the user press
go directly to the screen reader
and not to the web page or any other app.
This can be convenient because it means
you don't have to hold down modifier keys
while you're interacting with the screen reader.
But the problem is,
is that you can't, as a web developer,
assume that someone who's using a screen reader
is able to always press keys
that your application can listen to.
But luckily, there's a very easy solution,
which is that whenever the user has focused a control,
then any keys they press
are going to be sent to that focused control.
So if you just keep that in mind
and just remember that global key handlers
may not always work,
but that keys on specific focus controls will work,
then you can build something that'll be compatible
with the majority of screen readers out there.
There's one alternative for more advanced developers,
which is the ARIA role application.
You can set a certain port of the page
or the entire page to be a web application
which listens to all keyboard events
and sends nothing to the screen reader.
There's some caveats in working with this,
but this can be a great way
that you can build a very custom experience
if you want to do that.
Shearer: So in the last part of our talk,
we want to talk about some of the opportunities
that are available out there
if you're a developer interested in accessibility,
which I'm sure all of you are.
But first, before I start talking
about the cool things that you can do,
I want to talk about some of the limitations
that are out there, unfortunately.
Specifically with some of the advice that we gave you
like ARIA, there are wide implementation differences
at this time between browsers, platforms, and screen readers.
And what is implemented can be buggy and quirky.
If your user base is customers
who are using older browsers and older screen readers,
at this time the best way to reach those customers
is still writing a static HTML page.
So if that's your customer base,
a static HTML page is the best way to reach them.
But you guys are here at Google I/O.
You want to learn about cool, emerging tech,
and the great thing about ARIA
is that it's kind of in the same place
as HTML5 generally.
The spec is really ambitious.
And it's implemented in some places better
than it's implemented in other places.
But at the same time, there's a lot of stuff
that works really well everywhere.
And we showed you a few of those today.
So there's no reason to wait until things settle down
to start hacking and building cool tools
with the stuff that is available.
Mazzoni: So we want to talk a little bit
about the power of browser extensions.
You know that we've been demoing these things using ChromeVox,
which is built as a browser extension.
And browser extensions in the last couple of years
have really become a lot more powerful
because you don't have to restart your browser anymore
when you want to install an extension.
You don't have to worry as much
about what types of privileges
that extension might have.
You know exactly what sites and what things
it has access to.
And because of all this,
we think that browser extensions
are a perfect platform
not only for accessibility solutions for end users,
like we've been demonstrating with ChromeVox,
but also for developers
who want to test things out for accessibility
and who want additional tools
to help make their websites more accessible.
So we'd like to talk about three of Google's extensions
that we've developed that you might find useful
or inspirational for other ideas or extensions
that you might be interested in building.
Shearer: The first one we want to talk about
of course is ChromeVox.
It's built into Chrome OS.
But because it's a Chrome extension,
you can install it on Chrome on any platform
and use it as a screen reader inside the browser.
It's implemented as JavaScript,
which means that it's basically built for the web.
It uses the new Chrome experimental TTS API
to do text-to-speech.
And it also uses some special Chrome OS APIs
to listen for user interface events in the Chrome of Chrome.
Which means that when you have your Chrome OS,
your Chromebook that some of you are gonna be getting,
it actually will speak the sign in dialog.
It will speak the menus that you open
in order to change the settings.
And so that's really great too.
It's speaking the Chrome of Chrome for you.
And for ChromeVox the goal is really
to have the best support for HTML5 and ARIA,
because this is a screen reader for the web.
And if you want to go beyond that,
we also support custom scripts
that you as a developer can add to your site
if you want to add the extra level
of interactive accessibility
beyond what ARIA and HTML5 allow you to offer.
The second extension that we've done
is called ChromeVis.
And this is an extension that we made
for low-vision users.
It's basically a type of screen magnifier.
We released it last summer,
and the goal with ChromeVis
was to kind of take advantage of the power of extensions
to allow users to customize their entire web experience.
There's a lot of different types of low-vision users.
They all have different needs.
And ChromeVis allows them to modify almost everything
about this magnified lens.
Basically users will select text on the page,
and ChromeVis will display that selected text
in this special lens.
And users can change the color.
They can change the size of the text.
They can even change the position of the lens.
And so we really see extensions
as a really powerful way to allow users
to customize their entire world on the web.
And ChromeVis was an example of that.
Mazzoni: The last extension I want to talk about
is called ChromeShades, which we just released.
And this is different.
This is an accessibility tool entirely for developers.
And in fact, it's entirely for sighted developers.
Because I found myself as a sighted developer
who is interested in building more web applications
that are accessible to people with screen readers
and magnifiers and other assistive technology.
The problem I found is that as a--
Because I'm not a screen reader user,
it was a little bit cumbersome for me
to keep turning on a screen reader,
testing out my application,
then turning it off, going back to coding,
because keeping it on all the time and jabbering
is not the experience I'm used to.
So I wanted a tool that would help me find and identify
accessibility problems quickly
without going through the same experience.
And so ChromeShades transforms your web page
into a visual experience
that helps highlight potential accessibility problems.
It highlights which controls are focusable and interactive
and different roles, whether you're using ARIA
or whether you're using native controls.
You can continue to interact with your application
just as you would normally.
So you can test you your whole application
and visually see at a glance if there are any problems,
which can be a lot faster for development.
So the source code to all of these extensions
is available on Google code.
Of course everything here is open-source.
And if you're interested in how any of these things work
or if you have ideas on how you can build
on any of these extensions or the ideas behind them
to make things accessible to different users
or just to get an idea of how to make
your own web app accessible,
you can check out the source code
or interact with us by taking a look at that.
Shearer: And we're also at the Developer Sandbox.
So if you want to talk to us in person
and maybe try out some of these extensions,
we'd be more than happy to demo those for you.
But we've reached the end of our presentation.
So I wanted to leave you with a few final thoughts.
First of which is that,
as we said at the beginning of the presentation,
an accessible website does not have to be
a static, slow, HTML site.
With just a little bit more work,
you can deliver to your users
an interactive, dynamic experience
that's gonna be fun for them to use.
And the first step down this road,
as I said as I was stalling for time,
is just unplug your mouse.
All you have to do is unplug your mouse
and try out your app or your favorite web app
and you really might be surprised at what you find.
It's the quickest way to figure out
what the problems are
for users that aren't gonna be using a mouse
to access your site.
And finally, HTML5 and ARIA
are gonna get you the rest of the way there.
With just a little bit of extra work,
you can really give users of assistive technology
an experience that rivals the experience of any other user
without building a separate page.
So it can be the same page for everybody,
and that's really the goal here.
So we hope you enjoyed the presentation.
We hope that you learned something.
We have a feedback link at the top.
It's goo.gl/eWAqj if you wrote that down.
We also have hashtags
if you can tweet about the presentation.
And of course the presentation code
is on our Google Code site.
And feel free to stop by the Sandbox
and talk to us in person.
Mazzoni: Any questions while we're right here?
Yeah, someone's coming up.
man: The--I looked on the web store
for those extensions you were just talking about.
I found ChromeShades and ChromeVis,
but ChromeVox was not listed.
Shearer: The reason-- Oh, sorry.
man: No, go ahead.
Shearer: The reason why ChromeVox
is not on the web store is because it uses
the experimental TTS API.
And because that's still experimental,
we can't put it on the gallery.
man: So how do you install it then?
Shearer: On our Google Code site,
you can actually get the package CRX
and you can actually also build it from source.
man: Thank you.
Mazzoni: So yeah, as soon as the TTS extension
becomes a part of stable Chrome,
we'll definitely put this on the web store.
And we're planning also a separate launch
with more features to integrate with Chrome
on platforms other than Chrome OS.
Today we're essentially launching
for all users on Chrome OS
and essentially for developers who are more comfortable
doing things like building from source
or downloading and installing the extensions separately.
So essentially this launch of ChromeVox
on other platforms is for the audience here, developers.
man: Hello. Oh, okay.
So about managing the focus on dialogs,
is there any other way to keep the focus
from escaping that dialog,
instead of using JavaScript, like using ARIA role
or a property or something like that?
Mazzoni: So that's a really good question.
The question is, is there any other way
to keep focus inside of something like a dialog?
I've experimented with this a bit in different browsers
and screen readers.
There is no one solution
that works across all browsers and screen readers
other than listening for focus events,
because focus is not a cancelable event
as part of the HTML standard.
So this is by design.
You can listen to the focus event
and move it back.
There's one exception,
which is that if you're using Safari on Mac OS X,
it implements the dialog role slightly differently
so that it actually treats the dialog
as essentially a separate region of the page.
And by default, all of the control
will be trapped within the dialog
in Safari with the Mac screen reader.
So users get a slightly better experience there,
and they can choose to escape the dialog with one extra step.
But across other browsers
right now there isn't a solution for that.
That's something we're definitely considering
for ChromeVox, so it's a good question.
man: Okay, thanks.
Mazzoni: Another question here.
man: Yeah, does ARIA validates on W3C validator,
HTML5 validator, or those kind of tools?
Mazzoni: The question was,
does ARIA validate with W3C validators?
There might be some ARIA tags that do,
but the experience we've had
is that validators work great for static web pages.
And they're not going to help in order to determine
whether something really is accessible.
Validators should be recognizing ARIA tags
as valid syntax so they should tell you
that the syntax is correct,
but they're not going to tell you
whether you've actually semantically implemented
things correctly.
It's a little bit beyond what a validator can do.
But this--since this is part of the HTML5 standard,
there's no reason it shouldn't validate.
man: Beyond what you'd already talked about,
making an accessible website that's also dynamic
and interesting, do you foresee any issues
of being Section 508 compliant?
Mazzoni: Can you elaborate on the question?
You're asking, like, what other issues
do you see in being Section 508 compliant?
Do you mean from the perspective of a web developer
what else they need to do?
man: I was thinking more like
making an HTML5 website,
are there particular complications
to being Section 508 compliant
that go beyond just, you know,
what you've recommended in this session?
Mazzoni: So what I would say there is,
that Section 508 compliance-- for people who don't know,
it's a compliance standard that essentially
gives a checklist of a bunch of different ways
in which a website or lots of other types of products
should be accessible to people
with a wide range of disabilities.
Section 508 compliant is mostly,
at least for the web,
focused on things that are a little bit more static
or just things like whether something
can be interacted with at all.
There are a lot of things that we didn't cover
in this presentation
because there's a lot of resources on it.
For example, a lot of people are color-blind
or have partial low-vision,
so they might need larger fonts.
We didn't talk about those issues
because they don't relate to interactivity.
We've been just talking about the issue of interactivity.
And for interactivity, the things we've talked about
in working with ARIA,
specifically the ARIA roles to deal with interactive controls
and managing focus and keyboard handlers,
those are the things you need to do
in order to make something work
when you've got an interactive website.
But there are tons of other aspects
to accessibility.
Most of those are not necessarily affected
just because you have an interactive Web 2.0 app
as opposed to, like, a more static web page.
So there's tons of resources
on all the other types of accessibility,
and if you want we can talk about some of those offline.
And--Oh, another question coming up.
man: HTML5 is also about mobile applications.
Is there any supportive ARIA in mobile browsers?
And how do you deal with focus issues
on multi-touch devices for instance?
Mazzoni: That's a really good question.
There is some ARIA support in mobile browsers already
on, like, right now there's a great support
on the iPhone and iOS devices.
And you'll see some cool things
coming to Android at some point.
But yeah, focus is definitely something
that can be different.
Right now I guess I'll just say that
that on iOS there is a concept of focus
when people are using the voiceover on iOS.
And so a lot of these things do apply.
But we could probably do a whole talk
on accessibility for mobile,
which is definitely a different experience.
Shearer: It's definitely something that's defin--
really an emerging field.
I mean, if you think back even a few years ago,
it was only static, you know, websites
that you could see on mobile.
So this is definitely something
where there's a lot of changes happening very fast.
Mazzoni: That's a very good question though.
man: Thanks.
Mazzoni: Okay, I don't see any other questions,
but we'll be up here if anyone wants to talk to us
about anything else.
And thank you very much.
Shearer: Thank you.