Upload
jimbo
View
57
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Mobile Accessibility # MobA11y. Senior Usability and Accessibility Specialist, BBC @ iheni [email protected] www.iheni.com AccessU 2012. Henny Swan. 1 / Mobile accessibility 2 / Strategy 3 / Build 4 / Debug 5 / Take aways. 1 / Mobile accessibility . What is ‘mobile’?. - PowerPoint PPT Presentation
Citation preview
Henny SwanSenior Usability and Accessibility Specialist, BBC@[email protected] 2012
Mobile Accessibility#MobA11y
1 / Mobile accessibility 2 / Strategy3 / Build4 / Debug5 / Take aways
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 model
Access technology users
Access services
Hidden disability
Aging
Temporary
Cultural
Technology
‘There are 62 million potentially disabled users in the UK’ Gareth Ford Williams, BBC
Mobile isby definitiondisabling
Poor lightGlareSmall fontsPoor image and colour supportSmall keyboardsNo mouseTouchOne handScreen size
Mobile isby definitionis enabling
Integration with phone featuresGeolocationCamera 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
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 20111. Opera 21 %2. iPhone 19 %3. Nokia 15%4. Blackberry 14%5. Android 14%
Mobile browsers, May20126. Opera 22% (lead for 12 months)7. Android 21% (steady rise)8. iPhone 20% (slight increase)9. Nokia 11% (a decline)10. UC browser 7% (New)
Blackberry dropped out of the top 5 to 5%
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
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”
Separate versions or one fits all? What should you build?
Responsive websiteAdaptive websitesSeparate 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
Widget Usability Best Practices
Resources for mobile accessibility guidelines – iheni.com
Device guidelines Android
Android designAndroid AccessibilityBlackberry Best Practice Designing Accessible ApplicationsiOS: Accessibility Programming GuideNokia/Symbian: User Experience checklist for Touch and Keypad (PDFs)
Desktop and mobile web
Shared principles:EquivalenceProgressive enhancementUnobtrusive JavaScriptSeparation of content and presentationContent order and focus
Agnostic standards and guidelines with device specific techniques
Mobile Accessibility Guidelines & techniques
Coming soon
1Device 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 supportedTooltip (links and form fields not images)Landmarks (read out but not named)
Not supportedSlider, progress bar, tree, carousel, date picker, tabindex
Think HTML firstWAI ARIA support on iOS – iheni.com
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
2Alternatives
Images 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’ Android do not make focusable via
android:focusable
Alternatives
Images 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 etc)
Announce changes of state
Localise text
The language rotor in iOS
Alternatives
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, selected, adjustableMore than one trait can be used i.e. 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
iOS objects
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 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
Alternatives
3Colour
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.0MWBP Default Delivery ContextCheck device specific advice
Contrast
Firefox:
Mobile Safari:
MeaningAlternatives for colour must be both visible and readable by voice output
Colour
4Links
Grouping Good practice to group related links e.g. images and link text
Creates 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>Episode 1…</p></a>
Links
Title and span Title text:Supported on form inputsNot supported in on links
Span:Supported on linksNot 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 usersSome screen reader users
Mobile and some tablets:Collapsed navigationRedundant on touch
Remove using media queries and JavaScript
Skip links on mobile and tablets – iheni.com
Links
BBC Global navigation
Links
5Structure
SemanticsAll 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 mobileTip: It’s not possible to code headings
in iOS, only container views
Structure
‘Accordion’ structure
Should structure be consistent across desktop, tablet and mobile?
Not always feasibleNot always preferablePotentially verbose
Mobile is a different context to DesktopNavigation packed awayContent contractsHeadings may be removedLandmarks less necessary
Structure
Smashing Magazine - Desktop
Structure
Tablet - landscape
Structure
Mobile
Main navigation packed away
Landmarks now redundant (?)
Heading structure collapsed
Structure
1
2
3
Page titles
iOS YouTube app
Ensure page/screen titles are visible
Structure
6Touch
Swipe areas Visual cues to help users navigate
Audible cues for voice output users‘BBC Two'
Notify screen readers of changes to layout
BBC iPhone app for iPlayer
Touch
Finger friendly Provide enough ‘read-tap symmetry’
Provide enough paddingHTML - padding: 1em; iOS - autoResizingMask Android - setPadding(int, int,int,int);
Touch targets should be large enough:iOS - 44pxAndroid – 48dp wide
Beware: Pixel density changes per handset
Touch
7Order
Content order Provide visible focusHTML “Focus First” - a:focus, a:hover, a:active
Android - setVisibility(int)
Ensure a logical page orderHTML - Set a logical code orderiOS – override natural order with accessibilityElementAtIndex, accessibilityElementCount, indexOfAccessibilityElement
Android: setFocusable (), isFocusable (), requestFocus ()
Content order on touch screens – iheni.com
Order
8Zoom
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=”user-
scalable=YES” />
Zoom
9Multimedia
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 iPhoneFallback must be providedCaptions should be provided
Source: HTML5 and Accessibility sitting in a tree Bruce Lawson
Multimedia
10Forms
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
Tip: Mobile Safari and Voiceover ignore autofucus
IMDB app for iOS
Forms
HTML5 forms 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:
LettersNumbersPhone pad
type=tel<label for=“tel”>Tel:</label><input <strong>type=“tel”</strong> name=“tel” id=“tel” />
HTML5 input types by Paul J Adam
Forms
HTML5 Current mobile browser support is poor
But
The promise of accessibilityMore accessible formsAudio and video controlsCaptioningSectioning elements
Invest in your future but don’t rely fully on HTML5 just yet
In
Introducing HTML5 – Bruce Lawson and Remy Sharp
Forms
4 / Debug
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
FirebugFireEyes – includes a user agent
switcherFireFox 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 4Talkback built inStill no accessible browserExplore by touchAccessible Firefox for Android Nightly
Talk is cheap, screen reader testing on mobile – iheni.com
Testing iOS: Accessibility Inspector (xCode)
iPhone/iPad web and app accessibility – Paul Adams
iOS and VoiceOver
Switch VoiceOver onTriple press the home keySettings > General > Accessibility > VoiceOver on/Off
VoiceOver screen curtainTriple tap to turn the screen off
Use Web RotorNavigate via: headings, landmarks, lists, form fields, links…Test:
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
5 / Take aways
/ StrategyOnly build separate mobile sites where appropriate
/ BuildAgnostic mobile accessibility guidelines with device specific techniques
/ DebugTalk is cheap
/ ShareBlog, Tweet #MobA11y, Discuss, BUILD
Thank you