Mobile accessibility can be a very difficult space to navigate. Let's make it easier to dive right in! From common terms, breakdown of application accessibility, and building up accessibility on mobile development teams, this session will help build the foundation to ensure your mobile applications are accessible.
2. Who Am I?
Name: Mark Steadman
Director – Digital Accessibility
Fidelity Investments
Mobile Contributions:
W3C Mobile Working Group Member
MCAG Contributor
IAAP mobile cert committee member
3. Learning Outcomes
The Disconnect
Why mobile
accessibility
tends to be an
afterthought
Simple Mobile
Requirements
Simple guide to
helping you build
accessible mobile
apps
Sustaining and
Building
How can each role
impact making our
apps accessible
5. • Global traffic on mobile devices has increased from 6% in 2011, to 54%
in 2021
• Anything and everything has a mobile app now.
• Some sites even force you to USE the mobile app (Reddit)
• Quick, easy access:
• Communication
• Ride Sharing
• Banking
• Food delivery/Grocery Delivery
Why Does Mobile Accessibility Matter
6. Why Does Mobile Accessibility Matter cont.
According to A study done in the
Netherlands:
• 45% of users have one or
more accessibility setting on.
• 15% have more than one
accessibility setting on.
Source Credit: https://appt.org/en
https://www.cdc.gov/ncbddd/disabilityandhealth/infographic-disability-impacts-all.html
According to a study done by the CDC, in the US:
Around 260 Million Adults in the US
• 1 in 4 Adults (27%) have a disability (~70 Million)
• 12.8% Have cognitive disabilities (~33.3 Million)
• 12.1% have mobility disabilities (~31.5 Million)
• 6.1% have Hearing Disabilities (~15.9 Million)
• 4.8% have vision disabilities (~12.5 Million)
7. What Enforces It?
● Court Decisions:
○ State of Oklahoma/DOJ Settlement
○ Labcorp Kiosk Settlement
○ Dominos Lawsuit
● In Law:
○ ADA Act Title II
○ DOJ Accessibility Guidance
● Guidelines:
○ WCAG – Specifically 2.1 and 2.2
○ Human interface guidelines
○ User Agent Accessibility Guidelines
8. Android Assistive Technology
Screen Reader: Voice Over
Text Resizing
Voice Control
Switch Control
iOS Assistive Technology
Screen Reader: TalkBack
Text Resizing
Switch Access
Keyboard
How Do Users Interact with Mobile Apps?
9. Common Navigation Patterns
Basic Navigation
• Move to the next item – Swipe right
• Move to previous item – Swipe left
• Activate Focused Item – Double Tap
• Stop speaking – Two finger tap
Additional Controls
• Rotor Navigation (iOS) – Two finger
rotation in circle
• Once selected swipe up/down
• LCM Local Context Menu (Android)
• Three finger swipe right or left
• Once selected swipe up/down
12. TalkBack Directions
1.Open Settings
2. Open Accessibility option
3. Scroll to the bottom, Accessibility
Shortcut option
4. Make sure
VoiceOver is selected
VoiceOver Directions
1. Open Settings
2. Open Accessibility option
3. Scroll to the bottom, Accessibility
Shortcut option
4. Make sure
VoiceOver is selected
Voiceover and Talkback Shortcut Activation
13. Amazon Workshop Activity
• Open Amazon App
• Turn on screen reader (Using shortcut)
• Using the navigation patterns in previous slide do
the following:
• Search for notebook
• Add notebook to cart
• Navigate to the cart
14. Amazon Workshop Outcomes
• What did you notice?
• How difficult was the experience?
• Was there anything you believe could have made it
better?
16. • Accessibility always gets a bad reputation in the mobile
community because of one big thing.
• “Web specialists don’t get mobile!”
• Mobile developers and designers only have one set of
guidelines and resources to go off of, and those are all
web based.
• Minimum requirements are difficult and hard to parse
through
What is the Disconnect
17. ● Talking the mobile talk!
○ How can we talk in the same terms as
mobile devs and designers?
● What are the actual mobile standards?
● Hybrid application development vs native
mobile application development
Fixing the Disconnect
18. ● Page = View
● Main Nav = Navigation/System Bar
● Aria-describedby or extra content = Hint
● Focus = Swipe stop/point
● Tab Order = Swipe Order
● Resize Text = Scale
Key Accessibility Terminology - Common
19. Android Terms
• Alt Text = accessibilityLabel
• Role/Aria = Trait
• Heading = isHeader
• Tabindex of 0 =
groupAccessibilityChildren
• Aria-hidden = accessibilityHidden
iOS Terms
• Alt Text = ContentDescription
• Role = Role or RoleDescription
• Aria-labeledby = labelFor
• Tabindex of 0 = focusable attribute
• Aria-hidden = importForAccessibility
Key Accessibility Terminology
20. ● The Problem:
● There are no “official” mobile accessibility standards.
● Expectations for user interaction in mobile unclear
● The Reality :
● WCAG DOES apply to mobile applications, and quite easily.
● W3C has a working group that is building official set of mobile
accessibility standards
Where Are The Standards?!
22. Wrench of Hybrid
● Hybrid applications combine Web and Native development into one
singular application
● Apps are built in web frameworks and then compiled into mobile
applications
● Examples of Hybrid frameworks
● Cordova
● Ionic
● React Native
23. Wrench of Hybrid Cont.
● Major disconnect in the accessibility community is understanding the type
of application being developed.
● If it is hybrid, then (unless React Native) it is developed using web
based frameworks
● If it is Native, it is developed using Android and iOS based
development frameworks
● Example: Swift/SwiftUI, Android View/JetPack Compose
25. For This Breakdown…
● For this ENTIRE section, pick any application you want on your mobile
device and test it for these requirements
● You may want to have a couple apps to try out on this.
● We will leave plenty of testing time for you all to try it out as we go, but
please ensure your volume is down a little bit or headphones are in for
others around you
● Ask questions! I want this to be interactive!
26. The Breakdown of the Breakdown!
● 12 Specific requirements.
● These 12 requirements are based on data collection done through
multiple applications and audits completed that took the top 12
issues seen in mobile applications
● 4 Categories of Issues
● View Structure (Navigation)
● Interactable elements
● Content
● User Interaction
27. Proper navigating through
an application
Headings
Easy navigation
between content
View Titles
Unique titles for
each new view
Swipe Order
View Structure (Navigation)
28. Headings - Requirement
● Rule #1: Main view title must be announced as heading (iOS), Android is
NOT required to announce as heading
● Rule #2: Any text that breaks up logical chunks of content should be
properly designated as a heading
● Rule #3: Headings MUST be navigable by proper OS functionality
● iOS: Rotor
● Android: LCM (Local content menu)
29. Headings - Tests
● Test #1 Identifying Headings: Text that breaks up logical chunks of
content should announce as “<Text> Heading”
● Test #2 Navigation: A user should be able to navigate between sections of
content using the Rotor in iOS or LCM in Android
● iOS Rotor: With VO on, Twist two fingers right/left until you hear
headings and swipe up/down to navigate by headings
● Android LCM: Use three finger swipe left/right until you hear
“Headings” then swipe up/down to navigate by headings
31. View Titles - Requirements
● Rule #1: Each view must have a unique title
● Rule #2: If a unique title is not possible on each view (Ex: Sign up for
insurance), then the following subheading can qualify as the unique
heading
● Rule #3: Titles should not have trailing … or be cutoff
32. View Titles - Tests
● Test #1 Ensure Unique Titles: As you navigate from view to view, ensure
the title in the top of the view is changing
● Test #2 Ensure Titles Exist: No view should have no title UNLESS the next
subsequent text is a heading that serves as the views title (Example to
follow)
● Test #3 Ensure title does not cut off: Without resizing, ensure the title
does not have any trailing … or is cut off. Titles should be unique and
concise.
34. Swipe Order - Requirements
● Rule #1: Items that logically are group together (Ex: buttons with large
amounts of info) are grouped properly in swipe order
● Rule #2: Ensure content that is not visible is not accessible with screen
reader on.
● Rule #3: Ensure focus view to view is consistent
● Default focus is to the back button or view title
● If modal or tray, the focus must return to the trigger
35. Swipe Order -Test
● Rule #1: Items that logically are group together (Ex: buttons with large
amounts of info) are grouped properly in swipe order
● Rule #2: Ensure content that is not visible is not accessible with screen
reader on.
● Rule #3: Ensure focus view to view is consistent
● Default focus is to the back button or view title
● If modal or tray, the focus must return to the trigger
36. Swipe Order Examples
1. Test #1: With VO and TB on, swiping through (right/left) ensure logical
grouped content reads as one stop
2. Test #2: With VO and TB on, swiping through (right/left) Ensure no hidden
content is visible to screen reader users.
3. Test #3 Ensure focus view to view is consistent. Either stick with default
in the title bar OR if focus is controlled it is consistent where it goes
4. Test #4 If a modal or tray is opened, focus returns to the trigger that
opened it
38. Native apps should
work with keyboard
and screen reader
Button/Links
What is button/Link.
Ensuring it properly
states its role
Input/Forms
Inputs/forms should
conform to specific
mobile standards
Keyboard
Interactable Elements
39. Button/Link - Requirements
● Rule #1: Each actionable item must have a proper role! (Trait in iOS)
● Rule #2: Links take you to webview or web content, buttons keep you
within native views
● Rule #3: Each actionable item must have a proper accessible name that
clearly defines its purpose.
● Note: The label CANNOT include the role
40. Button/Link - Tests
● Test #1: With VO and TB on, ensure each actionable item has a proper
role (Trait) that describes its purpose
● Test #2: With VO and TB on, if an actionable item takes you to a webview
or web content, it has proper role (trait) of link
● Test #3: With VO And TB on, ensure that the label for each actionable item
properly describes it and does not include:
● file extension naming
● the role of the item
42. Inputs/Forms - Requirements
● Rule #1: Each input should have a consistent and visible label
● Rule #2: Forms should have an error message WITH proper error icon
associated with the input or the entirety of the form
● Rule #3: Each input MUST NOT have multiple swipe stops (focus points).
Single swipe point is all that is needed.
43. Inputs/Forms - Tests
● Test #1: Ensure each input has a consistent and visible label that is within
a logical proximity to the input
● Test #2: In a form (such as login) enter no information and ensure there is
either error messages on each field in question OR a global error message
● Test #3: With VO or TB on, ensure while swiping through the inputs that
the label or error message are not swiped to and it is only focused on the
input
46. Keyboard - Requirement
● Rule #1: Native application should function properly in iOS and Android
with screen reader on. Should properly function WITHOUT in Android
47. Keyboard - Test
● Test #1: Connect a Bluetooth keyboard to your device, and turn on VO or
TB. Using standard navigation for keyboard, navigate through the view of
the application and ensure all actions and content are accessible.
● Android Keyboard Commands
● iOS Keyboard Commands
49. Color alone cannot
dictate vital info
Resize Text
Text changing size
and not cutting ff
Images
Are properly hidden
or described
Use of Color
Content
50. Resize Text - Requirements
● Body copy should be readable, without overlap or truncation, at roughly 200% of its
default size
● Headings (e.g., not body copy) should be readable roughly 130% of its base size
● The following is a generally agreed upon method of resizing text on mobile devices to
measure the above success criteria:
○ iOS
● Settings > Accessibility > Display & Text Size > Larger Text
● With the “Larger Accessibility Sizes” toggle Off, using the drag slider
increase the text size as large as it will go, then
● Toggle the “Larger Accessibility Sizes” toggle On, and drag the slider three
more notches (this is considered AX3)
○ Android
● Settings > Accessibility > Text & Display > Font Size
● Use the drag slider to increase the text size to 6 of 8
51. Resize Text - Test
● Test #1:
● iOS
○ With font settings to AX3, look to see if all content is available
does NOT contain trailing …
● Android
○ With font settings to 6 of 8, look to see if all content is available
does NOT contain trailing …
53. Images - Requirements
● Rule #1: Images that are decorative should be hidden from screen reader
users, those that are not should have proper accessibility label.
● Rule #2: Images MUST NOT contain large chunks of text.
54. Images - Test
● Test #1: With VO and TB on, ensure that each image is either properly
hidden from screen reader OR has proper accessible label for it.
● Test #2: Locate any images that contain multiple lines of text or text with
vital information for the user.
56. Use of Color - Requirement
● Rule #1: Any use of color that depicts vital information to users cannot be
used and must have an alternative to share said information
57. Use of Color - Test
● Test #1: Navigating your application, seek any information that depicted
using color alone. IF there is not alternative way to gain that information,
use of color is violated
● Example: Showing negative and positive integers as red and green
respectively
59. All custom gestures
must not interfere
with common gestures
Touch Target Size
Proper sizes for
interaction
Orientation
App must work in both
landscape and
portrait
Custom Gestures
User Interaction
60. Touch Target Size - Requirements
● Rule #1: All touch targets in mobile applications must be large enough
and easily touchable by all users
● Android MUST have a minimum touch target size of 48dp x 48dp
● iOS MUST have a minimum touch target size of 44pt x 44 pt
61. Touch Target Size - Tests
● Test #1:
○ iOS:
■ Use of the Accessibility Inspector
○ Android
■ Use of the Google Accessibility Scanner
63. Orientation - Requirements
● Rule #1: Mobile applications must adhere to landscape and portrait
modes
● Rule #2: When in landscape, not text or loss of context has occurred
64. Orientation – Test
● Test #1:
● Turn on Orientation (allow rotation:
○ iOS: Open control center by swiping from right corner and
tapping the “Lock” logo
○ Android: Open control center by swiping from right corner and
tapping the “rotation” button (or lock icon if it is locked)
● Once on, ensure the application works in both landscape and
portrait.
● If portrait works, ensure no overlap or loss of context occurs
66. Custom Gestures - Requirements
● Rule #1: Any custom gestures (Swipe patterns, touch and hold) MUST
NOT interfere with common gestures
● Rule #2: Swipe only gestures MUST have an alternative method or proper
instruction and not be overly complex
67. Custom Gestures - Test
● Test #1: With VO or TB on, navigate the application using right and left
swipe. If any item in the view does something out of the norm (Text
sliding, item selected) custom gestures fails
● Test #2: With VO or TB on, navigate to a “slide to” gesture component and
ensure that either:
● The component has proper instruction to use
● Has an alternative method to interact
70. Everybody Has A Role
● Each person in an organization plays a vital
role in ensuring your mobile content is
accessible
● Using the 12 requirements above, we can
see how each role can have a large impact
in ensuring the issues are fixed before they
are even released into production!
71. Tools to Use
● Headings
● Visible Label
● Resize Text
● Swipe Order Grouping
● Touch target size
● Orientation
Potential Issues to Fix
● Include: eBays accessibility
annotations toolkit
● CVS iOS Annotations: CVS
a11y kit for iOS specifically
Role: Designers
76. ● QA members can have a multitude of different jobs in their daily tasks
● Regression testing can be a MASSIVE endeavor for teams to get done,
and adding accessibility testing to this can be difficult.
● So what can we do to ensure QA gets accessibility as part of their testing?
Role: QA/Test Team
77. Minute to Win it Tests! – Screen Reader
Roles for Actions:
• Do actionable items have a proper
Role? Roles include button, link, switch.
Headers:
• Do labels that break up sections of
content announce as headings?
• Using the heading rotor command, can
you navigate through headings?
Appropriate Accessible Text:
• Do screen reader announcements
match the visual label?
Image Descriptions :
• Informative: Does the accessible label
properly represent the image?
• Decorative: Is the image hidden from
screen reader focus?
78. Minute to Win it Tests! – Visual
Persistent and Visible Labels
• Does every input have a visible label?
• Do labels disappear once the field is
interacted with?
Use of Color
• Is any information given using color
alone?
Images of Text
• Are there images of text that share vital
information?
Text Resizing
• Does the text resize?
• Does content truncate...?
• Does content overlap?
Heading and Structure
• Are there visual labels breaking up
groups of content?