How to create an accessible app (and why you should)
Best practices that will enhance the quality of your mobile application
When it comes to mobile app development, many UX designers and developers overlook the importance of accessibility. Most apps are not adapted to those with some form of disability. Whilst many development teams see accessibility as a ‘nice-to-have’, it is crucial in today’s mobile world. Building your mobile application with accessibility in mind will drastically improve user experience as well as maximize revenue.
“We need to make every single thing accessible to every single person with a disability.” — Stevie Wonder
The importance of Accessibility
Approximately 15% of the world population suffer from some kind of disability or impairment. Since mobile apps increasingly play a major role in our everyday lives, it is peculiar to think that approximately 1 in 7 people might not have the same level of access that other app users have.
It’s a common misconception to think that accessibility is an optional feature in mobile app development. Both Android and iOS platforms offer developers accessibility tools to aid them in creating an accessible user experience for all users, including those with a disability or impairment. Besides, not only disabled people benefit from good accessibility: voice assistants like Siri and Alexa are becoming ubiquitous, and haptic feedback (e.g. vibrations) are a part of Google’s Material Design guidelines. Some people might want to navigate an app while driving a car or doing laundry, without having to touch a mobile device.
In addition to moral considerations, you can expand your user base by being more inclusive. From a business perspective, it makes perfect sense to try and reach that 15% of additional users. And last but not least, governmental institutions are starting to codify laws and regulations requiring equal access for all users. More on that later.
Since accessibility impacts apps in a positive way, one might wonder why it’s overlooked so often. There are a couple of reasons why. Both Android and iOS have an ecosystem that is evolving, meaning that all platforms are building new accessibility features. Many accessibility features are available to developers but it’s still a work in progress. Even when they are available, accessibility features often take practice to use well, and developers — not to mention UX designers — often don’t have any experience with them, making designing and testing difficult. Finally, unlike the Web Content Accessibility Guidelines (WCAG) for web, there is no established body that defines the accessibility standards for mobile applications.
Understanding Accessibility
I’ve talked about the importance of accessibility, but what exactly is accessibility? In simple words, accessibility describes the way in which products are designed in order to be fully accessible for users with a disability or impairment. These impairments and disabilities can have many different forms, so I’ll discuss the ones that are most relevant to mobile applications.
Vision
Users coping with some kind of visual impairment experience the most difficulty using a mobile application that is not adapted to them. Color blindness, vision loss or even complete blindness are three major impairments. In an accessibility context, sound, usually in the form of a screen reader, is often used to compensate for the missing visual information.
Hearing
Whether a user is deaf, has minor hearing impairment or has difficulties hearing sounds within a certain range, there is always a way to embrace a good user experience. Videos and sound clips can be enhanced with optional transcriptions or captions.
Mobility
People that have physical motor limitations might encounter problems while navigating a mobile application. Tapping or other forms of gestures need to be configurable so that a user is not bound to a specific gesture. Also, a gesture should never be a mandatory event since physical motor limitations should not restrict the navigational behavior of an app. Both Android and iOS offer users the ability to configure shortcuts for frequently used phrases or words, as well as timing between presses on the screen. The size of buttons (or other touchable triggers in apps) are also configurable.
Literacy
An often overlooked aspect of accessibility is accessibility for people with a learning disadvantage, like (functional) illiteracy, (functional) innumeracy, and digital illiteracy. And this is not just a problem in the developing world: the Dutch government estimates that 1 in 9 citizens between the ages of 18 and 65 has difficulty with reading and writing. The US National Center for Educational Statistics found in a 2003 survey that 1 in 7 citizens had a below basic level of prose literacy and 1 in 5 has a below basic level of quantitative literacy. Apps can better serve these users by using simple, short sentences, supported by clear, culturally recognizable iconography. Voice feedback is also an option. Implementing accessibility solutions for any one of the previously stated disabilities is not enough to make an app accessible. Ideally, all aspects are taken into consideration when designing and developing a mobile application to ensure everyone can have a good user experience.
“Accessibility allows us to tap into everyone’s potential.” — Debra Ruh
Best practices
Now that we’re familiar with the different obstacles, it’s time to look at possible solutions to improve accessibility.
One of the most important aspects is consistency. Consistency is always a major UX guideline, but it pays dividends for users with a disability. For instance, finding an inconsistently placed home button is even more difficult when you can’t see the screen.
And don’t just have a consistent experience across screens. Have a consistent experience across interfaces: whether using sight, touch or hearing, every user should experience the same UX.
Note: Notwithstanding the fact that accessibility features will enhance your app in the absolute right way, these features should solely be used for the purpose of helping disabled users to interact with your app. I’m not sure the message here is clear. “Don’t use accessibility features for easter eggs”? That sort of thing?
Navigation
Buttons and URLs should not be directly inline with the content of your screen. Instead, actions should be clearly marked as an action, separate from the text. Changing the text style (e.g. underline/bold) will clarify these actions as well.
And although consistency is mentioned earlier, extra emphasis is needed when discussing navigation. Users with cognitive limitations will benefit from a consistent layout. Even fully blind users will understand an app layout right away when a mobile application meets either the Material Design guidelines from Google or the Human Interface Guidelines from Apple.
One last important guideline is to warn users when a navigational action leads to an environment outside the app. You never want users to close your app by accident.
UI
An important aspect to keep in mind is that your mobile application can be viewed in different resolutions. Users have the option to zoom in up to 200%. Your app needs to be tested at different resolutions in order to confirm a good user experience.
Color handling is also important. There should be a clear contrast between foreground and background. Placing light text in front of a white background, or dark text in front of a black background will make content hard to read. The result might be difficult to read for most users, but it could be impossible for someone with a visual deficiency.
Content
As for the actual content, in addition to contrasting text coloring, the font style of the text is also something to take into consideration. While a fancy font can be appealing to some, it might be unreadable to others. Be cautious when using fonts that are cursive or curly. When in doubt, please use the suggested (or default) font that corresponds to the font used in the, previously mentioned, guidelines.
Images can also detract from the user experience when an app is not adapted for accessibility. It gets worse when images are used in a non-decorative way. For these images, you should provide content descriptions. That way, users with a visual impairment can get the same user experience as others since the text-to-speech readers on their devices will convert text into sound. These image descriptions should detail what’s happening in the image. They can also describe how a particular image is related to the text. However, a description text should not repeat what the surrounding text is already saying. Repeated phrases in short succession may confuse the user or come across as a bug. In short, decorative images (or images that contain no additional information) should be ignored by accessibility tools.
Video and audio content should also be adapted for accessibility. All media player controls should be usable by anyone. For example, hearing impaired users must be able to change the volume of the media that is played. And for whom turning up the volume is insufficient, transcriptions are essential when a message is conveyed through a video or audio clip.
Testing
All professional software products ought to be thoroughly tested before deployment to production, in order to assure the quality of that product. In case of accessibility, a tester is able to check whether accessibility tools are implemented correctly. However, if you want to ensure that people with a disability will have a good UX experience, it’s advisable to gather a beta group of people with impairments. Colleges, universities or local organizations might be able to help finding this group of testers.
Main differences between Android and iOS
The core concepts of accessibility apply to all (mobile) platforms. UI and design choices should make a software product accessible for everyone. However, each platform has its own accessibility solutions. In this section, the main differences between the two major mobile platforms are described.
Screen readers
In order to ensure that users with visual or learning impairments have access to the same data, screen readers are often used to transform text to speech. That way, users can hear instead of reading the content. Screen readers are platform specific. Android offers Google Voice Assistant (previously TalkBack) while iOS offers VoiceOver. Screen readers treat the entire user interface as components. By use of gestures, these components can be navigated. Every newly highlighted component is read out loud. By default, the hierarchy of these components is based on position from left to right, and from top to bottom. The gestures used for navigating are fairly similar for both platforms.
Keyboard differences
Some relevant differences exist between Android and iOS when it comes down to keyboards. For Android, users can use a bluetooth keyboard for navigation. This behavior is similar to navigating on a desktop computer. However, iOS is not operable solely by keyboard. VoiceOver needs to be turned on, leading to some limitations in navigation, when compared to Android. Android even supports external braille keyboards when used with the accessibility tool BrailleBack.
Legal implications of Accessibility
The EU is discussing ways to enforce accessibility with regulation. The European Accessibility Act is a proposed law aiming to improve accessibility for services and products. As soon as this act is fully approved, the European Union will have three years to come up with explicit rules that will benefit people with disabilities.
So, offering everyone access to you product is not only the ethical thing to do, but you may also find yourself legally ahead of the curve.
Conclusion
By developing a mobile application with accessibility in mind, you will be able to provide a good user experience to all users. Accessibility comes with a wide array of potential financial, moral and legal benefits. Both Android and iOS platforms offer various tools to incorporate accessibility solutions in your app. There is basically no legitimate reason to ignore the concept of accessibility.
Accessibility isn’t just a feature. It’s a must for every mobile application.