Successfully reported this slideshow.

Introduction to mobile accessibility

23

Share

Loading in …3
×
1 of 101
1 of 101

Introduction to mobile accessibility

23

Share

Download to read offline

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/

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/

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

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

Editor's Notes

  • Good morning, everyone.

    Favour: Ask people to take photos and tweet feedback and photos re the session using #digpen
  • Short version: “What’s accessibility all about for me?”

    Many accessibility presentations will kick off with an explanation of what accessibility is all about, why you should be thinking about it.
    Corporate Social Responsibility.
    The legal aspects (ADA, 508).
    The benefits.
    You may have heard that the Internet’s biggest blind user is Google.
    Accessibility is good for SEO.
    Accessibility can save you time and helps make your applications more robust. No, really! Adding accessibility into applications makes automated testing easy.

    Developers:
    Often see accessibility as having to jump through hoops for little gain.
    It’s such a hassle.
    Why should I do it?
    For me:
    It’s a challenge.
    It’s on a par with testing, security and documentation. You don’t have to do it, but you should.
    I think it’s cool!
    Most importantly, I’ve seen what accessibility can do.
    I’m going to kick off with why I do accessibility…
  • Jon’s first experience of accessibility – a talking clock used by his blind mother.
  • Jon’s earliest experience of “geek”

    Smart watches / phones:
    Jon first saw these in a book in the 80s and thought, “Woah, that’s pretty cool! I can be Inspector Gadget!”

    Technology is cool! But also enabling!
    LG watch phone: 1.3 inch full touch screen, 3G+ connectivity, video call capabilities, Voice recognition software, Bluetooth v2.1 with A2DP, MP3 player.
  • Back to Jon’s experience:
    Jon has a passion for music. He plays guitar, sings, writes songs…
    At university, he got to work with disabled musicians to develop accessible music composition and performance software.

    T-shirt Demo – Accessible? – Forgive the contrived example!
    You can read it in some light conditions
    The point is that we need to think outside the box a little.
    We need to find ways to empathize.
    And that’s what this experience with disabled musicians did.

    Empathy:
    Accessibility is not about code or compliance; it’s about people.
    Accessibility is about understanding people and the barriers that they face.
    We have all experienced disabling circumstances. Mobile technology itself is disabling:
    in the car (blind)
    at concerts (hard of hearing)
    small text on non-optimised sites on our smart phones (low vision)
    fat fingers (hand tremors)
    broken bones (crutches)
  • Out of interest, do we have people with a disability here today?
  • Android has a larger market share than iOS.
    However, where accessibility is concerned, iOS provides a more stable and uniform platform for users.
    Some problems with the Android platform, as we’ll see later, is users getting stuck on older versions and vendor customization of the platform.
    iOS support for accessibility is not complete, but it has come a long way and is the most mature.
    Android accessibility has particularly improved over the last two releases; Jelly Bean is particularly good (more later).
  • Aside: Mobile Web and native apps each have their advantages and disadvantages:
    Native: Faster, lower bandwidth, (currently) better access to hardware features, UI familiarity, infrastructure support (e.g. app stores), can work offline
    Mobile Web:
    Flexibility, maintainability / updatability (release regularity), cheaper and faster to develop and maintain, require Internet connection
    HTML5/ARIA: Location API, storage (offline mode, caching), accessibility (ARIA for OS-like controls)
  • Mobile is important for people with disabilities
    Mobile devices, such as smartphones and tablets, are the cheapest way for people to get online
    People with accessibility needs are also finding mobile devices the best way to get online because of the innovative assistive technologies that are available for free with smartphone operating systems, such as iOS and Android.
  • Disabled users don’t always fall neatly into the 4 main disability types
    Older users, for example, could fall into any of the above groupings (limited dexterity, hearing and vision)
  • Often, we have images of people with extreme disabilities in mind (totally blind, amputees, wheelchair users, totally deaf, etc.)
    Many of us have mild disabilities (e.g. people who wear glasses) or hidden disabilities
    We are all subject to aging
  • Temporary:
    Someone with a broken arm cannot use a mouse.

    Cultural:
    Not everyone understands English.
    Colours have different meanings or associations all over the world. Red is often associated with stop, errors, or passion in Western cultures. In China, red can relate to celebration or good luck.

    Technology:
    User requirements can be diverse.
    Technology issues include user preference, for a particular hardware feature, for example. You cannot account for user preference, you can only build for flexibility.
    “Device disabled”:
    Touch screen devices in bright light or noisy environments.
    Mobile users can be limited by data allowances.
  • Vision impairment
    Uses a screen reader or screen magnifier
    Physical impairment
    Only use a keyboard, may use voice recognition software
    Equally, people may use a diverse range of different access technology and settings
  • Deaf or hard of hearing
    Requires captions for audio content
  • BACKUP PLAN!
    A short 1:08 minute video of Victor Tsaran navigating headings and links using the iPhone.
    http://www.youtube.com/watch?v=t60voPIY5xY
  • Of particular interest to Jon… mobile accessibility: 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 is like having low vision
    Small input devices
    Tiny keys
    Eyes-free usage, e.g. in car, is like being blind

    Empathy examples:
    Broken limbs
    A temporary physical disability
    Try making a cup of tea while using crutches
    Noisy surroundings (concerts, trains) = hard of hearing
    Like being hard of hearing
    Imagine if SMS had been like voicemail
    Note: Google Voice provides voicemail transcription
  • Of particular interest to Jon… mobile accessibility: 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 is like having low vision
    Small input devices
    Tiny keys
    Eyes-free usage, e.g. in car, is like being blind

    Empathy examples:
    Broken limbs
    A temporary physical disability
    Try making a cup of tea while using crutches
    Noisy surroundings (concerts, trains) = hard of hearing
    Like being hard of hearing
    Imagine if SMS had been like voicemail
    Note: Google Voice provides voicemail transcription
  • Of particular interest to Jon… mobile accessibility: 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 is like having low vision
    Small input devices
    Tiny keys
    Eyes-free usage, e.g. in car, is like being blind

    Empathy examples:
    Broken limbs
    A temporary physical disability
    Try making a cup of tea while using crutches
    Noisy surroundings (concerts, trains) = hard of hearing
    Like being hard of hearing
    Imagine if SMS had been like voicemail
    Note: Google Voice provides voicemail transcription
  • Typical desktop screen: 1280 x 1024
  • Main point: user preference sometimes plays a part that you as a developer or tester cannot do anything about, but should be aware of.

    An anecdote about being reliant on touch and one-handed usage:
    One blind Nokia / Talks user tested iOS and preferred using Nokia, which is arguably a poorer experience
    He likes to browse bus times one-handed in his pocket as he is walking and iOS needs two hands
    He can’t use touch as easily in the rain as the screen doesn’t respond well
    Reference: I like my Nokia with all its buttons but should I stay or should I go iPhone.
    http://inclusivesociety.wordpress.com/2011/12/16/i-like-my-nokia-smartphone-with-all-its-buttons-but-should-i-stay-or-should-i-go-iphone/
  • Possibilities!

    Example innovations that can also be considered accessibility aids:
    Accelerometer:
    Tilt Scrolling: an innovation in Instapaper app on iOS – which is an app that presents text-only versions of content from the Web (less distraction)
    Environmental awareness (light/dark conditions):
    Auto-dimming displays, e.g. iPhone screen
    Automatic Dark Mode: another innovation in the Instapaper app

    More innovations on the next slide.
  • Some innovative mobile features happen to be enabling for people with disabilities. For example, FaceTime can be used by deaf people to communicate.
    Some features are traditionally assistive technology. For example, voice recognition built into iOS as Siri.
    Some accessibility features happen to be useful to everybody. For example, custom vibrations are great when your phone’s in silent mode.

    FaceTime used by deaf people:
    http://youtu.be/jSADqRwFAV4
  • V-B-Reader:
    http://vbraille.cs.washington.edu/Applications

    Vibrating touch screens:
    http://news.cnet.com/8301-17938_105-10213356-1.html

    Touch-screen Braille writer:
    http://news.cnet.com/8301-17938_105-20118728-1/tablet-app-brings-new-touch-to-braille/
  • We’ll look at “explore by touch” first; gesture navigation is explained in the next slide. Also, more general notes about these interaction methods are in the notes on the next slide.
    Explore by touch:
    is spatial
    requires users to become aware of the layout of a page/screen
    can be tedious and things can be missed by users
  • Gesture navigation:
    is sequential, typically following the reading order of a page/screen
    allows users to interact with one element of a page/screen at a time, similar to how you interact with the keyboard on desktop applications
    uses a virtual focus cursor, which is roughly equivalent to keyboard focus and tabbing around an interface
    often makes more sense to users (provided reading order makes sense) and things are less likely to be missed
    Both of these methods are now used in iOS and Android
    Both methods available in iOS since iPhone OS 3 was released with the iPhone 3GS in June 2009
    Android TalkBack Explore by Touch mode available since Android 4.0 (Ice Cream Sandwich) in October 2011
    Android TalkBack Gesture mode available since Android 4.1 (Jelly Bean) in June 2012
    Gesture navigation on Android does not behave in exactly the same way as VoiceOver on iOS, but it is similar
    These interaction methods are becoming a de facto standard on mobile devices
    We will go into more depth on using these methods later in this training (including video links)
  • The Rotor:
    Can be used to check headings, landmarks, form controls, etc.
  • You can test pinch zoom in the iOS Simulator (Mac only, covered later).
    Large Text only worked in some of Apple’s own native apps.
    As of iOS 7, Dynamic Type can be implemented by any app.
  • Assistive Touch makes multi-finger gestures possible using a single finger
    Captioning is available on Android, e.g. see YouTube Mobile.

    Captioning in iOS 6:
    Captioning settings in different place: Settings > Video > Closed Captioning
    Also, BBC iPlayer has subtitles.

    Assistive Touch:
    http://youtu.be/7WslOyWvL30

    Custom vibrations:
    • iOS 6 introduces custom vibrations for all notifications

    Hearing aid support:
    • iOS 5 includes Hearing Aid Mode support for iPhone 4 onwards
    • iOS 6 supports Made for iPhone hearing aids
    • iPhone 5 has hardware built in for compatibility with hearing aids

    TTY:
    • Teletype
    • Requires adapter

    Visual Voicemail:
    • Hard of hearing
    • Scrubber for replaying
  • Main points:
    Android is less evolved than iOS, but the last two versions has brought it closer to the features of iOS
    TalkBack on Ice Cream Sandwich is explore by touch only
    TalkBack on Jelly Bean behaves a lot like iOS with both interaction methods: explore by touch and gesture navigation

    Reiterating earlier notes:
    Android TalkBack Explore by Touch mode available since Android 4.0 (Ice Cream Sandwich) in October 2011
    Android TalkBack Gesture mode available since Android 4.1 (Jelly Bean) in June 2012
    Gesture navigation on Android does not behave in exactly the same way as VoiceOver on iOS, but it is similar

    Further information:
    TalkBack is bundled with the OS in version 4.0 (Ice Cream Sandwich) upwards.
    For Android version 2.2 upwards, TalkBack has to be downloaded from the Android app store.
    In older versions, everything on Android is accessible using TalkBack except browsing which can only be done using a keyboard. The Eyes-Free Keyboard is a virtual keyboard which works together with TalkBack. Very old versions of Android used something called Eyes-Free Shell to provide accessibility to apps.
    On the right is a picture of the home screen on an Android phone. The bottom third of it is covered by a transparent square which you can move your finger around to navigate. By holding the volume key you can change the rectangle to a virtual keyboard.

    TalkBack on Jelly Bean – 9 mins 47 secs.
    http://www.youtube.com/watch?v=w3Sz3KNkQ4U

    Android Explore by Touch:
    http://support.google.com/android/bin/answer.py?hl=en&answer=2492750

    Android Gesture mode (sequential navigation):
    http://support.google.com/nexus/bin/answer.py?hl=en&answer=2692469
  • Warning: DEMO and EXECISE on this slide!

    TalkBack is bundled with the OS in version 4 (Ice Cream Sandwich) upwards. Versions 2.2 + it has to be downloaded from the Android app store.

    Everything on Android is accessible using Talkback except browsing which can only be done using a keyboard. The Eyes-Free Keyboard is a virtual keyboard which works together with Talkback.

    On the right is a picture of the home screen on an Android phone. The bottom third of it is covered by a transparent square which you can move your finger around to navigate. By holding the volume key you can change the rectangle to a virtual keyboard.

    DEMO!

    EXERCISE: ask the group to browse a web page using whatever device they have at hand. Note I have not put this on a separate slide in case you don’t feel it’s appropriate on the day.
  • The Ideal Web Reader offers better support for browsing than the native, Chrome or Firefox browsers. Offers browsing by heading, table, form, sentence, word, and character. Also works with an external keyboard.
  • Main points:
    Often WCAG is referenced as a mobile standard, and it’s a good place to start.
    WCAG 2.0 was written to be technology agnostic, so principles apply to mobile, but do not specifically address mobile platforms or features, such as touch screens, gestures, technology support (WAI-ARIA/HTML5), etc.
    Desktop has 5 major browsers, but mobile has many more, further complicated by multiple operating systems as opposed to the major 3 on desktop.
    What is the lowest denominator phone (browser, OS, version) we should support? More shortly…

    Yahoo!’s Browser Test Baseline
    http://yuilibrary.com/yui/docs/tutorials/gbs/
  • BBC Mobile Accessibility Guidelines:
    http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile_access.shtml

    Resources for Mobile Accessibility Guidelines:
    http://www.iheni.com/mobile-accessibility-guidelines/
  • Main points:
    WAI’s resources are a bit out of date, but still useful.
    Funka Nu have developed some useful guidelines.
    New guidelines are on their way, and should be ready in the first half of 2013.
    Native app guidelines help us understand the context of the platform even when building for the Mobile Web (device-specific colour, fonts and styling support within the OS).
    Further platform-specific guidelines are available via the “Resources for Mobile Accessibility Guidelines” link or the resources at the end of this training.

    Mobile Web Best Practices (MWBP) 1.0:
    http://www.w3.org/TR/mobile-bp/

    Web Content Accessibility Guidelines (WCAG) 2.0:
    http://www.w3.org/TR/WCAG/

    Relationship between MWBP and WCAG:
    http://www.w3.org/TR/mwbp-wcag/

    Mobile Accessibility Guidelines by Funka Nu:
    http://www.funkanu.se/en/About-Funka/News/News-archive-en/Mobile-accessibility-guidelines/

    Getting to grips with a mobile accessibility strategy:
    http://www.iheni.com/getting-to-grips-with-a-mobile-accessibility-strategy/

    Also:
    Mobile Website Guidelines by the University of Austin (very basic)
    http://www.utexas.edu/brand-guidelines/web-guidelines/mobile
  • We have native app guidelines in order to understand the context of the platform even when building mobile website and web apps.

    Main point: Even if working with mobile web these are useful to reference for device specific guidance on some areas such as colour, fonts and styling support within the OS.
  • Laws:
    Section 508 – seems to include mobile web and apps (“information and communication technology” must be WCAG 2.0 compliant)
    21st Century Communications Act – definitely includes mobile web and apps and says by 2013 phones must ship with accessible browsers, so no excuse for inaccessible content.
    21st Century Act – expect more accessible browsers out there beside mobile safari and native Android and Nokia browsers. Already we have accessible Chrome on iOS and Android, and Firefox nightly on Android (ref: http://www.iheni.com/accessible-firefox-chrome-android-ios/). This means no excuse for inaccessible content, could this mean easier to bring lawsuits against companies like Comcast with inaccessible mobile web sites?
  • Information about an application’s user interface is sent to assistive technologies as object properties and events

    Accessible Object Properties provide information which allows multi-modal access to content.
    Name, role, and state are important properties to be aware of.
    Accessible Events inform AT about changes to the otherwise static DOM-based representation. For example, virtual buffer in JAWS.
  • A lot we could go into here
  • Progressive enhancement
    Build for lowest common denominator handset - not all handsets are equal, and some are more equal than others in terms of support for colour palettes and fonts in the OS, plus the ability to to handle ARIA and HTML5 by the AT and mobile browser. Even some basic HTML4 (e.g. title text) is not supported in the same way it is on desktop

    NB: today we are talking about the mobile web with an emphasis on iOS. All techniques discussed are supported by iOS but be aware some may not (these are flagged)

    Use web standards as intended – build core content using HTML, enhance with colour, styling, WAI-ARIA (for OS-like controls), HTML5

    Native – Build to capabilities of early versions for example new accessibility techniques released with iOS6 should not be relied on but used to progressively enhance

    Use web standards
    Use standard not custom controls (where possible) - code a button as a’ button’ don’t just style a link as a button. SRs announce the trait of an element before reading the label/alternative; users expect a link to open a resource and a button to carry out an action. Can be confusing when these are muddled.
    Accessibility already baked in to web standards as well as interoperability for browsers, platforms and assistive tech

    Support platform accessibility settings/AT
    For example pinch zoom on touch should not be suppressed. Layout bug in iOS for landscape mode now fixed in iOS 6 reference: http://www.iheni.com/mobile-accessibility-tip-dont-suppress-pinch-zoom/. iOS you can select text and hear it (Settings > General > Accessibility > Speak Selection)
    Support text selection – suppressing ability for copy paste text also suppresses ability to highlight text on iOS and have it read out
  • Using aria-label only works in iOS if there is not a connected label.
    Always recommend HTML over WAI ARIA as lower end phones wont handle WAI ARIA
  • Important: How this example is announced will vary depending on screen reader.
  • Inputting text, numbers, emails, URLs and search terms are hard using touch in general but especially for low vision, mobility or blind users. Often people revert to Siri and voice input.

    Predictive search is useful for dyslexics.

    Input types bring up the correctly configured keyboard i.e. numbers for numbers, keypad for phone number, keyboard with ‘@’ for emails. Helps mitigate against making mistakes.
  • The image shows how incorrect use of colour to indicate required fields has been further distorted by iOS rendering the yellow (seen on desktop) as red on mobile.
    Take away – always test content across mobile.
  • From Mobile BP at W3C:
    The error message should provide one or more of the following navigational constructs:
    A "back" link to return to the previous page (particularly for devices that do not have an easy to find back button);
    A "retry" link to attempt the relevant part of the transaction again (note that this may not be equivalent to a page "refresh");
    A "home" link to allow the user to return to the main part of the application.
    The error message can provide an error code to be used for diagnosis of the issue. However, the use of an error code is not a substitute for a human-readable message. While some users may understand "404" to mean "page cannot be found", this must not be assumed to be true for all users.

  • aria-live=“assertive” can be used to present users with a warning:
    Updates are announced and interrupt what the user is doing
    • Only use for important updates that require immediate attention.
    • Warnings & error notifications.
    • Session timeout notifications
  • Use focus management with caution in forms. If form elements are preceded with instructions or text you wont want to set focus to the first form element as a user will miss the text. More useful on screens where the form is the key part i.e. a log in screen.

    If building an HTML app with a ‘Back’/’Done’ button as the first thing in the content order setting focus to an item at the start of the main content is better than hearing ‘Done’ or ‘Back’ when you first open a page.
  • This is potentially useful for addresses in forms
    An example of progressive enhancement
    Note: CSS3 Speech module is not stable (draft)
  • The element does have a click event handler attached to it (which can’t be seen from the HTML).
    The element can receive keyboard focus due to the tabindex.

    Problems:
    This element does not have an accessible role; it is not a button!
    There is no accessible label for this “button”.
    Even though the element can receive focus, assistive technologies are not provided with accessible information to announce to users.
  • Retrofitting accessibility where no semantics exist

    Fixes:
    Accessible role added using role attribute.
    Accessible label added using aria-label attribute.
  • Problems:
    This element’s behavior is that of a button, not a link. A link should take the user to a new context.
  • Consider what you might write on a help page. For example, “Click the Favorite button to favorite a post” would not be correct for assistive technology users. By setting a role of button, screen reader users are able to locate and identify interactive elements more easily.

    Problems:
    This element’s behavior is that of a button, not a link. A link should take the user to a new context.
  • Fixes:
    More appropriate role added using role attribute.
  • Responsive examples:
    http://www.medicare.gov/
    http://8faces.com/
  • Voice output users use semantics to navigate between parts of a page.
    On iOS you can activate the Web Rotor with a dial action then select how you want to navigate. Swipe up and down to jump between headings then when you reach the heading you want you swipe to the right to read the next item in the content order.
  • Also: Form fields are grouped logically.
  • Browse the site with a screen reader
    Ultimately, this tests the user experience, but your experience does not necessarily match that of other users or other platforms.
    Can pick up many issues in one go, e.g. encompasses keyboard/gesture accessibility, appropriateness of link text, image alt text, reading order, keyboard traps, invisible content, etc.
  • Appropriate markup structures and semantic, includes headings, navigation lists, table structures, etc.
  • Interact with all forms, since these are a fundamental interaction point and behave differently to normal navigation modes.
  • Tab/gesture through the page
    Checks tab/focus order, should be picked up with a quick run-through with a screen reader, but can help with checking certain navigation modes.
  • Images
    Speaks for itself, but also keep an eye out for images of text.
  • Missing
    Pages and frames are titled
    Link text is appropriate to target (sort of covered by tabbing through)
    Headings exist and are appropriate
    Navigation is consistent
    Alternative means of locating pages is provided
    Repetitive navigation can be skipped
    Non-HTML content is accessible (Flash, PDF, Silverlight)
    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
    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
  • Missing
    Pages and frames are titled
    Link text is appropriate to target (sort of covered by tabbing through)
    Headings exist and are appropriate
    Navigation is consistent
    Alternative means of locating pages is provided
    Repetitive navigation can be skipped
    Non-HTML content is accessible (Flash, PDF, Silverlight)
    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
    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
  • Missing
    Pages and frames are titled
    Link text is appropriate to target (sort of covered by tabbing through)
    Headings exist and are appropriate
    Navigation is consistent
    Alternative means of locating pages is provided
    Repetitive navigation can be skipped
    Non-HTML content is accessible (Flash, PDF, Silverlight)
    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
    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
  • Demo (if time)
  • Slides will be uploaded shortly.
  • SEO
    You may have heard that the Internet’s biggest blind user is Google
    Accessibility encourages valid code: easily digestible
    Increased usability and business
    There are close ties between accessibility and usability
    Expanding and diversifying the customer base
  • Time
    Accessibility can save your developers time: easier to understand and navigate code
    Easier to automate testing, e.g using tools such as Selenium, UIAccessibility in iOS, etc.
    Stability
    Accessibility encourages valid code: make your applications more robust
    Reduced server load
    Valid code is leaner, is easier to serve, and uses less bandwidth
  • Cost savings
    Proven Return On Investment: Legal & General case study: http://www.w3.org/WAI/bcase/legal-and-general-case-study
    Time and reduced server load
    Reputation
    Truth: “an accessible website will make you look good”
    A better, more usable website will earn you a good reputation
  • ×