Welcome to part three of the Mobile Accessibility Advent Calendar! In this post we will cover days 17 through 24!
Day 17 of the Mobile Accessibility Advent Calendar!
Let's talk assistive technology on Android!
In the previous post, we talked about getting into the mindset of only testing with screen readers, in this case TalkBack 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.
What you should be testing with:
- TalkBack- The standard default screen reader with Android, that should be at the core of the testing you are doing.
Switch Access - Allows users to use an adaptive accessory to interact with their phone in customizable ways that make it easier to use.
Keyboard - Android tends to have more keyboard users. Android actually allows for developers to make their applications accessible with keyboard by having specific attributes in the code, which in turns makes it a bit more keyboard friendly. Keyboard is CORE to what is needed to ensure your application is accessible.
Day 18 of the Mobile Accessibility Advent Calendar!
Lets talk about tables!
One misconception in mobile applications developed in SwiftUI (iOS) and Android (View/Jetpack) is that tables announce the EXACT same way as they do in web. Announcing the column and the row numbers and each respective cells data that you are on.
In mobile, there is NOT a semantic table like this. There are tables that layout content, and even a table in iOS that is used for desktop applications, but they do not function like this. In order to properly create a table and get the associations, you have to customize the table you have created and add in the proper announcements. The label must include the row (if necessary) and column header text, along with the data text.
Using this delivery table as an example: https://www.w3.org/WAI/tutorials/tables/two-headers/.
In mobile we would want the label for the first cell to announce as "9:00 - 11:00, Monday, Closed". You can add in the word Row, or Column, but for the most part a lot of users have advocated not to have that information in mobile applications.
Please ensure you take the time to make your data tables accessible for all! It can make a huge difference in making your application easier to consume for everyone!
Day 19 of the Mobile Accessibility Advent Calendar!
iOS Accessibility inspector that comes with Xcode has a bad rep. Does it have some bugs and quirks, absolutely. However, most of the accessibility community thinks it is only automated issues that it finds, and those are about 3 issues. The truth is, it is a robust tool that lets you inspect the application for both automated AND manual issues. Here are some super dope facts about XCode accessibility inspector:
- You can connect your phone and inspect ANY application for accessibility issues. No access needed to the code.
- It has a step through ability to see all the information in the accessibility tree (Traits, Labels, Hints)
- Navigation inspector can show how a user with VoiceOver would navigate the application.
- Run Audits that check for 7 automated issues:
- Element description
- Hit Region
- Contract
- Element Detection
- Clipped Text
- Traits
- Dynamic Type
Day 20 of the Mobile Accessibility Advent Calendar!
Orientation matters!
A lot of mobile accessibility applications currently only work in portrait. When they need to work in both portrait and landscape. Landscape allows ALL types of users to be able to interact with your application how they want. Some users use mounts for their device, others like a large screen, some use keyboards and its easier for them to navigate and see with keyboard.
However, if you do not develop/design with both modes in mind, this can be a very heavy lift to fix up and ensure that it is accessible. Not only must it not just orient, it must also:
- Not cut off any text or overlap content
- Must still have proper navigation order
- All actions must still function
- Must work with screen reader
Day 21 of the Mobile Accessibility Advent Calendar!
(Photo credit droids on roids)
Have you ever used an application and tried to tap a button on the screen and you just cannot seem to be able to get it to work? Maybe it's the smudge on your screen, or maybe, its that the application you are using does not have proper touch target sizes!
iOS and Android each respectively have their own touch target sizes that each item that has an action must meet in order for it to work for ALL users.
iOS Dimensions: 44 X 44pt
Android Dimensions: 48 X 48dp
Day 22 of the Mobile Accessibility Advent Calendar!
The ability for any and all users to be able to resize the text on their phone is one of the best features of mobile devices. Allowing for users to adjust their text size can help a variety of different users be able to interact with your applications in ways they may not have been able to in the past. Unfortunately, there are still MANY applications that do not resize AT ALL, causing frustration that may make them leave your application all together. How can we ensure our applications scale?
Designers:
- Ensure you include specs that show multiple levels of resizing content.
- Ensure no text content is cut off using a trailing …
- Minimum font sizes for body text, 17 pt for iOS, 16sp for Android Developers
- In iOS ensure your application uses Dynamic type
- In Android use Scalable Pixels (SP) instead of DP Is this everything? No, but it does help to start getting your application down the right path of properly resizing!
Day 24 of the Mobile Accessibility Advent Calendar!
Today I want to take an opportunity to shout out some of my favorite mobile accessibility presentations I have seen! These are all free to view and are great resources to use at your organization!
Building Accessibility Android Apps w/ Jetpack Compose by Devanshu Chandra
Intro to Mobile App Accessibility by Rachael Yomtoob
Native Mobile Accessibility Testing by Jan Jaap de Groot
Mobile Accessibility Tools by Shafik Quoraishee
Day 25 of the Mobile Accessibility Advent Calendar!
We have made it to the end!! My final post will not be a new tip or trick, it will be an ask and a call to action.
Mobile accessibility has long since been an afterthought for a lot of people in the world. However, with the world turning more and more to using mobile applications, it is time for organizations and creators of mobile applications to make their content accessible.
At the end of the day, it doesn't take that much to make your application accessible. I have a challenge:
Designers:
- Use free annotations kits to properly annotate accessibility
- Ensure color alone is not used to indicate state or contain valuable information
- Ensure the application works in both orientations
Developers:
- Use testing tools (iOS a11y inspector, Android google scanner)
- Take advantage of the linters for iOS and Android
- Learn to use a screen reader (Talkback and Voiceover) and test your application
Scrum masters/Product owners:
- Prioritize accessibility in definition of done
- Include accessibility bugs in sprint planning
This is not everything or every role, but even doing these simple things above can help turn the tide to ensure we start building applications with accessibility in mind.
Thank you for following #MobileA11yAdventCalendar all month for tips and tricks on #Mobile #Accessibility ! Lets make the mobile world a more accessible place for all!
Top comments (0)