1. www.dwt.com | www.ssbbartgroup.com Mobile Accessibility Development Making an Accessible App Usable Scott McCormack

2. Agenda Mobile Accessibility –How is Mobile Different? –Accessibility APIs –Universal Approach –INPUT and OUTPUT –Standard Controls vs. Custom Controls –iOS vs. Android Sign Here App Demo Q&A

3. How is Mobile Different from Desktop Platforms? Mobile security model limits global access to the device Applications are isolated and are severely limited in their ability to communicate with each other Devices have limited memory and CPU resources Developers limited to official APIs Traditional input methods (keyboard/mouse) have been mostly replaced with touch or voice input. –Input methods may vary between devices even within the same platform

4. Accessibility APIs Are It! Accessibility APIs provide a method of universal access to applications while preserving mobile security model Assistive technologies (ATs) must use Accessibility APIs to communicate with the OS and access all applications Applications must use the Accessibility API to provide information to assistive technologies Standard controls provide basic Accessibility API support Custom control must leverage the Accessibility API to be made accessible –Correct implementation of the Accessibility API is key – one mistake and your control will be inaccessible or will crash the application or Assistive Technology!

5. Universal Approach Developers are not going to be familiar with the needs of all (or perhaps any) disabilities When thinking about accessibility consider both the INPUT and OUTPUT of the control –INPUT – What data or interaction the control expects from the user –OUTPUT – What data the control conveys back to the user via the user interface Different disabilities will affect the users’ ability to provide INPUT to the control or perceive the OUTPUT so developers must always consider BOTH when making controls accessible

6. Accessible INs and OUTs Input (WCAG 2.0 Prn. 1 & 3) –Touch Gestures altered to provide control of AT Touch Alternatives –Switch controls Custom gestures must be accessible too! –Data Entry (Keyboards) Support standard data entry methods Input & Control must be fully accessible no matter the AT or input method used Output (WCAG 2.0 Prn. 2) –Name Concise labels If it matters, label it –Role What is it – Button, Text Field etc. Provided by all standard controls –State Provided for standard controls that have a state –Value Values change, labels do not Custom controls need Name, Role, and possibly State defined.

7. Standard VS. Custom Controls Standard Controls –Provide out of the box accessibility support –In most cases, only an accessible label is needed –Complex controls require more work from the developer but all the basics will be provided Custom Controls –May not provide ANY accessibility support –Extending standard controls may require significant changes to make inherited accessibility support work correctly –Developer is solely responsible for the resulting accessibility level of the custom control

8. iOS vs. Android iOS Accessibility provided since iOS 3 (2009) – directly inherited from Mac OS X Apple develops and provides all system-wide AT software. Third party hardware such as Braille displays and switch controls are supported Mature Accessibility API tightly integrated with included ATs, providing support for standard input and output methods Standard controls need little to no work by developers to provide accessibility Providing accessibility to custom controls is well documented and typically requires only a modest development effort Majority of user base is up to date so new features are useable.

9. iOS vs. Android (cont.) Android Accessibility provided since Android 1.6 (2009) –Proper input control (explore by touch) not introduced until Android 4 (2011) AT applications (Accessibility Services) can be developed by third parties Standard AT applications include: –TalkBack (Screen Reader) –BrailleBack (Braille Display) Accessibility API is basic: –Gesture control must be coded manually by app developers especially if controls need more than a simple tap gesture –Developer is limited to minimum API app is set to support.

10. Sign Here DEMO The Problem: –Provide an accessible interface where a user can digitally sign using a finger and the touch screen. Assume we must capture a live signature and no substitute is available or acceptable. Accessibility Issues to Address: –Assistive Technologies take over the touch screen interfering with normal gesture input –Signature box is a custom control which provides no accessible output –User input must be accessible in real time to the user so the user can verify the presence of a signature and know that a signature is being captured

11. Sign Here SOLUTIONS – Middle Box Make signature box visible to Assistive Technologies and provide a basic label: –iOS: set isAccessibilityElement to YES and set an accessibilityLabel –Android: provide a label by setting contentDescription This is the level of effort required to make most standard controls fully accessible – Just label it and the API will take care of the rest!

12. Sign Here SOLUTIONS – Lower Box Make it possible for the user to draw while Assistive Technologies are active and using the touch screen –iOS: Apply the Accessibility Trait UIAccessibilityTraitAllowsDirectInteraction –Android: Modify gesture capture to listen for onHoverEvent in addition to onTouchEvent – consuming hover events break accessibility focus Provide an indication if the signature box contains a signature or is empty –iOS: Apply an AccessibilityValue indicating if the box is empty or has a signature and update at the appropriate times –Android: Include the state of the signature box in the ContentDescription and update at the appropriate times

13. Sign Here SOLUTIONS – Lower Box (cont.) BONUS!!! Provide accessible confirmation that the user is drawing in the signature box –iOS: When drawing begins and ends post an UIAccessibilityAnnouncementNotification –Android: When drawing begins use announceForAccessibility – we are not announcing when drawing ends due to many false announcements

14. Questions?

15. Thank You Contact Us Scott McCormack Principal Technical Consultant scott.mccormack@ssbbartgroup.com SSB Contact Information sales@ssbbartgroup.com (800) 889-9659 Follow Us Twitter @SSBBARTGroup LinkedIn www.linkedin.com/company/ssb-bart- group Facebook www.facebook.com/ssbbartgroup Blog www.ssbbartgroup.com/blog