Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to mobile accessibility

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/

Related Books

Free with a 30 day trial from Scribd

See all
  • Login to see the comments

Introduction to mobile accessibility

  1. 1. Introduction to Mobile accessibility Digpen 7 25 Sep 2014
  2. 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. 3
  4. 4. Photo credit: LG, GD910 watch phone 4
  5. 5. Jon Gibbins / Drake Music 5
  6. 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. 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. 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. 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. 10. Accessible People with disabilities can perform the same functions… receive same information… and participate as producers and consumers.
  11. 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. 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. 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. 14. Who? • Four main user groups with diverse needs: – Vision (blind, partially sighted) – Hearing (deaf, hard of hearing) – Mobility – Cognitive and learning 14
  15. 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. 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. 17. How? • Assistive technology users – Speech output (screen readers) – Braille output – Voice input – Magnification 17
  18. 18. How? • Access services – Captions – Subtitles – Audio description – Sign language interpretation 18
  19. 19. Quick screen reader demo 19
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. iOS Accessibility Features
  31. 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. 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. 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. 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. 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. 36. Android Accessibility Features
  37. 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. 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. 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. 40. Standards and guidelines
  41. 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. 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. 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. 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. 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. 46. General principles
  47. 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. 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. 49. The Mobile Web
  50. 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. 51. Forms
  52. 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. 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. 54. Forms Group related form elements: • Group related elements using <fieldset> • Caption the related elements using <legend> 54
  55. 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. 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. 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. 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. 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. 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. 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. 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. 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. 64. WAI-ARIA
  65. 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. 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. 67. <a href="#">Favorite</a> ARIA 67
  68. 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. 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. 70. ARIA Mobile support for WAI-ARIA Source: http://caniuse.com/#feat=wai-aria 70
  71. 71. Structure and layout
  72. 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. 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. 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. 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. 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. 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. 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. 79. Testing 79
  80. 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. 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. 82. Top 5 tests 2. Check markup and structure – Quick check: W3C Nu Markup Validator – Appropriate markup structures and semantics 82
  83. 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. 84. Top 5 tests 4. Tab/gesture through the page 84
  85. 85. Top 5 tests 5. Images have appropriate text alternatives – Use the alt text decision tree 85
  86. 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. 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. 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. 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. 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. 91. Summary Let’s recap… 91
  92. 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. 93. Questions?
  94. 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. 95. Appendices 95
  96. 96. Benefits of digital inclusion 96
  97. 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. 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. 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. 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. 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

×