Mobile Accessibility (MobA11y)

Mobile Accessibility

Henny Swan#MobA11y

Henny SwanAccessibility Hobo /Senior Usability and Accessibility Specialist, BBC@iheniwww.iheni.comhenny@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