UNA KRAVETS: Welcome back to
"Designing in the Browser."
Today we're starting a special
series right here at home
on accessibility in design.
It's super important
to bake accessibility
in from the start, since good
structure, or a bad structure,
for that matter, scales
to your entire product.
So I'm really excited to create
this series of short episodes
on how you can give
all of your users
a better experience as
you build and design.
Disco is excited too.
Right, buddy?
So we've been talking and
decided the best place
to get started would be right
with where the content lives
in the markup, and
jump into semantics.
So let's get started.
[MUSIC PLAYING]
First of all, why is
this even important?
Why can't we just use
divs and call it a day?
Well, I'm glad you asked.
To understand this
better, I want
to illustrate how the browser
would parse your web page.
In the new Canary
experimental DevTools,
you can actually see a
little accessibility tab
on hover over your elements.
Here's what that looks like.
So I can open up DevTools here.
I like to do so through
the Inspect panel.
And there is a little
Inspection toggle here.
You can also hit
Command-Shift-C to open that up.
And when I'm toggling
over these elements,
you'll see not only the color,
font, and padding that you
would in normal inspection,
but with the new DevTools that
are coming to Chrome, you
see this Accessibility bar
here with some
accessibility information.
So under here you could see
the role of this is the Button.
And if I start to go
through this page,
you could see the
role of Banner here
for this web.dev live banner.
As I continue here, you
see a role of Heading.
Then you see a role of
Paragraph under that heading.
And I can just continue here.
This roll lists Time.
And here we have a link,
a couple of other links.
In addition to the role,
you see the contrast,
the name of this element, and if
it's keyboard focusable or not.
So this is a pretty cool
tool here that can show you
how users could
navigate the page
and what the various roles
are for these various elements
on your page.
If I scroll all the
way down at the bottom,
you can see that we have a
whole Navigation role here.
That's the macro element.
And then as I go in
here, there's links.
And these are all various links.
Here we have a
combo box that you
can click to drop down
and get more content there
to choose from.
So this is a language selector.
So you can clearly see here
how all of these roles and all
these various elements
make up the page
and really help users in
how they can access it.
You can see that a
lot of these elements,
like the headers and
paragraphs, specify
a type of element in the
DOM, Document Object Model.
The browser itself gives you a
lot of built-in accessibility,
so you should leverage
that when you can.
Where you can use
a semantic element,
like a main tag or article or
header or footer, you should.
Did you know there are
semantic elements for keyboard
characters, addresses,
details, dialog, maps,
and abbreviations?
These are always a much better
choice than your average div.
Another important distinction
is between links and buttons.
Links specify a
change in location,
whereas buttons
specify an action.
Now I know sometimes the design
calls for an element which
looks like a button, but acts
as a link into another page,
such as a Learn More
call to action in a card.
But this Learn
More call to action
would actually link
into another page.
This is a case where
you should semantically
be using a link in your
markup, but with CSS, you
can style that link
to look like a button.
Let's take a look at
what that looks like.
On this page, we see
this list of services.
And each of these cards
has a call to action
here to get started.
And this looks like a button,
but if we hit Inspect,
you can see that this
is actually a link.
So what we're doing here is
we're using a semantic link,
but then we're applying
the styling that gives it
a boxy-looking background, that
gives it this letter spacing,
this text transform
uppercase, all that fun stuff.
We're giving it
this hover state.
So what we're doing is
semantically keeping things
as they are by making sure that
a link is something that opens
into another page, not using
a button, which signifies
an action, and using CSS
to style this to have
it look however we want.
Native input and
semantic elements
give you automatic free and
effective keyboard navigation.
You can use Tab to go
forward through a website,
Shift-Tab to go backwards,
and the space bar, arrow keys,
or enter keys to
manipulate these elements.
Here I'm in a great
demo by Rob Dodson,
which is linked to a
wonderful blog post
that I will have in the
show notes for this video.
And here what he's
doing is showcasing
all of the various
HTML elements that
are native that aid in
this keyboard navigation.
So I'm just going to
go through and tab
through every one
of these elements,
or navigate through
them using my keyboard.
So you can see that this is
a multi-line content editor.
This one's content
editable, so I could just
delete the existing
content and then
update it to say whatever
I want to put in there.
Here you have Select.
So here I could hit
Shift and then Enter,
and select a different item.
With the multiple
select, as you're
tabbing through this
list, you can also
use that Shift to have
multiple items selected.
Or use Command, and then have
this Enter for the next item
that you want to use.
Then Tab will tab you
into that next element.
Here's a link.
If I hit Enter, it'll
open into a new window.
The next element here
that is a native element
is this range slider.
So you can use the left
and right arrow keys
to go through the different
items, values in this range
slider.
This is the date picker.
So I could go
numerically through this
and update the
month, date and year.
And here we have time.
So again, you could
change the hours, minutes,
and AM or PM individually using
both the Tab key and the arrow
keys.
And this is a Number input type.
So the number you could manually
enter using the keyboard,
or you can use the arrow
keys to go up or down,
changing that number input.
Here we have a Color input type.
So if I hit return, it's
going to open a color picker.
And I can use the arrow keys
to navigate this brightness,
this light versus dark meter
with the saturation that's
sort of the dark to light and
saturation level of this color.
But if you want to adjust
the hue, what you could do
is hit tab.
And now you are changing
the hue on this color wheel.
So that's how you can sort
of access all these colors.
You can go through and enter
any of these RGB values.
And then if you hit Tab
here and use the arrow keys,
you can adjust
the type of color.
So that can be HEX, RGB, or HSL.
Always you should be
able to hit Escape
to get out of these
experiences, and then
Tab to enter into
the next experience.
So here, this is
a File input type.
If I hit Enter, I could
then select a file
and have that be
chosen for this input.
If you don't use native
elements and build your own,
say you're building
a component to handle
the color picker instead
of a native color input,
you have a lot of catching up
to do regarding accessibility
and making the functionality
of that component
work in an accessible way.
There's just a lot
of room for error,
so I prefer using what
the browser gives us.
However, if a component
you're building
doesn't neatly tie with
some semantic markdown
or you need some more
complex interactions,
you can add ARIA roles.
ARIA stands for Accessible
Rich Internet Applications.
It's a specification
from the W3C
and was created to improve
accessibility of applications
by providing extra information
to assistive technologies,
such as screen
readers, by attributes
which could be added to HTML.
ARIA provides a long list
of possible role options
to help describe your
content to the browser.
Let's go over a few of the
different types of roles,
and then look at an example
of a more complex interaction.
First there are landmark roles.
Landmark roles identify
large content areas
and are used by screen
readers for navigation.
Many of these roles have
corresponding HTML elements,
such as main,
header, and footer.
Ideally, you should place
all of your macro content
into a landmark,
however, don't overdo it.
Having too many nav
or side elements
can make a web
page harder to use.
So make sure that you're
using them appropriately.
Section role equals
contentinfo is
an example of a
landmark role that
can be used to describe a
section within the footer that
contains the
document's meta content
information, such as the
copyright information.
You can combine landmark roles
with other area properties,
too.
For example, nav
aria-label equals
primary can help you
identify primary versus
secondary navigation,
or just aid
in giving more context
to the type of navigation
you're providing.
The next type is
document structure roles.
As with landmark elements,
there are many equivalencies
in HTML to these
document structure roles.
Role equals form or role
equals nav is unnecessary
when you use the form or
nav elements, respectively.
Headings are another example
of semantic document structure.
Using the proper
headings, h1 through h6,
in the correct order
makes a big impact
in helping users
navigate your document.
In a 2016 screen reader
study by Heydon Pickering,
many respondents that
used screen readers
noted that they use headings
and regions as a primary means
of navigation.
However, you can use
other structure roles when
there's no existing equivalent.
There are also widget roles.
Widget roles describe
common interactive patterns
that currently lack semantic
equivalence in HTML,
such as tabpanel or combobox.
Window roles consist of
alertdialog and dialogue.
These roles are meant to be
used when creating a sub-window
to the primary document.
You can think of this
like a popup or tooltip.
And finally, we have
live region roles,
which can be set to either
the assertive, polite,
or off states.
These are used
within applications
that use JavaScript to
change parts of the page
without a full reload,
and the developer
wants to send a small alert
or some other type of message
to the user.
These are great when
used in moderation,
but can become quite distracting
for users when overused.
The search bar on
the web.dev site
is one example of where
ARIA roles are used heavily
to ensure an accessible
experience for everyone.
In fact, we have Rob Dodson
here to walk us through it.
Hi, Rob.
ROB DODSON: So
here on web.dev, we
have a Search field
up at the top.
And it allows the user
to start typing a query.
And importantly, we keep the
focus inside of this text box,
so that they can continue
typing their query,
but they can also use the
up and down arrow keys
to look for other options.
So how do we make something
like this accessible?
Well, any time building a
really custom component,
something where there's no
counterpart in vanilla HTML,
I'll start by looking at the
ARIA Authoring Practices guide.
So this is a really
wonderful doc
that lists a number
of UI patterns
and explains how to build
them in accessible fashion.
In this case, what we're
building is a combo box.
So a combo box is
a widget made up
of a combination of two distinct
elements, a single line text
box and an associated
popup element
that helps the user set
the value of the text box.
That sounds like
a pretty good fit.
So I'll scroll down and
I'll check out the examples.
Here is an example right here.
We can play around with these.
Seems to match the
pattern that we want.
Importantly, if we scroll
down a little bit further,
it'll tell us what is
the expected keyboard
behavior for both the text
box and the list box popup.
And it'll also tell
us the required ARIA
roles, properties and states.
So in this case, we know we're
going to need an outer element
with a role of combo box.
There are a number of
additional ARIA properties
that are going to
set on that element.
Inside of that, we're
going to use a text box.
A regular input type equals
text will work in this case.
And lastly, we're going to
need a list box element.
And this is going to
have a list box role,
and this is what's going to
contain all of our results.
So that's what we've
built over here.
We've got a combo box
element right here.
That's sort of the wrapper.
Inside of that, we've
got this input element.
And I've added a
role of search box
to it, so it'll
additionally announce
that it's meant for searching.
And then finally down
here, we have our element.
It's not visible right now, but
it's got a role of list box,
and this is what's
going to contain
all of our search results.
So let's try this
with a screen reader.
So we'll navigate over
to our search field.
DIGITAL SPEAKER:
[DIGITAL STUTTER]
visited all articles,
search text field search.
ROB DODSON: You can see that
it announced all articles.
That's because we have
an ARIA label that
specifies that the
search is going
to search all of the
articles across the site.
And then it also announced
that it's using a search role.
We can start typing.
DIGITAL SPEAKER: C-S.
ROB DODSON: And then when the
user presses the down arrow
key.
DIGITAL SPEAKER: Visited link.
10 modern layouts in one
line of CSS, one of 10.
ROB DODSON: It tells
them how many results
are available on the page.
Lastly, because we're building
a single-page application, when
they select an
option, we're going
to call focus on the first
header in the new page
that we've loaded in.
This way, the user
knows that something
has changed on the page.
Again, you only
really need to do this
if you're building a
single page web app.
Well, let's see what
the experience is
like using voiceover.
DIGITAL SPEAKER: All, heading
level one, 10 modern layouts
in one line of CSS.
Main.
UNA KRAVETS: Thank you, Rob,
for that excellent run-through.
And thank you for
joining us today
in the semantic
accessibility discussion.
Basically, use semantic HTML as
much as you can and substitute
with ARIA roles where you can't.
That's how we can
make sure that users
who navigate your website using
a keyboard or screen reader
will also have a
great experience.
Until next time.
[MUSIC PLAYING]
