# Tema acessível no WordPress: Os 6 critérios que importam

Um <strong>tema acessível</strong> respeita a WCAG 2.2 em contraste, foco visível, semântica e navegação por teclado. Segundo o <a href="https://webaim.org/projects/million/">WebAIM Million (2026)</a>, 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 <a href="https://full.services/acessibilidade-wordpress/">acessibilidade no WordPress da FULL</a> 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.

<table id="criterios-tema-acessivel">
  <caption>Tema acessível: o que o tema resolve e o que fica com o editor</caption>
  <thead>
    <tr>
      <th scope="col">Critério WCAG 2.2</th>
      <th scope="col">Responsabilidade do tema</th>
      <th scope="col">Responsabilidade do editor</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Contraste de cor</th>
      <td>Paleta padrão acima de 4.5:1</td>
      <td>Não aplicar cores fora da paleta</td>
    </tr>
    <tr>
      <th scope="row">Texto alternativo</th>
      <td>Suporte ao campo alt na mídia</td>
      <td>Preencher o alt de cada imagem</td>
    </tr>
    <tr>
      <th scope="row">Foco por teclado</th>
      <td>Outline visível em links e botões</td>
      <td>Não remover o foco via CSS custom</td>
    </tr>
    <tr>
      <th scope="row">Semântica de cabeçalho</th>
      <td>H1 único e hierarquia correta</td>
      <td>Não pular de H2 para H4 no editor</td>
    </tr>
  </tbody>
</table>

<p class="wp-caption-text">Legenda: a mesma paleta reprova ou passa na WCAG conforme a razão de contraste do texto sobre o fundo.</p>

---

## 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 <time datetime="2026">2026</time>. 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 <a href="https://full.services/glossario/contraste-de-cor-acessibilidade/">contraste de cor para acessibilidade</a> 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 `<button>` nativa por uma `<div>` com `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 <a href="https://full.services/como-adicionar-um-menu-de-navegacao-no-wordpress/">menu de navegação no WordPress</a> 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 `<h1>`, hierarquia sem saltos, e regiões `<header>`, `<main>`, `<nav>` e `<footer>`. 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 <a href="https://full.services/core-web-vitals-wordpress/">Core Web Vitals</a>, porque tema leve e semântico costuma carregar mais rápido.

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>Os critérios deste guia seguem a WCAG 2.2 nível AA, referência adotada pela maioria das legislações de acessibilidade digital, e foram cruzados com os apontamentos recorrentes nos tickets de suporte da FULL sobre temas WordPress. As ferramentas citadas (WAVE, axe DevTools, Lighthouse) foram usadas entre <time datetime="2026-01">janeiro</time> e <time datetime="2026-05">maio de 2026</time> em temas de page builder e temas de bloco do core. O teste de teclado e leitor de tela foi feito manualmente com NVDA e VoiceOver, porque nenhuma ferramenta automática detecta sozinha mais de 30% a 40% das barreiras reais de uso.</p>
</aside>

---

## 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 <a href="https://full.services/glossario/alt-text/">alt text</a> de cada imagem é decisão de quem publica, e ferramentas de <a href="https://full.services/alt-text-com-ia-wordpress/">alt text com IA no WordPress</a> 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 <a href="https://full.services/astra-theme-review/">review do tema Astra</a>, é o ponto de partida certo, mas a manutenção contínua é o que sustenta o resultado. Você pode aprofundar com <a href="https://full.services/ia-para-acessibilidade-wordpress/">IA para acessibilidade no WordPress</a> e <a href="https://full.services/personalizar-tema-astra/">personalização segura do Astra</a>.

---

## 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 <a href="https://full.services/planos">planos da FULL</a> para comparar o que cada nível inclui.

---

<h2 id="faq">Perguntas frequentes sobre tema acessível</h2>

<details>
<summary>É possível deixar um tema acessível sem trocar de tema?</summary>
<p>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 `<div>` no lugar de `<button>` ou remove ARIA essencial, a correção manual fica frágil e quebra a cada update. Nesses casos, migrar para um tema acessível de base sólida custa menos esforço que remendar.</p>
</details>

<details>
<summary>Por que um tema marcado como acessível ainda reprova em auditoria?</summary>
<p>Porque o rótulo "acessível" não é certificado WCAG 2.2 e mede só o template vazio. Ferramentas como WAVE e Lighthouse avaliam a página publicada inteira, então a reprovação vem do que o editor adicionou: imagem sem alt, formulário de terceiros mal rotulado, cor de marca abaixo de 4.5:1. O Lighthouse pode dar nota 100 no tema puro e cair para 70 com o conteúdo real por cima. O tema entrega a base; a auditoria julga o resultado final.</p>
</details>

<details>
<summary>Qual a diferença entre tema acessível e tema responsivo?</summary>
<p>São coisas distintas. Tema responsivo adapta o layout a telas de tamanhos diferentes, do celular ao desktop. Tema acessível garante que o conteúdo seja percebido e operado por todos, incluindo quem usa leitor de tela ou só teclado, seguindo a WCAG 2.2. Um tema pode ser perfeitamente responsivo e mesmo assim reprovar em contraste, foco e semântica, ou seja, ser inacessível.</p>
</details>

<details>
<summary>Quanto custa tornar um tema WordPress acessível?</summary>
<p>Varia conforme o ponto de partida. Corrigir contraste e foco num tema já bom é trabalho de poucas horas e custo zero de licença. Reescrever um tema com HTML não semântico pode exigir desenvolvimento dedicado. Optar por um tema acessível de fábrica, como o Astra PRO incluso no plano PRO da FULL por R$849 ao ano (cerca de R$85 por site), costuma sair mais barato que a correção retroativa.</p>
</details>

<details>
<summary>O que a WCAG 2.2 exige de um tema acessível?</summary>
<p>A WCAG 2.2 nível AA exige contraste mínimo de 4.5:1 para texto corpo e 3:1 para texto grande, foco visível em todo elemento interativo, operação completa por teclado, hierarquia de cabeçalhos sem saltos e marcação semântica com regiões e ARIA quando necessário. Um tema acessível precisa atender a esses critérios de código de fábrica, deixando ao editor apenas o alt das imagens e a revisão do conteúdo publicado.</p>
</details>

---

## Próximos passos para um site acessível

Escolher um tema acessível é a decisão de maior impacto e a mais difícil de reverter depois, então vale priorizá-la antes de qualquer plugin. Comece pelos quatro critérios de código (contraste, foco, semântica e teclado), valide com WAVE, Lighthouse e um teste manual de teclado, e só então parta para o conteúdo. Lembre que o tema resolve a estrutura, mas alt de imagem, plugins de terceiros e customizações de CSS continuam nas suas mãos. Para continuar aprendendo, o <a href="https://full.services/academy/">FULL Academy</a> reúne tutoriais, guias e reviews de WordPress em um só lugar. A acessibilidade, como o <a href="https://full.services/glossario/acessibilidade-web-wcag/">padrão WCAG</a> deixa claro, é processo contínuo, não item de checklist único, e um bom <a href="https://full.services/glossario/tema-wordpress/">tema WordPress</a> é onde esse processo começa.
