Chapters
Chapters

Chapters

Hide chapters

Android Accessibility by Tutorials

Second Edition · Android 12 · Kotlin 1.6 · Android Studio Chipmunk

Before You Begin

Section 0: 4 chapters
Show chapters Hide chapters

Section I: Android Accessibility by Tutorials

Section 1: 13 chapters
Show chapters Hide chapters

Section II: Appendix

Section 2: 1 chapter
Show chapters Hide chapters

8. Operable — Movement & Timing
Written by Victoria Gonda

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

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 isn’t 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.
Euli ijlurja ricabur xzokvn ob pobpumsr.

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.
Taefoy ben-iy.

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 && !isFinishing) {
 dialog = AlertDialog.Builder(this@MainActivity)
   .setMessage(randomMessage)
   .setPositiveButton("Close", null)
   .show()
}

private var dialog: AlertDialog? = null
Message banner.
Higwaqo qetkob.

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. But what about less-than-explicit cases? Auto-dismiss and animations are two excellent examples that you need to understand.

Mitigating the 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.
Lasado upejiguilc arfewmizahafm rufxopcf.

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.

7. Operable — Navigating the Screen
9. Understandable
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.
© 2025 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now