Simplifying Mobile A11y Presentation.pptx

Mobile accessibility can be a very difficult space to navigate. Let's make it easier to dive right in! From common terms, breakdown of application accessibility, and building up accessibility on mobile development teams, this session will help build the foundation to ensure your mobile applications are accessible.

1. Simplifying Mobile Accessibility

2. Who Am I? Name: Mark Steadman Director – Digital Accessibility Fidelity Investments Mobile Contributions: W3C Mobile Working Group Member MCAG Contributor IAAP mobile cert committee member

3. Learning Outcomes The Disconnect Why mobile accessibility tends to be an afterthought Simple Mobile Requirements Simple guide to helping you build accessible mobile apps Sustaining and Building How can each role impact making our apps accessible

4. Why, What, How? Mobile Accessibility 101 /01

5. Global traffic on mobile devices has increased from 6% in 2011, to 54% in 2021 Anything and everything has a mobile app now.  Some sites even force you to USE the mobile app (Reddit) Quick, easy access: Communication Ride Sharing Banking Food delivery/Grocery Delivery Why Does Mobile Accessibility Matter

6. Why Does Mobile Accessibility Matter cont. According to A study done in the Netherlands: 45% of users have one or more accessibility setting on. 15% have more than one accessibility setting on. Source Credit: https://appt.org/en https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html According to a study done by the CDC, in the US: Around 260 Million Adults in the US 1 in 4 Adults (27%) have a disability (~70 Million) 12.8% Have cognitive disabilities (~33.3 Million) 12.1% have mobility disabilities (~31.5 Million) 6.1% have Hearing Disabilities (~15.9 Million) 4.8% have vision disabilities (~12.5 Million)

7. What Enforces It? Court Decisions: State of Oklahoma/DOJ Settlement Labcorp Kiosk Settlement Dominos Lawsuit In Law: ADA Act Title II DOJ Accessibility Guidance Guidelines: WCAG – Specifically 2.1 and 2.2 Human interface guidelines User Agent Accessibility Guidelines

8. Android Assistive Technology Screen Reader: Voice Over Text Resizing Voice Control Switch Control iOS Assistive Technology Screen Reader: TalkBack Text Resizing Switch Access Keyboard How Do Users Interact with Mobile Apps?

9. Common Navigation Patterns Basic Navigation Move to the next item – Swipe right Move to previous item – Swipe left Activate Focused Item – Double Tap Stop speaking – Two finger tap Additional Controls Rotor Navigation (iOS) – Two finger rotation in circle Once selected swipe up/down LCM Local Context Menu (Android) Three finger swipe right or left Once selected swipe up/down

10. Lets Get Hands On! Lets get hands on

11. BUT FIRST!!! Shortcuts! INDEX.HTML BUT FIRST! Shortcuts

12. TalkBack Directions 1. Open Settings​ 2. Open Accessibility option​ 3. Scroll to the bottom, Accessibility Shortcut option​ 4. Make sure  VoiceOver  is selected VoiceOver Directions 1. Open Settings​ 2. Open Accessibility option​ 3. Scroll to the bottom, Accessibility Shortcut option​ 4. Make sure  VoiceOver  is selected Voiceover and Talkback Shortcut Activation

13. Amazon Workshop Activity Open Amazon App Turn on screen reader (Using shortcut) Using the navigation patterns in previous slide do the following: Search for notebook Add notebook to cart Navigate to the cart

14. Amazon Workshop Outcomes What did you notice? How difficult was the experience? Was there anything you believe could have made it better?

15. The Disconnect WCAG? Terminology? Hybrid Apps? Oh my! /02

16. Accessibility always gets a bad reputation in the mobile community because of one big thing. “Web specialists don’t get mobile!” Mobile developers and designers only have one set of guidelines and resources to go off of, and those are all web based. Minimum requirements are difficult and hard to parse through What is the Disconnect

17. Talking the mobile talk! How can we talk in the same terms as mobile devs and designers? What are the actual mobile standards? Hybrid application development vs native mobile application development Fixing the Disconnect

18. Page = View Main Nav = Navigation/System Bar Aria- describedby or extra content = Hint Focus = Swipe stop/point Tab Order = Swipe Order Resize Text = Scale Key Accessibility Terminology - Common

19. Android Terms Alt Text = accessibilityLabel Role/Aria = Trait Heading = isHeader Tabindex of 0 = groupAccessibilityChildren Aria-hidden = accessibilityHidden iOS Terms Alt Text = ContentDescription Role = Role or RoleDescription Aria- labeledby = labelFor Tabindex of 0 = focusable attribute Aria-hidden = importForAccessibility Key Accessibility Terminology

20. The Problem: There are no “official” mobile accessibility standards. Expectations for user interaction in mobile unclear The Reality : WCAG DOES apply to mobile applications, and quite easily. W3C has a working group that is building official set of mobile accessibility standards Where Are The Standards?!

21. Unofficial Mobile Standards Two sets of unofficial standards: BBC Mobile Standards MCAG (Evinced)

22. Wrench of Hybrid Hybrid applications combine Web and Native development into one singular application Apps are built in web frameworks and then compiled into mobile applications Examples of Hybrid frameworks Cordova Ionic React Native

23. Wrench of Hybrid Cont. Major disconnect in the accessibility community is understanding the type of application being developed. If it is hybrid, then (unless React Native) it is developed using web based frameworks If it is Native, it is developed using Android and iOS based development frameworks Example: Swift/ SwiftUI , Android View/ JetPack Compose

24. Breaking Down Mobile A11y Requirements /03

25. For This Breakdown… For this ENTIRE section, pick any application you want on your mobile device and test it for these requirements You may want to have a couple apps to try out on this. We will leave plenty of testing time for you all to try it out as we go, but please ensure your volume is down a little bit or headphones are in for others around you Ask questions! I want this to be interactive!

26. The Breakdown of the Breakdown! 12 Specific requirements. These 12 requirements are based on data collection done through multiple applications and audits completed that took the top 12 issues seen in mobile applications 4 Categories of Issues View Structure (Navigation) Interactable elements Content User Interaction

27. Proper navigating through an application Headings Easy navigation between content View Titles Unique titles for each new view Swipe Order View Structure (Navigation)

28. Headings - Requirement Rule #1: Main view title must be announced as heading (iOS), Android is NOT required to announce as heading Rule #2: Any text that breaks up logical chunks of content should be properly designated as a heading Rule #3: Headings MUST be navigable by proper OS functionality iOS: Rotor Android: LCM (Local content menu)

29. Headings - Tests Test #1 Identifying Headings: Text that breaks up logical chunks of content should announce as “<Text> Heading” Test #2 Navigation: A user should be able to navigate between sections of content using the Rotor in iOS or LCM in Android iOS Rotor: With VO on, Twist two fingers right/left until you hear headings and swipe up/down to navigate by headings Android LCM: Use three finger swipe left/right until you hear “Headings” then swipe up/down to navigate by headings

30. Headings - Examples Good Bad

31. View Titles - Requirements Rule #1: Each view must have a unique title Rule #2: If a unique title is not possible on each view (Ex: Sign up for insurance), then the following subheading can qualify as the unique heading Rule #3: Titles should not have trailing … or be cutoff

32. View Titles - Tests Test #1 Ensure Unique Titles: As you navigate from view to view, ensure the title in the top of the view is changing Test #2 Ensure Titles Exist: No view should have no title UNLESS the next subsequent text is a heading that serves as the views title (Example to follow) Test #3 Ensure title does not cut off: Without resizing, ensure the title does not have any trailing … or is cut off. Titles should be unique and concise.

33. View Titles - Test Test #1 Ensure Unique Titles: As you navigate from view to view, ensure the title in the top of the view is changing Test #2 Ensure Titles Exist: No view should have no title UNLESS the next subsequent text is a heading that serves as the views title (Example to follow) Test #3 Ensure title does not cut off: Without resizing, ensure the title does not have any trailing … or is cut off. Titles should be unique and concise.

34. View Titles - Examples Good Bad

35. Swipe Order - Requirements Rule #1: Items that logically are group together (Ex: buttons with large amounts of info) are grouped properly in swipe order Rule #2: Ensure content that is not visible is not accessible with screen reader on. Rule #3: Ensure focus view to view is consistent Default focus is to the back button or view title If modal or tray, the focus must return to the trigger

36. Swipe Order -Test Rule #1: Items that logically are group together (Ex: buttons with large amounts of info) are grouped properly in swipe order Rule #2: Ensure content that is not visible is not accessible with screen reader on. Rule #3: Ensure focus view to view is consistent Default focus is to the back button or view title If modal or tray, the focus must return to the trigger

37. Swipe Order Examples Test #1: With VO and TB on, swiping through (right/left) ensure logical grouped content reads as one stop Test #2: With VO and TB on, swiping through (right/left) Ensure no hidden content is visible to screen reader users. Test #3 Ensure focus view to view is consistent. Either stick with default in the title bar OR if focus is controlled it is consistent where it goes Test #4 If a modal or tray is opened, focus returns to the trigger that opened it

38. Swipe Order- Examples Good Bad Example Credit: Android Documentation and Microsoft Mobile Engineering

39. Swipe Order- Examples Cont. Good Bad

40. Native apps should work with keyboard and screen reader Button/Links What is button/Link. Ensuring it properly states its role Input/Forms Inputs/forms should conform to specific mobile standards Keyboard Interactable Elements

41. Button/Link - Requirements Rule #1: Each actionable item must have a proper role! (Trait in iOS) Rule #2: Links take you to webview or web content, buttons keep you within native views Rule #3: Each actionable item must have a proper accessible name that clearly defines its purpose. Note: The label CANNOT include the role

42. Button/Link - Tests Test #1: With VO and TB on, ensure each actionable item has a proper role (Trait) that describes its purpose Test #2: With VO and TB on, if an actionable item takes you to a webview or web content, it has proper role (trait) of link Test #3: With VO And TB on, ensure that the label for each actionable item properly describes it and does not include: file extension naming the role of the item

43. Buttons/Links - Examples Good Bad

44. Inputs/Forms - Requirements Rule #1: Each input should have a consistent and visible label Rule #2: Forms should have an error message WITH proper error icon associated with the input or the entirety of the form Rule #3: Each input MUST NOT have multiple swipe stops (focus points). Single swipe point is all that is needed.

45. Inputs/Forms - Tests Test #1: Ensure each input has a consistent and visible label that is within a logical proximity to the input Test #2: In a form (such as login) enter no information and ensure there is either error messages on each field in question OR a global error message Test #3: With VO or TB on, ensure while swiping through the inputs that the label or error message are not swiped to and it is only focused on the input

46. Inputs/Forms - Examples Good Bad

47. Inputs/Forms - Examples Bad

48. Keyboard - Requirement Rule #1: Native application should function properly in iOS and Android with screen reader on. Should properly function WITHOUT in Android

49. Keyboard - Test Test #1: Connect a Bluetooth keyboard to your device, and turn on VO or TB. Using standard navigation for keyboard, navigate through the view of the application and ensure all actions and content are accessible. Android Keyboard Commands iOS Keyboard Commands

50. Keyboard – Example

51. Color alone cannot dictate vital info Resize Text Text changing size and not cutting ff Images Are properly hidden or described U s e of Color Content

52. Resize Text - Requirements Body copy should be readable, without overlap or truncation, at roughly 200% of its default size Headings (e.g., not body copy) should be readable roughly 130% of its base size The following is a generally agreed upon method of resizing text on mobile devices to measure the above success criteria: iOS Settings > Accessibility > Display & Text Size > Larger Text With the “Larger Accessibility Sizes” toggle Off, using the drag slider increase the text size as large as it will go, then Toggle the “Larger Accessibility Sizes” toggle On, and drag the slider three more notches (this is considered AX3) Android Settings > Accessibility > Text & Display > Font Size Use the drag slider to increase the text size to 6 of 8

53. Resize Text - Test Test #1: iOS With font settings to AX3, look to see if all content is available does NOT contain trailing … Android With font settings to 6 of 8, look to see if all content is available does NOT contain trailing …

54. Resize Text -Example Good Bad

55. Images - Requirements Rule #1: Images that are decorative should be hidden from screen reader users, those that are not should have proper accessibility label. Rule #2: Images MUST NOT contain large chunks of text.

56. Images - Test Test #1: With VO and TB on, ensure that each image is either properly hidden from screen reader OR has proper accessible label for it. Test #2: Locate any images that contain multiple lines of text or text with vital information for the user.

57. Images - Examples Good Bad

58. Use of Color - Requirement Rule #1: Any use of color that depicts vital information to users cannot be used and must have an alternative to share said information

59. Use of Color - Test Test #1: Navigating your application, seek any information that depicted using color alone. IF there is not alternative way to gain that information, use of color is violated Example: Showing negative and positive integers as red and green respectively

60. Use of Color - Example Good Bad

61. All custom gestures must not interfere with common gestures Touch Target Size Proper sizes for interaction Orientation App must work in both landscape and portrait Custom Gestures User Interaction

62. Touch Target Size - Requirements Rule #1: All touch targets in mobile applications must be large enough and easily touchable by all users Android MUST have a minimum touch target size of 4 8dp x 48dp iOS MUST have a minimum touch target size of 44pt x 44 pt

63. Touch Target Size - Tests Test #1: iOS: Use of the Accessibility Inspector Android Use of the Google Accessibility Scanner

64. Touch Target Size - Example Good Bad

65. Orientation - Requirements Rule #1: Mobile applications must adhere to landscape and portrait modes Rule #2: When in landscape, not text or loss of context has occurred

66. Orientation – Test Test #1: Turn on Orientation (allow rotation: iOS: Open control center by swiping from right corner and tapping the “Lock” logo Android: Open control center by swiping from right corner and tapping the “rotation” button (or lock icon if it is locked) Once on, ensure the application works in both landscape and portrait. If portrait works, ensure no overlap or loss of context occurs

67. Orientation – Example Good

68. Custom Gestures - Requirements Rule #1: Any custom gestures (Swipe patterns, touch and hold) MUST NOT interfere with common gestures Rule #2: Swipe only gestures MUST have an alternative method or proper instruction and not be overly complex

69. Custom Gestures - Test Test #1: With VO or TB on, navigate the application using right and left swipe. If any item in the view does something out of the norm (Text sliding, item selected) custom gestures fails Test #2: With VO or TB on, navigate to a “slide to” gesture component and ensure that either: The component has proper instruction to use Has an alternative method to interact

70. Custom Gestures – Example Good Bad

71. Sustain and Build Simple Mobile A11y /04

72. Everybody Has A Role Each person in an organization plays a vital role in ensuring your mobile content is accessible Using the 12 requirements above, we can see how each role can have a large impact in ensuring the issues are fixed before they are even released into production!

73. Tools to Use Headings Visible Label Resize Text Swipe Order Grouping Touch target size Orientation Potential Issues to Fix Include : eBays accessibility annotations toolkit CVS iOS Annotations : CVS a11y kit for iOS specifically Role: Designers

74. Sample Designer Tools

75. Tools to Use Buttons/Links Images Touch Target Swipe Order Potential Issues to Fix Role: Developers Linters SwiftLint Android ATF Automated Tools Accessibility Inspector (iOS) Google Accessibility Scanner

76. Linting Example with SwiftLint

77. Automated Testing Tool Example

78. QA members can have a multitude of different jobs in their daily tasks Regression testing can be a MASSIVE endeavor for teams to get done, and adding accessibility testing to this can be difficult. So what can we do to ensure QA gets accessibility as part of their testing? Role: QA/Test Team

79. Minute to Win it Tests! – Screen Reader Roles for Actions:  Do actionable items have a proper Role? Roles include button, link, switch. Headers:   Do labels that break up sections of content announce as headings? Using the heading rotor command, can you navigate through headings? Appropriate Accessible Text:  Do screen reader announcements match the visual label?  Image Descriptions : Informative: Does the accessible label properly represent the image? Decorative: Is the image hidden from screen reader focus?