Mobile Accessibility Best Practices & Trends

© 2014 IBM Corporation
IBM INTERACTIVE EXPERIENCEIBM INTERACTIVE EXPERIENCE
MOBILE ACCESSIBILITY
BEST PRACTICES & TRENDS
Aidan Tierney
Senior Accessibility Consultant
IBM Interactive Experience
atierney@ca.ibm.com
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 LANDSCAPE
Circumstances 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
1001010101011101001010
0100101011101001001101
0101010100100100101111
0010011001010101001010
1010100101010101010101
0101011111100000101010
1010101001001010101010
1010001111010100011110
1010011101010111110010
1101111010001011001110
Mixed web and
native components.
Native services.
Native Shell
Web Native
Device APIs
<!DOCTY
PE html
PUBLIC
created
2003-12

</body>
</html>
1001010
1010111
0100101
0101010
1010010
0100101
1110010
0110010
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
<html>
<! - - created 2003-12-12 -
-
<head><title>XYZ</title>
</head>
<body>

</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
1001010101011101001010
0100101011101001001101
0101010100100100101111
0010011001010101001010
1010100101010101010101
0101011111100000101010
1010101001001010101010
1010001111010100011110
1010011101010111110010
1101111010001011001110
Native Application
Device APIs
1001010101011101001010
0100101011101001001101
0101010100100100101111
0010011001010101001010
1010100101010101010101
0101011111100000101010
1010101001001010101010
1010001111010100011110
1010011101010111110010
1101111010001011001110
1001010101011101001010
0100101011101001001101
0101010100100100101111
0010011001010101001010
1010100101010101010101
0101011111100000101010
1010101001001010101010
1010001111010100011110
1010011101010111110010
1101111010001011001110
Mixed web and
native components.
Native services.
Native Shell
Web Native
Device APIs
<!DOCTY
PE html
PUBLIC
created
2003-12

</body>
</html>
1001010
1010111
0100101
0101010
1010010
0100101
1110010
0110010
Native Shell
Web Native
Device APIs
<!DOCTY
PE html
PUBLIC
created
2003-12

</body>
</html>
<!DOCTY
PE html
PUBLIC
created
2003-12

</body>
</html>
1001010
1010111
0100101
0101010
1010010
0100101
1110010
0110010
1001010
1010111
0100101
0101010
1010010
0100101
1110010
0110010
Hybrid Apps - WebHybrid Apps - Web
Web app packaged
in native shell.
CSS skins.
Native services.
Native Shell
Web Code
<html>
<! - - created 2003-12-1
</head>
</body>
</html>
Device APIs
Native Shell
Web Code
<html>
<! - - created 2003-12-1
</head>
</body>
</html>
<html>
<! - - created 2003-12-1
</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
<html>
<! - - created 2003-12-12 -
-
</head>
<body>

</body>
</html>
Mobile Browser
Web Code
<html>
<! - - created 2003-12-12 -
-
</head>
<body>

</body>
</html>
<html>
<! - - created 2003-12-12 -
-
</head>
<body>

</body>
</html>
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

Outlying use cases can become
fundamental 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

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

18: The number of iOS devices since 2007
 iPhone
– 8 models since launch
 iPad
– 5 models
 iPod Touch
–5 models
Source: Wikipedia
13

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

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

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

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

Mobile platform usage trend
19
Source: WebAim Survey 2014

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

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

‘Official’ mobile development practices
 Mobile Web Best Practices 1.0 – (2008)
 Mapping between WCAG and MWBP
 Mobile Web Application Best Practices– (2010)
24

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

CREATING ACCESSIBLE APPS
Practices a project team can often control
26

POLICIES FOR
MOBILE ACCESSIBILITY
Mostly 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

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

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

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

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

Android Accessibility resources
• Android Developer Resources for Accessibility
• Accessibility Developer Checklist
• Android Design Patterns for Accessibility
• Accessibility Testing Checklist
58

QUESTIONS & COMMENTS
59

Contact information
Aidan Tierney
Senior Accessibility Consultant
IBM Interactive Experience
atierney@ca.ibm.com
slideshare.net/aidantierney/
ca.linkedin.com/in/aidantierney/
60
• ca.linkedin.com/in/aidantierney/

Mobile Accessibility Best Practices & Trends

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Mobile Accessibility Best Practices & Trends (20)

Recently uploaded (20)

Mobile Accessibility Best Practices & Trends