Todo Mundo Consegue Usar o Seu App Feito com IA? Um Guia Simples de Acessibilidade

Quando você constrói um app com IA, você o testa do jeito que você mesmo usa: sua tela, seus olhos, sua pegada firme e com as duas mãos no laptop. O problema é que uma boa parte das pessoas que vão abrir o seu app não o usam assim. Alguém aumenta o zoom do texto do celular para o dobro do tamanho normal. Alguém não consegue diferenciar a sua mensagem de erro em vermelho do texto preto ao redor. Alguém está segurando um bebê e tocando na tela com um polegar só. Acessibilidade de app é simplesmente saber se essas pessoas ainda conseguem usar o app — e essa é uma pergunta que a maioria dos apps feitos com IA nunca chega a responder.

Você não precisa de um diploma nem de uma equipe de compliance para resolver isso. Você precisa saber quais são os quatro ou cinco pontos em que os apps costumam deixar as pessoas de fora, e como pedir para o seu builder corrigir isso. Deixa eu te mostrar os casos mais comuns com histórias, porque fica mais fácil identificá-los depois que você já viu um exemplo.

Por que o layout do meu app quebra quando alguém aumenta o zoom?

Porque a maioria dos apps feitos com IA é desenhada para um único tamanho fixo de texto, então quando alguém aumenta o texto do celular ou do navegador — algo que muita gente faz, especialmente pessoas com mais de sessenta anos — os botões se sobrepõem, as colunas desmoronam numa pilha bagunçada e os controles deslizam um por cima do outro.

Uma criadora que eu conheço construiu um appzinho bem organizado de agendamento para o salão de cabeleireiro da mãe dela. Ficou ótimo. Aí a mãe dela abriu o app, e a primeira coisa que ela fez — como muita gente com mais de sessenta anos — foi dar aquele beliscão na tela para aumentar o texto. O layout desmoronou. Os botões se sobrepuseram, o botão “Agendar” deslizou para debaixo do menu, e uma coluna de horários virou uma pilha bagunçada, impossível de ler.

Essa é a quebra de acessibilidade mais comum nos apps feitos com IA, e ela fica invisível até alguém dar zoom. Peça ao seu builder: “Garanta que o layout continue funcionando quando o texto estiver com 200% de zoom. Nada deve se sobrepor ou ficar cortado.” Depois teste você mesmo — no seu celular, aumente o tamanho da fonte do sistema para o máximo e abra o seu app. Se ele desmoronar, esse é o seu primeiro ajuste.

Por que o meu app não deveria usar só a cor para mostrar status?

Porque cerca de um em cada doze homens enxerga as cores de forma diferente, mais comumente vermelho e verde — então um status mostrado apenas como um ponto vermelho versus um ponto verde parece igual para eles, e eles realmente não conseguem diferenciar “pago” de “atrasado”.

Um freelancer construiu um controle de faturas que mostrava o status só pela cor — ponto verde, ponto vermelho. Um dos clientes dele, que por acaso era daltônico (não distinguia vermelho de verde), vivia pagando faturas que já tinham sido pagas, porque os dois pontos pareciam idênticos para ele. A informação estava lá. Só não estava lá para ele.

A solução é um hábito, não uma funcionalidade: nunca use a cor como a única forma de comunicar algo. Adicione uma palavra, um ícone ou um formato junto com ela. “Atrasado” ao lado do vermelho. Uma marca de verificação ao lado do verde. Um asterisco e a palavra “obrigatório”, não só um contorno vermelho. A cor pode continuar ali — só não pode ser a única portadora da mensagem.

Por que os leitores de tela só dizem “botão” em vez de dizer o nome dele?

Porque um botão de ícone sem rótulo — uma lixeira, um lápis, uma lupa sem nenhuma palavra — não tem texto para o leitor de tela (o software que pessoas cegas e com baixa visão usam para ouvir a tela em voz alta) anunciar, então ele lê, literalmente, “botão”. Não “excluir”. Não “editar”. Só “botão”.

Os builders de IA adoram botões de ícone limpos porque eles parecem modernos. Mas imagine usar um app em que todo controle se chama “botão” e você tem que adivinhar o que faz. Você não precisa adicionar texto visível em cada ícone — precisa garantir que cada controle tenha um nome por trás, mesmo que invisível, que o leitor de tela consiga anunciar. Peça ao seu builder: “Dê a cada botão de ícone um rótulo acessível — um ícone de lixeira deve ser anunciado como ‘Excluir’, um lápis como ‘Editar’.” É uma mudança pequena, e é a diferença entre um app que uma pessoa cega consegue navegar e um que é uma parede de botões anônimos.

Qual deve ser o tamanho dos alvos de toque em um app para celular?

A regra geral que os designers usam é que qualquer elemento tocável deve ter cerca de 44 pixels — mais ou menos o tamanho de uma ponta de dedo — com espaçamento de verdade para que dois elementos tocáveis não fiquem espremidos um colado no outro.

Observe alguém usando o seu app com uma mão só, dentro de um ônibus. Os polegares são largos e imprecisos, o ônibus está balançando, e o “X” para fechar é um pontinho de 16 pixels no canto. A pessoa erra duas vezes, acerta a coisa atrás dele uma vez, e desiste. Alvos de toque pequenos e apertados são um problema de acessibilidade, não só um incômodo — eles atingem com mais força quem tem tremores, dedos maiores, ou está num ambiente em movimento. Peça ao seu builder: “Faça os alvos de toque terem pelo menos 44 pixels e adicione espaçamento entre eles para que as pessoas não toquem no elemento errado.” Depois teste: abra o seu app no celular e tente fazer a ação principal com uma mão só, andando. Se você continuar errando o toque, todo mundo também vai errar.

Como eu testo a acessibilidade do meu app em cinco minutos?

Você consegue identificar a maior parte disso sozinho, sem nenhuma ferramenta, com três verificações rápidas na tela mais usada pelas pessoas:

1. Dê zoom. Aumente o texto do celular ou do navegador para a configuração máxima e abra a tela principal. Alguma coisa se sobrepõe, some ou fica cortada?
2. Tire a cor. Olhe para todo lugar em que o seu app usa a cor para comunicar algo — status, erros, campos obrigatórios. Se você imaginar tudo em escala de cinza, ainda consegue entender o que está acontecendo? Se não, adicione uma palavra ou um ícone.
3. Ative o leitor de tela por dois minutos. Tanto o iPhone (VoiceOver) quanto o Android (TalkBack) já vêm com um. Ative, feche os olhos e tente fazer a ação principal do seu app. Você vai perceber na hora quais botões estão sem nome.

Nada disso exige que você seja desenvolvedor. Exige que você pare de testar como você mesmo por cinco minutos e teste como alguém cujas mãos, olhos ou tela são diferentes dos seus.

Você não precisa corrigir tudo de uma vez. Escolha a tela mais usada pelas pessoas — o formulário de agendamento, o cadastro, a lista principal — e faça essa tela funcionar quando tiver zoom, sem cor e lida em voz alta. Essa única tela, bem feita, alcança mais gente do que uma auditoria completa de acessibilidade nos cantos que ninguém visita. Comece por aí, e a próxima pessoa que abrir o seu app com um polegar só e a tela com zoom vai virar uma usuária, em vez de só mais um abandono.