Transcript `mobile`? - Environments for Humans

Mobile Accessibility
#MobA11y
Henny Swan
Senior Usability and Accessibility Specialist, BBC
@iheni
[email protected]
www.iheni.com
AccessU 2012
1 / Mobile accessibility
2 / Strategy
3 / Build
4 / Debug
5 / Take aways
1 / Mobile accessibility
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
What is
‘accessibility’?
Diverse user model
Access technology users
Access services
Hidden disability
Aging
Temporary
‘There are 62 million potentially
disabled users in the UK’
Gareth Ford Williams, BBC
Cultural
Technology
Mobile is
by definition
disabling
Poor light
Glare
Small fonts
Poor image and colour support
Small keyboards
No mouse
Touch
One hand
Screen size
Mobile is
by definition
is enabling
Integration with phone features
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
There’s nothing on iPhone or
iPad that you can do that I can’t
do.
Stevie Wonder
2 / Strategy
What devices
should I
support?
1. Assess mobile OS and browser
market share
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
strategy – iheni.com
5. Review laws in your country
Market share
globally
Mobile browsers, Jan 2011
1. Opera 21 %
2. iPhone 19 %
3. Nokia 15%
4. Blackberry 14%
5. Android 14%
Mobile browsers, May2012
1. Opera 22% (lead for 12 months)
2. Android 21% (steady rise)
3. iPhone 20% (slight increase)
4. Nokia 11% (a decline)
5. UC browser 7% (New)
Source: StatCounter 2011-2012
Blackberry dropped out of the top 5 to 5%
Device
capability
“The on-screen keyboard is fully speech
enabled and supposedly accessible but
how much skill in my fingertips am I going
to need to use this thing?”
Should I stay or should I go iPhone – Hugh
Huddy
Speech input/output
iOS Voiceover (iOS3+)
Android Talkback (2.2, built in for v4 )
Android Accessibility
iOS Siri
Proloquo
Accessibility settings
Zoom
Font resizing
Custom gestures
Colour settings
Haptics
Sound feedback
Web technology support
HTML, CSS, WAI ARIA, Flash
Remember, people don’t just choose a device for
browsing
User
preference
WebAIM Screen Reader Survey 2008 to
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
Which of the following is your primary
mobile platform? (2010)
Mobile Platform
Number of respondents
% of respondents
Nokia
400
42.4%
Apple iPhone or iPod Touch 308
32.6%
Android
38
4.0%
Blackberry
10
1.1%
Palm
3
.3%
Other
185
19.6%
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
Blackberry
8
.6%
Other
80
6.4%
21st Century
Communications
and Video
Accessibility Act,
USA
All smartphones sold in the U.S. must
have an accessible web browser by
October, 2013
Smartphones will need to be accessible
in general
Solutions must be free or of "nominal
cost”
Separate versions
What should you build?
or one fits all?
Responsive website
Adaptive websites
Separate websites
Let the mobile web learn from the
desktop web – www.iheni.com
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
Responsive
design and
accessibility
One website across desktop, tablet and
mobile which responds to screen size,
orientation and environment
…a seamless experience
…a single accessible code base
…consistency
But what are the breakpoints?
3 / Build
No definitive, universally accepted set of
mobile accessibility guidelines
Related
guidelines
Web Content Accessibility Guidelines
(WCAG)
Mobile Web Best Practices (MWBP)
Relationship between WCAG and
MWBP
Funka.Nu Mobile Accessibility
Guidelines
Widget Accessibility Guidelines
Resources for mobile accessibility
guidelines – iheni.com
Widget Usability Best Practices
Device
guidelines
Android
Android design
Android Accessibility
Blackberry Best Practice Designing
Accessible Applications
iOS: Accessibility Programming
Guide
Nokia/Symbian: User Experience
checklist for Touch and Keypad
(PDFs)
Desktop and
mobile web
Shared principles:
Equivalence
Progressive enhancement
Unobtrusive JavaScript
Separation of content and presentation
Content order and focus
Agnostic standards and guidelines with
device specific techniques
Mobile Accessibility Guidelines &
techniques
Coming soon
Device capabilities
Accessibility
support
Content must not break or disable
device accessibility settings or assistive
technology
Web and platform specific controls
should be used as intended
Accessibility features must be
implemented in a way that is not
mutually exclusive
Device specific guidelines should be
followed
Device capability
WAI ARIA
support
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
Think HTML first
Device capability
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
Device capability
Alternatives
Images
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’
Android do not make focusable via
android:focusable
Alternatives
Images
Alternatives must be appropriate to the
purpose or content of the object
The language rotor in iOS
Assign brief and descriptive labels to all
meaningful content
Do not describe the type within the
alternative (link, button etc)
Announce changes of state
Localise text
Alternatives
iOS objects
Channel 4’s iOS app showing multiple
programs with play buttons
Label
Short word or phrase
Describes the object or view i.e. ‘Play’
Does not describe the type i.e. ‘Play
button’
Trait
Describes the type i.e. link, button,
selected, adjustable
More than one trait can be used i.e.
selected
Hint
Use sparingly
Explanation not a command i.e. ‘Plays
video’ not ‘Play video’
Alternatives
Consistency
Document image alternatives and
tooltips
Creates a consistent user experience
Reinforces branding and ‘look and feel’
for a non visual user
Image
Alternative
Type
Tooltip
Notes
BBC 4
Link
NA
HTML: CSS background
image with text
replacement
Play
Button
NA
Download
[item
name]
Button
Downloads
item to your
phone
Must dynamically update
with item name
Alternatives
Colour
Contrast
Do not rely on colour alone to convey
information
Use blocks of colour rather than vague
outlines/shades
Use high contrast – but what is good
contrast on mobile?
WCAG 2.0
MWBP Default Delivery Context
Check device specific advice
Contrast
Meaning
Alternatives for colour must be both
visible and readable by voice output
Firefox:
Mobile Safari:
Colour
Links
Grouping
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>Episode 1…</p>
</a>
Links
Title and span
Title text:
Supported on form inputs
Not supported in on links
Span:
Supported on links
Not supported on plain text
Tested on iOS, IDEAL web reader
Android, and Nokia
Screen reader support for abbr and
span on mobile – iheni.com
Links
Skip links
Desktop:
Sighted keyboard users
Some screen reader users
Mobile and some tablets:
Collapsed navigation
Redundant on touch
Remove using media queries and
JavaScript
Skip links on mobile and tablets –
iheni.com
Links
BBC Global navigation
Links
Structure
Semantics
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
Tip: It’s not possible to code headings
in iOS, only container views
Article, footer, header,
nav, aside, section
No support on mobile
Structure
‘Accordion’
structure
Should structure be consistent across
desktop, tablet and mobile?
Not always feasible
Not always preferable
Potentially verbose
Mobile is a different context to Desktop
Navigation packed away
Content contracts
Headings may be removed
Landmarks less necessary
Structure
Smashing Magazine - Desktop
Structure
Tablet - landscape
Structure
Mobile
Main navigation packed away
Landmarks now redundant (?)
Heading structure collapsed
Structure
Page titles
Ensure page/screen titles are visible
1
2
3
iOS YouTube app
Structure
Touch
Swipe areas
BBC iPhone app for iPlayer
Visual cues to help users navigate
Audible cues for voice output users
‘BBC Two'
Notify screen readers of changes to
layout
Touch
Finger friendly
Provide enough ‘read-tap symmetry’
Provide enough padding
HTML - padding: 1em;
iOS - autoResizingMask
Android - setPadding(int,
int,int,int);
Touch targets should be large enough:
iOS - 44px
Android – 48dp wide
Beware: Pixel density changes per
handset
Touch
Order
Content order
Provide visible focus
HTML “Focus First” - a:focus,
a:hover, a:active
Android - setVisibility(int)
Ensure a logical page order
HTML - Set a logical code order
iOS – override natural order with
accessibilityElementAtIndex,
accessibilityElementCount,
indexOfAccessibilityElement
Content order on touch screens
– iheni.com
Android: setFocusable (),
isFocusable (), requestFocus
()
Order
Zoom
Zoom
Ensure the viewport metatag is set to user
scalable
Ensure the maximum scale is at least 2.0
i.e.
<meta content=”width=device-width;
initial-scale=1.0; maximum-scale=2.0;
user-scalable=1;” name=”viewport”>
and
<meta name=”viewport” content=”userscalable=YES” />
Zoom
Multimedia
Multimedia
Ensure buttons have labels
Ensure buttons are focusable
Ensure content order of buttons is
logical
Provide tooltips and hints where
necessary
Support captions, subtitles, audio
description where the technology
supports it
Multimedia
Bbc iplayer showing subtitles
HTML5 audio
and video
Supported on iPad and iPhone
Fallback must be provided
Captions should be provided
Source: HTML5 and Accessibility sitting in a
tree Bruce Lawson
Multimedia
Forms
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
Tip: Mobile Safari and Voiceover ignore
autofucus
Forms
HTML5 forms
HTML5 input types by Paul J Adam
Input types specify mode of input:
Date, Month, Number, Range, Tel,
Text, Time, url, week
On iOS and Android this will bring up
the appropriate keypad:
Letters
Numbers
Phone pad
type=tel
<label for=“tel”>Tel:</label>
<input <strong>type=“tel”</strong>
name=“tel” id=“tel” />
Forms
HTML5
Current mobile browser support is poor
But
In
The promise of accessibility
More accessible forms
Audio and video controls
Captioning
Sectioning elements
Introducing HTML5 – Bruce Lawson
and Remy Sharp
Invest in your future but don’t rely
fully on HTML5 just yet
Forms
4 / Debug
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
Testing tools
for HTML
Browser based
Firebug
FireEyes – includes a user agent
switcher
FireFox user agent switcher
Online tools
Opera Emulator
Opera TV emulator
Opera Dragonfly remote debugger
W3C mobileOK
Device specific
iOS xCode
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
FireEyes
W3C mobileOK Checker
Testing
Android
Android 1.6 up
Enable accessibility: Menu > settings >
Text-To-Speech
Talkback
IDEAL Web Browser
Android Accessibility
Talk is cheap, screen reader testing on
mobile – iheni.com
Android 4
Talkback built in
Still no accessible browser
Explore by touch
Accessible Firefox for Android Nightly
Testing iOS: Accessibility Inspector (xCode)
iPhone/iPad web and app accessibility – Paul Adams
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
Navigate via: headings, landmarks, lists,
form fields, links…
Test:
structure
Forms fields and associated labels
Page order
Quick tests
with mobile
screen readers
Top ten tests for alternatives on
mobile on iheni.com
1.
All functional/content related
elements have an alternative
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
2.
Changes of state are announced
There is no substitute for testing with
users with disabilities on mobile
5 / Take aways
/ Strategy
Only build separate mobile sites where
appropriate
/ Build
Agnostic mobile accessibility guidelines with
device specific techniques
/ Debug
Talk is cheap
/ Share
Blog, Tweet #MobA11y, Discuss, BUILD
Thank you
[email protected]