Building accessible web components without tears

without tears
Building accessible web components

Have you ever tried to navigate
through your web site or
application using the
keyboard only (no mouse)?
1

Were you able to perform all
the site/application tasks
without issues?
2

As you navigated through the
application using keyboard
only, could you always see
the element that was in
focus?
3

Was tab order in a logical
order (that reﬂected the on-
screen order) or did focus jump
all around the page?
4

Over the last 5 years,  
there seems to have been  
a major change in front end
development.

Developers are now being
asked to be ﬂuent in all sorts
of libraries and frameworks -
to be “full stack” developers.

But many “full stack”
developers seem to have
forgotten some of the core
web principles…

Like… understanding basic
HTML, CSS, accessibility, and
using progressive
enhancement.

“Why can’t I
wrap a span
around a div?”

Web accessibility
begins with
semantic markup

https://www.ﬂickr.com/photos/tinto/16027598548
Why should I care?

One of our core roles as web
professionals is making sure
our sites /applications can be
used by the widest possible
audience.

This means everyone,
including people with
disabilities that include: Visual,
Auditory, Motor skill and
Cognitive

This also means making our
sites and apps accessible for
Assistive Technologies:

Input devices:  
Accessible keyboards, Track
pads, Head wands, Puﬀers,
Switches, Touch screens, Voice
activation software, etc.

Output devices:  
Text-based browsers, Screen
Readers, Magniﬁers,
Refreshable Braille Devices
etc.

Assistive
Technologies are
more than just
screen readers

All of this may sound time
consuming and costly, but it
doesn’t have to be.

I'm going to talk about some
quick things you can do to
make some common
application components more
accessible.

I’ll be focussing on some
components that often
present major barriers to
Assistive Technologies.

I have a range of online tests
available, which show how
diﬀerent assistive technologies
work with application
components.
http://maxdesign.com.au/jobs/sample-accessibility/

WAI: Web Accessibility
Initiative
ARIA: Accessible Rich Internet
Applications

WAI-ARIA deﬁnes a way to
make web sites and web
applications more accessible -
especially advanced
JavaScript-based
components.

We can use HTML attributes to
deﬁne the role, states and
properties of speciﬁc HTML
elements.

Roles:
Is it a widget (menu, slider,
progress bar etc.) or an
important type of element
(heading, region, table, form
etc.)

States:
What is the current state of the
widget? Is it checked, disabled
etc.

Properties:
What are the properties of the
widget? Does it have live
regions, does it have
relationships with other
elements, etc?

<button aria-‐label="Close and return to
application">
Close
</button>
<a href="#" aria-‐describedby="info1">
Purchase
</a>

ARIA allows us to
make speciﬁc HTML
elements more
meaningful for ATs

Well done! Your changes have been saved
Inserted after page load

Adding content after the initial
page has loaded can cause
potential issues for screen
readers.

Problem 1:
Screen readers “buﬀer” pages
as they are loaded. Any
content that is added after this
time many not be picked up by
the screen reader.

Problem 2:
Screen readers can only focus
on one part of the page at a
time. If something changes on
another area of the page,
screen readers may not pick
this up.

The aria-live attribute allows
us to notify screen readers
when content is updated in
speciﬁc areas of a page.

We can apply the aria-live
attribute to any HTML
element.

If we then use JavaScript to
inject/hide/show content
within this element, screen
readers will be made aware of
any DOM changes within that
element.

The aria-live attribute can be
used for any page regions that
are likely to get updates after
the initial page is loaded.

Success alerts! Your changes are saved
Info alerts! Some info to be aware of
Warning alerts! Something has changed
Error alerts! Fix the error and try again
Alert messages

There are three possible
values for aria-live: “oﬀ”,
“polite” and “assertive”.

Assistive Technologies should
not announce updates unless
the assistive technology is
currently focused on that
region.

Should be used for
information that is not
critical for users to know
about immediately.

announce updates at the
next graceful opportunity
(e.g. end of current sentence).

Should be used for warning
notiﬁcations that users may
need to know.

announce updates
immediately.

Should only be used if the
interruption is imperative for
users to know immediately
such as error alerts.

Unfortunately, aria-
live=“assertive” is not well
supported at this point, so
the “polite” value may be
preferred.
http://maxdesign.com.au/jobs/sample-accessibility/10-notiﬁcations/
index.html

aria-relevant
This attribute gives a hint
about what types of changes
are relevant and should be
announced by Assistive
Technologies.

<!-‐-‐ Insertion of nodes into the live region
should be considered relevant -‐-‐>
<div aria-‐relevant="additions">
</div>

<!-‐-‐ Deletion of nodes should be considered
relevant
-‐-‐>
<div aria-‐relevant="removals">
</div>

<!-‐-‐ Changes to the textual content of
existing nodes should be considered relevant
-‐-‐>
<div aria-‐relevant="text">
</div>

<!-‐-‐ All changed nodes should be considered
relevant -‐-‐>
<div aria-‐relevant="all">
</div>

The default behaviour is
equivalent to “additions text”.

aria-relevant values of
“removals” or “all” should be
used sparingly.

role=“alert”
Deﬁnes a message with
important information.

Elements with the role=“alert”
have an implicit aria-live
value of “assertive”.

aria-live:
easy to apply,
major beneﬁts

Accessible Errors
https://www.pexels.com/photo/animal-dog-pet-sad-7289/

It is important to understand
that Screen Reader users
generally read and interact
with web pages in two main
ways:

‘Read’ mode:
Users can read and navigate
the page but can not enter
data into form controls.

‘Form’ mode:
User can enter data into form
controls. Keyboard access is
restricted to page elements
that can accept focus.

These days, screen readers
will automatically switch
between these two modes -
though users can manually
trigger these modes as
needed.

Why do these
two modes
matter?

If a screen reader is in forms
mode, content that is not
directly associated with form
controls may not be
announced.

<!-‐-‐ this error message may not be announced
-‐-‐>
<div>
<label for="email">Email</label>
<input type="email" id="email">
<p class="error">Error</p>
</div>

We’re going to look at two
diﬀerent aspects of client-
side form validation.

1. Form control validation
Individual form ﬁelds are
validated as the user moves
focus out of the form control.

2. On-submit form validation
The entire form is validated as
the user submits the form -
before the script sends the
form to the server.

Problem 1:
Form Control Error messages
only appears after a control
has lost focus. For this reason,
it is not immediately presented
to screen reader users.

Screen reader users often
have to travel back through the
form to try and find invalid
form controls. If invalid form
controls are not effectively
flagged, users may not be
able to find them.

Problem 2:
Screen reader users are often
not informed that the overall
form contains errors.

In the worst cases, focus
remains on the form submit
button, even after the form
has been found to be invalid,
and screen reader users have
no idea why the form won’t
submit.

A solution for form
control validation

1. When a form control is
deﬁned as invalid, the control
and associated label should be
“ﬂagged” so that users can be
made aware that there is an
error.

2. Flagging form controls and
associated labels should not
use colour alone to signify
errors.

3. An error message should be
displayed in close proximity to
the relevant form control.

Error: The phone number must include a 10 digit number
Phone

4. The error message should
be informative - it should
provide information that will
help users ﬁll in the ﬁeld
correctly.

be programmatically
associated with the form
control.

This means that the error
message should be
announced along with the
relevant label information.

There are a range of diﬀerent
methods to programmatically
associate error messages with
form controls.

The simplest is to place the
error message content inside
the label.

<div>
<label for="email">
Email
<input type="email" id="email">
<span class="error">Error</span>
</label>
</div>

A solution
for on-submit
form validation

If there are one or more form
validation errors:

1. An error message should
appear at the top of the form
alerting users that there are
errors.

2. Focus must be taken to the
error message as soon as the
user has attempted to submit
for form.

list all errors.

4. Each error should ideally be
a link that takes the user to the
relevant form control.

The form has two errors that must be completed before it

can be submitted.

1. Error: You must include your ﬁrst name

2. Error: Email address must include an "@" symbol

Optionally, error messages can
be placed inside a hide/show
function that allows users to
choose whether they see the
list of errors or not.

The form has two errors that must be completed before it

can be submitted.

View all errors

The error message container
can exist on the page, even
when non-active. However, it
should not contain any content
until triggered.

This container should be set
with role=“alert”. This is used
to communicate important
information.

Optionally, the aria-live
attribute can added with a
value of “assertive” or “polite”.

This container can be set with
tabindex value of “-1” so that
it will not receive focus.

When the error message
needs to be displayed (i.e. the
user has attempted to submit
the form with invalid form
controls) some changes need
to occur dynamically.

If present, the tabindex
attribute value needs to be
changed from “-1” to “0” so
that the element will appear in
normal tab order.

The container can be given a
label so that it is announced to
screen reader users.

Accessible form
errors:
simple solutions,
major beneﬁts.

Problem 1:
Keyboard-only users are often
able to TAB outside of the
modal window while the
modal is still active. This can
be very confusing and
disconcerting.

Problem 2:
Screen reader users are
sometimes not informed that
an action will trigger a modal.

Problem 3:
sometimes not made aware of
the purpose of the modal or
what actions they need to
perform within the modal.

Problem 4:
sometimes sent to the top of
the parent page after a modal
window has been closed. This
can be confusing.

When a modal is not in use, we
need to hide it so that is not
seen by sighted users or
announced to Screen
Readers.

When a modal window is
triggered, we need to change
the value.

When the modal window
becomes active, all other
content should be hidden
from Assistive Technologies.

<!-‐-‐ all other content -‐-‐>
<div
aria-‐hidden="true">
...
</div>
<!-‐-‐ modal window -‐-‐>
<div
style="display:block">
...
</div>

We need to set the initial
focus to the modal window
element itself rather than
elements inside the modal.

This is important because we
are going to give the modal a
label.

If we set focus on an element
inside the window, the label
will not be announced to
Assistive Technologies.

We need to inform screen
reader users that this modal
window is a “modal dialog”.

We need to provide a label
for the modal dialog, so
Assistive Technologies can
announce its purpose.

<div
role="dialog"
aria-‐labelledby="modal-‐label">
<h1 id="modal-‐label">Choose account</h1>
</div>

In some circumstances, we
may need to provide a more
detailed description of the
purpose of the modal dialog.

<div
role="dialog"
aria-‐labelledby="modal-‐label"
aria-‐describedby="modal-‐description">
<h1 id="modal-‐label">Choose account</h1>
<p id="modal-‐description">
Description here
</p>
</div>

Adding meaning
to important
actions

For some important actions
inside the modal window,
be given additional
information to let them know
what will happen.

As screen reader users are
submitting form data, they
should be informed that:

1. They will be taken back to
the parent page.

2. Where this data will be
submitted when they return to
the parent page.

ENTER
“Submit and return to
bank balance information.
Your data will be added to
the Balance table”

As screen reader users focus
on the “Close” function, they
should be informed that
closing will take them back
to the parent page.

ENTER
“Leave form and return to
bank balance information”

When the modal window is
closed, if users are being
taken back to the parent
page:

1. Focus should be placed on
the relevant component of
the parent page. The most
common practice is to move
focus back to the element that
invoked the dialog.

The user should not be
thrown back to the top of the
parent page unless there is a
good reason!

2. The user should be
informed where they are and
what change has occurred.

Lorem ipsum dolor sit amet consect etuer adipi scing elit sed diam
nonummy nibh euismod tinunt ut laoreet dolore magna aliquam
erat volut. Ut wisi enim ad minim veniam, quis nostrud exerci tation
ullamcorper suscipit lobortis nisl ut aliquip vel eum iriure dolor in
hendrerit in vulputate.
Accumsan et iusto odio dignissim qui blandit praesent luptatum
zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum
dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat.
Heading here
Another thing here
Add your bank balance
Another heading
$1,200.34
Focus
“Bank balance $1200.34 added
to bank information table”

Modals are a pain,
but we can make
them less painful

Accessible tabs
https://www.ﬂickr.com/photos/quandc/16426960180

In-page tabs can present
issues for screen reader as
well as keyboard-only users.

Problem 1:
Screen reader users are often
confused by the relationship
between tabs and panels.

Problem 2:
Keyboard-only users are often
unable to navigate through the
tabs and panels simply or
intuitively.

The preferred keyboard-only
navigation method for in-
page tabs uses TAB keystrokes
to move onto the active tab
and active panel, and ARROW
keys to move across tabs.

“TAB & ARROW”:
Straight through
pass

Tab 1 Tab 2 Tab 3
This is a heading inside Tab 1
Lorem ipsum dolor sit amet consect etuer adipi
scing elit sed diam nonummy nibh euismod
tinunt ut laoreet dolore magna aliquam erat
volut. Ut wisi enim ad minim veniam, quis
nostrud exerci tation.
This is a link inside tab 1.
This is a link above the tabs
This is a link below the tabs
TAB

“TAB & ARROW”:
Across the tabs
pass

Tab 1 Tab 2 Tab 3
ARROW

Tab 1 Tab 2 Tab 3
TAB

Where to put
focus for
panels?

Ideally, focus should be placed
on the panel itself after
moving oﬀ the relevant tab
above. This also allows us to
announce the panel to screen
reader users.

Focus can then move to any
focusable items inside the
panel as needed.

We can start with a basic list
and a series of <div> elements
below.

<!-‐-‐ In-‐page-‐tabs -‐-‐>
<ul>
<li><a href="#panel1">Apple</a></li>
<li><a href="#panel1">Pears</a></li>
<li><a href="#panel1">Oranges</a></li>
</ul>
<div id="panel1">Panel 1</div>

We can then use WAI ARIA to
deﬁne the role or purpose of
each element.

<!-‐-‐ tablist applied to UL -‐-‐>
<ul role="tablist">
</ul>

<!-‐-‐ presentation applied to LI -‐-‐>
<ul role="tablist">
<li role="presentation">
</li>
</li>
</li>
</ul>

<!-‐-‐ tabs applied to tabs -‐-‐>
<ul role="tablist">
<a href="#panel1" role="tab">Apple</a>
</li>
<a href="#panel2" role="tab">Pears</a>
</li>
<a href="#panel3" role="tab">Oranges</a>
</li>
</ul>

<!-‐-‐ tabpanel applied to panels -‐-‐>
<div id="panel1" role="tabpanel">
Panel 1
</div>
Panel 2
</div>
Panel 3
</div>

Next up, we need to deﬁne
the controls for the tab panels
- using aria-controls.

<!-‐-‐ relating panels to tabs -‐-‐>
<a href="#panel1" role="tab" aria-‐
controls="panel1">Apple</a>
<div role="tabpanel" id="panel1">

We also need to add labels to
the tab panels using aria-
labelledby.

<!-‐-‐ relating tabs to panels -‐-‐>
controls="panel1" id="tab1">Apple</a>
<div role="tabpanel" aria-‐labelledby="tab1"
id="panel1">

Now, we need to set the
various states for the tabs
using aria-selected=“true” (if
the user has selected this tab)
or aria-selected=“false” (for all
other tabs.

<!-‐-‐ selected tab -‐-‐>
controls="panel1" aria-‐selected="true"
id="tab1">Apple</a>
<!-‐-‐ inactive tab -‐-‐>
controls="panel2" aria-‐selected="false"
id="tab2">Pears</a>

And the various states for the
tabs panels using aria-hidden
and aria-expanded.

<!-‐-‐ active panel -‐-‐>
<div role="tabpanel" aria-‐hidden="false"
aria-‐expanded="true" aria-‐labelledby="tab1"
id="panel1">
<!-‐-‐ inactive panel -‐-‐>
<div role="tabpanel" aria-‐hidden="true"
aria-‐expanded="false" aria-‐labelledby="tab2"
id="panel2">

And now to set focus on the
relevant elements.

<!-‐-‐ active tab -‐-‐>
controls="panel1" aria-‐selected="true"
tabindex="0" id="tab1">Apple</a>
<!-‐-‐ inactive tab -‐-‐>
controls="panel2" aria-‐selected="false"
tabindex="-‐1" id="tab2">Pears</a>

JavaScript can be used to
swap these various option as
needed.

<!-‐-‐ active tabs -‐-‐>
<a
href="#panel1"
role="tab"
aria-‐controls="panel1"
aria-‐selected="true"
tabindex="0"
id="tab1">Apple</a>

<!-‐-‐ inactive tabs -‐-‐>
<a
href="#panel1"
role="tab"
aria-‐controls="panel1"
aria-‐selected="false"
tabindex="-‐1"
id="tab1">Apple</a>

<!-‐-‐ active panels -‐-‐>
<div
role="tabpanel"
aria-‐hidden="false"
aria-‐expanded="true"
aria-‐labelledby="tab1"
id="panel1"
class="panel">

<!-‐-‐ inactive panels -‐-‐>
<div
role="tabpanel"
aria-‐hidden="true"
aria-‐expanded="false"
aria-‐labelledby="tab1"
id="panel1"
class="panel">

OK, that was
intense, but you
don’t have to do
all of it

Moving forward
https://www.ﬂickr.com/photos/kakissel/5484265811

Don’t be
overwhelmed.
Look for quick
wins.

You’ll be surprised
what you can do
without too many
tears.

Test with keyboard-only
and make changes as
needed. (Make sure you
also check for visible
focus).
1

/* avoid this! */
:focus { outline: none; }

Test with accessibility
checking tools and
make changes as
needed.2

Tenon
https://tenon.io/
Web Accessibility Toolbar
https://www.paciellogroup.com/resources/wat/
Accessibility Viewer
https://www.paciellogroup.com/resources/aviewer
Colour Contrast Analyser
https://www.paciellogroup.com/resources/contrastanalyser/

Accessibility Evaluation Toolbar 1.5.7.1.1
https://addons.mozilla.org/en-US/ﬁrefox/addon/accessibility-evaluation-
toolb/
WAVE
http://wave.webaim.org/
Total Validator
http://www.totalvalidator.com/
CynthisSays
http://www.cynthiasays.com/

Test with one or more
screen readers and
make changes as
needed.3

Win/IE11
Win/IE8
Win/Chrome
Win/Firefox
OSX/Chrome
OSX/Firefox
OSX/Safari
NVDA
PASS/FAIL
PASS/FAIL
PASS/FAIL
PASS/FAIL
-
-
-
JAWS
PASS/FAIL
PASS/FAIL
PASS/FAIL
PASS/FAIL
-
-
-
Voiceover
-
-
-
-
PASS/FAIL
PASS/FAIL
PASS/FAIL

Get expert assistance
and conduct a formal
accessibility audit of
your website or web
application and action as
needed.
4

When is the best
time to focus on
accessibility?

The best time to focus on
accessibility is right at the
beginning of development
process, when creating the
individual components in
your pattern library.

Russ Weakley
Max Design

Site: maxdesign.com.au

Twitter: twitter.com/russmaxdesign

Slideshare: slideshare.net/maxdesign

Linkedin: linkedin.com/in/russweakley

Building accessible web components without tears

Building accessible web components without tears

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Building accessible web components without tears

Similar to Building accessible web components without tears(20)

More from Russ Weakley

More from Russ Weakley(15)

Recently uploaded

Recently uploaded(20)

Building accessible web components without tears