Um tema acessível respeita a WCAG 2.2 em contraste, foco visível, semântica e navegação por teclado. Segundo o WebAIM Million (2026), 83,9% das home pages têm texto abaixo do contraste mínimo. A maioria desses erros nasce no tema, não no conteúdo. Escolher o tema certo resolve a base; o resto depende de plugins e revisão editorial.
Um tema acessível é o template que entrega o site já em conformidade com a WCAG 2.2 nos pontos que dependem do código: contraste de cor, ordem de foco, marcação semântica e operação por teclado. Ele não garante um site 100% acessível sozinho, porque imagem sem texto alternativo e formulário mal rotulado vêm do editor. Mas um tema acessível remove a camada de barreiras estruturais que nenhum plugin conserta depois. Na prática que a gente vê no suporte da FULL, trocar de tema resolve mais problemas de acessibilidade do que instalar dez plugins de correção. Este guia faz parte do hub de acessibilidade no WordPress da FULL e cobre os critérios que separam um tema acessível de um tema apenas bonito.
O que define um tema acessível: Definição operacional
Um tema acessível atende a quatro frentes técnicas mensuráveis antes de qualquer conteúdo entrar no ar. A primeira é contraste: razão mínima de 4.5:1 para texto corpo, conforme a WCAG 2.2. A segunda é foco visível. A terceira é semântica, com um único H1 e hierarquia sem saltos. A quarta é operação total por teclado, sem depender do mouse.
A tabela abaixo resume o que um tema acessível precisa entregar de fábrica e o que continua sendo responsabilidade de quem publica. A separação importa: muita gente compra um tema rotulado como acessível e culpa o template por erros que são de conteúdo.
| Critério WCAG 2.2 | Responsabilidade do tema | Responsabilidade do editor |
|---|---|---|
| Contraste de cor | Paleta padrão acima de 4.5:1 | Não aplicar cores fora da paleta |
| Texto alternativo | Suporte ao campo alt na mídia | Preencher o alt de cada imagem |
| Foco por teclado | Outline visível em links e botões | Não remover o foco via CSS custom |
| Semântica de cabeçalho | H1 único e hierarquia correta | Não pular de H2 para H4 no editor |
Legenda: a mesma paleta reprova ou passa na WCAG conforme a razão de contraste do texto sobre o fundo.
Por que contraste é o erro mais comum em tema acessível
O contraste de cor é a falha número um e aparece em 83,9% das páginas analisadas pelo WebAIM Million em . A causa costuma ser a mesma: um cinza claro elegante para texto secundário e rótulos cai abaixo de 4.5:1 contra o branco. Um tema acessível trata isso fixando a paleta dentro do limite WCAG já no theme.json.
O problema agrava quando o tema usa cores de marca do cliente sem checagem. Texto branco sobre um amarelo de marca, por exemplo, costuma ficar em 1.8:1, ilegível para qualquer pessoa com baixa visão. A regra de contraste de cor para acessibilidade não é estética: é a diferença entre o conteúdo ser lido ou não. Ferramentas como WAVE e Lighthouse apontam cada par de cores reprovado em segundos, e um tema acessível bem construído sai com zero apontamentos de contraste no relatório inicial.
Foco visível e teclado: O critério que ninguém testa
Operação por teclado é o critério que mais reprova em auditoria, e ferramentas automáticas pegam menos de 40% dessas falhas. Um tema acessível mantém o outline de foco visível em todo elemento interativo e preserva a ordem de tabulação. Quando o tema troca a tag nativa por uma
onclick, o teclado não alcança aquele controle.
O caso mais frequente nos tickets da FULL é o menu mobile de temas de page builder. O overlay abre, mas o foco continua no conteúdo atrás dele. Sem aria-modal e sem focus trap, o leitor de tela segue lendo a página de fundo enquanto o menu está aberto, o que confunde por completo a navegação. Para validar, basta navegar o site só com Tab e Enter: se algum link some do caminho ou o foco desaparece, o tema reprova. O guia de menu de navegação no WordPress mostra como manter a estrutura do menu semântica.
Semântica e leitor de tela: A estrutura invisível
A marcação semântica é o que um leitor de tela usa para montar o mapa da página, e um tema acessível acerta isso no template. São 4 pilares: um único
, hierarquia sem saltos, e regiões
, ,
e
. Quando o tema repete H1 em cada widget ou pula de H2 para H4, quem navega por cabeçalhos perde a referência.
A camada seguinte é o uso correto de WAI-ARIA, e aqui menos é mais. Um tema acessível só adiciona atributos aria-* quando o HTML nativo não dá conta, porque ARIA mal aplicado quebra mais do que conserta. Botões de menu hambúrguer precisam de aria-expanded que muda de estado; o conteúdo principal precisa de um link “pular para o conteúdo” no topo. Temas como o Twenty Twenty-Five do core já trazem esse skip link de fábrica, e é um bom parâmetro de comparação ao avaliar qualquer tema acessível comercial.
Como testar um tema acessível antes de publicar
Testar um tema acessível leva cerca de 15 minutos com três ferramentas gratuitas e uma verificação manual. Comece pelo axe DevTools ou pelo WAVE numa página com conteúdo real, não na home vazia: eles listam contraste, alt ausente e erros de ARIA com a linha exata. Em seguida, rode o Lighthouse no Chrome, cuja aba de acessibilidade dá uma nota de 0 a 100 e detalha cada item reprovado.
A parte que nenhuma ferramenta automática cobre é a navegação por teclado, e ela responde por boa parte das barreiras reais. Percorra o site inteiro só com Tab, Shift+Tab e Enter, confirmando que todo link e botão recebem foco visível e que o menu abre e fecha sem o mouse. Por fim, ative o leitor de tela do próprio sistema (NVDA no Windows, VoiceOver no Mac) e ouça a home: se a ordem de leitura faz sentido, o tema acessível passou no teste que mais importa. A acessibilidade também conversa com Core Web Vitals, porque tema leve e semântico costuma carregar mais rápido.
Quando o tema acessível não basta
Um tema acessível resolve a estrutura, mas 3 fontes de barreira continuam fora do seu alcance. A primeira é o conteúdo editorial: imagem sem alt, vídeo sem legenda e PDF não marcado passam direto pelo melhor template. O alt text de cada imagem é decisão de quem publica, e ferramentas de alt text com IA no WordPress ajudam a escalar isso.
A segunda fonte são os plugins. Um formulário de terceiros, um pop-up de marketing ou um slider podem injetar HTML inacessível que o tema não controla. A terceira é a customização: remover o outline de foco no CSS ou aplicar cores fora da paleta destrói a acessibilidade que o tema entregava. Por isso, escolher um tema acessível com boa base, como mostra nosso review do tema Astra, é o ponto de partida certo, mas a manutenção contínua é o que sustenta o resultado. Você pode aprofundar com IA para acessibilidade no WordPress e personalização segura do Astra.
Tema acessível pronto com o bundle da FULL
Montar um stack de tema acessível mais plugins de SEO, performance e segurança avulso custa caro e dá trabalho de licença. No plano PRO da FULL, por R$849 por ano, você tem o Astra PRO mais 16 plugins premium inclusos, o que dá cerca de R$85 por site quando o plano cobre 10 sites. A gente vê no suporte que ter o tema base já confiável e atualizado evita a maior parte dos chamados de acessibilidade e performance que chegam de sites montados com peças soltas. Veja os planos da FULL para comparar o que cada nível inclui.
Perguntas frequentes sobre tema acessível
É possível deixar um tema acessível sem trocar de tema?
Sim, em parte. Dá para corrigir contraste pela paleta, restaurar o foco visível via CSS e ajustar a hierarquia de cabeçalhos sem trocar o tema. Mas se o tema gera HTML não semântico, usa `
















