Developing Accessible Experiences

Developing accessible experiences
April 2019
Alison Walden
Director of Technology
@lsnrae
Medium.com/@lsnrae

Developing accessible experiences
April 2019
Alison Walden
@lsnrae
Medium.com/@lsnrae
I presented this deck at Web à Québec 2019 and want to give a special shout out to my excellent audience who requested that I make it available
online. This is the slideshare version. On every slide, I provide my speaker notes in a box like this one. The conference version of the deck did not
have these boxes on every slide!
My name is Alison Walden, and I’m a director of technology at Publicis Sapient. I’m responsible for the quality of our front-end code deliverables,
the customer-facing aspect of our code. I’m also our accessibility lead.
This combination role puts me in a position where I get to review large samples of our front end code and that of vendors we work with, and I
started to compile a list of the most common accessibility issues inadvertently caused by front end developers.
I’m going to share this list with you today, in hopes that you can avoid making these same issues. So let’s get started.

Key Ideas:
1. An accessible web benefits everyone.
2. The WCAG guidelines are easy to read.
3. Test with your keyboard & screen reader.
3
@lsnrae

Section 1
What is accessibility?
4
@lsnrae

“Accessibility means access. It refers to the
ability for everyone, regardless of disability
or special needs, to access, use and benefit
from everything within their environment.”
- The Canadian National Institute for the Blind
5
@lsnrae

@lsnrae
I’ve been focusing on accessibility in my
work for over 10 years.
One of the first times I thought about
accessibility was on a trip to the Great Wall
of China in 2006.
The Great Wall is one of the wonders of
the ancient world, as you know. There’s no
denying that it wasn’t designed to be
accessible. That’s understandable for a
structure built over 2000 years ago.
As a healthy, active person, I wouldn’t
have noticed the accessibility challenges of
the Great Wall if I had not been traveling
with my elderly father in law. He simply
couldn’t climb up all of those stairs. It was
the first time that someone else’s
accessibility requirements affected me
personally.

The next time I recall noticing accessibility
barriers is when I had a baby. This isn’t a
picture of me but it illustrates what all
parents face when they want to take their
child out in a stroller.
Carrying a stroller up the stairs is
challenging. Depending on how many
stairs there are, it could be impossible
without help.
It made me empathize with people in
wheelchairs who always faced this
problem that had never affected me
before.
And it struck me how willing strangers
were to help me carry the stroller up the
stairs. People are kind, and they want to
help.

@lsnrae
And people are smart. They find
workarounds. Even when something isn’t
designed for accessibility, sometimes
people can find a way to succeed in their
task.

But we also have an opportunity to
consider everyone’s needs up front, and to
design and develop accessible
experiences purposefully, so that everyone
can enjoy them.

Here’s another view of this style of
accessible ramp. This won an urban
design award and it shows that it’s
definitely possible to have an experience
that is both beautiful AND accessible.
What I’m trying to convey is that when
we make a physical space accessible, it
actually benefits everyone.

Section 2
Who benefits from web accessibility?
11
@lsnrae

@lsnrae
With the advent of smartphones we are all
subject to a degree of new challenges
when trying to navigate websites. Here I’m
showing how the glare on the screen can
cut down on anyone’s ability to view
content.

@lsnrae
We also have to consider the temporary
disabilities we’re all subject to – temporary
vision loss or when you injure your arms.

We have all ages of people surfing the
internet, with varying degrees of dexterity
and vision loss…

@lsnrae
…who wouldn’t even self-identify as
needing an “accessible” experience.
But let’s talk about the population of people
with disabilities, who will also benefit from
accessible experiences.

People with disabilities (US, 2016)
16%
Ambulatory
6%
Cognitive
5%
Hearing
3%
Sight
2%
US POPULATION
“web
impacting
disabilities”
@lsnrae
A full 16% of the US population had some
kind of disability in 2016.
Let’s talk about disabilities other than
ambulatory ones:
Cognitive issues, hearing loss, and vision
loss. I refer to these as “web impacting”
disabilities, because these are examples of
disabilities that affect peoples’ ability to
navigate the web using a mouse pointing
device. How many people are impacted by
these disabilities?

0 50,000,000 100,000,000 150,000,000 200,000,000 250,000,000 300,000,000 350,000,000
"Web Disabilities" Pop. (US)
Canadian Population
US Population
A significant number of people are affected…
~35 million
people
@lsnrae
A significant number. The top grey bar
represents the number of people online in
the US.
The middle grey bar is the population of
people online in Canada.
I want to draw your attention to the blue
bar at the bottom, which is the population
of people with “web impacting” disabilities
in the US. ~35 million people. This is
almost the same as the population of
Canada.

0 50,000,000 100,000,000 150,000,000 200,000,000 250,000,000 300,000,000 350,000,000
"Web Disabilities" Pop. (US)
Canadian Population
US Population
A significant number of people are affected…
~35 million
people
@lsnrae
Here are some Canadian numbers:
~half a million Canadians live with
significant vision loss. (Almost the whole
population of Quebec City).
Canadians who identify themselves
as culturally Deaf comprise more than
350,000 people across Canada. (Canadian
Association of the Deaf, 2007)
That’s about ¾ of a million people.

Section 3
Web Content Accessibility Guidelines (WCAG)
overview
19
@lsnrae

Some definitions:
20
Web Accessibility:
Web accessibility means that people with disabilities can perceive, understand, navigate, and
interact with the Web.
Web Content Accessibility Guidelines (WCAG):
A series of guidelines from the World Wide Web Consortium (W3C) that explain how to make
web content accessible to people with disabilities.
World Wide Web Consortium (W3C):
The main international standards organization for the World Wide Web.
@lsnrae

P E R C E I V A B L E
1.1 Text Alternatives
1.2 Time-based Media
1.3 Adaptable
1.4 Distinguishable
2.1 Keyboard Accessible
2.2 Enough Time
2.3 Seizures
2.4 Navigable
2.5 Input modalities
4.1 Compatible3.1 Readable
3.2 Predictable
3.3 Input Assistance
O P E R A B L E U N D E R S T A N D A B L
E
R O B U S T
The Web Content Accessibility Guidelines (WCAG) are organized under 4
principles:
@lsnrae

1.1 Use alternative text
1.2 Audio/video related
1.3 Use semantic markup
1.4 Make content easy to
see
2.1 Use the keyboard alone
2.2 Give users enough time
2.3 Don’t cause seizures
2.4 Help users navigate
2.5 …Beyond keyboard
4.1 Use correct syntax and
follow HTML specifications
3.1 Use language attributes
3.2 Predictable operation
3.3 Make accessible forms
CONTENT SHOULD BE CONTROLS SHOULD BE CONTENT SHOULD BE CODING SHOULD BE
P E R C E I V A B L E O P E R A B L E U N D E R S T A N D A B L
E
R O B U S T
The Web Content Accessibility Guidelines (WCAG) are organized under 4
principles:
@lsnrae

A
AA
AAA
L O W E S T
H I G H E S T
WCAG guidelines are divided into 3 conformance levels:
@lsnrae

A
AA
AAA
L O W E S T
H I G H E S T
WCAG guidelines are divided into 3 conformance levels:
@lsnrae
Even the W3C doesn’t recommend trying
to adhere to all of level AAA because some
of the guidelines are less measurable.
E.g. There’s a AAA guideline about
unusual words needing to be defined in a
glossary. Who gets to decide if a word is
unusual? Me? You? This is not objective
enough to be measurable.

Accessibility compliance is collaborative:
 Project Managers must ensure
accessibility compliance is considered in
the timeline.
 Experience Designers must consider
the linear screen reader experience in
their wireframes.
 Visual Designers must consider people
with vision challenges in their design.
 Front end developers must test their
work with the keyboard and screen
reader.
 Copywriters must be sure to write in an
accessible way.
 Quality Assurance Specialists must
test against accessibility requirements.
 Vendors must adhere to the same
standards.
 Everyone must be trained how to
comply.
@lsnrae

“Imagine not
being able to
access
information.
For [35 million people in
the US], this is the reality.
Today, only 5 percent of
printed materials are
available in alternate
formats, while less than 1
percent of websites are
accessible.” - CNIB
WHY?
26

“Design is not just what it looks like and
feels like. Design is how it works.”
- Steve Jobs
27
@lsnrae

Ways the web works:
@lsnrae
And the web works in a variety of ways: It can work with a mouse pointing device and a monitor, the way many of us probably use it. It can work with just a keyboard and a
monitor. Consider someone who has a tremor and cannot focus their mouse pointer and needs to use a keyboard instead. Or, a sighted person who may be paralyzed, and
use a puff and suck device that mimics the function of a tab key. Or, in the case of a non-sighted person, they will use their keyboard in conjunction with a screen reader.
In both of these latter two cases, the main way people are navigating is with their keyboard, not a mouse. But most people who design websites today actually use a
mouse pointer to navigate.

@lsnrae
Would you ask someone to design OR
BUILD the perfect bike who has never
ridden one?
You probably wouldn’t. But that is
effectively what we’re asking designers
AND DEVELOPERS to do, when they
usually navigate the web using a mouse
pointing device, and we ask them to start
designing or DEVELOPING experiences
for people who mainly use their keyboards.
Just because it works fine with our mouse
pointing device doesn’t mean it’ll work with
a keyboard.
Let’s now look at a few common issues I
see in front end code. These are issues
where the site works fine with a mouse,
but has problems with the keyboard and/or
screen reader.

Section 4
10 Common code-related accessibility issues
30
@lsnrae

Forgetting to test ALL of our work
with our keyboard, every time
Common code-related issue #1:
Home About Us Products Services
Lorem
Ipsum dolor sit
amet, consectetur
adipiscing elit, sed
do eiusmod tempor
incididunt ut labore
et dolore.
Learn more >
Lorem
Ipsum dolor sit
amet, consectetur
do eiusmod tempor
et dolore.
Learn more >
@lsnrae
When people don’t test with their keyboards, they miss obvious and easy to
fix issues. This example shows a basic global navigation menu that a user is
navigating with the keyboard. They will hit enter to open the “Services” menu, and
they can tab through it with their keyboard…

Forgetting to test ALL of our work
with our keyboard, every time
Home About Us Products Services
Lorem
Ipsum dolor sit
amet, consectetur
do eiusmod tempor
et dolore.
Learn more >
Lorem
Ipsum dolor sit
amet, consectetur
do eiusmod tempor
et dolore.
Learn more >
Service
s
• Link 1
• Link 2
• Link 3
• Link 4
@lsnrae
…but when they tab out of the menu, it doesn’t close. Every front end developer
reading this knows why this happened and how to fix it. The problem is, the
developer who made it did not test with their keyboard, so they didn’t notice
that the issue was happening!

Developing modal windows without
keyboard functionality
 First focus on close button (that has a “close” label).
 Modal heading is announced.
 Focus kept within modal.
 Close modal with close button or escape key.
Common code-related issue #2
Main title goes here
Subtitle 1
Body text goes here lorem ipsum
dolor sit amet.
Learn more
Subtitle 2
dolor sit amet.
Learn more
Subtitle 3
dolor sit amet.
Learn more
But wait, there’s more!
Lorem ipsum dolor sit amet here
is
the text of the modal window
lorem ipsum dolor sit amet.
Cancel Submit
X
<div role="dialog" aria-labelledby=
"dialog1Title" aria-
describedby="dialog1Desc">
<h2 id="dialog1Title">But wait,
there’s more</h2>
<p id="dialog1Desc">Lorem ipsum dolor
sit amet…</p>
<button>Close</button>
...
</div>
@lsnrae

<img src=“images/instagram.gif”
alt=“Connect with us on Instagram” />
<i class="icon-twitter"><span
class="visually-hidden">Twitter</span></i>
<a href="https://www.facebook.com/myPage"
target="_blank" class="social_icons
social_facebook">
<span class="icon-facebook"></span></a>
Writing invalid HTML markup, like
empty links.
This is the MOST COMMON error I see in front end development. These icons are
designed for sighted users only. When they get keyboard focus, the screen reader
will only announce “Link, link,link…” because the links have no label.
Use <img> tags instead. Images that are content should be within image
tags. Use SVG if you want them to scale. Or, if you really want to use an
icon font, add a hidden label the screen reader can announce.

Building inaccessible forms
 All fields have programmatically associated labels.
 Even fields with no visible label have hidden labels.
 Error messages are announced by the screen reader.
 User can submit form with errors.
First name*:
Last name*:
Phone number:
Email address*:
Please enter a valid email address.
Jane
Doe
janedoe@gmail
Submit
Required field indicators
Actual labels for all fields
Error messaging is read out by screen
reader
Buttons are not disabled
@lsnrae

Not separating heading styles from
structure
H1 – Franklin Gothic Medium, 24 px
H2 – Franklin Gothic Medium, 20 px
H3 – Franklin Gothic Book, 18 px
P – Garamond, 16 px
L1 – Franklin Gothic Medium, 24 px
L3 – Franklin Gothic Book, 18 px
Body copy – Garamond, 16 px
@lsnrae
Don’t apply CSS styles directly to heading elements. Make classes instead, so you
can use whichever heading level you need to use to display whatever font design is
shown in a given page layout.

L3 – Franklin Gothic Book, 18 px
Body copy – Garamond, 16 px
Main title goes here
Subtitle 1
dolor sit amet.
Learn more
Subtitle 2
dolor sit amet.
Learn more
<h1 class=“L1”>
<h2 class=“L3”>Not separating heading styles from
structure
@lsnrae
Then, when suddenly we get a design that skips heading levels, we can write code
that does not skip heading levels.

Overuse of ARIA
when simple
semantic HTML
will suffice
<img src=“myimage.jpg”
role=“img”…/>
<a href=“mypage.html”
role=“link”…/>
<article role=“article”…/>
<img src=“house.jpg”
alt=“A house” aria-
label=“A house” />
<nav role=“navigation”>
<img src=“smiley.gif” alt=“”
aria-label=“Smiley face” />
<div role="link"><a href="/"
role="button" tabindex="12" title="link
text">Link text</a></div>
<div role=
“presentation” aria-
label=“Presentation”>
The problem with WAI-ARIA is
that too many developers are
using it the wrong way. Respected
accessibility service
provider WebAIM recently analyzed
the home pages for the top one
million websites (Google the
WebAIM million) and among their
other results, they discovered
that home pages with ARIA present
averaged 11.2 more detectable
errors than pages without ARIA.
This means that well-intentioned
developers are making pages LESS
accessible. 

Mis-using aria-label and
aria-describedby attributes
4-door 2-door
<button aria-label=“Four door vehicle highlights”…>
4-door
</button>
<button aria-label=“Two door vehicle highlights” …>
2-door
</button>
(1) Aria-label attributes are used to
completely replace vague control names:
@lsnrae
This is a real example taken from a page that shows vehicle highlights for either a
4-door version of the vehicle or a 2-door version of the vehicle. The sighted user
can gather this context by seeing the interface, but it is not enough for a non-
sighted user to hear “button: 4-door” or “button: 2-door”.

Mis-using aria-label and
aria-describedby attributes
<p id=“mystatement”>Buy tires and wheels online.</p>
<a href=“page.html” aria-describedby=“mystatement”>
Learn More</a>
(2) Aria-describedby attributes are used to
append existing nearby content to vague
control names to provide more context.
Buy tires and wheels online.
Learn more >
Nearby text is appended to vague link text
@lsnrae
When you are able to use aria-describedby attributes instead of aria-labels, I like
it better because it requires less maintenance down the road and is less subject
to error.

Not using captions and scope
attributes for data tables
<table>
<caption>Javascript Libraries</caption>
<tbody><tr>
<th scope=“col”>Name</th>
<th scope=“col”>Age</th>
<th scope=“col”>Birthday</th>
</tr>
<tr>
<td scope=“row”>Jquery</td>
<td>11</td>
<td>August 26</td>
</tr>
<tr>
<th scope=“row”>React</th>
<td>4</td>
<td>March 21</td>
</tr>
</tbody></table>
Name Age Birthday
JQuery 11 August 26
React 4 March 21
Javascript LibrariesScreen readers use the caption element and scope attributes to help
non-sighted people understand how a data table is organized.
TABLE DO’s AND DON’Ts:
DO use the table heading in the caption element.
DO use the <th> element for table headings.
DO define the scope of a heading as belonging to a column or row.
DON’T make insanely complex tables without trying to help a designer
to simplify them. Some screen readers can’t handle merged rows or
columns, for example.

Not using captions and scope
attributes for data tables
<table>
<caption>Javascript Libraries</caption>
<tbody><tr>
<th scope=“col”>Name</th>
<th scope=“col”>Age</th>
<th scope=“col”>Birthday</th>
</tr>
<tr>
<th scope=“row”>Jquery</th>
<td>11</td>
<td>August 26</td>
</tr>
<tr>
<th scope=“row”>React</th>
<td>4</td>
<td>March 21</td>
</tr>
</tbody></table>
Name Age Birthday
JQuery 11 August 26
React 4 March 21
Javascript LibrariesTable caption is announced by screen reader
If you don’t provide a caption element, the screen reader will simply
announce, “table: 3 columns, 3 rows”.

Building inaccessible calendars
http://airbnb.io/react-dates/
 Can I tab through the dates with my keyboard?
 How does the screen reader read the date?
 Can I select a date range in an intuitive way by
keyboard?
 If not, can I simply type the date into a text field?
 Is the date format provided as part of the label?
@lsnrae
Calendars are hard to make accessible. Why not just use React Dates? They made
it work with the keyboard. I highly recommend it. If you can’t use it, make sure you
have lots of time to make your calendar keyboard accessible.

Focus order not logical and
intuitive
Log in to Online Banking
Card number*:
 Remember my card number
Password (case sensitive)*:
Forgot my password
Bank
Logo
Contact us | Help
Log in
1
2
3
4 5
6
7
8
@lsnrae
Keyboard focus should go from top to bottom, left to right, unless there
is some user experience reason to deviate from this. The example
opposite shows a scenario where the default focus was overridden on
purpose. A user got to this page from clicking on a link that said “Login
to online banking” so the UX designer thought it would make more
sense for them to land immediately on the card number field. I agree.
However, the developer forced the tabindex shown in red, resulting in a
cumbersome experience for the user. Tabindex is shown opposite with
the red and grey numbers. This is another mistake that would have
been obvious and easy to fix, had the developer tested with their
keyboard.

All of this information belongs in
the wireframes.
If it’s not there, ask!
 Heading levels/structure
 Keyboard functionality
 Hidden wayfinding cues
 Hidden form labels
 What the screen reader should
SAY if different than what the
sighted user sees
 Updating content areas and
associated notification text
 Focus order (if not default)
 Table captions and hidden
column or row heading values
 Etc.
@lsnrae

Section 5
Accessibility testing tools & methods
46
@lsnrae

Automated vs.
Manual testing –
Do both!
Automated testing –
For issues that do not
require human
judgment to be
detected.
E.g. 1.1.1 Non-Text
Content.
• If there is an <img>
tag, does it have an
alt attribute?
47
@lsnrae

Automated vs.
Manual testing –
Do both!
Manual testing – For
issues that do require
human judgment to be
detected.
E.g. 1.1.1 Non-Text
Content
A human can judge the
following
characteristics:
• Should the alt
attribute be null or
descriptive?
• What constitutes a
descriptive alt
attribute?
48
@lsnrae

Page-level
automated
testing tool
examples• Free browser
plugins you can
download.
49
WAVEWeb accessibility evaluation tool by WebAIM
Google Lighthouse
for developers
Axe accessibility
tool by Deque
ACHECKER

Manual web accessibility test procedure:
1.Build the functionality.
2.Test it with your keyboard alone (employing your sight).
3.Test it with your keyboard plus a screen reader, without
employing your sight.
50
@lsnrae

3-Step manual testing
1. Build the functionality.
2. Test it with your keyboard alone (employing your sight).
 Is all of the functionality available to the keyboard?
 Is the method of access an intuitive one that the user will
understand? (e.g. Do you force them to navigate with the
keyboard arrows without actually saying that is how it works?)
 Can content be accessed without employing non-intuitive
workarounds (e.g. tabbing past something, then back-tabbing
to access something else)?
3. Test it with your keyboard plus a screen reader, without
employing your sight.
 Are all of the points above still true?
 Could you in good faith use what you built if you were not the
person who developed it?
Procedure:
51
@lsnrae

Note: Screen readers are built for specific browsers.
@lsnrae

Things to remember:
1. An accessible web benefits everyone.
2. The WCAG guidelines are easy to read.
3. Test with your keyboard & screen reader.
53
@lsnrae
Today I’ve talked about the most common code-related accessibility issues that I see on web experiences every day that make it impossible for a person
with disabilities to access content and to really be part of our community. I wanted to empower all of you to understand the extra steps we must take as
developers to enable accessible experiences so that you could bring these skills to your daily work.
I conduct screen reader training internally and with clients at Publicis Sapient, and the most impactful moment during the session is when I invite the
class to do some online shopping. I let them choose any online retailer and any product, then let them loose to try to purchase that product with their
keyboard and screen readers alone. I always make sure they notice that I do not constrain their choices – I let them pick any online store. That’s how
confident I am that no e-commerce experience will be accessible.
We’ve tried many popular retailers and they are getting better, but it is still all to rare that someone gets through the checkout.

Imagine the impact
of web accessibility
54
@lsnrae
A positive way of looking at this is that there is a massive opportunity in
this area.
I like to imagine the amazing impact as developers like us continue to
learn how to implement websites in an accessible way, and to influence
our respective agencies and through them, our clients. Imagine the top
ecommerce and content websites becoming truly accessible, and what it
will mean to so many people. Thanks again for having me here today.

thank you
copyright publicis sapient | confidential
Alison Walden
@lsnrae
Medium.com/@lsnrae

Developing Accessible Experiences

More Related Content

Similar to Developing Accessible Experiences (20)

Recently uploaded (20)

Developing Accessible Experiences

Editor's Notes