Introduction to mobile accessibility, 2015
22 likes4,805 views
This document outlines a workshop on mobile accessibility led by Henny Swan, focusing on key concepts, user experience, development, and quality assurance for a non-technical audience. It discusses the diversity of disabilities, user personas, barriers to accessibility, and the importance of utilizing standards and guidelines to create inclusive mobile experiences. The workshop also emphasizes practical strategies for designing accessible mobile applications that cater to varying user needs and preferences.
Introduction to mobile accessibility, 2015
- 1. Introduction to mobile accessibility Henny Swan
- 2. This is a full day workshop I gave at AccessU 2015 and an updated version of the same workshop I gave at AccessU in 2013. As an introduction to mobile accessibility it covers key concepts, user experience, development and some QA. It is intended mostly for a non-‐technical audience who are looking for an introduction to mobile web accessibility and native apps although it does contain some technical guidance. 2
- 3. Agenda • Requirements and planning • User experience • Development • QA and testing 3
- 4. Hand outs and slides • Handouts available now in http://bit.ly/1e0Wn8g • Slides to follow • Follow @iheni for URLS • All questions are good questions • Today is about sharing 4
- 5. Henny Swan • User Experience and Design Lead, The Paciello Group • Formally BBC, Opera Software, Royal National Institute of Blind People • Specialize in accessible user experience, mobile, media players, strategy • Member of W3C Mobile Accessibility Task Force. User Agent Accessibility Working Group and Web of Things Task Force
- 6. You • Name • Company • Role • Your experience of accessibility • Device
- 8. Audience: who Diversity in disability: • Type of impairment(s) • Severity of impairment(s) • Circumstances of acquisition of impairment(s) • Changeable impairment(s) 8
- 9. Audience: who Diversity in disability: • Assistive technology and settings* used: • Vendor • Version • Configuration • Aptitude in using AT • Attitude to using AT * Assistive technologies include screen readers, zoom, text resizing, voice input, invert colors 9
- 10. Audience: who We all face being impaired: As a child… Unable to hold a tablet Unable to use certain gestures Unable to understand text and iconography As an older user… Reduced sight, hearing, cognition Problems with perception Temporarily Broken wrists, RSI, carpel tunnel Designing touch tablet experiences for preschoolers – Sesame Street 10
- 11. Audience: Personas • Persona resources from the W3C Mobile Accessibility Task Force 11
- 12. Judy Dench Ability: Advanced macular degeneration and mild arthritis Aptitude: Hasn’t really used tech much but realizes she now has to and uses an iPad Attitude: Willing but is too busy to dedicate the time 12
- 13. Gary Numan Ability: Autism Spectrum Disorder. Uses zoom and occasionally VoiceOver when he is tired Aptitude: Uses tablets for news and research, but doesn’t learn new sites easily Attitude: Prefers apps to mobile content and an established routine 13
- 14. Sinead O’Conner Ability: Fatigue from fibromyalgia, touch screens, tapping and scrolling are hard Aptitude: Average user, has good days and bad days Attitude: Wishes the hardware made more sense 14
- 15. Marlee Matlin Ability: Native language is ASL; can speak and read lips; uses SMS/IM, Skype, and video chat Aptitude: Good with graphic tools, and prefers visuals to text; poor spelling makes searching more difficult Attitude: Gets annoyed by lack of subtitles 15
- 16. Stephen Hawking Ability: Suffers from acute Motor Neurons Disease, no movement or speech Aptitude: Super user, patient, curious, but is a busy man Attitude: Tries anything, knows what he wants, determined -‐ this is his only line of communication 16
- 17. Barriers -‐ Input • Dexterity and touch • Single handed • Environment and voice 17
- 18. 18 I’m going to stick 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, blind Nokia and Talks user
- 19. Barriers -‐ orientation • Forced orientation • Mounted tablets • Limited scrolling • Content changes 19
- 20. Barriers -‐ Zoom and text resize • Pinch zoom being disabled • Loss of context • Floating toolbars • Pop ups 20
- 21. Barriers -‐ Zoom 21 • Fixed position content
- 22. Barriers -‐ Zoom 22 • Snap scrolling
- 23. Barriers – cognitive overload • Inconsistent design • Excess clutter • Ambiguous labels • Ambiguous icons • Poor error handling • Where am I?
- 24. Opportunity -‐ platform features • Geolocation • Camera • Contacts • Phone 24
- 25. Opportunity -‐ Web of Things • Home energy management • Healthcare and fitness • Google’s Physical Web • Identity management and authentication • Casting, audio and video control 25
- 26. Web and mobile standards A significant but not exact mapping between desktop and mobile • Touchscreen on both desktop and mobile • Mobile devices with external keyboards • Responsive design • User interface patterns from desktop used on mobile (links, tables, buttons, menus etc) 26
- 27. Legal requirement 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” soluQons ImplicaQons • North American mobile market influenQal globally • Apple, Google, MicrosoU, RIM SecQon 508 Refresh • ‘informaQon and communicaQon technology’ must be WCAG 2.0 compliant 27
- 28. Standards and guidelines W3C guidelines: • Web Content Accessibility Guidelines (WCAG) • How WCAG and UAAG apply to mobile devices • Shared experiences: Barriers common to mobile device users and people with disabilities • Mobile Accessibility Overlap • Independant User Interface (Indi UI) Working Group 28
- 29. Standards and guidelines iOS guidelines: • Accessibility Programming Guide for Developers • Human Interface Guidelines for Designers 29 Android guidelines: • Making applications accessible • Accessibility Developers checklist • Android design: accessibility
- 30. BBC Mobile Accessibility Standards and Guidelines • Technology agnostic • iOS, Android and HTML techniques • Test procedures 30
- 31. 31
- 32. 32
- 33. 33
- 34. Platform and browser support Define the delivery context • Responsive • Native app • Hybrid 34
- 35. Platform and browser support Define supported devices: • Reference pre-‐existing platform and browser support plans • What devices have sufficient accessibility support • What devices have accessible native browsers • What devices are easy to upgrade • Version support 35
- 36. Platform and browser support Define supported devices: • Analyze web stats • Assess regional preferences • Assess local legal requirements • Research user preferences Output: mobile platform and browser support matrix with version support logic 36
- 37. Platform and browser support Webaim screen reader surveys • Surveys screen reader user preferences of web and mobile usage • Every year since 2009 • Open to anyone • 2014 survey results: • 1456 respondents • 61% from the US, 21% UK and EU, Asia 10%… • 95% reported having a disability 37
- 38. WebAim screen reader survey 38
- 39. WebAim screen reader survey 39
- 40. WebAim screen reader survey 40
- 41. TPG 2013 MOBILE SURVEY 41 http://www.paciellogroup.com/mobile/
- 42. Breakout session Write a Mobile Accessibility Strategy for a product including • Product name and purpose • Target audience • Platform, access technology and browser support • HTML, native or hybrid 42
- 44. Mobile accessibility landscape iOS Accessibility features and API are the most mature Android has some good accessibility features Google are working to improve Current market share favors iOS and Android devices over other vendors BlackBerry Curve smartphones have free BlackBerry Screen Reader Windows Phone 8.1 Text resizing, High Contrast mode, Narrator, screen magnificaQon, Zoom 44
- 45. iOS accessibility features 45 Seang User Voiceover Blind, low vision, learning and cogniQon Zoom, Large Text Blind, low vision, learning and cogniQon Invert colors, Grey scale Low vision, color blindness, learning, cogniQon Speak selection Low vision, learning and cogniQon Speak auto-‐text Blind, low vision, learning and cogniQon Hearing aid mode Deaf, hard of hearing, deaf blind Customize closed captions Deaf, hard of hearing, everyone Guided access Everybody including children &educaQon Assistive touch Mobility Switch control Mobility, hands free
- 46. iOS -‐ mapping accessibility shortcuts 1. Go to Settings > General Accessibility > Accessibility Shortcut 2. Select shortcuts 3. Triple click the Home key to activate 46
- 47. iOS -‐ switch support • iOs7+ • Using an external device or FaceTime • Accessed via Settings > Accessibility > Switch control 47
- 48. Switch control in iOS8 -‐ Luis Perez 48
- 49. iOS -‐ VoiceOver • Supports 36 languages • Gesture and explore by touch support • Supports braille output • Excellent browsing support 49
- 50. iOS -‐ activating VoiceOver 1. Triple click the Home key to activate 2. Dial to open the Rotor 3. Swipe up/down to navigate parts 4. Swipe right/left for next previous 50
- 51. iOS -‐ rotor navigation 1. Dial gesture on screen 2. Select how you want to navigate 3. Swipe up or down 51
- 52. 52 Gesture FuncGon Switch VO on/off Triple click the home key Speak an element Single tap pActivate an element Double tap Open the Rotor Turn a dial Zoom 3 finger double tap -‐ iOS6+ only Next section in Rotor Swipe up/down Next/previous item in content order Swipe right/left Pass through gesture (drag & drop) Double tap hold Play/Pause 2 finger double tap iOS -‐ basic VoiceOver gestures
- 53. 53 3 finger triple tap Screen curtain
- 54. 54
- 55. Seang User Voice output Blind, low vision, learning and cogniQon HapGc feedback Blind, Deaf-‐Blind, Low vision, deaf Large text Low vision, cogniQon, learning Speak passwords Blind, low vision, cogniQon, learning Enhance web accessibility Blind Android -‐ accessibility features
- 56. Chrome: Force enable zoom Text size Text scaling Zoom on double-‐tap Minimum font size Inverted colors Contrast A useful ‘screen curtain’ equivalent Shades app can also do this 56 Android -‐ browser settings
- 57. Enable WebScripts via Settings > Accessibility > ‘Enable Accessibility’ Download the Eyes Free Keyboard Browsing Less reliable than iOS ApplicaQons Talkback well supported Beware hybrid content Maps, adverts, Terms and CondiQons, Help pages etc 57 Android -‐ Talkback
- 59. Zoom OS-‐level features • Set default text size • Magnifies entire screen • Magnifying lens view under user's finger • 3 finger scroll 59
- 60. Zoom Browser-‐level features • Set default text size of text in the browser • Reader mode (not universally supported) • Pinch zoom 60
- 61. Zoom Browser-‐level features • Magnifying lens view under user's finger • Force enable zoom (Chrome, Android) 61
- 62. Breakout session Using iOS or Android try using each of the following: • Screen reader • Zoom • Head switch Refer to the handouts which have set up and gesture instructions. 62
- 63. USER EXPERIENCE
- 64. As a user I want… • WCAG Level AA compliance • WAI ARIA • Validated code Said no user ever! 64
- 65. Accessibility and inclusive design Standards and guidelines tend to focus more on: …code over design …output over outcome …compliance over experience 65
- 66. – I A N P O U N C E Y, W E B D E V E L O P E R , B B C “It pains me to say this but web developers might not be the most important people when it comes to making accessible websites and web apps.”
- 67. Principles of accessible UX 67
- 68. People first • Put people before technology • Consider environment and context • Consider first time users and repeat users • Consider AT super users, average users, or basic users 68
- 69. 69 iOS start up screens
- 70. 70 Android start up screens
- 71. Focus Prioritise key features in the layout and content order Remove unnecessary elements Group elements logically, visually and in the content order Progressively reveal content on user request 71
- 72. “ T h e o b v i o u s i s a a b o u t a l w a y s ”
- 74. Focus 74
- 75. Choice Provide multiple ways to: • Access key tasks, screens or information • Complete key or complex tasks • Complete non standard interactions 75
- 76. Choice 76
- 77. Control What ways can user controls over content be suppressed? 77
- 78. Control What ways can user controls over content be suppressed? • Orientation 78
- 79. Control What ways can user controls over content be suppressed? • Orientation • Pinch zoom 79
- 80. Control What ways can user controls over content be suppressed? • Orientation • Pinch zoom • Right click (web) 80
- 81. Control What ways can user controls over content be suppressed? • Orientation • Pinch zoom • Right click (web) Support browser and platform accessibility features 81
- 82. Control 82
- 83. Control iOS7+ closed caption customization: • Font • Size • Color • Background color • Background opacity • Text edge style • Text highlight 83
- 84. Familiarity BBC Radio iOS app’s custom ‘dial’. “Although the 3 finger swipe works for exposing stations, it’s not intuitive… it would be nice if some alternative solution could be implemented as someone new to the app probably wouldn't think of doing that, and of course it should be pointed out that VoiceOver gives no feedback when you do the 3 finger swipe” 84
- 85. Prioritise features that might be of particular value for everyone • Platform features • A to Z, filters, sort, manage, delete • Web of things Value 85
- 87. Value Web of Things • Health • Home • Entertainment 87 • Energy • Education • Security
- 88. Breakout session What features might you add to your product to provide a better user experience for diverse users? 88
- 89. DESIGN
- 90. Color contrast -‐ desktop Based on 15-‐inch monitor at 1024x768 resolution with a 24-‐inch viewing distance WCAG 2.0 recommends: • contrast of 4.5:1, 14pt text • contrast ratio of 3:1 for 18pt+ 90
- 91. Focus states • Use distinctive hover/focus states • Ideally use the same hover state on focus • Selected states must be unique 91
- 92. Visual cues • Navigation must be visually explicit • Distinguish interactive elements 92
- 93. Visual cues What’s wrong with the visual cues on this screen? 93
- 94. Visual cues -‐ iconography Question mark, home, burger for home, disc for save, back arrow etc 94 GridAdd List Menu
- 95. Visual cues -‐ conventional positioning 95
- 96. Positioning -‐ reach • Optimize for use one handed • Important content bottom left to right • Position important content above page scroll 96Mobile First by Luke Wroblewski
- 97. Consistent layout -‐ platforms 97 Netflix on desktop
- 98. Consistent layout -‐ Platforms 98Main menu when open Sign out at the foot of the page
- 100. Keyboard control • Via on screen keyboards and via physical keyboards • On touch, with VO and Talkback running ‘keyboard access’ includes static and hidden content as well as focusable elements • Everything related to content and functionality must be focusable 100
- 101. 101
- 102. Touch events Mouse or touched events prevent unintentional triggers when interacting • Gives mouse users the opportunity to move the cursor outside the element to prevent the event from being triggered • Only triggers elements on touch when the user lifts the finger off the screen, the last position of the finger is inside the actionable element, and the last position of the finger equals the position at touch start 102
- 103. Touch target size 103 “The fingers you have used to dial are too fat. To obtain a special dialling wand, please mash the keypad with your palm now.”
- 104. Touch target size 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 PosiQoning Provide 1mm inacQve space around elements Balance enough informaQon density and targetability of UI Elements PosiQon content appropriately 104
- 105. Touch target size Group links to the same resource • Larger touch target • Removes repetition for screen reader users • Less swiping and physical overhead needed 105
- 106. Gestures Easier / more intuitive Tap Draw / Move finger Swipe Drag Slide Double tap Harder / least intuitive Pinch Device manipulation e.g. tilt / shake Multi-‐touch Flick / Fling Reference: Designing touch tablet experiences for preschoolers – Sesame Street
- 107. Gestures -‐ device manipulation • Device manipulation = tilting, shaking etc • Challenge to people who can not hold a device • Discoverability and accidental activation also an issue • Always provide touch and keyboard operable alternative 107
- 108. Zoom / Magnification • Consider mobile first when designing layout and content relevancy • Minimise content in comparison to desktop • Provide a reasonable default size for content and touch controls • Adapt link text length to adapt to the viewport • Position form fields above rather than beside form labels (in portrait layout) 108
- 109. Zoom / Magnification -‐ HTML 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 orientaQon Jeremy Keith 109
- 110. 110
- 111. FORMS
- 112. Forms -‐ labels • Auto zoom cuts off left aligned labels • Labels above the field are always in view • Label explicitly (HTML) for larger touch zones 112
- 113. Forms -‐ viewport Use the correct viewport: • Responsive: <meta name=”viewport” content=”width=d evice-width” /> • Mobile: make sure the viewport is the width of your layout (usually about 320 pixels • CSS for padding and large touch targets 113
- 114. Forms -‐ keyboards • Default keyboard -‐ capitals, numbers, special characters, punctuation buried in sub menus • Use HTML text input types to invoke task based keyboards 114
- 115. Keyboards 115
- 116. Forms -‐ sign up • Minimise data entry • Gradual engagement • Third party sign up 116
- 117. Forms -‐ autofill and predictive text • Support both where logical • Disable where logical e.g. for names, email addresses • iOS5 • autocapitalize=”sentences” autocapitalize=”words” autocapitalize=”characters” 117
- 118. ALTERNATIVES
- 119. Alternatives are used for… • Images • Buttons • Graphs, charts, diagrams • Audio • Video 119
- 120. Editorial for alternatives… • Briefly describe the image • Do not describe the role / Trait • Begin with a capitalized word • Don’t end with a period (.) • Localized 120
- 121. Alternative text -‐ HTML Assign contentDescription to all user interface components e.g.: • alt=“” • alt=“Home” • alt=“Austin University Campus” 121
- 122. Tooltips -‐ HTML • Not well supported on mobile and touch • Not always accessible on desktop • Never include primary information • If in doubt just say no 122
- 123. Alternatives -‐ Android Assign contentDescription to all user interface components e.g.: • imageButton • imageView • checkbox Decorative images should not have a contentDescription 123
- 124. Labels -‐ iOS accessibilityLabel must be provided for all interacQve and informaQonal elements including images, buoons, headings, staQc text and form fields 124
- 125. Hints -‐ iOS accessibilityHints may be used to provide further informaQon • Describes what an element does • Must not include informaQon about the objects type (i.e. Trait) • Use sparingly and not for key informaQon Must be a descripQon not a command e.g. ‘Deletes programme’ not ‘Delete programme’ 125
- 126. Traits -‐ iOS Assign accessibilityTrait to all user interface components Traits describe control type or behavior Control types are mutually exclusive and describe the nature of the item More than one behavior trait can be used to describe what items do 126
- 127. Traits -‐ iOS • None • Button • Link • SearchField • Image • Selected • PlaysSound • KeyboardKey • StaticText 127 • SummaryElement • NotEnabled • UpdatesFrequently • StartsMediaSession • Adjustable • AllowsDirectInteraction • CausesPageTurn • Header
- 128. 128
- 129. STRUCTURE
- 130. content a logical order provide 130
- 131. provide a logical content order 131 Don’t make your content sound like Yoda
- 132. Headings HTML • Headings indicated using H1 to H6 Android • No means to indicate headings iOS • Use accessibilityTraitHeader 132
- 133. Headings Headings and lists H1 to H6 OL and UL NavigaQon to headings and the start of lists for screen readers Seven plus or minus 2 The opQmum number humans process informaQon 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 133
- 135. Headings 135
- 136. Headings -‐ iOS • iOS 6+ • UIAccessibilityTraitHeading • Accessed via the Web Rotor 136
- 137. Landmarks -‐ HTML Landmarks reach the parts of the page other HTML can not reach • 1 ‘main’ per page • 1 ‘header’ • use ‘navigation’ for navigation between pages • ‘complementary’ for reusable content • Use sparingly 137
- 138. Landmarks -‐ HTML HTML5 sectioning elements map to ARIA Landmarks • article maps to role=“article” • aside maps to role=“complementary” • footer maps to role=“contentinfo” • header maps to role=“main” • nav maps to role=“navigation” • section maps to role=“region” 138
- 139. 139
- 140. 140
- 141. ANNOTATED UX
- 142. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold…
- 143. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold: 1. Expose accessibility issues that originate from the design
- 144. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold: 1. Expose accessibility issues that originate from the design 2. Document accessibility requirements prior to coding
- 145. Annotated UX Annotate UX refers to annotating wireframes, style guides and designs for accessibility. The need for Annotated UX is threefold: 1. Expose accessibility issues that originate from the design 2. Document accessibility requirements prior to coding 3. Stop developers mucking up your designs!
- 146. Risks of not doing it • Designs come back to you once signed off with questions and clarifications • Designs are interpreted and coded incorrectly • Consistency, value, choice and familiarity for the user will be compromised
- 147. Annotated UX – iPlayer BBC One homepage
- 148. Annotated UX – iPlayer native Android app
- 149. Breakout session: Annotated UX Refer to either the response wires or iOS wires in the handouts: 1. What should be changed for accessibility? 2. Annotate the wireframes for accessibility 3. How would you document requirements in an accessible way?
- 152. What else can annotated UX be used for? Wireframes Visual design Style guides Usability testing Accessible prototypes Requirements User stories Pattern libraries Manual tests Automated tests
- 153. TESTING
- 154. Testing -‐ HTML • W3C developing a mobile checker • User agent switchers 154
- 155. Remote debugging iOS • iOS in Safari (also Android) • iOS select Settings > Safari > Advanced and switch Web Inspector on • Mobile Safari Preferences > Advanced and select Show Develop Menu in menu bar 155
- 156. Remote debugging 156
- 157. Remote debugging Android • Enable USB debugging via Settings > Developer options • Note -‐ On Android 4.2 and later, the developer options are hidden by default. To enable the developer options, select Settings > About phone and tap Build number seven times. • Select USB debugging 157
- 158. Remote debugging Android • In Chrome go to chrome://inspect • Select ‘Discover USB devices • Conform allow USB debugging 158
- 159. Remote debugging Android The chrome://inspect page displays every connected device, along with its open tabs and debug-‐enabled WebViews 159
- 160. Remote debugging Android Select Inspect on the tab you want to inspect 160
- 161. Testing -‐ Android Android emulator • Virtual device in the Android SDK • Configurable to mimic different devices • Contains a debug console 161
- 162. Testing -‐ Android • Lint • Finds missing contentDescriptions • Finds missing input types on text fields • Quick fix window • Write custom scripts to test 162
- 164. 164
- 165. Manual testing • Always manually test websites and apps • Simulators, automated tests, inspecting code will not spotlight usability issues 165
- 166. Top tests for voice output 1. Content and focus order 2. Alternatives exist and make sense 3. Structure is communicated 4. Form labels and instructions 5. Notifications are provided 166
- 167. Top tests for zoom 1. Context is not lost 2. Labels for forms are visible above form inputs 3. Screens are not cluttered 4. Primary information is obviously positioned 5. Notifications are visible on screen 167
- 168. Top tests for greyscale / invert colors 1. Text is readable 2. Color contrast is sufficient 3. Color is not relied upon to convey meaning 168
- 169. Breakout session Using either zoom, switch or a screen reader (with screen curtain on for iOS) complete the following: 1. On the Airbnb find a place to stay in Austin between September 1st and 7th, for 2 people for under $200 2. Using both Twitter and Facebook send a Tweet or post a comment using the #AccessUSummit hashtag 169
- 170. Want to suggest your site? 170
- 171. THANK YOU
- 173. Thank you • Hand outs and slides at • hswan@paciellogroup.com • @iheni • www.iheni.com 173
- 174. iOS Design Principles: Direct manipulation 174
- 175. iOS Design principles: feedback 175
- 176. Android design principles Enchant me • Delight me in surprising ways • Real objects are more fun than buttons and menus • Let me make it mine • Get to know me 176
- 177. Android design principles Simplify my life • Keep it brief • Never lose my stuff • Pictures are faster than words • Decide for me but let me have the final say • Only show what I need when needed • I should always know where I am • If it looks the same it should act the same • Only interrupt me if it’s important 177
- 178. Android design principles Make me amazing • Give me tricks that work everywhere • It’s not my fault • Sprinkle encouragement • Do the heavy lifting for me • Make important things fast 178
- 179. Alternatives -‐ testing Test 1. Switch on speech output 2. Navigate to images, elements and objects either by • Explore by touch (Android/iOS) • Swiping up/down, leU and right 3. Verify an alternaQve is provided 4. Verify the alternaQve accurately describes the content or funcQon Expected results • Each meaningful images element and object has an alternaQve • AlternaQves describe either the • content of a non-‐funcQonal image, element or object • the funcQon of an acQonable image, element or object 179
- 180. Color contrast -‐ mobile • Only use 3:1 when text is roughly equivalent to 1.2 times bold or 1.5 times (120% bold or 150%) that of the default platform size • Still wont guarantee access for low vision. Platform specific tools may need to be used. 180