O que é acessibilidade web? WCAG e design inclusivo explicados

Acessibilidade web significa construir sites e apps para que pessoas com deficiência consigam usá-los — seja porque são cegas e usam leitor de tela, não conseguem usar o mouse, têm baixa visão ou daltonismo, são surdas ou têm deficiências cognitivas ou de aprendizagem. Na prática, isso se resume a coisas como textos alternativos para imagens, contraste de cor suficiente, formulários com rótulos adequados e tudo funcionando só com o teclado. O padrão internacional para isso é a WCAG, as Web Content Accessibility Guidelines do W3C.

Acessibilidade costuma ser abreviada como a11y — “a”, depois 11 letras, depois “y”.

Por que a acessibilidade importa ao criar com IA

Criadores com IA são bons em produzir apps que parecem corretos. A acessibilidade é, principalmente, sobre o que você não vê em uma captura de tela: se um botão é realmente um botão, se um campo tem um rótulo que um leitor de tela consegue anunciar, se você consegue chegar ao menu com a tecla Tab.

Por isso vale perguntar:

• É fácil deixar passar. Um menu suspenso com estilo personalizado pode parecer perfeito e ser impossível de usar sem mouse. Você não percebe a menos que teste.
• É mais barato acertar cedo. Pedir componentes acessíveis já no primeiro prompt custa quase nada. Adaptar um app pronto significa mexer em cada tela.
• Ajuda a todos. Legendas ajudam quem está em lugares barulhentos, bom contraste ajuda quem usa o celular sob sol forte, e rótulos claros ajudam todo mundo a preencher formulários mais rápido.
• Tem relação com SEO. Títulos bem estruturados, links descritivos e textos alternativos ajudam os buscadores a entender suas páginas também — veja SEO para sites criados com IA.
• Pode ser obrigatório. Dependendo de onde você atua e de quem atende, a acessibilidade pode ser uma obrigação legal.

Uma analogia do dia a dia

Pense na entrada de um prédio.

Escadas funcionam bem para muitas pessoas. Uma rampa atende cadeirantes — e também quem empurra um carrinho de bebê, entregadores com carrinhos de carga e viajantes com malas. Portas automáticas, placas claras, braille nos botões do elevador e boa iluminação removem uma barreira para alguém.

A acessibilidade web é a mesma ideia para espaços digitais: as rampas, placas e corrimãos do seu app. E, assim como em um prédio, é muito mais fácil incluir uma rampa no projeto do que construí-la depois que o concreto secou.

A WCAG em resumo

A WCAG é publicada pela Web Accessibility Initiative do W3C. A versão atual é a WCAG 2.2, publicada pela primeira vez em outubro de 2023. Ela é retrocompatível: conteúdo que atende à WCAG 2.2 também atende à 2.1 e à 2.0, e o W3C incentiva o uso da versão mais recente. A WCAG 2.2 também foi aprovada como padrão internacional, ISO/IEC 40500:2025. Uma WCAG 3 bem diferente está em desenvolvimento como rascunho inicial, não como padrão finalizado.

A WCAG é organizada em quatro princípios, frequentemente lembrados pela sigla POUR:

Cada diretriz tem critérios de sucesso testáveis em três níveis:

• Nível A — o mínimo. Falhar nesses bloqueia completamente algumas pessoas.
• Nível AA — a meta padrão, e o nível ao qual a maioria das leis e políticas se refere.
• Nível AAA — o nível mais alto. Vale mirar nele em alguns pontos, mas o W3C não recomenda exigi-lo para sites inteiros, porque parte do conteúdo não consegue atendê-lo.

A WCAG 2.2 acrescentou nove critérios de sucesso à 2.1, incluindo Tamanho Mínimo do Alvo no nível AA — alvos clicáveis devem geralmente ter pelo menos 24 por 24 pixels CSS, com exceções — e Autenticação Acessível (Mínimo), que limita etapas de login que dependem de memória ou quebra-cabeças, como ter de redigitar uma senha sem permissão para colá-la. Também removeu o antigo critério “Parsing”, por ser obsoleto.

Um exemplo prático: um formulário de cadastro

Aqui está um formulário de cadastro que uma IA poderia produzir, e o que uma verificação de acessibilidade encontra:

Nenhuma dessas correções muda muito a aparência do formulário. Todas elas mudam se algumas pessoas conseguem ou não usá-lo.

Termos-chave

Equívocos comuns

• “Acessibilidade só importa para usuários cegos.” Ela cobre deficiências visuais, motoras, auditivas, de fala e cognitivas, além de situações temporárias, como um braço quebrado.
• “Sites acessíveis são sem graça.” A acessibilidade limita algumas coisas — contraste, estilos de foco, tamanho do texto —, mas sites acessíveis e bonitos são a regra, não a exceção.
• “Um verificador automático deu 100, então terminamos.” Ferramentas automáticas pegam apenas parte dos problemas. Saber se o texto alternativo é de fato significativo, ou se um fluxo faz sentido com um leitor de tela, exige uma pessoa para verificar.
• “Um widget de overlay vai nos deixar em conformidade.” Barras de ferramentas colocadas por cima não corrigem rótulos ausentes ou acesso por teclado quebrado no seu código. Corrija a origem.
• “Não temos usuários com deficiência.” Você pode simplesmente não saber. Muitas deficiências não são visíveis, e quem encontra uma barreira geralmente só vai embora.

O que pedir ao seu criador com IA

• “Construa isto para atender à WCAG 2.2 no nível AA.”
• “Use HTML semântico: botões e links de verdade, títulos em ordem e rótulos para cada campo de formulário.”
• “Garanta que todo elemento interativo funcione só com o teclado e tenha um estilo de foco visível.”
• “Verifique o contraste de todas as cores de texto e ícones — 4,5:1 para texto normal, 3:1 para texto grande e ícones.”
• “Adicione texto alternativo significativo às imagens informativas e alt vazio às decorativas.”
• “Mostre os erros de formulário como texto, ligados ao campo, e não apenas com cor.”
• “Respeite a configuração de movimento reduzido do usuário nas animações.”
• “Rode uma verificação automática de acessibilidade e liste o que ela não consegue testar, para que eu teste isso manualmente.”

Depois, teste você mesmo: afaste o mouse e tente concluir seu fluxo principal usando apenas Tab, Shift+Tab, Enter e Espaço. Teste o leitor de tela embutido do seu celular na página principal. Aumente o zoom do navegador para 200% e veja se algo quebra.

Acessibilidade no Mythex

O Mythex não inclui um verificador de acessibilidade dedicado, então trate a acessibilidade como parte dos seus prompts e dos seus testes. Peça WCAG 2.2 AA já no primeiro prompt, confira o resultado no Preview usando o teclado e use /test para que o agente percorra seus fluxos principais antes de publicar — veja Testes de app. A receita de SEO também pede títulos semânticos e textos alternativos significativos, que atendem aos dois objetivos.

Para uma lista de verificação prática, veja como tornar seu site acessível. Para design, leia como criar um app bonito com IA, e antes do lançamento, como testar seu app antes do lançamento. A visão geral da WCAG do próprio W3C é a fonte autorizada.

Perguntas