If you were asked right now to scope out a baseline of accessibility needs in your app, with details on how to implement them, could you articulate a plan in 5 minutes? Whether you have an already existing project, or a brand new app you’re working on, accessibility can sometimes be a daunting topic. At Michigan Labs, we have projects that specifically target users who need these features. Because of this, accessibility has become more and more important to us. I wanted to share this post with you, in case you need a plan quickly, and aren’t sure where to start. This won’t be comprehensive, but will touch on some of the major elements in order to give you a good, technical starting point. We’ll cover the following areas, which are platform agnostic, but also their React Native implementations as an example:
- Text Scale
- Screen Reader Text
- UI/UX Responsibility
Text Scale #
From my personal experience, the broader your user base gets, the more users you’ll find that set the universal text scale feature on their phone to the absolute maximum, or anything above the default.
This feature is available to help overcome low visibility across the entire OS. If you’re not prepared for handling it, these universal settings could override your UI and give the user a bad experience. How can we be prepared for this?
In React Native, for all <Text>
components, we must use the following props where applicable:
There are others, but these are the most basic props that have the most impact. What this is not, is a way to just ignore all of the font scaling accessibility settings. We don’t want to do this, but instead add a buffer of space in our UI, so that the user can increase/decrease font scaling to a moderate degree without breaking the experience.
After you’ve added these measures to control font scaling, how can we test this easily? In your simulator, you can typically just update the font scaling in the accessibility settings for the OS.
However, in iOS you can do this live via these steps:
- Run the app using Xcode
- Locate the log bar near the bottom of the screen
- Open the
Environment Overrides
window - Adjust the slider accordingly
Screen Reader Text #
When was the last time you’ve used a screen reader? If your answer is “never,” then I would encourage you to try it out on your phone.
- On iOS, go to Settings -> Accessibility -> VoiceOver -> toggle on
- On Android, go to Settings -> Accessibility -> Screen Reader / TalkBack -> toggle Voice Assistant / Use TalkBack
It’s amazing to experience your phone’s OS in an entirely different way. If you try a screen reader on an app you’re working on, you might realize how hard it would be for someone who’s visually impaired to use it.
Supporting a screen reader in your app has a few benefits beyond just accessibility for the visually impaired:
- It adds natural descriptions to the code in various elements of the app, which helps with onboarding or understanding the practical use-case of a component
- It forces us to better organize complex interactive structures, like forms or grouped controls
In order to properly support screen readers, we can use the following props:
- accessible={true} — This indicates that a component is an accessibility element, and its children are intended to be grouped into a single selectable component. Consider the following:
<View accessible={true}>
<Text>text one</Text>
<Text>text two</Text>
</View>
In this case, the children are intended to be grouped together. The screen reader won’t focus separately on each child.
- accessibilityLabel={“Some label”} — This is the text that will be read by the screen reader. By default, if you don’t include this prop, the screen reader will instead concatenate all
<Text>
children. Consider these examples:
Here, the screen reader will read “text one text two”.
<View accessible={true}>
<Text>text one</Text>
<Text>text two</Text>
</View>
Here, the screen reader will read “A text area”.
<View accessible={true} accessibilityLabel="A text area">
<Text>text one</Text>
<Text>text two</Text>
</View>
- accessibilityHint={“Some hint”} — Hints are read by the screen reader after the label. They’re intended to tell the user what the result of an action will be.
- On iOS, hints can be turned off in the VoiceOver settings
- On Android, hints cannot be turned off
How do we know what good screen reader text is, and isn’t? If you apply the same concept to alt
text on images, which is another way you can add accessibility, Harvard University published a very simple guide on choosing what to say.
Extra Notes
- Touchable components such as
TouchableOpacity
are by default set toaccessible={true}
- For a group of components, use the
accessible
prop on the parent to group the children into a single “selectable” component
UI/UX Responsibility #
There are many ways to implement more accessibility features in an app, such as accessibilityIgnoresInvertColors to help with photos when the OS color mode is inverted. However, the need for some of these must be clarified by designers, and not assumed as a requirement for developers.
Typically, we can assume the following areas are already being addressed in our designs, unless there’s specific concerns:
- Color contrast
- Fonts
- Default text sizes
- Colorblind friendly design
Conclusion #
If you incorporate these basic accessibility features into your app, you’ll have a great foundation and baseline that covers a large portion of user needs. Beyond this, it will depend on your own use-cases, and how deep you need to adhere to standards like WCAG.
WCAG is an accessibility standard for web content, however this doesn’t translate 1:1 with mobile development. Because of this, WCAG published guidelines to help bridge this gap.
In the future, I’d like to delve into more accessibility features to help developers create great software. Future topics include:
- Semantic hierarchy of content, and how it can impact the grouping of UI elements
- Using proper semantic UI elements, like buttons, links, tab groups, etc.
- Accessible design for users who are neurodivergent, have dyslexia, physical or motor disabilities, low vision, or use screen readers
Looking for more like this?
Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.
Kotlin Multiplatform
July 14, 2022A brief look at Kotlin Multiplatform Mobile, a newer cross-platform mobile application framework.
Read moreAdvanced Tailwind: Container Queries
July 28, 2023Explore some advanced web layout techniques using Tailwind CSS framework
Read moreMichiganLabs’ approach to software delivery: 3 ways delivery leads provide value
February 12, 2024Delivery leads ensure the successful execution of custom software development. They build great teams, provide excellent service to clients, and help MichiganLabs grow. Learn what you can expect when working with us!
Read more