GitHub

Falar sobre acessibilidade é fácil. Implementar acessibilidade em um aplicativo real, com prazos apertados, dívida técnica e design complexo, é outra história.

Este guia "na prática" é focado em desenvolvedores Mobile (Android/iOS/Flutter/React Native) e Designers que precisam colocar a mão na massa hoje. Vamos pular a filosofia e ir direto para o workflow de implementação.

O "Kit de Sobrevivência" da Acessibilidade Mobile

Antes de escrever código, você precisa das ferramentas certas para testar. Sem elas, você está programando no escuro.

Scanner de Acessibilidade (Accessibility Scanner): App do Google disponível na Play Store. Ele tira um print da sua tela e sugere correções (aumentar texto, contraste, área de toque).
VoiceOver (iOS) / TalkBack (Android): Aprenda os gestos básicos.
- Swipe direita: Próximo item.
- Swipe esquerda: Item anterior.
- Duplo toque: Ativar/Clicar.
Simulador de Daltonismo: Apps como "Sim Daltonism" (Mac/iOS) permitem que você olhe para a tela do seu app como se tivesse diferentes tipos de cegueira de cor.

Checklist Prático de Implementação

1. Ordem de Foco (Traversal Order)

O leitor de tela lê a tela de cima para baixo, da esquerda para a direita (em idiomas ocidentais). Mas layouts complexos podem bagunçar isso.

Problema: O leitor lê o rodapé antes do conteúdo principal.
Solução Prática:
- Android: Use android:accessibilityTraversalBefore e android:accessibilityTraversalAfter para forçar a ordem lógica se o XML estiver fora de ordem visual.
- iOS: Ajuste o array accessibilityElements na sua View Controller.

2. Agrupamento de Conteúdo (Grouping)

Imagine um cartão de produto com: [Foto do Tênis] [Nome: Nike Air] [Preço: R$ 500]. Se o leitor focar em cada item separadamente, o usuário tem que fazer "swipe" 3 vezes para entender um único produto. Isso é cansativo.

Solução Prática: Agrupe o container.
- Flutter: Envolva o Widget do cartão em um Semantics(container: true, label: "Tênis Nike Air, preço 500 reais") e esconda os filhos da semântica (excludeSemantics). Assim, o foco é único no cartão inteiro.

3. Fontes Dinâmicas (Dynamic Type)

O usuário aumentou a fonte nas configurações do celular porque tem presbiopia (vista cansada). Seu app respeita isso ou quebra tudo?

Prática: Nunca defina tamanhos de fonte em pixels fixos (px).
- Android: Use sp (scale-independent pixels).
- iOS: Use Fontes Dinâmicas (UIFont.preferredFont(forTextStyle: .body)).
- React Native: Evite limitar numberOfLines={1} em textos importantes. Deixe o texto quebrar linha se a fonte aumentar.

4. Cores e Contraste (Dark Mode)

Acessibilidade também é sobre conforto visual.

Prática: Teste seu app no Modo Escuro e no Modo Claro. O texto cinza claro que fica lindo no fundo branco pode desaparecer no fundo preto se você não usar cores semânticas do sistema (ex: SystemGray no iOS) em vez de hardcoded hex colors.

5. Touch Targets (Área de Toque)

O botão parece grande, mas só o ícone de 24px no meio é clicável.

Prática: Use ferramentas de "Debug Paint" ou "Show Layout Bounds" nas opções de desenvolvedor do Android para ver o tamanho real da caixa clicável. Se estiver menor que 48dp, aumente o padding interno do componente.

Fluxo de Desenvolvimento Acessível (DoD)

Para garantir que a acessibilidade aconteça na prática, inclua estes itens na sua "Definition of Done" (Critérios de Aceite) de cada tarefa:

Todos os elementos interativos têm rótulos (labels)?
Naveguei pela feature inteira usando apenas o teclado/leitor de tela?
O contraste de cores passa no teste WCAG AA?
Se aumentarmos a fonte do sistema, o layout se adapta (scroll) ou corta texto?

Acessibilidade em WebViews (Cuidado!)

Muitos apps são híbridos e carregam páginas web dentro deles.

O Perigo: A acessibilidade nativa do celular (TalkBack/VoiceOver) nem sempre conversa bem com o HTML da WebView se ele não for bem feito.
A Prática: Se usar WebViews, o site carregado PRECISA ser acessível (HTML semântico, ARIA labels). O app nativo não consegue "consertar" um HTML ruim magicamente.

Conclusão

Acessibilidade na prática é menos sobre heroísmo e mais sobre hábito. É criar o reflexo muscular de adicionar contentDescription sempre que adicionar uma ImageView. É o hábito de testar com o TalkBack ligado por 2 minutos antes de mandar o Pull Request.

Pequenas ações diárias criam um produto robusto. Comece hoje, na próxima tela que você codar.

Acessibilidade Em Aplicativos Moveis - Guia Completo Na Pratica