mobile accessibility (moba11y)
DESCRIPTION
Making the mobile web accessibleTRANSCRIPT
Mobile Accessibility
Henny Swan#MobA11y
Henny SwanAccessibility Hobo /Senior Usability and Accessibility Specialist, [email protected]@iheni.com
Mobile + Accessibility = MobA11y
1 / Mobile accessibility 2 / Strategy4 / Build3 / Responsive design5 / Test6 / Next
1 / Mobile accessibility
What is ‘mobile’? Mobile web
Viewing content on devices with a browser
Web appsBrowser based web applications built with HTML, CSS and JavaScript
Native appsDownloaded applications that take advantage of phone capabilities (proprietary or Java based)
Hybrid appsBuilt with HTML, CSS and JavaScript, downloadable and can access phone capabilities
What is ‘accessibility’?
Diverse user modelSight, hearing, mobility, learning and cognitionAccess technology usersScreen readers, screen magnification, voice
inputAccess servicesCaption, subtitles, audio description, signingHidden disabilityChronic fatigue, depression, ME, fibromyalgia,
vertigo, nausea, photo sensitivityAging
Deterioration, first time usersTemporaryRSI, broken wrists, back pain, short-term illnessCulturalLanguage, colour, iconographyTechnology
Hardware, software, access
Mobile isby definitiondisabling
Poor lightGlareSmall fontsPoor image and colour supportSmall keyboardsNo mouseTouchOne handScreen size
Mobile isby definitionis enabling
Task basedGeolocationCamera integration Calendar integration
Mobile is more agile than desktopSoftware developmentUptake of web standards?
Bridges the digital divideI can’t afford a computer but I have a mobile
Essential ingredients of accessibility
Web standardsWeb browserPlatform Accessibility APIAssistive technologyPlatform accessibility featuresUsers
Nom, nom, nom Not so nom, nom
Platform accessibility APIs
The bridge between applications and assistive technology
Enables screen readers to readLess mature on mobile than desktopiOS has the best supportAndroid working on it
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
5. Review laws in your countryEstablishing a mobile accessibility strategy – iheni.com
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 20126. Opera 24% (lead for 12 months)7. Android 21% (steady rise)8. iPhone 19.5% (slight increase)9. Nokia 11.8% (a decline)10. Blackberry 7% (sharp decline)
Source: StatCounter 2011-2012
Device capability Speech input/output
iOS Voiceover (iOS3+)Android Talkback (2.2, built in for v4 )Android AccessibilityiOS SiriProloquo
Accessibility settingsZoomFont resizingCustom gesturesColour settingsHapticsSound feedback
Web technology supportHTML, CSS, WAI ARIA, Flash
Remember, people don’t just choose a device for browsing
“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
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
Graded mobile browser support
Yahoo! Graded Browser Support
jQuery Graded mobile browser support
Mobile Web Best Practices Default Delivery Context:
Screen width - 120px minimumMarkup - XHTML Basic 1.1UTF-8Images - JPEG, GIF 89aMaximum page weight - 20KBColour - 256 minimumCSS 1, CSS 2 @media handheld and all
media types
User preference WebAIM Screen Reader Survey 2008 to
2010*550% increase in mobile screen reader usage 2 yearsAdvanced 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 respondentsNokia 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 respondentsNuance 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”
3 / Build
No definitive, universally accepted set of mobile accessibility guidelines
Guidelines related to mobile accessibility
• Web Content Accessibility Guidelines (WCAG)
• Mobile Web Best Practices (MWBP)• Relationship between WCAG and M
WBP• Widget Accessibility Guidelines• Widget Usability Best Practices• Mobile Website Guidelines
(University of Austin)
S
Resources for mobile accessibility guidelines – iheni.com
Device specific mobile accessibility guidelines
AndroidDesigning for AccessibilityAndroid AccessibilityBlackberry Best Practice Designing Accessible ApplicationsiOS: Accessibility Programming GuideNokia/Symbian: User Experience checklist for Touch and Keypad (PDFs)
Agnostic mobile accessibility guidelines
Shared principles with the desktop webEquivalenceProgressive enhancementResponsive designUnobtrusive JavaScriptSeparation of content and presentationFocus and keyboard tab order
Let the mobile web learn from the mistakes of the desktop web – iheni.com
Mobile Accessibility Guidelines & techniques
Coming soon
1. Support device capabilities Use standard controls for native apps
Do not repress zoom capability
Use the most appropriate element for the job:
Avoid text input Pick form controls carefully
2. Alternatives Provide alternatives for content and functionality:
HTML: alt=“Description”iOS: labels, hints and traitsAndroid:
android:contentDescription
Hide non content and functionality objects:
HTML: alt=“”iOS do not ‘Enable Accessibility’
2. Alternatives Alternatives must be appropriate to the purpose or content of the object
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
The langauge rotor in iOS
2. Alternatives –iOS apps Label
Short word or phraseDescribes the object or view i.e. ‘Play’Does not describe the type i.e. ‘Play button’TraitDescribes the type i.e. link, button, checkbox, selected, adjustableMore than one trait can be used i.e. checkbox, selected Hint Use sparinglyExplanation not a command i.e. ‘Plays video’ not ‘Play video’
Channel 4’s iOS app showing multiple programs with play buttons
Label: Done, back to….Trait: Button
Label: [Program name, Episode number]Trait: Static text
Label: Subtitles On/OffTrait: Button
Label: Enter/Exit Full screenTrait: Button
Label: Play /PauseTrait: Button
Label: [ 00.07 of 59.37 ] swipe up or down to adjustTrait: Adjustable
Label: Show/Hide moreTrait: Button
Use consistent alternatives across desktop and mobile
Image Alternative Type Tooltip NotesBBC 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
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
3. Colour Do not rely on colour alone to convey information
Use blocks of colour rather than vague outlines/shades
Use high contrastWCAG 2.0MWBP Default Delivery ContextCheck device specific advice
Firefox
Mobile Safari
3. Colour
4. Structure All structural elements must be marked up
Headings: <h1> to <h6>Lists: <ol>, <ul>, <li>Text: <p>
WAI ARIA landmarksNavigation, banner, main, complementry, search, contentinfoPartial support on mobile
HTML5 sectioning elementsArticle, footer, header, nav, aside, sectionNo support on mobile
Note: Headings only apply to page heading in iOS apps
1
2
3
4. Structure: Unique page titles
Example taken from the iOS YouTube app
Ensure page titles are visible
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
6. Page order Provide visible focusHTML “Focus First” : a:focus, a:hover, a:active
Android: setVisibility(int)
Ensure a logical page orderSet a logical code orderAndroid: setFocusable (), isFocusable (), requestFocus ()
Important for touch screen as wellSwipe up or down to navigate
componentsSwipe left or right to navigate all items
(= arrow keys on desktop)
7. Focus Provide enough ‘read-tap symmetry’
Touch targets should be large enough
Jacob Neilson9.2-9.6mm minimally Provide 1mm inactive space
around elements
Beware: Pixel density changes per handset
8. Forms Correctly label form input items
Avoid free input where possible, use drop down menus etc
Support default input modeDates, text, number, language formats
Support predictive inputDrop down listPage updates
IMDB app for iOS
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
Bbc iplayer showing subtitles
9. Multimedia:HTML5 audio and video
Supported on iPad and iPhoneFallback must be providedCaptions should be provided
Source: HTML5 and Accessibility sitting in a tree Bruce Lawson
HTML5 Current mobile browser support is poor
No support in mobile screen readers
But
The promise of accessibilityMore accessible formsAudio and video controlsCaptioningSectioning elements
It’s not too early to start experimenting with HTML5
In
Introducing HTML5 – Bruce Lawson and Remy Sharp
4 / Responsive design
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
‘Responsive’ – a website responds to screen size, orientation and environment
A seamless experience
But what are the ‘breakpoints?’
1. Title text and span <title> and <abbr> not
supported in Mobile Safari, IDEAL (Android) and Nokia
Avoid reliance on <title> text on linksProvide information elsewhere
<span> works in links but not plain text in Mobile Safari
Screen reader support for abbr and span on mobile – iheni.com
2. Grouping links Good practice to group related links e.g. images
and link textCreates one keypress / touchzoneReduces repetition and clutterLarge 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
2. StructureShould structure be consistent across desktop, tablet and mobile?
Not always feasibleNot always preferableStructure may ‘collapse’
Plan underlying code structure during wireframing
Desktop – Smashing magazine
Tablet
Mobile
WAI ARIA and Mobile Safari Supported
Menu bar, buttons, dialog, checkbox, accordion, tabs, auto-complete, panel
Partially supportedTooltip (links and form fields not images)Landmarks (read out but not named)
Not supportedSlider, progress bar, tree, carousel, date picker, tabindex
WAI ARIA support on iOS – iheni.com
5 / Test
Types of testing Specialist tools
DebuggersEmulatorsExtensions
User acceptance criteriaPersonas Scenarios
User testingFormalInformal with volunteers
Accessibility support testingAssistive technologyAccessibility settings
Finding usability bugs with automated testing – Julian Harty, eBay
Testing tools for HTML Browser based
FirebugFireEyesFireFox user agent switcher
Online toolsOpera EmulatorOpera TV emulatorOpera Dragonfly remote debuggerW3C mobileOK
Device specificiOS xCode
FireEyes WCAG and Section 508 testingIntegrated with FireBug in FireFoxReport generationReport sharingIntegration 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
TalkbackIDEAL Web BrowserAndroid Accessibility
Android 4Enable accessibility by drawing a rectangleTalkback built inStill no accessible browserExplore by touch
Talk is cheap, screen reader testing on mobile(http://www.iheni.com/talk-is-cheap-screen-reader-testing-on-mobile/)
Testing iOS: Accessibility Inspector (xCode)
iPhone/iPad web and app accessibility – Paul Adams
iOS and VoiceOver Switch VoiceOver on
Triple press the home keySettings > General > Accessibility > VoiceOver on/Off
VoiceOver screen curtainTriple tap to turn the screen off
Use Web Rotor to testUsers rarely just tap around the screenTests logical structureForms fields and associated labelsPage order
Quick tests with mobile screen readers
1. All functional/content related elements have an alternative
2. Eye candy is ignored
3. Elements that need explanation have a longer description
4. Alternatives do not describe the type
5. Pages/screens have titles
6. Layout changes are announced
7. Changes of state are announced
Top ten tests for alternatives on mobile on iheni.com
There is no substitute for testing with users with disabilities on mobile
6 / Next
/ Guidelines Agnostic mobile accessibility guidelines with device specific techniques
/ StrategyBuild an accessible HTML mobile website then add accessible native apps
/ BuildCreate shared inventories for alternatives, headings and labels
/ TestTalk is cheap
/ NextShare
Thank you
@iheni
One web