mobile accessibility best practices & trends

© 2014 IBM Corporation

IBM INTERACTIVE EXPERIENCEIBM INTERACTIVE EXPERIENCE

MOBILE ACCESSIBILITY

BEST PRACTICES & TRENDS

Aidan TierneySenior Accessibility Consultant

IBM Interactive Experience

[email protected]

Guelph Accessibility Conference - May 27, 2014

slideshare.net/aidantierney/


IBM INTERACTIVE EXPERIENCE

IBM Interactive Experience & Accessibility

Accessibility consulting

– assessments

– remediation

– training

– corporate policy

– compliance and governance

Customers include:

– banks, insurance companies,

provincial, federal government

Contribute to technical accessibility

standards: WCAG & ARIA

Participation in policy bodies

2



THE MOBILE LANDSCAPECircumstances and trends

relating to accessibility

Project team has no control over these

3



Mobile: different experiences & technology

Native

Hybrid

Mobile web apps

–Browser• Responsive

• Specifically for mobile:

– ‘m dot’: e.g. m.hilton.com

4



Native AppsNative Apps

Platform-specific.

High quality.

Code each platform.

More OS release

volatility.

Native Application

Device APIs

1001010101011101001010010010101110100100110101010101001001001011110010011001010101001010101010010101010101010101010111111000001010101010101001001010101010101000111101010001111010100111010101111100101101111010001011001110

Mixed web and

native components.

Native services.

Native Shell

Web Native

Device APIs

<!DOCTYPE html PUBLICcreated 2003-12</p></body></html>

10010101010111010010101010101010010010010111100100110010

Hybrid Apps - WebHybrid Apps - Web

Web app packaged

in native shell.

CSS skins.

Native services.

Native Shell

Web Code

<!DOCTYPE html PUBLIC<html><! - - created 2003-12-1<head><title>XYZ</title</head></body></html>

Device APIs

Web AppsWeb Apps

HTML5,

JavaScript®.

CSS skins.

Develop faster.

Develop cheaper.

Result less powerful.

No native services.

Mobile Browser

Web Code

<!DOCTYPE html PUBLIC<html><! - - created 2003-12-12 --<head><title>XYZ</title></head><body></p></body></html>

Browser Access Downloadable Downloadable Downloadable

Mobile BrowserMobile Browser Hybrid Apps - WebHybrid Apps - Web Hybrid Apps-MixedHybrid Apps-Mixed Native AppsNative AppsNative AppsNative Apps

Platform-specific.

High quality.

Code each platform.

More OS release

volatility.

Native Application

Device APIs

1001010101011101001010010010101110100100110101010101001001001011110010011001010101001010101010010101010101010101010111111000001010101010101001001010101010101000111101010001111010100111010101111100101101111010001011001110

Native Application

Device APIs

1001010101011101001010010010101110100100110101010101001001001011110010011001010101001010101010010101010101010101010111111000001010101010101001001010101010101000111101010001111010100111010101111100101101111010001011001110

1001010101011101001010010010101110100100110101010101001001001011110010011001010101001010101010010101010101010101010111111000001010101010101001001010101010101000111101010001111010100111010101111100101101111010001011001110

Mixed web and

native components.

Native services.

Native Shell

Web Native

Device APIs


10010101010111010010101010101010010010010111100100110010

Native Shell

Web Native

Device APIs



10010101010111010010101010101010010010010111100100110010

10010101010111010010101010101010010010010111100100110010

Hybrid Apps - WebHybrid Apps - Web

Web app packaged

in native shell.

CSS skins.

Native services.

Native Shell

Web Code


Device APIs

Native Shell

Web Code



Device APIs

Web AppsWeb Apps

HTML5,

JavaScript®.

CSS skins.

Develop faster.

Develop cheaper.

Result less powerful.

No native services.

Mobile Browser

Web Code


Mobile Browser

Web Code



Browser Access Downloadable Downloadable Downloadable

Mobile BrowserMobile Browser Hybrid Apps - WebHybrid Apps - Web Hybrid Apps-MixedHybrid Apps-Mixed Native AppsNative Apps

Device APIs Device APIs Device APIs

Native, hybrids and browser



Universal design, inclusive design

6

“The practice of making products that are inherently

accessible to all users, regardless of ability.” Android

“Products are simple, intuitive, and easy to use… So

every device not only has accessible features —

but accessible principles — built right in.” Apple

http://developer.android.com/design/patterns/accessibility.html

http://www.apple.com/accessibility/



Outlying use cases can becomefundamental requirements

7



Disability types

Blind

Low Vision

Colour Blind

Mobility Impairment

Deaf/Hard of Hearing

Cognitive Impairment

Seizure Disorders

8



Situational and temporary disability

Created by challenging environments

No view of app (e.g. driving)– Speech output

Limited vision (e.g. dimly lit restaurant, bright sunlight)– High contrast

– Screen magnification, zoom

Cannot touch screen (e.g. cooking, driving)– Speech input

Cannot hear the audio track of video (e.g. noisy bar)– Closed captions

– Visual or haptic feedback and notification

9



MOBILE PLATFORMS & DEVICES

10



Mobile platform market share

11

Source: comScore 2014 Canada Digital Future in Focus

http://www.comscore.com/Insights/Presentations_and_Whitepapers/2014/2014_Canada_Digital_Future_in_Focus



Platform version adoption

88% iOS devices using iOS 7

Released September 2013

8.5% Android devices using KitKat

Released October 2013

12

Source: iOS Developer Program Source: Android Developer Dashboard

https://developer.apple.com/support/appstore/

http://developer.android.com/about/dashboards/index.html



18: The number of iOS devices since 2007

iPhone

– 8 models since launch

iPad

– 5 models

iPod Touch

–5 models

Source: Wikipedia

13

http://en.wikipedia.org/wiki/List_of_iOS_devices



11,868: Android device fragmentation

14

Source: OpenSignal: Android Fragmentation Visualized

“We have seen 11,868 distinct devices download our app in the past few

months. In our report last year we saw 3,997” – OpenSignal, July 2013

http://opensignal.com/reports/fragmentation-2013/



ACCESSIBILITY FEATURES &

ASSISTIVE TECHNOLOGY

15



Android Accessibility features

TalkBack (screen reader)

Captions

Magnification gestures

BrailleBack support

Touch & hold delay

Mono audio

Explore by touch

Change font size

Support only available in

recent version of OS

16

Source: Google Android

https://support.google.com/accessibility/android/answer/6006564?hl=en&ref_topic=6007234



iOS Accessibility features

Vision

VoiceOver (screen reader)

Siri

Speak Selection

Dictation

Zoom

Font Adjustments

Invert Colors

Braille display support

Wireless Bluetooth

keyboard support

Deaf or hard of hearing

FaceTime

Closed Captions

Mono Audio

Visible and Vibrating Alerts

Made for iPhone Hearing Aids

17

Source: Apple

Physical or motor challenges

AssistiveTouch

Siri

Switch Control

https://www.apple.com/accessibility/ios/



WebAim survey of screen reader users

18

Primary Mobile Platform %

Apple iPhone, iPad, or iPod touch 65.2%

Android 16%

Nokia 14.3%

Windows Phone 0.3%

Blackberry 0.3%

Other 4%

Source: WebAim Survey of Screen Reader Users, 2014

http://webaim.org/projects/screenreadersurvey5/



Mobile platform usage trend

19

Source: WebAim Survey 2014

http://webaim.org/projects/screenreadersurvey5/



iOS: Dominant platform for mobile AT

Accessibility features and assistive technology

– Built into OS

–No special downloads or extra cost

–Updated with OS updates

– Experience consistent across the device

(Apple and 3rd party apps)

–Consistent with Mac OS features

Extensive accessibility API

Robust support for WAI-ARIA

20



STANDARDS

21



There is no agreed standard

Ideally, app creators build to a standard

Ideally, makers of the user agents support the

same standard–User agent = browsers, devices, AT

But this is not the case– Speed of change

– Some of the major players aren’t too

interested in standards

22

http://en.wikipedia.org/wiki/User_agent



WCAG & Mobile

• WCAG created before mobile was pervasive

• Primarily deals with a browser-based

experience

• Doesn’t address gestures and other changes

to interaction model

• Native apps are more like software than web

applications.

23

http://www.w3.org/WAI/WCAG20/quickref/



‘Official’ mobile development practices

Mobile Web Best Practices 1.0 – (2008)

Mapping between WCAG and MWBP

Mobile Web Application Best Practices– (2010)

24

http://www.w3.org/TR/mobile-bp/

http://www.w3.org/TR/mwbp-wcag/mwbp-wcag20.html

http://www.w3.org/TR/mwabp/



Emerging mobile development practices

BBC Mobile Accessibility Standards and

Guidelines–Comprehensive and practical

–Code samples for web, iOS and Android

– Recommendations later in this presentation draw

on these

Platform-specific guidance: Apple

Android

25

http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile_access.shtml

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Introduction/Introduction.html

http://developer.android.com/guide/topics/ui/accessibility/index.html



CREATING ACCESSIBLE APPSPractices a project team can often control

26



POLICIES FOR

MOBILE ACCESSIBILITYMostly for the enterprise, but even a small

project will need to address these topics

27



Set the Standard

Decide which standard the enterprise will meet– Since there is no real standard, must define one

Communicate mobile accessibility requirements across the

enterprise and to vendors

Authorize someone to interpret and rule on accessibility

standards issues

Create a process to check for conformance to the standard

Create a clear exception process

– Accept that standard will never actually be met

– Define when and how apps will request exceptions and who

will approve them

28



Target mobile platforms, devices and AT

Decide which mobile platforms and devices to target

for accessibility support

– iOS and/or Android and which versions

– Which browser if a web app? Support varies

– Which devices

– Bluetooth keyboard support?

– Understand the accessibility (and limitations) of the

device, operating system, assistive technology

Communicate decisions internally and to customers

Focus effort where most benefit

Remember it’s not only about screen readers!

29



Testing: tools and methods

Select, acquire and distribute testing tools

– Both developers an testers need these

Create test practices that align with existing test

methods

Create accessibility testing procedures

– Step by step instructions

– Pass/fail/exception

30



Training

Identify and address skills gaps

New requirements require new skills

Deliver targeted training based on role

31



Compliance

Compliance documents conformance to the

standard

Compliance doesn’t always require 100%

conformance

Where conformance is not met:– Reasons why not

– Plans and timeline to address issues

– Sign-off from senior executive of business unit

Communicate results internally, and with

government and the public as appropriate

32



INTERACTION DESIGN

33



Personas

If you currently use personas, include persons with

disabilities

Disability is not what defines a user

Consider their experience: power user or novice

Disability may be situational or temporary

Users may not always self-identify as disabled

For more info see:

–AEGIS project personas

– Just Ask: Integrating Accessibility Throughout Design

34

http://www.aegis-project.eu/index.php?Itemid=53&id=63&option=com_content&view=article

http://www.uiaccess.com/accessucd/



Interaction design process

Inclusive design from the start

Wireframe can communicate accessibility

requirements to designers & development team– Roles of elements (button, checkbox)

– State (e.g. selected)

– Labels (including off-screen text)

Assess wireframes for accessibility

Document off-screen text

35



Labels and controls

Standard OS controls–Custom controls often less accessible

–Use standard controls as intended

Labels, inputs and instructions– Set input types (e.g. phone, date, number)

– Indicate expected or default values

– Required or optional

– Labels close to control (important for low vision users)

– Portrait mode: label above control

– Landscape mode: label to the left of control

– Inside text field or drop down also effective

36



Focus & context

Focus or context should not automatically

change when a field is focused or on input

Focus visible when expected

Warn users when launching a browser or

another application (e.g. pdf)

37



Zoom, resize & scroll

Do not disable pinch zoom

Do not block scrolling

Use relative sizing for containers

38



Feedback

Notify screen reader users if the layout of a

screen changes

Feedback must be provided for user action

Provide time-out warnings or alternatives to

timeout

Audio alerts need visual alternative (and/or

haptic)

39



Navigation

Back buttons must correctly move the users

back one step

Use consistent and recognizable navigation

across related screens and between desktop,

web and mobile.

Give screens a unique title

For mobile web, give users options to switch

between full/mobile versions

40



Alerts & pop-ups

Use standard OS alerts where available

Non system pop-ups should completely fit on

the screen, take focus properly, identify

themselves to screen readers.

41



VISUAL DESIGN

42



Visual design

Colour contrast ratio – 7:1 recommended

Target size–min 9.6mm

Indicate swipe areas–Visual and audible clues so content is discoverable

Tap symmetry

Don’t use images of text–Unless logos or other WCAG exceptions

43



CONTENT & LANGUAGE

44



Consistent language across brand

Language on app consistent with website– Labelling, navigation, buttons

Content team can own off-screen text

Consistent and concise off-screen text

Tooltips should not repeat link text or other

alternatives

45



DEVELOPMENT

46



App development process

Provide clear requirements for build and testing

Provision tools (e.g. Bluetooth keyboard), licenses

Allow time for learning requirements, AT and tools

Explain how and when to unit test for accessibility

When in doubt code to spec not to fix AT quirks

Connect developers with accessibility testers

Determine an exception process

47



Development practices

Simple touch events triggered when touch is removed

from a control not when first touched

Support alternative input methods to touch

– E.g. external keyboards

– Some users may use touch and keyboard

Ensure elements are focusable and focus visible

Communicate changes of state so that both sighted

and non-sighted users can perceive the change

– E.g. ,selected/not selected, delete/deleted, add/added

Controls, elements, and objects must be properly

grouped and labeled

48



Making an App Accessible in iOS SDK

iOS Accessibility API and Tools

The UI Accessibility Programming Interface

Accessibility Attributes– Label

– Traits

– Hint

– Frame

– Value

Defining Custom Attribute Information in Interface Builder

Debug Accessibility in iOS Simulator with the Accessibility

Inspector

Test Accessibility on Your Device with VoiceOver

49

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Making_Application_Accessible/Making_Application_Accessible.html#//apple_ref/doc/uid/TP40008785-CH102-SW1

https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityiniOSSimulatorwithAccessibilityInspector/TestAccessibilityiniOSSimulatorwithAccessibilityInspector.html#//apple_ref/doc/uid/TP40012619-CH4

https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html#//apple_ref/doc/uid/TP40012619-CH3



iOS SDK Interface Builder Inspector Pane

50



TESTING

51



Unit testing for Accessibility

Developers can do this

Yes they can

Most testing must be on the

devices and with AT, not a

simulator

Apple Accessibility Inspector

There are no automated tests for

mobile native at this time

HTML syntax checking tools

52

https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityiniOSSimulatorwithAccessibilityInspector/TestAccessibilityiniOSSimulatorwithAccessibilityInspector.html#//apple_ref/doc/uid/TP40012619-CH4-SW1



Acceptance testing for Accessibility

Accessibility Verification Testing (AVT)

Create custom test procedures

Most testing must be on device, not a simulator

Few options for automated testing

Align with existing test methods but realize this differs

Be realistic that not everything will pass

– user agent issues and bugs (browser, AT, device)

Create a process to deal with non-conformance

53



Usability testing

Testing your app with users who have a

disability

Can be informal

Doesn’t have to be complicated

54



RESOURCES

55



Platform agnostic standards & best practices

BBC Mobile Accessibility Standards and Guidelines

Mobile Web Best Practices 1.0

Mapping between WCAG and MWBP

Mobile Web Application Best Practices

Research Report on Mobile Web Accessibility

56

http://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile_access.shtml

http://www.w3.org/TR/mobile-bp/

http://www.w3.org/TR/mwbp-wcag/mwbp-wcag20.html

http://www.w3.org/TR/mwabp/

http://www.w3.org/WAI/RD/2012/mobile/note/ED-mobile



iOS Accessibility resources

Accessibility Programming Guide for iOS

Designing for iOS 7

Verifying App Accessibility on iOS

Accessibility Inspector runs in iOS Simulator

Debug Accessibility in iOS Simulator with the

Accessibility Inspector

57

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/iPhoneAccessibility/Introduction/Introduction.html

https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/index.html

https://developer.apple.com/library/ios/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html#//apple_ref/doc/uid/TP40012619-CH3-SW1





Android Accessibility resources

• Android Developer Resources for Accessibility

• Accessibility Developer Checklist

• Android Design Patterns for Accessibility

• Accessibility Testing Checklist

58

http://developer.android.com/guide/topics/ui/accessibility/index.html

http://developer.android.com/guide/topics/ui/accessibility/checklist.html

http://developer.android.com/design/patterns/accessibility.html

http://developer.android.com/tools/testing/testing_accessibility.html



QUESTIONS & COMMENTS

59



Contact information

Aidan Tierney Senior Accessibility Consultant

IBM Interactive Experience

[email protected]

slideshare.net/aidantierney/

ca.linkedin.com/in/aidantierney/

60

• ca.linkedin.com/in/aidantierney/

mailto:[email protected]

http://www.slideshare.net/aidantierney/

http://ca.linkedin.com/in/aidantierney/

http://ca.linkedin.com/in/aidantierney/

mobile accessibility best practices & trends

Technology