In most of my previous posts, I have spoken about accessibility on desktop websites. Today, I will be writing about common accessibility problems on mobile applications. The number of people who use mobile applications on smartphones and tablets is steadily increasing.
I myself do all of my online shopping and banking through apps on my iPhone and iPad. While I find apps to be more user-friendly and exhibit fewer accessibility bugs than websites, the experience is far from flawless.
I have found that some companies offer a solid accessibility experience on the website but a poor one on the app. As more customers rely on mobile, companies should consider the app as a key part of their overall accessibility portfolio.
As always, I will be exclusively covering screen reader accessibility in this post. Mobile screen readers work differently than desktop-based screen readers, but I'll explain more later.
1. I need large touch targets for mobile buttons.
I recently did a post exclusively covering button accessibility for screen readers- read it here. Buttons are even more critical on mobile applications because users find themselves moving back and forth between different sections of the app far more frequently due to the smaller display sizes on mobile devices. Screen readers on smartphones and tablets are primarily touch-based. As a result, users must be able to locate navigation and action buttons in apps by direct touch.
I have encountered so many apps where the touch targets for the buttons are so small that it takes three or four attempts to touch the screen in exactly the right spot to select the button. When I say touch target, I am referring to the area of the screen around a given button that is part of the detectable area for a press of that button.
This issue is most common on the bottom app navigation bars and with the back button.
2. Label your symbols.
Because the screen of real estate on mobile apps is so limited, common design practice uses visual symbols and graphics to represent buttons and actions. For example, the bottom tab bar of a shopping app may have a graphic of a house to represent “Home,” an image of a physical shopping wagon to represent “Cart,” an image of a magnifying glass to signify “Search,” and a symbol of a head to convey “Account.” In many cases, there is simply not enough room to also include the word associated with each symbolic graphic.
This is generally not a problem for sighted users because most people have gotten used to the meaning of universal digital symbols. The issue is that in many cases, app developers do not include labels in the code for each symbol-based button for assistive technology dependents. It is not an issue of screen size limitations because the labels are embedded in the code and if implemented correctly, are not visible on screen.
Unlabeled graphic-based buttons are either completely ignored by screen readers or announced as meaningless terms such as “Image,” “Button,” or “Graphic.” All image-based buttons on mobile applications must have corresponding text labels in the code to be understood.
3. Media player problems are common.
It is very common to come across video-based media in mobile applications, from product detail videos to repair how-tos. On desktop systems, the space bar will almost always work universally as a play/pause button for videos. This is, unfortunately, not an option on mobile devices because most people do not use them with a keyboard. The screen reader experience for using the media playback controls in apps is a clunky mess. I have found that in many cases, the screen reader will repeatedly speak the position of the time playback head on the seek slider, completely blocking out the auditory content of the video. The only way to remedy this is to disable the screen reader which is an unacceptable solution to an accessibility problem.
In other cases, the play/pause button is not locatable or actionable by a screen reader because the controls disappear before the user has a chance to find and click the button.
A persistent media controls option in the app’s settings can remedy this problem. Such a setting will allow the user to keep the media controls on the screen at all times even if they visually block the video. I love it when apps use this option; it works extremely well in my experience.
4. The keyboard in mobile applications can be trouble for accessibility
There is one recurring flaw related to the keyboard that I encounter on a regular basis. If there is a screen with a text field toward the top and some sort of action button near the bottom of the screen such as “Search,” “Continue,” or “Log In,” invoking the keyboard will cover that button. The problem is that at this point, there is no way to scroll the screen down using the mobile screen reader to expose the action button. Typical scroll gestures do not work. Using manual swipe navigation does not seem to work either.
Once I get to the part of the screen that disappears behind the keyboard, the screen reader’s focus switches to the keyboard itself when swiping. Oddly enough, there is no way to manually dismiss the keyboard. At this point, I am completely stumped.
5. You can improve mobile app accessibility
While apps may share some accessibility issues found on websites, there seem to be some reoccurring bugs that plague apps specifically. As a blind customer, I'd want companies and app developers to know that app-accessibility should never be overlooked. Apps are a huge part of my experience with your company.
If you need help, UsableNet provide accessibility technology and services that can help you with app accessibility- request a call. UsableNet also has some more free resources like our popular blog, the 6-Step, mobile app accessibility checklist- read it here.
