Content Description: o que é, princípios e como definir para acessibilidade

O que é Content Description em acessibilidade

Content Description é uma propriedade de string de um elemento de interface que fornece uma representação textual do conteúdo visual para tecnologias assistivas. Um leitor de tela (VoiceOver no iOS, TalkBack no Android) lê a descrição em voz alta em vez de tentar reconhecer o elemento visualmente. As descrições são aplicadas a imagens sem camada de texto, ícones, gráficos, controles personalizados e quaisquer elementos não textuais.

De acordo com Google Material Design, 2024, elementos sem contentDescription violam WCAG 1.1.1 (Non-text Content). As verificações do Accessibility Scanner mostram que até 40% dos ícones em aplicativos de compras não têm descrições. Um usuário do VoiceOver ouve “imagem” ou “botão” sem especificações — essa interface se torna inutilizável para navegação.

Content Description não substitui o texto visível de um elemento. Se um botão contém o rótulo de texto “Enviar,” não é necessário definir uma descrição adicional — o leitor de tela lerá o texto. Para imagens, ícones e campos de entrada, a descrição é obrigatória.

As ferramentas Accessibility Scanner (Android) e Xcode Accessibility Inspector (iOS) verificam automaticamente a presença de descrições. Recomenda-se executar essas verificações em cada tela antes do lançamento.

Por que Content Description é importante: cenários de usuário

Um usuário com deficiência visual depende do VoiceOver para entender a interface. Se um ícone de carrinho de compras não tiver descrição, ele ouve apenas “botão.” Para descobrir o que o botão faz, ele precisa tocá-lo às cegas — arriscando uma ação irreversível. Uma descrição como “Remover item do carrinho” resolve esse problema em um segundo.

Um usuário com limitações temporárias (sol forte na rua, tela quebrada) também usa VoiceOver. De acordo com Apple Accessibility Report, 2023, cerca de 20% dos usuários do VoiceOver não têm deficiências visuais permanentes — eles ativam o recurso situacionalmente.

WCAG 1.1.1: Non-text Content

O critério WCAG 1.1.1 (Nível A) exige que todo conteúdo não textual tenha uma alternativa textual. Exceção: conteúdo que é decorativo, usado apenas para apresentação visual ou que não transmite informações. O teste de decoratividade: se você remover o elemento, o significado da página muda? Se não — pode ser ocultado do leitor de tela.

Diferença entre Content Description e Label

Accessibility Label (accessibilityLabel no iOS) é o nome do elemento que o leitor de tela pronuncia ao receber foco. Content Description (accessibilityHint no iOS) é um esclarecimento adicional anunciado após o nome que informa o resultado de uma ação.

A diferença fica clara com o exemplo de um botão “Carrinho”. Label: “Carrinho.” Description: “Abrirá a tela de finalização de compra.” VoiceOver diz: “Carrinho. Abrirá a tela de finalização de compra.” Se apenas o Label for definido, o usuário não saberá o que acontece após tocar.

Tabela: Label versus Description

Regra: Label responde a “O que é isso?”, Description responde a “O que vai acontecer?” No Android, contentDescription pode servir a ambos os papéis, mas na prática é melhor separá-los: usar a concatenação “[nome], [explicação].”

Quando Description é mais importante que Label

Para gestos complexos (deslizar para excluir, pressão longa para menu de contexto), accessibilityHint é obrigatório. Um usuário do VoiceOver não conhece gestos ocultos a menos que sejam descritos. Especifique: “Deslize para a esquerda para excluir” no hint do elemento.

iOS: o atributo accessibilityHint

Na plataforma iOS, accessibilityHint é definido através da propriedade de mesmo nome de UIView ou NSObject. O valor é uma string de até 80 caracteres. VoiceOver lê o hint após o label quando o modo de descrições detalhadas está ativado (nas configurações do VoiceOver — “Verbosity”).

Exemplo de definição de hint para um botão personalizado:

import UIKit

class CustomButton: UIButton {
    override func awakeFromNib() {
        super.awakeFromNib()
        self.accessibilityLabel = "Adicionar aos favoritos"
        self.accessibilityHint = "Salvará o item na lista de favoritos"
    }
}

Para UIImageView sem conteúdo textual, é obrigatório definir isAccessibilityElement = true e accessibilityHint:

let imageView = UIImageView(image: UIImage(named: "chart-sales"))
imageView.isAccessibilityElement = true
imageView.accessibilityHint = "Gráfico de vendas do último trimestre"

VoiceOver lê: “Gráfico de vendas do último trimestre.” Se o hint estiver vazio — apenas “imagem.” Apple HIG, 2024 recomenda não usar verbos como “toque” ou “aperte” nos hints — VoiceOver adiciona automaticamente uma instrução de gesto.

SwiftUI: o modificador accessibilityHint

No SwiftUI, o hint é definido através de um modificador em cadeia:

Image(systemName: "trash")
    .accessibilityLabel("Excluir")
    .accessibilityHint("Excluirá permanentemente o item selecionado")

SwiftUI combina automaticamente os modificadores para visualizações compostas. Se uma Image está dentro de um Button, o SwiftUI usa o rótulo do botão como accessibilityLabel principal.

Android: a propriedade contentDescription

No Android, contentDescription é definida seja na marcação XML ou programaticamente através de setContentDescription(). TalkBack anuncia a descrição quando o elemento recebe foco.

Exemplo em XML:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_search"
    android:contentDescription="Pesquisar produtos" />

Definição programática para elementos dinâmicos:

binding.iconSearch.contentDescription =
    "Pesquisar. Abrirá a tela de pesquisa com filtros"

Para imagens decorativas (separadores, fundos, ícones decorativos) defina contentDescription = "@null" ou setContentDescription(null) — TalkBack pulará tais elementos. Em XML: android:contentDescription="@null". Uma string vazia "" não funciona — TalkBack ainda anunciará “imagem.”

Android: detalhes importantes para ImageButton e CheckBox

Para ImageButton, sempre defina contentDescription — TalkBack não vê texto em imagens. Para CheckBox, a descrição deve mudar dinamicamente: “Selecionado” / “Não selecionado” em vez de uma descrição estática. Use setContentDescription no ouvinte de estado.

Regras para escrever descrições

Informatividade — a descrição deve transmitir significado, não aparência. Não “Ícone azul com uma marca de verificação,” mas “Item adicionado ao carrinho.” Um leitor de tela não se importa com cores — ele se importa com o resultado.

Concisão — o comprimento ideal é de 2 a 4 palavras (até 80 caracteres). Descrições longas retardam a navegação: VoiceOver lê sequencialmente, cada palavra é um segundo do tempo do usuário. De acordo com Apple WWDC 2023, “Accessibility by Design”, uma frase que leva mais de 5 segundos para ler interrompe o fluxo cognitivo.

Unicidade — não deve haver dois elementos na mesma tela com a mesma descrição. O usuário não conseguirá distinguir qual resultado será provocado pelo foco no primeiro versus no segundo elemento. Se houver vários botões “Comprar,” adicione um identificador: “Comprar iPhone 15,” “Comprar iPhone 15 Pro.”

Localização — Content Description deve ser traduzido para todos os idiomas que o aplicativo suporta. Um erro de localização nas descrições é uma das causas comuns de falha de uma Accessibility Review na App Store.

Comprimento da descrição: pesquisa

Uma pesquisa do Nielsen Norman Group, 2024 mostrou que o comprimento ideal da descrição para leitores de tela é de 3 a 5 palavras (até 50 caracteres). Descrições mais longas reduzem a velocidade de navegação em 30%, pois o usuário precisa esperar o anúncio terminar antes do próximo passo.

Erros comuns ao usar

Redundância — a descrição duplica o texto visível. Se um botão contém o texto “Enviar,” não defina accessibilityHint = “Botão enviar.” VoiceOver lerá o texto automaticamente, e o hint adicionará ruído desnecessário.

Confusão com Label — usar contentDescription em vez de label para botões de texto. No iOS, accessibilityLabel deve corresponder ao texto do botão (ou estar vazio se o texto já estiver visível), e o hint deve apenas esclarecer a ação. De acordo com Google Testing Blog, 2024, 23% dos aplicativos revisados na Play Store têm descrições duplicadas.

Ignorar a dinâmica — a descrição não é atualizada quando o estado muda. Por exemplo, a descrição de um interruptor “Wi-Fi” permanece “Ativar Wi-Fi” mesmo depois de ligado. Abordagem correta: mudar dinamicamente a descrição para “Desativar Wi-Fi” através da observação do estado.

Ciclos de renderização e regressões

Após uma atualização de design (mudança de ícones, reorganização de elementos), Content Description frequentemente se perde. Motivo: o designer substitui uma imagem, e o desenvolvedor não verifica as propriedades de acessibilidade do novo recurso. Solução: tornar a verificação de acessibilidade uma etapa obrigatória na revisão de código — adicionar um item de lista de verificação: “Content Description foi atualizado?”

Como verificar Content Description

• No iOS: Xcode → Accessibility Inspector — selecione o elemento, verifique os campos Label e Hint
• No Android: instale Accessibility Scanner da Play Store — execute na sua tela
• Em ambas as plataformas: ative VoiceOver/TalkBack e percorra toda a tela com gestos
• Escreva um teste de UI que verifique contentDescription para todos os ImageView

Exemplo de teste de UI para iOS

func testContentDescriptionExists() {
    let app = XCUIApplication()
    app.launch()
    let image = app.images["chart-sales"]
    XCTAssertNotNil(image.label)
    XCTAssertGreaterThan(image.label.count, 0)
}