Gian Wild - Mobile Accessibility: Testing native apps and mobile sites for accessibility

Unfortunately, when developing WCAG2, the Working Group did not envision the current world where mobile is almost ubiquitous. For example, on a mobile device there is no continual access to a keyboard (unless someone is using it as an add-on to the device – or using a Blackberry Classic). WCAG2 requires that all content be accessible to the keyboard interface, but it does not require that all content be accessible to a mouse or to a touchscreen user – which is essential on a mobile device. WCAG2.1 does include some mobile accessibility requirements, but doesn’t go far enough. Gian Wild chaired the Mobile Site Sub-Committee to develop a set of Mobile Site Testing Guidelines that are available under Creative Commons. These guidelines are meant to be used in conjunction with WCAG2 (and WCAG2.1) to ensure that sites are accessible to people with disabilities using mobile and tablet devices.

Accessibility is important to all – not everyone using your mobile app, device or wearable will be fully functioning: either because they have a disability or they are simply engaged elsewhere. Gian Wild talks about the things that are essential to avoid when designing mobile apps, devices and wearables to ensure that everyone can use them. She talks about specific mobile accessibility features: pinch zoom, native screen readers, haptic keyboard etc, and system accessibility settings: font size, screen rotation, high contrast etc

Transcript

1. @accessibilityoz www.accessibilityoz.com Mobile Accessibility
2. @accessibilityoz | Mobile Accessibility Fails: The good, the bad and the ugly
3. @accessibilityoz | Autoplay Fails WCAG2 Success Criterion 2.2.2 Pause, Stop, Hide
4. @accessibilityoz | Color contrast Fails WCAG2 Success Criterion 1.4.3 Contrast (Minimum)
5. @accessibilityoz | Testing Fails WCAG2 Success Criterion 3.3.1 Error Identification WCAG2 Success Criterion 3.3.3 Error Suggestion
6. @accessibilityoz | In-app settings Fails WCAG2 Success Criterion 1.4.4 Resize Text
7. @accessibilityoz | In-app settings Ummm… Where is the large text?
8. @accessibilityoz | Fails 3.2.3: Consistent navigation
9. Why did we develop this methodology?
10. @accessibilityoz | Introduction ICT Accessibility Testing Symposium has developed a methodology for evaluating the accessibility of mobile web sites. This document is an amalgamation of accepted mobile accessibility testing standards from around the world, including additional developments from the ICT Accessibility Testing Symposium’s Mobile Sub-Committee.
11. What about WCAG2.1?
12. @accessibilityoz | WCAG2 WCAG2 success criteria are applicable to mobile, however, not all aspects of mobile accessibility are specifically covered by WCAG2. For example, although WCAG2 requires sites to be accessible to the keyboard user, it does not specify that it should also be accessible to the touchscreen user.
13. @accessibilityoz | WCAG2.1 WCAG2.1 builds on this and addresses more criteria related to touch screen (pointer gestures), sensors and small screen devices, however it still does not cover all user needs related to mobile accessibility.
14. @accessibilityoz | Mobile accessibility features • Native screen readers o TalkBack (Android) o Narrator (Windows) o VoiceOver (iOS) • Volume control • Haptic keyboard • Visual, auditory and vibrational notifications • Text-to-speech / speech recognition • Zoom
15. @accessibilityoz | System accessibility settings • Font size • Touch and hold delay • Screen rotation • High contrast • Assistive touch • Mono audio (left / right balance)
16. @accessibilityoz | WCAG2.1 page variations Low vision users (who use the zoom function inherent in the browser) are often restricted to a mobile view of the site on their desktop. As part of WCAG2, zooming to 200% should already be included in regular testing (and therefore is not included in this methodology). It is essential that functionality is not removed due to a variation in the page.
17. @accessibilityoz | WCAG2.1 page variations For example, previously in YouTube (this has now been fixed), the upload and notifications buttons were visible at 100% screen size but not at 200% screen size. This would mean that people browsing at 200% screen size would not be able to upload a video or view their notifications, because it was assumed that the 200% view was a mobile view and people would use the mobile app instead.
18. @accessibilityoz | WCAG2.1 page variations WCAG Conformance Requirement – Full Pages – Page variations
19. @accessibilityoz | @accessibilityoz | WCAG2.1 Accessibility Supported WCAG Conformance Requirement - Accessibility Support - Implementation techniques that supports Assistive technology used on mobile devices such as Talkback, VoiceOver, and switch control. (Also applicable to WCAG 2.0) What does A11y Supported mean for mobile? Testing (especially Native Apps) with the following assistive technologies on mobile must be conducted
20. @accessibilityoz | Please note that this methodology does not include those errors already included in WCAG2 but does include those errors in WCAG2.1
21. @accessibilityoz | Test with real devices I don’t feel safe giving you my credit card details…
22. @accessibilityoz | Testing methods
23. @accessibilityoz | @accessibilityoz | Testing methods – Mobile Sites There are four main testing methods in mobile testing: • Devices: test on mobile and tablet devices • Devices with assistive technology: test on mobile and tablet devices with assistive technologies • Responsive Window: test on responsively sized window on desktop • Desktop: test on desktop
24. @accessibilityoz | @accessibilityoz | Testing methods – Native App There are two main testing methods in mobile testing: • Devices: test on mobile and tablet devices • Devices with assistive technology: test on mobile and tablet devices with assistive technologies
25. @accessibilityoz | Site Types (Mobile Site only)
26. @accessibilityoz | @accessibilityoz | Three types of mobile sites Desktop web sites: that have only one display, whether viewed on desktop or mobile or tablet device m.dot sites: that have a particular display for mobile and tablet sites. The m.dot site must also be tested against the entirety of WCAG2, in addition to the standard www version of the site. Responsive web sites: that change depending on the screen size or other feature as determined by the developer
27. @accessibilityoz | @accessibilityoz | Example of a desktop site
28. @accessibilityoz | @accessibilityoz | Example of a desktop site The site is a desktop site if the content does not change as you drag the browser window narrower. In most cases you will see a horizontal scrollbar at the bottom of the page.
29. @accessibilityoz | @accessibilityoz | Steps to identify an m.dot site 1. Ask the client 2. Change the URL to start with “m.” instead of “www.” 3. Compare the site on desktop to the site on a mobile device.
30. @accessibilityoz | @accessibilityoz | Example desktop site
31. @accessibilityoz | @accessibilityoz | Example m.dot site
32. @accessibilityoz | Desktop m.dot
33. @accessibilityoz | @accessibilityoz | Responsive web sites Please note that it is most likely that a site is responsive. If a site is responsive, it is definitely not a desktop site. However, it is possible (but very unlikely) that there is also a m.dot web site.
34. @accessibilityoz | @accessibilityoz | Identifying a responsive web site The site is responsive if the layout changes as you change the browser window size. To test this, open the web site in a browser, ensure the window is not maximized, and select the right-hand edge and drag it to the center of the screen.
35. @accessibilityoz | @accessibilityoz | Example of a responsive web site – desktop
36. @accessibilityoz | @accessibilityoz | Example of a responsive web site – mobile If elements in the page move around, then the site is responsive. Another way to tell is if the navigation disappears and is replaced with a hamburger menu.
37. @accessibilityoz | Variations of a page (Mobile Site only)
38. @accessibilityoz | @accessibilityoz | Variations of a page It is important that each variation of the page is tested, and that all functionality is available on all variations of the page. The testing methods for responsive web site testing are dependent on whether there are variations of the page.
39. @accessibilityoz | @accessibilityoz | Why provide variations of a page? • Highlighting particular content on mobile, such as phone details; • Hiding particular content on mobile, such as image galleries; and • Hiding functionality that does not work on mobile, such as a drag and drop feature.
40. @accessibilityoz | @accessibilityoz | Triggers for variations of a page Developers can identify one or more of the following four features: • The device (e.g. iPhone, desktop, Android, etc.); • The operating system (e.g. Windows, iOS, OS, etc.); • The browser (e.g. Safari, IE 11, Chrome, etc.); and • The screen size (e.g. 280 by 720, 1920 by 1080, 320 by 480, etc.).
41. @accessibilityoz | @accessibilityoz | Variations of a page Variations in content included on the page
42. @accessibilityoz | @accessibilityoz | Types of variations of a page Variations in the presentation of components displayed
43. @accessibilityoz | @accessibilityoz | Which variations need to be tested? Every variation of a page needs to be tested, if it contains a variation in content or variation in presentation. For more information see WCAG2.1: Conformance.
44. @accessibilityoz | Elements that need testing (Native App only)
45. @accessibilityoz | @accessibilityoz | Define application functionality Through your understanding of the purpose of the native mobile application, define which functionality is critical to its purpose and use and that must be tested for efficacy, operability, and workflow from a user experience perspective.
46. @accessibilityoz | Common elements that need testing • Navigation (menus, header, footer) • Landing page • Emergency alert pages • Login pages • Settings • Account and profile • Contact Us • Real-time updates (eBay, Uber) • Privacy policy, Terms & Conditions • Interactional / transactional (select product, add to cart, payment, live chat, help, Q&A) • Widgets (calendars, date pickers) • Third-party integrations (geo- locational maps, chat, etc.) • And/or High-traffic areas
47. @accessibilityoz | @accessibilityoz | Common elements to test (continued) Ask the question: how would the experience be impacted if the functionality failed, the content could not be reached, and or the experience caused a barrier to the user? Prioritize. All functionality should be accessible within the native application; however, it is important to define and include the critical functionality for each individual app to be prioritized in your testing.
48. Mobile Site & Native App Testing Methodology
49. @accessibilityoz | @accessibilityoz | Mobile Site Testing Methodology Overview Step 1: Identify devices Step 2: Identify site type and variations Step 3: Test critical issues Step 4: Test mobile-specific issues Step 5: Test mobile assistive technology and feature support
50. @accessibilityoz | @accessibilityoz | Native App Testing Methodology Overview Step 1: Identify devices Step 2: Define application functionality Step 3: Test critical issues Step 4: Test mobile-specific issues Step 5: Test mobile assistive technology and feature support
51. @accessibilityoz | 1. Identify devices
52. @accessibilityoz | @accessibilityoz | Identify devices Recommended devices and browser combinations: • iPhone, (Safari) • iPad, (Safari) • Android phone, (Chrome)
53. @accessibilityoz | @accessibilityoz | Identify devices Other devices to consider • Android tablet (for example, Samsung Tab A or Chromebook), Chrome • Alternative devices such as a Kindle device
54. @accessibilityoz | @accessibilityoz | Identify devices Test on the latest version of iOS. Test on latest two versions of Android. Where a site is directly aimed at people with a particular kind of disability, consider including assistive devices and/or other assistive technologies used by potential users.
55. @accessibilityoz | @accessibilityoz | You need to meet WCAG2 and this mobile testing methodology
56. @accessibilityoz | 2. Identify site type & variations of the page
57. @accessibilityoz | @accessibilityoz | Identify site type Is the site: • Desktop • Responsive • M.dot
58. @accessibilityoz | @accessibilityoz | Identify site type If the site is responsive: • Identify each variation of the page
59. @accessibilityoz | 2. Define application functionality
60. @accessibilityoz | @accessibilityoz | Common elements to test • Navigation • Landing screen(s) • Emergency sections • Login flows • Settings • Account and profile • Contact Us • Real-time updates • Privacy policy, Terms and Conditions • Interactional functionality • Help section • Widgets (calendars, etc) • Geo-locational maps • High-traffic areas
61. @accessibilityoz | 3. Test critical issues
62. @accessibilityoz | @accessibilityoz | New features means new traps Trap: Where a user is trapped within a component and cannot escape without closing the browser or app. There are many more traps in mobile sites and native apps than on desktop.
63. @accessibilityoz | @accessibilityoz | Exit trap Ensure there is always an accessible actionable item (eg. a close button that meets color contrast requirements and has an accessible name) that closes any feature that overlays the current page (such as a full-page ad). Applies to: All users Methodology: Mobile Site and Native App
64. @accessibilityoz | Exit trap No way to close the feature (usually an ad)
65. @accessibilityoz | Exit trap Close button does not meet color contrast requirements
66. @accessibilityoz | @accessibilityoz | Swipe / Scroll trap Ensure you do not override standard mobile touch functions (swiping, scrolling, etc.) on the majority of the page. Applies to: Touch users Methodology: Mobile Site and Native App
67. @accessibilityoz | Swipe / Scroll trap Cannot move the screen unless you activate the up arrow
68. @accessibilityoz | Swipe / Scroll trap The zoom of doom
69. @accessibilityoz | @accessibilityoz | Text-to-speech trap If the app has an ability to provide content via text-to- speech, the screen reader user must be able to pause or stop the app speaking in a simple manner, e.g. by performing a swipe on a screen. Applies to: Screen reader users Methodology: Native App
70. @accessibilityoz | Text-to-speech trap Once activated, screen reader users cannot stop the TTS
71. @accessibilityoz | @accessibilityoz | Headset trap Headset users must always be able to pause media (audio or video) content by using the Pause/Play control on the headset. Applies to: Screen reader users, Headset users Methodology: Native App
72. @accessibilityoz | Headset trap Cannot pause the audio using headset hardware (pause on the headset pauses the screen reader)
73. @accessibilityoz | @accessibilityoz | Layer trap The user should not be trapped on a non-visible layer. Applies to: All users (but mostly encountered by screen reader users) Methodology: Mobile Site and Native App
74. @accessibilityoz | Layer trap Screen reader user cannot access the menu. Focus stays on the parent layer.
75. @accessibilityoz | Test mobile-specific issues
76. @accessibilityoz | @accessibilityoz | Alternatives
77. @accessibilityoz | @accessibilityoz | Alternatives Alternatives are provided for non-web mobile functionality that is mandatory (for example, recording a specific gesture by the camera, before functionality appears).
78. @accessibilityoz | Alternatives Alternative is not sufficient.
79. @accessibilityoz | @accessibilityoz | Alternatives Alternatives are provided for geolocation functionality that is mandatory (for example, requiring a specific geolocation before functionality appears), unless the geolocation is essential for legal reasons, or doing so would invalidate the activity. This applies to geolocation via GPS, user statement, IP address or other methods.
80. @accessibilityoz | Alternatives Fail – Blocking location
81. @accessibilityoz | Alternatives Pass – Choosing a different location
82. @accessibilityoz | Alternatives Changes of state of non-standard controls (e.g. hamburger menu, star ratings) are clearly indicated
83. @accessibilityoz | @accessibilityoz | Display
84. @accessibilityoz | @accessibilityoz | Display Size of touch targets is at least 44 by 44 CSS pixels (approximately 7 to 10 millimeters). For more information see WCAG2.1 SC 2.5.5: Target Size. Please note that this differs from WCAG2.1 as SC 2.5.5 is a Level AAA requirement, but in this methodology, it is a mandatory requirement.
85. @accessibilityoz | 2.5.5 example Fail – Touch target size
86. @accessibilityoz | 2.5.5 example Pass – Touch target size
87. @accessibilityoz | @accessibilityoz | Display Actionable items have sufficient inactive space between them (Inactive space of at least 10 pixels should be provided around active elements).
88. @accessibilityoz | Spacing Be careful what you select…
89. @accessibilityoz | @accessibilityoz | Actionable items
90. @accessibilityoz | @accessibilityoz | Actionable items Native UI controls, objects, alerts and elements have been used
91. @accessibilityoz | Non-standard UI Fail – Non-standard UI element
92. @accessibilityoz | @accessibilityoz | Actionable items When direct input via the keyboard is not required provide options for the user to achieve the same result (i.e. use dropdown, radio buttons & checkboxes, etc.).
93. @accessibilityoz | Actionable items Fail – Keyboard dependent
94. @accessibilityoz | Actionable items Pass – Non-keyboard options
95. @accessibilityoz | @accessibilityoz | Actionable items Functionality that can be operated by device motion or user motion can also be operated by user interface components, and responding to the motion can be disabled to prevent accidental actuation, except for certain situations. For more information see WCAG2.1 SC 2.5.4: Motion Actuation.
96. @accessibilityoz | 2.5.4 example Fail – Undo Typing on iOS (can be turned off in Settings, but no alternative)
97. @accessibilityoz | 2.5.4 example Fail – Report a problem on Facebook (can’t be turned off)
98. @accessibilityoz | Actionable items Fail – Infinite scrolling has been used
99. @accessibilityoz | @accessibilityoz | Navigational aids
100. @accessibilityoz | @accessibilityoz | Navigational aids Visual indicators, (such as arrows, next and previous buttons) have been used to indicate swipe or scroll areas or additional functionality (for more information see WCAG2.1 SC 2.5.1: Pointer Gestures).
101. @accessibilityoz | Navigational aids Fail – No indicator of horizonal swipe
102. @accessibilityoz | @accessibilityoz | Navigational aids Navigational aids such as back buttons, breadcrumbs, next and previous buttons are provided.
103. @accessibilityoz | Navigational aids Fail – No clear navigational aids
104. @accessibilityoz | @accessibilityoz | Audio and video
105. @accessibilityoz | Audio and video Pass – All audio and video have an accessible transcript
106. @accessibilityoz | @accessibilityoz | Forms
107. @accessibilityoz | @accessibilityoz | Forms Field labels are positioned adjacent to their input field and appear closest to their respective input field in relation to other field labels and other input fields.
108. @accessibilityoz | Field labels Fail – Not positioned correctly
109. @accessibilityoz | @accessibilityoz | Mobile / desktop interaction (mobile site only)
110. @accessibilityoz | @accessibilityoz | Testing (mobile site only) Item labelling between different types of a site (desktop, m.dot and/or responsive), and different variations of a responsive site, is consistent.
111. @accessibilityoz |
112. @accessibilityoz | Test mobile assistive technology and feature support
113. @accessibilityoz | @accessibilityoz | Test mobile assistive technology and features All actionable items can be accessed and activated by the following assistive technologies (or when the following feature is enabled) All important content can be accessed by the following assistive technologies (or when the following feature is enabled)
114. @accessibilityoz | Mobile assistive technologies and features • VoiceOver (iOS) • Keyboard (iOS) • Keyboard and switch (iOS) • Zoom (iOS) • Invert colors (iOS) • Grayscale (iOS) • Reader view (iOS) • TalkBack (Android) • Keyboard (Android • Keyboard & switch (Android) • Magnification (Android) • Invert colors (Android) • Grayscale (Android) • Increase text size (Android) • Simplified view (Android)
115. @accessibilityoz | @accessibilityoz | Q&A
116. @accessibilityoz AccessibilityOz inquiries @accessibilityoz.com