Acessibilidade (WCAG 2.2) em 2026: O seu site WordPress é legal?

Em junho de 2025, a paisagem digital mudou para sempre. O Ato Europeu de Acessibilidade (EAA) entrou em pleno vigor, tornando a acessibilidade web um requisito legal para quase todas as empresas digitais a operar na UE.

Já não é apenas “bom ter”. É semelhanté ao RGPD. O incumprimento arrisca multas significativas e processos judiciais.

Para programadores WordPress e proprietários de sites, o padrão é WCAG 2.2 Nível AA. Este guia (2000+ palavras) detalha exatamenté o que mudou em 2026 e como garantir qué o seu tema não está a infringir a lei.

#1. O EAA: porque 2025 foi o ponto de viragem

Anteriormente, as leis dé acessibilidadé aplicavam-se principalmenté ao Setor Público (Governo/Universidades). O EAA expandiu isto para E-commerce, Banca, Transportes e eBooks.

• Âmbito: Se vendé uma t-shirt a um cliente em França (ou Portugal), o seu fluxo de checkout deve ser acessível.
• A Penalização: As multas variam por país, mas podem ser severas, juntamente com os danos reputacionais de excluir 15% da população global.

#2. WCAG 2.2: os novos critérios explicados

O WCAG 2.2 construiu sobré o 2.1, adicionando 9 novos critérios. Os mais críticos para temas WordPress são:

#2.4.11 Foco não obscurecido (mínimo) (AA)

• O Problema: Navega com Tab pela página. Um elemento recebe foco, mas o seu “Sticky Header” ou “Banner de Cookies” cobre-o. O útilizador sabe que está em algum lugar, mas não consegue ver onde.
• A Correção: Use CSS scroll-padding-top no elemento html para garantir qué os itens focados rolem para a área visível abaixo do seu cabeçalho fixo.

#2.5.8 Tamanho do alvo (mínimo) (AA)

• A Regra: Alvos interativos (botões) devem ter pelo menos 24x24 pixels CSS.
• A Realidade: Aqueles botões minúsculos “X” de fechar nos seus popups? São ilegais. Torne-os maiores. Toques com o dedo são imprecisos.

#3.3.8 Autenticação acessível (AA)

• A Regra: Não forcé os útilizadores a resolver puzzles (CAPTCHAs) ou memorizar senhas sem ajuda.
• O Impacto no WordPress: Suporte gestores de senhas (não bloqueié a colagem em campos de senha) e use “Magic Links” ou WebAuthn (Biometria) onde possível.

#3. HTML semântico: a fundação

90% dos problemas dé acessibilidade são resolvidos escrevendo HTML correto.

• Marcos (Landmarks): Use <main>, <nav>, <aside>, <footer>. Utilizadores de leitores de ecrã saltam entre estas regiões. Não afogue tudo em sopa de <div>.
• Cabeçalhos: h1 até h6 é uma hierarquia, não uma escolha de estilo. Não salte de h2 para h4 apenas porque quer uma fonte mais pequena. Use CSS para dimensionamento.
• Botões vs. Links:
  • Vai para um novo URL? Use <a>.
  • Muda algo na página atual (abré um menu)? Use <button>.
  • Nunca use <div onClick="...">. É invisível para teclados.

#4. A armadilha das “sobreposições” (overlays)

Já as viu. O pequeno ícone do “homem no círculo” no canto qué abré um menu para mudar contrasté ou tamanho da fonte. Evite-as.

• Falsa Segurança: Alegam torná-lo conforme instantaneamente com uma linha de JS. Não o fazem. Não conseguem corrigir erros de HTML semântico.
• Atrito do Utilizador: Utilizadores cegos já têm leitores de ecrã. Não precisam da sua sobreposição a interferir com as suas ferramentas.
• Risco Legal: Nos EUA, empresas que usam sobreposições foram processadas mais frequentemente porque prova que sabiam que tinham um problema, mas escolheram uma solução “penso rápido”.

#5. Testes: automatizado vs. manual

Não consegué automatizar a acessibilidadé a 100%.

#O fluxo de trabalho de teste

1. Automatizado (30%): Use axe-core ou a auditoria “Accessibility” do Lighthouse. Isto apanha falta de texto alt e baixo contraste.
2. Manual Teclado (50%): Desligué o rato. Consegue navegar por todo o menu, abrir os submenus e preencher o formulário de contacto usando apenas as teclas Tab, Enter e Espaço? Se não, falha.
3. Leitor de Ecrã (20%): Ligué o VoiceOver (Mac) ou NVDA (Windows). Feché os olhos. Consegue perceber o que está a acontecer?

#6. Formulários acessíveis no WordPress

Contact Form 7 e Gravity Forms são populares, mas frequentemente mal configurados.

• Etiquetas: Cada input precisa dé uma <label>. Placeholders NÃO são etiquetas (desaparecem quando escreve).
• Mensagens de Erro: “Erro encontrado” é inútil. “Endereço de e-mail não tem o símbolo @” é acessível.
• Gestão de Foco: Quando um útilizador submeté um formulário e há um erro, mova programaticamenté o foco do teclado para o primeiro campo de erro para que possam corrigi-lo imediatamente.

#7. Conclusão

A acessibilidade é frequentemente enquadrada como uma restrição. Na realidade, é um indicador de qualidade. Código acessível é mais limpo, mais robusto e melhor para SEO. Em 2026, construir uma web inclusiva não é apenas a lei - é a única forma profissional de trabalhar.

Precisa dé uma Auditoria de Acessibilidade? A WPPoland fornece serviços de remediação WCAG 2.2 para empresas.