Um app que você fez com IA precisa ser acessível por lei?
Geradores de apps com IA constroem rápido mas pulam a acessibilidade por padrão. O que a lei exige de verdade de um projeto feito em um fim de semana, e como revisar sem refazer o app.
· Rampa
Você construiu um app em um fim de semana com uma ferramenta de IA, publicou e já tem alguns usuários. Depois vê um post sobre um app pequeno que recebeu uma notificação por acessibilidade, ou um cliente pergunta se o seu produto “está dentro da lei de acessibilidade”, e você não faz ideia. A resposta honesta é que pode se aplicar a você, e isso não tem nada a ver com como o app foi construído.
A lei não liga para quem escreveu o código
A ADA (Americans with Disabilities Act, a lei dos EUA de 1990 contra a discriminação por deficiência) não menciona sites, apps, IA nem editores de código. Desde 2017 os tribunais federais a aplicam a qualquer site ou app aberto ao público, não importa o tamanho da equipe nem a ferramenta usada para construir. Todo ano são abertos mais de 4.000 processos de acessibilidade web nos Estados Unidos, e produtos pequenos, de uma ou duas pessoas, são um alvo cada vez mais comum porque esses casos se resolvem rápido. Se o seu produto também vende para a União Europeia, a Lei Europeia de Acessibilidade (EAA), em vigor desde junho de 2025, pede a mesma coisa com outro nome. E se você vende para o Brasil, a Lei Brasileira de Inclusão (LBI) segue a mesma lógica, e aqui é o Ministério Público quem cobra.
Por que apps feitos com IA falham quase sempre do mesmo jeito
Os geradores de apps com IA e os assistentes de código são muito bons em construir rápido algo que parece pronto: uma landing page, um painel, um cadastro, um pagamento. Que funcione com um leitor de tela (o programa que lê a página em voz alta em vez de mostrá-la) é um pedido separado, e quase nenhum prompt inclui isso. As mesmas falhas se repetem sempre nos apps feitos assim:
- Botões que são só um ícone, sem nome que um leitor de tela consiga anunciar.
- Campos de formulário com um texto de exemplo em vez de um rótulo de verdade, que some assim que você começa a digitar.
- Cores escolhidas pela estética, não pelo contraste, então o cinza claro sobre branco não passa do mínimo.
- Componentes personalizados (um menu suspenso, uma janela pop-up, um interruptor) que só respondem ao mouse, porque o acesso pelo teclado nunca entrou no prompt.
- Ícones e imagens sem nenhuma descrição.
Nada disso é um erro do modelo de IA. “Que fique bonito” e “que seja acessível” são dois pedidos diferentes, e por padrão só um deles é feito.
Zero usuários não é o mesmo que zero risco
É fácil achar que um projeto pessoal sem clientes pagando não vale a pena processar. Os processos não dependem de quanto o produto fatura: dependem de estar aberto ao público e falhar com um leitor de tela ou só com o teclado. Uma landing page que coleta e-mails, uma lista de espera, uma ferramenta grátis com um formulário de cadastro: tudo isso é público e tudo isso conta. Um acordo típico para um negócio pequeno fica entre 5.000 e 25.000 dólares mais advogados, e isso é dinheiro real para quem constrói sozinho, mesmo antes do primeiro cliente pagante aparecer.
O que corrige de verdade
Corrigir não significa refazer o app. Cerca de metade do que uma varredura automática aponta (texto alternativo faltando, campos sem rótulo, botões sem nome, contraste baixo, idioma da página não declarado) se encontra do mesmo jeito rápido que o app foi construído: apontando uma ferramenta para as páginas que você publicou. A outra metade precisa de uma revisão manual curta: acesso pelo teclado nos componentes personalizados, se uma janela pop-up prende o foco ao abrir, se um leitor de tela anuncia direito quando algo muda na tela sem recarregar a página. São justamente as interações que uma interface gerada por IA costuma pular, porque quase nunca aparecem numa captura de tela.
Com a lista em mãos, a maior parte do trabalho é adicionar um atributo, um rótulo ou corrigir uma cor num componente que a IA já gerou para você. É rápido porque o app é pequeno, não porque isso seja opcional.
Um hábito para começar agora
Publique uma declaração de acessibilidade curta (uma página pública dizendo qual norma você segue e como falar com você) e guarde uma nota com data do que revisou e corrigiu. Isso não torna um processo impossível, mas muda o que uma notificação (uma carta, normalmente de um advogado, ameaçando ação legal se você não corrigir ou fizer um acordo) encontra quando chega: um projeto mantido ativamente, não um que nunca revisou nada. Para quem constrói sozinho e publica uma função nova toda semana, essa mesma lista é o jeito mais rápido de saber se a próxima tela gerada por IA repete a mesma falha.
Isto é informação geral sobre como essas leis funcionam hoje, não aconselhamento jurídico para o seu caso; se uma carta já chegou até você, o certo é falar com um advogado licenciado onde você opera.
Faça uma varredura grátis do que você publicou, sem cadastro: https://rampa.solutions/pt?de=blog-vibe-coded-app-ada-accessibility-lawsuit