In the month of December, I created a mobile accessibility advent calendar across social platforms (LinkedIN, BlueSky). Each day I posted something about mobile accessibility to strengthen the knowledge of the a11y community, mobile developers and designers.
Day 1 of the Mobile Accessibility Advent Calendar!
If you ever are talking to an iOS dev or designer and say "this icon is missing a role of button" and they give you a perplexed look, it's because in iOS these are called "traits". When communicating with iOS devs, one of the biggest disconnects in Accessibility is talking the same talk. If you say "this needs a trait of .isButton", it will stick!
Day 2 of the Mobile Accessibility Advent Calendar!
Did you know, that Android comes with its own accessibility testing framework by default? The Accessibility Test Framework (ATF) is googles out of the box testing library that runs at multiple levels, including linting and UI automated testing.
https://developer.android.com/guide/topics/ui/accessibility/testing#analysis
Day 3 of the Mobile Accessibility Advent Calendar!
If you are developing your application in SwiftUI, you are probably using SwiftLint to check your code for issues as you develop. Did you know that you can activate two accessibility rules within library? Its super simple to turn on and can help your team check for accessibility issues as you code! Here are the two rules:
Accessibility Trait for Button - All views with tap gestures added should include the .isButton or the .isLink accessibility traits
Accessibility Label for Image - Images that provide context should have an accessibility label or should be explicitly hidden from accessibility
Documentation (Search accessibility): https://realm.github.io/SwiftLint/Guides.html
Day 4 of the Mobile Accessibility Advent Calendar!
One of the most common issues in mobile applications is the lack of proper headings. Headings are needed in mobile applications to make it easy for users to navigate between large chunks of content. Without them, mobile applications can become cumbersome for users to navigate with Voiceover and Talkback.
The dope part, they are available in both platforms and yes users do use them to navigate your application! Simply give the heading text the proper trait of .isHeading in iOS and accessibilityHeading=true in Android.
For more information on headings for iOS and Android visit:
https://www.magentaa11y.com/checklist-native/headings/
Day 5 of the Mobile Accessibility Advent Calendar!
In the previous post we discussed headings and how they can make applications easier to navigate for users who use Talkback in Android and Voiceover in iOS. The typical navigation of users in both platforms is to swipe right with their finger to navigate down the view and swipe left with their finger to navigate backwards. Each time a user swipes, each item in the view gains accessibility focus. This of course can be cumbersome without a way to jump around large chunks of content.
This is where the Rotor in iOS and Reading Controls in Android come in handy. Both are features that allow for users to quickly access features of an application such as headings. When a user selects "headings" to navigate, they then can swipe with their finger up or down to navigate heading to heading! There other forms of actions and navigation that can be done using both, for more information click on one of the links below!
- iOS Rotor: https://dequeuniversity.com/screenreaders/voiceover-ios-shortcuts
- Reading Controls Android: https://dequeuniversity.com/screenreaders/talkback-shortcuts
Day 6 of the Mobile Accessibility Advent Calendar!
Be careful when using hints!
Hints can be used for extra information on content in mobile applications, however, hints should not contain ANY vital information for a user.
Users of TalkBack and Voiceover have the option to turn off hints. There are a large amount of users who have this turned off, as hints are misused and may give more information than needed in mobile applications. The one misconception in mobile is that hints behave like aria-describedby in web, and is always read. Therefore, a hint really should only be used when it is extra context for a user and not VITAL context for them to understand the control.
- Android Hints: https://appt.org/en/docs/android/samples/accessibility-hint
- iOS Hints: https://appt.org/en/docs/ios/samples/accessibility-hint
Day 7 of the Mobile Accessibility Advent Calendar!
Hybrid applications combine Web and Native development into one singular item. These applications can be built with a web framework such as Angular, Vue OR they are their own language entirely like Flutter or React Native.
The major disconnect in the accessibility community is understanding the type of application that is being developed. Not all mobile applications are developed in SwiftUI/UIKit (iOS) or View/JetPack(Android). Knowing how the mobile application you are working with is being built can help you be able to give proper information on how to fix specific issues in the application itself.
The big question though is, do they need to adhere to the same standards for mobile accessibility? The answer is YES! Even though they may behave more similarly to web content, users would expect them to behave as much as possible like a mobile application!
Day 8 of the Mobile Accessibility Advent Calendar!
Terminology is key to making a connection with mobile designers and developers. One of the big disconnects in the mobile community, is a lot of us come from a web accessibility background, and it can get really hard trying to tell mobile developers how to fix issue when what we say doesn't connect with what they know.
The next couple of posts will cover key terms in mobile and the equivalents in web. Think of this as a terminology cheat sheet! Lets first start with common terms between iOS and Android both:
- Web Page = View
- Main Navigation = Navigation/System Bar
- Aria-describedby = Hint
- Focus = Accessibility Focus
- Tab Order = Swipe Order
- Resize Text = Scale
Even just these 5 common terms can help you make a connection that lasts! In our next posts we will cover iOS and Android respectively.
Conclusion
Stay tuned for part 2 very soon!
Follow #MobileA11yAdventCalendar on LinkedIn and BlueSky to see more posts from the last month!
Top comments (0)