Don't have 2020 vision? Me neither! And we're not alone. The World Health Organization reports at least 2.2 billion people have a vision impairment or blindness, with about 15% of the world's population living with some form of disability.
In 2019 I read a lot of passionate articles on web accessibility like this one on dev.to by Charlotte on common mistakes and how to fix them. I also began my venture into coding mobile applications. With these topics swirling together I wondered - are there different accessibility considerations when building a mobile app? The answer is yes, and no!
The internationally recognized standard for web accessibility defined in the Web Content Accessibility Guidelines (WCAG) is written to evolve with technology. This means standards like contrast, text size, and consistent navigation are identical in desktop websites and mobile apps.
That being said, there are a few notable considerations unique to mobile applications.
So we're all on the same page, I'm using mobile as a generic term that encompasses a variety of devices that are easy to carry such as:
- phones and tablets
- digital TVs
- wearables such as smartwatches
- devices in car dashboards and airplane seatbacks
- devices in household appliances
- other “Internet of Things”
Touch Targets
This is the big one. The pixel density of mobile devices varies greatly. For this reason, the suggested target size is in mm not pixels! Your user should feel comfortable using the pad of their finger (or thumb!) to tap the target.
Best practices for touch target size:
- Ensuring that touch targets are physically 7 – 10mm wide. This size is equivalent to the smallest average finger. On a typical mobile screen, 9mm is roughly 44 by 44 CSS pixels - but again screen density varies. [2]
- Ensuring that touch targets are surrounded by a small amount of inactive space to help avoid mis-taps.
- If you want to use very small control targets, make an alternative, larger control available as well.
Screen magnification should not need to be used to obtain this size. That often introduces the need to pan horizontally as well as vertically, which can decrease usability. [3]
Benefits
- Where the touch screen is the primary mode of interaction
- Users with mobility impairments such as hand tremors
- Users who use a mobile device in environments where they are exposed to shaking such as public transportation
- Users who have difficulty with fine motor movements
- Users who access a device using one hand
- Users with large fingers, or who are operating the device with only a part of their finger or knuckle
- Users who have low vision may better see the target
Custom User Interface (UI) Controls
Android UI and iOS components have accessibility built-in with useful metadata in the default code for buttons, switches, checkboxes, etc.. This allows screen readers to speak these components out loud for blind and low vision users. It's recommended that whenever possible, use these baked-in controls to lessen the cognitive load and ensure you have appropriate labels! When you create your own custom views or components, you need to ensure they are accessible.
If you’re writing a pure native app, you’ll need to learn the Accessibility APIs (application program interfaces) available to the platform you’re coding.
For example, iOS uses Swift, not HTML, so there is no “alt” attribute available to explain what an image is about and make it accessible. To give images an accessible name, you'd use the .accessibilityLabel property.[1]
Further Reading:
- The A11y Project
- Dev article by Madalyn Rose on getting set up to manually test web accessibility.
- Apple developers human interface guidelines
- Google developer fundamentals on accessible styles (great visuals!)
References
[1] https://www.microassist.com/digital-accessibility/mobile-application-accessibility-part-2-of-2/
[2] https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile/design/touch-target-size
[3] https://www.w3.org/WAI/WCAG21/Understanding/target-size.html
Top comments (0)