Henny Swan

Henny SwanSenior Usability and Accessibility Specialist, BBC@ihenihenny@iheni.comwww.iheni.comAccessU 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

henny@iheni.com