Mobile Accessibility (MobA11y)

  • 13,899 views
Uploaded on

Making the mobile web accessible

Making the mobile web accessible

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Thank you @allisonhermannphd.

    @voy1 - audio and video is something I hope I will be abel to present on in the future. There's still a lot of work to be done in the area but it's kind of pivotal given how much TV we consume on tablets and mobile.

    Maybe next year at CSUN - you've got me thinking now!
    Are you sure you want to
    Your message goes here
  • Very informative!
    Are you sure you want to
    Your message goes here
  • Very Nice Presentation. Very Glad I found it here. Posted a tweet about it. Thanks for sharing. Looking forward to perhaps your presenting specifically related to audio and video accessibility on multiple devices and how that is shaping up on mobile globally.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
13,899
On Slideshare
0
From Embeds
0
Number of Embeds
6

Actions

Shares
Downloads
261
Comments
3
Likes
42

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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
  • 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/

Transcript

  • 1. Mobile Accessibility Henny Swan #MobA11y
  • 2. Henny SwanAccessibility Hobo /Senior Usability and Accessibility Specialist, BBC@iheniwww.iheni.comhenny@iheni.com
  • 3. Mobile + Accessibility = MobA11y
  • 4. 1 / Mobile accessibility2 / Strategy4 / Build3 / Responsive design5 /Test6 / Next
  • 5. 1 / Mobile accessibility
  • 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. 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. Mobile isby definition Poor lightdisabling Glare Small fonts Poor image and colour support Small keyboards No mouse Touch One hand Screen size
  • 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. Essentialingredients of Web standardsaccessibility Web browser Platform Accessibility API Assistive technology Platform accessibility features Users Nom, nom, Not so nom, nom
  • 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. There’s nothing on iPhone oriPad that you can do that I can’tdo. Stevie Wonder
  • 13. 2 / Strategy
  • 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 – iheni.com
  • 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. 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. WAI ARIA support• iOS 3.2 up – partially supported• Opera Mini 5.0 – partially supported• Opera Mobile 10.0 – partially supported• Android – not supportedSource: whencaniuse.com
  • 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. 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. 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. 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. 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. 3 / Build
  • 24. No definitive, universally accepted set ofmobile accessibility guidelines
  • 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 – iheni.com
  • 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. 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 –iheni.com
  • 28. Mobile Accessibility Guidelines & techniques Coming soon
  • 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. 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. 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. 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. 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. 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. 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. 3. ColourFirefoxMobile Safari
  • 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. 4. Structure:Unique page Ensure page titles are visibletitles 1 2 3Example taken from the iOS YouTubeapp
  • 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. 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. 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. 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. 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. Bbciplayer showing subtitles
  • 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. 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. 4 / Responsive design
  • 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. 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. 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 – iheni.com
  • 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. 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. Desktop – Smashing magazine
  • 54. Tablet
  • 55. Mobile
  • 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 – iheni.com
  • 57. 5 /Test
  • 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. 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. 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. FireEyes
  • 62. W3C mobileOK Checker
  • 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(http://www.iheni.com/talk-is-cheap- Still no accessible browserscreen-reader-testing-on-mobile/) Explore by touch
  • 64. Testing iOS: Accessibility Inspector (xCode) iPhone/iPad web and app accessibility – Paul Adams
  • 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. 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 iheni.com 2. Changes of state are announced
  • 67. There is no substitute for testing withusers with disabilities on mobile
  • 68. 6 / Next
  • 69. / GuidelinesAgnostic mobile accessibility guidelineswith device specific techniques
  • 70. / StrategyBuild an accessible HTML mobile websitethen add accessible native apps
  • 71. / BuildCreate shared inventories for alternatives,headings and labels
  • 72. /TestTalk is cheap
  • 73. / NextShare
  • 74. Thank you @iheni
  • 75. One web