Embed Size (px)
Citation preview
Introduction to mobile accessibility
Henny Swan
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
Agenda
• Requirements and planning • User experience • Development • QA and testing
3
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
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
You
• Name • Company • Role • Your experience of accessibility • Device
MOBILE ACCESSIBILITY LANDSCAPE
Audience: who
Diversity in disability: • Type of impairment(s) • Severity of impairment(s) • Circumstances of acquisition of
impairment(s) • Changeable impairment(s)
8
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
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
Audience: Personas
• Persona resources from the W3C Mobile Accessibility Task Force
11
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
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
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
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
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
Barriers -‐ Input
• Dexterity and touch • Single handed • Environment and voice
17
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
Barriers -‐ orientation
• Forced orientation • Mounted tablets • Limited scrolling • Content changes
19
Barriers -‐ Zoom and text resize
• Pinch zoom being disabled • Loss of context • Floating toolbars • Pop ups
20
Barriers -‐ Zoom
22
• Snap scrolling
Barriers – cognitive overload
• Inconsistent design • Excess clutter • Ambiguous labels • Ambiguous icons • Poor error handling • Where am I?
Opportunity -‐ platform features
• Geolocation • Camera • Contacts • Phone
24
Opportunity -‐ Web of Things
• Home energy management • Healthcare and fitness • Google’s Physical Web • Identity management and authentication • Casting, audio and video control
25
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
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
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
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
BBC Mobile Accessibility Standards and Guidelines
• Technology agnostic • iOS, Android and HTML techniques • Test procedures
30
31
32
33
Platform and browser support
Define the delivery context • Responsive • Native app • Hybrid
34
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
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
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
WebAim screen reader survey
38
WebAim screen reader survey
39
WebAim screen reader survey
40
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
MOBILE ACCESSIBILITY FEATURES
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
iOS accessibility features
45
Seang UserVoiceover 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
iOS -‐ mapping accessibility shortcuts
1. Go to Settings > General Accessibility > Accessibility Shortcut
2. Select shortcuts 3. Triple click the
Home key to activate
46
iOS -‐ switch support
• iOs7+ • Using an external device or FaceTime • Accessed via Settings > Accessibility > Switch control
47
iOS -‐ VoiceOver
• Supports 36 languages • Gesture and explore by touch support • Supports braille output • Excellent browsing support
49
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
iOS -‐ rotor navigation
1. Dial gesture on screen
2. Select how you want to navigate
3. Swipe up or down
51
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
3 finger triple tap Screen curtain
Seang UserVoice 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
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
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
Zoom
OS-‐level features • Set default text size • Magnifies entire screen • Magnifying lens view under user's finger
• 3 finger scroll
59
Zoom
Browser-‐level features • Set default text size of text in the browser
• Reader mode (not universally supported)
• Pinch zoom
60
Zoom
Browser-‐level features • Magnifying lens view under user's finger
• Force enable zoom (Chrome, Android)
61
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
USER EXPERIENCE
As a user I want…
• WCAG Level AA compliance • WAI ARIA • Validated code
Said no user ever!
64
Accessibility and inclusive design
Standards and guidelines tend to focus more on: …code over design …output over outcome …compliance over experience
65
– 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.”
Principles of accessible UX
67
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
iOS start up screens
70
Android start up screens
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
“ T h e o b v i o u s i s a a b o u t a lway s ”
Focus
74
Choice
Provide multiple ways to: • Access key tasks, screens or information • Complete key or complex tasks • Complete non standard interactions
75
Choice
76
Control
What ways can user controls over content be suppressed?
77
Control
What ways can user controls over content be suppressed? • Orientation
78
Control
What ways can user controls over content be suppressed? • Orientation • Pinch zoom
79
Control
What ways can user controls over content be suppressed? • Orientation • Pinch zoom • Right click (web)
80
Control
What ways can user controls over content be suppressed? • Orientation • Pinch zoom • Right click (web)
Support browser and platform accessibility features
81
Control
82
Control
iOS7+ closed caption customization: • Font • Size • Color • Background color • Background opacity • Text edge style • Text highlight 83
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
Prioritise features that might be of particular value for everyone • Platform features • A to Z, filters, sort, manage, delete • Web of things
Value
85
Value
86
GeolocationPhoneCamera
Value
Web of Things • Health • Home • Entertainment
87
• Energy • Education • Security
Breakout session
What features might you add to your product to provide a better user experience for diverse users?
88
DESIGN
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
Focus states
• Use distinctive hover/focus states • Ideally use the same hover state on focus • Selected states must be unique
91
Visual cues
• Navigation must be visually explicit • Distinguish interactive
elements
92
Visual cues
What’s wrong with the visual cues on this screen?
93
Visual cues -‐ iconography
Question mark, home, burger for home, disc for save, back arrow etc
94
GridAdd List Menu
Visual cues -‐ conventional positioning
95
Positioning -‐ reach
• Optimize for use one handed
• Important content bottom left to right
• Position important content above page scroll
96Mobile First by Luke Wroblewski
Consistent layout -‐ platforms
97Netflix on desktop
Consistent layout -‐ Platforms
98Main menu when open Sign out at the foot of the page
KEYBOARD AND TOUCH
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
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
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.”
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
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
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
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
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
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
FORMS
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
Forms -‐ viewport
Use the correct viewport: • Responsive: <meta name=”viewport” content=”width=device-width” />
• Mobile: make sure the viewport is the width of your layout (usually about 320 pixels
• CSS for padding and large touch targets 113
Forms -‐ keyboards
• Default keyboard -‐ capitals, numbers, special characters, punctuation buried in sub menus
• Use HTML text input types to invoke task based keyboards
114
Keyboards
115
Forms -‐ sign up
• Minimise data entry • Gradual engagement • Third party sign up
116
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
ALTERNATIVES
Alternatives are used for…
• Images • Buttons • Graphs, charts, diagrams • Audio • Video
119
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
Alternative text -‐ HTML
Assign contentDescription to all user interface components e.g.: • alt=“”• alt=“Home”• alt=“Austin University Campus”
121
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
Alternatives -‐ Android
Assign contentDescription to all user interface components e.g.: • imageButton• imageView• checkbox
Decorative images should not have a contentDescription
123
Labels -‐ iOS
accessibilityLabel must be provided for all interacQve and informaQonal elements including images, buoons, headings, staQc text and form fields
124
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
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
Traits -‐ iOS
• None • Button • Link • SearchField • Image • Selected • PlaysSound • KeyboardKey • StaticText 127
• SummaryElement • NotEnabled • UpdatesFrequently • StartsMediaSession • Adjustable • AllowsDirectInteraction • CausesPageTurn • Header
128
STRUCTURE
content a logical order provide
130
provide a logical content order
131
Don’t make your content sound like Yoda
Headings
HTML • Headings indicated using H1 to H6
Android • No means to indicate headings
iOS • Use accessibilityTraitHeader
132
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
Headings -‐ HTML
134
Headings
135
Headings -‐ iOS
• iOS 6+ • UIAccessibilityTraitHeading• Accessed via the Web Rotor
136
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
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
140
ANNOTATED UX
Annotated UX
Annotate UX refers to annotating wireframes, style guides and designs for accessibility.
The need for Annotated UX is threefold…
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
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
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!
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
Annotated UX – iPlayer BBC One homepage
Annotated UX – iPlayer native Android app
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?
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
TESTING
Testing -‐ HTML
• W3C developing a mobile checker • User agent switchers
154
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
Remote debugging
156
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
Remote debugging Android
• In Chrome go to chrome://inspect • Select ‘Discover USB devices
• Conform allow USB debugging 158
Remote debugging Android
The chrome://inspect page displays every connected device, along with its open tabs and debug-‐enabled WebViews
159
Remote debugging Android
Select Inspect on the tab you want to inspect
160
Testing -‐ Android
Android emulator • Virtual device in the Android SDK • Configurable to mimic different devices • Contains a debug console
161
Testing -‐ Android
• Lint • Finds missing contentDescriptions • Finds missing input types on text fields • Quick fix window • Write custom scripts to test
162
xCode iOS Simulator
163
164
Manual testing
• Always manually test websites and apps • Simulators, automated tests, inspecting code will not spotlight usability issues
165
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
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
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
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
Want to suggest your site?
170
THANK YOU
iOS Design Principles: Direct manipulation
174
iOS Design principles: feedback
175
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
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
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
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
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
![모바일접근성 (Mobile Accessibility] 모바일 접근성_현준호... · 모바일접근성 (Mobile Accessibility] PG 605 워크숍[2010. 8. 26) 현준호 한국정보화진흥원현준호책임](https://img.dokumen.tips/doc/110x75/5f1273f7b3fa035e217ad337/eee-mobile-accessibility-ee-e-eee.jpg)
