Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Mobile Application Testing
Mobile Application Testing
Loading in …3
×
1 of 75

Mobile Accessibility (MobA11y)

50

Share

Download to read offline

Making the mobile web accessible

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Mobile Accessibility (MobA11y)

  1. 1. Mobile Accessibility Henny Swan #MobA11y
  2. 2. Henny Swan Accessibility Hobo / Senior Usability and Accessibility Specialist, BBC @iheni www.iheni.com henny@iheni.com
  3. 3. Mobile + Accessibility = MobA11y
  4. 4. 1 / Mobile accessibility 2 / Strategy 4 / Build 3 / Responsive design 5 /Test 6 / Next
  5. 5. 1 / Mobile accessibility
  6. 6. 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
  7. 7. Diverse user model What is Sight, hearing, mobility, learning and cognition Access technology users ‘accessibility’? Screen readers, screen magnification, voice input Access services Caption, subtitles, audio description, signing Hidden disability Chronic fatigue, depression, ME, fibromyalgia, vertigo, nausea, photo sensitivity Aging Deterioration, first time users Temporary RSI, broken wrists, back pain, short-term illness Cultural Language, colour, iconography Technology Hardware, software, access
  8. 8. Mobile is by definition Poor light disabling Glare Small fonts Poor image and colour support Small keyboards No mouse Touch One hand Screen size
  9. 9. Mobile is by definition Task based is enabling 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
  10. 10. Essential ingredients of Web standards accessibility Web browser Platform Accessibility API Assistive technology Platform accessibility features Users Nom, nom, Not so nom, nom
  11. 11. Platform accessibility The bridge between applications and APIs assistive technology Enables screen readers to read Less mature on mobile than desktop iOS has the best support Android working on it
  12. 12. There’s nothing on iPhone or iPad that you can do that I can’t do. Stevie Wonder
  13. 13. 2 / Strategy
  14. 14. What devices 1. Assess mobile OS and browser should I market share support? 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 5. Review laws in your country strategy – iheni.com
  15. 15. 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 2012 1. Opera 24% (lead for 12 months) 2. Android 21% (steady rise) 3. iPhone 19.5% (slight increase) Source: StatCounter 2011-2012 4. Nokia 11.8% (a decline) 5. Blackberry 7% (sharp decline)
  16. 16. Device capability Speech input/output iOS Voiceover (iOS3+) Android Talkback (2.2, built in for v4 ) Android Accessibility iOSSiri Proloquo Accessibility settings Zoom Font resizing Custom gestures Colour settings Haptics “The on-screen keyboard is fully speech Sound feedback enabled and supposedly accessible but how much skill in my fingertips am I going to need to use this thing?” Web technology support Should I stay or should I go iPhone– Hugh HTML, CSS, WAI ARIA, Flash Huddy Remember, people don’t just choose a device for browsing
  17. 17. 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
  18. 18. Graded mobile browser Yahoo! Graded Browser Support support jQuery Graded mobile browser support Mobile Web Best PracticesDefault Delivery Context: Screen width - 120px minimum Markup - XHTML Basic 1.1 UTF-8 Images - JPEG, GIF 89a Maximum page weight - 20KB Colour - 256 minimum CSS 1, CSS 2 @media handheld and all media types
  19. 19. User WebAIM Screen Reader Survey 2008 to preference 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
  20. 20. Which of the following is your primary mobile platform? (2010) Mobile Platform Number of respondents % of respondents Nokia 400 42.4% AppleiPhone or iPod Touch 308 32.6% Android 38 4.0% Blackberry 10 1.1% Palm 3 .3% Other 185 19.6%
  21. 21. 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 8 .6% Blackberry Other 80 6.4%
  22. 22. 21st Century Communications All smartphones sold in the U.S. must and Video have an accessible web browser by Accessibility Act, October, 2013 USA Smartphones will need to be accessible in general Solutions must be free or of "nominal cost”
  23. 23. 3 / Build
  24. 24. No definitive, universally accepted set of mobile accessibility guidelines
  25. 25. Guidelines related • Web Content Accessibility Guidelines (WCAG) to mobile S • Mobile Web Best Practices (MWBP) accessibility • Relationship between WCAG and MWBP • Widget Accessibility Guidelines • Widget Usability Best Practices • Mobile Website Guidelines (University of Austin) Resources for mobile accessibility guidelines – iheni.com
  26. 26. Device specific Android mobile Designing for Accessibility accessibility Android Accessibility guidelines Blackberry Best Practice Designing Accessible Applications iOS: Accessibility Programming Guide Nokia/Symbian: User Experience checklist for Touch and Keypad (PDFs)
  27. 27. Agnostic mobile Shared principles with the desktop web accessibility Equivalence guidelines Progressive enhancement Responsive design Unobtrusive JavaScript Separation of content and presentation Focus and keyboard tab order Let the mobile web learn from the mistakes of the desktop web – iheni.com
  28. 28. Mobile Accessibility Guidelines & techniques Coming soon
  29. 29. 1. Support device Use standard controls for native apps capabilities Do not repress zoom capability Use the most appropriate element for the job: Avoid text input Pick form controls carefully
  30. 30. 2. Alternatives 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’
  31. 31. 2. Alternatives Alternatives must be appropriate to the purpose or content of the object The langauge rotor in iOS 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
  32. 32. 2. Alternatives – Label iOS apps Short word or phrase Describes the object or view i.e. ‘Play’ Channel 4’s iOS app showing multiple Does not describe the type i.e. ‘Play programs with play buttons button’ Trait Describes the type i.e. link, button, checkbox, selected, adjustable More than one trait can be used i.e. checkbox, selected Hint Use sparingly Explanation not a command i.e. ‘Plays video’ not ‘Play video’
  33. 33. Label: Done, Label: [Program name, Label: Subtitles Label: back to…. Episode number] On/Off Enter/Exit Full Trait: Button Trait: Static text Trait: Button screen Trait: Button Label: Play Label: [ 00.07 of 59.37 ] swipe up or Label: /Pause down to adjust Show/Hide Trait: Button Trait: Adjustable more
  34. 34. Use consistent alternatives across desktop and mobile 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 Image Alternative Type Tooltip Notes BBC 4 Link NA HTML: CSS background image with text replacement Play Button NA Download Button Downloads Must dynamically update [item item to your with item name name] phone
  35. 35. 3. Colour Do not rely on colour alone to convey information Use blocks of colour rather than vague outlines/shades Use high contrast WCAG 2.0 MWBP Default Delivery Context Check device specific advice
  36. 36. 3. Colour Firefox Mobile Safari
  37. 37. 4. Structure 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 Article, footer, header, nav, aside, Note: Headings only apply to page heading in iOS apps section No support on mobile
  38. 38. 4. Structure: Unique page Ensure page titles are visible titles 1 2 3 Example taken from the iOS YouTube app
  39. 39. 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
  40. 40. 6. Page order Provide visible focus HTML “Focus First” : a:focus, a:hover, a:active Android: setVisibility(int) Ensure a logical page order Set a logical code order Android: setFocusable (), isFocusable (), requestFocus () Important for touch screen as well Swipe up or down to navigate components Swipe left or right to navigate all items (= arrow keys on desktop)
  41. 41. 7. Focus Provide enough ‘read-tap symmetry’ Touch targets should be large enough Jacob Neilson 9.2-9.6mm minimally Provide 1mm inactive space around elements Beware: Pixel density changes per handset
  42. 42. 8. 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
  43. 43. 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
  44. 44. Bbciplayer showing subtitles
  45. 45. 9. Multimedia: Supported on iPad and iPhone HTML5 audio Fallback must be provided and video Captions should be provided Source: HTML5 and Accessibility sitting in a tree Bruce Lawson
  46. 46. HTML5 Current mobile browser support is poor No support in mobile screen readers In But The promise of accessibility More accessible forms Audio and video controls Captioning Sectioning elements Introducing HTML5 – Bruce Lawson and Remy Sharp It’s not too early to start experimenting with HTML5
  47. 47. 4 / Responsive design
  48. 48. 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
  49. 49. Responsive design and One website across desktop, tablet and accessibility mobile ‘Responsive’ – a website responds to screen size, orientation and environment A seamless experience But what are the ‘breakpoints?’
  50. 50. 1. Title text and span <title>and <abbr>not supported in Mobile Safari, IDEAL (Android) and Nokia Avoid reliance on <title>text on links Provide information elsewhere <span>works in links but not plain text in Mobile Safari Screen reader support for abbr and span on mobile – iheni.com
  51. 51. 2. Grouping links 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>Holby City</p> </a> Visible outline not shown using Voiceover and Mobile Safari but it behaves as one touchzone
  52. 52. 2. Structure Should structure be consistent across desktop, tablet and mobile? Not always feasible Not always preferable Structure may ‘collapse’ Plan underlying code structure during wireframing
  53. 53. Desktop – Smashing magazine
  54. 54. Tablet
  55. 55. Mobile
  56. 56. WAI ARIA and Mobile Safari 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
  57. 57. 5 /Test
  58. 58. 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
  59. 59. Testing tools for HTML Browser based Firebug FireEyes FireFox user agent switcher Online tools Opera Emulator Opera TV emulator Opera Dragonfly remote debugger W3C mobileOK Device specific iOSxCode
  60. 60. 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
  61. 61. FireEyes
  62. 62. W3C mobileOK Checker
  63. 63. Testing Android 1.6 up Android Enable accessibility: Menu > settings > Text-To-Speech Talkback IDEAL Web Browser Android Accessibility Android 4 Enable accessibility by drawing a rectangle Talk is cheap, screen reader testing on Talkback built in mobile (http://www.iheni.com/talk-is-cheap- Still no accessible browser screen-reader-testing-on-mobile/) Explore by touch
  64. 64. Testing iOS: Accessibility Inspector (xCode) iPhone/iPad web and app accessibility – Paul Adams
  65. 65. 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 to test Users rarely just tap around the screen Tests logical structure Forms fields and associated labels Page order
  66. 66. Quick tests with mobile 1. All functional/content related elements have an alternative screen readers 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 Top ten tests for alternatives on mobile on iheni.com 2. Changes of state are announced
  67. 67. There is no substitute for testing with users with disabilities on mobile
  68. 68. 6 / Next
  69. 69. / Guidelines Agnostic mobile accessibility guidelines with device specific techniques
  70. 70. / Strategy Build an accessible HTML mobile website then add accessible native apps
  71. 71. / Build Create shared inventories for alternatives, headings and labels
  72. 72. /Test Talk is cheap
  73. 73. / Next Share
  74. 74. Thank you @iheni
  75. 75. One web

Editor's Notes

  • Image of tins
  • Add images from flickr
  • Image of tins
  • Image of tins here?
  • We all have a differing definition of what mobile is so for the purposes of today here is some scene setting
  • Add dates
  • Add URL and references
  • http://www.flickr.com/photos/bdesham/2432400623/
  • BBC iPlayer on iPad
  • Navigation now in a drop down menu (no go button!)No natural H1Stories as H2
  • One web.http://www.flickr.com/photos/psd/2731067095/sizes/l/in/photostream/
  • ×