Accessibility and React Native — From 0 to 100
A year ago, as a mobile app developer I was tasked with making an app accessible. The app was written using React Native and had not been designed with accessibility in mind. If you’re about to undergo a similar activity in React Native, I believe this story will help you hit the ground running (or at least speed walking).
Phase 1 — Understand what’s in your tool kit
When starting out, I didn’t have much experience making apps accessible. If you’re in the same boat as I was, you’ll need to know what tools are available. Spend time reading Apple and Android’s accessibility documentation. One of my favourite accessibility features (which iOS provides out of the box) is the escape function. It allows the user to easily navigate back and close modal dialogs with a ‘Z’ shaped gesture. This is much nicer than making the user swipe left many times until they hit the back or close button.
Phase 2.0 — Find out how accessible the app currently is
If you’re lucky, you may be surprised at how accessibility friendly the app already is. This has been my experience with native apps. The operating system tends to “know” what to do with all of the views and controls in a native app. This is not the case for React Native apps. The operating system may not even know if you’re currently selecting a button, a label, or an image. To find out, turn on Voice Over, load the app, close your eyes and try to use it. This is certainly not fool proof. It’s likely that you’ve already developed a mental map of how the app works.
Phase 2.5 — Sit down with someone who’s vision impaired
Sitting down and watching someone with vision impairment use a phone or tablet is a mind blowing experience. The way they navigate the operating system and their favourite apps is incredible. Their proficiency at using well designed/thought out apps will astound you. Next, have them install your app. How well your app employs accessibility metaphors will soon become apparent. This is a great opportunity to find out where the app needs accessibility improvements. Take note of this person’s favourite apps. Find similarities between those apps and yours, make changes accordingly. The more uniform the experience, the better.
Phase 3 — Time to write some code
Here are some general rules I’ve found to be true when making apps accessible.
More is more
Whenever you have a control, add all of the accessibility information you can. At a minimum, implement the following properties
- accessibilityRole (button, text, link, etc.)
- accessibilityLabel (when the operating system can’t derive a useful read out on what this control does)
- accessibilityHint (when the label alone won’t tell the user what’s going to happen when they click it)
- onSubmitEditing (when the control is a text input, ensure hitting return fires the same action as swiping away the keyboard and hitting the button next to the text input)
More really is more
For list items, it can’t be stressed how important it is to programatically create your accessibilityLabel. Let the user know the following:
- Which element in the list is currently focussed
- What place in the list is this element at (e.g. “result 3 of 5 is selected. It is a blah”)
- If this is a section list, we also want to know which section we are looking at in the list. (e.g. “result 3 of 5 in section XYZ is selected. It is a blah”)
Ask, is this helpful?
Some elements in a UI are not helpful to visually impaired people. An example might be a map where the user has to hold their finger over a point of interest to get some information. A better solution may be to simply disable the map, and allow the user to search for the location using text or voice. Alternatively list the ten nearest points of interest to the user. Accessibility can be disabled on elements using the accessible property.
Don’t be too clever
Use autofocus sparingly. It may seem like a good idea to autofocus on certain elements in your app. Perhaps the user has just entered some text and hit return. It may sound like a good idea to have the app automatically jump focus to the first result. Sometimes this may be helpful, but often it’s just confusing to the user. It is my understanding that visually impaired users are used to having to navigate to results after hitting search buttons. Allow them to do this; it’s almost always the better option.
Be a little clever
In the above example, when results appear on screen, rather than setting focus on the first result, announce to the user whether or not results are available.
Always hold hands
Make it incredibly obvious when an action is going cause navigation in the app. Nothing is more confusing than going back three screens un-announced and (potentially) not knowing which screen you’re currently on and why you’re on it.
Watch out for the Phantom Menace
Sometimes views are created simply to fill space. I’ll refer to these as phantom views. Generally the operating system is smart enough to not focus on these in accessible mode, but not always. It’s best to disable these using the accessible property.
Avoid buttons inside buttons
Generally, this is a problem when a list of items are selectable, but each also has some custom actions. Perhaps there’s a list of items and tapping an item takes you to a screen which shows that item’s information, but in the same row there’s a small link which allows you to edit this item. If the entire row is touchable, the operating system will not be able to select the link inside it. The outermost touchable element, is the only element Voice Over can select. Consider redesigning it so that link is on the next screen, or in accessibility mode, don’t make the entire row touchable, allowing the inner link to be exposed to Voice Over.
Phase 4 — Test the app and make changes
This is similar to phase two, but now you have a better idea of how the app will be used in accessibility mode. Remember, not everyone uses the on screen reader the exact same way. Connect a Bluetooth keyboard to your phone; learn how to use this keyboard properly. You may be surprised at how differently the app behaves, because typing on a keyboard is much faster and pressing the return key feels natural.
To conclude
The earlier in the design cycle accessibility is considered, the easier it is to implement. Both iOS and Android provide developers with many tools in making apps accessible to more users. As Facebook have slowly been exposing more and more accessibility features through the React Native API, it’s making the developer’s job easier to create React Native apps in line with native apps. If you want your app to be used by as many people as possible, make your app accessible!
