Accessibility in Mobile Applications - Complete Guide with Examples

accessibility theory is beautiful, but what developers and designers really need are examples. Seeing how the code works, how the interface behaves and where companies make mistakes (and get things right) is the best way to learn.

In this practical guide, we will leave the field of ideas and delve into real examples of implementing accessibility in mobile applications (iOS and Android), dissecting UI patterns and showing how to make them inclusive.

Example 1: The "Ghost" Button (Icon Buttons)

You know that magnifying glass icon in the corner of the screen to search for something? Or the gear icon for settings? For a sighted user, the icon is enough. For a blind user using a screen reader (VoiceOver/TalkBack), if that button does not have a label (label), they will just hear: "Button".

"Button" says nothing. Button what? To delete the account? To buy?

The Wrong Way (Inaccessible)

<!-- Android Layout -->
<ImageButton
    android:id="@+id/btn_settings"
    android:src="@drawable/ic_gear"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" />

The screen reader will read the class name or just "unlabeled button".

The Right Way (Accessible)

<!-- Android Layout -->
<ImageButton
    android:id="@+id/btn_settings"
    android:src="@drawable/ic_gear"
    android:contentDescription="@string/settings_button_description"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" />

On iOS (SwiftUI):

// Acessível
Button(action: openSettings) {
    Image(systemName: "gear")
}
.accessibilityLabel("Configurações")

Result: The user will hear "Settings, button." Simple but essential.

Example 2: Error Feedback in Forms

You fill out a form, click "Submit" and nothing happens. The password field turned red, but you didn't see it because you are color blind (Protanopia).

Golden Rule: Never use just color to convey information.

The Right Way

In addition to making the border red, add an alert icon and an explanatory text message below the field.

❌ Bad: Red border.
✅ Good: Red border + Icon ⚠️ + Text "Password must be 8 characters long".

Additionally, for screen readers, the focus must go to the error field or the error must be announced.

// Android: Anunciar erro para TalkBack
passwordInputLayout.error = "Senha muito curta"
passwordInputLayout.announceForAccessibility("Erro: Senha muito curta")

Example 3: Touch Targets

Have you ever tried to click that tiny "x" to close an ad and ended up clicking on the ad? This is frustrating for everyone, but impossible for those who have hand tremors (Parkinson's, for example).

WCAG and Apple/Google guidelines recommend a minimum touch area of 44x44 dp (iOS) or 48x48 dp (Android).

Implementation Tip: You don't need to visually enlarge the icon. You can only increase the invisible padding around it.

/* CSS (React Native / Web App) */
.close-button {
  width: 20px;   /* Ícone visual pequeno */
  height: 20px;
  padding: 12px; /* Área de toque grande */
  box-sizing: content-box; /* Garante que o padding some ao tamanho */
}

Example 4: Decorative Images vs. Information

Not every image needs a description. If you describe everything, you will pollute the user's listening experience.

Informative Image: A photo of a product you are selling.
- Action: alt="Tênis de corrida azul com solado branco".
Decorative Image: An arrow icon next to a "Read more" text, or a graphic wave at the bottom of the header.
- Action: Hide from the screen reader.

In Flutter:

// Imagem Decorativa (Invisível para Semântica)
ExcludeSemantics(
  child: Image.asset('background_wave.png'),
)

// Imagem Informativa
Semantics(
  label: 'Logo da Empresa',
  image: true,
  child: Image.asset('logo.png'),
)

Example 5: Loading State

The user clicks "Pay". The screen freezes. A spinner appears spinning. To anyone who sees it, it's clear: "It's loading." For those who don't see it, the silence is distressing. "It crashed? The app closed? My internet went down?"

Always provide auditory feedback for charging states.

Android: Use ProgressBar with android:stateDescription="Carregando pagamento...".
iOS: Use UIAccessibility.post(notification: .announcement, argument: "Processando pagamento, aguarde.").

Conclusion

Accessibility is not about memorizing abstract rules. It's about understanding how code translates into experience for different humans.

By applying these standards (Button Labels, Redundant Colors, Generous Touch Areas, Correct Semantics, and State Feedback), you solve 90% of the barriers that prevent people from using your app.

The best code is not the most complex. It's the one that works for the greatest number of people.