Acessibilidade — fundamentos, VoiceOver e TalkBack para usuários cegos

O que é Acessibilidade (a11y) em aplicativos móveis?

Accessibility (abreviado a11y — 11 letras entre «a» e «y») — a prática de desenvolver aplicativos utilizáveis por pessoas com deficiências visuais, auditivas, motoras e cognitivas. No desenvolvimento móvel, a acessibilidade abrange quatro cenários principais: usuários cegos (leitores de tela), usuários com baixa visão (dimensionamento, contraste), usuários surdos ou com dificuldade auditiva (legendas, alternativas visuais ao som) e usuários com mobilidade reduzida (controle por voz, Switch Control, grandes áreas de toque).

Requisitos legais — em muitos países, a acessibilidade é legalmente obrigatória. EUA: Section 508 e ADA. UE: European Accessibility Act (2025). Reino Unido: Equality Act 2010. Sem suporte de acessibilidade, um aplicativo pode se tornar alvo de ações judiciais — nos EUA em 2023, mais de 4.000 processos foram movidos por produtos digitais inacessíveis. Apple e Google verificam a acessibilidade durante a moderação de aplicativos: App Store Review Guidelines (4.2) e Google Play Store exigem suporte mínimo de acessibilidade.

Argumento comercial — a acessibilidade expande seu público. De acordo com a Return on Disability (2021), pessoas com deficiência controlam US$ 13 trilhões em renda disponível anualmente. Aplicativos acessíveis também têm melhor classificação em buscas (HTML semântico, textos alternativos), têm classificação de usuário mais alta e menos avaliações sobre problemas de UX. Na IT Sectr, incluímos acessibilidade na definição de pronto de todos os projetos — é um padrão de qualidade, não uma melhoria opcional.

Acessibilidade no iOS: VoiceOver e UIAccessibility

VoiceOver — o leitor de tela da Apple integrado ao iOS, iPadOS e macOS. O usuário arrasta o dedo pela tela e o VoiceOver lê o nome do elemento sob o dedo. Toque duplo ativa o elemento. O VoiceOver suporta mais de 40 gestos: deslizar com três dedos (rolagem), toque duplo com dois dedos (parar), gesto Z (voltar). Os desenvolvedores controlam o que e como o VoiceOver lê através do protocolo UIAccessibility e das propriedades accessibilityLabel, accessibilityTraits e accessibilityHint.

class CustomButton: UIButton {

    override var isAccessibilityElement: Bool {
        get { return true }
        set {}
    }

    // substituir accessibilityLabel
    override var accessibilityLabel: String? {
        get { return "Botão de envio do formulário" }
        set {}
    }

    // substituir accessibilityHint
    override var accessibilityHint: String? {
        get { return "Toque duas vezes para enviar dados" }
        set {}
    }

    // substituir accessibilityTraits
    override var accessibilityTraits: UIAccessibilityTraits {
        get { return .button }
        set {}
    }
}

// Dynamic Type — dimensionamento de texto
titleLabel.font = UIFontMetrics.default.scaledFont(
    for: UIFont.systemFont(ofSize: 16)
)
titleLabel.adjustsFontForContentSizeCategory = true

Tipografia dinâmica — o Dynamic Type no iOS permite que o usuário escolha o tamanho do texto (de XS a XXXL). Os desenvolvedores usam UIFontMetrics.scaledFont para dimensionamento automático. O texto deve ser exibido corretamente em todos os tamanhos: as linhas não devem ser cortadas, os botões devem crescer proporcionalmente ao texto. UITableView atualiza automaticamente a altura das células quando o tamanho do texto muda. Ignorar o Dynamic Type significa tornar seu aplicativo inacessível para usuários com baixa visão.

Acessibilidade no SwiftUI

SwiftUI fornece modificadores de acessibilidade: .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(), .accessibilitySortPriority(). Por padrão, todos os elementos padrão do SwiftUI (Text, Button, Image) já são elementos de acessibilidade com rótulos automáticos. Para visualizações personalizadas, use .accessibilityElement(children: .combine) para combinar elementos filhos em um único. O SwiftUI suporta automaticamente Dynamic Type e VoiceOver.

VStack {
    Image(systemName: "trash")
        .accessibilityLabel(Text("Excluir item"))
    Text("Lixeira")
        .font(.body)
}
.accessibilityElement(children: .combine)
.accessibilityAddTraits(.isButton)
.accessibilityHint(Text("Exclui o item selecionado permanentemente"))

Acessibilidade no Android: TalkBack e contentDescription

TalkBack — o leitor de tela do Google, pré-instalado na maioria dos dispositivos Android (disponível no Google Play para todas as versões Android 5+). O TalkBack usa os mesmos gestos que o VoiceOver: deslizar para navegar, toque duplo para ativar. Os desenvolvedores definem as descrições dos elementos através do atributo android:contentDescription em XML ou via setContentDescription() no código. Para ImageView, contentDescription é obrigatório — sem ele, o TalkBack dirá «não rotulado» ou lerá o nome do arquivo.

// XML: contentDescription para ImageView
<ImageView
    android:id="@+id/iconDelete"
    android:src="@drawable/ic_delete"
    android:contentDescription="@string/delete_button_desc"
    android:focusable="true"
    android:clickable="true" />

// Kotlin: atribuição programática
iconDelete.contentDescription = getString(R.string.delete_button_desc)

// Accessibility Delegate (personalizado)
iconDelete.accessibilityDelegate = object : View.AccessibilityDelegate() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfo
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.text = "Botão excluir"
        info.contentDescription = "Excluir item selecionado"
        info.className = Button::class.java.name
    }
}

// Live Regions para atualizações dinâmicas
textView.accessibilityLiveRegion = View.ACCESSIBILITY_LIVE_REGION_POLITE

Live Regions — o mecanismo do Android para notificar o TalkBack sobre mudanças de conteúdo sem foco. O atributo android:accessibilityLiveRegion aceita três valores: none (sem notificações), polite (anunciar após o atual), assertive (anunciar imediatamente). Use polite para atualizações de status de carregamento, assertive para erros críticos. O uso excessivo de assertive criará caos para o usuário — o TalkBack interromperá constantemente a ação atual.

Accessibility Scanner

Accessibility Scanner — um aplicativo gratuito do Google para testar a acessibilidade de aplicativos Android sem acesso ao código fonte. O scanner verifica: contraste do texto, tamanho das áreas de toque (mínimo 48×48dp de acordo com as Diretrizes de Acessibilidade do Android), contentDescription para ImageView e hierarquia correta de elementos. Para testes automatizados, use AccessibilityChecks do Espresso — eles se integram ao CI/CD e verificam a acessibilidade a cada compilação.

WCAG 2.1: contraste, tamanho e áreas de toque

WCAG 2.1 (Web Content Accessibility Guidelines) — o padrão internacional de acessibilidade desenvolvido pelo W3C. A versão 2.1 (2018) inclui 13 critérios adicionais para aplicativos móveis. Níveis de conformidade: A (mínimo), AA (obrigatório para a maioria das organizações), AAA (máximo). Apple e Google recomendam o nível AA como mínimo para publicar aplicativos. O WCAG 2.2 foi lançado em 2023 com refinamentos para foco e entrada de dados.

Critérios-chave para desenvolvimento móvel: contraste de texto de pelo menos 4.5:1 (AA) ou 7:1 (AAA), tamanho das áreas de toque de pelo menos 44×44pt (iOS) ou 48×48dp (Android), suporte para orientação paisagem e retrato sem perda de funcionalidade, capacidade de desativar animações (prefers-reduced-motion), legendas para multimídia e compatibilidade com controle por voz (Voice Control no iOS, Voice Access no Android).

Ferramentas de verificação de contraste — Colour Contrast Analyser (TPGI), WebAIM Contrast Checker, Stark (Figma), Accessibility Inspector (Xcode). Na IT Sectr, verificamos o contraste na fase de design (Figma + Stark) e novamente na fase de desenvolvimento (Accessibility Inspector / Accessibility Scanner). O requisito mínimo é 4.5:1 para todo texto abaixo de 18pt (14pt bold). Logotipos e elementos decorativos não precisam de contraste.

Testes de acessibilidade: ferramentas e lista de verificação

Testes no iOS — Accessibility Inspector no Xcode (Xcode → Open Developer Tool → Accessibility Inspector) verifica o rótulo, traits e dica para cada elemento. O VoiceOver pode ser ativado nas Configurações ou pelo Atalho de Acessibilidade (toque triplo no botão). Para testes automatizados, use XCUITest com XCTAssertTrue(app.staticTexts["rótulo"].isAccessibilityElement). A Apple recomenda testar todas as telas do aplicativo com o VoiceOver ativado.

Testes no Android — Accessibility Scanner (Play Store) verifica contraste, tamanho das áreas de toque e contentDescription. Para automação: Espresso AccessibilityChecks (importação: androidTestImplementation 'androidx.test.espresso:espresso-accessibility:3.5.1'). O Google recomenda a seguinte lista de verificação: cada ImageView tem contentDescription, as áreas de toque têm pelo menos 48×48dp, o texto escala para 200% sem cortes e todos os elementos são acessíveis por deslizamento do TalkBack.

Lista de verificação da IT Sectr — antes do lançamento, verificamos: (1) VoiceOver/TalkBack lê corretamente todos os elementos, (2) o texto escala para o tamanho máximo sem perda de funcionalidade, (3) todos os ImageViews têm contentDescription, (4) contraste do texto ≥4.5:1 em todos os temas, (5) áreas de toque ≥44pt/48dp, (6) nenhum menu de contexto acessível apenas por pressão longa, (7) suporte a Reduce Motion / Remove Animations nas configurações do sistema. Esta lista de verificação faz parte da definição de pronto de cada sprint.