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