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>

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>

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>
  • 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

Stay in the loop with our latest content!

Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.

MichiganLabs named #1 iOS Development Company by MobileAppDaily
Business iOS Press Release

MichiganLabs named #1 iOS Development Company by MobileAppDaily

January 28, 2020

The report features leading iOS companies of the mobile app industry, who have made themselves known because of their exceptional app development services.

Read more
Three principles for creating user-friendly products
Business Design

Three principles for creating user-friendly products

January 25, 2023

Grayson discusses three guiding principles he utilizes when designing user experiences for products.

Read more
Looking for a Front-End Framework? Our View On Vue

Looking for a Front-End Framework? Our View On Vue

March 15, 2021

The programming world has always had its share of opinions. Our community loves debating everything from tabs vs. spaces to Vim vs. non-Vim to which frontend framework you should use. For me, the answer almost always comes down to: “Whichever, so long as it’s consistent across your project.” End of article. Thanks for reading!

Read more
View more articles