[MUSIC PLAYING] JEN DEVINS: Hi, everybody. Thanks for coming. We're really excited to
have you all here today. My name is Jen Devins. I lead the user experience
team for Google accessibility. And with me, I
have Andrea Wong-- she's a researcher
on accessibility; Catherine Idylle, who is a
designer on accessibility; and Bethany Fong, who is
the lead designer on Google material design. We're really happy to have
such a great crowd here that's interested in inclusive
design and accessibility, and we're looking forward
to sharing with you how you can make your
products more inclusive. But before we dive in
and get into specifics, we wanted to start
with just some basics-- what is accessibility, inclusive
design, and why it's important. As described by the Web
Accessibility Initiative, accessibility, usability,
and inclusive design are all very closely related. Their goals, approaches,
and guidelines overlap significantly. And when we sit down to
design and develop our apps, it's really effective to
address them together. Let's start with accessibility. Accessibility focuses
on enabling users with disabilities to perceive,
interact, understand, and navigate tools and
services and products, and that they can contribute
equally without barriers. Now, some of the guidelines we
think about with accessibility, such as clear color contrast
or clear, concise writing, are useful not only to
users with disabilities but also those that might be-- or that don't have
disabilities but might be in different situations. For example, we know
that alternative text can be useful to users who are
blind and can't see the screen, as it describes the
imagery and visual icons. Alternative text can
also be useful to users who might be out in remote
locations with low bandwidth or using old technology. Another example-- it's clear
that providing enough time for users to interact with
and read content on the screen is useful for users who
might have a motor impairment or cognitive impairment. This extra time is also
very useful for users that might be learning
a new language or have low literacy, or
children learning to read, or simply just
people distracted. And this is how accessibility
is a key component of inclusive design. Inclusive design is all about
considering the wide range of human abilities. We think of age, gender,
ethnicity, and others. And as you can
see, accessibility overlaps significantly
with these areas as well. And that's why we feel
like accessibility is a really clear starting point. So at this point, we could
just throw up on the screen a checklist of
guidelines for you to follow to ensure that
your product is accessible. And that's a great place to
start, no doubt about it. However, what we've
seen is that may often lead to a product that's
technically accessible but not necessarily usable, let alone a
great experience for all users. And this is where
usability comes into play. Now how many people, by
a quick show of hands, take time to reach out and get
feedback and input from users? Quick show of hands-- right. It's an important and really
useful thing to do, right? Unfortunately, we know that a
lot of users with disabilities are left out of this really key
critical point in the process. If we're not out there talking
and observing our users, we'll never understand, what
are their true experiences? What are their challenges? And most importantly,
what are their insights that could actually
benefit everyone? And in the end, you
could be left missing out on a large number
of potential users and also miss out on helping
existing users who might be in these limiting situations. OK, so that's the basics. We've got the stage set. Now, we want to walk you
through more of a case study to demonstrate how
to design and develop with accessibility in mind. Today, we're going to
use our fictional app. It's a travel and
hospitality app called Crane. And we're going to use this
throughout the rest of the talk to demonstrate specifics of
how to make products more inclusive using the standard
user-centered design methodologies, as well as
material design system, which includes clear guidelines,
components, and tooling. So to get this started,
we're going to break it down into four primary stages. We have defining the product
vision, design, development, and after design. Now, this framework probably
seems familiar to you, and that's on purpose. We're not here to introduce
yet another process for you to follow. Instead, we see this as a
tool kit of ideas and things that you can do to
enhance your product to make it more inclusive,
because in the end, inclusive design is really
just simply good design. OK, so now Andrea is going to
walk through the first stage of defining the product vision. ANDREA WONG: Thanks, Jen. Stage one, defining
the product vision. No matter what you're
building, understanding what problems you're
solving for users is the key to product success. So who are your users? Most teams start
with the assumption that all their users
are fully-abled, but that may not
always be the case. So let's say you're
building a photos app. And you think, well, why
would someone who is blind use my photos app? Actually, a person who
is blind may use your app because they want to
take photos and then share them with
friends and families or post them on social media,
just like everyone else. Consider these three
people on the screen. There's a man in a wheelchair
with Lou Gehrig's disease. So he has impaired
motor functioning for upper and lower body. There's a boy with a broken arm. And there's a woman holding
a full bag of groceries. Let's have a pop quiz. Which of these three people
have limited mobility. Raise their hand if you think
it's the man in the wheelchair. OK, hands down. Raise your hand if you
think it's the boy. Thank you. And lastly, raise your hand
if you think it's the woman. So if you raised your hands all
three times, you're correct. All three of them have
a different relationship with limited mobility,
whether it's permanent, like the man; temporary,
like the boy; or situational, like the woman
with the groceries. Yet, they're all experiencing
the exact same need right now. It's a good reminder that
for every single one of us, we'll have accessibility
needs at some point throughout our lifetime. Disability is a much broader
term than we might think. And often, when something
doesn't work well for a user with no
disabilities, that pain point is amplified for people
with disabilities. And that's actually
good news for you, because it gives you much
clearer signals of what you should be focusing on. Because when everything doesn't
work-- when something doesn't work for everyone, it
clearly is something that you should be
paying attention to. And that's, in fact, what
we found with our studies at Google. All users have the same core
needs because they're all trying to meet the
same goal, whether it's sending a photograph,
writing a email, buying CryptoKitties,
whatever it is. So at this point, you're
probably asking, well, how do I do research with
people with disabilities? The answer is do
what you usually do. Are you, let's say
in the early stage right now, where you're
just chatting and sitting down and talking to users? If you are, that's actually
the easiest and the best time to be including users with
disabilities into your process, because you can get their
context, their needs, and everything right
from the very start. You can ask the
exact same questions as you would to someone
without disabilities. The only difference
is you have to ask a few additional questions about
this assistive technologies they may be using and
their context of use. So for example,
you'll be asking, say, how do you use your
assistive technologies when you're navigating
a mobile device? Or how does your
impairment impact or not impact your interactions
when you're planning travel? Or maybe even, which
workarounds, if any, do you use to get
to what you need? And always, always follow
up after each question with, why, tell me more,
to really dig in there to get to the
context of their needs. The bonus here is
their answers may inspire new ways of
interactions they've never thought of before. Or maybe you're past
that stage already. That's fine. Right now, you're testing a
low-fidelity paper prototype. That's fine. You can still test with
people with disabilities. Let's say you're testing with
a user who is blind and uses a screen reader, which is an
assistive at the technology that reads out loud the
contents on the screen. So you're doing that, but
you don't have a screen reader-friendly prototype. What you can do here,
though, is write a script of what the
screen reader might verbalize and have
someone on your team act as a screen reader. And that person can read each
step out loud to the user as they walk through the user
flow during the study session. By integrating people with
disabilities, whenever you're talking to people
without disabilities, you're automatically ensuring
that their viewpoints will be included and
part of the process throughout the entire design
and the development phases. Along with understanding
user needs, you need to have a
general comprehension of assistive technologies
and the different tools that people may use
interact with your product. Trying the technologies yourself
is a great place to start, but the best way to learn is
to observe the real experts. Those are the people who
use these technologies day in and day out. And if you can't find someone
to observe in real life, that's OK. You can just go online and ask--
look for any kind of video. Whether it's like
going to the ATM, going to the
grocery store, there are countless
great videos online to explain the different
ways people use different technologies. The goal here is
to understand what makes a good versus a
poor experience, what are the common pitfalls, and
the standard expectations that people have when
using your site or app. Later, using our fictional
app, Crane, we'll walk you through designing
a great keyboard navigation model. Starting with a keyboard
navigation model creates a very good
foundation for you when building for other
assistive technologies, which we won't go into here. You may be feeling a bit
overwhelmed right now at how to design to meet
all those needs, but the great thing
about design inclusively is that people on
teams have been working for years to understand what
design inclusively actually means. So as Jen mentioned,
material design components includes accessibility
guidelines baked right in that anyone
can follow, regardless of the size of your team. Doing the right
thing, though, isn't necessarily mutually exclusive
to good business sense either. It could even increase
your market share. According to the American
Institute of Research, who came out with this
report a few months ago, working-age people with
disabilities in the US alone have a discretionary
income of $21 billion. That's the third largest market
segment in the entire country. Then, if you think about
their families and friends who may also use your product to
interact with them, or they may just simply
appreciate good design. And this is not
just the US alone. According to Gartner,
people with disabilities and their friends
and family worldwide have a collective disposable
income of $8 trillion dollars. Think about that. OK, that was a lot
of information, so let's go over the important
points to keep in mind. One, talk to people
with disabilities to inform your product vision. Two, learn assistive
technologies from the experts. And three, build a better
experience for all users and potentially capture
more market share. Now, I'm going to hand it
over to Catherine, who's going to go over stage two, design. CATHERINE IDYLLE: Right here. ANDREA WONG: Oh,
you're right here. CATHERINE IDYLLE:
Thanks, Andrea. [APPLAUSE] Hi. Now that you've defined
your product vision, it's time to design your app. At this stage,
you'll need to think about interaction design, visual
design, UX writing, and motion design. But don't worry. We'll do a design
challenge together using our fictional app,
Crane, to learn how to do this. So Crane is a travel
and hospitality app that lets users book flights
and accommodations on a computer or phone. In terms of
interaction design, you might be wondering,
how do I even get started design accessible
and usable experience for everyone? Well, design as you normally do. Have your wireframes
and your sketches, and we'll get started there. This is a wireframe of filter
options on mobile when you search for a flight on Crane. Here, we can see that
the checkboxes are aligned with the label, but
they're pretty far apart. When designing your layout,
ensured that related content and controls are
grouped together. This makes it
easier to understand and also easier to reach for
people with motor disabilities, especially for people with ALS
or a traveler on a bumpy train. So what we did here is that
we placed the checkboxes right next to the labels. It's just a better
experience for everyone. In terms of
interaction design, you can also have a huge
impact on all users by thinking about the
tab interaction model, meaning a great
keyboard experience. Here, we have a wireframe on web
of the flight search results. Tabbing on the keyboard
allows you to jump from one interactive element
on the screen, as we can see right here. This would be the
default tab experience if we didn't design it at all. It would take 94
tabs stops to go from point A, the back button,
to point B, the filter options. This is a slow experience. So what we can do is
actually group major elements together, like this list
of individual flights. Now, it only takes seven
tab stops to reach point B. And once you've grouped
your big tab stops together, don't forget how to
quickly navigate to those smaller elements, such
as the individual flights in this big list of flights. Here, we'll go with an
up and down arrow option to navigate between them. Overall, this is a much better
and productive experience for power users, much like
yourselves right here, and assistive tech users alike. Here are some things
you can do to make your app more accessible in
terms of interaction design. Group your content and
your controls together. Design your tab
interaction model. And don't forget the
error navigation as well. Now, onto Bethany to
talk about visual design. [APPLAUSE] BETHANY FONG: Thanks, Catherine. So now that we've
laid a good foundation in terms of interaction design,
let's refine our visuals. Now, to start with
the very basics, I'm sure you all have felt the
pain of viewing light gray text on light gray background. Let's not put our
users through that. So the number one way that you
can be a hero for these users is by ensuring that
color contrast is-- between your foreground and
your background colors is going to be high enough. And you can use our
material color tool, pictured here, to check the
legibility of your choices and check them against
different background colors, like the three shades of purple
here that we were exploring for the Crane app. So let's apply this. Going back to our
app, where the user is filling in their information
to purchase their flight, these faded colors that
you see are trendy, but the contrast
is so low that it's hard for even most
sighted users to have a legible experience here. And remember, this is going to
be better not just for users with low vision but
someone with dilated eyes after a doctor's
appointment or people like yourselves, out
in the sun all day with glare on your screen. So let's add more
color contrast. First, we're going to zoom
in on how we can add contrast into the text field component. We increase the font
weight and color darkness in the text fields, which
makes it easier to scan and ensures a better
visual hierarchy. And we also increase the
background color darkness on the button at the bottom,
making the text more legible and making the
call-to-action much easier to spot, which is
really important, because you're trying to
get your users to purchase something here. And already with the
before and after, you can see that this
is a much better design. Other than just looking
more aesthetically pleasing, the text is more legible. The relative importance
of elements is clearer. And the call-to-action
are a lot easier to spot. So now, your user is
filling in their information into those much
better text fields and is getting closer
to booking that flight. But it looks like
they made an error. Some users can tell because
of the bolded orange outline. However, some users
with color blindness might miss this important
piece of information, and this can be fixed
by supplementing any information that's coded
in color through other means, like icons or shapes. So we're going to check
out the material icon site and search for error icons. It's good to use a central
resource like this, because these are common
visual metaphors that may be recognizable to
a wide variety of users. So it looks like we can
go ahead and use this one. So we're going to download
it, add it to our text field, and now, there are
two ways to understand that this is an error state. And this makes it clearer
for everyone, not just users who are color blind. And for our last
visual design example, let's look at focus state
and element size on screen. So when users choose a
seat in this travel app, it's important that they can
select the seat that they want and that they know that their
selection was successful. And on mobile, this means
having a touch target size of 48 dp by 48 dp, or
about seven millimeters wide, which is calibrated against
the size of an adult fingertip. Makes sense. And on web, try to ensure that
your focus is highly visible. You can see it as a bold
purple outline around seat 8A. So when you're doing
your visual design, when keeping it accessible, make
sure that you have high color contrast. Make sure that you have
multiple visible indicators for any important
component states. And lastly, make sure
that your touch target sizes are going
to be large enough for people to actually reach. Back over to Catherine. [APPLAUSE] CATHERINE IDYLLE:
Thanks, Bethany. I'm back. With writing, you have the
power to guide all users with accessible onscreen
text, as well as meaningful off-screen
text that'll be verbalized by
the screen reader. A screen reader is
software that sits between you and the application,
and it works in tandem with the keyboard. The keyboard moves the
focus, and the screen reader will verbalize whatever
has come into focus. We have this example
from Google.org com, if you heard of it, and
it'll read this button as Google Search button. Because a screen reader
automatically reads out loud the label, Google Search,
and the control type, button. So back to our Crane app. Here we have a checkout screen. It has several
interactive elements, but let's just focus
on these four buttons. And remember, the screen
reader automatically reads out loud the control type. So it'll verbalize these buttons
as button, button, button, button. That's problematic. We don't know what
the buttons will do, and the council order and
complete order actions are right next to
each other, which could lead to major user error. Instead, what we can do is
add meaningful and concise accessory labels in addition
to the default button verbalization. So here, we've added Previous
Step, Checkout Progress, Cancel Order, and Checkout Order. Now, we know what
each button will do, and there won't be a major gaffe
of canceling order rather than completing one, and vice versa. You can be a champion
for screen reader users by writing accessory
labels in addition to the default verbalization
provided by screen readers. In terms of motion
design, have you had something important
flash before your eyes, blink, and then be gone? Well, this just happened to
you and is a major pain point for users with low
vision or someone who isn't paying attention. Try to ensure that
alerts, like snack bars, are present on the screen long
enough so that everyone can see them, like right now,
and have an option to easily dismiss them, like
dismiss button or a tapping out function. Likewise, consider supporting
screen magnification users. Here on web, when a
user hovers over a seat, they get additional information
about that seat in a hover card, but it covers the rest
of the screen when magnified. To help our users get back
to whatever they were doing, consider an easy escape hatch,
such as an escape key shortcut or a close button. To ensure that your
motion design accessible, present alerts for long
enough, and have an option to easily dismiss them. Likewise, easily escape
hover information during screening magnification. At this stage, we have designed
the interactive, visual, writing, and motion
aspects of our product. Now, it's time to talk to users. Get some feedback and check
if you're on the right track. Also, see if you run
into any major blockers you didn't anticipate. Consider running a
heuristic evaluation. It consists of having a
small set of examiners evaluate your app against known
usability principles, otherwise called heuristics. So right here, we have three
heuristics from the material design accessibility
guidelines, and they're clear, they're robust, and specific. So let's check. Is your app clear, meaning
are its layouts non-crowded, and are its calls-to-action
visually distinct? Is your app robust? Does it support a variety
of user capabilities? Finally, is your app specific? Does it specifically support
a variety of user technologies in the ways that
the user expects? Let's try this out with Crane. So here, we have two
button variations, and we want to see if it's clear
enough for low-vision users. Well, we may find that
these two buttons actually have the same color contrast. But we may also find that people
prefer the one on the right, because the shopping cart icon
makes the purpose of the button more obvious for people with
and without disabilities. After you're completing
your product, conduct a heuristics
evaluation, and feel free to use the accessibility
guidelines provided by material design. Is your app clear,
robust, and specific? Now, back to Bethany on
how to develop your app. BETHANY FONG: Thanks, Catherine. [APPLAUSE] So you've moved on to
the development stage. And you'll want to make sure
that all of those decisions you just made in the
design stage pull through to the final product. So the first thing you can
do is use standard components when designing. If you use material components,
that will be pre-vetted, work well within a
holistic design system, and they'll be usable and
recognizable to your users. If you do something
nonstandard, note that you'll perhaps have to
design the full component yourself, as well
as marking it up with the appropriate metadata,
particularly for screen reader users. You'll need to provide labels,
structure, and traversal paths. And designers, one
tool that you can use is Gallery, created
by Google to help you manage design iterations
and get quick design feedback. If you use our
material theme editor with Sketch, which is
a popular design tool, and upload your
mocks to Gallery, you'll automatically see all
measurements, or red lines, as designers call them. For example, you can see here
how large this price text is and make sure that
the touch target size is going to be large
enough to be tappable for people with hand tremor. You can also use it to
communicate back and forth with your team about
accessibility markup and any verbalizations
or UX writing that you might want to do. And don't forget to
use scalable text. This allows for a piece of
text to scale up or down, according to the user's
individual settings. This is really important
for users with low vision who may have large
text turned on, but usually, the rest of the
UI remains the same size. So follow the specific
platform standards for how scalable text
should be implemented. And here's the same screen with
the large text now rendered correctly. You can actually read
it, which is great. So engineers, you can keep
users with various impairments in mind as you code, just as
a designer would periodically consider a user with
low vision, no vision, or some mobility challenges. And one way of
focusing this work is to schedule
periodic bug bashes and fix-its from a specifically
accessibility point of view. And there's also
a number of tools that you can use
during development to check your accessibility
on web and on Android. These include
Accessibility Scanner on Android, which is the
app shown here, which is really easy to use,
because it checks your app screen by screen for any
accessibility errors. And come by the Accessibility
Sandbox during I/O to speak for engineers to
learn about other dev tools that you can use during
your own process. So as you're
developing, don't forget to use common components
when you can and just inherit the work that we've
already done for you there. Use scalable text, and use
accessibility development tools throughout your process to
check yourself as you go. All right. ANDREA WONG: Thanks, Bethany. So now, I'm going to talk about
the last stage, stage four, after development. At this point, the bulk of your
development work is complete, and you're about to launch. At this time, we recommend using
a tool like Pre-Launch Report from the Google Play Store. Some of you may already be
using Pre-Launch Report, but the good news is, it
now includes accessibility. So upload your app to
alpha or beta channel, and it'll crawl through your
app to identify a number of ways to improve it, like crashes,
latency issues, and, of course, accessibility. And you won't need to instrument
your app ahead of time. For the web, we recommend
automated accessibility tools that's built right into
our Chrome DevTools. So inside the
Audits panel, you'll see a tool called Lighthouse. Lighthouse will run
about 40 automated tests against your site to check for
common accessibility issues. When it's finished,
it'll give you a score. It'll point out the
failing elements. And the best part is, it'll
link you to documentation with instructions on how to
fix those failing elements. And if you've done everything
right up to this point, if you've listened to all
of us, then everything here should be a breeze. One more thing-- no great
onboarding experience is complete without
good help content. And help content is a resource
that people with disabilities often utilize. So make sure you include in
help content on accessibility, and make sure that content
is actually accessible. This is a great opportunity
to help all users get off to a great start with
your app or your product and recover quickly
when they get stuck. Yay, you've launched. Now that we're here,
you're probably going through your
metrics, your analytics. You're checking the
effectiveness of your launch, the user engagement,
and so forth. You're hopefully also
doing user studies, and you're measuring
satisfaction to see how well your app is
being received by everyone. At this point, include
respondents with accessibility needs so that you're
hearing all the feedback. This is also the perfect
time to stop and understand what benefits your team has
reaped from design inclusively from the very beginning. So here, do a post-mortem. Decide what to cut, what
to keep, what to change, and apply that to
your next cycle. Over time design inclusive will
become second nature to you. Let's go over the main points. One, check for common
accessibility issues with Pre-Launch
Report and Lighthouse and countless other
tools out there. Make sure you have accessibility
help content that's accessible. And get feedback from
users with disabilities. And now, Jen will
summarize all this for us. JEN DEVINS: Thank you, Andrea. All right, so there you have
it, our tool kit of ideas that, hopefully, you can
apply to your process. We know it's a lot
of information. There's a lot of great resources
out there that you can rely on. We wanted to leave
you with one thing you can do during each stage
of the process starting today. So if you're starting
out and you're defining your product vision,
can't stress it enough-- get out there and talk to users. If you're curious
of, where should I find users with disabilities? I don't know anyone. There's lots of organizations
nationally and internationally that you can reach out to,
and they'll often put you in contact with their members. And in fact, today in the
Design and Accessibility Sandbox across the way, there are
members from the National Federation of the
Blind that are willing and wanting to give you feedback
or just answer your questions. If you're in the design
stage, you probably started working on your
interaction workflow model, and you're thinking about
it, have it drafted. Before you get too far, take
a step back and think, now, how would a user that's
using just a keyboard go through this
interaction model? How would they get
their task done? This is a great place
to start, and you'll be very happy you did
this earlier than later. If you're in the development
stage, use standard components. They've been
stress-test, and they're familiar to users,
which is great. You don't want users
to have to relearn their app for each screen. And finally, if you're
nearing that finish line and it's after development,
just as Andrea mentioned, we really recommend
ensuring that you have accessible onboarding
and help content and, if it makes
sense for your app, to have accessibility-focused
tutorials and onboarding material. Making inclusive
products is critical. We all have the power
and responsibility to remove barriers
and empower all users to be productive and connected. [MUSIC PLAYING] Thank you so much for your time. [APPLAUSE] [MUSIC PLAYING]
