Acessibilidade no desenvolvimento móvel: o que é, quais padrões e como implementar

O que é acessibilidade?

Accessibility (abreviado a11y — letra a + 11 letras + y) é a propriedade de um produto ser utilizável por pessoas com deficiência. No contexto de aplicações móveis, isso significa: suporte a leitores de tela (VoiceOver, TalkBack), tamanho de texto adequado, alto contraste, ordem de foco correta para navegação por teclado e ausência de elementos animados que causam tontura.

Inclusividade não é apenas uma obrigação ética, mas também legal. Muitos países têm leis de acessibilidade digital: ADA (EUA), Seção 508, European Accessibility Act (UE, obrigatório para aplicações a partir de 2025). De acordo com o Business Disability Forum, empresas que investem em acessibilidade aumentam seu público em 15–20% e reduzem riscos legais.

Na IT Sectr, verificamos a acessibilidade em cada etapa do desenvolvimento. Nossa experiência mostra: corrigir problemas de acessibilidade na fase de design custa 10 vezes menos do que após o lançamento. Acessibilidade não é um recurso, mas um requisito básico para uma aplicação moderna.

iOS: VoiceOver, Accessibility Label, Trait

O ecossistema Apple oferece ferramentas poderosas de acessibilidade. VoiceOver é um leitor de tela integrado que vocaliza tudo o que acontece na tela. O usuário controla o dispositivo com gestos: deslizar para a direita — próximo elemento, deslizar para a esquerda — elemento anterior, toque duplo — ativação.

Accessibility Label é o texto que o VoiceOver lê para um elemento. Por padrão, o iOS usa o texto do botão ou rótulo, mas para ícones e elementos gráficos você precisa definir o rótulo explicitamente. Accessibility Trait é uma propriedade que descreve o tipo de elemento: button (botão), header (cabeçalho), link (link), image (imagem). Traits corretos ajudam o usuário a entender como interagir com um elemento.

VoiceOver e Accessibility Label

VoiceOver suporta mais de 40 idiomas e funciona em todos os dispositivos Apple. Para o desenvolvedor, o principal é definir accessibilityLabel e accessibilityTraits corretos para cada elemento da interface. Se um elemento não deve ser acessível (imagem decorativa), defina isAccessibilityElement = false.

// Swift — configuração de acessibilidade para um botão
let shareButton = UIButton()
shareButton.setImage(UIImage(named: "share-icon"), for: .normal)
shareButton.accessibilityLabel = "Compartilhar este artigo"
shareButton.accessibilityHint = "Abre um diálogo para escolher um método de envio"
shareButton.accessibilityTraits = .button

// SwiftUI — ainda mais simples
struct ShareButtonView: View {
    var body: some View {
        Button(action: share) {
            Image(systemName: "square.and.arrow.up")
        }
        .accessibilityLabel("Compartilhar")
        .accessibilityHint("Abre o menu de compartilhamento")
    }
}

O código mostra a configuração de acessibilidade para um botão sem texto (apenas ícone). AccessibilityLabel é o que o usuário ouvirá. AccessibilityHint é uma dica adicional sobre o resultado da ação. Não use frases como «botão para» no rótulo — Trait já indica que é um botão.

Android: TalkBack, Content Description

TalkBack é o leitor de tela do Google para Android, parte do pacote Android Accessibility Suite. Assim como o VoiceOver, ele vocaliza elementos da interface e é controlado por gestos. O TalkBack suporta mais de 100 idiomas e funciona em todos os dispositivos com Google Play Services.

Content Description é o equivalente do accessibilityLabel no Android. É definido através do atributo android:contentDescription em XML ou através do método setContentDescription() em código. Para elementos não focáveis (ImageView decorativo), use importantForAccessibility="no".

TalkBack e Focus Order

Focus Order (ordem de foco) é a sequência na qual o TalkBack se move entre os elementos ao deslizar. Por padrão, o Android usa a ordem dos elementos no layout, mas pode ser alterada através dos atributos accessibilityTraversalBefore e accessibilityTraversalAfter. Isso é importante para telas complexas com componentes personalizados.

Na IT Sectr, verificamos o Focus Order em cada tela. Erros de ordem de foco estão entre os problemas de acessibilidade mais comuns. Por exemplo, se após um cabeçalho o usuário vai para os comentários em vez do texto do artigo — isso é um bug de acessibilidade.

WCAG e padrões

WCAG (Web Content Accessibility Guidelines) é um padrão internacional de acessibilidade desenvolvido pelo W3C. A versão atual é WCAG 2.2 (2023). O padrão é dividido em 4 princípios: Perceivable (perceptível), Operable (operável), Understandable (compreensível), Robust (robusto) — abreviação POUR.

Níveis WCAG: A (mínimo), AA (médio, obrigatório por lei na UE), AAA (máximo). Para aplicações móveis, o nível AA é suficiente: contraste de texto de pelo menos 4.5:1, suporte a leitores de tela, tamanho mínimo de alvo de 44x44 pixels, legendas para vídeo.

Níveis WCAG

Nível A — requisitos básicos: alternativas de texto para imagens, controle por teclado, contraste de pelo menos 3:1. Nível AA — médio: contraste 4.5:1, suporte a escala de até 200%, cabeçalhos e rótulos corretos. Nível AAA — alto: contraste 7:1, língua de sinais para vídeo, controle total por voz. Na prática, a maioria das empresas visa AA.

Tabela 2. Comparação das APIs de acessibilidade iOS e Android. Apesar dos nomes diferentes, os conceitos são idênticos: rótulo, tipo, ordem de foco e suporte à adaptação de texto.

Testes de acessibilidade

Testes de acessibilidade é a verificação de uma aplicação quanto à conformidade com os padrões WCAG e operação correta com leitores de tela. O conjunto mínimo de testes: ativar VoiceOver/TalkBack e navegar por todas as telas da aplicação. Ouça para verificar se todos os elementos são anunciados, a ordem de foco é lógica e os elementos inadequados (decorativos) são ignorados.

Ferramentas automatizadas: Xcode Accessibility Inspector (auditoria no Xcode para iOS), Android Accessibility Scanner (escaneia a tela e encontra problemas), Axe DevTools, WAVE. Essas ferramentas verificam contraste, tamanho do alvo, presença de rótulos e outros parâmetros.

Na IT Sectr, realizamos uma revisão de acessibilidade antes de cada lançamento. O processo inclui: auditoria automatizada (Accessibility Inspector), teste manual com VoiceOver e TalkBack, verificação de contraste e escala de texto. Registramos problemas no Jira e os atribuímos a uma sprint. Isso nos permite manter o nível AA WCAG em todos os projetos.