Why did we Mobile Testing Process pz.tt/ict19 develop this - PDF document

29/04/2020 Why did we Mobile Testing Process pz.tt/ict19 develop this methodology? www.accessibilityoz.com gian@accessibilityoz.com @accessibilityoz accessibilityoz.com 1 2 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 What about from the ICT Accessibility Testing Symposium’s Mobile WCAG2.1? Sub ‐ Committee. gian@accessibilityoz.com 3 @accessibilityoz accessibilityoz.com 3 4 WCAG2 WCAG2.1 WCAG2 success criteria are applicable to mobile, however, WCAG2.1 builds on this and addresses more criteria related not all aspects of mobile accessibility are specifically covered to touch screen (pointer gestures), sensors and small screen by WCAG2. For example, although WCAG2 requires sites to devices, however it still does not cover all user needs related be accessible to the keyboard user, it does not specify that it to mobile accessibility. should also be accessible to the touchscreen user. 5 6 @accessibilityoz @accessibilityoz 5 6 1

29/04/2020 WCAG 2.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 Test all variations testing (and therefore is not included in this methodology). It is essential that functionality is not of mobile sites removed due to a variation in the page. gian@accessibilityoz.com 8 @accessibilityoz accessibilityoz.com 7 8 WCAG 2.1 Page variations WCAG 2.1 Page variations For example, previously in YouTube (this has now been WCAG Conformance Requirement ‐ Full Pages ‐ Page variations 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. 9 10 @accessibilityoz @accessibilityoz 9 10 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 Choosing what to experience perspective. test in native apps gian@accessibilityoz.com 12 @accessibilityoz accessibilityoz.com 11 12 2

29/04/2020 Common elements to test Common elements to test (continued)   Navigation (menus, header, Privacy policy, Terms & Conditions Ask the question: how would the experience be impacted if footer)  Interactional / transactional (select the functionality failed, the content could not be reached,  Landing page product, add to cart, payment, live and or the experience caused a barrier to the user? chat, help, Q&A)  Emergency alert pages Prioritize. All functionality should be accessible within the  Widgets (calendars, date pickers)  Login pages native application; however, it is important to define and  Third ‐ party integrations (geo ‐  Settings include the critical functionality for each individual app to be locational maps, chat, etc.)  Account and profile prioritized in your testing.  And/or High ‐ traffic areas  Contact Us  Real ‐ time updates (eBay, Uber) 13 14 @accessibilityoz @accessibilityoz 13 14 Pl ea s e not e t ha t t hi s Test with real devices met hodol ogy does not i nc l ude t hos e er r or s a l r ea dy i nc l uded i n WC WCAG2, bu but doe does i nc nc l ud ude e t ho hos e er er r or or s s i n n WC WCAG2. 1 I don’t feel safe giving you my credit card details… gian@accessibilityoz.com accessibilityoz.com 15 16 Mobile Testing Methodology Overview Step 1: Identify what needs to be tested • Identify devices Mobile Testing Methodology • Identify the site type and variations of the page (Mobile site only) gian@accessibilityoz.com 18 @accessibilityoz accessibilityoz.com 17 18 3

29/04/2020 Mobile Testing Methodology Overview Step 2: Conduct specific mobile tests • Critical issues • Mobile ‐ specific issues Identify what needs • Mobile assistive technology and feature support to be tested • Mobile and desktop relationship issues 19 20 @accessibilityoz @accessibilityoz 19 20 Identify what needs to be tested 1. Identify devices You need t o meet 2. Identify the site type (mobile site only) WC WCAG2and t hi s 3. If a responsive site, determine if there are mobi l e t es t i ng variations of the page (mobile site only) met hodol ogy 21 @accessibilityoz 21 22 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 Test critical issues apps than on desktop. 23 24 @accessibilityoz @accessibilityoz 23 24 4

29/04/2020 Hover trap Hover trap Content must be able to be dismissed if activated on touch (often these are actionable items that are activated on mouse hover on a desktop) Applies to: Touch users Cannot dismiss zoomed in section 25 @accessibilityoz 25 26 On ‐ screen keyboard trap On ‐ screen keyboard trap Onscreen keyboard must be able to be dismissed. Applies to: Onscreen keyboard users Cannot dismiss keyboard 27 @accessibilityoz 27 28 Screen reader swipe trap Screen reader swipe trap Screen reader users must always be able to activate an item on the current page or move back to the previous page. Applies to: Screen reader users Cannot change or close page, access keyboard or go back 29 @accessibilityoz 29 30 5

29/04/2020 Touch trap Touch trap User must always be able to scroll / swipe to move up and down the page. Applies to: Touch users Cannot move the screen unless you activate the up arrow 31 @accessibilityoz 31 32 Zoom trap Zoom trap Do not replace the entirety of the page with a feature that over ‐ rides standard mobile functions such as swiping and scrolling. Applies to: Touch users The zoom of doom @AccessibilityOz 33 33 34 Text ‐ to ‐ speech trap 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. Once activated, screen Applies to: Screen reader users reader users cannot stop the TTS @AccessibilityOz 35 35 36 6

29/04/2020 Swipe trap Swipe trap Any swipe gesture that is superceded by the screen reader must have an alternate gesture. You must be able to perform the same action, by using a link. Facebook– Friends list Applies to: Screen reader users or other assistive Cannot go back to news technology users which capture the swipe feed, access keyboard or back button @AccessibilityOz 37 37 38 Headset trap Swipe trap Headset users must always be able to pause media (audio or video) content by using the Pause/Play control on the headset. Screen reader user cannot Applies to: Screen reader users, Headset users swipe, as swiping is captured by screen reader only 40 @accessibilityoz 39 40 Exit trap Headset 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 Cannot pause the audio any feature that overlays the current page (such as a using headset hardware full ‐ page ad). (pause on the headset Applies to: All users pauses the screen reader) 42 @accessibilityoz 41 42 7

29/04/2020 Exit trap Exit trap YouTube ‐ homepage Screen reader user cannot No way to close the escape from search box feature (usually an ad) 43 44 Exit trap Exit trap “Ad closed by Google” Close button does not overlaps the “Simplified meet color contrast view” option on Android requirements 45 46 Layer trap Layer Trap The user should not be trapped on a non ‐ visible layer. Applies to: All users (but mostly encountered by Screen reader screen reader users) user cannot access the menu. Focus stays on the parent layer @AccessibilityOz 47 47 48 8

29/04/2020 Test mobile ‐ specific issues Alternatives gian@accessibilityoz.com 49 @accessibilityoz accessibilityoz.com 49 50 Alternatives Alternative Alternatives are provided for non ‐ web mobile functionality that is mandatory (for example, recording a specific gesture by the camera, before functionality appears). Alternative is not sufficient @AccessibilityOz 51 51 52 Alternatives Simplified Important functionality and information is available in the Reader or Simplified view. Simplified view ‐ Pass @AccessibilityOz 53 53 54 9