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:

• max­Font­Size­Mul­ti­pli­er
• min­Font­Size­Mul­ti­pli­er — iOS only
• allow­FontScal­ing

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