Hi there.
My name's Alice.
And this is Making Polymer Elements Accessible.
So you've gotten the Web Components
bug and downloaded Polymer.
And you've made your first custom element.
Fantastic.
Today I'm here to talk a bit about how
we can make sure our brand new custom
elements can be used by everyone.
Right now, built-in HTML5 elements
work well for accessibility.
This didn't happen by accident.
Browser developers follow published standards
for ensuring the accessibility of these elements
and add keyboard handling, styling,
and semantic information to make sure
that all users can use them.
When we're creating new components for the web,
ideally they should be using the same standards.
They, too, should be accessible to all users.
When we talk about all users, there
are several broad classes of impairment
that we consider-- visual impairment, which
could range from poor color vision through low vision,
to no vision; hearing issues, whether a user is
deaf, hard-of-hearing, or simply can't use the device's
audio output; mobility or motor impairment,
whether temporary or permanent, such as a broken arm, RSI,
or long-term motor disorder; other impairments which
encompass a very broad range of issues, including
cognitive impairments like dyslexia, ADHD, brain injury,
and other impairments like learning disorder, epilepsy,
and vestibular disorder.
The first thing we want to look at
is whether an element can be used with the keyboard alone.
This is the first step ensuring it
can be used by users of assistive technology
on all platforms.
But also important for users with motor impairments,
or injuries, or any desktop users who
can't or won't use a mouse right now.
During your user-experience design,
think about how you would use your element with a keyboard
alone and figure out a consistent set
of keyboard interactions.
To help with the design process, consider
including physical impairments in your user experience
personas.
If you're creating an element which mimics an existing
element in some way, consider copying
the way it handles keyboard interactions to provide
consistency.
Try using a native element with the keyboard
and find out what already works.
Chances are, you've been using the keyboard sometimes anyway.
So you'll find it comes pretty naturally.
Later, we'll talk about ARIA, which
allows you to specify additional semantics for your element.
Once you've picked a semantic role,
you can use the ARIA design patents
guide to get some extra advice on what
keyboard events to handle.
The first step in actually implementing
keyboard interactions is to make sure the element can
take keyboard focus.
Unless you can actually focus on the element,
it's not going to get any keyboard events.
Ensure you have a sensible focus target for your element.
For a simple element like a button,
this will obviously just be the element itself.
A complex element like a menu-- maybe one focused target
within the page, but then manage focus within itself.
So the active menu item always takes focus.
In this case you want to make sure
that the menu items are programmatically focusable,
but not in the tab order itself.
This is where an understanding of the nuances of the tabIndex
attribute is going to come in handy.
TabIndex can take one of three classes of values.
When tabIndex is zero, the element
will be in the natural tab order which
is defined by the DOM order.
This is what you would use to make a custom
element, such as a custom button, keyboard focusable.
When tabIndex is negative, the element
will be programmatically focusable but not in the tab
order.
This would be useful for something
like the menu example on the previous slide.
The menu container element can manage
setting focus to each individual menu item when appropriate.
The tabIndex is greater than zero,
the element will be in a manual tab order.
This makes no sense in the context of Web Components,
since you essentially never know where your event-- your element
will fall on the page.
So now that you've spec'd out your keyboard interactions
and made your element focusable, you'll
need to implement the actual keyboard interactions.
Luckily, there's an event handler for that.
You can add an on-key data attribute to your Polymer
element and add a method to handle the keyboard event,
checking for any key-press events you're interested in.
Finally, make sure your keyboard interactions are discoverable,
especially if they're not using one of the standard patents.
Tool tips or keyboard help overlays
are common patterns for achieving this.
Once our keyboard interactions are working,
we're a good part of the way there already.
Next, we need to take a look at whether our element can
be used with assistive technology.
The types of users who would use assistive technology
range from users with visual impairments
who might use screen readers or braille displays;
to users with cognitive impairments
such as dyslexia, who might use a screen reader to augment
their reading ability; and users with motor impairments
who need to use technologies like voice
control to interact with their devices.
There are really only two parts to ensuring
that your element can be used with assistive technology,
including screen readers, once you've addressed keyboard
accessibility-- adding semantic information,
including the element's role, state, value, and name,
and making sure that all information conveyed
visually has a text alternative.
First, let's talk about semantics.
One of the great things about custom elements
is that they make a mark-up look semantic again.
We can hide presentation logic inside the shadow DOM
and use meaningful element names to create a readable DOM.
However, assistive technology doesn't see those semantics.
It still sees essentially DIV soup,
unless you tell it about the semantics you want your element
to have.
Assuming we're not extending built-in elements,
the way we tell assistive technology
about these additional semantics is
using WAI-ARIA, or ARIA for short.
ARIA is a specification defining support
for accessible-rich web applications.
It defines mock-up extensions implemented
as attributes and elements, which
can be used to provide additional information
about the semantics of elements to assistive technologies
like screen readers.
This is what using ARIA looks like in vanilla HTML5.
So we can use ARIA to add the semantic information
we want to our custom elements.
This is a custom slider element which you can visually
see as a minimum value of one, a maximum value of five,
and a current value of 2.5.
Until we add the relevant ARIA attributes,
though, this element doesn't communicate any of these
to assistive technology.
We can add ARIA value attributes to tell assistive technology
about the value of this element.
Here we have added the attributes
for role and current minimum and maximum values.
Finally, once all your semantics are in place,
make sure you always have text alternatives
for any other information which is conveyed visually.
For example, if your custom button uses a settings icon,
make sure you give it a name of settings as well.
And obviously make sure all of your images
have an alt attribute.
Even if you want them to be skipped
by assistive technology.
Assistive technology will try to come up with alternative text
if you don't provide it.
And often it'll pick the file name.
So provide an empty alt attribute
if you want the image to be visible to assistive
technology.
We also need to make sure that users
of any form of color blindness can use our element.
Firstly, let's make sure that we're not
communicating anything with color alone.
Color shouldn't be used as the only means
of conveying information such as indicating a status,
prompting for a response, or distinguishing a visual custom
element.
Here we have the Chromium dashboard
which, as well as being a Polymer application,
gives the status for each new web
platform feature being developed or shipped in Chromium.
Since the color dots next to the stakeholders
are meant to convey information, the developers
added a tool tip here which appears
when you hover over the name giving the same information.
We also need to make sure that there's always
sufficient contrast between text or icons and background color.
This is important for users with low vision
who might have trouble reading low-contrast text,
color blind users in the case where we're
using two different colors next to each other,
and any user using a mobile phone
or device in bright sunlight.
Any text content displayed in your element
should at least meet the minimum contrast ratio of 4.5 to one.
You can audit your element for sufficient contrast using
the accessibility developer tools extension, which
even provides suggested foreground and background color
pairs if it finds low-contrast text.
Lastly, make sure any moving or flashing content
is stoppable and safe.
If you have any fancy, slidey parallax-y transitions,
make sure you have a way to turn those off.
They can be a real pain for people with vestibular disorder
who may experience motion sickness
symptoms while using them.
And if you have any flashing content-- please don't tell me
you're re-implementing the blink tag--
make sure it meets the criteria for safe flashing content
of having a flash frequency of three times per second,
or fewer.
So let's recap and summarize everything into a handy list.
Remember, every built-in HTML5 element
will have all of these properties, at least
in a mainstream browser.
So we should make sure the custom elements do, too.
Make sure that your element can be used with a keyboard alone.
Make sure that it works with assistive technology.
Make sure that it doesn't rely on color
to communicate important information.
Make sure all text and icons have sufficient contrast
ratio with the background.
Make sure that it works without sound.
I didn't cover this, but make sure
any video or audio elements have the appropriate text
alternatives.
And make sure you aren't relying on audio cues
to prompt for actions.
And finally, make sure any moving or flashing content
is configurable and safe.
Please check out our article on the Polymer project website,
which goes into more detail on much of what I've covered here
as well as providing links to many other useful resources.
Remember, we're creating new components for the web.
We have an amazing opportunity to make
sure the web is accessible for everyone.
Let's do this.