O WordPress alimenta 43% da web. São mais de 800 milhões de sites — e a maioria deles tem problemas de acessibilidade que violam os padrões WCAG 2.1 AA.
Os processos judiciais da ADA contra websites ultrapassaram os 6.000 em 2025 e estão a caminho de ultrapassar esse número em 2026. Os alvos não são apenas empresas. Escritórios de advocacia estão apresentando cartas de demanda contra pequenas empresas, lojas WooCommerce, clínicas de saúde e prestadores de serviços locais – a maioria deles executando WordPress.
Em nossa análise de 1.025 sitesas falhas no contraste de cores foram o problema mais comum, aparecendo em 58% dos sites. Texto alternativo ausente, texto de link quebrado e pontos de toque subdimensionados seguiram de perto. O padrão é consistente em todos os setores. E os sites WordPress não são exceção.
Este artigo analisa as falhas de acessibilidade mais comuns específicas do WordPress, por que elas acontecem e exatamente como corrigi-las.
Por que os sites WordPress lutam com acessibilidade
O principal problema não é o WordPress em si – a plataforma suporta desenvolvimento acessível. O problema é o ecossistema: temas criados para apelo visual, construtores de páginas que geram marcações inacessíveis e plug-ins que injetam componentes não compatíveis sem aviso prévio.
A maioria dos desenvolvedores WordPress herda esses problemas sem saber que eles existem.
1. Falhas no contraste de cores
Este é o problema número 1 de acessibilidade na web, e os temas do WordPress são a fonte primária.
Por que isso acontece
Os designers de temas escolhem paletas de cores pela estética, não pelas taxas de contraste. Texto cinza claro em fundos brancos, links azuis claros em fundos claros e texto de espaço reservado em estilo marca d’água são padrão em temas populares – e todos falham nas WCAG 1.4.3, que requer uma taxa de contraste de pelo menos 4,5:1 para texto normal e 3:1 para texto grande.
Como verificar
Use o DevTools do seu navegador. No Chrome, inspecione qualquer elemento de texto, abra o painel Estilos e clique na amostra de cor. O Chrome exibirá a taxa de contraste e a sinalizará como falha se estiver abaixo do limite WCAG.
Para uma verificação em todo o site, execute uma verificação completa nas WCAG 1.4.3 – muitas ferramentas de verificação sinalizam isso automaticamente.
Como consertar
Substitua as cores padrão do seu tema em style.css ou o personalizador do seu tema. Para o corpo do texto, procure uma taxa de contraste acima de 7:1 para melhores práticas, embora 4,5:1 seja o mínimo das WCAG.
/* Example: fixing low-contrast body text */
body {
color: #333333; /* contrast ratio ~12.6:1 on white */
}
/* Example: fixing low-contrast placeholder text */
input::placeholder {
color: #767676; /* minimum passing ratio on white */
}
Se estiver usando um tema de bloco, você poderá controlar as cores por meio de theme.json:
{
"settings": {
"color": {
"palette": (
{
"slug": "body-text",
"color": "#333333",
"name": "Body Text"
}
)
}
}
}
2. Texto alternativo ausente ou decorativo nas imagens
O WordPress facilita a adição de texto alternativo – e igualmente fácil de ignorá-lo. O resultado: milhares de imagens com atributos alt vazios ou, pior, texto alternativo baseado em nome de arquivo, como IMG_20240312_143022.jpg.
Por que isso acontece
Ao fazer upload de imagens na Biblioteca de Mídia, o campo de texto alternativo é opcional e geralmente deixado em branco. Construtores de páginas como Elementor e Divi às vezes preenchem automaticamente o texto alternativo com o título da imagem, que geralmente é um nome de arquivo ou rótulo genérico – não uma descrição significativa.
Requisito WCAG
WCAG 1.1.1 (Nível A) exige que todas as imagens não decorativas tenham uma alternativa de texto que transmita as mesmas informações que a imagem.
Como consertar
Para imagens decorativas que não transmitem nenhuma informação, use um atributo alt vazio:
<img src="divider.png" alt="" role="presentation">
Para imagens informativas, escreva um texto alternativo descritivo que transmita o conteúdo ou função da imagem:
<img src="team-photo.jpg" alt="photo">
<img src="team-photo.jpg" alt="WCAGsafe team of five developers gathered around a conference table reviewing accessibility reports">
Para auditar sua biblioteca de mídia em massa, instale um plugin como “Wp Accessibility” ou consulte seu banco de dados diretamente:
SELECT ID, post_title, guid
FROM wp_posts
WHERE post_type = 'attachment'
AND post_mime_type LIKE 'image/%'
AND ID NOT IN (
SELECT post_id FROM wp_postmeta WHERE meta_key = '_wp_attachment_image_alt' AND meta_value != ''
);
Isso retorna todas as imagens sem texto alternativo definido em sua biblioteca.
Os menus de navegação do WordPress são notoriamente problemáticos para usuários de teclado e leitores de tela. Menus suspensos que abrem apenas ao passar o mouse, estados de foco ausentes e pontos de referência de navegação não rotulados são as falhas mais comuns.
Por que isso acontece
A maioria dos temas do WordPress implementa navegação suspensa apenas com estados de foco CSS – que são inacessíveis para usuários apenas de teclado que não podem acionar :hover. Além disso, os temas raramente adicionam aria-expanded ou aria-haspopup atributos para alternar o menu.
Requisito WCAG
WCAG 2.1.1 requer que todas as funcionalidades sejam operáveis via teclado. WCAG 4.1.2 exige que os componentes interativos tenham funções e estados ARIA apropriados.
Como consertar
Adicione suporte de teclado aos seus menus suspensos. Se você estiver usando um tema personalizado, modifique seu navigation.js:
document.querySelectorAll('.menu-item-has-children > a').forEach(function(link) {
link.setAttribute('aria-haspopup', 'true');
link.setAttribute('aria-expanded', 'false');
link.addEventListener('click', function(e) {
const expanded = this.getAttribute('aria-expanded') === 'true';
this.setAttribute('aria-expanded', !expanded);
e.preventDefault();
});
link.addEventListener('keydown', function(e) {
if (e.key === 'Escape') {
this.setAttribute('aria-expanded', 'false');
this.focus();
}
});
});
Certifique-se também de que seu ponto de referência de navegação esteja devidamente identificado:
<nav aria-label="Main navigation">
nav>
Se você tiver vários
aria-label.
Contact Form 7, WPForms, Gravity Forms – todos populares, todos capazes de produzir resultados inacessíveis dependendo de como estão configurados.
Os problemas mais comuns: entradas de formulário sem rótulos associados, mensagens de erro que não são anunciadas aos leitores de tela e campos obrigatórios não identificados programaticamente.
Por que isso acontece
Os padrões do plug-in geralmente usam texto de espaço reservado como substituto dos rótulos – que desaparecem quando o usuário começa a digitar, deixando-os sem contexto. Mensagens de erro são frequentemente inseridas visualmente no DOM, mas não são anunciadas por meio de regiões ativas ARIA.
Requisito WCAG
WCAG 1.3.1 exige que as entradas do formulário tenham rótulos associados programaticamente. WCAG 3.3.1 exige que as mensagens de erro sejam identificadas no texto e associadas ao campo relevante.
Como consertar
Sempre use elementos explicitamente associados às suas entradas por meio de for / id:
<input type="email" placeholder="Your email address">
<label for="email">Email address <span aria-hidden="true">*span><span class="sr-only">(required)span>label>
<input type="email" id="email" name="email" placeholder="you@example.com" required aria-required="true">
Para mensagens de erro, use aria-describedby para associar o erro ao campo:
<label for="email">Email addresslabel>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<span id="email-error" role="alert">Please enter a valid email address.span>
O role="alert" garante que os leitores de tela anunciem o erro imediatamente quando ele aparecer no DOM.
No Contact Form 7, habilite o modo de acessibilidade nas configurações, que adiciona associações de rótulos adequadas por padrão.
5. Link para pular navegação ausente
Todo site WordPress com menu de navegação deve ter um link para pular – um link oculto que aparece no foco do teclado e permite aos usuários pular a navegação diretamente para o conteúdo principal.
Sem ele, os usuários do teclado devem percorrer cada item de navegação em cada página antes de chegar ao conteúdo que procuram.
Por que isso acontece
A maioria dos temas do WordPress simplesmente não inclui links para pular. É uma adição única que é fácil de perder durante o desenvolvimento e invisível para usuários com visão durante o controle de qualidade.
Requisito WCAG
WCAG 2.4.1 (Nível A) — o requisito mais fundamental de desvio de navegação.
Como consertar
Adicione isso ao topo do seu header.phpantes da abertura
<a class="skip-link screen-reader-text" href="#main-content">Skip to main contenta>
Adicione este CSS para torná-lo visível apenas no foco:
.skip-link {
position: absolute;
left: -9999px;
top: auto;
width: 1px;
height: 1px;
overflow: hidden;
}
.skip-link:focus {
position: fixed;
top: 0;
left: 0;
width: auto;
height: auto;
padding: 1rem 2rem;
background: #000000;
color: #ffffff;
font-size: 1rem;
font-weight: bold;
z-index: 99999;
text-decoration: none;
}
Em seguida, adicione id="main-content" ao seu wrapper de conteúdo principal:
<main id="main-content">
main>
Isso leva menos de 10 minutos para ser implementado e satisfaz uma das falhas mais comumente citadas das WCAG em ações judiciais da ADA.
6. Construtores de páginas gerando marcação inacessível
Elementor, Divi, WPBakery e Beaver Builder são responsáveis por uma parcela significativa das falhas de acessibilidade do WordPress. Eles geram estruturas div profundamente aninhadas, injetam estilos embutidos que substituem os indicadores de foco e criam componentes interativos sem atributos ARIA.
Falhas comuns no construtor de páginas
Abas e acordeões Elementor – muitas vezes construído sem role="tablist", role="tab"e aria-selected atributos, tornando-os inutilizáveis para usuários de leitores de tela.
Divi alterna – uso frequente
Carrosséis WPBakery — reprodução automática habilitada por padrão, violando WCAG 2.2.2 (Pausar, Parar, Ocultar).
Como consertar
Para Elementor, habilite as opções “Carregamento de CSS aprimorado” e “Recursos de acessibilidade” em Elementor > Configurações > Avançado. Isso adiciona atributos ARIA básicos aos widgets Elementor.
Para correções personalizadas, você pode conectar-se wp_footer para corrigir atributos ARIA após a saída do construtor de páginas:
document.querySelectorAll('.elementor-tab-title').forEach(function(tab, index) {
tab.setAttribute('role', 'tab');
tab.setAttribute('aria-selected', index === 0 ? 'true' : 'false');
tab.setAttribute('tabindex', index === 0 ? '0' : '-1');
});
document.querySelectorAll('.elementor-tab-content').forEach(function(panel, index) {
panel.setAttribute('role', 'tabpanel');
panel.setAttribute('aria-hidden', index === 0 ? 'false' : 'true');
});
Para carrosséis, sempre desative a reprodução automática ou adicione controles de pausa:
document.querySelectorAll('.elementor-carousel').forEach(function(carousel) {
carousel.addEventListener('focusin', function() {
this.swiper.autoplay.stop();
});
});
7. Supressão do Indicador de Foco
Esta é uma das falhas de acessibilidade mais comuns e prejudiciais em sites WordPress. Os temas rotineiramente incluem este CSS:
*:focus {
outline: none;
}
Esta regra única remove o indicador de foco visível de todos os elementos interativos da página – links, botões, entradas de formulário, tudo. Os usuários que utilizam apenas o teclado não têm como saber onde estão na página.
Requisito WCAG
WCAG 2.4.7 (Nível AA) exige que o foco do teclado esteja visível. WCAG 2.4.11 (Nível AA, adicionado nas WCAG 2.2) exige que o foco não fique totalmente oculto.
Como consertar
Remover outline: none do seu CSS global. Substitua-o por um indicador de foco estilizado que funcione com seu design:
:focus-visible {
outline: 3px solid #005fcc;
outline-offset: 2px;
border-radius: 2px;
}
:focus:not(:focus-visible) {
outline: none;
}
O :focus-visible a pseudoclasse agora é suportada em todos os navegadores modernos e mostra o indicador de foco apenas ao navegar pelo teclado - resolvendo a preocupação "Não quero um contorno ao clicar do mouse" sem sacrificar a acessibilidade do teclado.
Plug-ins de acessibilidade para WordPress recomendados
Vários plug-ins podem ajudar a detectar e corrigir problemas de acessibilidade sem mexer no código:
Acessibilidade WP (grátis) — por Joe Dolson, um dos nomes mais respeitados em acessibilidade WordPress. Adiciona links para pular, corrige problemas comuns de temas e melhora rótulos de formulários.
Verificador de acessibilidade digital Equalize (gratuito/pago) – verifica seu conteúdo no editor WordPress e sinaliza problemas antes de publicar.
Sa11y — um verificador de acessibilidade baseado em JavaScript que é executado no front-end e destaca visualmente os problemas para os editores.
Nenhuma dessas soluções é completa – elas abordam um subconjunto de problemas. Uma auditoria WCAG 2.1 AA completa requer uma combinação de verificação automatizada e testes manuais.
A realidade jurídica
Os tribunais têm decidido consistentemente que WCAG 2.1 AA é o padrão aplicável para conformidade do site ADA. O DOJ formalizou isto na sua regulamentação de março de 2024 para entidades do Título II, e a aplicação do Título III no setor privado segue o mesmo padrão na prática.
Os sites WordPress não estão isentos. A escala da plataforma significa que os advogados a direcionam especificamente – um modelo de carta de demanda pode ser enviado para milhares de sites semelhantes. Restaurantes, escritórios de advocacia, consultórios médicos e lojas de comércio eletrônico que executam WordPress foram todos alvo.
A boa notícia: a maioria dos problemas de acessibilidade do WordPress podem ser corrigidos. Contraste de cores, texto alternativo, indicadores de foco, links para pular e rótulos de formulário são responsáveis pela maioria das violações citadas em cartas de demanda – e todas elas podem ser resolvidas com alterações direcionadas de CSS e HTML.
Por onde começar
Se você não tiver certeza da localização do seu site WordPress, comece com uma verificação automatizada. As ferramentas automatizadas detectam aproximadamente 30–40% das falhas das WCAG, mas identificam rapidamente os problemas mais comuns e fornecem uma lista de prioridades para trabalhar.
A partir daí, complemente com testes manuais de teclado: navegue por todo o site usando apenas o teclado. Se você ficar preso, perder a noção de onde está ou não conseguir alcançar alguma coisa – isso é um fracasso.
A acessibilidade não é uma caixa de seleção única. É uma prática contínua, especialmente no WordPress, onde cada atualização de plugin e mudança de tema pode introduzir novos problemas. Inclua auditorias em seu processo de implantação e você estará bem à frente dos riscos legais.
O autor analisou violações de acessibilidade em 1.025 sites. O estudo de dados completo, incluindo uma análise das falhas mais comuns das WCAG por categoria, está disponível aqui: 10 problemas de acessibilidade mais comuns: um estudo de 1.025 locais.
