the good, the bad, the voiceover - ios accessibility
TRANSCRIPT
The Good,The Bad,
The Voice OverAimee Maree Forsstrom
Technical Director
Aug 29-31, 2016
@aimee_maree
Who am I?Aimee Maree Forsstrom
Old School Technologist — Born before the classic mac was (something Princess Josh reminded me)
Educational Research - Academic and paid researcher
Principal Engineer - Marcel Sydney
Accessibility Advocate - ADHD / ASD / SPD
Someone who wants to help people
A Problem Solver! and that I think is the most important
Why am I here?I have been working in technology since the early days (when flashing gifs where actually how we animated)
My main passion in technology has been how humans use technology and the human connection to tech
When I was being taught to code I was told don't worry about making your code accessible… Challenge accepted…
Solutions Architect and developer for many Aussie accessible websites
As I like to say all great things start with a story…
DisclaimerI told you there would be iOS code examples
I am a web developer and web/email systems administrator by trade
Y'all probably know iOS better then me
So lets chat about how the API works and discuss some ways to change our thinking of accessibility when designing and developing Apps
Accessibility MattersEstimated 15 percent of the worlds population live with some kind of impairment - 2011 WHO World Report on Disability
Ageing population
Increase in diagnosis of cognitive and sensory differences (ASD, ADHD, SPD)
Time Poor
Because you make Apps for People
Increased Market Share as you cater for wider audience
Historyin 2009 Apple released Voice Over feature on iOS 3.0
If you have an iPhone higher then iphone3 it includes the UI Accessibility programming interface
Part of iOS SDK
Accessibility checker built into xcode simulator
Accessibility attributes available in interface designer
OSX / iOS and AccessibilityApple is actually pretty good at having a similar accessibility experience across devices
They have for a long time had an actual accessibility team
iPad and iPhone have become an assistive aid for many people with disabilities (in certain circumstances the government will give you a grand under NDIS for an ipad)
Sorry Android… but after using VoiceOver on iphone Android is a poor experience
Google maps horribly inaccessible, however Apple Maps is
Accessibility AssistanceOr as I like to call it Human Assistance
Lets look into some differences in humans that iOS caters for
Cognitive AssistanceGuided Access
Introduced in iOS 6 to help people with cognitive differences and sensory challenges to focus on a single app to provide an uninterrupted learning experience
iOS 8 introduced with Time Limits (above), which guides a child through transitions to prepare them to move on to the next activity in a scheduled series
Visual ImpairmentsVoice Over on iOS it works with touch sensitive - it can tell the user what is under there finger
Speak Screen - it can read your screen for example emails this can be turned on with Siri or your fingers Siri - can be used to activate other accessibility features as well as assist you with reading your emails, tweets
Dictation - need to send a message? with dictation you can simply speak it
Braille Keyboard - Last time I checked I think Apple supported around 56 Braille keyboards
Hearing ImpairmentsCaptions - You can caption movies but you can also caption your application when a noise occurs
Hearing Aid - There is a long list of different hearing aids supported
Mono Audio - Removes the left and right track this is useful for people with hearing issues in only one ear etc
Motor ImpairmentsSwitch Control - Interaction without touching the screen this allows you to point at elements using a gliding cursor
Select elements and actions via external switches that can be activated with head, chin, limb
Can work with simple sensitive controls, sip and puff and motion
The Good, The Bad, The Voice Over
Lets look at VoiceOver?Accessibility API is a way to talk to AT aka VoiceOver
Lives in UIKit in UIAccessiblity.h
Can access individual items in the user interface
Query for its STATUS, STATE and DESCRIPTION
Perform ACTIONS and EVENTS
Accessibility Architecture
Voice OverIphone
AppUI Accessibility Protocol
UI Accessibility Protocol
1. User presses compass app2. VoiceOver asks
"Whats the element at this position"
3. The app looks to its code bundles up the info and sends it to Voiceover RPC
4. VoiceOver knows the actionsand attributes of the elementand performs needed action
Its all about the Attributes(BOOL) isAccessibilityElement - does the element have accessibility features
(NSString *) accessibilityLabel - the description
(UIAccessiblityTraits) accessibilityTraits - is it a button is it selected
(CGRect) accessiblityFrame - onscreen rectangle [container]
(NSString *) accessibilityHint - provides additional help
(NSString *) accessibilityValue - indicates dynamically changing element [changing states]
Accessibility Traits
Iphone
App
Welcome TextStatic Text
Button
Picture
Play Button
Image
Traits also have Traits
Traits define behaviours
The play button will startmusic
When user presses buttonVoiceOver knows to stop speaking
and let the media playStarts Media Session
Interface Builder has Accessibility functionality build in, makes it easy to add accessibility into your App
So its simple then?Standard UI Elements have the accessibility features included
However
Custom Elements do not, so this is where you need to add them yourself and think about the actions you need VoiceOver to perform
Voice Over GotchasVoice over takes over the gestures on your phone
It changes how your phone is controlled
Touch to select and double tap to operate
Why? Focus… Screen Readers need focus and users need to know whats under their fingers
Remember your users don't all speak the one language, so localise your app
DevelopmentLocalise your app - remember your audience is international
Errors - make sure your communicate in simple language with text clearly
Remember Containers can be a trap, it will start on the high level UI container and then drill down
API Calls for media (void) awakeFromNib {
UIControl *control = [[UIControl alloc] initWithFrame:frame];
control.isAccessibilityElement = YES;
control.accessibilityLabel = @"Play";
[window addSubview:control];
}
Whats wrong with this scenario?
So lets think about a scenario where you are wanting to convey a historical story about World War II Diary letters, the creative might think I know lets add a fading song in the background and include snippets of soldiers speaking…
Think through your application
Design is creating something functional, lets think about the functionality of our design
Think about scenarios that you might find yourself in?
Your on the train your listening to music you see a tweet that says check this cool site out and you click the link… In an autoplay world what happens?
does your audio overtake the music app? does your audio interfere with VoiceOver?
Change your approach and language
See what we did there? We did not need to say “But someone with a disability can not use this app or site” we changed the language to “This will provide a negative user experience”
But we want Sound and your degrading our user experience So Lets make it not auto play, lets add a stop and pause button so the user can control it?
Accessibility needs to be thought of as inclusive design,
Accessibility needs to happen at Design
Before you code something draw it
Work through the workflow
Integrate inclusive thinking into your UX and design
Low Vision and Color Bilindness can also be thought of as Sunlight Blindness - don't use colour alone to convey information use colour and shape
Think about your timing, don't limit actions to time constraints
Screen Readers, Screen Readers…Mac OSX Voice Over Safari/FirefoxMac OSX NVDA Safari/FirefoxMac OSX JAWS Safari/FirefoxiOS Voice OverWindows Phone Narrator Windows JAWS Internet Explorer/FireFox/ChromeWindows NVDA Internet Explorer/FireFox/ChromeLinux ORCA Firefox/Chromium… the list keeps growing and the user experience varies greatly
There is no industry standard
So when your developing a desktop Application you need to speak to the Operating System accessibility APIs
For Mobiles its the phones Operating Systems accessibility features
For the web its the browser and screen reader combination and this can get complex
What can we do?Build accessibility into your release cycle
There are accessibility frameworks for testing
The iOS Simulator has a built-in Accessibility Inspector. It displays all the accessibility data of any given object on screen (just click on it)
Think about inclusivity of your website or app at the design stage
Accessibility is not easy…
You will need to educate people
You will need to add extra time to development
You will need to learn new tools
You will need to test
You will need to fix the bugs
You will need to retest