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

Looking for more like this?

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

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
How to Prepare for our Associate Software Developer Position

How to Prepare for our Associate Software Developer Position

June 30, 2023

Tips for applying to MichiganLab's Associate Software Developer program

Read more
How to approach legacy API development

How to approach legacy API development

April 3, 2024

Legacy APIs are complex, often incompatible, and challenging to maintain. MichiganLabs’ digital product consultants and developers share lessons learned for approaching legacy API development.

Read more
View more articles