Como Tornar o Seu Site Acessível: Um Guia Inicial de WCAG 2.2

Para tornar um site acessível, construa-o para que as pessoas o possam usar com um teclado, um leitor de ecrã, zoom ou um dispositivo de comutação, e não apenas com um rato: use elementos HTML reais para botões, ligações, cabeçalhos e etiquetas de formulário, dê às imagens um texto alternativo com significado, mantenha o contraste do texto elevado e torne o foco visível. A norma a atingir é a WCAG 2.2 Nível AA. Os verificadores automáticos apanham parte do problema; um teste de dez minutos com teclado e leitor de ecrã apanha grande parte do resto.

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

A acessibilidade diz respeito a pessoas: alguém cego que usa um leitor de ecrã, alguém com tremores que navega pelo teclado, alguém com baixa visão que aumenta o zoom até 200%, alguém a ler à luz forte do sol, alguém com um pulso partido temporariamente. Uma boa acessibilidade tende a tornar o site melhor para todos — estrutura mais clara, texto legível, formulários que explicam os erros.

A referência é as Diretrizes de Acessibilidade para Conteúdo Web (WCAG) do W3C. Em setembro de 2026, a versão atual é a WCAG 2.2 (publicada em outubro de 2023, atualizada em dezembro de 2024); a WCAG 3 é um rascunho inicial. A WCAG organiza-se em quatro princípios — o conteúdo tem de ser percetível, operável, compreensível e robusto — e tem três níveis de conformidade:

Nível	O que significa	Quem o visa
A	O mínimo; sem ele, algumas pessoas não conseguem usar o site de todo	Todos
AA	O alvo comum; abrange contraste, foco, redimensionamento e tratamento de erros	A maioria das organizações e muitas leis
AAA	O mais exigente; não é alcançável para todos os conteúdos	Serviços e públicos específicos

Leis em vários países fazem referência à WCAG — por exemplo, o Ato Europeu da Acessibilidade, que se aplica a muitos serviços digitais de consumo na UE desde junho de 2025. As regras que se aplicam a si dependem de onde opera e do que vende; em caso de dúvida, consulte um consultor. Este guia cobre o trabalho prático.

Opções: como lá chegar

Abordagem	Adequada para	Compromisso
Construir com acessibilidade desde o início	Sites e apps novos	Menor esforço no total; tem de ser dito logo à partida
Auditar e corrigir	Sites existentes	Encontra problemas reais; exige uma passagem focada por página
Auditoria profissional	Setores regulados, sites grandes, entidades públicas	Minuciosa e documentada; tem custo
Widget de sobreposição	Não recomendado	Não consegue corrigir o código subjacente

Para a maioria dos sites pequenos, as duas primeiras chegam: peça à IA que construa de forma acessível desde o início e depois audite antes do lançamento.

As correções que mais importam

Use os elementos HTML certos

A maior parte da acessibilidade vem de graça com um HTML correto. Um <button> é focável, funciona com Enter e Espaço, e é anunciado como botão. Um <div> com um gestor de clique não é nada disso. O código gerado por IA usa por vezes divs estilizados para tudo; peça elementos semânticos:

<button> para ações, <a href> para navegação
Um <h1> por página, depois <h2>, <h3> por ordem — os utilizadores de leitores de ecrã saltam entre cabeçalhos
Pontos de referência: <header>, <nav>, <main>, <footer>
<label> ligada a cada campo de formulário
O idioma da página em <html lang="pt-PT">

Use atributos ARIA apenas quando nenhum elemento nativo servir — por exemplo, para um conjunto de separadores ou uma caixa combinada personalizada. ARIA mal usado é pior do que nenhum.

Acesso por teclado e foco visível

Tudo o que pode fazer com o rato tem de funcionar só com o teclado (WCAG 2.1.1). Prima Tab ao longo da página: cada ligação, botão e campo deve ser alcançável por uma ordem lógica, e deve ver sempre onde está o foco (2.4.7 Foco Visível). A WCAG 2.2 acrescentou que o elemento em foco não pode ficar completamente escondido atrás de cabeçalhos fixos ou de banners de cookies (2.4.11, Nível AA).

Falhas comuns: menus que só abrem ao passar o rato, janelas modais que não prendem o foco ou não se fecham com Escape, e outline: none no CSS sem nada que o substitua.

Alternativas textuais

Cada imagem com significado precisa de texto alternativo que descreva o que mostra no contexto ("Chef a apresentar o menu de degustação", não "imagem1.jpg"). As imagens decorativas recebem um alt="" vazio para que os leitores de ecrã as ignorem. Os botões só com ícone precisam de um nome acessível ("Fechar", "Pesquisar"). Os vídeos precisam de legendas; o áudio precisa de uma transcrição.

Cor e contraste

A WCAG 2.2 AA exige um rácio de contraste de pelo menos 4,5:1 para texto normal e 3:1 para texto grande (1.4.3), e 3:1 para partes da interface como contornos de campos e ícones com significado (1.4.11). O texto de marcador cinzento claro e os botões pálidos são as falhas habituais. Além disso, nunca use apenas a cor para transmitir significado — um contorno vermelho num campo inválido precisa também de uma mensagem de erro.

Redimensionamento e reflow

O texto tem de continuar utilizável com zoom a 200% (1.4.4), e o conteúdo tem de funcionar com uma largura de 320 píxeis CSS sem rolagem lateral (1.4.10). Um layout responsivo resolve a maior parte disto.

Alvos, formulários e erros

Tamanho dos alvos: a WCAG 2.2 AA pede alvos de ponteiro de pelo menos 24 por 24 píxeis CSS, ou espaço suficiente à volta dos mais pequenos (2.5.8). Maior é mais simpático nos telemóveis.
Formulários: etiquetas visíveis (não apenas marcadores), instruções claras e mensagens de erro que digam o que está errado e como corrigir, junto ao campo.
Início de sessão: não obrigue as pessoas a resolver um puzzle ou a transcrever um código sem alternativa; permita os gestores de palavras-passe e colar texto (3.3.8 Autenticação Acessível).

Prompts que funcionam

Constrói este site para cumprir a WCAG 2.2 Nível AA: marcos semânticos de HTML, um h1 por página com cabeçalhos por ordem, elementos de botão e ligação reais, etiquetas em cada campo de formulário, estilos de foco visíveis, contraste de texto de pelo menos 4,5:1, texto alternativo nas imagens com significado e alt="" nas decorativas, e html lang definido.

Audita as páginas /signup e /checkout quanto à acessibilidade. Verifica a utilização só com teclado, a ordem de foco, o foco visível, as etiquetas, as mensagens de erro, o contraste e os nomes para leitores de ecrã nos botões só com ícone. Lista cada problema com o critério WCAG correspondente e depois corrige-os sem alterar o design visual mais do que o necessário.

O menu móvel não pode ser usado com teclado. Transforma-o num botão com aria-expanded, move o foco para dentro do menu quando abre, fecha-o com Escape e devolve o foco ao botão.

Passo a passo

Execute uma verificação automática. A secção de Acessibilidade do Lighthouse nas DevTools do Chrome, ou a extensão do navegador axe, em cada página principal. Corrija tudo o que assinalar.
Largue o rato. Use o Tab em cada página e complete todas as tarefas principais — registar-se, pesquisar, fazer checkout. Anote tudo o que não consegue alcançar, não vê o foco ou não consegue sair.
Aumente o zoom para 200% e reduza a janela até à largura de telemóvel. Nada deve ficar cortado nem exigir rolagem lateral.
Experimente um leitor de ecrã durante dez minutos: VoiceOver no Mac e no iPhone, TalkBack no Android ou NVDA no Windows (gratuito). Ouça cabeçalhos, ligações e campos de formulário. "Botão" sem nome, ou "ligação, clique aqui", indicam trabalho por fazer.
Verifique o contraste do texto, dos botões e dos campos com um verificador de contraste.
Corrija e volte a testar as mesmas tarefas.
Publique uma declaração de acessibilidade que indique a norma que pretende cumprir e como reportar problemas — e responda a esses relatos.

Erros comuns

Confiar num widget de sobreposição em vez de corrigir o código.
Remover os contornos de foco porque parecem desarrumados, sem nada que os substitua.
Texto de marcador como única etiqueta. Desaparece quando alguém começa a escrever e costuma ter contraste fraco.
Ligações "clique aqui" e "ler mais". Fora do contexto, os utilizadores de leitores de ecrã ouvem uma lista de ligações idênticas.
Texto alternativo cheio de palavras-chave. O texto alternativo é para as pessoas; descreva a imagem.
Testar uma única vez. Cada nova funcionalidade pode partir o acesso por teclado. Acrescente uma passagem com teclado ao seu teste antes do lançamento.

Lista de verificação de acessibilidade

Verificação automática (Lighthouse ou axe) sem erros nas páginas principais
Todas as tarefas podem ser concluídas só com o teclado
Foco sempre visível e nunca escondido atrás de elementos fixos
Cabeçalhos, marcos, botões e ligações semânticos; lang definido
Texto alternativo com significado; imagens decorativas com alt=""; legendas nos vídeos
Contraste do texto ≥ 4,5:1 (texto grande ≥ 3:1); partes da interface ≥ 3:1
Funciona com zoom de 200% e largura de 320 px
Cada campo de formulário tem uma etiqueta visível e mensagens de erro claras
Declaração de acessibilidade com uma forma de reportar problemas

Para os conceitos por trás disto, leia o que é a acessibilidade web. Design acessível e bom design sobrepõem-se muito; como criar uma app com bom aspeto com IA cobre o lado visual.

Acessibilidade no Mythex

O Mythex constrói com a norma que pedir, por isso coloque "WCAG 2.2 AA" no seu primeiro prompt e nos seguintes. Pode usar a moldura de tamanho de telemóvel da Pré-visualização para verificar ecrãs pequenos (Pré-visualização e Código), mas os testes de teclado, zoom e leitor de ecrã funcionam melhor no URL publicado ou numa pré-visualização aberta no seu próprio separador. Peça ao agente que audite uma página, corrija o que encontrar e depois teste as correções pessoalmente — uma passagem automática é um começo, não uma aprovação final.

Perguntas

Qual é a norma de acessibilidade atual para sites?

Em setembro de 2026, a norma atual do W3C é a WCAG 2.2, publicada pela primeira vez em outubro de 2023. A maioria das organizações e muitas leis visam o Nível AA. A WCAG 3 ainda é um rascunho inicial.

Um widget de sobreposição de acessibilidade pode tornar o meu site conforme?

Não confie nisso. As sobreposições acrescentam uma barra de ferramentas por cima da página, mas não conseguem corrigir etiquetas em falta, acesso por teclado avariado ou uma estrutura deficiente no código subjacente. Corrigir o próprio site é o que o torna utilizável.

As ferramentas de verificação automática encontram todos os problemas?

Não. Ferramentas como o Lighthouse e o axe detetam coisas como texto alternativo em falta, contraste fraco e campos sem etiqueta, mas muitos problemas — uma ordem de foco confusa, texto de ligação sem significado, texto alternativo presente mas errado — precisam de uma pessoa para verificar com o teclado e um leitor de ecrã.

Que rácio de contraste exige a WCAG?

A WCAG 2.2 de Nível AA exige pelo menos 4,5:1 para texto normal e 3:1 para texto grande, e 3:1 para componentes da interface, como contornos de campos e ícones que transmitam significado.