[MUSIC PLAYING]
JENINE DURLAND: Hi, there.
I'm Jenine Durland, and I run the UX accessibility design
training program here at Google.
And it's a lot of words, but essentially, I
help our design and our research teams
understand and then implement best practices to make
products more accessible.
So today, I am super excited to share a framework that we've
developed over the last many, many years that incorporates
standards from WCAG and W3C and ARIA
into a usable, step-by-step framework.
So let's get started.
Here's what we'll be going through,
just a quick intro over accessible design.
We have our framework, whose main elements are
structure, flow, and elements.
And then we'll just talk about putting it together
and what artifacts you may need.
So here, we have a quite beautiful quote
from Kat Holmes.
She says, "What happens when a designed object rejects us?
For better or worse, the people who
design the touchpoints of society
determine who can participate and who's left out."
And this is why we're here, right?
Both to design better from the start
and to make sure those user experience decisions
are passed on to our engineering partners.
Accessible design doesn't mean you're
designing one thing for all.
You're designing a diversity of ways
to help everyone participate.
And designing for diversity can be challenging.
This is not a one-size-fits-all approach.
But with ample research and design,
you'll be in a much better position
to create products that are more accessible for as many people
as possible.
So how do we begin to think about the diversity
of human ability?
When it comes to accessibility, we focus on four main areas
where users experience impairments--
with vision, with hearing, with motor function,
and with cognitive function.
These are generally what we'd call permanent disabilities.
But check out that last item there we
have under "cognitive"-- high stress.
This may be a broader definition of ability
than you're used to seeing.
And now look at what happens when we add more
temporal aspects to this list.
I mean, have you ever tried to use your phone
while you're carrying a baby or checking your watch?
We all fit into one or more of these groups
on a regular basis.
Because when we talk about accessibility,
we're talking not just about permanent disabilities
but temporary disabilities as well.
All of these scenarios help us design for broader audiences.
So how do we do this?
And once we've done it, how do we make sure
we're communicating these complex user experience
decisions to our eng partners?
Here, we have the main stages of the product journey.
The areas of research and testing
are vital, vital aspects of understanding your product's
audiences and accessibility needs in addition
to the design and eng phase.
So this funnel makes it look like an entirely
linear process, but it really isn't, right?
Making products more accessible is
a fluid and iterative collaboration
between all teams.
So while there are many considerations
to weigh when making a product more accessible,
we're going to focus on the sweet spot between UX
and engineering.
This is where a wealth of interactions
get decided and coded.
Here with our framework, we start to think about,
how do we bundle all of these considerations
when approaching design?
And when I first came to Google, this
is exactly what I was tasked with doing.
So over the years and through a lot
of cross-functional collaboration,
we've come up with best practices and a process
to help make products more accessible.
And I will let you know ahead of time that this content is
all up on material.io.
So you don't have to worry too much about getting
all the details down.
What we're really doing is going over an overview,
a big-picture view.
So this big picture, the accessible design framework.
Here, we have visual design, structure, flow, and elements.
And well, we begin with research,
very important aspect of this.
We begin with our research to understand our primary user
journeys and usability issues.
We rely on our visual design reviews
to address many, many visual and content checks.
And from there, we move to an interaction-based framework
to help tackle the more technical aspects of accessible
design.
So we found it helpful to bucket these items into structure,
flow, and elements.
So before getting into the interaction patterns,
there are some best practices to consider at the design phase.
These are referenced on material.io,
and they focus on curating your content and your design
with specific visual affordances, things
like touch targets, contrast.
This is a great opportunity to think
through the holistic challenges of accessible design
before diving into the technical interaction patterns.
From visual design, we move into structure.
This is important for assistive technology,
including our brains, because we rely on clear,
delineated structure to process a page, right?
And AT, which is Assistive Technology abbreviated--
ATs such as screen readers, they navigate primarily
through the use of headings and landmarks.
So thoughtful decisions here really
help reduce friction for our users.
Remember that many assistive technologies,
such as screen readers, they translate your design
to a linear experience.
So users interact with the content in a predetermined,
one-by-one order.
What this means is that thinking through structural decisions
impacts the accessibility of your product.
Start with landmarks.
Those are shown here.
These are specific to web.
And you can find more information about them
on WCAG and on material.io.
Essentially, landmarks help users navigate
and identify content quickly.
They also force our designers to really think about,
what is the main content of your page?
And that can sometimes be really challenging.
With mobile, landmarks specifically as
called "landmarks," they don't apply.
But you can group content areas to help clarify
navigation and a user journey.
So moving onto headings, we get more
into the hierarchy of a page and the content
that you have there.
So screen readers use headings to navigate.
I mentioned that earlier.
And sighted users use visual layout
to convey relative importance or hierarchy and group
elements or content.
So when it comes to assistive technology,
we recommend using headings to help
establish those same things.
Now, when we talk about headings,
we are talking about the H1, H2s, and so on in your code.
And we're also talking about the labels associated with them.
Words and order really matter here.
And in doing this exercise, you may
find that additional headings may
be helpful in your visible UI for all users.
So you go back to your design teams, and you add those in.
Or you may want to add what we call invisible headings that
can be added just for AT users to provide more context.
This is really a great opportunity
to look critically at the content for any opportunities
to streamline or improve.
So here, I'm annotating the Google Search page.
The accessibility tree in Chrome Developer Tools
can really help you understand these semantics
by seeing the structure of existing pages.
Notice in the H1 example that we're adding these invisible
headings to help with context and navigation.
The label "search results" will be
read by assistive technology.
Note also there are H2s for a complimentary sidebar.
But they're not shown in this mock.
They're actually hidden in the code.
Again, you can learn more about all
of this on Material or WCAG, or pull up the developer tools
and check out code for yourself.
So next, we get to talk about flow.
Flow's really about thinking through the linear order
of your UI.
So whether you're a user using a screen reader or a keyboard
or you're swiping on a mobile device,
they're going to interact with your application
in a linear order.
So to help users navigate linearly through the UI,
it's important to be really intentional about focus, tab,
and arrow key decisions.
So a default DOM for tab order will run left to right, top
to bottom in languages like English.
And our job is to make sure that journey is efficient
so folks can get to the main content and actions easily.
The first consideration is where you
want users to land both at the page and the component level.
So this is called focus.
And there are also some ways to help users
jump right into main tasks.
So an example here is from Calendar,
where they've added a Skip To Main shortcut.
And this allows users to jump right into the calendar
or report accessibility feedback right from the get-go.
Can be super helpful.
So we've talked about the concept of focus.
And we've talked about how assistive technology users
navigate in a linear fashion.
But how do they actually navigate, especially
with keyboard?
So Tab is the primary key.
Tab allows us to traverse from top-level interactive elements,
like one button to the next or one link to the next.
And then arrow keys allow users to move within components.
So the overall goal here is to reduce
the friction and the amount of key presses needed for users
to complete their tasks.
So one overall design consideration
is to simplify the user experience.
And so clustering related items can really improve the user
experience for keyboard users.
As you can learn from WCAG and ARIA standards,
components have built-in keyboard expectations.
So a navigation menu, for instance,
it will default to arrow key navigation within list items,
reducing the number of overall tab stops
because you're using those arrow keys.
Here, with this set of cards, to traverse
from the first interactive element
to the last one in a single card,
I need to tap the Tab key nine times.
So if this happens to be a large grid of cards,
it might get really time consuming
to navigate to the final card.
So to improve the UX, you could group these elements
so that each card is a Tab stop.
All right.
So we're going to move onto the last aspect of the framework,
and that's elements.
So here, we're looking at the interactive elements of an app
and adding information to make sure
that the text-based user experience is
equitable to the visual one.
So identifying interactive elements,
adding labels, and hiding images totally help you achieve this.
So most UIs have some graphic elements, right?
It's information conveyed visually.
But in many instances, that visual information
isn't conveyed in text.
And this is where words really matter.
And I'm actually a poet, so this is one of the paths that
led me into this work.
So I want you to think about icons, images,
and all the interactive elements in your app.
If those don't have labels associated with them,
a screen reader is going to read the file name.
So you're trying to hit a button, interact with that,
and it's going to read 4583.png.
Is that helpful?
No.
And is that painful?
Yeah.
So to improve that, we can add a label.
And here, what we've done is add Download Image.
The other scenario we often deal with
is that we need to hide images.
And they're ones that just may not be relevant,
or they're going to create redundancy
for our assistive technology users.
And this is a tough decision.
This is a UX decision, for sure.
There are cases like here, with the Jamaican flag,
where the description provides critical information
for a person with visual impairment.
So I know we're moving through these quickly.
But I can tell you that we think a lot about what
makes an actionable label.
And we do have resources on that,
and you can find those on material.io, also.
So moving onto roles, this aspect of elements.
And you can read a lot about this on WCAG.
Defining rules is super important.
It helps ensure the intended user experience.
And it also helps engineers when they're
reviewing your static mocks if you're a designer.
It helps them understand the desired behavior.
What do you want to achieve in this experience?
So here in this slide, we have two buttons.
And visually, they look the same.
But how they're defined and coded changes how they behave.
So in the first example, the role
has been defined as a button.
So when we submit it, it'll keep the user in the flow.
And in the second version, this element
actually navigates me to a whole different page.
And because of that, its role is a link.
So in the world of the web, we use ARIA roles.
And those include defined accessibility behavior.
And just to talk about ARIA for a moment,
depending on your familiarity with front-end accessibility,
this could be a new term.
Luckily, there really are a lot of resources for teams
to learn more on ARIA on WCAG.
So the documentation-- excuse me-- the documentation,
it can be a little daunting.
So what we do is we focus on UX defining the interaction
pattern-- what do you want to have happen here-- and eng
diving into ARIA or their native mobile markup
to make sure that that happens.
OK, so let's look at some roles and labels in action.
So here, I'm annotating the Google Search page again.
And I have the accessibility tree in Chrome.
That can really help you understand these semantics
by seeing the structure of existing pages.
So notice that we have ARIA roles defining behavior,
and we have labels for icons.
Particularly, you can check out the little caret arrow
that's in the search results.
And that needs to be defined as a button
with the label defined.
And here, we have that as visible text.
So wrapping this all up, how do we put this all together?
The annotated mock we were just looking at of the Google Search
page is an example of how we mark up our framework.
So for UX design teams to communicate with our eng
and test partners, we need a clear way of accounting
for all this information.
And in this next section, I'll just
come back to some of these earlier examples you've
seen that just show a lightweight, Slides-based
method for sharing this information.
So you've seen this markup before from the Structure
section.
But including a mock specific for landmarks and headings
is a really helpful way of conveying decisions
without overwhelming the mock with too much metadata-- so
in other words, keeping that mock separate
from the flow and elements.
And then here again is an example
of markup for elements in flow.
And while approaches can and they
will vary on how to convey the information you're seeing,
it's easy to create a template in Slides or Figma
or whatever your design team works in
to overlay the framework.
Remember, you can go through all of this and dive
into more details in the material.io Accessibility
section.
And we hope this framework and process helps you
in your efforts.
And with that, it's a wrap.
Thank you for working in this really critical area of product
design.
[MUSIC PLAYING]