11. Designing for Neurodiversity

Written by Tori Gonda

Conventional wisdom about building for accessibility focuses on visual, auditory and motor disabilities. But another important consideration is neurodiversity.

Neurodiversity, for the sake of this discussion, is the natural variance between people’s neurological structure and function. Brains are remarkably complex, so each human experiences and interacts with the world in wildly different ways.

When you design an app, it’s just as important to consider users with lesser-known syndromes, such as Williams Syndrome (a developmental disorder that can interfere with visual and spatial reasoning), as it is to consider those who live with anxiety. Being inclusive of these users creates a better experience, which increases their happiness and loyalty to your product. Inclusive design also gives all of your users a better experience.

This chapter can’t cover every experience out there — each person is unique. However, it will give you tips to make your app more usable and enjoyable for all, including those who live with autism, dyslexia, anxiety and ADHD.

Some of the things you’ll learn to do in this chapter include:

• Reduce time stress

• Communicate with clarity

• Provide help

• Be consistent

• Watch phrasing

• Give alternatives

• Add configurability

Many of the solutions in this chapter will positively affect your Taco Tuesday experience, even if you don’t identify as neurodiverse.

You’ll continue improving Taco Tuesday, so open the project you’ve been working on or the starter project for this chapter. With that done, move on to the first topic: Reducing time stress.

Reducing Time Stress

Imagine you’re filling out a form on your phone. Now, quick! Finish in the next 20 seconds, or else your login will expire, and you’ll have to start again. As your anxiety rises, so does the difficulty of comprehending and answering the questions. Ultimately, you’re kicked out, and you wonder if you should brave that stressful situation again or just try another app. You’ll probably find another app.

Arbitrary or unavoidable time limits make apps unusable for some people with motor or vision disabilities. They can also induce anxiety responses. Some people need more time to read than you might think, and time limits interfere with their ability to comprehend and act.

WCAG wants you to avoid imposing arbitrary time limits. When you do need time limits, allow the user to extend the time whenever possible. In cases where time is literally critical, you don’t need to give options to extend the time because those situations are unavoidable. Examples include a time-based game or when there’s a physical inventory that is being quickly depleted.

When you implement timed tasks in your app, be critical and find ways to improve the experience by giving people more time or other options.

Introducing Time Configurability

In Chapter 8, “Operable — Movement & Timing”, you worked with the auto-advance timer on the recipe cards in Taco Tuesday. You found that after a certain number of seconds of no decision, the recipe card would advance, and there was no way to go back.

You added a toggle for the time limit to resolve the issue, putting the control into the user’s hands.

There’s another option, which you’ll work with now: Make this time limit configurable. Some users might appreciate a nudge if they haven’t made a decision. Others will prefer more time to read and consider. Others might opt out of time limits altogether.

You’ll add these options to Taco Tuesday. Start by adding the following to strings.xml:

<!-- 1 -->
<string name="preference_seconds_title">Seconds for auto advance</string>
<!-- 2 -->
<string-array name="time_options">
 <item>10</item>
 <item>15</item>
 <item>20</item>
 <item>30</item>
 <item>50</item>
</string-array>

Here, you’re setting up resources for:

1. The title of the preference you’ll add to the settings screen
2. Seconds for the options of this preference

Next, go to root_preferences.xml. Below the SwitchPreferenceCompat with the key value of auto_advance, add:

<ListPreference
 android:defaultValue="15"
 android:entries="@array/time_options"
 android:entryValues="@array/time_options"
 android:key="time_length"
 android:title="@string/preference_seconds_title" />

This sets up a preference to use the resources you’ve created.

Finally, to put it all together, in DiscoverViewModel.kt, find fetchRandomTaco(). Find the top of the if block where you’re already checking shared preferences to see if the auto advance is on.

Add this statement within that if block:

val seconds = sharedPreferences.getString("time_length", "15")
  ?.toIntOrNull() ?: 15

This code fetches the set number of seconds from preferences, defaulting to 15 if it’s unset.

To use this value, replace the call to delay() with:

delay(seconds * 1000L)

With this call, you convert seconds to milliseconds then set the length of time before the app auto-advances to the next recipe.

Confirm that the updated section of the method looks like this:

if (sharedPreferences.getBoolean("auto_advance", false)) {
 val seconds = sharedPreferences.getString("time_length", "15")
   ?.toIntOrNull() ?: 15
 fetchTacoTimer = viewModelScope.launch(Dispatchers.IO) {
  delay(seconds * 1000L)
  fetchRandomTaco()
 }
}

Build and run. Confirm that you have control when auto-advance is turned on and that you can set the interval.

Communicating with Clarity

Regardless of users’ abilities, you need to make two things clear: How to use the app and what happens after taking an action. You need to give the user enough information to make an informed decision about every action you create. Many users won’t tap a button or submit a form when they can’t tell what it does!

Buttons, in particular, can induce anxiety when they’re poorly explained. The user may wonder if they get a confirmation screen after tapping “Submit” or if their card was charged. Or if they’ll receive a barrage of spammy emails.

There are a few best practices to know:

1. Ask the user to confirm their choice, especially in a multi-step process.

2. Anticipate the questions a user might ask and build the answers into the app. For example, “Are there more steps to complete the process, or is this the last one?”

3. Assume that features and next steps are unapparent to most users.

Any clarity you can provide will reduce cognitive overhead and give your user a smoother, more enjoyable experience.

Clarifying When a Recipe is Saved

In Taco Tuesday, it’s unclear when it saves changes you’ve made to a recipe. You’re left guessing. You can’t undo and there’s very little control. The only way to know is to close the app and get back into the recipe.

In reality, the recipe saves when you leave the screen. This use case is an excellent example of why you need to anticipate user questions. You’ll clarify the experience, so the user isn’t left guessing.

Open strings.xml and add this resource:

<string name="recipe_detail_save">Details will be saved when exiting the recipe.</string>

Now, open fragment_recipe_detail.xml. Add this text view above the recipe_detail_made_it CheckBox:

<TextView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:paddingTop="@dimen/space_normal"
 android:paddingBottom="@dimen/space_normal"
 android:text="@string/recipe_detail_save"
 android:textAppearance="@style/TextAppearance.AppCompat.Caption" />

This logic informs the user when their changes are saved.

Build and run. Open the first shown recipe’s details, make some changes to it, and then observe the new message.

There are more best practices you can lean on to improve your app’s clarity, for example:

• Eliminate long blocks of text
• Explain images
• Limit distractions

Eliminating Long Blocks of Text

Unless you’re settling in to read a long-form article, you’re unlikely to read more than a few lines of text. The same goes for your users.

Walls of text are hard to consume. They can feel like too much to process at once or make somebody feel burdened. Text walls are also a great reason to get distracted with another app. And let’s face it: They’re often poorly written. In particular, long text blocks can be stressful for people with dyslexia, autism or cognitive decline.

In Chapter 9, “Understandable”, you touched on this when you reduced the text on the discover screen, so it’s more appropriate for the role of the view.

When you’re preparing copy for your app, opt for short sentences, short words, clear directions and bullet points instead of paragraphs.

You can also lean into diagrams and images when there is a lot of context to share.

For many, diagrams are easier to process than walls of text.

Formatting Text

When you do have areas of text, format it such that:

• It’s justified towards the start of the screen.
• It’s free of unnecessary formatting such as underlining, italics or uppercase.

Removing these formatting attributes makes your text easier to read, especially for users with dyslexia.

Explaining Images

When your app has images, it’s your job to enable the user to assign meaning to them. Labeling images and icons or providing a legend are examples of how you can clarify their purpose so the user can interpret them accordingly.

Everyone interprets images differently. Think about all the times you’ve seen a star icon in an app. Does the star indicate a way to rate something? Or does it favorite something? Does it give you a badge or add something to a private list? Without an explanation, some users will never understand this poor star’s purpose!

Each user has a different ability to assign meaning to imagery. The better you describe these images, the clearer your app will be, and the less likely your user will get distracted or discouraged from using your app.

Limiting Distractions

Speaking of distractions: Do your best to limit them. Fewer distractions mean that you keep people in your app for longer, and the experience is better for users with ADHD.

Distractions can include a popup or something that branches off the main flow of your app. Another example could be that the user has to close the app to adjust a setting before using it. Distractions can become points of friction in your UX.

When building an experience, think about points of friction and if the user benefits more from branching off to other tasks or staying focused on the task at hand.

Providing Help

Have you ever had a question or problem with a product and became frustrated because you couldn’t get the answers you were looking for? A point of frustration is an example of friction.

Reduce friction in your app by making help readily available, and don’t make users jump through hoops to get answers. Hunting around for help can trigger anxiety or discourage someone from using your app.

You can add help inline, as an FAQ, or as a help center with access to avenues like email, chat and calls. Whatever option you implement should be easy to find and access.

Adding Help

Now that you know you need to add a help option to your apps, you’ll practice by adding it to Taco Tuesday.

Open root_preferences.xml. Within the PreferenceCategory under the help header, add the following:

<PreferenceScreen
 android:title="@string/preference_book_forum_title">
 <intent
  android:action="android.intent.action.VIEW"
  android:data="https://forums.raywenderlich.com/c/books/android-accessibility-by-tutorials/74" />
</PreferenceScreen>

This code adds an option to the settings screen that allows the user to post on a help forum for this book. Build and run to see this change.

Achieving Consistency

In Chapter 9, “Understandable”, you learned about using consistent layouts, which benefit those who use assistive technologies and reduce confusion for neurodiverse users. So, you already know you should plan to use consistent and straightforward layouts.

You want each part of your app to be as predictable as possible, with similar elements performing similar behaviors regardless of where they’re used.

Similarly, you also want to be able to expect changes in context. Don’t change to a different screen or context without user action unless you let them know about it first. Otherwise, the change could confuse the user about where they are in the app and how they got there.

Minding Your Phrasing

Language and phrasing significantly impact your app’s user experience. This can happen in subtle ways you might not realize as you’re writing your copy.

When you’re careless about the words you use, your copy could be misunderstood. In other cases, your words can negatively impact users.

Providing Consumable Language

Here are three best practices to follow:

• As noted in Chapter 9, avoid figures of speech, jargon, idioms and complex language.
• Be descriptive and succinct.
• Use simple words.

People on the autistic spectrum or who do not use English as a first language may interpret phrases in your app literally. Read the copy in your app through a literal filter to see if it makes sense.

And if you’re having trouble “wrapping your head around that”, maybe that’s because skulls are rigid and aren’t meant to wrap around things. Please don’t give yourself a concussion trying. (See what I did there?)

Using Inclusive Language

Derogatory language has no place in most apps. Make your copy inclusive of all people, regardless of who they are.

This includes ability. For example, don’t use terms like “crazy” or “idiotic”, as these are derogatory words for people with disabilities. Use terms such as “outrageous” or “misguided” instead.

These shifts in your language remove some of the ableism, and they make your message more precise and descriptive.

Other words to avoid are more nuanced, such as “easy”, “clearly” and “just.” Something easy or clear for one user could trigger anxiety for another. When you say to “just” follow this instruction, you imply that it is easy for everyone.

The wrong words can be incredibly discouraging and make your user feel excluded. Make your user feel welcome by using inclusive language.

Giving Alternatives

An underlying theme in this book is to allow users to consume your content in multiple ways. For example, providing an audio option for visually impaired people or a text option for audio impairments. Graphics and video can also be useful alternatives.

Giving options also makes your app more usable for people with dyslexia.

There are more options you can provide. One example is reminders. Especially useful for a multi-step process, prompts help the user remember content from previous pages.

Whenever possible, allow users to input inaccurate spelling. Even with autocomplete, it’s easy to misspell words. Unless correct spelling is critical for the app, try to find a way to accept inaccuracy.

Supporting Configurability

To close out the chapter, you’ll turn your focus to one of the best things you can do: making your app configurable. Each user has unique needs and preferences. Some people need light mode while others need dark. Some prefer text labels and other logos. Some want confirmation for everything, and others prefer fewer clicks.

Adding configurability allows your app to meet the needs of more people. This gives all your users a more tailored, and therefore enjoyable, experience.

Adding a Dark Mode Option

To demonstrate the concept of configurability, you’ll allow the user to toggle between dark and light mode directly from Taco Tuesday.

Open root_preferences.xml, and add this to the Display PreferenceCategory:

<SwitchPreferenceCompat
  app:key="dark_mode"
  app:title="@string/preference_dark_mode_title"
  app:useSimpleSummaryProvider="true" />

This block allows the user to set the dark mode preference on the settings screen.

Next, open SettingsFragment.kt. Add this to the bottom of onCreatePreferences():

findPreference<SwitchPreferenceCompat>("dark_mode")
 ?.onPreferenceChangeListener =
  Preference.OnPreferenceChangeListener { _, newValue ->
   AppCompatDelegate.setDefaultNightMode(
    if (newValue == true) {
     AppCompatDelegate.MODE_NIGHT_YES
    } else {
     AppCompatDelegate.MODE_NIGHT_NO
    }
   )
   true
  }

You’ve set a listener on the dark mode setting so that when the user changes the setting on their device, it’s immediately reflected in the app’s color scheme.

Finally, open TacoTuesdayApp.kt. Add SharedPreferences as a property:

@Inject
lateinit var sharedPreferences: SharedPreferences

You’re injecting SharedPreferences to use in the next step.

At the bottom of onCreate(), delete the lines:

AppCompatDelegate.setDefaultNightMode(
 AppCompatDelegate.MODE_NIGHT_FOLLOW_SYSTEM)

And replace them with:

AppCompatDelegate.setDefaultNightMode(
 if (sharedPreferences.getBoolean("dark_mode", false)) {
  AppCompatDelegate.MODE_NIGHT_YES
 } else {
  AppCompatDelegate.MODE_NIGHT_NO
 }
)

Now, when the app starts, the color scheme will be set according to the preferences.

Build and run. Toggle this setting and confirm that it’s working correctly.

Key Points

• Being inclusive of neurodiverse users makes your app better for everyone.
• Reducing time constraints can reduce user anxiety.
• Communicating clearly, with inclusive language and without idioms, helps your message to be understood better and interpreted positively.
• Reading long blocks of text is difficult for many users.
• Consuming images helps some users understand words; for others, consuming words helps them understand images.
• Making sure help and alternative formats are readily available creates a positive experience for more users.
• Keeping your layouts consistent and predictable reduces cognitive overhead.
• Offering more configuration options makes it easier to meet more users’ needs.

Neurodiversity is often overlooked in the already neglected topic of accessibility. Congrats to you for learning about how to improve your apps in this way!

Where to Go From Here?

All of these guidelines and best practices can be hard to remember. For a visual reminder, check out these posters.

You can also use the accessibility checklist found at the end of this book.