Android Accessibility Fundamentals

Think of the last time you used your phone in bright sunlight, with one hand, while carrying something. The screen was hard to read, buttons were hard to hit, and you wished the app were simpler. For a moment you experienced what many people live with every day. Accessibility means building apps that work for everyone: people who are blind or have low vision, who are deaf or hard of hearing, who have limited movement, who have dyslexia or other cognitive differences, who are older, who are tired, or who are simply in a noisy bus on Ojota road.

This lesson is the first of three accessibility lessons (46–48). It covers the Get started with Android Accessibility, Accessibility in Android, Accessibility Services and the Android Accessibility Model and Common accessibility problems items of the Make your Android app accessible pathway (https://developer.android.com/courses/pathways/make-your-android-app-accessible). Lesson 47 shows how to fix problems in Compose, and lesson 48 shows how to test.

By the end you will be able to:

• Explain who benefits from accessibility and why it is good design, good business and, in many places, a legal requirement.
• Use Android's accessibility settings yourself: TalkBack, Select to Speak, font and display size, colour correction and inversion, Switch Access, Voice Access and captions.
• Describe the Android accessibility model: how an app exposes information to an accessibility service.
• Recognise the six most common accessibility problems in apps.
• Do a first manual accessibility check of any app.

Big idea: accessibility is not a feature added at the end. It is a quality of the design, like performance. Each barrier you remove helps people with permanent disabilities, temporary injuries and situational limits.

• Running an app on an emulator or device (lessons 4–5).
• Composables, Text, Image, Button (lessons 15–17).
• Resources: string and dimension resources (lesson 15).
• Material 3 colours (lesson 40).

A helpful way to remember: needs come in three flavours.

Because the needs overlap, one fix helps many people. Captions help a deaf student, but also someone watching a video on a noisy bus with the sound off. Large touch targets help a person with tremors, and also anyone using the phone while walking.

The four groups of abilities

Accessibility guidance often groups needs by what a person finds hard:

1. Vision: blindness, low vision, colour blindness. Needs: screen readers, magnification, high contrast, large text, no information by colour alone.
2. Hearing: deafness, hard of hearing. Needs: captions, visual alerts and vibration instead of sound-only signals.
3. Motor / dexterity: limited movement, tremor, one-handed use. Needs: large touch targets, switch devices, voice control, no gestures that need precision or two fingers only.
4. Cognitive / learning: dyslexia, ADHD, memory difficulties, low literacy, stress. Needs: plain language, consistent layout, enough time, undo, clear errors.

Why it matters

• People. The World Health Organization estimates that a very large number of people, well over a billion, live with some form of disability. Many more are older adults whose vision and dexterity change.
• Reach. An app that works with large text, a screen reader and switch access has more potential users.
• Quality. Accessible apps are also easier to test automatically (lesson 45) because they have a clear semantic structure.
• Law and policy. Many countries and organisations require accessible digital services, and public and education clients may ask for accessibility conformance. Check the rules that apply to your market; this is not legal advice.

You cannot build for an experience you have never had. Spend 30 minutes with your emulator or phone and try each of these. Menu names differ by Android version and phone brand: search Settings for the feature name if you cannot find it.

1. Font size and display size

Settings → Accessibility → Display size and text (or Display → Font size and style):

• Font size scales text (it changes the sp scale).
• Display size scales everything (it changes the density, so dp values get bigger).
• Bold text, high contrast text and remove animations are here as well.

Open your own app at the largest font and display size. Does text overlap? Do buttons get cut off? Is anything unreadable? Many apps break here, because the developer used fixed heights.

2. TalkBack (the screen reader)

TalkBack is Android's screen reader. It speaks what is on the screen and changes how you touch the phone:

Turn it on: Settings → Accessibility → TalkBack. The first time, Android offers a short tutorial: do it. Tip: set a shortcut (volume keys held for three seconds, or the accessibility button) so that you can switch it off easily. If you lose control of the phone, hold both volume keys for three seconds to turn TalkBack off.

Exercise for 10 minutes: turn the screen brightness down or close your eyes, and try to open the Settings app, find Wi-Fi and go back using only TalkBack. Then try your own app.

On an emulator, TalkBack may not be installed by default; use an emulator image that includes Google Play services and install Android Accessibility Suite from the Play Store (that package contains TalkBack, Select to Speak and Switch Access), or test on a real phone.

3. Select to Speak

A lighter tool: tap an on-screen button, then tap or drag an area, and Android reads it aloud, without changing the touch gestures. It helps people with low vision or dyslexia.

4. Colour correction, inversion and contrast

Settings → Accessibility → Colour and motion (names vary): Colour correction (for different kinds of colour blindness), Colour inversion and Extra dim. Turn on grayscale (in some versions under Digital Wellbeing, or via Developer options "Simulate colour space") and look at your app: can you still tell the error state from the success state when there is no red and green?

5. Switch Access and Voice Access

• Switch Access lets people operate the phone with one or two physical switches (a button, a keyboard key, or a head movement) instead of touch. The system scans from item to item and highlights each; the person presses the switch to select. Apps need logical focus order and every action reachable.
• Voice Access lets people operate the phone by speaking: "Tap Save", "Scroll down". It uses the visible text and content descriptions of items, and can show numbers over clickable items.

6. Captions and hearing

Live Caption can caption audio on the device (available on some devices, may need to download language files). Sound Notifications can show alerts for sounds such as a doorbell or baby crying. For your app, any information given by sound (a beep for success) needs a visual or haptic equivalent.

7. Timing and animation

Remove animations reduces motion for people with vestibular disorders. Accessibility timeout ("Time to take action") lets people keep a transient message, such as a Snackbar with an action, on screen longer.

Write down at least three things you noticed in each of your favourite apps. This list is your first accessibility audit.

How does TalkBack know what is on the screen of an app it did not write? Through the accessibility framework, a conversation between three parties.

 +--------------------+     events + node info     +-----------------------+
 |  Your app (UI)     | -------------------------> |  AccessibilityService |
 |  Views / Compose   |                            |  (TalkBack, Switch    |
 |  builds a tree of  | <------------------------- |   Access, Voice       |
 |  "accessibility    |   actions (click, scroll,  |   Access, ...)        |
 |   nodes"           |   set text, focus)         +-----------+-----------+
 +--------------------+                                        |
                                                               v
                                                 speech / braille / highlight / commands

Accessibility nodes

For every thing on the screen your app can describe a node (an AccessibilityNodeInfo in the Views world; a semantics node in Compose, lesson 45). A node carries properties:

Accessibility events

When something changes, the framework sends events to services: a view got focus, a window changed, text changed, a notification appeared. The service decides what to say.

Accessibility services

An AccessibilityService is a special app component with powerful permissions, explicitly turned on by the user in Settings. Examples: TalkBack (speech and haptics), Switch Access (scanning), Voice Access, Select to Speak, braille displays (BrailleBack) and third-party tools. Because they can read the screen and perform actions, the user must enable them manually, and Google Play has strict rules about apps that use the accessibility API for anything other than helping people with disabilities.

So your job as an app developer is not to talk to TalkBack. Your job is to describe your UI honestly (labels, roles, state, order, actions) so that any service can do its job. This is why standard components are so valuable: Material 3 buttons, checkboxes, text fields and switches already describe themselves correctly.

An analogy

Imagine you give a friend who cannot see a menu board in a restaurant and ask them to order. A good board has clear item names and prices in a logical order. If one item is just a picture of food with no words, your friend cannot order it, however nice the picture. The semantics tree is the spoken menu of your app.

Focus and reading order

Screen readers move focus through the tree, normally in reading order (top to bottom, start to end of text direction). Wrong order is a classic problem: an overlay is read after the content it covers, a floating button is read first. In Compose you can adjust order with traversal semantics (lesson 47). In Views you use accessibilityTraversalBefore/After and nextFocus* attributes.

Google's accessibility tooling and codelab highlight a few problems that account for most real failures. Memorise this list; lesson 47 fixes each in Compose, and lesson 48 tests them.

Problem 1: Missing or poor labels

An icon-only button such as a trash can has no text. A screen reader says "Button" or "Unlabelled button", and a user cannot know what it does. Fix: give every meaningful image and icon a content description that says the purpose ("Delete message"), not the picture ("trash can"). For purely decorative images, mark them as decorative (no description) so they are skipped.

Problem 2: Touch targets that are too small

Fingers are bigger than icons. The Android guidance is that interactive elements should be at least 48 × 48 dp, with some space between neighbours. A 24 dp icon is fine visually as long as its touch area is 48 dp. Small targets hurt everyone, and are a barrier for people with tremor or limited dexterity.

Problem 3: Low colour contrast

Text that is light grey on white is hard to read for anyone, and impossible for many people with low vision. WCAG (the Web Content Accessibility Guidelines, widely used as the basis for mobile guidance too) asks for a contrast ratio of at least 4.5 : 1 for normal text and 3 : 1 for large text and for important icons and UI component boundaries. We measure ratios in lesson 47.

Problem 4: Meaning conveyed by colour alone

A red border for an error and a green border for success mean nothing to a person with red-green colour blindness (roughly 1 in 12 men) or in grayscale. Fix: add an icon, text or pattern as well ("Error: enter a valid email" with an icon).

Problem 5: Text that does not scale, or breaks at large sizes

Text in dp, fixed-height containers, or text that is truncated at 200% font scale. Fix: use sp for text, let containers grow (wrapContentHeight, heightIn(min = ...)), and test at the largest font size.

Problem 6: Custom controls with no semantics

A Box with clickable works for a sighted finger but may not announce a role or state. A custom checkbox made of an icon and text must tell a service that it is a checkbox and whether it is checked. Fix: use standard components, or add semantics (Role, toggleable, selectable).

More problems to watch for

• Focus traps and wrong focus order, and focus that disappears after a dialog closes.
• Gestures with no alternative: swipe-to-delete with no button. Provide a visible, simple alternative (custom accessibility actions in lesson 47).
• Time limits with no way to extend.
• Unannounced changes: a toast or error that appears but is never spoken (use live regions).
• Flashing content (more than three flashes per second) can trigger seizures.
• Sound-only information and unlabelled form fields.
• Orientation locked with no good reason.
• Complex jargon and unclear error messages.

Severity: who is blocked?

Fix blockers first.

Create a Compose project AccessDemo. The following screen has six deliberate problems. Find them before reading the answer.

package com.example.accessdemo
import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.background
import androidx.compose.foundation.clickable
import androidx.compose.foundation.layout.Box
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.Row
import androidx.compose.foundation.layout.height
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.layout.size
import androidx.compose.material.icons.Icons
import androidx.compose.material.icons.filled.Delete
import androidx.compose.material3.Icon
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.unit.dp
import androidx.compose.ui.unit.sp
class MainActivity : ComponentActivity() {
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContent { MaterialTheme { BadScreen() } }
 }
}
@Composable
fun BadScreen() {
 Column(Modifier.padding(16.dp)) {
 Text(
 "Order summary",
 color = Color(0xFFBBBBBB), // problem A
 modifier = Modifier.background(Color.White)
 )
 Row {
 Icon(
 Icons.Filled.Delete,
 contentDescription = null, // problem B
 modifier = Modifier
 .size(24.dp) // problem C
 .clickable { /* delete */ }
 )
 Text("Zobo x 2", fontSize = 14.sp)
 }
 Box(
 Modifier
 .height(30.dp) // problem D
 .background(Color.Red) // problem E
 ) {
 Text("Payment failed", color = Color.White)
 }
 Box(Modifier.clickable { /* pay */ }) { // problem F
 Text("Pay now")
 }
 }
}

Answers.

• A: Light grey on white has a contrast ratio far below 4.5:1.
• B: The delete icon is clickable but has no description: TalkBack cannot say what it does.
• C: A 24 dp clickable area is below the 48 dp minimum touch target.
• D: A fixed 30 dp height will clip the text at large font sizes.
• E: The error is communicated by a red background only; add an icon and text role.
• F: A clickable Box has no role: TalkBack announces "Pay now" but not that it is a button, so a user might not know to double-tap it. Use a Button, or add Role.Button through Modifier.clickable(role = Role.Button, onClick = ...).

Run it, turn on TalkBack and swipe through the screen to hear problems B and F, then set the font to the largest size to see D. In lesson 47 you fix all six.

You do not need to wait for lesson 48 to start checking. Three quick tools:

1. Accessibility Scanner (a free Google app on the Play Store). Turn it on, open your app, tap its floating button, and it lists suggestions such as touch target size, contrast and missing labels, with a screenshot of the problem area.
2. Layout Inspector → semantics (lesson 44) to look at labels and roles of Compose nodes.
3. Android Studio lint and the Compose accessibility checks. Lint flags missing content descriptions in Views; Compose UI tests can enable accessibility checks automatically (lesson 48).

Lesson 47 goes deep; here are the small building blocks you need to read other people's code today.

In Compose: content descriptions and decorative images

import androidx.compose.foundation.Image
import androidx.compose.material.icons.Icons
import androidx.compose.material.icons.filled.Search
import androidx.compose.material3.Icon
import androidx.compose.runtime.Composable
import androidx.compose.ui.res.painterResource
@Composable
fun SearchIcon() {
 // Meaningful: describe the purpose
 Icon(Icons.Filled.Search, contentDescription = "Search")
}
@Composable
fun Divider(dividerRes: Int) {
 // Decorative: null means "skip this"
 Image(painterResource(dividerRes), contentDescription = null)
}

contentDescription = null is a decision, not an omission: it says "this image adds no information". Compose makes you write the parameter explicitly so that you cannot forget.

In Compose: a role and a state on a custom control

import androidx.compose.foundation.selection.toggleable
import androidx.compose.foundation.layout.Row
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.Role
@Composable
fun NotifyRow(checked: Boolean, onChange: (Boolean) -> Unit) {
 Row(
 Modifier.toggleable(
 value = checked,
 role = Role.Switch,
 onValueChange = onChange
 )
 ) {
 Text("Send me reminders")
 }
}

TalkBack now says something like "Send me reminders, switch, on" and double-tap toggles it, because the row declares a toggle role and state.

In Views (XML): the same ideas

<ImageButton
 android:id="@+id/deleteButton"
 android:layout_width="48dp"
 android:layout_height="48dp"
 android:src="@drawable/ic_delete"
 android:contentDescription="@string/delete_item" />
<ImageView
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:src="@drawable/divider"
 android:importantForAccessibility="no" />
<TextView
 android:id="@+id/nameLabel"
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:labelFor="@id/nameInput"
 android:text="@string/student_name" />

importantForAccessibility="no" is the Views version of a decorative image. labelFor links a label to the field it describes, so a screen reader reads the label when the field gets focus. A description must be a string resource so that it can be translated.

Asking whether a screen reader is on

import android.content.Context
import android.view.accessibility.AccessibilityManager
fun isTalkBackLikelyOn(context: Context): Boolean {
 val manager = context.getSystemService(Context.ACCESSIBILITY_SERVICE) as AccessibilityManager
 return manager.isEnabled && manager.isTouchExplorationEnabled
}

isTouchExplorationEnabled is true when a screen reader that uses explore-by-touch is running. Use this sparingly: the aim is to build one UI that works for everyone, not a separate "accessible mode". It is acceptable to adjust timing (for example keeping a message longer).

Reading the font scale

import androidx.compose.runtime.Composable
import androidx.compose.ui.platform.LocalConfiguration
import androidx.compose.ui.platform.LocalDensity
@Composable
fun isLargeText(): Boolean {
 val density = LocalDensity.current
 return density.fontScale >= 1.3f
}

If you detect a very large font scale, you can switch a three-column row to a single column. Compose layouts that use weight, wrapping and heightIn usually adapt without any such code.

Preview at several font sizes

import androidx.compose.material3.MaterialTheme
import androidx.compose.runtime.Composable
import androidx.compose.ui.tooling.preview.Preview
@Preview(name = "Normal", fontScale = 1.0f, showBackground = true)
@Preview(name = "Large", fontScale = 1.5f, showBackground = true)
@Preview(name = "Largest", fontScale = 2.0f, showBackground = true)
@Composable
private fun FontScalePreview() {
 MaterialTheme { BadScreen() }
}

Preview your screen at 2.0 and watch problem D (the fixed-height banner) clip its text. This is the cheapest accessibility test there is.

Mistake #1: "Our users are not disabled." Reality: situational and temporary needs affect everyone. Fix: design for the range of use.

Mistake #2: Describing the picture, not the purpose. Symptom: "trash can" instead of "Delete". Fix: say what it does.

Mistake #3: Repeating "image" or "button" in the description. Symptom: "Button, Save button". Fix: the role is announced for you.

Mistake #4: Giving every decorative image a description. Symptom: noisy TalkBack. Fix: mark decorative images so they are skipped.

Mistake #5: Fixed dp heights for text containers. Fix: allow growth.

Mistake #6: Colour as the only signal. Fix: add icon or text.

Mistake #7: Testing only with a mouse and good eyes. Fix: test with TalkBack, large text and grayscale.

Mistake #8: Custom clickables with no role. Fix: use standard components.

Mistake #9: Treating accessibility as a final polish. Fix: include it in each task's "definition of done".

Mistake #10: Locking orientation and blocking zoom without reason. Fix: support rotation unless the task truly requires otherwise.

Question 1. Give one example each of a permanent, temporary and situational need.

Question 2. What is the minimum recommended size for touch targets?

Question 3. What contrast ratio does WCAG ask for normal-sized text?

Question 4. What is an accessibility service, and who turns it on?

Question 5. What is the difference between Font size and Display size settings?

Go deeper: official resources

• Make your Android app accessible pathway
• Starting with Android accessibility codelab
• Build more accessible apps (developer guide)
• Testing your app's accessibility