Would you ask someone who had only ever driven a car to design or build the perfect bicycle? At Publicis Sapient, we endeavor to create experiences that are accessible to the widest possible audiences both because it’s the right thing to do, and also to maximize our clients’ customer base. All audiences benefit from experiences designed accessibly, including people with disabilities. But most web experiences are still not accessible, and that is because most people who design and develop websites are not familiar with the alternate ways that disabled people navigate a website. Would you ask someone who had only ever driven a car to design or build the perfect bicycle? Probably not. But that’s effectively what we’re doing when we ask designers and developers who have only ever navigated with a mouse pointing tool to create an experience that works well with a keyboard and screen reader. So let’s change that. This hands-on presentation for developers describes who benefits from accessible web experiences & outlines a series of the most typical code-related accessibility issues encountered during accessibility audits and how to fix them — and avoid them in the first place!

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

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

3. Section 1
What is accessibility?
3
@lsnrae

4. “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
4
@lsnrae

5. @lsnrae

7. @lsnrae

10. Section 2
Who benefits from web accessibility?
10
@lsnrae

11. @lsnrae

12. @lsnrae

14. @lsnrae

15. People with disabilities (US, 2016)
16%
Ambulatory
6%
Cognitive
5%
Hearing
3%
Sight
2%
US POPULATION
“web
impacting
disabilities”
@lsnrae

16. 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

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

18. Some definitions:
18
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

19. 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

20. 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

21. 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

22. 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

23. 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

24. “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?
24

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

26. Ways the web works:
@lsnrae

27. @lsnrae

28. Section 4
10 Common code-related accessibility issues
28
@lsnrae

29. 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
adipiscing elit, sed
do eiusmod tempor
incididunt ut labore
et dolore.
Learn more >
Service
s
• Link 1
• Link 2
• Link 3
• Link 4
@lsnrae

30. Developing modal windows without
keyboard functionality
 First focus on close button.
 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
Body text goes here lorem ipsum
dolor sit amet.
Learn more
Subtitle 3
Body text goes here lorem ipsum
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

31. <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>
Common code-related issue #3:
Writing invalid HTML markup, like
empty links.

32. 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.
Common code-related issue #4:
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

33. Not separating heading styles from
structure
Common code-related issue #5:
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
L2 – Franklin Gothic Medium, 20 px
L3 – Franklin Gothic Book, 18 px
Body copy – Garamond, 16 px
@lsnrae

34. L1 – Franklin Gothic Medium, 24 px
L2 – Franklin Gothic Medium, 20 px
L3 – Franklin Gothic Book, 18 px
Body copy – Garamond, 16 px
Main title goes here
Subtitle 1
Body text goes here lorem ipsum
dolor sit amet.
Learn more
Subtitle 2
Body text goes here lorem ipsum
dolor sit amet.
Learn more
<h1 class=“L1”>
<h2 class=“L3”>Not separating heading styles from
structure
Common code-related issue #5:
@lsnrae

35. 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”>
Common code-related issue #6:

36. Mis-using aria-label and
aria-describedby attributes
Common code-related issue #7:
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

37. Mis-using aria-label and
aria-describedby attributes
Common code-related issue #7:
<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

38. Not using captions and scope
attributes for data tables
Common code-related issue #8:
<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 Libraries

39. Not using captions and scope
attributes for data tables
Common code-related issue #8:
<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

40. Building inaccessible calendars
Common code-related issue #9:
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

41. Focus order not logical and
intuitive
Common code-related issue #10:
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

42. 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

43. Section 5
Accessibility testing tools & methods
43
@lsnrae

44. 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?
44
@lsnrae

45. 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?
45
@lsnrae

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

47. 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.
47
@lsnrae

48. 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:
48
@lsnrae

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

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

51. Imagine the impact
of web accessibility
51
@lsnrae

52. thank you
copyright publicis sapient | confidential
Alison Walden
Director of Technology
@lsnrae
Medium.com/@lsnrae