Introduction to mobile accessibility - AccessU 2013
33 likes15,150 views
The document discusses the importance of mobile accessibility, emphasizing that designs should prioritize people with disabilities rather than treating them as an afterthought. It highlights the need for inclusive design practices, responsive design principles, and the integration of accessibility features across different mobile platforms. Additionally, it reviews various accessibility technologies and guidelines for mobile applications while stressing the lack of universally accepted standards in mobile accessibility.
![80
Label:"Done,"
back"to…."
Trait:"Bu1on"
Label:"[Program"name,"
Episode"number]"
Trait:"Sta>c"text"
Label:"Sub>tles"
On/Off"
Trait:"Bu1on"
Label:"Enter/
Exit"Full"screen"
Trait:"Bu1on"
Label:"Play"/
Pause"
Trait:"Bu1on"
Label:"["00.07"of"59.37"]"swipe"up"or"
down"to"adjust"
Trait:"Adjustable"
Label:"Show/
Hide"more"
Trait:"Bu1on"
iOS
Labels,
Hints
&
Traits Design
&
Build
Tuesday, 21 May 13](https://image.slidesharecdn.com/introductionmobileaccessibility-130521151549-phpapp01/85/Introduction-to-mobile-accessibility-AccessU-2013-90-320.jpg)
Introduction to mobile accessibility - AccessU 2013
- 1. Henny Swan @iheni | www.iheni.com | henny@iheni.com Introduc)on to Mobile Accessibility Tuesday, 21 May 13
- 2. Me 2 Tuesday, 21 May 13
- 3. Me 2 Tuesday, 21 May 13
- 4. Me 2 Tuesday, 21 May 13
- 5. Me 2 Tuesday, 21 May 13
- 6. Me 2 Tuesday, 21 May 13
- 7. Me 2 Tuesday, 21 May 13
- 8. Me 2 Tuesday, 21 May 13
- 9. Me 2 Tuesday, 21 May 13
- 10. Me 2 Tuesday, 21 May 13
- 11. Me 2 Tuesday, 21 May 13
- 12. Me 2 Tuesday, 21 May 13
- 13. You 3 Tuesday, 21 May 13
- 14. 4 Discovery Design & Build Deploy Tuesday, 21 May 13
- 15. 5 Discovery Design & Build Test Tuesday, 21 May 13
- 16. Who Disabled, ageing, young, legacy tech You What Mobile web, RWD, Apps, Hybrids Pla@orms Devices How Guidelines Technology and device support Test plans 6 Discovery Discovery Tuesday, 21 May 13
- 17. Who 7 Tuesday, 21 May 13
- 18. People first, disability second People not defined by disability People are not defined by assisEve tech May have mulEple or changing impairments Beware disability silos Design for different acEvity flows: I am a first Eme user / I am a repeat user I am on the move I am task focused I am on the sofa Challenge your assumpEons about disabled users 8 Who Discovery Tuesday, 21 May 13
- 19. Design for disability, not in spite of it 9 Who Discovery Tuesday, 21 May 13
- 20. 10 The mul)faceted user Repeat user Task based user First )me user AA ‘Lean back’ user Design for the MulEfaceted User by Stephanie Troeth Tuesday, 21 May 13
- 21. 11 The mul)faceted user Repeat user Task based user Low vision First )me user Old AA Limited data Hard of hearing Screen reader user Mobility Travelling On the sofa ‘Lean back’ user Dexterity Children Tuesday, 21 May 13
- 22. 12 The mul)faceted user Repeat user Task based user Aspergers Low vision First )me user Second language Old AA Limited data Hard of hearing Deaf Poor connec)on Screen reader user Zoom user Blind Voice input user Mobility Travelling On the sofa Depressed Young ‘Lean back’ user Cap)ons Scrolling Dexterity Children Cogni)on Tuesday, 21 May 13
- 23. 13 The mul)faceted user Repeat user Task based user Aspergers Low vision First )me user Second language Old AA Limited data Hard of hearing Deaf Poor connec)on Screen reader user Zoom user Blind Voice input user Mobility Travelling On the sofa Depressed Young ‘Lean back’ user Cap)ons Scrolling Touch Keyboard D Pad Dexterity Children Cogni)on Apps, Hybrid Web Mobile Tablet TV Windows Android iOS... Tuesday, 21 May 13
- 24. I’m going to s=ck with my Nokia C5. I want my mobile to be something that’s mobile, as in I can walk and use it without having to stop. Hugh Huddy, Nokia and Talks user 14 Tuesday, 21 May 13
- 25. Flip phone A phone that flips open and answers automaEcally may be useful for blind, low vision or users with mobility impaired users Monoblock / sEck For people with arthriEs or poor dexterity useful to avoid the need for added movements like sliding or flipping open the phone to use it. 15 Who Discovery Source: www.MobileAccessibility.info Tuesday, 21 May 13
- 26. Slide or slip Useful for people with limited or low vision or who are blind, as they will answer automatically upon sliding open Touch and Smartphone May be useful to people who are deaf or hard of hearing and who use larger screen sizes for texEng or video calling . 16 Who Discovery Tuesday, 21 May 13
- 27. What 17 Tuesday, 21 May 13
- 28. Mobile is by defini)on is disabling 18 Tuesday, 21 May 13
- 29. Screen size iPhone is 1/12 a typical desktop screen size 40 pixel finger is big on small targets Reach Fonts and colour Poor support on older phones Small text Fixed text Input Dexterity and touch Environment and voice Single handed Barriers mulEplied x 10 for diverse users 19 Restric=ons on mobile Discovery Tuesday, 21 May 13
- 30. Mobile is by defini)on is enabling 20 Tuesday, 21 May 13
- 31. Mobile over desktop Faster innovaEon Portability LocaEon services Maps Tailored content Device integraEon Contacts Camera Maps Accessibility support Built in & third party Se[ngs Second screen 21 Opportuni=es on mobile Discovery Tuesday, 21 May 13
- 32. While engaging with content on ne device, e.g. TV, addiEonal contextual informaEon is displayed on a companion device e.e. mobile or tablet EPG The app synchronises content via listening to the TV Select camera angles for awards shows / sport Audio descripEon / Enriched commentary at The Olympic Opening Ceremony Massive opportuniEes for people with disabiliEes Delivery of access services -‐ signing, AD, capEoning Using a device as a remote Shared but tailored experiences 22 Second screening & accessibility Discovery Tuesday, 21 May 13
- 33. While engaging with content on one device, e.g. TV, addiEonal contextual informaEon is displayed on a companion device such as a mobile or tablet EPG The app synchronises content via listening to the TV Select camera angles for awards shows / sport Audio descripEon / Enriched commentary at The Olympic Opening Ceremony Massive opportuniEes for people with disabiliEes Delivery of access services -‐ signing, AD, capEoning Using a device as a remote Shared but tailored experiences 23 Second screen & accessibility Discovery Tuesday, 21 May 13
- 34. ¥Ho 24 PlaSorm accessibility support / seUngs User profiles Voice output Blind, low vision, cogniEve Zoom Low vision, cogniEon, mobility Black & White, Inverse colors, brightness Low vision, cogniEon Headphone Hearing, cogniEon Speak text Low vision, cogniEon Voice input Blind, low vision, cogniEon, mobility External & virtual keyboards Blind, mobility CapEoning Deaf, cogniEon Audio descripEon Blind, low vision Accessibility sePngs & support Discovery Tuesday, 21 May 13
- 35. iOS Accessibility features and API are the most mature Android has some good accessibility features Google are working to improve Current market share favours iOS and Android devices over other vendors BlackBerry Curve smartphones have free BlackBerry Screen Reader Symbian Phones have accessibility features, including text-‐to-‐speech, but pla@orm currently has no accessibility API. Windows Phone 8 Phones appears to have accessibility features but no accessibility API 25 Mobile accessibility landscape Discovery Tuesday, 21 May 13
- 36. Se[ng User Voiceover Blind, low vision, learning and cogniEon Zoom, Large Text Blind, low vision, learning and cogniEon Invert colours Low vision, colour blindness, learning, cogniEon Speak selecEon Low vision, learning and cogniEon Speak auto-‐text Blind, low vision, learning and cogniEon Hearing aid mode Deaf, hard of hearing, deaf blind Guided access Everybody including children &educaEon AssisEve touch Mobility iOS accessibility sePngs Discovery Tuesday, 21 May 13
- 37. Speech output Available in 36 languages Supports zoom and VoiceOver iOS6 + Gesture and explore by touch Supports Braille output 27 iOS VoiceOver Discovery Tuesday, 21 May 13
- 38. 1. Triple click the Home key to acEvate 2. Dial to open the Web Rotor 3. Swipe up/down to navigate parts 4. Swipe right/led for next/previous content 28 iOS VoiceOver Discovery Tuesday, 21 May 13
- 39. Explore by touch Drag finger across screen Items read by VO Double tap to acEvate Gestures Swipe up/down to jump secEons Swipe right/led for next/previous content Rotor Web and Apps: Lines, Links, Form Controls, Tables, Lists, Landmarks, Non-‐Visited Links, Bugons, Text Fields, Images, StaEc Text, Zoom, In-‐page links, Search Fields, Same Item, Headings, Speech Rate, Volume, Hints (on/off), Characters, Words, VerEcal NavigaEon, PunctuaEon Apps: Headings, Speech Rate, Volume, Hints (on/off), Characters, Words, VerEcal NavigaEon, PunctuaEon 29 Naviga=ng with iOS VoiceOver Discovery Tuesday, 21 May 13
- 40. 30 iOS VoiceOver gestures Gesture Func)on Switch VO on/off Triple click the home key Speak an element Single tap pAcEvate an element Double tap Open the Rotor Turn a dial Zoom 3 finger double tap -‐ iOS6+ only Next secEon in Rotor Swipe up/down Next/previous item in content order Swipe right/led Pass through gesture (drag & drop) Double tap hold Play/Pause 2 finger double tap Discovery Tuesday, 21 May 13
- 41. 31 3 finger triple tap Screen curtain Tuesday, 21 May 13
- 42. 32 iOS clip Discovery Tuesday, 21 May 13
- 43. Se[ng User Voice output Blind, low vision, learning and cogniEon HapEc feedback Blind, Deaf-‐Blind, Low vision, deaf Large text Low vision, cogniEon, learning Speak passwords Blind, low vision, cogniEon, learning Enhance web accessibility Blind Android accessibility sePngs Discovery Tuesday, 21 May 13
- 44. Force enable zoom Text size Text scaling Zoom on double-‐tap Minimum font size Inverted colours Contrast A useful ‘screen curtain’ equivalent Shades app can also do this 34 Android na=ve browser sePngs Discovery Tuesday, 21 May 13
- 45. NaEve browser (Webkit) Poor support for screen readers Ideal Web Reader Self voicing thin client Browser, text messages, contacts, phone Chrome (4+) Zoom on links Force enable zoom Firefox Quick navigaEon keys Find in page 35 Browsers on Android Discovery Tuesday, 21 May 13
- 46. Quick navigaEon keys Requires a physical keyboard, bluetooth connected or Eyes-‐free keyboard Arrow around browser content Don’t work with the browser UI Don’t work when focus is on entry or password field in a form Explore by touch also supported 36 Firefox on Android Discovery Tuesday, 21 May 13
- 47. Support Gingerbread 2.3-‐ very basic Ice Cream Sandwich 4.0 a bit beYer Jelly Bean 4.1+ much beYer Screen readers TalkBack Spiel Mobile Speak Mobile Reader All available from the Play Store 37 Speech output on Android Discovery Tuesday, 21 May 13
- 48. Pre Ice Cream Sandwich Download Talks Enable WebScripts via Settings > Accessibility > ‘Enable Accessibility’ Download the Eyes Free Keyboard Browsing Voice output sEll not well supported Can use Firefox for tesEng ApplicaEons Talkback well supported Beware hybrid content Maps, adverts, Terms and CondiEons, Help pages etc 38 Naviga=ng with Android Talkback Discovery Tuesday, 21 May 13
- 49. 39 Android clip Discovery Tuesday, 21 May 13
- 50. Play)me! 40 iOS Triple click the Home Key Se[ngs > General Accessibility > VoiceOver ON Android Se[ngs > Accessibility > Talkback on Tuesday, 21 May 13
- 51. How 41 Tuesday, 21 May 13
- 52. Mobile website A separate mobile Website Different user experience -‐ good or bad thing? Responsive website A site that adapts screen size and content Widest potenEal reach NaEve app Pla@orm specific applicaEons Benefits from device capabiliEes May contain Web content Beger accessibility support Hybrid NaEve and Web Easier to maintain 42 Delivery Discovery Tuesday, 21 May 13
- 53. Stand-‐alone mobile apps will only be considered once the core web service works well on mobile devices, and if specifically agreed with the Cabinet Office. UK Government Digital Strategy We are not ‘appy, not ‘appy at all 43 Tuesday, 21 May 13
- 54. No internaEonally accepted, independent set of guidelines (a la WCAG) for mobile FragmentaEon within mobile No ‘Baseline browser’ support for mobile Mobile Web Best PracEces agempted it with the Default Delivery Context Usable screen width - 120 pixels, minimum. Markup language support - XHTML Basic 1.1 Character encoding - UTF-8 Image format support - JPEG GIF 89a. Maximum total page weight - 20 kilobytes. Colours - 256 colours, minimum. Style Sheet Support - CSS Level 1 and CSS Level 2 @media Scripts - No support for client side scripting. 44 Guidelines and resources Discovery Tuesday, 21 May 13
- 55. W3C WAI Mobile Web Best PracEces (MWBP) Web Content Accessibility Guidlines (WCAG Shared experiences: Barriers common to mobile device users and people with disabiliEes Mobile Accessibility Overlap Mapping between MWBP and WCAG Independant User Interface (Indi UI) Working Group -‐ Indie Events 1.0 -‐ Indie UI User Context 1.0 Android Android UI accessibility Android Design Pagerns Accessibility Android Training: ImplemenEng Accessibility Android: Developing Accessible ApplicaEons Google Eyes Free Project 45 Guidelines and resources Discovery Tuesday, 21 May 13
- 56. iOS iOS Human Interface Guidelines Accessibility for iPhone and iPad apps by Mag Gemmal Nokia Nokia user experience for touch checklist (PDF) Nokia user experience checklist for keyboard Windows Mobile Design Guidelines for Windows Mobile Touch InteracEon Design OrganisaEonal Funka.nu BBC Mobile Accessibility Guidelines 46 Guidelines and resources Discovery Tuesday, 21 May 13
- 57. Challenges 2010 Products developing in silos No globally accepted guidelines BBC Accessibility Standards and Guidelines didn’t cover mobile or apps Mobile more divers and faster changing than desktop No graded mobile browser support (Yahoo! and BBC) EvoluEon Technology specific guidelines vs technology agnosEc guidelines Built around how teams work Built to cross reference BBC Global Experience guidelines and Editorial Guidelines Benefits Consistency across products Consistency across Web, Hybrid and NaEve apps Beger labelling 47 BBC Mobile Accessibility Guidelines Discovery Tuesday, 21 May 13
- 58. 71 technology agnosEc standards and guidelines Standard = testable Guidelines = not easily tested, aspiraEonal Technology specific techniques and examples HTML Android iOS EvaluaEon criteria Steps VerificaEon criteria 48 BBC Mobile Accessibility Guidelines Discovery Tuesday, 21 May 13
- 59. Define a delivery context Mobile site, responsive, app, hybrid Define supported devices Reference pre-‐exisEng test plans What devices have accessibility support? What devices have accessible naEve browsers? What devices are easy to upgrade/free assisEve support Are any accessible devices missing? Establish version support matrix Analyse web stats % users < than 1% Assess regional preferences Assess laws Locally Globally Research user preferences 49 Device support plan Discovery Tuesday, 21 May 13
- 60. BB Decision Tree for Degrada=on of Browser Versions, BBC Browser support Guidelines 50 Browser support Tuesday, 21 May 13
- 61. 51 Webaim Screen Reader Survey 2012 Discovery Tuesday, 21 May 13
- 62. 52 Webaim Screen Reader Survey 2012 Discovery iOS device usage is significantly increasing and well above the standard populaEon Screen reader users represent a notable porEon of the iOS device user market Usage of Android devices is well below that of non-‐disabled user In the past 17 months: iOS devices increased from 32.6% to 58.5% Android usage increased slightly from 4% to 7.9% Nokia device usage fell drasEcally from 42.4% to 20.3% Tuesday, 21 May 13
- 63. 53 Law Discovery 21st Century Act, USA. By 2013 smartphones: must have an accessible browser must be accessible at the OS level must have free or of “nominal cost” soluEons ImplicaEons North American mobile market influenEal globally Apple, Google, Microsod, RIM SecEon 508 Refresh ‘informaEon and communicaEon technology’ must be WCAG 2.0 compliant Tuesday, 21 May 13
- 64. Breakout session: Put together a Mobile Accessibility Strategy 1. What mobile devices, plaEorms and access tech would you support? 2. How would you maintain and keep this up to date? 54 Tuesday, 21 May 13
- 65. 55 Discovery Design & Build Deploy Tuesday, 21 May 13
- 66. 56 Responsive design and accessibility ‘Responsive’ means design and development should respond to the person’s behaviour and environment based on screen size, platform and orientation. By definiEon accessibility should be complemented by responsive design. What do you think the benefits of responsive design are on desktop? Design & Build Tuesday, 21 May 13
- 67. 57 Responsive design overview Responsive design Creates a core experience Allows content and funcEonality to adapt to screen size and device capability Uses CSS3 media queries to enhance fluid layouts One code base Easier to maintain Beger consistency, familiarity and ease of use Generally more task based = geared towards diverse users Progressive enhancement Mobile first Data driven design Core content is HTML, HTML5 Design & Build Tuesday, 21 May 13
- 68. 58 Responsive design overview Use Web Standards as intended Supports accessibility Supports interoperability For example code a bugon as a bugon not a styled link Screen readers announce traits i.e. bugons, link, image etc User expectaEon is a link opens a resource, a bugon triggers an acEon On Desktop ENTER is used for links, SPACEBAR for bugons Use standard controls over custom implementaEons Vulnerable to accessibility failures e.g. incorrect traits May require non standard user input which leads to usability fails for diverse users Detect features, not devices Design & Build Tuesday, 21 May 13
- 71. 61 Responsive design overview “Cu[ng the mustard” (BBC Responsive news) Impossible to test across all browsers on desktop and devices Hard to keep up -‐ mobile contracts update every 12-‐18 months New browsers come in to play every day Websites accessed globally Design & Build HTML5 browsers IE9+ Firefox 3.5+ Opera 9+ Safari 4+ Chrome 1+(?) iPhone and iPad iOS1+ Android phones and tablets 2.1+ Blackberry OS6+ Windows 7.5+ Mobile Firefox (all versions?) Opera Mobile (most versions?) HTML4 browsers IE8-‐ Blackberry OS5-‐ Nokia S60 v6-‐ Nokia S40 (all versions) All other Symbian variants Windows 7 phone (pre-‐Mango) …and many more that are too numerous to men=on Tuesday, 21 May 13
- 72. 62 iOS development overview Use standard UIKit components AutomaEcally accessible to VoiceOver Traits pre-‐assigned Hints, where necessary, pre-‐assigned Only need to customise the label UIKit components offer roughly 80% accessibility. The other 20% is very much around making what is accessible usable Progressively enhance with new accessibility features in later versions Design & Build Tuesday, 21 May 13
- 73. 63 iOS development overview Interface Builder, accessibility panel Allows you to enable accessibility Add labels, traits and hints Design & Build Tuesday, 21 May 13
- 74. 64 Android development overview Use standard library components AutomaEcally accessible to TalkBack Correctly idenEfied Only need to customise the label Design & Build Tuesday, 21 May 13
- 75. 65 Principles of mobile accessibility (BBC) Provide core content in an accessible website Use apps on top of this Use web and pla@orm standards as intended e.g. code links as links, not bugons Use standard components NaEvely accessible Use progressive enhancement Support lower end devices Enhance apps with accessibility improvements in device version updates Be consistent and conEnuos Within reason, respect the delivery context Labels Design & Build Tuesday, 21 May 13
- 76. 66 Android design principles Design & Build Enchant me Delight me in surprising ways Real objects are more fun than buYons and menus Let me make it mine Get to know me Simplify my life Keep it brief Pictures are faster than words Decide for me but let me have the final say Only show what I need when I need it I should always know where I am Never lose my stuff If it looks the same it should act the same Only interrupt me if it’s importantMake me amazing Give me tricks that work everywhere It’s not my fault Sprinkle encouragement Do the heavy liiing for me Make important things fast Tuesday, 21 May 13
- 77. 67 iOS Human Interface Principles Design & Build Aesthe=c Integrity Aesthe=c integrity is not a measure of how beau=ful an app is. It’s a measure of how well the appearance of the app integrates with its func=on. Consistency Consistency in the interface allows people to transfer their knowledge and skills from one app to another. A consistent app is not a slavish copy of other apps. Direct manipulaEon When people directly manipulate onscreen objects instead of using separate controls to manipulate them, they're more engaged with the task and they more readily understand the results of their ac=ons (mul=touch) hYp://developer.apple.com/library/ios/#documenta=on/userexperience/conceptual/mobilehig/Principles/Principles.html Tuesday, 21 May 13
- 78. 68 iOS Human Interface Principles Design & Build Feedback Feedback acknowledges people’s ac=ons and assures them that processing is occurring. People expect immediate feedback when they operate a control, and they appreciate status updates during lengthy opera=ons. Metaphors When virtual objects and ac=ons in an app are metaphors for objects and ac=ons in the real world, users quickly grasp how to use the app User control People, not apps, should ini=ate and control ac=ons. Although an app can suggest a course of ac=on or warn about dangerous consequences, it’s usually a mistake for the app to take decision-‐making away from the user. Tuesday, 21 May 13
- 79. 69 Alterna=ves Needed for Images, objects, elements Media e.g. capEons, audio descripEon, transcripts Editorial Short, concise, descripEve Important informaEon first Avoid similar alternaEves for different funcEonality e.g. ‘Play’ and ‘Playlist’ FuncEon over content e.g. ‘Contact us’ not ‘Picture of a mobile phone’ Describe image type if appropriate ‘Portrait of...’ ‘Cartoon of...’ Ownership Editorial MarkeEng -‐ this is branding ader all Design & Build Tuesday, 21 May 13
- 80. 70 Alterna=ves & HTML Always provide an alt agribute alt=”Super useful alt text provided by marketing no less!” alt=”” ensures image is ignored by assisEve tech title and abbr Desktop Unavailable to some screen readers on desktop Unavailable to keyboard only users Mobile Unavailable visually on touch Not recognised by speech output on mobile Design & Build Tuesday, 21 May 13
- 81. 71 Alterna=ves & Android Assign contentDescription to all user interface components e.g. ImageButton ImageView CheckBox DecoraEve images should not have contentDescription Design & Build Tuesday, 21 May 13
- 82. 72 Alterna=ves & iOS Implement basic accessibility On all meaningful content and funcEonality Enables VoiceOver to voice and interact with the element via xCode a. Call the view’s setter method setIsAccessibilityElement:YES b. Override the view’s isAccessibilityElement method and return YES via Interface Builder, Accessibility Panel a. Select the object b. Check “Accessibility – Enabled” c. Assign a Label Design & Build Tuesday, 21 May 13
- 83. 73 Alterna=ves & iOS Assign accessibilityLabel to all user interface components Must start with a capital Must not end with a period (.) Must not include informaEon about the type of object i.e. ‘Play’ not ‘Play bugon’ Design & Build Tuesday, 21 May 13
- 84. 74 Alterna=ves & iOS Assign accessibilityTrait to all user interface components Traits describe control type or behaviour Control types are mutually exclusive and describe the nature of the item More than one behaviour trait can be used to describe what items do Design & Build Tuesday, 21 May 13
- 85. Trait DescripEon Bugon Used for acEons i.e. Play, Add, Download, Favourite Link Use to open views, pages resources Search field Search Keyboard key Used on controls which insert predefined text for example iOS traits for Type Design & Build Tuesday, 21 May 13
- 86. 76 BuYons or links? Design & Build Tuesday, 21 May 13
- 87. Trait DescripEon StaEc text Text that is readable but not selectable Image If image is interacEve combine with Bugon or Link Plays sound Used with bugon traits, mutes of reduces VO volume Selected Used on checkboxes, status read by VO Summary element Describes situaEon or state when an app starts, use sparingly Updates frequently Download progress bars, buffering Not enabled Indicates item is not currently interacEve Starts media session Silences Voiceover, used when recording Adjustable Sliders e.g. volume and Emeline, hint included iOS traits for Behaviour Tuesday, 21 May 13
- 88. Item DescripEon Usage Magic tap accessibilityPerformMagicTap Two finger double tap to perform a key acEon i.e. Pause/Play Trigger play from programme views, answer a call Header accessibilityTraitHeader Turn text into headings. Previously only view headings idenEfied as headings Add headings throughout ALL pages Focus accessibilityLayout ChangedNoEficaEon (or Screen) Set focus on anything other than first item in content order Set focus on the heading and NOT the Back/Done bugons Announcement accessibilityAnnouncment Force VO to say something when an acEon is complete Visual cue also needed as an alternaEve for non VO users Grouping shouldGroupAccessibilityChildren Groping related items Parent child relaEonships iOS traits for Behaviour Tuesday, 21 May 13
- 89. 79 Alterna=ves & Hints accessibilityHints may be used to provide further informaEon Describes what an element does Must not include informaEon about the objects type (i.e. Trait) Use sparingly and not for key informaEon Must be a descripEon not a command e.g. ‘Deletes programme’ not ‘Delete programme’ Design & Build Tuesday, 21 May 13
- 90. 80 Label:"Done," back"to…." Trait:"Bu1on" Label:"[Program"name," Episode"number]" Trait:"Sta>c"text" Label:"Sub>tles" On/Off" Trait:"Bu1on" Label:"Enter/ Exit"Full"screen" Trait:"Bu1on" Label:"Play"/ Pause" Trait:"Bu1on" Label:"["00.07"of"59.37"]"swipe"up"or" down"to"adjust" Trait:"Adjustable" Label:"Show/ Hide"more" Trait:"Bu1on" iOS Labels, Hints & Traits Design & Build Tuesday, 21 May 13
- 91. 81 Tests -‐ alterna=ves Test 01 Switch on speech output 02 Navigate to images, elements and objects either by 02.1 Explore by touch (Android/iOS) * 02.2 SelecEng Images/bugons from the Web Rotor and swiping up/down (iOS)* 03 Verify an alternaEve is provided 04 Verify the alternaEve accurately describes the content or funcEon Expected results Each meaningful images element and object has an alternaEve AlternaEves describe either the content of a non-‐funcEonal image, element or object the funcEon of an acEonable image, element or object Design & Build Tuesday, 21 May 13
- 92. 82 Colour & Contrast What is an appropriate contrast raEo for mobile? WCAG AA contrast of 4.5:1 MWBP Default Delivery Context -‐ 256 colour minimum Nokia design guidelines 5:1 BBC Mobile Accessibility Guidelines exceed WCAG AA, close to AAA, 7.1 Challenge for RWD Contrast raEo of 7.1 v’s brand and markeEng Works beger on devices than desktop -‐ considered too restricEve IndicaEng links with colour Design & Build Tuesday, 21 May 13
- 93. 83 Tests -‐ colour contrast Test 01 Select samples of text and links by 01.1 Checking contrast during UX (see 0.3) 01.2 Taking a screenshot (Home+power bugon on iOS/ Power and volume bugon on Android) and email or syncing the picture to a desktop Analyser. 03 Verify the luminosity and contrast requirements are met via the Colour Contrast Analyser* Expected results 01 Contrast between text and background meet minimum colour contrast (luminosity) raEo requirements indicated by the requirements * Any colour contrast checker can be used but only one used as a benchmark Design & Build Tuesday, 21 May 13
- 94. 84 Colour & Meaning Provide alternaEves for colour and meaning Visually Font weight Line weight Borders Gradients Art style Colour intensity Subtle animaEons Audibly Announce changes of state Design & Build “Selected, TV, tab, one of 5” Tuesday, 21 May 13
- 95. Firefox Mobile Safari Colour & Meaning Design & Build Tuesday, 21 May 13
- 96. Firefox Mobile Safari Colour & Meaning Design & Build TEST ON REAL DEVICES! Tuesday, 21 May 13
- 97. 87 Tests -‐ colour & meaning Test 01 AcEvate speech output / invert colours 02 Locate images, objects and elements that use colour 03 Determine if colour is the sole means of communicaEng informaEon 04 Verify speech output announces the meaning conveyed with colour there is an alternaEve visual means of indicaEng meaning Expected results Colour used to convey meaning is announced by screen readers Colour used to convey meaning is indicated visually without colour Design & Build Tuesday, 21 May 13
- 98. 88 Touch Standard touch target size of 7-‐10mm Jacob Neilson recommends 9.2 -‐ 9.6mm Android Touch target size of 48dp/9mm Spacing between UI elements 8dp iOS Touch target size of 44px / 44px tall PosiEoning Provide 1mm inacEve space around elements Balance enough informaEon density and targetability of UI Elements PosiEon content appropriately Design & Build Android Tuesday, 21 May 13
- 99. 89 Tests -‐ touch target size Test 01 IdenEfy touch targets 02 Measure size 03 Verify the size meets the requirements Expected results All touch targets meet or exceed the minimum requirement When should this test be carried out? Design & Build Tuesday, 21 May 13
- 100. 90 Touch Spacing and read-‐tap symmetry Balance informaEon density and targetability of UI Elements Spacing between groups of links e.g. www.bbc.co.uk/tv Design & Build Mobile Desktop Tuesday, 21 May 13
- 101. 91 Touch Group links to the same resource Larger touch zone Less audible repeEEon for screen reader users Less swiping needed = less physical overhead Design & Build Tuesday, 21 May 13
- 102. 92 Touch Grouped links with HTML Treated inconsistently by screen readers Some only announce the first element Some only announce the heading Depends on reading mode (tabbing, read all, arrowing) Main concern is VoiceOver repeats the link Basic rule: place key informaEon first Accessibility and HTML5 block level links -‐ Simply Accessible Design & Build <a href="http://feathermelbourne.eventbrite.com/"> <h3 class="summary">Melbourne</h3> ! <span><em>Supported by WIPA</em></span> ! <span>July 25, 2011</span> ! <span class="button">Purchase Tickets</span> ! <img src="star.png" title="Melbourne" alt="" /> </a> Tuesday, 21 May 13
- 103. 93 Tests -‐ Grouped links Test 01 AcEvate the screen reader 02 Navigate to acEve screen objects, elements, and controls that have textual and image components 03 Verify that the text is not announced twice 04 Verify that there are not two equivalent acEonable items announced for each item Expected results Object, elements, and controls with images and text labels are announced only together Design & Build Tuesday, 21 May 13
- 104. 94 Touch Consider reach One handed Important content bogom led to right Design & Build Luke Wroblewski’s book Mobile First Tuesday, 21 May 13
- 105. 95 Best PracLces: Designing Touch Tablet Experiences for Pre Schoolers Source: hYp://www.sesameworkshop.org/assets/1191/src/Best%20Prac=ces%20Document%2011-‐26-‐12.pdf Tuesday, 21 May 13
- 106. 96 Touch -‐ most intui=ve gestures Tap Universally familiar Draw / Move finger SomeEmes hard not to lid a finger Can also support parEal compleEon Swipe Provide visual indicaEons of where to swipe Consider using swipe and tap on an arrow Design & Build xxxx Tuesday, 21 May 13
- 107. 97 Touch -‐ most intui=ve gestures Drag Possible difficulEes with on-‐screen-‐finger-‐conEnuity Can support parEal compleEon Slide Less familiar than dragging Needs explicit instrucEons e.g., VO, strong visual indicaEon of end point, a large hotspot, supporEve/explicit highlighEng Design & Build “Familiar faces to take you new places” Tuesday, 21 May 13
- 108. 98 Touch -‐ least intui=ve gestures Pinch Needs good dexterity Use it on non-‐essenEal acEons Tilt/Shake Tablet size and weight make it hard to control Limit it to smaller devices MulE-‐Touch MulEple fingers on screen at once Oden used unintenEonally, limited dexterity Flick/Fling Use interchangeably with tap/and or drag Double Tap Children expect immediate response Use it to prevent accidental navigaEon e.g. leaving an acEvity Design & Build Tuesday, 21 May 13
- 109. 99 Zoom Support pinch zoom Avoid <meta content=”width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=1;” name=”viewport”> Use <meta content=”width=device-width; initial-scale=1.0; maximum-scale=2.0; user-scalable=1;” name=”viewport”> iOS bug: Scale and orienta=on Jeremy Keith Design & Build Tuesday, 21 May 13
- 110. 100 Structure and content order Android No means (that I am aware of) to indicate headings, lists etc Content order needs to be hard coded iOS iOS 3 -‐ 5 only the screen Etle was announced as a heading iOS 6 accessibilityTraitHeader Content order handled naturally but can be hard coded HTML Structure and content order are a core component accessibility Same rules as desktop Design & Build Tuesday, 21 May 13
- 111. 101 Structure and content order Headings and lists H1 to H6 OL and UL NavigaEon to headings and the start of lists for screen readers Seven plus or minus 2 The opEmum number humans process informaEon In taxonomy this translates to 5-‐9 headings Headings as lists Content under a heading may be removed on mobile Consider lists over headings Avoid mixing both Design & Build Tuesday, 21 May 13
- 112. 102 Structure and content order WAI ARIA Landmarks application, banner, complementary, contentinfo, form, main, navigation, search NavigaEon to parts of a page, for screen reader HTML5 secEoning elements body, section, nav, article, aside, hgroup, header, footer, address, main Not well supported by desktop or mobile screen readers Design & Build Tuesday, 21 May 13
- 113. 103 Structure and content order Screen readers announce Landmarks differently Jaws “NavigaEon region start” / “NavigaEon region end” NVDA 2012.3 “NavigaEon region start” nothing at the end iOS VoiceOver “Landmark start” / “Landmark end” but announces next item in the content order TalkBack “NavigaEon” but nothing at the end Design & Build Tuesday, 21 May 13
- 114. content a logical order provide 104 Tuesday, 21 May 13
- 115. provide a logical content order 105 Don’t make your content sound like Yoda Tuesday, 21 May 13
- 116. 106 Iden=fy Landmarks Content order Place Landmarks before the relevant heading Heading can be visible or hidden aria-‐label <role="navigation" aria-label="Channels"> Design & Build Tuesday, 21 May 13
- 117. 107 Responsive landmarks Tuesday, 21 May 13
- 118. 108 Responsive landmarks Tuesday, 21 May 13
- 119. 109 Landmarks & collapsed naviga=on Closed Open Design & Build VoiceOver / TalkBack says: “Landmark start, Channels navigaFon, Open Menu, BBC One, BBC Two, BBC Three, BBC Four, TV Guide, A-‐Z, Categories, Arts, CBBC...” Tuesday, 21 May 13
- 120. 110 Landmarks & collapsed naviga=on Closed Open Design & Build left: -999em; position: absolute VoiceOver / TalkBack says: “Landmark start, Channels navigaEon, Open Menu” or “Open Menu” Tuesday, 21 May 13
- 121. 111 Structure and content order ConsideraEons for responsive Structure originates with UX (or we might as well all go home...) Mobile first -‐ adding in is easier than subtracEng Balance informaEon and verbosity Annotate UX Headings, lists, landmarks Content and focus order Keyboard / swipe interacEon Focus states Summary An H1 follows role=“main” and the main content follows an H1 An H2/3/4 follows role=“complementary” An H2 (3/4) follows role=“navigation” Duplicated links grouped in one <a href> Design & Build Tuesday, 21 May 13
- 122. 112 Responsive naviga=on One Responsive Barlesque BBC Framework including the header and footer Design & Build Tuesday, 21 May 13
- 123. 113 Responsive naviga=on -‐ case study Structure Landmarks -‐ Banner, NavigaEon and Search Hidden headings -‐ H2 Accessibility links, H2 BBC.co.uk navigaEon Visible focus Strong, branded visible focus Design & Build Tuesday, 21 May 13
- 124. 114 Responsive naviga=on Issues Search repeated 3 times -‐ landmark, label, placement text “BBC.co.uk navigation” makes no sense Design & Build Tuesday, 21 May 13
- 125. 115 Responsive naviga=on More panel Added hidden span to “More” i.e. “Open More BBC sites” / “Close More BBC sites” Set focus to first item in the list “TV” Panel remains open until closed More is an H2 inside the panel Design & Build Tuesday, 21 May 13
- 126. 116 Responsive skip links Do they have a place on mobile? On touch screens they feel redundant Not necessary for collapsable navigation Possibly necessary on keypad devices Design & Build Tuesday, 21 May 13
- 127. 117 Clear naviga=on Page Etles content or purpose of the screen Act as a reverse breadcrumb Avoid Done/Back Design & Build 2 3 1 YouTube iOS App Tuesday, 21 May 13
- 128. 118 Forms Use programmaEcally readable instrucEons Add ‘required’ to the <label> <label for="name">Your Name (required)</label> Progressively enhance with HTML <input type=“text required> (iOS5+) Using both techniques do not result in ‘required’ being read twice Design & Build Tuesday, 21 May 13
- 129. 119 Keyboard focus Don’t forget keyboard users, D-‐Pad users and external keyboard users HTML Provide a logical code order PosiEve and negaEve tab order not well supported on iOS and Android Be aware of this for responsive sites Design & Build Tuesday, 21 May 13
- 130. 120 Keyboard focus -‐ Android Enable focus-‐based navigaEon on components: android:focusable="true” setFocusable isFocusable RequestFocus Force focus order if it is not logical: nextFocusDown nextFocusLeft nextFocusRight nextFocusUp Design & Build Tuesday, 21 May 13
- 131. 121 Keyboard focus -‐ visible iOS No means of providing a focus (that I’m aware of) Android Provided by default for standard controls Must be added to custom controls using style sheets state_focused=“true” HTML, think ‘focus’ first a:hover, a:focus, a:active { background-color: #ff9; } Design & Build Tuesday, 21 May 13
- 132. 122 No=fica=ons NoEficaEon may be necessary due to Layout changes Content removal due to orientaEon changes i.e. a menu opens in Layout List of links may change to drop downs Use standard platform notifications Familiar behaviour across apps Baked in accessibility Ensure there are both visual and audible notifications How Only notify the user if changes are not self evident ARIA announcements System alerts iOS -‐ UIAccessibilityLayoutChangedNotification Android -‐ update the contentDescription Design & Build Tuesday, 21 May 13
- 133. 123 Screen reader detec=on Detect if a screen reader is running Hide content specifically for sighted users i.e. splash screen instrucEons Serve alternaEves i.e. a video player that doesn’t autoplay Use rarely HTML Not possible iOS UIAccessibilityIsVoiceoverRunner Android isScreenReaderActive Design & Build Tuesday, 21 May 13
- 134. Breakout session: How accessible is Facebook and how would you fix it? 1. HTML 2. Android 3. iOS 124 Tuesday, 21 May 13
- 135. 125 Discovery Design & Build Deploy Tuesday, 21 May 13
- 136. 126 Workflow Discovery RWD, hybrid, naEve app etc Device support plan Test plan In house, technical, user, automated Secure and allocate budget early on DefiniEon Requirements Guidelines: pre-‐exisEng, internal, customised Who owns what (originates with, implemented by) User stories Sign off process Training requirements Editorial, UX, Development, QA teams Deploy Tuesday, 21 May 13
- 137. 127 Workflow DefiniEon conEnued Wireframes Annotate for structure, content order, keyboard interacEon Done by UX collaboraEng with development UX Review and document Deploy DefiniEon of Done -‐ ensure accessibility is one aspect Minimal Viable Product Maintenance plane Deploy Tuesday, 21 May 13
- 138. 128 Defini=on of Done Code adheres to internal code standards Core content adheres to accessibility requirements Content passes Automated tests User tests Manual tests User Acceptance Criteria Core content is available to Available to screen readers Available with colours inverted Usable with zoom Usable with screen readers and zoom Usable without JavaScript Deploy Tuesday, 21 May 13
- 139. 129 Minimal Viable Product All core content and funcEonality is Available to screen readers Available with colours inverted Usable with zoom Usable with screen readers and zoom Not reliant on JavaScript ExempEons Pixel perfecEon FuncEonality the offers an alternaEve route to already accessible core content Effects, animaEons, transiEons AddiEonal features can be added later i.e. font switchers if content is already flexible “Beauty is only skin deep” -‐ Me Deploy Tuesday, 21 May 13
- 140. 130 My rule of thumb Any relaunch exceeds exisEng levels of accessibility Version one has no Showstopper/Blocker issues and all other issues prioriEsed in the Backlog Showstopper = affects producEon so adversely that it must be fixed or addressed immediately Blocker = This issue blocks further progress or another issue. It may be blocking Release Deploy Tuesday, 21 May 13
- 141. 131 Tes=ng -‐ HTML Responsive design Hard to test for all devices OpEmise then test on the most common devices Tools FireEyes, includes a responsive tesEng features Default user agent switching ValidaEng HTML WebAim Toolbar Deploy Tuesday, 21 May 13
- 142. 132 Tes=ng -‐ Android Android Emulator Virtual device in Android SDK Configurable to mimic different devices Contains a debug console Deploy Tuesday, 21 May 13
- 143. 133 Tes=ng -‐ Android Android Lint Tool Finds missing ContentDescription Finds missing input types on text fields Quick fix window Write custom tests Deploy Tuesday, 21 May 13
- 144. Tes=ng -‐ Android Deploy Tuesday, 21 May 13
- 145. Tes=ng -‐ iOS iOS Accessibility Inspector Displays accessibility informaEon of accessible elements Simulates Voiceover interacEon Runs in the iOS Simulator When running the AI hijacks single click to focus, double click to acEvate A good development tool but not suitable for final tesEng Deploy Tuesday, 21 May 13
- 146. Tes=ng -‐ scenarios Complete keys tasks: with voice output with zoom with voice output and zoom with inverse colours on Mobile Accessibility tests Deploy Tuesday, 21 May 13
- 147. Switch off the screen iOS -‐ Screen Curtain Android -‐ browser se[ngs > Brightness or use Shades Voice output tests Are images labelled? Is content order logical? Are changes of state announced? Are bugons used for acEons? Are links used to open pages? Are form elements labelled? Are appropriate keyboards used? Tes=ng screen reader support Deploy Tuesday, 21 May 13
- 148. Text is readable? Large areas of empty space are not present? Labels and form inputs are not separated by large areas of empty space? Pop ups do not obscure the whole screen? Tes=ng low vision Deploy Tuesday, 21 May 13
- 149. Visible text matches audible labels? Bugons, images of text etc Is visible and voice output focus are in sync? Tes=ng zoom and voice output Deploy Tuesday, 21 May 13
- 150. Is text readable? There is sufficient contrast? Visible navigaEon cues are clear? Meaning is clear? Tes=ng inverse colours Deploy Tuesday, 21 May 13
- 151. 01 Establish a mobile accessibility strategy 02 Define requirements (Guideline, MVP, DOD) 03 Establish test plans 04 Establish training needs 05 Map requirements to wireframes and UX Wrap up Deploy Tuesday, 21 May 13
- 152. To be con(nued... henny@iheni.com 142 Tuesday, 21 May 13