Acessibilidade Web (WCAG)

WCAG (Web Content Accessibility Guidelines) é o padrão global de acessibilidade web criado pelo W3C. Define regras técnicas para tornar conteúdo da web acessível a pessoas com deficiência: visual, auditiva, motora, cognitiva. WCAG 2.1 nível AA é o padrão recomendado e o mínimo legalmente exigido em vários países. Para sites WordPress, aplicar WCAG significa imagens com alt text, contraste de cor adequado, navegação por teclado, estrutura semântica e formulários acessíveis.

O que é WCAG?

WCAG é a sigla para Web Content Accessibility Guidelines, um conjunto de diretrizes técnicas mantido pelo W3C (consórcio internacional que padroniza tecnologias web). Existe desde 1999, em versões progressivas (WCAG 1.0, 2.0, 2.1, 2.2). É a referência mundial para acessibilidade digital.

Acessibilidade web não é só sobre pessoas cegas usando leitores de tela. Cobre cinco categorias principais: deficiência visual (cegueira, baixa visão, daltonismo), deficiência auditiva (surdez, perda parcial), deficiência motora (dificuldade de mouse, tremor, paralisia), deficiência cognitiva (dislexia, TDAH, autismo), e usuários situacionais (idoso, conexão lenta, ambiente barulhento).

No Brasil, sites de empresas privadas com mais de 50 funcionários e qualquer site público devem seguir acessibilidade conforme a Lei Brasileira de Inclusão (LBI). Multas podem ser aplicadas. Mais que conformidade, é responsabilidade — pessoas com deficiência são 23% da população brasileira segundo IBGE.

Para sites WordPress, WCAG impacta tema, plugins, conteúdo e configurações. Não é responsabilidade só do desenvolvedor — é decisão de produto que envolve design, conteúdo e negócio.

Versões do WCAG

Quatro versões marcam a evolução do padrão.

WCAG 2.0

Lançada em 2008, primeira versão amplamente adotada como referência legal. Tem 12 diretrizes em quatro princípios. Ainda é citada em legislações antigas, mas considerada desatualizada para web moderna.

WCAG 2.1 (atual padrão)

Lançada em 2018, adiciona 17 novos critérios à 2.0. Cobre melhor mobile, baixa visão e deficiência cognitiva. É o padrão recomendado em 2026 para a maioria dos contextos. Lei brasileira (LBI) aceita 2.0 ou 2.1, mas 2.1 é o esperado para sites novos.

WCAG 2.2

Lançada em 2023. Adiciona 9 novos critérios à 2.1, focando em melhorias para deficiência cognitiva e motora. Em 2026, ainda em adoção. Sites novos podem mirar 2.2 para se preparar para legislações futuras.

WCAG 3.0 (em desenvolvimento)

Versão futura, em desenvolvimento desde 2020. Reescreve completamente o framework com pontuação numérica em vez de pass/fail binário. Ainda sem data de lançamento oficial. Não use como referência ainda.

Níveis de conformidade WCAG

WCAG define três níveis de conformidade. A escolha define quais critérios precisam ser atendidos.

Nível A (básico)

O mínimo absoluto. 25 critérios em WCAG 2.1. Cobre o que torna o site usável por pessoas com deficiência (alt text, navegação por teclado, formulários com label). Site sem nível A não é acessível, ponto.

Nível AA (recomendado)

Soma 13 critérios adicionais ao nível A (38 total em WCAG 2.1). É o padrão recomendado para sites comerciais e o mínimo exigido pela maioria das legislações. Cobre contraste de cor adequado, redimensionamento de texto, estrutura semântica robusta. Mire AA para todos os projetos WordPress.

Nível AAA (avançado)

Soma 23 critérios adicionais ao AA (61 total). É excelência em acessibilidade. Cobre línguas de sinais em vídeos, contrastes maiores, conteúdo extremamente claro. Atingir AAA em todo site é difícil — geralmente foca-se em partes críticas. Não obrigatório por lei.

Os 4 princípios do WCAG

Todos os critérios WCAG se organizam em quatro princípios fundamentais, conhecidos pelo acrônimo POUR.

Perceptível

Conteúdo pode ser percebido por todos os usuários, incluindo aqueles que não veem ou não ouvem. Imagens precisam ter alt text. Vídeos precisam ter legendas e transcrições. Ícones precisam de label aria. Conteúdo só visual exclui cegos; conteúdo só auditivo exclui surdos.

Operável

Interface pode ser operada por todos, incluindo quem não usa mouse. Tudo precisa funcionar com teclado. Tempos de timeout precisam ser ajustáveis. Conteúdo que pisca rápido (mais de 3 vezes por segundo) é proibido por causar convulsões.

Compreensível

Texto e operação são previsíveis e claros. Linguagem clara. Erros de formulário identificados claramente, com sugestão de correção. Comportamento da página não muda inesperadamente quando elementos recebem foco.

Robusto

Conteúdo é compatível com tecnologias assistivas atuais e futuras. HTML semântico bem-formado. Atributos ARIA usados corretamente quando necessário. Site funcional em diferentes navegadores e leitores de tela.

Como aplicar WCAG no WordPress

Seis práticas essenciais para WordPress acessível.

Alt text em imagens

Toda imagem informativa precisa de alt text descrevendo o conteúdo. Em WordPress, o campo está disponível ao subir mídia. Não use “imagem.jpg” ou “foto” — descreva o que a imagem mostra. Imagens decorativas podem usar alt vazio (alt=””) para serem ignoradas por leitores de tela.

Contraste de cor adequado

Texto precisa de contraste mínimo de 4.5:1 com o fundo (3:1 para texto grande, definido como 18px+ regular ou 14px+ bold). Use ferramenta como WebAIM Contrast Checker para validar. Veja mais em contraste de cor.

Navegação por teclado

Tudo que se faz com mouse precisa funcionar com teclado. Tab para mover, Enter para clicar, Escape para fechar modal. Foco visível (outline ou similar) sempre presente. Skip link no topo da página para pular menu repetitivo.

Estrutura semântica de headings

Use H1, H2, H3 conforme estrutura lógica, não conforme tamanho desejado. Um H1 por página. H2 para seções principais. H3 para subseções. Leitores de tela navegam por essa estrutura — má hierarquia confunde usuários cegos.

Labels em formulários

Todo input precisa de label vinculado (via for/id ou wrap). Placeholders sozinhos não bastam — somem ao digitar e leitores de tela não os anunciam consistentemente. Em formulários WordPress, plugins como Contact Form 7 e Gravity Forms permitem labels acessíveis se configurados corretamente.

Skip links

Link no topo da página, escondido até receber foco, que permite pular direto para o conteúdo principal. Útil para usuários de teclado que não querem tabular pelo menu inteiro a cada página. Plugins como WP Accessibility adicionam automaticamente.

Acessibilidade web e LGPD/legislação brasileira

A LBI (Lei Brasileira de Inclusão, Lei nº 13.146/2015) exige que sites de pessoa jurídica de direito público e empresas privadas com mais de 50 funcionários sigam padrões de acessibilidade. Não cumprimento pode gerar multas e ações judiciais.

Decreto 5.296/2004 detalha requisitos. Em geral, o esperado é WCAG 2.0 ou 2.1, nível AA, em todo conteúdo público do site. Áreas administrativas internas têm exigência similar para empresas com público com deficiência entre funcionários.

A LGPD, embora foque em proteção de dados, intersecta acessibilidade no termo de consentimento. Pop-ups de cookies que bloqueiam navegação por teclado violam tanto LGPD quanto WCAG. Solução: pop-up acessível, com botões funcionais via teclado e contraste adequado.

O Brasil também tem Modelo de Acessibilidade em Governo Eletrônico (eMAG) — versão brasileira do WCAG, alinhado ao padrão global mas com adaptações culturais. Sites de governo seguem eMAG; sites comerciais geralmente seguem WCAG diretamente.

Ferramentas para testar acessibilidade

Lighthouse (no Chrome DevTools) tem aba Accessibility que verifica automaticamente vários critérios WCAG. Score de 0 a 100 com lista de problemas. Não pega tudo — automação cobre cerca de 30% dos critérios — mas é o ponto de partida fácil.

WAVE (do WebAIM) é extensão de navegador que injeta marcadores visuais no site mostrando problemas de acessibilidade. Identifica imagens sem alt text, headings em ordem errada, contraste insuficiente. Gratuita e fácil de usar.

axe DevTools é uma das ferramentas mais robustas, com versão grátis e paga. Plugin no Chrome/Firefox que escaneia a página. Identifica problemas com explicações detalhadas e sugestões de correção. Padrão da indústria em times profissionais.

Para teste manual, use TalkBack (Android) ou VoiceOver (iOS, macOS) para experimentar o site como pessoa cega. NVDA (Windows) e JAWS (Windows) são leitores de tela populares. Tabular pelo site sem mouse revela problemas que automação não pega.

Perguntas frequentes

WCAG é obrigatório no Brasil? Para empresas com mais de 50 funcionários e órgãos públicos, sim, conforme LBI (Lei nº 13.146/2015). Padrão esperado é WCAG 2.0 ou 2.1, nível AA. Para empresas menores não é obrigatório por lei, mas é boa prática e protege contra ações judiciais por inacessibilidade.

Como saber se meu site WordPress é acessível? Use Lighthouse no Chrome DevTools para teste rápido (Score 90+ é bom sinal). Use WAVE ou axe DevTools para auditoria detalhada. Teste manualmente com leitor de tela e navegação por teclado. Para certeza, contrate auditoria profissional de acessibilidade.

Plugin de acessibilidade resolve sozinho? Não. Plugins como WP Accessibility ajudam adicionando skip links, ARIA básico e correções comuns. Mas acessibilidade real exige decisões em design, conteúdo e código. Plugin é apoio, não solução. Cuidado especial com “overlays” que prometem acessibilidade automática — não funcionam e podem piorar a experiência.

Sites WordPress acessíveis e conformes: conheça os planos PRO da FULL Services. Entregamos WordPress com tema acessível, plugins configurados para WCAG e UX profissional para todos os usuários.