Android Development iOS

The 5 Minute Accessibility Strategy

May 18, 2023
The 5 Minute Accessibility Strategy

If you were asked right now to scope out a base­line of acces­si­bil­i­ty needs in your app, with details on how to imple­ment them, could you artic­u­late a plan in 5 min­utes? Whether you have an already exist­ing project, or a brand new app you’re work­ing on, acces­si­bil­i­ty can some­times be a daunt­ing top­ic. At Michi­gan Labs, we have projects that specif­i­cal­ly tar­get users who need these fea­tures. Because of this, acces­si­bil­i­ty has become more and more impor­tant to us. I want­ed to share this post with you, in case you need a plan quick­ly, and aren’t sure where to start. This won’t be com­pre­hen­sive, but will touch on some of the major ele­ments in order to give you a good, tech­ni­cal start­ing point. We’ll cov­er the fol­low­ing areas, which are plat­form agnos­tic, but also their React Native imple­men­ta­tions as an example:

  1. Text Scale
  2. Screen Read­er Text
  3. UI/UX Respon­si­bil­i­ty

Text Scale #

From my per­son­al expe­ri­ence, the broad­er your user base gets, the more users you’ll find that set the uni­ver­sal text scale fea­ture on their phone to the absolute max­i­mum, or any­thing above the default. 

This fea­ture is avail­able to help over­come low vis­i­bil­i­ty across the entire OS. If you’re not pre­pared for han­dling it, these uni­ver­sal set­tings could over­ride your UI and give the user a bad expe­ri­ence. How can we be pre­pared for this?

In React Native, for all <Text> com­po­nents, we must use the fol­low­ing props where applicable:

There are oth­ers, 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 scal­ing acces­si­bil­i­ty set­tings. 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 scal­ing to a mod­er­ate degree with­out break­ing the experience.

After you’ve added these mea­sures to con­trol font scal­ing, how can we test this eas­i­ly? In your sim­u­la­tor, you can typ­i­cal­ly just update the font scal­ing in the acces­si­bil­i­ty set­tings for the OS.

How­ev­er, in iOS you can do this live via these steps:

  1. Run the app using Xcode
  2. Locate the log bar near the bot­tom of the screen
  3. Open the Environment Overrides window
  4. Adjust the slid­er accordingly

Screen Read­er Text #

When was the last time you’ve used a screen read­er? If your answer is nev­er,” then I would encour­age you to try it out on your phone.

  • On iOS, go to Set­tings -> Acces­si­bil­i­ty -> VoiceOver -> tog­gle on
  • On Android, go to Set­tings -> Acces­si­bil­i­ty -> Screen Read­er / Talk­Back -> tog­gle Voice Assis­tant / Use TalkBack

It’s amaz­ing to expe­ri­ence your phone’s OS in an entire­ly dif­fer­ent way. If you try a screen read­er on an app you’re work­ing on, you might real­ize how hard it would be for some­one who’s visu­al­ly impaired to use it.

Sup­port­ing a screen read­er in your app has a few ben­e­fits beyond just acces­si­bil­i­ty for the visu­al­ly impaired:

  1. It adds nat­ur­al descrip­tions to the code in var­i­ous ele­ments of the app, which helps with onboard­ing or under­stand­ing the prac­ti­cal use-case of a component
  2. It forces us to bet­ter orga­nize com­plex inter­ac­tive struc­tures, like forms or grouped controls

In order to prop­er­ly sup­port screen read­ers, we can use the fol­low­ing props:

  • accessible={true} — This indi­cates that a com­po­nent is an acces­si­bil­i­ty ele­ment, and its chil­dren are intend­ed to be grouped into a sin­gle selec­table com­po­nent. Con­sid­er the following:
<View accessible={true}>
  <Text>text one</Text>
  <Text>text two</Text>
</View>

In this case, the chil­dren are intend­ed to be grouped togeth­er. The screen read­er won’t focus sep­a­rate­ly on each child.

  • accessibilityLabel={“Some label”} — This is the text that will be read by the screen read­er. By default, if you don’t include this prop, the screen read­er will instead con­cate­nate all <Text> chil­dren. Con­sid­er these examples:

Here, the screen read­er will read text one text two”.

<View accessible={true}>
  <Text>text one</Text>
  <Text>text two</Text>
</View>

Here, the screen read­er 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 read­er after the label. They’re intend­ed 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 can­not be turned off

How do we know what good screen read­er text is, and isn’t? If you apply the same con­cept to alt text on images, which is anoth­er way you can add acces­si­bil­i­ty, Har­vard Uni­ver­si­ty pub­lished a very sim­ple guide on choos­ing what to say.

Extra Notes

  • Touch­able com­po­nents such as TouchableOpacity are by default set to accessible={true}
  • For a group of com­po­nents, use the accessible prop on the par­ent to group the chil­dren into a sin­gle selec­table” component

UI/UX Respon­si­bil­i­ty #

There are many ways to imple­ment more acces­si­bil­i­ty fea­tures in an app, such as acces­si­bil­i­tyIg­noresIn­vert­Col­ors to help with pho­tos when the OS col­or mode is invert­ed. How­ev­er, the need for some of these must be clar­i­fied by design­ers, and not assumed as a require­ment for developers.

Typ­i­cal­ly, we can assume the fol­low­ing areas are already being addressed in our designs, unless there’s spe­cif­ic concerns:

  • Col­or contrast
  • Fonts
  • Default text sizes
  • Col­or­blind friend­ly design

Con­clu­sion #

If you incor­po­rate these basic acces­si­bil­i­ty fea­tures into your app, you’ll have a great foun­da­tion and base­line that cov­ers a large por­tion of user needs. Beyond this, it will depend on your own use-cas­es, and how deep you need to adhere to stan­dards like WCAG.

WCAG is an acces­si­bil­i­ty stan­dard for web con­tent, how­ev­er this doesn’t trans­late 1:1 with mobile devel­op­ment. Because of this, WCAG pub­lished guide­lines to help bridge this gap.

In the future, I’d like to delve into more acces­si­bil­i­ty fea­tures to help devel­op­ers cre­ate great soft­ware. Future top­ics include:

  1. Seman­tic hier­ar­chy of con­tent, and how it can impact the group­ing of UI elements
  2. Using prop­er seman­tic UI ele­ments, like but­tons, links, tab groups, etc.
  3. Acces­si­ble design for users who are neu­ro­di­ver­gent, have dyslex­ia, phys­i­cal or motor dis­abil­i­ties, low vision, or use screen readers
David Crawford
David Crawford
Software Developer

Looking for more like this?

Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.

Kotlin Multiplatform
Android Development iOS

Kotlin Multiplatform

July 14, 2022

A brief look at Kotlin Multiplatform Mobile, a newer cross-platform mobile application framework.

Read more
Advanced Tailwind: Container Queries
Development Web

Advanced Tailwind: Container Queries

July 28, 2023

Explore some advanced web layout techniques using Tailwind CSS framework

Read more
MichiganLabs’ approach to software delivery: 3 ways delivery leads provide value
Process Team

MichiganLabs’ approach to software delivery: 3 ways delivery leads provide value

February 12, 2024

Delivery 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
View more articles