This primer on mobile accessibility will give you a solid grounding on standards, guidelines and principles of making websites accessible on mobile devices, and demonstrate some of the accessibility features available on iOS and Android. This presentation was delivered at Digpen 7: http://lanyrd.com/2014/digpen7/sdfcth/

1. Introduction to
Mobile accessibility
Digpen 7
25 Sep 2014

2. Introduction
Jon Gibbins
– Accessibility consultant at Dig Inclusion
– Web developer since 2003 – or 1999!
– Assistive technology since 2002
– Training since 2012
– Passionate about accessibility – why?
2

3. 3

4. Photo credit:
LG, GD910 watch phone
4

5. Jon Gibbins / Drake Music
5

6. Introduction
What we will learn:
• How people with disabilities use mobile
devices
• Barriers typically faced by users with
disabilities
• Mobile accessibility principles
6

7. • This session will focus on iOS and Android
– Current market share favours iOS and Android devices
– iOS accessibility features and API is most developed
– Android have some good accessibility features and are
improving all the time
• Demonstrations
– Mostly using VoiceOver on iOS and Mobile Safari
– Android features will also be demonstrated with web
features shown using Chrome or Firefox nightly
7
Introduction

8. Introduction
• Questions are encouraged
– Nobody knows your work like you know your work
– If you have a question, or want to know more,
please put your hand up
• Links
– Web accessibility training resources
– WebAIM screen reader survey (Jan 2014)
8

9. Ensuring that anyone can use your websites
and applications to find information, buy
stuff, play games, watch video…
Making a website or application more
accessible to people with disabilities
9
Accessibility

10. Accessible
People with disabilities can perform the same
functions…
receive same information…
and participate as
producers and consumers.

11. Mobile
• “Mobile” is not just about phones
– Tablets, games consoles, TVs, etc.
– More users: cheaper technology reduces Digital Divide
• Mobile Web
– Sites and applications built for viewing on mobile
browsers
– Note: Feature gap to native apps is narrowing due to
standards such as HTML5 and ARIA
11

12. Mobile accessibility
• Making a website or application more accessible to
people with disabilities using mobile devices
• The basics are the same as on desktop:
– Alternatives: images, audio, video
– Labeling: form controls, headings, buttons
– Good structure: landmarks, lists, heading levels
– Use native controls where possible
– Content order
12

13. Why?
• Mobile devices are the cheapest way for
people to get online.
• Innovative assistive technologies are
available for free with operating systems,
such as iOS and Android.
13

14. Who?
• Four main user groups with diverse needs:
– Vision (blind, partially sighted)
– Hearing (deaf, hard of hearing)
– Mobility
– Cognitive and learning
14

15. Who?
• Hidden disabilities
– Chronic fatigue
– Photo sensitivity
– Mental health
• Aging
– Spans various disabilities and user groups
– Often first-time users
– Note: Older people, like young children, find primary solid colour
easier to see and draw meaning from than pastel colours, etc.
15

16. Who?
• Temporary
– Broken wrist
– Repetitive strain injury
– Tiredness
• Cultural
– Language
– Colour and iconography
• Technology
– Particular software and hardware requirements or preferences
(mobileaccessibility.info Device Details)
– Connectivity, data limitations, etc.
16

17. How?
• Assistive technology users
– Speech output (screen readers)
– Braille output
– Voice input
– Magnification
17

18. How?
• Access services
– Captions
– Subtitles
– Audio description
– Sign language interpretation
18

19. Quick screen reader demo
19

20. Who?
Shared web experiences on mobile devices:
• Common ground between mainstream users and
users with disabilities
– Comparable to temporary disability (in the car, at
concerts, walking)
– http://www.w3.org/WAI/mobile/experiences
20

21. Who?
Shared web experiences on mobile devices:
• Empathy
– Accessibility is about understanding people and
the barriers that they face
– Getting your own experience of accessibility helps
you to put yourself in the shoes of others and keep
accessibility in mind when building and testing
your sites and applications
21

22. Who?
Shared web experiences on mobile devices:
• Innovation
– Assistive technology that are useful to all users!
– For example, Siri or custom vibrations on iOS
22

23. Constraints of mobile
23
Mobile by definition is disabling for all…
• Small screen
– iPhone is 1/12 of a typical desktop screen
– 40-pixel finger is big on small targets
– Can be hard to reach some parts of the screen
• Small text sizes – like having low vision
• Small input devices
• Eyes-free – like being blind, e.g. in car

24. Constraints of mobile
24
Mobile by definition is disabling for all…
• Reliant on touch
• Not as usable in the rain
• Need for special gloves
• One-handed usage
• Low light
• Connectivity, data limitation

25. Capabilities of mobile
• Better integrated accessibility than desktop
• Location and direction
• Camera and augmented reality
• Accelerometer (tilt/orientation, movement, speed)
• Touch screen
• Proximity (NFC)
• Environmental awareness (light/dark conditions)
25

26. Capabilities of mobile
26
• FaceTime used by deaf people
• Custom vibrations as ringtone
equivalents
• Speeches given using iPad with Proloquo
• HueVue app that helps colour blind
people to identify colours

27. Capabilities of mobile
27
• Braille:
– V-B-Reader app (Android) that enables Braille to be read
using vibrating touch screens
– Touch-screen Braille writer
• Innovative assistive technology that’s useful to all users!
– Apple’s Siri voice recognition
– Google Voice’s voicemail transcription
– Custom vibrations (iPhone setting and Android app)

28. How?
Two main interaction methods:
1. Explore by touch
– Drag finger over screen
– Items under your finger are
described by screen reader
– Tap with a second finger or
double tap to open/activate
2. Gesture navigation

29. How?
Two main interaction methods:
1. Explore by touch
2. Gesture navigation
– Swipe right/left moves focus to
next/previous content in
sequence
– Items are described by screen
reader as focus moves
– Double tap to open/activate

30. iOS Accessibility Features

31. iOS Accessibility Features
VoiceOver
1. Triple click the Home
key to activate
2. Dial to open the Rotor
3. Swipe up/down to
navigate parts
4. Swipe right/left for
next/previous content

32. iOS Accessibility Features
VoiceOver
1. Triple click the Home
key to activate
2. Dial to open the Rotor
3. Swipe up/down to
navigate parts
4. Swipe right/left for
next/previous content

33. iOS Accessibility Features
VoiceOver
1. Triple click the Home
key to activate
2. Dial to open the Rotor
3. Swipe up/down to
navigate parts
4. Swipe right/left for
next/previous content

34. iOS Accessibility Features
Other accessibility features
• These mostly “just work”, but must test in
combination – e.g. VoiceOver running with
Zoom may experience focus issues
• Pinch zoom
• Zoom (system-wide)
– Three-finger gestures for zoom
control/movement
– Zoom up to 5x
• Large Text / Dynamic Type

35. iOS Accessibility Features
Other accessibility features (2)
• LED Flash
• Mono audio and balance control
• Hearing aid support
• TTY (used by the Deaf)
• iMessage
• Visual Voicemail
35
• Invert Colors / Black on White
• Assistive Touch
• Captioned content
(QuickTime)
• Guided Access
• Speak selection
• Custom vibrations

36. Android Accessibility
Features

37. Android Accessibility Features
• TalkBack
– Bundled since version 4.0 (Ice Cream Sandwich)
– Since Jelly Bean, it behaves a lot like iOS
– Eyes-Free Keyboard
• Download as necessary for accessing web views
• Haptic feedback
• Large text
• Zoom
• TalkBack on Jelly Bean (9 mins 47 secs.)
– http://youtu.be/w3Sz3KNkQ4U

38. Android Accessibility Features
TalkBack
1. Install Eyes-Free keyboard
2. Enable TalkBack via settings
3. Explore screen by touch
4. Single tap to activate

39. Android Accessibility Features
Browsers with good accessibility support
• Native (WebKit)
– being replaced by Chrome as default browser
• Chrome
– requires Ice Cream Sandwich
• Firefox Nightly
– looks set to provide the best accessibility support
• Ideal Web Reader

40. Standards and guidelines

41. The problem:
• There is no one set of internationally accepted mobile
guidelines and standards
• WCAG was written for desktop
• Mobile is more diverse than desktop and is developing
quickly – more browsers, OSs, hardware, software
• We fall back on WCAG 2.0, which provides a sound
foundation but is only the start of the story
41
Standards and guidelines

42. • BBC Mobile Accessibility Guidelines
– The best reference we have to date
– Technology-agnostic standards and guidelines
– Technology specific techniques – HTML, Android, iOS
– Getting to grips with a mobile accessibility strategy
• Resources for Mobile Accessibility Guidelines
42
Standards and guidelines

43. • Web Accessibility Initiative resources (now fairly dated)
– Mobile Web Best Practices (MWBP) 1.0 (last updated mid-2008)
– Web Content Accessibility Guidelines (WCAG) 2.0
– Relationship between MWBP and WCAG
• Mobile Accessibility Guidelines by Funka Nu
– Released in March 2012, these are more up to date
• Nielsen Norman Group have a useful report:
Usability of iPad Apps and Websites
43
Standards and guidelines

44. Device-specific guidelines and standards:
• iOS Accessibility Programming Guide
• Android Designing for Accessibility
• Android Developers Accessibility Guide
• Nokia user experience for touch checklist (PDF)
• Nokia user experience checklist for keyboard (PDF)
• Design Guidelines for Windows Mobile
• Widget Accessibility Guidelines
44
Standards and guidelines

45. • Be aware of the laws governing accessibility in your
country
• Section 508
– US Federal Government websites
– ‘information and communication technology’ must be WCAG
2.0 compliant
• 21st Century Act says by 2013 phones must ship with
accessible browsers
– No defense for inaccessible content when handsets and
browsers are accessible
45
Legal requirements

46. General principles

47. • We know what assistive technology is, but how does it work?
• Accessibility APIs
– Present user interfaces as information rather than a purely
graphical medium, translating an application’s user interface into
information that assistive technology can understand
– Allow an application’s user interface to be changed by the
assistive technology
– Provide a common vocabulary we can use when talking about
accessibility.
47
Theory: accessibility APIs

48. • Accessible Object Properties
– User interface is represented as a hierarchy of accessible objects
– Each object has a variety of properties, such as:
• name: Defines a label. (“Hi, what’s your name?)
• role: Defines the behavior. (“So, what do you do?”)
• state: Defines the current condition. (“How are you?”)
• Accessible Events
– Accessibility APIs notify assistive technologies of changes by
broadcasting events
48
Theory: accessibility APIs

49. The Mobile Web

50. The Mobile Web
Principles of mobile accessibility
• Use progressive enhancement
• Use web standards as intended
• Support platform accessibility settings and assistive
technology
– HTML5 input types and contextual keyboards, e.g. number,
email, date
– Support for ARIA is good on Mobile Safari and Chrome and
Firefox for Android
– iOS/Android do not identify the type of landmark roles
50

51. Forms

52. Forms
Typical barriers of access
• Missing labels
– Voice output and sighted users don’t know what to
input
• Lack of input types
– Users forced to use free input, likely to make mistakes
• Error handling
– Lack of help prevents forms being submitted
52

53. Forms
Label form inputs:
• HTML label element is best
<label for="first-name">First Name</label>
• WAI-ARIA aria-label
– only works when there is no HTML label
• HTML title attribute
<input id="name" name="name" type="text" value=""
title="Your name">
– But not accessible to sighted users
53

54. Forms
Group related form elements:
• Group related elements using
<fieldset>
• Caption the related elements using
<legend>
54

55. Forms
<fieldset>
<legend>filter by</legend>
<input type="radio" name="filter" id="a">
<label for="a">television</label>
<input type="radio" name="filter" id="b">
<label for="b">radio</label>
<input type="radio" name="filter" id="c">
<label for="c">cinema</label>
</fieldset>
Browser output:
55

56. Forms
• Voice output:
“Filter by radio button television, radio button radio,
radio button cinema”
Or:
“Filter by radio button television, Filter by radio
button radio, Filter by radio button cinema”
56

57. Forms
• Replace free input with drop downs, radio buttons, etc.
• Use HTML5 input types
– Supported in Mobile Safari and Webkit (Android)
– Contextual keyboards in iOS
– Previous, Next…

58. Forms
• Use colour to reinforce meaning, not alone
– Avoid ‘All fields marked in red are required’
– Inaccessible to blind, colour blind users
– Colour output may also vary across devices
58

59. Forms
• Consider inline validation
(when appropriate)
• Draw focus to error
• Don’t rely on colour alone
• Make message clear
• Suggest how to correct
• Provide ease of navigation away from error
59

60. Error handling
• Use programmatically readable instructions
– Add ‘required’ to the <label>
<label for="name">Your Name (required)
</label>
– Progressively enhance with:
<input type="text" required> (iOS 5+)
Note: Using both techniques does not result in ‘required’ being
announced twice.
60

61. Session timeouts
• Users with visual, physical or cognitive disabilities may
need more time to read and interact with pages
• Choose one of the following recommendations:
– Allow users to turn off the time limit
– Allow users to adjust the time limit (allow a range of
options and at least ten times the default)
– Allow users to extend the time limit (show a warning
before timeout, give at least 20 seconds to easily extend
time, e.g. by pressing the space bar)
61

62. Focus management
• Screen reader focus is not the same as
keyboard focus on desktop
• Set focus in a web view:
var button =
document.getElementsByTagName('button')[0
];
button.focus();
• Set focus using tabindex="0"
62

63. Speech
Control speech verbosity
• VoiceOver announces ‘12345’ as ‘Twelve thousand
three hundred and forty-five’
• Announce ‘One, two, three, four, five’ using:
.address {speak: digits;}
• VoiceOver announces ‘1 != 2’ as ‘One equals two’:
code {speak: literal-punctuation;}
63

64. WAI-ARIA

65. ARIA
<div tabindex="0" act="20" class="T-I J-J5-Ji nu T-I-ax7
L3" style="-moz-user-select: none;" data-tooltip="
Refresh">
<div class="asa">
<span class="J-J5-Ji ask">&nbsp;</span>
<div class="asf T-I-J3 J-J5-Ji"></div>
</div>
</div>
65

66. ARIA
<div role="button" aria-label="Refresh" tabindex="0"
act="20" class="T-I J-J5-Ji nu T-I-ax7 L3" style="-moz-user-
select: none;" data-tooltip="Refresh">
<div class="asa">
<span class="J-J5-Ji ask">&nbsp;</span>
<div class="asf T-I-J3 J-J5-Ji"></div>
</div>
</div>
66
“Refresh button”

67. <a href="#">Favorite</a>
ARIA
67

68. <a href="#">Favorite</a>
ARIA
68
“Favorite link”
“Click the Favorite button to favorite a
post” would not be correct for assistive
technology users.

69. ARIA
<a role="button" href="#">Favorite</a>
69
“Favorite button”
Fixed semantics!
But… using a button element would
be even better and would provide
expected behaviours for free!

70. ARIA
Mobile support for WAI-ARIA
Source: http://caniuse.com/#feat=wai-aria 70

71. Structure and layout

72. Structure and layout
Typical barriers of access
• Headings and Landmarks not marked up
– Voice output users can’t navigate
• Landmarks are not labeled
– Voice output users don’t know where they are in a
page
• Content order is incorrect
– Flow of content is illogical
72

73. Structure and layout
• Responsive Design
– Screens of 320-pixel width are typical but not guaranteed
– Test only the elements that change at each of the supported
screen resolutions
– Remember to test both landscape and portrait
• Guidelines
– http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-
web-design/
• Resource: Responsive Web Design by Ethan Marcotte
– http://www.abookapart.com/products/responsive-web-design
73

74. Structure and layout
• Use semantic and structured
mark-up
– Headings
– ARIA landmarks
– Lists
– Data tables
• HTML5 structural elements
not yet well supported
74

75. Structure and layout
• New HTML5 control types are well supported on iOS (5+) and
Android (Chrome and Firefox)
– type="date"
• type="month"
• type="time” …
– type="email"
– type="range"
– type="tel"
– type="url"
– And more…
75

76. Structure and layout
Landmarks
• Landmarks describe parts of the page (e.g. main,
search, navigation)
• iOS and Android do not currently distinguish between
types of landmark
– Next item of content is read with the landmark instead, for
example:
role="main"…
<h1>Mobile accessibility</h1>…
VoiceOver announces:
”Landmark, Mobile accessibility, heading level 1”
76

77. Structure and layout
Content order
• Ensure a logical content order:
– An H1 follows role="main"
– Main content follows an H1
– An H2/3/4 follows
role="complementary"
– An H2/3/4 follows role="navigation"
– Duplicated links grouped in one <a href>
77

78. • Logical order is generally left to
right, top to bottom
• Sometimes poor code choices
cause strange focus order
• Generally best to let the order
of elements in the source code
determine the focus order
78
Structure and layout
Content order

79. Testing
79

80. Top 5 tests
1. Browse the site with a screen reader
2. Check markup and structure
3. Interact with all forms
4. Tab/gesture through the page
5. Images have appropriate text alternatives
80

81. Top 5 tests
1. Browse the site with a screen reader
– Tests the user experience
– Can pick up many issues in one go
81

82. Top 5 tests
2. Check markup and structure
– Quick check: W3C Nu Markup Validator
– Appropriate markup structures and semantics
82

83. Top 5 tests
3. Interact with all forms
– Are they clearly labelled and include
instructions?
– Check error messages are clear and easy to find
83

84. Top 5 tests
4. Tab/gesture through the page
84

85. Top 5 tests
5. Images have appropriate text alternatives
– Use the alt text decision tree
85

86. Top 5 tests
• Missing?
– Pages and frames are titled
– Link text is appropriate to target (covered by tabbing through)
– Headings exist and are appropriate
– Navigation is consistent
– Alternative means of locating pages is provided
– Repetitive navigation can be skipped
86

87. Top 5 tests
• Missing?
– Non-HTML content is accessible (PDF, Flash, etc.)
– All visible content is conveyed to assistive technologies
– Hidden content is not conveyed to assistive technologies
– Appropriate colour contrast
– Colour is not used as the only means of conveying information
– Animated content can be paused, stopped, or hidden
87

88. Top 5 tests
• Missing?
– Accessible alternatives for audio and video content
– Language
– Role and state information
– Animated content must not cause seizures
– Users are allowed enough time
– Content can be resized
88

89. • Make a test strategy
– Henny Swan has developed a great starting point
• http://www.iheni.com/mobile-accessibility-tests/
– Test with:
• Both zoom and speech output features off
• Speech output only
• Zoom only
• Both zoom and speech output features on
• Inverted colours
89
Testing

90. Testing on iOS
• Cheat sheet for learning the gestures used on
VoiceOver for iOS: http://a11y.cc/iosvoref
Tip:
• You can use the Simulator or AirPlay to check colour
contrast.
90

91. Summary
Let’s recap…
91

92. Summary
• An introduction to mobile accessibility
• How people with disabilities use mobile
devices (iOS and Android)
• How to go about building in accessibility on
mobile
92

93. Questions?

94. Thank you!
• I’m Jon Gibbins
– @dotjay on Twitter
– For more information contact: jon@diginclusion.com
• Slides will be available on Lanyrd
• Feedback gratefully received!
• Please also tweet feedback and photos #digpen
• Note: Contributions from The Paciello Group used with
permission
© Jon Gibbins 94

95. Appendices
95

96. Benefits of digital inclusion
96

97. Making a case
• Search engine optimisation
• Increased usability and business
• Reduced development and maintenance time
• Improved stability and interoperability
• Reduced server load
• Cost savings
• Reputation
• Competitive advantage
• Compliance with law
97

98. Making a case (continued)
• Informed by:
– Web statistics
– Cost versus savings analysis
– Corporate Social Responsibility
– Non-quantifiable benefits
• Developing a Web Accessibility Business Case for Your
Organization
– http://www.w3.org/WAI/bcase/
98

99. Making a case (continued)
• Search engine optimisation
– “The Internet’s biggest blind user is Google”
– Valid code is easily digestible
• Increased usability and business
– Close ties between accessibility and usability
– Expanding and diversifying the customer base
– Overall increase in business volumes
99

100. Making a case (continued)
• Reduced development and maintenance time
– Accessibility can save your developers time
– Easier to automate testing
• Improved stability and interoperability
– Accessibility encourages valid code, making your websites and
applications more robust and more likely to work with other
software
• Reduced server load
– Leaner code, easier to serve, less bandwidth
100

101. Making a case (continued)
• Cost savings
– Proven return on investment
– Increased sales and improved profitability
– Time and reduced server load
• Reputation
– Corporate Social Responsibility
– “An accessible website will make you look good”
– A better, more usable website will earn you a good reputation
– Loyal customer base, word-of-mouth advertising, and repeat
business
101