Sites feitos com IA são acessíveis? Guia prático 2026

Em parte. Construtores com IA geram HTML semântico, e isso já cobre uma fatia da acessibilidade: títulos, links e campos de formulário nativos. O que raramente sai certo sem pedido explícito é contraste, ordem de foco no teclado e rótulo em componentes personalizados. Um site gerado é um ponto de partida, não uma auditoria.

Essa resposta serve melhor que um sim ou um não, porque acessibilidade não é um interruptor. É um conjunto de propriedades concretas que uma página tem ou não tem, e o código gerado costuma acertar umas e falhar outras seguindo um padrão bastante previsível.

O que "acessível" significa na prática?

Significa que uma pessoa consegue usar sua página com leitor de tela, com teclado no lugar do mouse, com zoom em 200 por cento, com baixa visão ou com uma limitação motora que dificulta apontar com precisão. A referência de trabalho são as WCAG, organizadas em níveis A, AA e AAA.

Para a maioria dos projetos, o alvo prático é o nível AA. É nele que moram os requisitos que as pessoas realmente percebem: contraste suficiente no texto, indicador de foco visível, rótulo em cada campo, alternativa textual nas imagens que carregam significado e uma página operável sem mouse.

Vale separar duas coisas que se misturam sempre. Uma é se a sua página fica utilizável para visitantes com deficiência, que é uma pergunta de produto. Outra é se ela cumpre uma obrigação legal, que depende de onde você opera e de que tipo de organização você é. Um construtor ajuda com a primeira e não responde a segunda.

O que os construtores com IA costumam acertar?

Mais do que os céticos esperam, porque os acertos vêm do próprio HTML e não de alguma esperteza do modelo. Páginas geradas são montadas com elementos padrão, e elementos padrão já chegam com comportamento embutido.

• Estrutura do documento. Os títulos costumam aninhar em ordem e as seções são seções de verdade, então um leitor de tela consegue montar um índice da página. Só isso já a torna navegável de um jeito que um monte de divs estilizadas não é.
• Controles nativos. Um formulário gerado normalmente usa <input>, <button> e <select> reais. Eles são operáveis pelo teclado, focáveis e anunciados corretamente sem trabalho extra.
• Texto dos links. Os modelos tendem a escrever rótulos descritivos em vez de "clique aqui", em parte porque foram treinados com prosa que se lê bem.
• Layout responsivo. Um layout fluido que sobrevive a uma tela estreita costuma sobreviver também ao zoom do navegador, que é um requisito real de baixa visão e não só um assunto de celular.

Nada disso é garantido em uma construção específica. É a linha de base: o que sai bem por padrão porque o HTML embaixo já estava correto.

Onde o código gerado erra com mais frequência?

Os defeitos se concentram em quatro lugares, e todos vêm de uma decisão de design, não de marcação desleixada.

Contraste. Você pede uma "paleta suave e discreta" e recebe exatamente isso: texto cinza claro sobre branco. Fica calmo no seu monitor e some para quem tem sensibilidade ao contraste reduzida. O nível AA pede uma relação mínima de 4,5:1 em texto de corpo, e nada em um prompt sobre clima visual diz ao modelo para conferir esse número.

Foco visível. Muitos layouts modernos removem o anel de foco do navegador porque ele briga com a estética. Se nada entra no lugar, quem navega pelo teclado não enxerga onde está, e a página deixa de ser usável sem mouse.

Componentes personalizados. Acordeões, abas, janelas modais e carrosséis feitos com divs e manipuladores de clique parecem certos e não anunciam nada. Aqui são necessários papéis ARIA, tratamento de teclado e retenção de foco, e é aqui que o código gerado tem mais chance de parar no meio do caminho.

Imagens e ícones. Ícones decorativos chegam com frequência sem atributo alt em vez de com um vazio, e imagens com significado recebem texto alternativo genérico porque o modelo não sabe qual imagem você vai colocar no fim. Um botão só de ícone sem nome acessível é o defeito mais comum que merece revisão.

Como pedir acessibilidade no prompt?

Com especificidade. "Deixe acessível" é abstrato demais para mudar muita coisa no resultado; nomear as propriedades muda bastante, porque cada frase vira uma decisão concreta que o gerador precisa tomar.

Um prompt que funciona se parece mais com isto: "Landing page para uma clínica de fisioterapia. Use texto de corpo com contraste de 4,5:1 ou melhor sobre o fundo, mantenha um contorno de foco visível em todo elemento interativo, associe cada campo a um <label> real e dê nome acessível a todo botão que só tenha ícone."

São quatro requisitos verificáveis, não uma sensação. No Zugo as mesmas frases funcionam como edição sobre um projeto existente, que costuma ser a ordem mais barata: primeiro você chega no layout que quer e depois gasta uma edição na passada de acessibilidade, em vez de brigar com as duas coisas ao mesmo tempo. Cada edição custa 3 créditos.

Como revisar um site gerado em dez minutos?

Não é preciso um especialista para pegar os defeitos comuns. Cinco verificações cobrem a maior parte do que quebra, e todas são feitas em um navegador que você já tem.

Duas verificações valem a pena quando o básico já passa: percorrer a página com o leitor de tela do próprio sistema operacional e conferir se toda janela modal devolve o foco ao elemento que a abriu.

Quanto custa a passada de acessibilidade?

Pouco, e é justamente esse o argumento para fazer a revisão em vez de adiar. A correção é uma edição, e uma edição é uma frase, não um chamado aberto com alguém.

O plano gratuito inclui 5 créditos, que é menos que uma construção completa de 6, então ele serve para conhecer a ferramenta mais do que para terminar um projeto. O Pro custa $25 por mês com 200 créditos, o que dá cerca de 66 edições ou 33 construções rápidas. O Business custa $99 por mês com 800 créditos.

Uma construção simples leva por volta de um minuto. Uma plataforma multipágina leva alguns minutos. Em qualquer um dos dois casos, a passada de acessibilidade cabe na mesma sessão de trabalho em que você olhou o resultado pela primeira vez.

O que um construtor com IA não faz por você?

Três coisas, e vale dizer com clareza, porque a distância entre "o código gerado parece bom" e "passou por auditoria" é onde as pessoas tomam susto.

Ele não julga intenção. Se uma imagem é decorativa ou significativa é uma pergunta sobre o seu conteúdo, não sobre a sua marcação. O modelo chuta; você sabe.

Ele não testa com tecnologia assistiva real. Verificações automáticas pegam rótulo ausente e contraste baixo. Não pegam uma hierarquia de títulos tecnicamente válida e semanticamente sem sentido, nem um percurso operável e exaustivo.

Ele não faz determinação jurídica. As obrigações variam por jurisdição e por tipo de organização. Se o seu site cai sob uma norma específica, trate o que foi gerado como rascunho para um especialista revisar.

Os limites do Zugo entram na mesma lista. Antes da entrega, cada construção é aberta em uma sandbox, e uma falha aparece como falha em vez de ser entregue como projeto pronto. Essa checagem confirma que a página carregou e desenhou. Ela não é uma auditoria de acessibilidade e não pretende ser. Vale lembrar também que o Zugo não substitui um time de desenvolvimento em um produto complexo: regras de negócio muito específicas se afinam com edições sucessivas, não com um prompt só.

Por onde começar?

Comece testando algo que você já publicou. Percorra com Tab, meça o contraste do texto de corpo e conte quantas das cinco verificações a página passa. A maioria dos sites falha em duas ou três, tenha sido escrita por uma pessoa ou por um modelo.

Depois corrija onde sai mais barato, que é dentro de um construtor, onde uma mudança é uma frase. O ciclo que funciona é construir, revisar, corrigir. Se você quiser o contexto mais amplo, como criar um site com IA cobre a descrição e o caminho até publicar, como criar um aplicativo com IA detalha o ciclo de edições feitas conversando e criador de apps com IA e domínio próprio explica o que muda quando o projeto sai do link de teste.

Dá para testar tudo isso em zugo.dev, publicar em um link .zugo.run e repetir as cinco verificações na página no ar antes de conectar um domínio. Entre os 25 modelos prontos há vários pontos de partida que já vêm com estrutura de página razoável, o que reduz o tamanho da lista de correções antes mesmo da primeira edição.