O que é a acessibilidade web? WCAG e design inclusivo explicados

A acessibilidade web significa criar sites e aplicações para que as pessoas com deficiência os possam usar — quer sejam cegas e usem um leitor de ecrã, não consigam usar um rato, tenham baixa visão ou daltonismo, sejam surdas ou tenham deficiências cognitivas ou de aprendizagem. Na prática, resume-se a coisas como textos alternativos para imagens, contraste de cor suficiente, formulários com rótulos adequados e tudo a funcionar só com o teclado. A norma internacional para isto é a WCAG, as Web Content Accessibility Guidelines do W3C.

A acessibilidade é muitas vezes abreviada para a11y — "a", depois 11 letras e "y" (a palavra inglesa tem 13 letras).

Porque é que a acessibilidade importa quando se cria com IA

Os construtores de IA são bons a produzir aplicações que parecem corretas. A acessibilidade diz respeito sobretudo ao que não se vê numa captura de ecrã: se um botão é mesmo um botão, se um campo tem um rótulo que um leitor de ecrã consegue anunciar, se é possível chegar ao menu com a tecla Tab.

Por isso, vale a pena perguntar:

• É fácil de falhar. Um menu pendente com estilo personalizado pode parecer perfeito e ser impossível de usar sem rato. Não vai reparar nisso se não testar.
• Sai mais barato acertar cedo. Pedir componentes acessíveis no primeiro pedido custa quase nada. Adaptar uma aplicação já terminada obriga a mexer em cada ecrã.
• Ajuda toda a gente. As legendas ajudam quem está em locais barulhentos, um bom contraste ajuda quem usa o telemóvel ao sol, e rótulos claros ajudam todos a preencher formulários mais depressa.
• Sobrepõe-se ao SEO. Títulos bem estruturados, ligações descritivas e textos alternativos ajudam também os motores de pesquisa a compreender as suas páginas — veja SEO para sites criados com IA.
• Pode ser obrigatório. Consoante o local onde opera e os clientes que serve, a acessibilidade pode ser uma obrigação legal.

Uma analogia do dia a dia

Pense na entrada de um edifício.

Os degraus funcionam bem para muita gente. Uma rampa serve os utilizadores de cadeira de rodas — e também os pais com carrinhos de bebé, os estafetas com carrinhos de transporte e os viajantes com malas. As portas automáticas, as placas claras, o braille nos botões do elevador e a boa iluminação eliminam, cada um, uma barreira para alguém.

A acessibilidade web é a mesma ideia para os espaços digitais: as rampas, placas e corrimãos da sua aplicação. E, tal como num edifício, é muito mais fácil incluir uma rampa nos planos do que acrescentá-la depois de a betão secar.

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. É retrocompatível: o conteúdo que cumpre a WCAG 2.2 também cumpre a 2.1 e a 2.0, e o W3C incentiva a utilização da versão mais recente. A WCAG 2.2 foi também aprovada como norma internacional, a ISO/IEC 40500:2025. Uma WCAG 3, muito diferente, está em desenvolvimento como rascunho inicial, e não como norma final.

A WCAG está organizada em quatro princípios, muitas vezes lembrados pela sigla POUR:

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

• Nível A — o mínimo. Falhar aqui bloqueia completamente algumas pessoas.
• Nível AA — o objetivo-padrão, e o nível a que apontam a maioria das leis e políticas.
• Nível AAA — o nível mais alto. Útil para mirar em alguns pontos, mas o W3C não recomenda exigi-lo em sites inteiros, porque alguns conteúdos não o conseguem cumprir.

A WCAG 2.2 acrescentou nove critérios de sucesso à 2.1, incluindo Tamanho do alvo (mínimo) no nível AA — os alvos clicáveis devem, em geral, ter pelo menos 24 por 24 pixels CSS, com exceções — e Autenticação acessível (mínimo), que limita os passos de início de sessão que dependem da memória ou de puzzles, como ter de reescrever uma palavra-passe sem permitir colá-la. Também retirou o antigo critério "Parsing", por estar obsoleto.

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

Eis um formulário de registo que uma IA poderia produzir, e o que uma verificação de acessibilidade encontra:

Nenhuma destas correções muda muito o aspeto do formulário. Todas mudam se algumas pessoas o conseguem usar.

Termos-chave

Ideias erradas comuns

• "A acessibilidade só importa para pessoas cegas." Abrange deficiências visuais, motoras, auditivas, da fala e cognitivas, além de situações temporárias, como um braço partido.
• "Os sites acessíveis são sem graça." A acessibilidade limita algumas coisas — contraste, estilos de foco, tamanho do texto —, mas os sites acessíveis e bonitos são a norma, não a exceção.
• "Um verificador automático dá 100, por isso acabámos." As ferramentas automáticas detetam apenas alguns problemas. Saber se o texto alternativo é mesmo útil, ou se um fluxo faz sentido com um leitor de ecrã, exige uma pessoa a verificar.
• "Um widget de overlay torna-nos conformes." Barras de ferramentas acopladas por cima não corrigem rótulos em falta nem um acesso por teclado avariado no seu código. Corrija a origem.
• "Não temos utilizadores com deficiência." Pode simplesmente não saber. Muitas deficiências não são visíveis, e quem encontra uma barreira costuma simplesmente sair.

O que pedir ao seu construtor de IA

• "Construa isto para cumprir a WCAG 2.2 nível AA."
• "Use HTML semântico: botões e ligações reais, títulos por ordem e rótulos para cada campo de formulário."
• "Garanta que cada elemento interativo funciona só com o teclado e tem 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."
• "Acrescente textos alternativos com significado nas imagens informativas e alt vazio nas decorativas."
• "Mostre os erros de formulário em texto, ligados ao campo, e não apenas com cor."
• "Respeite a definição de movimento reduzido do utilizador nas animações."
• "Execute uma verificação automática de acessibilidade e liste o que ela não consegue testar, para eu verificar isso manualmente."

Depois, teste você mesmo: afaste o rato e tente concluir o seu fluxo principal usando apenas Tab, Shift+Tab, Enter e Espaço. Experimente o leitor de ecrã integrado do telemóvel na página principal. Aumente o navegador para 200% e veja se alguma coisa se quebra.

Acessibilidade no Mythex

O Mythex não inclui um verificador de acessibilidade dedicado, por isso trate a acessibilidade como parte dos seus pedidos e dos seus testes. Peça WCAG 2.2 AA desde o primeiro pedido, verifique o resultado na Pré-visualização com o teclado, e use /test para que o agente percorra os seus fluxos principais antes de publicar — veja Testes da aplicação. A receita de SEO também pede títulos semânticos e textos alternativos com significado, o que serve os dois objetivos.

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

Perguntas