Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Dive Into Mobile - Guidelines for Testing, Native and Web Apps

473 Aufrufe

Veröffentlicht am

Presented at International Association of Accessibility Professionals Access 2015

Veröffentlicht in: Mobil
  • Als Erste(r) kommentieren

Dive Into Mobile - Guidelines for Testing, Native and Web Apps

  1. 1. Dive into Mobile Guidelines for Testing Native, Hybrid, and Web Apps Susan Hewitt, Accessibility Consultant, Deque Systems Jeanine Lineback, Accessibility Subject Matter Expert, Deque Systems
  2. 2. Today’s Objectives • Identify key success criteria to test for mobile. • Learn which testing techniques can be used for each success criterion. • Understand how to use these techniques on native apps and mobile websites.
  3. 3. Which Guidelines Can You Use for Mobile? • WCAG 2.0 • Mobile Web Application Best Practices (WBAP) • Mobile Web Best Practices (MWBP) • iOS and Android Developer Specs
  4. 4. What Tools Do We Use? • Screen readers (VoiceOver and TalkBack) • Jim Thatcher’s Favelets • Paul Adam’s Bookmarklets • Desktop Browsers with a User Agent • Manual testing • Bluetooth devices
  5. 5. Headings • Applicable Guidelines: WCAG SC 1.3.1, 1 • Considerations: – Not all browsers and devices announce headings the same. – iOS & Android native apps won’t announce heading levels. – Safari on iOS and Firefox on Android will announce headings.
  6. 6. Headings – How to Test • iOS (Native and Web) – Using VoiceOver, choose “Headings” in rotor or swipe through the page items one by one. – Expected behavior: Elements that should be headings are announced as such. Web content in Safari should also announce the heading level. • Android (Web) – Navigate through page items with screen reader on. Elements that should be headings are announced as such. Web content in Firefox should also announce the heading level.
  7. 7. Tables • Applicable Guidelines: WCAG SC 1.3.1 • Considerations: Act differently depending on device
  8. 8. Tables – How to Test • iOS (both) – Using VoiceOver, navigate horizontally through data tables by flicking left and right through each data cell. Make sure column headers are spoken by VoiceOver. – Navigate vertically through data table cells by switching to the Vertical Navigation Rotor setting and flicking up or down. Make sure the row headers are spoken. • Android (Native & Web in Firefox only) – Using TalkBack, navigate horizontally through data tables by flicking left and right through each data cell. – Users must hear the content of row and column headers announced with the content of each data cell.
  9. 9. Form Labels and Grouping • Applicable guidelines: WCAG SC 1.3.1 & 3.3.1 • Special considerations: Form input types may present different keyboards.
  10. 10. Form Labels – How to Test • iOS (both) – Native: Using VoiceOver navigate through screen and make sure each form field is announced as such (and is the appropriate type) as well as having a descriptive label. Make sure the labels are visible to all users at all times (No placeholders for labels!) and programmatically linked to the field. • Android (both) – Native (both) Using TalkBack navigate through the screen and make sure each form field is announced as as well as having a descriptive label. Make sure the labels are visible to all users at all times. (No placeholders for labels!) • For groups of related form elements (i.e. checkboxes & radio buttons,) the labeled controls must be associated with their common grouping element.
  11. 11. Text Resize & Magnification • Applicable Guidelines: WCAG SC 1.4.4, MWBP 5.4.8 • Considerations: Some browsers and native apps will override a user’s chosen method of resizing.
  12. 12. Text Resize & Magnification – How to Test • Android and iOS expectations – Web: Users must be able to “pinch-and-zoom” to enlarge the screen. (Note, this will make it necessary to pan horizontally to see all content.) – Native: Apps should enlarge according to user font settings in the device.
  13. 13. Color Contrast • Applicable Guidelines: WCAG SC 1.4.3, 1.4.6 • Considerations: Viewing the screen in different environments and light can make poor contrast even worse.
  14. 14. Color Contrast – How to Test • Android and iOS – Native: Use colors designated in the style guide to check with a contrast tool. If the style guide is not available, take screen shots and test using photo software/eyedropper tools. Note that this may not yield completely accurate results. • Android and iOS – Web: Test the contrast ratio in HTML by using an automated tool, examining the style guide or style sheet for hex codes.
  15. 15. Keyboard Navigation & Visible Focus • Applicable Guidelines: WCAG SC 2.1.1, 2.4.7 • Considerations: Behavior varies between OS, Web vs. native, and browser.
  16. 16. Keyboard Navigation – How to Test • Android & iOS – With screen reader off, navigate using a Bluetooth keyboard. – Expectation for iOS: • Native: Content should be functional and navigable using keyboard commands. • Web: Keyboard functionality in Safari is not accessible. – Expectation for Android: • Content should be functional and navigable using keyboard commands in both native and Web apps.
  17. 17. Visible Focus – How to Test • With screen reader off, navigate via a Bluetooth keyboard. Visible focus must always show around active elements. • Expectations – Android, Web & Native: The active element with focus is always visible. – iOS native: Same as Android. iOS web will not show a visible focus.
  18. 18. Touch Target Size • Applicable Guidelines: WCAG SC 2.1.1, Developer Specs • Considerations: This guideline is in draft for addition as a WCAG advisory technique.
  19. 19. Touch Target Size– How to Test • All – Best method: Style guide. • Native apps: iOS active items should be at least 44by44px. Android, 48. • Web view: Check padding in style guide to ensure there’s a measurement equal to roughly 9mm
  20. 20. Names, Roles, and Values • Applicable Guidelines: WCAG SC 4.1.2 • Considerations: UI controls must allow AT to accurately relay information about their function and state to users. Use of custom controls is most likely to cause issues with this guideline. • Examples: “Hamburger menus,” links vs. buttons, tabs
  21. 21. Name, Role, and Value – How to Test • iOS and Android (Native and Web) – Using a screen reader, set focus to all user interface elements such as form fields, links, and scripted controls elements. Make sure the element’s name/label makes sense and is accurate. – Make sure the role spoken (link, button, etc.) matches the functionality of the element. – Make sure the state of the element is announced. (E.g. expanded/collapsed/dimmed/disabled. ) Note: this is broken in iOS 9.1.
  22. 22. References • W3C WCAG 2.0 http://www.w3.org/TR/WCAG20/ • Mobile Web Application Best Practices http://www.w3.org/TR/mwabp/ • Mobile Web Best Practices http://www.w3.org/TR/mobile-bp/ • New WCAG 2.0 Techniques Wiki http://www.w3.org/WAI/GL/mobile-a11y- tf/wiki/New_WCAG_2.0_Techniques
  23. 23. Keep In Touch Susan Hewitt susan.hewitt@deque.com Jeanine Lineback Jeanine.lineback@deque.com

×