--- title: "Acessibilidade no Android com Kotlin e Compose em 2026 | Kotlin Brasil" url: "https://kotlin.dev.br/blog/acessibilidade-android-compose-kotlin-2026/" markdown_url: "https://kotlin.dev.br/blog/acessibilidade-android-compose-kotlin-2026.MD" description: "Aprenda acessibilidade no Android com Kotlin e Jetpack Compose: TalkBack, semantics, contentDescription, foco, contraste, testes e checklist para produção." date: "2026-06-03" author: "Karina Melo" --- # Acessibilidade no Android com Kotlin e Compose em 2026 | Kotlin Brasil Aprenda acessibilidade no Android com Kotlin e Jetpack Compose: TalkBack, semantics, contentDescription, foco, contraste, testes e checklist para produção. Acessibilidade em apps Android ainda é tratada por muitos times como acabamento visual, mas em 2026 ela virou parte central de qualidade, produto e empregabilidade. Bancos, varejo, saúde, educação, governo, mobilidade e plataformas B2B precisam atender pessoas que usam leitor de tela, fonte ampliada, navegação por teclado, controles externos, alto contraste ou apenas um celular antigo em uma situação ruim de luz. Quando o app falha nesse ponto, ele não fica apenas “menos bonito”: ele bloqueia uma parte real dos usuários. Com **Kotlin e Jetpack Compose**, acessibilidade ficou mais fácil de modelar porque a UI é declarativa e os componentes Material já carregam várias informações semânticas. Ao mesmo tempo, Compose não resolve tudo automaticamente. Um ícone sem `contentDescription`, uma área de toque pequena, uma ordem de foco confusa ou um texto que não cresce com a fonte do sistema continuam gerando experiências ruins. Para quem já estudou [Jetpack Compose](/guias/guia-jetpack-compose/), [MVVM com Kotlin](/tutoriais/kotlin-mvvm-tutorial/) e [testes Android com Compose e Maestro](/guias/testes-android-compose-maestro/), acessibilidade é o próximo passo para transformar telas funcionais em produto pronto para produção. Este guia mostra como pensar acessibilidade no Android moderno: descrições, semântica, TalkBack, foco, tamanhos de toque, formulários, estados de erro, testes automatizados e revisão manual. A ideia não é decorar uma lista de regras, mas criar um hábito técnico que melhora a experiência de todo mundo. ## O que acessibilidade significa em um app Android? Acessibilidade é a capacidade de uma pessoa usar o app mesmo quando ela não interage do jeito que o designer imaginou. Isso inclui deficiência visual, baixa visão, daltonismo, deficiência motora, deficiência auditiva, neurodivergência, idade avançada, lesão temporária, uso com uma mão, tela pequena, ambiente barulhento ou conexão ruim. No Android, os recursos mais comuns envolvidos são: - TalkBack e outros leitores de tela; - tamanho de fonte e escala de exibição do sistema; - navegação por teclado, D-pad ou switch access; - contraste e modo escuro; - feedback textual para erro, carregamento e sucesso; - alvos de toque grandes o suficiente; - estrutura semântica clara para componentes customizados. O ponto prático é simples: se a tela depende apenas de cor, posição visual, gesto delicado ou ícone sem texto, provavelmente existe um usuário que não consegue completar a tarefa. ## Comece pela semântica correta Em Compose, a árvore visual não é exatamente a mesma coisa que a árvore de acessibilidade. Componentes como `Button`, `TextField`, `Checkbox` e `Switch` já expõem papéis úteis para tecnologias assistivas. O risco aparece quando criamos componentes customizados com `Box`, `Row`, `Icon` e `Modifier.clickable` sem informar o significado. Um card clicável de produto, por exemplo, precisa ser entendido como ação, não apenas como um agrupamento bonito: ```kotlin @Composable fun ProdutoCard( produto: Produto, onAbrir: () -> Unit, ) { Row( modifier = Modifier .fillMaxWidth() .clickable(onClickLabel = "Abrir detalhes de ${produto.nome}") { onAbrir() } .semantics { role = Role.Button } .padding(16.dp), verticalAlignment = Alignment.CenterVertically, ) { Text(produto.nome, modifier = Modifier.weight(1f)) Text(produto.precoFormatado) } } ``` O `onClickLabel` ajuda o leitor de tela a anunciar a intenção da ação. O `role` evita que um elemento interativo pareça apenas texto. Isso é especialmente importante em design systems próprios, onde muitos componentes são montados do zero. ## `contentDescription`: quando usar e quando não usar `contentDescription` descreve imagens e ícones para usuários de leitor de tela. O erro comum é preencher tudo de forma mecânica. Nem toda imagem precisa ser anunciada. Se um ícone é puramente decorativo ao lado de um texto que já explica a ação, a descrição pode ser `null`. Se o ícone é a única indicação da ação, a descrição é obrigatória. ```kotlin IconButton(onClick = onFavoritar) { Icon( imageVector = Icons.Default.Favorite, contentDescription = "Favoritar artigo", ) } Row(verticalAlignment = Alignment.CenterVertically) { Icon( imageVector = Icons.Default.Check, contentDescription = null, ) Text("Pagamento confirmado") } ``` No primeiro caso, sem descrição, a pessoa ouviria algo genérico ou inútil. No segundo, anunciar “ícone de check” antes de “pagamento confirmado” só adicionaria ruído. A regra é perguntar: **essa descrição ajuda a entender ou executar a tarefa?** Evite também descrições que repetem o tipo visual: “botão de salvar” em um botão que já tem texto “Salvar” pode virar redundância. Prefira linguagem de ação: “Remover endereço”, “Abrir comprovante”, “Expandir detalhes da vaga”. ## Estados precisam ser anunciados Apps modernos têm loading, erro, vazio, atualização, filtro aplicado, item selecionado e operação pendente. Visualmente, o usuário percebe spinner, cor, skeleton ou badge. Para acessibilidade, esses estados precisam aparecer em texto, semântica ou anúncio. Em uma tela de lista, não basta trocar conteúdo silenciosamente depois de uma busca. Mostre estado textual e, quando necessário, use semântica para indicar que aquela região mudou: ```kotlin @Composable fun ResultadoBusca(status: BuscaStatus) { when (status) { BuscaStatus.Carregando -> Text( text = "Carregando resultados", modifier = Modifier.semantics { liveRegion = LiveRegionMode.Polite }, ) is BuscaStatus.Erro -> Text( text = "Não foi possível carregar. Tente novamente.", color = MaterialTheme.colorScheme.error, ) is BuscaStatus.Vazio -> Text("Nenhum resultado encontrado para este filtro.") is BuscaStatus.Sucesso -> Text("${status.total} resultados encontrados") } } ``` Use `liveRegion` com moderação. Se tudo na tela anuncia mudança, o app vira uma sequência irritante de interrupções. Ele é útil para mensagens importantes que mudam sem uma ação direta visível, como resultado de busca, erro assíncrono ou confirmação crítica. ## Tamanho de toque e espaçamento não são detalhe Um botão pequeno pode parecer elegante, mas ser impossível para quem tem tremor, usa uma mão no ônibus ou navega em tela compacta. O Material Design recomenda alvos de toque com pelo menos 48 dp. Em Compose, componentes Material geralmente respeitam isso, mas elementos customizados podem quebrar a regra facilmente. ```kotlin Text( text = "Editar", modifier = Modifier .minimumInteractiveComponentSize() .clickable { onEditar() } .padding(horizontal = 12.dp, vertical = 8.dp), ) ``` Quando o layout está apertado, não reduza alvo de toque como primeira solução. Reorganize ações, use menu, aumente espaçamento ou transforme links críticos em botões claros. Um app profissional prioriza a tarefa, não apenas a densidade visual. ## Texto deve respeitar escala de fonte Muita tela Android quebra quando o usuário aumenta a fonte do sistema. Cards ficam cortados, botões perdem label, campos sobrepõem ícones e modais deixam ações fora da tela. Isso é comum quando o layout usa alturas fixas, linha única forçada ou componentes que não aceitam quebra. Boas práticas: - evite altura fixa para componentes com texto; - permita múltiplas linhas em títulos e descrições importantes; - teste com fonte grande no emulador; - não use `sp` minúsculo para “resolver” falta de espaço; - prefira rolagem quando o conteúdo pode crescer; - confirme que botões continuam legíveis em português, que costuma ter labels maiores. Se você cria design system, inclua estados com texto longo nas previews. Uma preview bonita com “OK” não prova que “Solicitar segunda via do comprovante” cabe no layout real. ## Contraste, cor e feedback visual Cor ajuda, mas não pode ser a única fonte de informação. Um campo inválido que muda apenas de borda verde para vermelha não comunica o suficiente para pessoas com daltonismo, baixa visão ou leitor de tela. Combine cor com texto, ícone significativo e estado semântico. ```kotlin OutlinedTextField( value = email, onValueChange = onEmailChange, label = { Text("E-mail") }, isError = erroEmail != null, supportingText = { if (erroEmail != null) { Text(erroEmail) } }, ) ``` Esse padrão é melhor que mostrar apenas uma borda vermelha. O texto de apoio explica o problema, aparece visualmente e pode ser anunciado pelo leitor de tela durante a navegação. Também revise contraste em modo claro e escuro. Apps Android costumam ter bom contraste em textos principais, mas falham em placeholder, label desabilitada, badge, texto sobre imagem e chips selecionados. ## Formulários acessíveis em Kotlin Formulários são onde acessibilidade compra mais resultado de negócio. Cadastro, login, checkout, candidatura a vaga, agendamento e pagamento precisam ser completáveis por todos. Um formulário acessível tem labels claros, teclado correto, ordem de foco previsível, validação compreensível e erro perto do campo afetado. Use `keyboardOptions` para reduzir esforço: ```kotlin OutlinedTextField( value = telefone, onValueChange = onTelefoneChange, label = { Text("Telefone") }, keyboardOptions = KeyboardOptions( keyboardType = KeyboardType.Phone, imeAction = ImeAction.Next, ), ) ``` Não use placeholder como substituto de label. Placeholder desaparece quando a pessoa digita e pode ser menos acessível. Também evite mensagens vagas como “campo inválido”. Explique: “Digite um e-mail com @ e domínio”, “A senha precisa ter pelo menos 8 caracteres”, “Selecione uma data futura”. ## Ordem de foco e navegação Quem usa TalkBack, teclado ou controles externos percorre a tela em ordem. Se a ordem semântica não combina com a ordem visual, a experiência fica confusa. Isso aparece em layouts com grids, cards complexos, banners promocionais e ações posicionadas fora do fluxo. Em Compose, a ordem natural geralmente segue a árvore de composição. Por isso, organize o código para refletir a leitura da tela. Se um botão aparece visualmente dentro de um card, mas no código fica em outro container distante, teste a navegação. Em alguns casos, agrupar semântica ajuda: ```kotlin Column( modifier = Modifier.semantics(mergeDescendants = true) {} ) { Text("Plano Pro") Text("R$ 49 por mês") Text("Inclui relatórios e suporte prioritário") } ``` `mergeDescendants` faz sentido quando vários textos formam uma única unidade de compreensão. Não use em excesso, porque pode esconder controles internos que deveriam ser navegáveis separadamente. ## Testes automatizados ajudam, mas não substituem uso real Compose UI Test permite validar semântica, texto e ações acessíveis. Isso evita regressões simples, especialmente em componentes reutilizáveis. ```kotlin @Test fun botaoFavoritarTemDescricaoAcessivel() { composeTestRule.setContent { ArtigoActions(onFavoritar = {}) } composeTestRule .onNodeWithContentDescription("Favoritar artigo") .assertExists() .assertHasClickAction() } ``` Você também pode testar mensagens de erro, labels de formulário e estado vazio. Em um design system, crie testes para botões, campos, cards clicáveis, banners de alerta e componentes de navegação. Isso combina bem com [testes de screenshot no Compose](/blog/testes-screenshot-compose-kotlin-2026/), mas lembre que screenshot valida pixels; acessibilidade valida intenção e interação. Mesmo com testes, use TalkBack manualmente. Navegue pelo fluxo principal sem olhar para a tela. Tente abrir uma lista, filtrar, entrar em detalhe, corrigir erro e concluir uma ação. Esse exercício revela problemas que testes unitários não capturam. ## Checklist prático antes de publicar Antes de considerar uma tela pronta, valide: - todos os botões de ícone têm `contentDescription` útil ou `null` quando decorativos; - cards clicáveis têm ação e papel semântico claros; - textos importantes não cortam com fonte grande; - campos têm label, teclado adequado e erro textual; - mensagens de loading, vazio e erro são visíveis e compreensíveis; - a ordem de foco segue a ordem visual; - contraste funciona em modo claro e escuro; - ações têm alvo de toque confortável; - TalkBack consegue completar o fluxo principal; - testes cobrem componentes acessíveis críticos. Para carreira, esse checklist também é uma ótima forma de diferenciar portfólio. Muitas pessoas mostram apps bonitos; poucas mostram apps que funcionam com fonte ampliada, leitor de tela e erro bem tratado. ## Acessibilidade e mercado Android no Brasil Acessibilidade aparece cada vez mais em vagas Android sênior porque empresas grandes não podem depender de telas frágeis. Apps financeiros, e-commerce, saúde, governo e educação precisam reduzir risco jurídico, melhorar conversão e atender públicos diversos. Saber falar sobre TalkBack, semântica, testes de UI e WCAG mostra maturidade além de “sei fazer tela em Compose”. Esse conhecimento também conversa com qualidade de engenharia. Um time que cuida de acessibilidade normalmente também cuida de [Crashlytics e estabilidade](/blog/firebase-crashlytics-anr-android-kotlin-2026/), testes, design system, arquitetura e revisão de produto. Para comparar como outras comunidades tratam qualidade e experiência, vale observar o ecossistema de Python para automação e testes, que popularizou práticas de validação simples e repetíveis em times de produto. ## Conclusão Acessibilidade no Android com Kotlin não é uma camada extra para o fim do projeto. Ela começa na escolha dos componentes, passa pela semântica do Compose, aparece em cada label de formulário e precisa ser verificada com testes e uso real. O melhor momento para corrigir um botão sem descrição é quando ele nasce, não depois que o app já virou uma coleção de exceções. Use componentes Material quando fizer sentido, descreva ações com clareza, preserve tamanho de toque, trate erro com texto, respeite escala de fonte e teste com TalkBack. Esses cuidados deixam o app melhor para pessoas com deficiência e também para qualquer usuário em contexto difícil. Em 2026, um app Android profissional não é apenas rápido, bonito e escrito em Kotlin idiomático. Ele também é possível de usar.