1.
Mobile Accessibility
Henny Swan
#MobA11y

2.
Henny Swan
Accessibility Hobo /
Senior Usability and Accessibility Specialist, BBC
@iheni
www.iheni.com
henny@iheni.com

3.
Mobile + Accessibility = MobA11y

4.
1 / Mobile accessibility
2 / Strategy
4 / Build
3 / Responsive design
5 /Test
6 / Next

5.
1 / Mobile accessibility

6.
What is
‘mobile’? Mobile web
Viewing content on devices with a
browser
Web apps
Browser based web applications
built with HTML, CSS and JavaScript
Native apps
Downloaded applications that take
advantage of phone capabilities
(proprietary or Java based)
Hybrid apps
Built with HTML, CSS and JavaScript,
downloadable and can access phone
capabilities

7.
Diverse user model
What is Sight, hearing, mobility, learning and cognition
Access technology users
‘accessibility’? Screen readers, screen magnification, voice
input
Access services
Caption, subtitles, audio description, signing
Hidden disability
Chronic fatigue, depression, ME, fibromyalgia,
vertigo, nausea, photo sensitivity
Aging
Deterioration, first time users
Temporary
RSI, broken wrists, back pain, short-term illness
Cultural
Language, colour, iconography
Technology
Hardware, software, access

8.
Mobile is
by definition Poor light
disabling Glare
Small fonts
Poor image and colour support
Small keyboards
No mouse
Touch
One hand
Screen size

9.
Mobile is
by definition Task based
is enabling Geolocation
Camera integration
Calendar integration
Mobile is more agile than desktop
Software development
Uptake of web standards?
Bridges the digital divide
I can’t afford a computer but I have a
mobile

10.
Essential
ingredients of Web standards
accessibility Web browser
Platform Accessibility API
Assistive technology
Platform accessibility features
Users
Nom, nom, Not so nom, nom

11.
Platform
accessibility The bridge between applications and
APIs assistive technology
Enables screen readers to read
Less mature on mobile than desktop
iOS has the best support
Android working on it

12.
There’s nothing on iPhone or
iPad that you can do that I can’t
do.
Stevie Wonder

13.
2 / Strategy

14.
What devices 1. Assess mobile OS and browser
should I market share
support? 2. Review devices in existing company
test plans
3. Assess which popular devices
support accessibility
4. Establish what devices people are
using
Establishing a mobile accessibility 5. Review laws in your country
strategy – iheni.com

15.
Market share
globally Mobile browsers, Jan 2011
1. Opera 21 %
2. iPhone 19 %
3. Nokia 15%
4. Blackberry 14%
5. Android 14%
Mobile browsers, Jan 2012
1. Opera 24% (lead for 12 months)
2. Android 21% (steady rise)
3. iPhone 19.5% (slight increase)
Source: StatCounter 2011-2012
4. Nokia 11.8% (a decline)
5. Blackberry 7% (sharp decline)

16.
Device
capability Speech input/output
iOS Voiceover (iOS3+)
Android Talkback (2.2, built in for v4 )
Android Accessibility
iOSSiri
Proloquo
Accessibility settings
Zoom
Font resizing
Custom gestures
Colour settings
Haptics
“The on-screen keyboard is fully speech Sound feedback
enabled and supposedly accessible but
how much skill in my fingertips am I going
to need to use this thing?”
Web technology support
Should I stay or should I go iPhone– Hugh HTML, CSS, WAI ARIA, Flash
Huddy
Remember, people don’t just choose a device for
browsing

17.
WAI ARIA support
• iOS 3.2 up – partially supported
• Opera Mini 5.0 – partially supported
• Opera Mobile 10.0 – partially supported
• Android – not supported
Source: whencaniuse.com

18.
Graded mobile
browser Yahoo! Graded Browser Support
support
jQuery Graded mobile browser support
Mobile Web Best PracticesDefault
Delivery Context:
Screen width - 120px minimum
Markup - XHTML Basic 1.1
UTF-8
Images - JPEG, GIF 89a
Maximum page weight - 20KB
Colour - 256 minimum
CSS 1, CSS 2 @media handheld and all
media types

19.
User
WebAIM Screen Reader Survey 2008 to
preference 2010*
550% increase in mobile screen
reader usage 2 years
Advanced screen reader users
more likely to use mobile
* Not hard research but great anecdotal
evidence

20.
Which of the following is your primary
mobile platform? (2010)
Mobile Platform Number of respondents % of respondents
Nokia 400 42.4%
AppleiPhone or iPod Touch 308 32.6%
Android 38 4.0%
Blackberry 10 1.1%
Palm 3 .3%
Other 185 19.6%

21.
Which mobile screen reader do you
commonly use? (2010)
Mobile Platform Number of respondents % of respondents
Nuance Talks 374 30.0%
VoiceOver for iPhone 338 27.1%
Mobile Speak 203 16.3%
Talkback for Android 31 2.5%
Orator/Oratio for 8 .6%
Blackberry
Other 80 6.4%

22.
21st Century
Communications
All smartphones sold in the U.S. must
and Video have an accessible web browser by
Accessibility Act, October, 2013
USA Smartphones will need to be accessible
in general
Solutions must be free or of "nominal
cost”

23.
3 / Build

24.
No definitive, universally accepted set of
mobile accessibility guidelines

25.
Guidelines
related • Web Content Accessibility Guidelines
(WCAG)
to mobile
S
• Mobile Web Best Practices (MWBP)
accessibility • Relationship between WCAG and
MWBP
• Widget Accessibility Guidelines
• Widget Usability Best Practices
• Mobile Website Guidelines
(University of Austin)
Resources for mobile accessibility
guidelines – iheni.com

26.
Device specific
Android
mobile
Designing for Accessibility
accessibility Android Accessibility
guidelines Blackberry Best Practice Designing
Accessible Applications
iOS: Accessibility Programming
Guide
Nokia/Symbian: User Experience
checklist for Touch and Keypad
(PDFs)

27.
Agnostic
mobile Shared principles with the desktop web
accessibility Equivalence
guidelines Progressive enhancement
Responsive design
Unobtrusive JavaScript
Separation of content and presentation
Focus and keyboard tab order
Let the mobile web learn from the
mistakes of the desktop web –
iheni.com

28.
Mobile Accessibility Guidelines &
techniques
Coming soon

29.
1. Support
device
Use standard controls for native apps
capabilities
Do not repress zoom capability
Use the most appropriate element for
the job:
Avoid text input
Pick form controls carefully

30.
2. Alternatives Provide alternatives for content and
functionality:
HTML: alt=“Description”
iOS: labels, hints and traits
Android: android:contentDescription
Hide non content and functionality
objects:
HTML: alt=“”
iOS do not ‘Enable Accessibility’

31.
2. Alternatives Alternatives must be appropriate to the
purpose or content of the object
The langauge rotor in iOS
Assign brief and descriptive labels to all
meaningful content
Do not describe the type within the
alternative (link, button, checkbox etc)
Announce changes of state
Localise text

32.
2. Alternatives –
Label
iOS apps
Short word or phrase
Describes the object or view i.e. ‘Play’
Channel 4’s iOS app showing multiple Does not describe the type i.e. ‘Play
programs with play buttons
button’
Trait
Describes the type i.e. link, button,
checkbox, selected, adjustable
More than one trait can be used i.e.
checkbox, selected
Hint
Use sparingly
Explanation not a command i.e. ‘Plays
video’ not ‘Play video’

33.
Label: Done, Label: [Program name, Label: Subtitles Label:
back to…. Episode number] On/Off Enter/Exit Full
Trait: Button Trait: Static text Trait: Button screen
Trait: Button
Label: Play Label: [ 00.07 of 59.37 ] swipe up or Label:
/Pause down to adjust Show/Hide
Trait: Button Trait: Adjustable more

34.
Use consistent alternatives across
desktop and mobile
Document a shared inventory via a wiki, shared folder
or design documentation
Better cross device experience for screen reader
users and users of lower end devices
Image Alternative Type Tooltip Notes
BBC 4 Link NA HTML: CSS background
image with text
replacement
Play Button NA
Download Button Downloads Must dynamically update
[item item to your with item name
name] phone

35.
3. Colour Do not rely on colour alone to convey
information
Use blocks of colour rather than vague
outlines/shades
Use high contrast
WCAG 2.0
MWBP Default Delivery Context
Check device specific advice

36.
3. Colour
Firefox
Mobile Safari

37.
4. Structure All structural elements must be marked
up
Headings: <h1>to <h6>
Lists: <ol>, <ul>, <li>
Text: <p>
WAI ARIA landmarks
Navigation, banner, main,
complementry, search, contentinfo
Partial support on mobile
HTML5 sectioning elements
Article, footer, header, nav, aside,
Note: Headings only apply to page
heading in iOS apps
section
No support on mobile

38.
4. Structure:
Unique page
Ensure page titles are visible
titles
1
2
3
Example taken from the iOS YouTube
app

39.
5. Orientation
and feedback Visual structure should help users
navigate
Swipe areas should be clear
Notify screen readers of changes to
layout
Provide page titles

40.
6. Page order Provide visible focus
HTML “Focus First” : a:focus, a:hover,
a:active
Android: setVisibility(int)
Ensure a logical page order
Set a logical code order
Android: setFocusable (),
isFocusable (), requestFocus ()
Important for touch screen as well
Swipe up or down to navigate
components
Swipe left or right to navigate all items
(= arrow keys on desktop)

41.
7. Focus Provide enough ‘read-tap symmetry’
Touch targets should be large enough
Jacob Neilson
9.2-9.6mm minimally
Provide 1mm inactive space around
elements
Beware: Pixel density changes per
handset

42.
8. Forms Correctly label form input items
IMDB app for iOS Avoid free input where possible, use
drop down menus etc
Support default input mode
Dates, text, number, language
formats
Support predictive input
Drop down list
Page updates

43.
9. Multimedia Support captions, subtitles, audio
description where the technology exists
Ensure buttons have labels
Ensure buttons are focusable
Ensure tab order of buttons is logical
Provide tooltips and hints where
necessary

44.
Bbciplayer showing subtitles

45.
9. Multimedia: Supported on iPad and iPhone
HTML5 audio Fallback must be provided
and video Captions should be provided
Source: HTML5 and Accessibility sitting in a
tree Bruce Lawson

46.
HTML5 Current mobile browser support is poor
No support in mobile screen readers
In
But
The promise of accessibility
More accessible forms
Audio and video controls
Captioning
Sectioning elements
Introducing HTML5 – Bruce Lawson
and Remy Sharp
It’s not too early to start
experimenting with HTML5

47.
4 / Responsive design

48.
There is no mobile web. There is only The
Web which we view in different ways. There
is also no Desktop Web. Or Tablet Web.
Thank you
Stephen Hay, There is no Mobile
Web

49.
Responsive
design and One website across desktop, tablet and
accessibility mobile
‘Responsive’ – a website responds to
screen size, orientation and
environment
A seamless experience
But what are the ‘breakpoints?’

50.
1. Title text
and span <title>and <abbr>not supported in
Mobile Safari, IDEAL (Android) and
Nokia
Avoid reliance on <title>text on
links
Provide information elsewhere
<span>works in links but not plain text
in Mobile Safari
Screen reader support for abbr and
span on mobile – iheni.com

51.
2. Grouping
links Good practice to group related links e.g. images
and link text
Creates one keypress / touchzone
Reduces repetition and clutter
Large clickable area
Tabindex not supported i.e. Tabindex=“-1”
Use a single link:
<a href="…”>
<img width="172" height="96" alt=""
src=”…images/episode.jpg">
<p>Holby City</p>
</a>
Visible outline not shown using Voiceover and
Mobile Safari but it behaves as one touchzone

52.
2. Structure
Should structure be consistent across
desktop, tablet and mobile?
Not always feasible
Not always preferable
Structure may ‘collapse’
Plan underlying code structure during
wireframing

53.
Desktop – Smashing magazine

54.
Tablet

55.
Mobile

56.
WAI ARIA and
Mobile Safari Supported
Menu bar, buttons, dialog, checkbox,
accordion, tabs, auto-complete, panel
Partially supported
Tooltip (links and form fields not
images)
Landmarks (read out but not named)
Not supported
Slider, progress bar, tree, carousel, date
picker, tabindex
WAI ARIA support on iOS – iheni.com

57.
5 /Test

58.
Types of
testing Specialist tools
Debuggers
Emulators
Extensions
User acceptance criteria
Personas
Scenarios
User testing
Formal
Informal with volunteers
Accessibility support testing
Finding usability bugs with automated
testing – Julian Harty, eBay
Assistive technology
Accessibility settings

59.
Testing tools
for HTML Browser based
Firebug
FireEyes
FireFox user agent switcher
Online tools
Opera Emulator
Opera TV emulator
Opera Dragonfly remote debugger
W3C mobileOK
Device specific
iOSxCode

60.
FireEyes WCAG and Section 508 testing
Integrated with FireBug in FireFox
Report generation
Report sharing
Integration with Jira
Next release: integrated user agent
switcher and responsive design
testing

61.
FireEyes

62.
W3C mobileOK Checker

63.
Testing
Android 1.6 up
Android
Enable accessibility: Menu > settings >
Text-To-Speech
Talkback
IDEAL Web Browser
Android Accessibility
Android 4
Enable accessibility by drawing a
rectangle
Talk is cheap, screen reader testing on Talkback built in
mobile
(http://www.iheni.com/talk-is-cheap- Still no accessible browser
screen-reader-testing-on-mobile/)
Explore by touch

64.
Testing iOS: Accessibility Inspector (xCode)
iPhone/iPad web and app accessibility – Paul Adams

65.
iOS and
VoiceOver Switch VoiceOver on
Triple press the home key
Settings > General > Accessibility
>VoiceOver on/Off
VoiceOver screen curtain
Triple tap to turn the screen off
Use Web Rotor to test
Users rarely just tap around the screen
Tests logical structure
Forms fields and associated labels
Page order

66.
Quick tests
with mobile 1. All functional/content related
elements have an alternative
screen readers
1. Eye candy is ignored
1. Elements that need explanation have a
longer description
1. Alternatives do not describe the type
1. Pages/screens have titles
1. Layout changes are announced
Top ten tests for alternatives on
mobile on iheni.com
2. Changes of state are announced

67.
There is no substitute for testing with
users with disabilities on mobile

68.
6 / Next

69.
/ Guidelines
Agnostic mobile accessibility guidelines
with device specific techniques

70.
/ Strategy
Build an accessible HTML mobile website
then add accessible native apps

71.
/ Build
Create shared inventories for alternatives,
headings and labels

72.
/Test
Talk is cheap

73.
/ Next
Share

74.
Thank you
@iheni

75.
One web