iOS Accessibility, 3 Ways

iOS/Swift talk for #SLUG in San Francisco on Nov. 6, 2015. Covers 3 levels of accessibility. We look at basic dev responsibilities. New iOS 8 and onward APIs and we take a fun look at how FRP (Functional Reactive Programming) might suit #a11y programming well.

Transcript

1. ACCESSIBILITY, 3 WAYS SOMMER PANAGE (@SOMMER)
2. ACCESSIBILITY & YOU TALK 1
3. ACCESSIBILITY MEANS “USING TECHNOLOGY TO OVERCOME CHALLENGES.” Apple
6. VOICEOVER DEMO HTTPS://YOUTU.BE/C0NVDIRDEHW?T=32S
7. HOW DO I SUPPORT MY VISUALLY IMPAIRED USERS? A good developer AS A DEVELOPER…
8. VISION VOICEOVER ▸ UIAccessibility APIs such as accessibilityLabel ▸ Avoid images with text ▸ Label all images ▸ Provide equal experiences
9. 44 minutes ago One nice thing about 2013 has been not having to hear Pumped Up Kicks very often. At rooland. Reply Retweet Favorite Jordan Kay At underscore Jordan Profile Picture
10. “Jordan Kay. At Underscore Jordan. 44 minutes ago. One nice thing about 2013 has been not having to hear Pumped Up Kicks very often. Dash. At Roooooland. Two-finger double-tap for tweet actions.”
11. VISION COLOR AND FONTS ▸ Always use Dynamic Type for everything ▸ Tap targets should be no smaller than 44x44 points ▸ All text should have a minimum contrast ratio of 4.5:1 (http:// webaim.org/resources/contrastchecker/) ▸ Keep color schemes simple ▸ Never indicate meaningful content with color alone
12. HOW DO I SUPPORT USERS WITH HEARING, MOTOR OR OTHER CHALLENGES? A good developer AS A DEVELOPER…
13. OTHER CHALLENGES CAPTIONING AND SOUND ▸ All audio/video content should provide optional captioning ▸ Never signal anything with sound alone ▸ Avoid background music/sound and make any background sound easy to disable
14. OTHER CHALLENGES TOUCH AND COGNITION ▸ Avoid complex / hard to discover gestures ▸ Again, keep touch target sizes at/above 44x44 points ▸ Test your interface using switch control; a simple, hierarchical interface will play well with switch control ▸ Avoid screen clutter - favor navigation to clutter
15. EXAMPLES AIRBNB — NOT GREAT ▸ Can’t access search ▸ Buttons are not labeled ▸ Grouping of items is poor ▸ No dynamic text support
16. EXAMPLES TWITTERIFIC 5 — GOOD! ▸ Buttons are well labeled ▸ Grouping of content makes sense ▸ Swipe to conversations has an accessibility shortcut (needs hint tho!) ▸ Customizable visual appearance. ▸ “Refreshing content” lets the user know what is going on
17. RESOURCES APPLE PROVIDES AMAZING #A11Y RESOURCES TO DEVS HTTPS://DEVELOPER.APPLE.COM/ACCESSIBILITY/
18. WHAT’S NEW IN IOS ACCESSIBILITY? TALK 2
19. WHAT’S NEW IN IOS ACCESSIBILITY? SIMPLIFYING THE COMPLEXITY ▸ Interfaces are becoming more dynamic and gesturally-driven ▸ iOS 8 marked the point at which accessibility caught up with these trends ▸ More support for custom behaviors ▸ More support for accessibility tools beyond VoiceOver (such as switch systems)
20. WHAT’S NEW IN IOS ACCESSIBILITY? ACCESSIBILITY ACTIONS ▸ Before ▸ When objects had gesture-based actions such as flicks or swipes, we had to create custom tap-based gestures for our users on VO ▸ After ▸ We can now wrap these actions into the accessibilityCustomActions property on a view and VO will give the user direct access
21. ACCESSIBILITY ACTIONS EXAMPLE: REMINDERS APP Swipe
22. ACCESSIBILITY ACTIONS EXAMPLE: REMINDERS APP
23. ACCESSIBILITY ACTIONS EXAMPLE: REMINDERS APP BUY A SPATULA. DOUBLE-TAP TO EDIT DETAILS. SWIPE UP OR DOWN TO SELECT A CUSTOM ACTION.THEN DOUBLE-TAP TO ACTIVATE. BUY A SPATULA. DOUBLE-TAP TO EDIT DETAILS. ACTIONS AVAILABLE. …Or…
24. WHAT’S NEW IN IOS ACCESSIBILITY? ACCESSIBILITY CONTAINERS ▸ Before ▸ Making custom drawing and non-UIKit objects accessible on screen meant implementing the somewhat buggy and heavy-anded Accessibility Container Protocol ▸ After ▸ Any view can simply set an accessibilityElements array to define objects within it that should be accessible
25. ACCESSIBILITY CONTAINERS EXAMPLE: HEALTH APP ▸ The graph is clearly not rendered via UIViews ▸ How do we provide information to the user about what is contained in this graph?
26. ACCESSIBILITY CONTAINERS EXAMPLE: HEALTH APP
27. ACCESSIBILITY CONTAINERS EXAMPLE: HEALTH APP WEIGHT. 129.2 POUNDS. DAILY AVERAGE 129.07. LAST UPDATED. OCTOBER 30TH, 2015.
28. ACCESSIBILITY CONTAINERS EXAMPLE: HEALTH APP 129 POUNDS. MAY 16TH.
29. WHAT’S NEW IN IOS ACCESSIBILITY? SWITCH CONTROL…CONTROL ▸ Before ▸ When switch support on iOS was introduced, it depended only on accessibility already present via VO. ▸ After ▸ Using accessibilityNavigationStyle, you can now control how the focus selects elements ▸ Switches also interface with any accessibilityCustomActions you add
30. SWITCH CONTROL DEMO
31. WHAT’S NEW IN IOS ACCESSIBILITY? MORE CUSTOMIZATION BASED ON DEVICE STATE ▸ Before ▸ Impossible to tell what AX features were in use. ▸ After ▸ Notifications and state checking functions for when the device enters/leaves various accessibility modes such as grayscale, reduced transparency, color inversion, and more. ▸ Allows you to change the appearance of your app, if necessary, given these modes
34. WHAT’S NEW IN IOS ACCESSIBILITY? BACKWARDS COMPATIBILITY RECOMMENDATIONS ▸ Accessibility Actions ▸ For pre iOS 8, you should still provide a custom gesture and a hint to help that user find said gesture ▸ Often a good solution is using accessibilityPerformMagicTap to trigger an action sheet ▸ Containers ▸ Stick to old UIAccessibilityContainer Protocol until you drop iOS 7 support
35. ACCESSIBILITY + FRP = :-) TALK 3
36. ACCESSIBILITY + FRP = :-) FUNCTIONAL REACTIVE PROGRAMMING ▸ An explicit way to model changes to values over time ▸ Ideal for GUI programming ▸ Since VO is simply another UI (non-visual), it makes sense that FRP would be good for VO as well ▸ Common FRP libraries are RxSwift and ReactiveCocoa
37. ACCESSIBILITY + FRP = :-) WHY FRP? ▸ Sometimes we just need static information in our accessibiltyLabels, values, hints, etc. ▸ But more often, those labels are dynamic NACHO ROBOT. AT SOMMER. IT’S NOTHING FANCY, ANYGENERATOR, IN SWIFT. RETWEETED 1 TIME. FAVORITED 2 TIMES.
38. ACCESSIBILITY + FRP = :-) WHY FRP? ▸ Could just update accessibilityLabel whenever we update the timestampLabel and the favoriteLabel… ▸ But pretty soon we end up calling our “update” methods EVERYWHERE ▸ Instead, whenever a tweet object is updated, that information can flow to both the visual and audio UI elements NACHO ROBOT. AT SOMMER. IT’S NOTHING FANCY, ANYGENERATOR, IN SWIFT. RETWEETED 1 TIME. FAVORITED 2 TIMES.
39. TIME FOR A REAL LIFE EXAMPLE
40. EXAMPLE ACCESSIBILITY ANNOUNCER ▸ The problem? Announcing things via VO is very lossy, using UIAccessibilityAnnouncementNotification. Announcements are not queued. ▸ The solution? A queue - place announcements in a queue and read them one at a time. ▸ But what if the queue is long? We’ll need a time out. ▸ What if the announcement fails? We’ll need a retry policy.
41. EXAMPLE ACCESSIBILITY ANNOUNCER ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT QUEUE ANNOUNCEMENT ANNOUNCEMENT ANNOUNCEMENT Timeout Drop Retry Fail?
42. EXAMPLE ACCESSIBILITY ANNOUNCER ▸ Have tried to do this many times before but always had some issues in my logic - usually somewhere between managing the retry and the timeout. ▸ I experimented with FRP and found that this type of UI data flow is much easier to implement this way. ▸ https://github.com/spanage/AccessibilityAnnouncer/blob/ master/AccessibilityAnnouncer/AccessibilityAnnouncer.swift
43. THANK YOU! QUESTIONS?