Skip to content
All posts
July 31, 20264 min read

Android Accessibility: Making Apps Work for Everyone

Accessibility isn't a feature you bolt on at the end — it's a set of small habits during development. Here's how I make Compose apps work with TalkBack, large fonts, and switch access without much extra effort.

AccessibilityAndroidJetpack ComposeTalkBackInclusive Design
Share:

Accessibility tends to get treated as a compliance checkbox or a thing for "later," and later usually means never. That's a mistake on two counts: it excludes real users, and retrofitting it is far harder than building it in. The encouraging truth is that an accessible Compose app is mostly the result of small habits during development, not a big separate project. Here's what those habits are.

Test With TalkBack Early

The single most valuable thing you can do is turn on TalkBack — Android's screen reader — and try to use your app with your eyes closed. It's humbling the first time. Buttons announce as "button" with no label, images interrupt with filenames, and the focus order jumps around nonsensically. Doing this early, while the screen is fresh, means you fix issues as you build instead of discovering a pile of them before release. I run a TalkBack pass on every new screen as part of finishing it, not as a separate audit.

Give Everything a Meaningful Label

A screen reader can only announce what you've described. An icon button with no content description is a dead end for a TalkBack user. In Compose, content descriptions are how you attach that meaning.

kotlin
Icon(
    imageVector = Icons.Default.Delete,
    contentDescription = "Delete item",
)

The flip side is decorative images, which should have a null content description so the reader skips them instead of announcing noise. The skill is describing the action or meaning — "Delete item," not "trash icon" — because the user cares what it does, not what it looks like.

Respect the User's Font Size

Users who increase their system font size are telling you they need larger text, and an app that ignores that by hardcoding pixel sizes is unusable for them. The fix is using scalable units (

code
sp
for text) and, just as importantly, testing your layouts at large font scales. The common failure is text that's correctly scalable but sits in a fixed-height container that clips it at 200% scale. Designing layouts that grow gracefully with text — wrapping instead of truncating, scrolling instead of clipping — is what makes large-font support real rather than nominal.

Make Touch Targets Big Enough

Anyone with limited motor control, or just large fingers on a small screen, struggles with tiny tap targets. The platform guidance is a minimum touch target of 48dp, and Compose's interactive components mostly handle this, but custom clickable elements often don't. I check that every tappable thing meets the minimum, padding the touch area where the visual element is smaller. It's a tiny change that makes the app usable for a much wider range of people, and honestly it makes the app feel better for everyone.

Group and Order Semantics Sensibly

Beyond labels, screen readers care about structure — what's grouped together and what order focus moves through. A list item with a title, subtitle, and button should usually be announced as one coherent unit rather than three disconnected stops. Compose's semantics modifiers let you merge related elements and set a logical focus order so navigation by screen reader feels deliberate, not random. Getting this right is the difference between an app a TalkBack user can technically operate and one they can comfortably use.

It Benefits Everyone

The reframe that makes accessibility easy to commit to is realizing it isn't charity for a few — it improves the app for everyone. Good contrast helps in sunlight. Large touch targets help on a bumpy bus. Clear labels and logical structure make the whole app easier to understand. The habits that serve users with disabilities are the same habits that make a polished, usable product. Building them in from the start costs little and pays off across your entire user base, which is exactly why it belongs in the normal flow of development rather than a checkbox at the end.

Key Takeaways

  • Use your app with TalkBack early and on every new screen, fixing issues while the screen is fresh.
  • Give interactive elements meaningful content descriptions and mark decorative images null so they're skipped.
  • Use scalable
    code
    sp
    units and test layouts at large font scales so text grows instead of clipping.
  • Ensure every tappable element meets the 48dp minimum touch target, padding custom ones as needed.
  • Use semantics modifiers to group related elements and set a logical focus order for screen-reader navigation.
  • Treat accessibility as habits that improve the app for everyone, built in from the start rather than bolted on.
Share:
S

Sudarshan Chaudhari

AI Systems Builder / Product Engineer

Bangkok, Thailand

Solo Android developer with 13+ years in QA, building Android apps, AI automation systems, and developer tools at SudarshanTechLabs.

Stay updated

Get new posts on Android, Kotlin, and solo dev straight to your inbox.

Newsletter preferences

Related Apps

MyFamilyTracker

Real-time family location sharing — Firebase Realtime DB for sub-second propagation, WorkManager + ForegroundService for OS-compliant background collection, geofencing via Google Maps API.

Building something? Available for Android dev and QA consulting.

Work with me

Comments — powered by Giscus

Apps tagged with this