Welcome to part two of the Mobile Accessibility Advent Calendar! In this post we will cover days 9 through 16!
Day 9 of the Mobile Accessibility Advent Calendar!
Continuing from where we started from our Day 8 post, common terminology in iOS. These are web terms translated into mobile accessibility terms. Web is on the left, and mobile equivalent on the right.
Aria-label = .accessibilityLabel
Role/State = Traits
Heading = .isHeader
Page Title = .navigationTitle
Aria-hidden = .accessibilityHidden
Aria-live = accessibilityNotification.Announcement
Using just these simple common terms can help you make a connection that lasts with iOS developers and designers! In our next posts we will cover iOS and Android respectively.
Day 10 of the Mobile Accessibility Advent Calendar!
Continuing from where we started from our Day 8 post, this is common terminology in Android. These are web terms translated into their similar mobile accessibility terms. Web is on the left, and mobile equivalent on the right.
Aria-label = contentDescription
Role/State = Role/RoleDescription
Heading = semantics isHeading()- Page Title = TopAppBar title
Aria-hidden = isImportantForAccessibility
Aria-live = LiveRegionMode Polite/Assertive
Using just these simple common terms can help you make a connection that lasts with iOS developers and designers! Are there any others that you can think of??
Day 11 of the Mobile Accessibility Advent Calendar!
Designers can help ensure mobile applications are accessible, however, most designers don't know where to start in order to properly annotate for accessibility. There are two FREE Figma plugins that exist that your design teams can use to begin bringing accessibility into the design process.
Include from eBay: https://www.figma.com/community/plugin/1208180794570801545/includeaccessibility-annotations
CVS A11y iOS Annotations: https://www.figma.com/community/file/1331647574396908226/accessibility-annotation-kit-for-ios
Day 12 of the Mobile Accessibility Advent Calendar!
Resource time!
There are 3 main resources that I tend to go back to over and over again when it comes to mobile accessibility. These are key resources that can help you with implementation guidance for fixing issues, what to avoid, and more education deep dives on multiple different types of mobile concepts and application types.
The iOS Accessibility Technique library created by Paul Adams
The Jetpack Compose Accessibility Technique library created by Robert Allen Henley
Appt.org by Stitching Appt
Day 13 of the Mobile Accessibility Advent Calendar!
One of the top issues seen in mobile applications, is the improper grouping of content. What do I mean by improper grouping? In Android and iOS applications you can create content and have the whole item be tappable, like the iOS settings menu. You can also create components such as cards that can have multiple different pieces of information in them, like in commercial applications where you have an image of the item, description of item, and the price.
By default, when creating components such as these each individual item is accessible one by one for screen reader users. This causes a very frustrating experience when navigating complex applications. So what's the solution? Group similar content together to make each accessibility focus point clear and concise for the user.
- For good and bad examples of grouping see my article here: https://dev.to/steady5063/top-5-ios-mobile-app-accessibility-issues-pt-1-51g8
More information on how to group content in iOS: https://www.hackingwithswift.com/books/ios-swiftui/hiding-and-grouping-accessibility-data
More information on how to group content in Android: https://appt.org/en/docs/jetpack-compose/samples/accessibility-group
Day 14 of the Mobile Accessibility Advent Calendar!
Question I am often asked is, "it seems like mobile accessibility is the right thing to do, but is there anything that is actually enforcing that my application be accessible?" or "All I see is things that say 'web' accessibility but nothing for mobile, so we are off the hook right?".
In the past year or so, it is no longer web that is being called out, it is mobile applications as well! So when anyone asks does the application need to be accessible, emphatically say YES! Besides from the question of WCAG (which we will get to in another post), there are things in law that now point to the need to have your mobile applications be accessible.
Oklahoma State Mobile Apps: https://adasitecompliance.com/oklahoma-agency-doj-settled-inaccessible-mobile-app/
DOJ Accessibility Guidance: https://www.ada.gov/resources/2024-03-08-web-rule/#the-reasons-the-department-set-specific-requirements-for-web-and-mobile-app-accessibility
Day 15 of the Mobile Accessibility Advent Calendar!
The daily conversation I have with folks in the mobile space is one of two questions:
- "Where are the standards for mobile accessibility!?!?!"
- "Does WCAG actually apply to mobile??"
The answer in short, WCAG does apply to mobile applications. Yes, before anyone gets up in arms and says the word "web" is literally in the title that doesn't make sense, it will. The principals that WCAG is built on are easily transferable to mobile applications.
Does every little thing within WCAG apply? Not necessarily. Are there resources and guidance in WCAG that are web based and can make it difficult to translate it into what is needed for mobile? Sure! However if you are looking for a starting set of resources to help guide you in the right direction for guidelines there are a couple really good ones!
BBC Mobile Standards:
https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/summary/
W3C (OLD) Accessibility Mapping: https://www.w3.org/TR/mobile-accessibility-mapping/
There are also some mobile specific standards (built on principal of WCAG but their own guidelines):
Evinced Mobile Standards (MCAG): https://getevinced.github.io/mcag/
Also, there is an awesome working group that is currently building a set of standalone mobile accessibility standards.
Day 16 of the Mobile Accessibility Advent Calendar!
Let's talk assistive technology!
One mindset we tend to get into in mobile application accessibility is testing only with screen readers. In theory screen reader testing SHOULD catch most of the issues in your application, however to get a full picture of the accessibility of your app you need to test with multiple assistive technologies. The truth is there is a load of different assistive technologies that users use that you should be testing with to ensure you content is accessible. For this post, we will cover iOS!
What you should be testing with:
- Voiceover - The standard default screen reader with iOS, that should be at the core of the testing you are doing.
- Switch Control - Allows users to use an adaptive accessory to interact with their phone by highlighting each item sequentially.
More on Switch Control
- Voice Control - Allows users to use voice to control iOS device. One of the common testing methodologies I suggest with this is saying "show numbers" and ensuring all the actionable items on the screen are accounted for AND function.
More on Voice Control
- Keyboard - Yes, you read this correctly. No it isn't an assistive technology per say, however keyboard users exist in iOS. To say that they don't would be a mistake, testing your application with keyboard and Voice Over on (and off) will ensure that multiple inputs can work with it.