Home Android & Kotlin Books Android Accessibility by Tutorials

8
Operable — Movement & Timing Written by Victoria Gonda

Timed content can be impossible for some people to consume. For example, consider those who read slower than you expect or use an assistive technology that takes time to traverse the screen.

Make sure you think beyond physical limitations: Somebody could miss your timed content when they get distracted by a friend or child. On top of that, some people find time limits to be stressful. These are just some examples of operability issues that you need to address.

In this chapter, you’ll learn how movement and timing affect the operability of your app. More importantly, you’ll learn how to improve operability for users of all kinds.

The following WCAG guideline will be the focus of this chapter:

Guideline 2.2 Enough Time: Provide users enough time to read and use content.

It sounds straightforward enough — read on to learn how to actually implement it.

Considering adjustable timing

When building an app, WCAG wants you to provide the user with several options to control the timing and give the user control over time limits:

Success Criterion 2.2.1 Timing Adjustable: For each time limit that is set by the content, at least one of the following is true:

Turn off: The user is allowed to turn off the time limit before encountering it; or

Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or

Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action, for example, “press the space bar”, and the user is allowed to extend the time limit at least ten times; or

Real-time Exception: The time limit is a required part of a real-time event, for example, an auction, and no alternative to the time limit is possible; or

Essential Exception: The time limit is essential and extending it would invalidate the activity; or

20 Hour Exception: The time limit is longer than 20 hours.

Level A

This criterion gives six options to consider for time limits. To summarize with two helpful points:

  1. Allowing the user to turn off or control a time limit.
  2. Determining that the restriction doesn’t apply because it’s a requirement for the function or over twenty hours.

Reviewing Taco Tuesday’s timing

Right now, if you don’t decide whether to try a recipe in the first 15 seconds, Taco Tuesday will automatically switch to the next recipe. This behavior is not compliant with Success Criterion 2.2.1.

Giving auto-update controls

For Taco Tuesday, you’ll fix the issues discussed above while also fixing it to comply with a related criterion:

Implementing auto-advance controls

Open root_preferences.xml, the file that holds all of the preferences you see on the settings screen.

<PreferenceCategory app:title="@string/display_header">

</PreferenceCategory>
<SwitchPreferenceCompat
  app:defaultValue="false"
  app:key="auto_advance"
  app:title="@string/preference_auto_advance_title" />
private val sharedPreferences: SharedPreferences
fetchTacoJob = viewModelScope.launch(Dispatchers.IO) {
 delay(15000) // 15 seconds
 fetchRandomTaco()
}
if (sharedPreferences.getBoolean("auto_advance", false)) {
 // ...
}
Auto advance recipes switch in settings.
Iago embobqa zasubaw qjuksz oc kucxatyy.

Managing interruptions

Interruptions are another example of events where timing matters. You may need to make adjustments to ensure your app is accessible. Consider the following criterion:

Dialog pop-up.
Voeyor fur-un.

Replacing the dialog

You’ll start by adding a view to hold the banner.

<TextView
  android:id="@+id/main_banner"
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:background="@color/colorPrimary"
  android:padding="@dimen/space_normal"
  android:textColor="?colorOnPrimary"
  app:layout_constraintEnd_toEndOf="parent"
  app:layout_constraintStart_toStartOf="parent"
  app:layout_constraintTop_toTopOf="parent"
  tools:text="@tools:sample/lorem" />
app:layout_constraintTop_toBottomOf="@id/main_banner"
app:layout_constraintTop_toTopOf="parent"
binding.mainBanner.text = randomMessage
if (dialog?.isShowing != true) {
 dialog = AlertDialog.Builder(this@MainActivity)
   .setMessage(randomMessage)
   .setPositiveButton("Close", null)
   .show()
}
private var dialog: AlertDialog? = null
Message banner.
Wopmeje yusjat.

Fixing the tests

The tests will still look for the dialog you just deleted, so you need to modify the tests’ logic.

Espresso.onView(ViewMatchers.withText("Close"))
  .perform(ViewActions.click())

Identifying time limits in your app

Some time limits are more overt than others. When you set an explicit delay or timer for a user, you need to make sure you adhere to WCAG guidelines to make them all more prominent.

Mitigating risk of adverse reactions

For some users, on-screen movement causes adverse reactions. Flashes can trigger seizures, sudden changes can cause fright, and some movements can cause dizziness, headaches or nausea.

Eliminating flashes

If your app includes things that flash or images that rapidly change, you may need to comply with this criterion:

Understanding compassionate motion

With this criterion, you’ll find that with animations, less really is more.

Remove animations accessibility settings.
Zayixo awexamaepp ayrajpacucuxw yuldottf.

Key points

  • Provide users with more than enough time to complete a task.
  • Give users control over any time limits your app imposes.
  • Make sure a user can pause or return to any auto-updated content.
  • Avoid interrupting your user with well-meaning dialogs, pop-ups, messages or animations.
  • Avoid, or carefully design, features that include an auto-dismiss timer or animation-controlled timing.
  • Make sure the user can easily control all speeds and extend any timers.
  • Avoid adding anything that flashes to an app.
  • Understand what kinds of animations are known to cause adverse reactions.
  • Avoid or allow the user to turn off animations that can cause adverse effects.

Where to go from here?

This was the final chapter about making your app operable. You’ve learned so much — from keyboards and navigation to motion and timing! Pat yourself on the back.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.

Have feedback to share about the online reading experience? If you have feedback about the UI, UX, highlighting, or other features of our online readers, you can send them to the design team with the form below:

© 2021 Razeware LLC

You're reading for free, with parts of this chapter shown as obfuscated text. Unlock this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

Unlock Now

To highlight or take notes, you’ll need to own this book in a subscription or purchased by itself.