Accessibility Label — o que é, conceitos básicos e como usar para iOS e Android

O que é Accessibility Label

Accessibility Label é uma propriedade de string que define o nome de um elemento para tecnologias assistivas. Quando o usuário desliza o dedo pela tela com o VoiceOver ativado, o leitor de tela lê o rótulo do elemento em foco. Sem um rótulo, o usuário ouve apenas o tipo do elemento: “botão”, “imagem” — sem indicar sua finalidade.

De acordo com Google I/O 2024, “Accessibility Testing”, 35% das violações críticas de acessibilidade em aplicativos de loja estão relacionadas à ausência ou incorreção dos rótulos. O Accessibility Scanner no Android detecta a falta de rótulo como um erro de gravidade máxima.

Uma limitação fundamental: o rótulo não deve conter o tipo do elemento. O VoiceOver e o TalkBack adicionam automaticamente o papel (botão, cabeçalho, link) ao anúncio. Se o rótulo contiver “Botão de enviar”, o usuário ouvirá: “Botão de enviar, botão” — duplicação.

Label e WCAG 4.1.2: Nome, Papel, Valor

WCAG 4.1.2 (nível A) exige que cada elemento da interface do usuário tenha um nome, papel e valor determináveis programaticamente. O Accessibility Label fornece o nome. Se o rótulo estiver ausente, o critério é considerado violado e o aplicativo não passa na certificação básica.

iOS: propriedade accessibilityLabel

No iOS, accessibilityLabel é herdado por todos os UIView do protocolo UIAccessibility. Se um elemento contém texto (UIButton com título, UILabel com texto), o rótulo é automaticamente definido para esse texto. Para UIImageView, controles personalizados e contêineres, o rótulo precisa ser definido manualmente.

Exemplo para uma célula de tabela personalizada:

class CustomTableViewCell: UITableViewCell {
    let titleLabel = UILabel()
    let priceLabel = UILabel()

    override func awakeFromNib() {
        super.awakeFromNib()
        self.isAccessibilityElement = true
        self.accessibilityLabel =
            "\(titleLabel.text ?? "") - \(priceLabel.text ?? "")"
    }
}

Para UIView personalizadas, você pode sobrescrever o getter accessibilityLabel:

class RatingView: UIView {
    var rating: Int = 5

    override var accessibilityLabel: String? {
        get { return "Avaliação: \(rating) de 5" }
        set {}
    }
}

Apple HIG, 2024 recomenda: se um elemento consiste em vários subelementos (por exemplo, um cartão de produto com nome e preço), combine-os em um único elemento de acessibilidade com um rótulo composto. Defina isAccessibilityElement = true no pai e false nos filhos.

NSAttributedString e accessibilityLabel

Se UILabel usa NSAttributedString, accessibilityLabel por padrão é igual a .string (texto simples). Se você precisar passar um valor semanticamente diferente (por exemplo, um ícone de símbolo é lido como “Estrela” em vez do caractere ★), defina accessibilityLabel explicitamente. O VoiceOver não lê caracteres Unicode de forma significativa.

Android: Label via contentDescription

No Android, contentDescription funciona como rótulo para ImageView, ImageButton e Views personalizadas. Para TextView e Button com texto incorporado, não é necessário definir contentDescription — o TalkBack lê o texto automaticamente.

Definição programática via Kotlin:

binding.iconStar.contentDescription = "Produto nos favoritos"

// Para View personalizada com múltiplos elementos
binding.customCard.setContentDescription(
    "\(title) por \(price)")

Em XML para elementos decorativos:

<ImageView
    android:contentDescription="@null"
    android:src="@drawable/divider"
    android:importantForAccessibility="no" />

A propriedade importantForAccessibility = “no” exclui completamente o elemento da árvore de acessibilidade. No iOS, o equivalente é isAccessibilityElement = false.

Compose: semantics e contentDescription

No Jetpack Compose, o rótulo é definido via modificador semantics:

Image(
    painter = painterResource(R.drawable.ic_search),
    contentDescription = "Pesquisar produtos",
    modifier = Modifier.semantics {
        contentDescription = "Pesquisar produtos"
    }
)

No Compose, contentDescription é um parâmetro obrigatório para Image — sem ele, o código não compila (aviso). Isso melhora forçadamente a acessibilidade através do design da API.

Label e Hint: diferença de papéis

Accessibility Label responde à pergunta “O que é este elemento?”. Hint (accessibilityHint no iOS, texto adicional em contentDescription no Android) — “O que acontecerá ao interagir?”. O VoiceOver os anuncia sequencialmente: primeiro Label, depois Hint.

Exemplo para um botão de excluir:

• Label: “Excluir”
• Hint: “Exclui permanentemente a foto selecionada”
• VoiceOver: “Excluir. Exclui permanentemente a foto selecionada”

De acordo com Deque University, 2024, a separação adequada de Label e Hint melhora a taxa de conclusão de tarefas para usuários do VoiceOver em 28%. Usuários com deficiências cognitivas dependem especialmente do Hint: ao não ter certeza sobre pressionar “Excluir” sem explicação, 40% recusam a ação.

Quando o Hint não é necessário

• Elemento com ação intuitivamente compreensível (“Voltar”, “Fechar” — Label é suficiente)
• Label já descreve o resultado (“Enviar mensagem” — verbo no próprio nome)
• Controles do sistema (UISwitch, UIButton com tipo de sistema) — seu comportamento é padrão

Erros comuns: Label em vez de Hint

Um erro frequente: escrever “Botão de excluir” no Label em vez de “Excluir”. O tipo do elemento (Botão) é adicionado pelo VoiceOver automaticamente através de uma característica. Como resultado, o usuário ouve: “Botão de excluir, botão” — duplicação. Label correto: “Excluir”, Hint: “Exclui a foto selecionada”.

Localização e melhores práticas

A localização de rótulos é obrigatória — ocorre através de mecanismos padrão: NSLocalizedString no iOS, recursos de string @string/ no Android. Nunca defina um rótulo por concatenação em inglês sem localização.

Regras para um bom rótulo, baseadas em W3C WCAG 2.2:

• Comece com a palavra-chave — “Pesquisar produtos”, não “Campo para pesquisar produtos”
• Não inclua as palavras “botão”, “campo”, “imagem” — o papel é adicionado automaticamente
• Use linguagem natural compreensível para o público-alvo
• Evite abreviações (exceto as comumente aceitas: “un.”, “kg”) — o leitor de tela as lê literalmente
• Para elementos de entrada, adicione um exemplo: “Email (exemplo@dominio.com)”

Consistência dos rótulos em toda a marca

Use um único glossário para rótulos em todo o aplicativo. Se uma tela diz “Favoritos” e outra diz “Marcadores”, o usuário fica desorientado. Crie uma tabela de termos de acessibilidade — coordene com designers e localizadores.

Rótulos para elementos de formulário

Para campos de entrada (UITextField, EditText), o rótulo deve corresponder ao placeholder ou ao rótulo do campo. No entanto, o placeholder muitas vezes desaparece após inserir o texto. Use accessibilityLabel para o nome permanente e accessibilityValue para o conteúdo atual do campo — este é o padrão WCAG 4.1.2. Solução: defina accessibilityLabel estaticamente (igual ao rótulo do campo) e accessibilityValue dinamicamente (igual ao texto inserido). No iOS isso é automático, mas para campos personalizados — manualmente sobrescrevendo accessibilityValue. Verifique se o VoiceOver lê: “Email, exemplo@dominio.com, campo de texto” em vez de “, campo de texto”.

Como testar rótulos de acessibilidade

Testes automatizados são a única maneira de garantir a correção dos rótulos em todas as telas. O iOS fornece XCUIApplication com acesso a .label, o Android — AccessibilityCheckRule e setContentDescription.

Exemplo de teste para iOS:

func testLabelsAreUnique() {
    let app = XCUIApplication()
    app.launch()
    let allButtons = app.buttons.allElementsBoundByIndex
    let labels = allButtons.compactMap { $0.label }
    let uniqueLabels = Set(labels)
    XCTAssertEqual(labels.count, uniqueLabels.count,
        "Rótulos duplicados encontrados")
}

Exemplo para Android com Espresso:

@Test
fun testButtonHasAccessibilityLabel() {
    onView(withId(R.id.btnSubmit))
        .check(matches(
            withContentDescription(containsString("Enviar"))
        ))
}

Testes manuais: ative o VoiceOver (iOS) ou TalkBack (Android) e deslize para a direita por todos os elementos da tela. Cada elemento deve receber um anúncio significativo. Se você ouvir apenas “botão” ou “imagem” — o rótulo está ausente.

Rotore do VoiceOver e navegação rápida

Após configurar o rótulo, os usuários do VoiceOver podem usar o rotore para navegação rápida: modos “Botões”, “Cabeçalhos”, “Links” e outros. Se o rótulo estiver configurado corretamente, o VoiceOver inclui o elemento no modo de rotore correspondente. Verifique se todos os botões estão visíveis no modo “Botões”, todos os cabeçalhos em “Cabeçalhos”.

O rótulo também afeta a pesquisa do VoiceOver. O usuário pode digitar uma palavra no modo de pesquisa, e o VoiceOver moverá o foco para o elemento com um rótulo correspondente. Portanto, os rótulos devem conter palavras-chave que o usuário pesquisará.

Integração no pipeline CI/CD

Adicione a verificação de rótulos ao pipeline. No iOS, use XCUITest com fastlane scan. No Android, use Accessibility Test Framework com a regra AccessibilityCheckRule que detecta contentDescription vazios. Isso evita regressões ao mesclar novas telas.