Screen Reader: o que é, tipos de leitores de tela e princípio de funcionamento

O que é um Screen Reader?

Screen Reader (leitor de tela) é uma tecnologia assistiva (Assistive Technology, AT) que interpreta a interface gráfica do usuário e a apresenta de forma não visual: através de fala sintetizada ou um display Braille tátil. Os leitores de tela são o principal meio de acesso a computadores e dispositivos móveis para pessoas com perda total ou parcial da visão.

Os primeiros leitores de tela surgiram no final da década de 1980 para MS-DOS (por exemplo, Vocal-Eyes) e posteriormente para Windows (JAWS, NVDA). Nas plataformas móveis, os leitores de tela foram integrados a nível de sistema: a Apple integrou o VoiceOver no iPhone 3GS em 2009, o Google integrou o TalkBack no Android 1.6 no mesmo ano. Em 2025, praticamente todos os smartphones modernos possuem um leitor de tela integrado que não requer instalação de software adicional.

Um leitor de tela não apenas lê texto da tela — ele analisa a hierarquia da interface, determina os tipos de elementos (botão, link, cabeçalho, campo de entrada), seus estados (ativado/desativado, selecionado/não selecionado) e relacionamentos (pai-filho, grupo). Esta informação é transmitida ao usuário através de prompts de voz ou sensações táteis de um display Braille, que atualiza as células em tempo real de acordo com a posição do foco.

Como funciona um Screen Reader?

Um leitor de tela trabalha em estreita colaboração com o sistema operacional, obtendo acesso à sua representação interna da interface — a árvore de acessibilidade (Accessibility Tree). Este mecanismo é o mesmo no iOS e Android, embora os nomes das APIs sejam diferentes.

Conversão de texto em fala (TTS)

O canal de saída principal de um leitor de tela é um sintetizador de fala (Text-To-Speech, TTS). Quando o foco de acessibilidade pousa em um elemento, o leitor de tela extrai seu conteúdo textual (ou a descrição fornecida pelo desenvolvedor) e o envia ao mecanismo TTS. Mecanismos TTS modernos, como o Apple Speech Synthesis e o Google Text-to-Speech, usam redes neurais para gerar fala natural com entonação, pausas e ênfase corretas, dependendo da pontuação e do tipo de conteúdo.

O usuário pode ajustar a velocidade da fala (geralmente de 60 a 80% do máximo para uma percepção confortável), o tom e o volume. Alguns leitores de tela suportam várias vozes e alternam entre elas dependendo do tipo de conteúdo — por exemplo, uma voz mais lenta para ler texto e uma mais rápida para navegação na interface. Os displays Braille conectam-se via Bluetooth e exibem até 40 a 80 caracteres por vez, atualizando a linha a cada mudança de foco.

Gerenciamento de foco e navegação

Um leitor de tela usa o conceito de Foco de Acessibilidade (Accessibility Focus), que difere do foco de entrada padrão. O usuário move o foco de acessibilidade usando gestos (toque, deslize), e o leitor de tela anuncia o elemento sob o foco. A ordem de navegação padrão segue a ordem visual: da esquerda para a direita, de cima para baixo. O desenvolvedor pode substituir essa ordem para layouts complexos.

O leitor de tela também suporta vários modos de navegação que o usuário alterna através do rotor (VoiceOver) ou menu (TalkBack): por cabeçalhos, links, caracteres, palavras, formulários. No modo de cabeçalhos, o leitor de tela se move apenas entre H1–H6 — isso é crítico para uma navegação eficiente em páginas e documentos longos. O modo de caracteres ajuda ao inserir códigos de confirmação ou senhas complexas, pronunciando cada caractere individualmente.

Principais leitores de tela para plataformas móveis

Dois leitores de tela dominam as plataformas móveis: VoiceOver no iOS e TalkBack no Android. Eles possuem APIs, gestos e capacidades diferentes, mas o princípio comum é ler a árvore de acessibilidade e o controle por gestos.

VoiceOver (iOS)

VoiceOver é o leitor de tela da Apple, integrado no iOS, iPadOS e macOS. Ele usa a API UIAccessibility para obter informações sobre os elementos e suporta o rotor para alternar modos de navegação. O VoiceOver é integrado ao iCloud (as configurações sincronizam entre dispositivos), Apple Pay (confirmação de pagamento via Touch ID ou Face ID) e Texto Dinâmico (a fonte se adapta às configurações do usuário).

Os gestos do VoiceOver diferem do TalkBack: usa rotação com dois dedos (rotor), toque triplo para Screen Curtain e toque duplo com dois dedos para cancelar uma ação. O VoiceOver suporta rotores personalizados que o desenvolvedor adiciona através de UIAccessibilityCustomRotor — por exemplo, para navegação rápida pelas seções do aplicativo, ignorando a ordem padrão.

TalkBack (Android)

TalkBack é o leitor de tela do Google, parte do Android Accessibility Suite. Ele usa AccessibilityService e AccessibilityNodeInfo para acessar a interface. O TalkBack suporta um menu global via deslize em forma de L, ações personalizadas para elementos e LiveRegion para atualizações dinâmicas. A partir do Android 14, o TalkBack ganhou suporte a gestos com uma mão e melhor integração com o Google Assistant.

O TalkBack possui um sistema de gestos mais flexível que o VoiceOver: o usuário pode atribuir praticamente qualquer gesto a qualquer ação. O TalkBack também suporta entrada Braille na tela (BrailleBack) — o usuário insere texto com caracteres Braille diretamente na tela sensível ao toque em um layout especial de 3×2 por dedo, o que acelera significativamente a digitação em comparação com o teclado na tela.

Além do VoiceOver e TalkBack, existem leitores de tela móveis menos comuns: Select to Speak (Android, vocaliza a área selecionada), Samsung Voice Assistant (substitui o TalkBack em dispositivos Samsung com One UI) e soluções de terceiros para nichos específicos — como para usuários de smartphones chineses sem serviços do Google.

Como um Screen Reader interage com o aplicativo

Um leitor de tela não tem acesso direto aos componentes de interface do aplicativo. Em vez disso, ele funciona através de uma camada — a API de acessibilidade do sistema operacional. O sistema operacional constrói uma árvore de acessibilidade (Accessibility Tree) que o leitor de tela percorre e analisa.

Árvore de acessibilidade no iOS e Android

No iOS, a árvore de acessibilidade é construída a partir de objetos UIAccessibilityElement correspondentes a cada View na tela. Cada elemento contém um label (texto principal), traits (tipo de elemento: botão, cabeçalho, link), hint (dica), value (valor atual para controles deslizantes e indicadores) e frame (área de toque). O sistema cria automaticamente elementos para componentes de interface padrão, mas o desenvolvedor pode adicioná-los e personalizá-los.

No Android, a árvore de acessibilidade é construída a partir de objetos AccessibilityNodeInfo. Cada nó contém: text (texto ou contentDescription), className (tipo de elemento), contentDescription (descrição), stateDescription (estado), isEnabled, isChecked, isClickable e outros indicadores. O Android também suporta AccessibilityAction — uma lista de ações que o leitor de tela pode realizar em nome do usuário: clique, pressão longa, rolagem, definir foco, definir texto.

Eventos de acessibilidade

Quando ocorre uma mudança na interface (um novo elemento aparece, o texto muda, um elemento se torna visível ou invisível), o sistema operacional envia um AccessibilityEvent. O leitor de tela se inscreve nesses eventos e reage a eles: por exemplo, quando uma caixa de diálogo aparece, o leitor de tela move automaticamente o foco para seu título e anuncia o conteúdo.

// Escuta de eventos de acessibilidade no Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

No iOS, eventos semelhantes são tratados através de UIAccessibility.Notification: layoutChanged (layout mudou), screenChanged (tela completamente nova), announcement (anúncio personalizado), pageScrolled (rolagem de página). O desenvolvedor envia esses eventos via UIAccessibility.post para que o leitor de tela responda corretamente às mudanças. Por exemplo, ao abrir uma janela modal, é necessário enviar screenChanged com o novo título — caso contrário, o VoiceOver permanece no elemento anterior sob a janela.

Desenvolvimento de aplicativos para Screen Reader

Criar um aplicativo acessível não se resume a adicionar contentDescription a cada elemento — trata-se de projetar a experiência do usuário para interação não visual. As regras básicas são as mesmas para ambas as plataformas, embora a implementação varie.

Regras básicas de acessibilidade

Todos os elementos interativos devem ter uma descrição significativa: um botão “Enviar” deve ser descrito como “Enviar mensagem”, não apenas “Botão”. Elementos decorativos (separadores, imagens de fundo, ícones não funcionais) devem ser ocultados do leitor de tela. A ordem de navegação deve seguir o fluxo lógico da tela, não o layout visual. O contraste do texto deve ser de pelo menos 4.5:1 para texto normal e 3:1 para texto grande (WCAG AA).

// iOS: configuração correta para um elemento complexo
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volume do som"
customControl.accessibilityValue = "75 por cento"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Aumenta ou diminui o volume"

// Atualização ao alterar o valor
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) por cento"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

No iOS, a flag isAccessibilityElement ativa o suporte ao VoiceOver para elementos personalizados. A combinação de traits (.adjustable + .button) informa ao VoiceOver que o elemento pode ser ajustado deslizando para cima/baixo e ativado com toque duplo. Após alterar o valor, uma notificação layoutChanged deve ser enviada — caso contrário, o VoiceOver continuará anunciando o valor antigo.

Recomendações específicas para cada plataforma

Para iOS: use accessibilityElements para substituir a ordem de leitura, accessibilityCustomActions para ações adicionais no menu de contexto e shouldGroupAccessibilityChildren para agrupar elementos em grupos lógicos. Para SwiftUI, use os modificadores .accessibilityLabel(), .accessibilityAddTraits() e .accessibilityRespondsToUserInteraction(). Evite definir isAccessibilityElement = false em contêineres que contenham elementos filhos interativos — isso os ocultará do VoiceOver.

Para Android: use accessibilityTraversalBefore e accessibilityTraversalAfter para ordem de navegação, AccessibilityDelegate para elementos personalizados e LiveRegion (polite/assertive) para atualizações dinâmicas. No Compose, use o modificador .semantics {} com contentDescription, stateDescription e customActions. Evite definir focusable = true em elementos não interativos — isso cria pontos de foco falsos para o TalkBack e confunde o usuário.

Ferramentas de teste

O teste com um leitor de tela deve ser feito em um dispositivo físico. Um emulador/simulador fornece uma compreensão básica, mas os gestos e a velocidade de resposta diferem. Use o Accessibility Inspector (Xcode) para iOS e o Accessibility Scanner (Android) para detecção automática de problemas.

Principais cenários de teste: registro (preencher formulário, validação, envio), pesquisa e navegação no catálogo, finalização da compra, recuperação de senha. Cada cenário deve ser concluído sem controle visual — apenas através dos prompts de voz do leitor de tela. Se um usuário de leitor de tela não conseguir concluir um cenário no mesmo tempo que um usuário comum (±50%), o aplicativo precisa de melhorias de acessibilidade.