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”. É semelhante 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 exatamente o que mudou em 2026 e como garantir que o seu tema não está a infringir a lei.
1. O EAA: porque 2025 foi o ponto de viragem
Anteriormente, as leis de acessibilidade aplicavam-se principalmente ao Setor Público (Governo/Universidades). O EAA expandiu isto para E-commerce, Banca, Transportes e eBooks.
- Âmbito: Se vende 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 sobre 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 utilizador sabe que está em algum lugar, mas não consegue ver onde.
- A Correção: Use CSS
scroll-padding-topno elementohtmlpara garantir que 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 force os utilizadores a resolver puzzles (CAPTCHAs) ou memorizar senhas sem ajuda.
- O Impacto no WordPress: Suporte gestores de senhas (não bloqueie 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 de 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:
h1atéh6é uma hierarquia, não uma escolha de estilo. Não salte deh2parah4apenas 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 (abre um menu)? Use
<button>. - Nunca use
<div onClick="...">. É invisível para teclados.
- Vai para um novo URL? Use
4. A armadilha das “sobreposições” (overlays)
Já as viu. O pequeno ícone do “homem no círculo” no canto que abre um menu para mudar contraste 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 consegue automatizar a acessibilidade a 100%.
O fluxo de trabalho de teste
- Automatizado (30%): Use
axe-coreou a auditoria “Accessibility” do Lighthouse. Isto apanha falta de textoalte baixo contraste. - Manual Teclado (50%): Desligue 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.
- Leitor de Ecrã (20%): Ligue o VoiceOver (Mac) ou NVDA (Windows). Feche 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 de 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 utilizador submete um formulário e há um erro, mova programaticamente 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 de uma Auditoria de Acessibilidade? A WPPoland fornece serviços de remediação WCAG 2.2 para empresas.
