App accessibility: Commonly overlooked accessibility practices for mobile apps
Accessible websites are still in the minority, but accessible apps are even rarer.
It’s hard to believe even with an approximately 80% smartphone penetration globally, most apps are still not accessible. Most companies still deem accessibility-related use cases as “edge cases”, and I’m not referring to small companies with limited budgets and headcounts, but rather companies that have the capacity and resources to provide sufficient accessibility practices for users with impairments and disabilities. Companies who do try to address accessibility often don’t go beyond surface-level design elements such as colours and contrast levels.
So, I’m not here today to discuss topics that have already been widely covered, such as color contrast, button size, image alt-text, or the use of icons, because learning materials about those are already ubiquitous. Instead, what I will do today is list some the things that are often overlooked in app design accessibility, to bring greater awareness to designers or engineers who are designing mobile apps.
In this article, we will still assume compliance according to minimum WCAG AA standards. I’ve had quite a few questions from my peers asking if WCAG is suitable for native mobile app design, WCAG is certainly not perfect but it is platform-agnostic, which means mobile app design can also follow a lot of the guidelines set out by WCAG, although some success criteria don’t apply or require compromises to achieve compliance.
Support landscape orientation display
WCAG reference: SC 1.3.4
Honestly, I think this is the most obvious and shocking one. A huge number of apps (if not, most apps) don’t support landscape orientation display. Even prominent apps that we are familiar with or use frequently don’t support landscape orientation display, such as Facebook, Instagram, Spotify, Reddit, and TikTok. And I have yet to see any banking apps, traditional or fintech, that support landscape orientation display. In my experience testing users with disabilities, a few of them have to rely on landscape mode as they have their devices mounted in a fixed landscape orientation (e.g on the arm of a powered wheelchair).
To be perfectly clear here, it’s not about providing landscape orientation display but it’s to ensure the apps support both portrait and landscape orientation display whenever possible, which means this applies to apps with the default display of landscape. Although some exceptions do apply here, for example, gaming apps, piano lesson apps, and any apps that require to be fixed on one display.
The lesson here is just because well-known apps don’t support certain accessibility criteria, it doesn’t mean they are not needed or they become the standard practice to be followed, it just simply means those well-known apps haven’t provided sufficient accessibility practices for users on those particular criteria.
Add a button on a pin/code input
WCAG reference: SC 3.2.1 & SC 3.2.2
In my opinion, this is one of the most often overlooked accessibility criteria in mobile app interaction. In a 2FA validation scenario, a huge number of apps, especially the ones that target a younger audience, are often in favour of not using a button but immediately validating the code without any final call-to-action button like ‘Confirm’. This violates the change of context rule in accessibility guidelines where users are experiencing a change of context without confirmation.
Unexpected changes of context can be disorienting for many users, in particular for those with visual disabilities or cognitive limitations. Therefore, a change of context should occur only when users activate a “Submit”, “Confirm”, “Apply” or other similar button commands.
And in my experience, I’ve had my fair share of defending this practice in a design review because many designers usually lean toward not using a button for confirmation because it’s “better” to do so, but the real question is “better” for whom?. If that means, sacrificing an extra second to tap on the button in order to make the design more accessible to the wider audience, what do we have to lose? And this is where our voice and candour are tested in product design, it’s our job to push against any inaccessible practices during design iterations, no matter how small it is. Letting any inaccessible practices take place in the design implementation could lead to adding design debt for the future, if we let these inaccessible practices enough over time to accrue, it will be ten times harder and costlier to fix them in production.
Provide multiple ways to navigate a page
WCAG reference: SC 2.4.5
As the title says, the goal here is to provide users with multiple ways to access a page or feature and not only rely on just one way. Because providing multiple ways of navigating to a page enables users to find information in the way that best meets their needs. Users may find one way easier or faster than another. For example, screen reader and screen magnifier users may find it easier to use a search than a large navigation bar.
For those who are not familiar with this success criterion, it’s natural to think that this success criterion is geared towards web pages, and not app design. Because there are already many familiar ways that allow users to access a page, such as using breadcrumbs, sitemaps, table of contents, pagination with clickable arrows and the page number itself, etc. But this success criterion can be applied to mobile apps too by providing a comprehensive search result via a search button or using primary and secondary navigation menus. While mobile apps are limited in providing ways to access a page, it can be done.
The interface can be controlled with just one finger
WCAG reference: SC 2.5.1
Here, we wanted to ensure any complex gestures have secondary options to ensure users with motor disabilities can still perform the actions. The idea is that the interface can be controlled with just one finger, and not rely on path-based or multipoint gestures (path-based or multipoint gestures fall under complex gestures). If complex gestures are offered, ensure that there is an alternative option that does not require complex gestures to go with them.
Examples of path-based gestures include swiping; such as range sliders, swiping left or right to delete or archive, navigating carousels by swipe, long pull down and release to refresh the page, and some smartphones’ unlocking screen mechanisms by completing custom complex gestures.
Examples of multipoint gestures include pinching to zoom in and zoom out, and tapping with two or three fingers to perform an action, for example panning or rotating a picture.
The good news here is that there are already good example apps that you’re probably familiar with for you to emulate, for example:
- Gmail app and Outlook app allow users to swipe email right or left to archive or delete emails, with the alternative option of pressing the avatar on the email to display a set of button icons that allow users to delete or archive emails.
- Zooming in and out pictures on Google photos or Apple photos can be done by pinching motion, the alternative option to zoom in and out is to double tap on Google photos or Apple photos on a particular area of the photos.
- Many apps provide chevron or arrow buttons to navigate cards or banners on top of swiping cards or banners.
- Some web browser apps like Chrome, Firefox, or Brave allow users to pull down to refresh with the alternative option of pressing reload button.
Avoid gesture-only to perform an action
WCAG reference: SC 2.5.4
Although it’s not very common to find apps that require gestures to perform an action, they do exist. The most common that you’ll come across is shaking the device. For example: shake to undo the last action and shake to send feedback (Instagram & Google maps). Other gestures also include tilting the phone, and gesturing toward the camera.
Some users with disabilities will not be able to move or gesture towards the device because the device is on a fixed mount (perhaps in a wheelchair) or due to motor impairments. Providing an alternative way to operate the device other than by motion will make it more accessible for these users.
Keep in mind that gesture to perform an action is allowed as long as there’s another mechanism to perform the same action without any gestures, for Google maps and Instagram example, ‘shake to send feedback’ is merely a shortcut, and users can still go to the account and select the action from there. An example where it’s not accessible is when there’s a gamification on the app such as ‘shake the dice’ and that’s the only way to perform an action. As intuitive and fun as it is, the gesture needs to be accompanied by another way to shake the dice to be accessible.
Support OS dynamic font scale
WCAG reference: SC 1.4.4
Your apps should react to font size increase on the setting. While this might be obvious but the fact is many apps ignore any font size changes on the setting on their OS, or if they do react to the font size increase, the container of the component or text is not properly adjusted, meaning there is a lot of text being cut off on the screen.
In my opinion, this is one of the complicated success criteria that requires compromise, because according to the guideline, contents need to be able to support font resize up to 200% but in practice, I find this is quite impractical and almost unreasonable to adhere to for native mobile apps. Before I elaborate on this point, I should note that there are elements of the app that should not increase in sizes such as the top and bottom navigation bar, tabs component, etc, so keep in mind that just because the font size is increased via setting, this does not mean it affects every single component.
While complying with this criterion for web pages on the desktop is fairly straightforward, where users need to zoom in their browser up to 200% and ensure that the content layout is still intuitive and there is no loss of information or functionality. It’s a different case for native mobile apps.
One example issue for iOS is that reaching 200% is simply not feasible, Glenda Simms has written a Google sheet displaying native Mobile iOS dynamic type and percentage of increase here. As you can see on line 68, even with AX5 on iOS, the “Large Title” style has only grown 176.47% from the default. Not reaching 200% on all font sizes.
So how do we solve this? for me, I interpret the success criterion a bit more leniently and function as a general guideline. As recommended by Alistair, I take a best-efforts approach, rather than a strict must-be 200% approach. This means I check how the design itself reacts to OS text and zoom settings, and see if there’s any crucial information or functionality that gets cut off by the font resize. So my rules are:
- Enable text-sizing up to 200% on body text.
- Allowing large titles to only reach around 150%.
- Most importantly, to ensure all other text is reflecting the size of the body text change so the heading relationships using relative sizes remain clear.
As you can see, not every single success criteria guideline is always written perfectly and applicable to all devices, and when that happens we need to apply a sensible and reasonable practice for that specific area.
Avoid automatic page refreshes
WCAG reference: SC 2.2.1 & SC 3.2.5
Have you ever noticed that when you switch to another app or lock your phone briefly and return to a social media feed or news app, the page automatically refreshes without any action on your part? This can be frustrating, especially for users with disabilities who may need more time to navigate and interact with the content. To make your app more accessible, avoid automatic page refresh and provide alternative ways to notify users of updates and refresh the page.
One way is to display a button (usually floating action buttons) or element that users can tap to refresh the page, along with an announcement that tells them about the update. You can also include a warning message that informs users of the upcoming refresh and gives them the option to extend the time to respond.
For iOS, you can use the UIAccessibilityScreenChangedNotification to notify VoiceOver when the layout of the app’s UI changes significantly and when elements are added or removed from the screen. This will ensure that VoiceOver updates the focus order and other accessibility attributes accordingly.
Additionally, for iOS, you can use UIAccessibilityTraitUpdatesFrequently to signal that a UI element’s contents are frequently updated and should be announced by VoiceOver. This is particularly useful for elements like stock tickers or weather apps.
For Android, you can send custom accessibility events for a view using the AccessibilityEvent() method in the Android framework’s View class. These events provide information to accessibility services, such as screen readers, about changes in the user interface.
End note
Accessibility design learning materials are still very much emphasised on web desktop platforms whereas, in reality, native mobile apps need attention just as much as web desktop accessibility despite some different implementations. I haven’t found enough materials that provide mobile app-specific accessibility guidelines out there apart from Google Material (plus android developer) and Apple Human Interface guidelines. Therefore, hopefully, this guideline helps a little.
My simple advice is to try your best to comply with accessibility standards, but bear in mind that the goal is not to be 100% accessible or perfect, furthermore, you should know that it’s also impossible to be 100% accessible and you should be cautious with anyone or anything claiming their product is 100% accessible. Accessibility compliance boils down to how your product is built and which criteria impact users the most in how you design the product, but you should never wait or aim for perfection in accessibility design.
Ps. Let me know in the comment if you find this helpful as I plan to make this App accessibility topic a series due to many other areas I haven’t touched here.
