Introduction to mobile accessibility, 2015

1. Introduction to mobile accessibility Henny Swan

2. This is a full day workshop I gave at AccessU 2015 and an updated version of the same workshop I gave at AccessU in 2013. As an introduction to mobile accessibility it covers key concepts, user experience, development and some QA. It is intended mostly for a non-‐technical audience who are looking for an introduction to mobile web accessibility and native apps although it does contain some technical guidance. 2

3. Agenda • Requirements and planning • User experience • Development • QA and testing 3

4. Hand outs and slides • Handouts available now in   http://bit.ly/1e0Wn8g • Slides to follow • Follow @iheni for URLS • All questions are good questions • Today is about sharing 4

5. Henny Swan • User Experience and Design Lead, The Paciello Group • Formally BBC, Opera Software, Royal National Institute of Blind People • Specialize in accessible user experience, mobile, media players, strategy • Member of W3C Mobile Accessibility Task Force. User Agent Accessibility Working Group and Web of Things Task Force

6. You • Name • Company • Role • Your experience of accessibility • Device

7. MOBILE ACCESSIBILITY LANDSCAPE

8. Audience: who Diversity in disability: • Type of impairment(s) • Severity of impairment(s) • Circumstances of acquisition of impairment(s) • Changeable impairment(s) 8

9. Audience: who Diversity in disability: • Assistive technology and settings* used: • Vendor • Version • Conﬁguration • Aptitude in using AT • Attitude to using AT * Assistive technologies include screen readers, zoom, text resizing, voice input, invert colors 9

10. Audience: who We all face being impaired: As a child… Unable to hold a tablet Unable to use certain gestures Unable to understand text and iconography As an older user… Reduced sight, hearing, cognition Problems with perception Temporarily Broken wrists, RSI, carpel tunnel Designing touch tablet experiences for preschoolers – Sesame Street 10

11. Audience: Personas • Persona resources from the W3C Mobile Accessibility Task Force 11

12. Judy Dench Ability: Advanced macular degeneration and mild arthritis Aptitude: Hasn’t really used tech much but realizes she now has to and uses an iPad Attitude: Willing but is too busy to dedicate the time 12

13. Gary Numan Ability: Autism Spectrum Disorder. Uses zoom and occasionally VoiceOver when he is tired Aptitude: Uses tablets for news and research, but doesn’t learn new sites easily Attitude: Prefers apps to mobile content and an established routine 13

14. Sinead O’Conner Ability: Fatigue from ﬁbromyalgia, touch screens, tapping and scrolling are hard Aptitude: Average user, has good days and bad days Attitude: Wishes the hardware made more sense 14

15. Marlee Matlin Ability: Native language is ASL; can speak and read lips; uses SMS/IM, Skype, and video chat Aptitude: Good with graphic tools, and prefers visuals to text; poor spelling makes searching more diﬃcult Attitude: Gets annoyed by lack of subtitles 15

16. Stephen Hawking Ability: Suﬀers from acute Motor Neurons Disease, no movement or speech Aptitude: Super user, patient, curious, but is a busy man Attitude: Tries anything, knows what he wants, determined -‐ this is his only line of communication 16

17. Barriers -‐ Input • Dexterity and touch • Single handed • Environment and voice 17

18. 18 I’m going to stick with my Nokia C5. I want my mobile to be something that’s mobile, as in I can walk and use it without having to stop. -‐ Hugh Huddy, blind Nokia and Talks user

19. Barriers -‐ orientation • Forced orientation • Mounted tablets • Limited scrolling • Content changes 19

20. Barriers -‐ Zoom and text resize • Pinch zoom being disabled • Loss of context • Floating toolbars • Pop ups 20

21. Barriers -‐ Zoom 21 • Fixed position content

22. Barriers -‐ Zoom 22 • Snap scrolling

23. Barriers – cognitive overload • Inconsistent design • Excess clutter • Ambiguous labels • Ambiguous icons • Poor error handling • Where am I?

24. Opportunity -‐ platform features • Geolocation • Camera • Contacts • Phone 24

25. Opportunity -‐ Web of Things • Home energy management • Healthcare and fitness • Google’s Physical Web • Identity management and authentication • Casting, audio and video control 25

26. Web and mobile standards A significant but not exact mapping between desktop and mobile • Touchscreen on both desktop and mobile • Mobile devices with external keyboards • Responsive design • User interface patterns from desktop used on mobile (links, tables, buttons, menus etc) 26

27. Legal requirement 21st Century Act, USA. By 2013 smartphones: • must have an accessible browser • must be accessible at the OS level • must have free or of “nominal cost” soluQons ImplicaQons • North American mobile market inﬂuenQal globally • Apple, Google, MicrosoU, RIM SecQon 508 Refresh • ‘informaQon and communicaQon technology’ must be WCAG 2.0 compliant 27

28. Standards and guidelines W3C guidelines: • Web Content Accessibility Guidelines (WCAG) • How WCAG and UAAG apply to mobile devices • Shared experiences: Barriers common to mobile device users and people with disabilities • Mobile Accessibility Overlap • Independant User Interface (Indi UI) Working Group 28

29. Standards and guidelines iOS guidelines: • Accessibility Programming Guide for Developers • Human Interface Guidelines for Designers 29 Android guidelines: • Making applications accessible • Accessibility Developers checklist • Android design: accessibility

30. BBC Mobile Accessibility Standards and Guidelines • Technology agnostic • iOS, Android and HTML techniques • Test procedures 30

31. 31

32. 32

33. 33

34. Platform and browser support Define the delivery context • Responsive • Native app • Hybrid 34

35. Platform and browser support Define supported devices: • Reference pre-‐existing platform and browser support plans • What devices have sufficient accessibility support • What devices have accessible native browsers • What devices are easy to upgrade • Version support 35

36. Platform and browser support Define supported devices: • Analyze web stats • Assess regional preferences • Assess local legal requirements • Research user preferences Output: mobile platform and browser support matrix with version support logic 36

37. Platform and browser support Webaim screen reader surveys • Surveys screen reader user preferences of web and mobile usage • Every year since 2009 • Open to anyone • 2014 survey results: • 1456 respondents • 61% from the US, 21% UK and EU, Asia 10%… • 95% reported having a disability 37

38. WebAim screen reader survey 38

41. TPG 2013 MOBILE SURVEY 41 http://www.paciellogroup.com/mobile/

42. Breakout session Write a Mobile Accessibility Strategy for a product including • Product name and purpose • Target audience • Platform, access technology and browser support • HTML, native or hybrid 42

43. MOBILE ACCESSIBILITY FEATURES

44. Mobile accessibility landscape iOS Accessibility features and API are the most mature Android has some good accessibility features Google are working to improve Current market share favors iOS and Android devices over other vendors BlackBerry Curve smartphones have free BlackBerry Screen Reader Windows Phone 8.1 Text resizing, High Contrast mode, Narrator, screen magniﬁcaQon, Zoom 44

45. iOS accessibility features 45 Seang User Voiceover Blind, low vision, learning and cogniQon Zoom, Large Text Blind, low vision, learning and cogniQon Invert colors, Grey scale Low vision, color blindness, learning, cogniQon Speak selection Low vision, learning and cogniQon Speak auto-‐text Blind, low vision, learning and cogniQon Hearing aid mode Deaf, hard of hearing, deaf blind Customize closed captions Deaf, hard of hearing, everyone Guided access Everybody including children &educaQon Assistive touch Mobility Switch control Mobility, hands free

46. iOS -‐ mapping accessibility shortcuts 1. Go to Settings > General Accessibility > Accessibility Shortcut 2. Select shortcuts 3. Triple click the Home key to activate 46

47. iOS -‐ switch support • iOs7+ • Using an external device or FaceTime • Accessed via Settings > Accessibility > Switch control 47

48. Switch control in iOS8 -‐ Luis Perez 48

49. iOS -‐ VoiceOver • Supports 36 languages • Gesture and explore by touch support • Supports braille output • Excellent browsing support 49

50. iOS -‐ activating 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 50

51. iOS -‐ rotor navigation 1. Dial gesture on screen 2. Select how you want to navigate 3. Swipe up or down 51

52. 52 Gesture FuncGon Switch VO on/off Triple click the home key Speak an element Single tap pActivate an element Double tap Open the Rotor Turn a dial Zoom 3 finger double tap -‐ iOS6+ only Next section in Rotor Swipe up/down Next/previous item in content order Swipe right/left Pass through gesture (drag & drop) Double tap hold Play/Pause 2 finger double tap iOS -‐ basic VoiceOver gestures

53. 53 3 ﬁnger triple tap Screen curtain

54. 54

55. Seang User Voice output Blind, low vision, learning and cogniQon HapGc feedback Blind, Deaf-‐Blind, Low vision, deaf Large text Low vision, cogniQon, learning Speak passwords Blind, low vision, cogniQon, learning Enhance web accessibility Blind Android -‐ accessibility features

56. Chrome: Force enable zoom Text size Text scaling Zoom on double-‐tap Minimum font size Inverted colors Contrast A useful ‘screen curtain’ equivalent Shades app can also do this 56 Android -‐ browser settings

57. Enable WebScripts via Settings > Accessibility > ‘Enable Accessibility’ Download the Eyes Free Keyboard Browsing Less reliable than iOS ApplicaQons Talkback well supported Beware hybrid content Maps, adverts, Terms and CondiQons, Help pages etc 57 Android -‐ Talkback

58. 58 Android -‐ Talkback

59. Zoom OS-‐level features • Set default text size • Magnifies entire screen • Magnifying lens view under user's finger • 3 finger scroll 59

60. Zoom Browser-‐level features • Set default text size of text in the browser • Reader mode (not universally supported) • Pinch zoom 60

61. Zoom Browser-‐level features • Magnifying lens view under user's finger • Force enable zoom (Chrome, Android) 61

62. Breakout session Using iOS or Android try using each of the following: • Screen reader • Zoom • Head switch Refer to the handouts which have set up and gesture instructions. 62

63. USER EXPERIENCE

64. As a user I want… • WCAG Level AA compliance • WAI ARIA • Validated code Said no user ever! 64

65. Accessibility and inclusive design Standards and guidelines tend to focus more on: …code over design …output over outcome …compliance over experience 65

66. – I A N P O U N C E Y, W E B D E V E L O P E R , B B C “It pains me to say this but web developers might not be the most important people when it comes to making accessible websites and web apps.”

67. Principles of accessible UX 67

68. People first • Put people before technology • Consider environment and context • Consider ﬁrst time users and repeat users • Consider AT super users, average users, or basic users 68

69. 69 iOS start up screens

70. 70 Android start up screens

71. Focus Prioritise key features in the layout and content order Remove unnecessary elements Group elements logically, visually and in the content order Progressively reveal content on user request 71

72. “ T h e o b v i o u s i s a a b o u t a l w a y s ”

73. Focus 74

74. Choice Provide multiple ways to: • Access key tasks, screens or information • Complete key or complex tasks • Complete non standard interactions 75

75. Choice 76

76. Control What ways can user controls over content be suppressed? 77

77. Control What ways can user controls over content be suppressed? • Orientation 78

78. Control What ways can user controls over content be suppressed? • Orientation • Pinch zoom 79

79. Control What ways can user controls over content be suppressed? • Orientation • Pinch zoom • Right click (web) 80

80. Control What ways can user controls over content be suppressed? • Orientation • Pinch zoom • Right click (web) Support browser and platform accessibility features 81

81. Control 82

82. Control iOS7+ closed caption customization: • Font • Size • Color • Background color • Background opacity • Text edge style • Text highlight 83

83. Familiarity BBC Radio iOS app’s custom ‘dial’. “Although the 3 finger swipe works for exposing stations, it’s not intuitive… it would be nice if some alternative solution could be implemented as someone new to the app probably wouldn't think of doing that, and of course it should be pointed out that VoiceOver gives no feedback when you do the 3 finger swipe” 84

84. Prioritise features that might be of particular value for everyone • Platform features • A to Z, filters, sort, manage, delete • Web of things Value 85

85. Value 86 GeolocationPhoneCamera

86. Value Web of Things • Health • Home • Entertainment 87 • Energy • Education • Security

87. Breakout session What features might you add to your product to provide a better user experience for diverse users? 88

88. DESIGN

89. Color contrast -‐ desktop Based on 15-‐inch monitor at 1024x768 resolution with a 24-‐inch viewing distance WCAG 2.0 recommends: • contrast of 4.5:1, 14pt text • contrast ratio of 3:1 for 18pt+ 90

90. Focus states • Use distinctive hover/focus states • Ideally use the same hover state on focus • Selected states must be unique 91

91. Visual cues • Navigation must be visually explicit • Distinguish interactive elements 92

92. Visual cues What’s wrong with the visual cues on this screen? 93

93. Visual cues -‐ iconography Question mark, home, burger for home, disc for save, back arrow etc 94 GridAdd List Menu

94. Visual cues -‐ conventional positioning 95

95. Positioning -‐ reach • Optimize for use one handed • Important content bottom left to right • Position important content above page scroll 96Mobile First by Luke Wroblewski

96. Consistent layout -‐ platforms 97 Netflix on desktop

97. Consistent layout -‐ Platforms 98Main menu when open Sign out at the foot of the page

98. KEYBOARD AND TOUCH

99. Keyboard control • Via on screen keyboards and via physical keyboards • On touch, with VO and Talkback running ‘keyboard access’ includes static and hidden content as well as focusable elements • Everything related to content and functionality must be focusable 100

100. 101

101. Touch events Mouse or touched events prevent unintentional triggers when interacting • Gives mouse users the opportunity to move the cursor outside the element to prevent the event from being triggered • Only triggers elements on touch when the user lifts the finger off the screen, the last position of the finger is inside the actionable element, and the last position of the finger equals the position at touch start 102

102. Touch target size 103 “The fingers you have used to dial are too fat. To obtain a special dialling wand, please mash the keypad with your palm now.”

103. Touch target size Standard touch target size of 7-‐10mm Jacob Neilson recommends 9.2 -‐ 9.6mm Android Touch target size of 48dp/9mm Spacing between UI elements 8dp iOS Touch target size of 44px / 44px tall PosiQoning Provide 1mm inacQve space around elements Balance enough informaQon density and targetability of UI Elements PosiQon content appropriately 104

104. Touch target size Group links to the same resource • Larger touch target • Removes repetition for screen reader users • Less swiping and physical overhead needed 105

105. Gestures Easier / more intuitive Tap Draw / Move finger Swipe Drag Slide Double tap Harder / least intuitive Pinch Device manipulation e.g. tilt / shake Multi-‐touch Flick / Fling Reference: Designing touch tablet experiences for preschoolers – Sesame Street

106. Gestures -‐ device manipulation • Device manipulation = tilting, shaking etc • Challenge to people who can not hold a device • Discoverability and accidental activation also an issue • Always provide touch and keyboard operable alternative 107

107. Zoom / Magnification • Consider mobile first when designing layout and content relevancy • Minimise content in comparison to desktop • Provide a reasonable default size for content and touch controls • Adapt link text length to adapt to the viewport • Position form fields above rather than beside form labels (in portrait layout) 108

108. Zoom / Magnification -‐ HTML Avoid <meta content=”width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=1;” name=”viewport”> Use <meta content=”width=device-width; initial-scale=1.0; maximum-scale=2.0; user-scalable=1;” name=”viewport”> iOS bug: Scale and orientaQon Jeremy Keith 109

109. 110

110. FORMS

111. Forms -‐ labels • Auto zoom cuts off left aligned labels • Labels above the field are always in view • Label explicitly (HTML) for larger touch zones 112

112. Forms -‐ viewport Use the correct viewport: • Responsive: <meta name=”viewport” content=”width=d evice-width” /> • Mobile: make sure the viewport is the width of your layout (usually about 320 pixels • CSS for padding and large touch targets 113

113. Forms -‐ keyboards • Default keyboard -‐ capitals, numbers, special characters, punctuation buried in sub menus • Use HTML text input types to invoke task based keyboards 114

114. Keyboards 115

115. Forms -‐ sign up • Minimise data entry • Gradual engagement • Third party sign up 116

116. Forms -‐ autofill and predictive text • Support both where logical • Disable where logical e.g. for names, email addresses • iOS5 • autocapitalize=”sentences” autocapitalize=”words” autocapitalize=”characters” 117

117. ALTERNATIVES

118. Alternatives are used for… • Images • Buttons • Graphs, charts, diagrams • Audio • Video 119

119. Editorial for alternatives… • Briefly describe the image • Do not describe the role / Trait • Begin with a capitalized word • Don’t end with a period (.) • Localized 120

120. Alternative text -‐ HTML Assign contentDescription to all user interface components e.g.: • alt=“” • alt=“Home” • alt=“Austin University Campus” 121

121. Tooltips -‐ HTML • Not well supported on mobile and touch • Not always accessible on desktop • Never include primary information • If in doubt just say no 122

122. Alternatives -‐ Android Assign contentDescription to all user interface components e.g.: • imageButton • imageView • checkbox Decorative images should not have a contentDescription 123

123. Labels -‐ iOS accessibilityLabel must be provided for all interacQve and informaQonal elements including images, buoons, headings, staQc text and form ﬁelds 124

124. Hints -‐ iOS accessibilityHints may be used to provide further informaQon • Describes what an element does • Must not include informaQon about the objects type (i.e. Trait) • Use sparingly and not for key informaQon Must be a descripQon not a command e.g. ‘Deletes programme’ not ‘Delete programme’ 125

125. Traits -‐ iOS Assign accessibilityTrait to all user interface components Traits describe control type or behavior Control types are mutually exclusive and describe the nature of the item More than one behavior trait can be used to describe what items do 126

126. Traits -‐ iOS • None • Button • Link • SearchField • Image • Selected • PlaysSound • KeyboardKey • StaticText 127 • SummaryElement • NotEnabled • UpdatesFrequently • StartsMediaSession • Adjustable • AllowsDirectInteraction • CausesPageTurn • Header

127. 128

128. STRUCTURE

129. content a logical order provide 130

130. provide a logical content order 131 Don’t make your content sound like Yoda

131. Headings HTML • Headings indicated using H1 to H6 Android • No means to indicate headings iOS • Use accessibilityTraitHeader 132

132. Headings Headings and lists H1 to H6 OL and UL NavigaQon to headings and the start of lists for screen readers Seven plus or minus 2 The opQmum number humans process informaQon In taxonomy this translates to 5-‐9 headings Headings as lists Content under a heading may be removed on mobile Consider lists over headings Avoid mixing both 133

133. Headings -‐ HTML 134

134. Headings 135

135. Headings -‐ iOS • iOS 6+ • UIAccessibilityTraitHeading • Accessed via the Web Rotor 136

136. Landmarks -‐ HTML Landmarks reach the parts of the page other HTML can not reach • 1 ‘main’ per page • 1 ‘header’ • use ‘navigation’ for navigation between pages • ‘complementary’ for reusable content • Use sparingly 137

137. Landmarks -‐ HTML HTML5 sectioning elements map to ARIA Landmarks • article maps to role=“article” • aside maps to role=“complementary” • footer maps to role=“contentinfo” • header maps to role=“main” • nav maps to role=“navigation” • section maps to role=“region” 138

138. 139

139. 140

140. ANNOTATED UX

141. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold…

142. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold: 1. Expose accessibility issues that originate from the design

143. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold: 1. Expose accessibility issues that originate from the design 2. Document accessibility requirements prior to coding

144. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold: 1. Expose accessibility issues that originate from the design 2. Document accessibility requirements prior to coding 3. Stop developers mucking up your designs!

145. Risks of not doing it • Designs come back to you once signed off with questions and clarifications • Designs are interpreted and coded incorrectly • Consistency, value, choice and familiarity for the user will be compromised

146. Annotated UX – iPlayer BBC One homepage

147. Annotated UX – iPlayer native Android app

148. Breakout session: Annotated UX Refer to either the response wires or iOS wires in the handouts: 1. What should be changed for accessibility? 2. Annotate the wireframes for accessibility 3. How would you document requirements in an accessible way?

149. What else can annotated UX be used for? Wireframes Visual design Style guides Usability testing Accessible prototypes Requirements User stories Pattern libraries Manual tests Automated tests

150. TESTING

151. Testing -‐ HTML • W3C developing a mobile checker • User agent switchers 154

152. Remote debugging iOS • iOS in Safari (also Android) • iOS select Settings > Safari >  Advanced and switch Web Inspector on • Mobile Safari Preferences >  Advanced and select Show   Develop Menu in menu bar 155

153. Remote debugging 156

154. Remote debugging Android • Enable USB debugging via Settings > Developer options • Note -‐ On Android 4.2 and later, the developer options are hidden by default. To enable the developer options, select Settings > About phone and tap Build number seven times. • Select USB debugging 157

155. Remote debugging Android • In Chrome go to chrome://inspect • Select ‘Discover USB devices • Conform allow USB debugging 158

156. Remote debugging Android The chrome://inspect page displays every connected device, along with its open tabs and debug-‐enabled WebViews 159

157. Remote debugging Android Select Inspect on the tab you want to inspect 160

158. Testing -‐ Android Android emulator • Virtual device in the Android SDK • Configurable to mimic different devices • Contains a debug console 161

159. Testing -‐ Android • Lint • Finds missing contentDescriptions • Finds missing input types on text fields • Quick fix window • Write custom scripts to test 162

160. xCode iOS Simulator 163

161. 164

162. Manual testing • Always manually test websites and apps • Simulators, automated tests, inspecting code will not spotlight usability issues 165

163. Top tests for voice output 1. Content and focus order 2. Alternatives exist and make sense 3. Structure is communicated 4. Form labels and instructions 5. Notifications are provided 166

164. Top tests for zoom 1. Context is not lost 2. Labels for forms are visible above form inputs 3. Screens are not cluttered 4. Primary information is obviously positioned 5. Notifications are visible on screen 167

165. Top tests for greyscale / invert colors 1. Text is readable 2. Color contrast is sufficient 3. Color is not relied upon to convey meaning 168

166. Breakout session Using either zoom, switch or a screen reader (with screen curtain on for iOS) complete the following: 1. On the Airbnb find a place to stay in Austin between September 1st and 7th, for 2 people for under $200 2. Using both Twitter and Facebook send a Tweet or post a comment using the #AccessUSummit hashtag 169

167. Want to suggest your site? 170

168. THANK YOU

169. Thank you • Hand outs and slides at • hswan@paciellogroup.com • @iheni • www.iheni.com 173

170. iOS Design Principles: Direct manipulation 174

171. iOS Design principles: feedback 175

172. Android design principles Enchant me • Delight me in surprising ways • Real objects are more fun than buttons and menus • Let me make it mine • Get to know me 176

173. Android design principles Simplify my life • Keep it brief • Never lose my stuff • Pictures are faster than words • Decide for me but let me have the final say • Only show what I need when needed • I should always know where I am • If it looks the same it should act the same • Only interrupt me if it’s important 177

174. Android design principles Make me amazing • Give me tricks that work everywhere • It’s not my fault • Sprinkle encouragement • Do the heavy lifting for me • Make important things fast 178

175. Alternatives -‐ testing Test 1. Switch on speech output 2. Navigate to images, elements and objects either by • Explore by touch (Android/iOS) • Swiping up/down, leU and right 3. Verify an alternaQve is provided 4. Verify the alternaQve accurately describes the content or funcQon Expected results • Each meaningful images element and object has an alternaQve • AlternaQves describe either the • content of a non-‐funcQonal image, element or object • the funcQon of an acQonable image, element or object 179

176. Color contrast -‐ mobile • Only use 3:1 when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size • Still wont guarantee access for low vision. Platform specific tools may need to be used. 180