WCAG no WordPress: o guia completo de acessibilidade para sites

A WCAG é o conjunto de diretrizes que define o que torna um site utilizável por pessoas com deficiência. Ela é a referência técnica citada em leis, contratos e editais mundo afora , e, para quem constrói sites em WordPress, é o documento que separa um site que parece funcionar de um site que funciona para todo mundo.

No Brasil são 14,4 milhões de pessoas com deficiência, 7,3% da população de 2 anos ou mais, segundo o Censo 2022 do IBGE. Este guia cobre a WCAG inteira do ponto de vista de quem põe a mão no WordPress: o que ela exige, o que a lei brasileira determina, como auditar um site, como corrigir cada categoria de problema e como transformar isso em serviço vendável.

O que você vai encontrar aqui

• O que é a WCAG e quem a publica
• Os quatro princípios: perceptível, operável, compreensível, robusto
• Níveis A, AA e AAA , qual mirar
• O que a WCAG 2.2 trouxe de novo
• A WCAG é obrigatória no Brasil?
• Onde o WordPress ajuda e onde ele atrapalha
• Os oito pontos onde sites WordPress mais falham
• Como auditar um site em seis etapas
• Corrigindo: cores, teclado, imagens, formulários, temas e loja
• O que depende de quem publica todo dia
• Fluxo editorial de acessibilidade
• Por que plugins de correção automática não bastam
• Acessibilidade como diferencial comercial
• Plano de 30 minutos para começar
• Matriz de auditoria e priorização
• Protocolo de testes manuais
• Padrões técnicos prontos para adaptar
• WooCommerce: teste e correção por etapa
• Entregáveis, evidências e declaração
• Perguntas frequentes
• Fontes para consulta
• O que vem pela frente

O que é a WCAG e quem a publica

WCAG é a sigla de Web Content Accessibility Guidelines, publicada pelo W3C , o consórcio internacional que mantém os padrões da web. A versão vigente é a WCAG 2.2, recomendação oficial desde outubro de 2023.

Ela não é lei em si. É uma especificação técnica que as leis referenciam , e é justamente essa neutralidade que a tornou o denominador comum: quando um contrato exige “site acessível”, a forma de tornar isso mensurável é escrever “conformidade com a WCAG 2.2 nível AA”.

Vale desfazer três confusões antes de seguir. Acessibilidade não é só para quem não enxerga: abrange deficiência visual, auditiva, motora, cognitiva e neurológica, além de limitações temporárias , um braço imobilizado, um ambiente barulhento, uma tela sob sol forte. Acessibilidade não é responsividade: um site pode se adaptar perfeitamente ao celular e ser inutilizável com leitor de tela. E acessibilidade não é feiura: nada nas diretrizes exige abrir mão de design, apenas que as escolhas visuais respeitem limites de contraste, tamanho e clareza.

Os quatro princípios da WCAG

A WCAG intimida de longe: dezenas de critérios numerados, cada um com nível e condições. Mas todos se organizam sob quatro princípios, e dominar os quatro resolve a maior parte das dúvidas do dia a dia.

Perceptível. A informação precisa chegar por mais de um canal sensorial. Se está numa imagem, precisa existir em texto. Se está num vídeo, precisa existir em legenda. Se está indicada por cor , o campo vermelho é o que está errado ,, precisa estar indicada também por outro meio, porque nem todo mundo distingue aquela cor.

Operável. Tudo o que funciona com mouse precisa funcionar com teclado: menu, carrossel, popup, filtro, formulário. É o princípio mais fácil de testar e o mais frequentemente quebrado por componentes que só respondem ao passar do cursor.

Compreensível. Conteúdo e funcionamento precisam ser previsíveis. Rótulos que descrevem o campo, mensagens de erro que explicam como corrigir, navegação que se comporta igual em todas as páginas, idioma declarado no código.

Robusto. O código precisa ser interpretável por tecnologias assistivas , leitores de tela, comando por voz, teclados alternativos. Na prática: HTML semântico, usando cada elemento para a função que ele tem, em vez de div estilizada imitando botão.

Níveis A, AA e AAA: qual mirar

Cada critério tem um nível de conformidade, e essa escolha define o escopo de qualquer projeto.

O nível A é o mínimo: sem ele existem barreiras que impedem completamente o uso. O nível AA é o patamar adotado como padrão de mercado , é ele que aparece em contratos, editais e referências normativas. O nível AAA é o mais exigente, e o próprio W3C não recomenda adotá-lo como meta para um site inteiro, porque alguns critérios são inviáveis para certos tipos de conteúdo.

Para projeto de cliente a resposta é quase sempre a mesma: mire AA. É o nível defensável, alcançável e que cobre as barreiras que realmente impedem o uso. Escrever “conformidade WCAG 2.2 nível AA” no escopo é mais honesto e mais mensurável do que prometer um site genericamente “acessível”.

O que a WCAG 2.2 trouxe de novo

Boa parte do material em português ainda descreve a versão 2.0 ou 2.1. A 2.2 acrescentou nove critérios e removeu um, e vários deles miram exatamente problemas comuns em sites feitos com construtor visual.

O 2.4.11 Foco não obscurecido trata do cabeçalho fixo que cobre o campo recém-focado , o menu acompanha a rolagem e esconde justamente onde a pessoa está. O 2.5.7 Movimentos de arrastar exige alternativa para qualquer coisa que só funcione arrastando, como sliders de preço e carrosséis. O 2.5.8 Tamanho do alvo estabelece 24 por 24 pixels como mínimo para elementos clicáveis, o que atinge ícones de redes sociais e menus mobile apertados.

Do lado da compreensão, o 3.2.6 Ajuda consistente pede que o canal de suporte apareça sempre no mesmo lugar; o 3.3.7 Entrada redundante proíbe pedir duas vezes a mesma informação no mesmo fluxo, algo corriqueiro em checkout; e o 3.3.8 Autenticação acessível inviabiliza o CAPTCHA que exige resolver charada visual como única forma de login. O critério 4.1.1, sobre análise sintática do HTML, foi removido por ter se tornado obsoleto com os navegadores modernos.

A WCAG é obrigatória no Brasil?

Quatro coisas diferentes costumam ser misturadas nessa conversa, e separá-las ajuda a responder ao cliente com precisão.

A lei. A Lei Brasileira de Inclusão (Lei 13.146/2015) estabelece a acessibilidade de sites como obrigação, com destaque para os de empresas com sede ou representação comercial no país e para portais públicos. O Decreto 5.296/2004 já tratava do tema para o setor público, com prazos vencidos há muito tempo.

A norma técnica. A ABNT NBR 17225:2025 estabelece requisitos para facilitar o acesso a ambientes virtuais. Ela é uma referência técnica nacional importante, mas a obrigação aplicável a cada organização deve ser analisada conforme seu setor, contratos e serviços oferecidos.

A recomendação de governo. O eMAG segue como referência para portais da administração pública federal.

A exigência de mercado externo. Se o cliente vende para a Europa, o European Accessibility Act passou a valer em junho de 2025 e alcança sites e aplicativos de comércio eletrônico, com a norma EN 301 549 como referência técnica.

Na prática, WCAG 2.2 nível AA é um alvo técnico forte para projetos novos e correções. Isso não substitui a análise de contratos, editais, regras setoriais ou requisitos de cada mercado. Para o setor público federal, o eMAG continua sendo referência própria; para vendas na Europa, o escopo do European Accessibility Act e a norma aplicável precisam ser verificados no caso concreto.

Onde o WordPress ajuda e onde ele atrapalha

O núcleo do WordPress tem equipe dedicada a acessibilidade e trata o assunto como requisito. O editor de blocos gera HTML semântico por padrão: um bloco de título vira <h2> de verdade, uma lista vira <ul>, um botão vira elemento operável por teclado. O campo de texto alternativo está na biblioteca de mídia desde sempre, e temas do repositório oficial podem receber a etiqueta accessibility-ready após revisão.

Três camadas colocadas por cima costumam desmontar essa base. O tema, quando remove o indicador de foco do navegador por questão estética. O construtor visual , Elementor, Bricks, Divi ,, que dá liberdade total de layout, inclusive a de escolher um título pelo tamanho da fonte em vez da hierarquia. E o conteúdo publicado no dia a dia: nenhum tema impede que alguém suba dez imagens sem alt ou escreva “clique aqui” em todos os links.

Os oito pontos onde sites WordPress mais falham

Depois de revisar sites suficientes, os mesmos problemas reaparecem com regularidade quase monótona. Esta lista funciona como triagem rápida antes de qualquer auditoria formal:

• Foco invisível. O contorno do navegador foi removido no CSS e nada entrou no lugar. Viola o critério 2.4.7.
• Contraste insuficiente. Texto cinza-claro sobre fundo branco, herdado da paleta escolhida no início do projeto.
• Texto alternativo ausente ou automático. Campo vazio em imagem informativa, ou preenchido com o nome do arquivo.
• Hierarquia de títulos usada como estilo. H4 escolhido porque a fonte tinha o tamanho desejado, quebrando o sumário da página.
• Menu que só abre no hover. Submenus inteiros inalcançáveis para quem navega por teclado.
• Formulário sem rótulo. O placeholder cumprindo papel que não é dele e sumindo quando a digitação começa.
• Popup que prende o foco. Modal sem tecla Esc e sem devolver o foco ao ponto de origem.
• Cabeçalho fixo cobrindo o foco. O menu que acompanha a rolagem esconde o campo recém-focado, problema que a WCAG 2.2 passou a endereçar no critério 2.4.11.

Observe que sete dos oito se resolvem no tema ou no modelo , uma única vez, valendo para o site inteiro. Só o terceiro depende de rotina de quem publica. É por isso que a ordem importa tanto: auditar antes de sair corrigindo muda o custo do trabalho inteiro, porque revela quais problemas são um só, repetido em centenas de páginas.

Como auditar um site em seis etapas

Antes de corrigir, é preciso saber o que está quebrado , e essa etapa costuma ser pulada. Auditar um site institucional de porte médio leva de duas a quatro horas.

1. Escolha a amostra. Auditar “o site inteiro” é armadilha: um site com 300 posts não tem 300 problemas, tem um punhado repetido 300 vezes, vindo do tema e dos modelos. Selecione de seis a dez URLs por tipo de página: home, página institucional, post, listagem do blog, página com formulário, busca com resultados, erro 404 e, havendo loja, listagem, produto e carrinho.

2. Rode a varredura automática. As três ferramentas gratuitas mais usadas se complementam: axe DevTools e WAVE, extensões que apontam o problema sobre o elemento na página, e o Lighthouse, embutido no Chrome, útil para acompanhar evolução ao longo do tempo.

3. Teste com o teclado. A etapa de melhor retorno, e gratuita: largue o mouse e percorra cada página com Tab. Quatro perguntas guiam o teste , você enxerga sempre onde está? A ordem faz sentido? Dá para chegar a tudo? Dá para sair de modais com Esc?

4. Ouça a página. No Windows o NVDA é gratuito; no Mac o VoiceOver já vem instalado. Você não precisa ser usuário avançado, só ouvir o que ele anuncia. Verifique a lista de títulos (deve funcionar como sumário), a lista de links (quantos “clique aqui”?) e os textos alternativos lidos em sequência.

5. Aplique zoom e reflow. Com 200% de zoom, nada pode ser cortado ou sobreposto. Com a janela em 320 pixels de largura, o conteúdo precisa se reorganizar em uma coluna sem rolagem horizontal.

6. Transforme a lista em plano. Organize cada item por onde acontece (tema, modelo específico ou conteúdo), quantas telas afeta e quanto custa corrigir. Uma correção no tema que resolve um problema em todas as páginas vale mais que dez ajustes pontuais , mesmo que as ferramentas tenham reportado os dez com a mesma severidade.

Corrigindo os pontos críticos

Contraste, cores e tipografia

Os números que importam: 4,5:1 para texto normal, 3:1 para texto grande e para elementos não textuais como bordas de campo e ícones informativos. O erro mais comum é texto cinza-claro sobre branco, quase sempre herdado da paleta definida no início do projeto.

Corrija na origem, não página por página: monte a paleta já validada em AA e registre-a nas cores globais do Elementor ou no theme.json do tema de blocos. Assim ninguém consegue escolher depois uma combinação reprovada. Verifique também o critério 1.4.1: cor nunca pode ser a única forma de transmitir informação.

Teclado e foco visível

O indicador de foco removido no CSS é o problema mais frequente em temas comerciais. A correção é devolver um anel visível com :focus-visible, que aparece para quem navega por teclado sem poluir a interface de quem usa mouse.

Some a isso um skip link como primeiro elemento focável, mega-menus que abram também por teclado e não apenas no hover, e modais que prendam o foco enquanto abertos, respondam ao Esc e devolvam o foco ao ponto de origem ao fechar.

Imagens e texto alternativo

A dúvida real é sempre “o que eu escrevo aqui?”. A regra: descreva o que a imagem comunica naquela página, não o que ela mostra. A mesma foto pode pedir alts diferentes em contextos diferentes. Se a imagem for puramente decorativa, alt="" é a resposta correta , o campo vazio faz o leitor de tela pular, o que é exatamente o desejado.

Atenção aos casos que o WordPress esconde: imagem de fundo aplicada pelo construtor não tem alt e some para quem usa leitor de tela; ícones SVG inline precisam de aria-hidden quando decorativos; e imagem dentro de link deve descrever o destino, não a figura.

Formulários

O placeholder não é rótulo e nunca foi: ele desaparece quando a pessoa começa a digitar, deixando o campo sem identificação. Todo campo precisa de <label> associado.

Mensagens de erro devem explicar como corrigir, não apenas sinalizar que há erro. E o resultado do envio , sucesso ou falha , precisa ser anunciado por região aria-live, senão quem usa leitor de tela não sabe que algo aconteceu. Contact Form 7, WPForms e Elementor Forms geram HTML diferente entre si; vale inspecionar o que o seu realmente produz.

Temas e construtores

A etiqueta accessibility-ready do repositório oficial garante que o tema passou por revisão , mas não impede que ele vire um site inacessível depois, nas mãos do construtor e do conteúdo. Antes de comprar um tema premium para um cliente, faça o teste de teclado na demonstração: dez minutos revelam mais do que a página de vendas.

WooCommerce

A loja é onde há mais dinheiro em jogo. Percorra a jornada inteira: variações de produto não podem depender só de cor para indicar a opção escolhida; o “adicionar ao carrinho” via AJAX precisa anunciar o que aconteceu; filtros de faixa de preço que só funcionam arrastando violam o critério 2.5.7; e o checkout precisa de rótulos, autocomplete correto e possibilidade de revisar antes de confirmar. O teste definitivo é fazer uma compra completa usando apenas o teclado.

Plano de 30 minutos para começar

Antes de abrir uma planilha ou instalar qualquer extensão, defina um recorte. O objetivo desta primeira rodada não é declarar conformidade. É descobrir as barreiras mais caras para usuários e as correções que se repetem pelo site.

1. Defina o alvo: registre WCAG 2.2 nível AA como objetivo técnico do projeto.
2. Escolha três fluxos: encontrar conteúdo, entrar em contato e, se houver loja, comprar um produto.
3. Faça um percurso de teclado: use Tab, Shift + Tab, Enter, Espaço e Esc. Anote cada ponto em que o foco some, a ordem quebra ou uma ação fica impossível.
4. Rode uma ferramenta automática: use-a para levantar hipóteses, não como certificado. Agrupe resultados iguais pelo componente que os criou.
5. Corrija um padrão global: foco, contraste, rótulos ou cabeçalho fixo costumam resolver muitas URLs de uma vez.
6. Repita o fluxo: a correção só está concluída quando o usuário consegue finalizar a tarefa sem a barreira.

Matriz de auditoria e priorização

Uma lista de erros sem contexto não vira trabalho. Para cada achado, registre a página, a etapa do fluxo, o critério relacionado, a evidência, quem será afetado e como será validada a correção. Esta matriz evita que dez ocorrências do mesmo botão pareçam dez problemas diferentes.

Achado	Critério	Onde corrigir	Prioridade	Validação
Foco não aparece	2.4.7	CSS global do tema	Alta	Todo elemento focável mostra foco visível
Campo sem rótulo	3.3.2 e 1.3.1	Formulário ou plugin	Alta	Leitor de tela anuncia nome e instrução
Contraste insuficiente	1.4.3 ou 1.4.11	Tokens de cor	Média ou alta	Combinação aprovada e legível no uso real
Imagem informativa sem alternativa	1.1.1	Conteúdo ou modelo	Média	Alternativa transmite a finalidade da imagem
Filtro só por arrastar	2.5.7	Componente da loja	Alta	Há controle alternativo por teclado

Prioridade alta significa que a pessoa não consegue concluir uma tarefa essencial, perde informação ou fica presa no fluxo. Prioridade média representa dificuldade relevante com alternativa disponível. Prioridade baixa deve ser corrigida, mas não pode atrasar uma barreira que bloqueia login, contato ou compra.

Protocolo de testes manuais

A auditoria confiável combina automação e avaliação humana. Ferramentas encontram padrões no código, mas não sabem se um texto alternativo descreve a finalidade correta, se um aviso é compreensível ou se a sequência de um checkout faz sentido.

Teclado

• Comece no topo da página, sem mouse, e percorra cada controle com Tab.
• Confirme que o foco é visível, não fica coberto pelo cabeçalho e segue uma ordem coerente.
• Abra menus, acordeões, popups, filtros e carrosséis com teclado.
• Use Esc para fechar diálogos e confirme que o foco volta ao botão que os abriu.
• Complete o formulário e, na loja, finalize uma compra de teste.

Leitor de tela, zoom e mobile

No Windows, use NVDA. No macOS e iPhone, use VoiceOver. Navegue pela lista de títulos, pela lista de links, pelos campos de formulário e pelas mensagens após uma ação. Depois teste a 200% de zoom e em uma largura de 320 pixels CSS. O conteúdo deve continuar disponível sem rolagem horizontal desnecessária, texto sobreposto ou controles inalcançáveis.

Registre também navegadores, dispositivo, URL, passos para reproduzir, resultado esperado e resultado encontrado. Essa evidência permite que outra pessoa confirme a correção sem depender da memória de quem fez o primeiro teste.

Padrões técnicos prontos para adaptar

Os exemplos abaixo são pontos de partida. Eles devem ser adaptados ao tema e testados no contexto real, especialmente quando um construtor visual ou plugin já controla o componente.

Foco visível e cabeçalho fixo

:focus-visible {
  outline: 3px solid #0b5cab;
  outline-offset: 3px;
}

html {
  scroll-padding-top: 6rem;
}

Use uma cor de foco que se destaque tanto em fundos claros quanto escuros. Se o site tem cabeçalho fixo, ajuste a área de rolagem e teste links internos, busca, filtros e campos próximos ao topo.

Link para pular ao conteúdo

<a class="skip-link" href="#conteudo">Pular para o conteúdo</a>
<main id="conteudo">
  ...
</main>

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
  z-index: 9999;
}

Formulário com rótulo e erro útil

<label for="email">E-mail</label>
<input id="email" name="email" type="email"
  autocomplete="email" aria-describedby="erro-email">
<p id="erro-email" role="alert">
  Informe um e-mail válido, como nome@exemplo.com.
</p>

O erro deve aparecer somente quando existir, identificar o campo e explicar a ação necessária. Para mensagens que surgem sem mudança de página, use uma região de status apropriada, como role="status" para confirmação não urgente.

Botões, menus e conteúdo dinâmico

Use <button> para uma ação e <a> para navegação. Não transforme uma div em botão apenas com JavaScript. Em acordeões e menus expansíveis, atualize aria-expanded ao abrir e fechar. Em carrinho AJAX, anuncie a atualização em uma região de status, sem mover o foco de forma inesperada.

WooCommerce: teste e correção por etapa

Uma loja não pode ser considerada acessível apenas porque a página do produto parece correta. Conformidade se aplica ao processo completo, do primeiro filtro até a confirmação do pedido.

1. Listagem e busca: filtros precisam ter rótulos, resultado atualizado compreensível e alternativa aos controles de arrastar.
2. Produto: galeria, variações, quantidade, preço promocional e botão de compra precisam comunicar estado e contexto.
3. Variações: nunca dependa apenas de cor, tamanho visual ou imagem para indicar seleção. Mostre texto e estado selecionado.
4. Carrinho: informe adição, remoção, alteração de quantidade e valor atualizado sem exigir que a pessoa encontre a mensagem visualmente.
5. Cupom: associe o campo ao rótulo e descreva erros, inclusive cupom inválido ou expirado.
6. Checkout: use rótulos persistentes, autocomplete, agrupamentos claros e revisão dos dados antes da confirmação financeira.
7. Confirmação: apresente número do pedido, itens, total, próximos passos e canais de suporte em texto acessível.

Teste ainda gateways, captcha, frete, login social, chat, avaliações e widgets de terceiros. Um componente externo não deixa de ser barreira por estar fora do tema. Quando não houver correção imediata, registre a limitação, ofereça canal alternativo e cobre uma solução do fornecedor.

O que depende de quem publica todo dia

Boa parte da acessibilidade não se resolve no código: ela é criada ou destruída a cada publicação. Quatro hábitos cobrem quase tudo.

Usar títulos como estrutura, nunca como tamanho de fonte , H1 a H6 formam o sumário que o leitor de tela usa para navegar. Escrever links que fazem sentido fora de contexto, porque quem navega por lista de links ouve só o texto âncora. Preencher alt em toda imagem informativa. E tratar vídeo com legenda e transcrição, que servem também a quem assiste sem som.

PDF merece menção à parte: é o formato onde a acessibilidade mais se perde. Sempre que possível, publique o conteúdo como página, não como arquivo.

Fluxo editorial para não recriar barreiras

Crie uma verificação curta antes de publicar. Ela deve fazer parte do processo de revisão, assim como ortografia e links quebrados.

• Há um único H1 e os títulos seguintes representam a estrutura do assunto.
• Todo link explica o destino sem depender do texto ao redor.
• Imagens informativas têm alternativa contextual; imagens decorativas ficam sem alternativa.
• Tabelas só são usadas para dados e têm cabeçalhos.
• Vídeos publicados têm legendas; conteúdos importantes também têm transcrição.
• PDFs essenciais têm estrutura acessível ou uma versão em HTML equivalente.
• Não há instrução baseada apenas em cor, posição ou forma.
• Embeds, mapas, vídeos, chat e formulários de terceiros foram testados no fluxo real.

Essa lista deve ter um responsável. O tema sustenta a base técnica, mas o resultado final depende de quem publica texto, mídia e componentes todos os dias.

Por que plugins de correção automática não bastam

Existe uma categoria de plugin , chamada overlay, ou camada de acessibilidade , que promete resolver a conformidade com uma instalação. Ela atua sobre o site já renderizado, sem alterar o tema: exibe um painel de ajustes de leitura e, nos bastidores, tenta corrigir o DOM em tempo de execução.

O painel de ajustes funciona. A correção automática encontra um limite técnico. Um algoritmo reconhece objetos numa imagem, mas não sabe o que ela comunica naquela página , e um alt gerado automaticamente pode ser descritivamente correto e informativamente inútil. Com ARIA o risco é maior: atributos inseridos sobre uma estrutura mal interpretada produzem marcação válida e semanticamente errada, fazendo o leitor de tela anunciar com segurança algo que não corresponde à tela.

Há ainda um efeito colateral que confunde a avaliação: como o overlay preenche os campos que as ferramentas automáticas verificam, a nota sobe sem que a experiência mude. A pontuação mede presença de atributo, não adequação da informação.

Existe outra família de plugins que ajuda de verdade: os verificadores. Em vez de corrigir, eles encontram e mostram os problemas dentro do editor, no momento em que o erro está sendo criado , quando corrigir custa trinta segundos em vez de uma auditoria depois.

Acessibilidade como diferencial comercial

Para quem trabalha com criação de sites, a WCAG não é só requisito técnico: é escopo vendável. E o erro mais comum é juntar tudo num orçamento só.

São três vendas distintas. A auditoria, que entrega diagnóstico e priorização. A remediação, que executa as correções. E a manutenção, que mantém o padrão a cada publicação , a única recorrente das três, e a mais esquecida.

Publique uma declaração de acessibilidade no site do cliente informando o nível almejado, o que já está conforme, o que ainda não está e um canal de contato para quem encontrar barreira. Ela demonstra compromisso de forma verificável , e é bem mais defensável do que afirmar que o site é “100% acessível”, promessa que ninguém consegue sustentar.

Entregáveis, evidências e declaração de acessibilidade

Uma auditoria bem entregue não termina em uma nota de ferramenta. Entregue inventário das URLs e fluxos testados, lista de achados agrupados por causa, evidência com passos para reproduzir, critério relacionado, prioridade, responsável, prazo e método de reteste.

Uma declaração de acessibilidade deve informar a data da última avaliação, o alvo adotado, os métodos usados, limitações conhecidas, alternativas disponíveis e um canal de contato. Não declare que o site é 100% acessível. Prefira uma afirmação verificável, como: “Este site busca atender à WCAG 2.2 nível AA. Avaliamos os fluxos principais em [data]. Caso encontre uma barreira, fale conosco em [canal].”

Se houver conteúdo de terceiros que não pode ser corrigido diretamente, descreva-o de forma transparente e ofereça caminho alternativo. Essa postura não substitui a correção, mas evita esconder uma limitação real do usuário.

O que vem pela frente

O W3C trabalha na WCAG 3.0, que propõe um modelo diferente de avaliação, mais gradual que a lógica de aprovado ou reprovado dos níveis atuais. Ela é um rascunho de trabalho, pode mudar e não deve ser usada como padrão de conformidade. A WCAG 2.2 permanece a referência vigente.

A conclusão prática é que esperar pela próxima versão é a pior decisão possível: a 3.0 foi desenhada para manter compatibilidade com o que a 2.2 já exige. Tudo que você corrigir agora continua valendo.

Perguntas frequentes

Uma nota alta no Lighthouse significa conformidade?

Não. A ferramenta é útil para encontrar parte dos problemas, mas não avalia a qualidade de um texto alternativo, a clareza de uma instrução, a ordem útil do foco ou todo comportamento dinâmico. Use a nota para acompanhar evolução, junto de testes manuais.

Um plugin resolve a acessibilidade do WordPress?

Não sozinho. Plugins verificadores ajudam a encontrar problemas e plugins específicos podem corrigir um componente, mas não substituem tema semântico, conteúdo revisado e testes de pessoas reais.

Qual é o primeiro ajuste técnico que vale fazer?

Teste o teclado. Se o foco não aparece ou o menu, modal ou checkout não podem ser usados sem mouse, corrija isso antes de aperfeiçoamentos visuais.

WCAG 2.2 AA é garantia de que ninguém encontrará barreiras?

Não. É um alvo técnico mensurável e muito importante, mas o próprio W3C reconhece que nenhum nível cobre todas as necessidades. Avaliação com usuários e manutenção contínua continuam necessárias.

Fontes para consulta

• WCAG 2.2, W3C
• Novidades da WCAG 2.2, W3C
• WCAG 3.0, rascunho de trabalho do W3C
• Lei Brasileira de Inclusão, Lei 13.146/2015
• eMAG, Governo Digital
• Manual da equipe de acessibilidade do WordPress

Por onde começar hoje

Acessibilidade não é um selo que se conquista e se guarda. É uma característica que se mantém, como desempenho e segurança , e que se perde aos poucos, a cada publicação apressada, se ninguém estiver olhando.

Se este guia parecer muito para o tempo que você tem agora, faça uma coisa só: abra seu site, largue o mouse e percorra a página inteira com a tecla Tab. Dez minutos, nenhuma instalação, nenhum custo. Se você chega ao menu, aos links e ao botão do formulário enxergando sempre onde está o foco, a base está saudável. Se o foco some no primeiro menu, você acabou de encontrar , em trinta segundos , por onde o trabalho começa.