Mobile Accessibility (MobA11y)


Published on

Making the mobile web accessible

Published in: Technology, Health & Medicine
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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
  • BBC iPlayer on iPad
  • Navigation now in a drop down menu (no go button!)No natural H1Stories as H2
  • One web.
  • Mobile Accessibility (MobA11y)

    1. 1. Mobile Accessibility Henny Swan #MobA11y
    2. 2. Henny SwanAccessibility Hobo /Senior Usability and Accessibility Specialist,
    3. 3. Mobile + Accessibility = MobA11y
    4. 4. 1 / Mobile accessibility2 / Strategy4 / Build3 / Responsive design5 /Test6 / 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 modelWhat 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 isby definition Poor lightdisabling Glare Small fonts Poor image and colour support Small keyboards No mouse Touch One hand Screen size
    9. 9. Mobile isby definition Task basedis 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. Essentialingredients of Web standardsaccessibility Web browser Platform Accessibility API Assistive technology Platform accessibility features Users Nom, nom, Not so nom, nom
    11. 11. Platformaccessibility The bridge between applications andAPIs 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 oriPad that you can do that I can’tdo. Stevie Wonder
    13. 13. 2 / Strategy
    14. 14. What devices 1. Assess mobile OS and browsershould I market sharesupport? 2. Review devices in existing company test plans 3. Assess which popular devices support accessibility 4. Establish what devices people are usingEstablishing a mobile accessibility 5. Review laws in your countrystrategy –
    15. 15. Market shareglobally 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. Devicecapability 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 feedbackenabled and supposedly accessible buthow much skill in my fingertips am I goingto need to use this thing?” Web technology supportShould I stay or should I go iPhone– Hugh HTML, CSS, WAI ARIA, FlashHuddy 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 supportedSource:
    18. 18. Graded mobilebrowser Yahoo! Graded Browser Supportsupport 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 topreference 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 primarymobile platform? (2010)Mobile Platform Number of respondents % of respondentsNokia 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 youcommonly 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 8 .6%BlackberryOther 80 6.4%
    22. 22. 21st CenturyCommunications All smartphones sold in the U.S. mustand Video have an accessible web browser byAccessibility Act, October, 2013USA 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 ofmobile accessibility guidelines
    25. 25. Guidelinesrelated • Web Content Accessibility Guidelines (WCAG)to mobileS • 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 accessibilityguidelines –
    26. 26. Device specific Androidmobile Designing for Accessibilityaccessibility Android Accessibilityguidelines Blackberry Best Practice Designing Accessible Applications iOS: Accessibility Programming Guide Nokia/Symbian: User Experience checklist for Touch and Keypad (PDFs)
    27. 27. Agnosticmobile Shared principles with the desktop webaccessibility Equivalenceguidelines Progressive enhancement Responsive design Unobtrusive JavaScript Separation of content and presentation Focus and keyboard tab orderLet the mobile web learn from themistakes of the desktop web –
    28. 28. Mobile Accessibility Guidelines & techniques Coming soon
    29. 29. 1. Supportdevice Use standard controls for native appscapabilities 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 objectThe 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 – LabeliOS 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 FullTrait: Button Trait: Static text Trait: Button screen Trait: ButtonLabel: Play Label: [ 00.07 of 59.37 ] swipe up or Label:/Pause down to adjust Show/HideTrait: 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 devicesImage 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. ColourFirefoxMobile 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 pageheading in iOS apps section No support on mobile
    38. 38. 4. Structure:Unique page Ensure page titles are visibletitles 1 2 3Example taken from the iOS YouTubeapp
    39. 39. 5. Orientationand 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 itemsIMDB 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 iPhoneHTML5 audio Fallback must be providedand 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 readersIn But The promise of accessibility More accessible forms Audio and video controls Captioning Sectioning elementsIntroducing HTML5 – Bruce Lawsonand 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 TheWeb which we view in different ways. Thereis also no Desktop Web. Or Tablet Web.Thank you Stephen Hay, There is no Mobile Web
    49. 49. Responsivedesign and One website across desktop, tablet andaccessibility mobile ‘Responsive’ – a website responds to screen size, orientation and environment A seamless experience But what are the ‘breakpoints?’
    50. 50. 1. Title textand 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 SafariScreen reader support for abbr andspan on mobile –
    51. 51. 2. Groupinglinks 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 andMobile 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, tabindexWAI ARIA support on iOS –
    57. 57. 5 /Test
    58. 58. Types oftesting Specialist tools Debuggers Emulators Extensions User acceptance criteria Personas Scenarios User testing Formal Informal with volunteers Accessibility support testingFinding usability bugs with automatedtesting – Julian Harty, eBay Assistive technology Accessibility settings
    59. 59. Testing toolsfor 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 upAndroid Enable accessibility: Menu > settings > Text-To-Speech Talkback IDEAL Web Browser Android Accessibility Android 4 Enable accessibility by drawing a rectangleTalk is cheap, screen reader testing on Talkback built inmobile( Still no accessible browserscreen-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 andVoiceOver 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 testswith mobile 1. All functional/content related elements have an alternativescreen 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 announcedTop ten tests for alternatives onmobile on 2. Changes of state are announced
    67. 67. There is no substitute for testing withusers with disabilities on mobile
    68. 68. 6 / Next
    69. 69. / GuidelinesAgnostic mobile accessibility guidelineswith device specific techniques
    70. 70. / StrategyBuild an accessible HTML mobile websitethen add accessible native apps
    71. 71. / BuildCreate shared inventories for alternatives,headings and labels
    72. 72. /TestTalk is cheap
    73. 73. / NextShare
    74. 74. Thank you @iheni
    75. 75. One web