Tech Insights
Reshaka Weerasinghe
July 8, 2025

Code for Inclusivity: Building Accessible Mobile Apps

Code for Inclusivity: Building Accessible Mobile Apps

Accessibility is often discussed in the context of the web, but it’s equally important in mobile applications.

Smartphones and tablets are central to how people navigate the world today. They are communication tools, payment systems, entertainment hubs, and gateways to essential services. If mobile apps aren’t accessible, millions of users with visual, auditory, motor, or cognitive impairments will be excluded.

In this post, we’ll explore what accessibility means for mobile applications, where it differs from the web, and how you can implement it using platform tools and code examples.

Whether you’re developing for Android or iOS, the goal is the same: make your app accessible for everyone.


Why accessibility matters in mobile apps

Globally, over 1 billion people live with some form of disability. For many of them, smart phones are a primary device. Mobile apps that aren’t accessible can block users from accessing vital services, communicating with others, or participating in everyday life.

In addition to ethical and legal reasons (ADA, WCAG, EN 301549, Section 508), accessibility has a business case: Accessible apps reach more users, improve usability for everyone, and often drive better customer loyalty and satisfaction.

Mobile accessibility does introduce some unique challenges:

  • Small screens and varied device sizes
  • Touch as the primary interaction
  • Gesture-based navigation
  • Physical device orientation
  • Hardware buttons and external devices (ADA keypads, Bluetooth keyboards)

In short: accessibility in mobile apps requires us to think beyond the screen.


Core areas of accessibility in mobile apps:

Let’s look at the most important aspects of accessibility to address in your mobile applications.


Screen reader support

Screen readers allow users with visual impairments to access your app’s content and controls through audio output.
On Android, the built-in screen reader is TalkBack. On iOS, it’s VoiceOver.

To support screen readers:

  • All meaningful UI elements should have accessible labels.
  • Decorative images should be marked as such (no description).

Example: Android (Jetpack Compose)

Image(
    painter = painterResource(id = R.drawable.profile_picture),
    contentDescription = "User profile picture"
)

‍

Example: iOS (SwiftUI)

Image("profile_picture")
    .accessibilityLabel("User profile picture")

‍

It is important have appropriate labels to make the app accessible to everyone. Without appropriate labels, a screen reader might say “Image” or skip the element entirely, leaving the user guessing.


Text Scaling & Font Accessibility

Users should be able to read app content comfortably, regardless of their vision.

Both Android and iOS allow users to adjust system-wide text size. Your app should respect this setting by using scalable text units.

Example: Android

Text(
    text = "Welcome!",
    fontSize = 18.sp // "sp" scales with user settings
)

‍

Example: iOS

Text("Welcome!")
    .font(.system(size: 18))
    .dynamicTypeSize(.large)

‍

If you hard-code pixel sizes or disable scaling, users with low vision will struggle to use your app.

Pro tip: Always test your app with large text enabled (up to 200%).


Color & Contrast

Good color contrast is essential for readability, especially for users with low vision or color blindness.

Aim to meet WCAG 2.1 AA contrast ratios:

  • 4.5:1 for normal text
  • 3:1 for large text

Additionally, don’t rely on color alone to convey information. For example, instead of marking success with only a green icon, include text or an accessible label:

Row {
    Icon(Icons.Default.Check, contentDescription = "Success")
    Text("Success", color = Color.Green)
}

‍

Focus & Navigation (Including External Keypads &Buttons)

Many users navigate apps using external input devices such as:

  • D- pads
  • ADA- compliant keypads
  • Bluetooth keyboards
  • Assistive switches (Switch Control on iOS)

Your app should allow full navigation without requiring touch gestures.

For example, in a kiosk app using an ADA keypad, users should be able to move between UI elements, activate buttons, and submit forms all via physical keys.

You should also ensure all interactive elements are focusable:

Modifier.focusable()

‍

On iOS, supporting Switch Control and keyboard navigation requires ensuring controls expose appropriate accessibilitytraits:

Button("Submit") {
    // Action here
}
.accessibilityAddTraits(.isButton)

‍

When testing your app, try using:

  • TalkBack + hardware keyboard (Android)
  • Switch Control + Bluetooth keyboard (iOS)
  • D-pad navigation (Android TV, kiosks)
  • ADA keypad navigation


Touch Targets & Gestures

Touch targets that are too small can be extremely difficult to interact with, particularly for users with motor impairments.

Both platforms recommend minimum target sizes:

  • Android: 48x48 dp
  • iOS: 44x44pt


Android example

Modifier.sizeIn(minWidth = 48.dp, minHeight = 48.dp)

‍

iOS example

.frame(minWidth: 44, minHeight: 44)

‍

It’s also important to avoid making key actions gesture-on. For example:

  • Provide a button to open a menu, don't rely on swipe gestures alone.
  • Avoid actions that require long press without a visible alternative.

Always test your app one-handed, and with reduced dexterity settings if your platform offers them.


Auditory Accessibility

If your app plays audio or video content, ensure that captions or transcripts are available.

For apps that use sound for alerts, also provide a visual indicator. For example, a toast, banner, or vibration.


Cognitive Accessibility

Many users benefit from apps that are:

  • Simple and consistent
  • Easy to understand
  • Forgiving of mistakes

For example:

  • Use clear, descriptive labels (not just "OK", "Submit”, “Do It”).
  • Avoid complicated navigation flows or screens overloaded with options.
  • Provide helpful error messages with suggestions for correction.

Apps that support cognitive accessibility help everyone, not just users with cognitive disabilities.


Accessibility in Public-Facing Mobile Apps and Kiosks

While accessibility is critical in personal mobile apps, it becomes even more essential in public-facing apps. such askiosks, ticket booking terminals, banking systems, etc. These applications are often used by a diverse audience, including people who may have:

  • Hearing impairments, requiring adjustable volume levels or visual cues.
  • Cognitive challenges, needing simplified interfaces, clear voice guidance, or slower speech rates.
  • Visual impairments, depending on screen readers, high-contrast modes, or magnified text.
  • Motor impairments, using ADA keypads, switch devices or needing larger touch targets.

Unlike personal apps, which can assume long-term use and personalisation, public apps must be inclusive by default. There's often no opportunity for the user to adjust accessibility settings through the options available in device settings, so designers and developers must build in those options proactively.

Practical considerations:

  • Offer audio volume control right from the welcome screen.
  • Allow the user to choose a voice rate (normal/slow) for audio instructions or announcements.
  • Design for ADA keypads, switch inputs, or touch- free input modes.
  • Provide visual feedback for actions triggered via sound or touch.
  • Use timeouts carefully. Allow more time or provide a “need more time” button.
  • Display content in simple, high- contrast layouts, with minimal distractions.


Platform Tools & APIs

Both platforms provide rich tools to help you implement and test accessibility.

Android

TalkBack is Android’s built-in screenreader. When enabled, it reads aloud everything that’s displayed on the screen and announces user interactions. You can activate TalkBack from Settings> Accessibility or with a gesture (varies by device). As a developer, you should test your app with TalkBack:

  • Navigate the app entirely with TalkBack enabled.
  • Check that content descriptions, hints, and announcements make sense.
  • Verify the correct reading order of your UI.

Accessibility Scanner is a free tool from Google.
It scans your app and suggests improvements such as:

  • Increasing touch target size
  • Improving contrast
  • Adding missing content descriptions

This is an easy first step in auditing your app.

Android Studio Lint Checks- Android Studio includes Lint checks that warn you when:

  • You forget to set content description on an ImageView
  • Your text sizes don't respect scaling
  • You use colors with insufficient contrast (with newer material themes

These warnings help catch common accessibility issues early in development.

iOS

VoiceOver is iOS’s built-in screenreader.
You can enable it in Settings > Accessibility > VoiceOver.

Test your app with VoiceOver:

  • Navigate through the app without touching the screen visually
  • Verify that elements are read out in the correct order with useful descriptions
  • Confirm that important interactions (buttons, sliders, navigation links) are announced properly

The Acessibility Inspector is built into Xcode.
It allows you to:

  • Simulate VoiceOver without using a device
  • Audit accessibility properties of your UI
  • Explore focus order
  • View which elements are exposed to accessibility APIs

SwiftUI Accessibility Modifiers provides a very convenient API for adding accessibility to your UI:

Text("Settings")
    .accessibilityLabel("Settings button")
    .accessibilityHint("Opens the settings screen")

‍

Modifiers you’ll commonly use:

  • .accessibilityLabel- what VoiceOver reads out
  • .accessibilityHint- additional context about what happens when the item is activated
  • .accessibilityAddTraits- communicates the role (button, selected, header, etc.)

UIKit Accessibility API- If you’re buildingwith UIKt, you’ll work with the UIAccessibility protocol.

Example:

button.accessibilityLabel = "Submit"
button.accessibilityHint = "Sends the form data"

‍

UIKit also lets you manage focus, announce dynamic content changes, and more advanced behaviors.


Testing Your App for Accessibility

Accessibility testing is an ongoing process, not a one-time task.

Here’s a good starting workflow:

  1. Enable TalkBack or Voiceover
  2. Navigate through your app: (Can you access all content? Is your content clearly described?)
  3. Test dynamic text scaling
  4. Verify color contrast
  5. Test with hardware input devices (keyboards, keypads)
  6. Test using Switch Control (iOS)
  7. Check focus order and visibility
  8. Validate any custom controls

Building accessible mobile apps is both a technical and a human challenge.
It requires us to think beyond default UI and imagine how all users willinteract with the experience we create.

By supporting screen readers, respecting text scaling, ensuring contrast and keyboard navigation, and testing thoroughly, we can create apps that are usable by everyone.

Accessibility improves usability for all users. It buildsbrand trust. And it’s simply the right thing to do.

As you work on your next mobile project, ask yourself:
“Could a user with no vision, no hearing, limited dexterity, or cognitiveimpairments still use this app effectively?”

If the answer is yes, you’re on the right track.