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

Desde 28 de junho de 2025, os Estados-Membros da UE aplicam as leis que transpõem o Ato Europeu de Acessibilidade (EAA), a Diretiva (UE) 2019/882. Em Portugal, essa lei é o Decreto-Lei 82/2022, de 6 de dezembro. Para muitas lojas online, serviços bancários e plataformas de transporte, a acessibilidade web passou de recomendação a obrigação legal.

Para programadores WordPress e proprietários de sites, a meta técnica prática é o WCAG 2.2 nível AA. Este guia mostra que critérios do WCAG 2.2 mais falham nos temas WordPress, o que a diretiva e a lei portuguesa exigem de facto e como testar o site antes de cada lançamento. Não substitui aconselhamento jurídico sobre o seu caso.

Fontes oficiais: a Recomendação WCAG 2.2, o texto da Diretiva 2019/882, a Portaria 220/2023 e o manual de acessibilidade do WordPress.

#A quem se aplica o Ato Europeu de Acessibilidade

Antes, as leis de acessibilidade aplicavam-se sobretudo ao setor público. O EAA estende requisitos ao setor privado, mas só a categorias concretas. O artigo 2.º, n.º 2, da diretiva enumera os serviços prestados a consumidores depois de 28 de junho de 2025:

• serviços de comunicações eletrónicas;
• serviços que dão acesso a serviços de comunicação social audiovisual;
• elementos dos serviços de transporte aéreo, rodoviário, ferroviário e por vias navegáveis (sites, aplicações móveis, bilhetes eletrónicos, informação de viagem);
• serviços bancários para consumidores;
• livros eletrónicos e o respetivo software;
• serviços de comércio eletrónico.

A diretiva define comércio eletrónico como os serviços prestados à distância, através de sites e aplicações móveis, a pedido individual de um consumidor e com vista à celebração de um contrato de consumo. Uma loja WooCommerce que vende a consumidores na UE cabe nessa definição. O site de uma consultora que só trabalha com empresas, sem contratos online com consumidores, não consta da lista.

#Que exceções prevê a diretiva

• Microempresas que prestam serviços (artigo 4.º, n.º 5) estão isentas dos requisitos de acessibilidade dos serviços. A diretiva define microempresa como a que emprega menos de 10 pessoas e tem um volume de negócios anual ou um balanço total anual que não excede 2 milhões de euros. A isenção não abrange produtos.
• Alteração fundamental e encargo desproporcionado (artigo 14.º): os requisitos aplicam-se apenas na medida em que não alterem a natureza básica do serviço nem imponham um encargo desproporcionado. O operador tem de fazer essa avaliação, documentá-la e guardar os resultados durante cinco anos.
• Conteúdos excluídos (artigo 2.º, n.º 4): por exemplo, conteúdos multimédia pré-gravados e ficheiros de escritório publicados antes de 28 de junho de 2025, e conteúdos de terceiros que o operador não financia, não desenvolve nem controla.

#Prazos da diretiva

A diretiva não fixa coimas. O artigo 30.º exige a cada Estado sanções efetivas, proporcionadas e dissuasivas, que tenham em conta a gravidade do incumprimento, o número de produtos ou serviços afetados e o número de pessoas prejudicadas.

#Como Portugal transpôs o EAA

O Decreto-Lei 82/2022, de 6 de dezembro, transpõe a Diretiva 2019/882 para a ordem jurídica portuguesa. As suas medidas produzem efeitos a partir de 28 de junho de 2025.

O artigo 37.º do decreto-lei previa uma regulamentação posterior. Essa regulamentação é a Portaria 220/2023, de 20 de julho, que define os requisitos de acessibilidade dos produtos e serviços e os critérios para avaliar o caráter desproporcionado de um encargo. É o documento a consultar quando quiser invocar o artigo 14.º da diretiva.

Não reproduzimos aqui os montantes das coimas, porque não os confirmámos no texto oficial. Consulte a versão consolidada do decreto-lei no Diário da República antes de os usar numa análise de risco.

Se vende para outros países da UE, cada Estado tem a sua lei. Veja a comparação de coimas e obrigações por país. Resumo de cinco mercados:

#Em que norma técnica se apoia o EAA

O EAA não menciona o WCAG. O anexo I exige que sites e aplicações móveis sejam acessíveis de forma coerente e adequada, tornando-os percetíveis, operáveis, compreensíveis e robustos: os mesmos quatro princípios que estruturam o WCAG. O artigo 15.º acrescenta uma presunção de conformidade para serviços que cumpram normas harmonizadas publicadas no Jornal Oficial.

O WordPress já escolheu a versão. As normas de código de acessibilidade dizem que o código integrado no ecossistema WordPress, incluindo o núcleo, os sites WordPress.org e os plugins oficiais, deve cumprir o WCAG 2.2 nível AA, e recomendam o ATAG 2.0 nas novas interfaces de edição.

#O que mudou entre o WCAG 2.1 e o WCAG 2.2

O WCAG 2.2 tornou-se Recomendação do W3C a 5 de outubro de 2023 e a edição em vigor tem data de 12 de dezembro de 2024. Segundo a página What’s new in WCAG 2.2, acrescenta nove critérios de sucesso:

Para uma meta AA contam seis. Os três critérios AAA continuam úteis como referência de design.

#Porque é que o WCAG 2.2 removeu o critério 4.1.1

O critério 4.1.1 Análise sintática (Parsing) foi removido por estar obsoleto. O W3C explica que as tecnologias de apoio já não analisam o HTML por conta própria, apoiam-se no navegador, e os problemas que antes falhavam o 4.1.1 falham hoje o 1.3.1 Informação e relações ou o 4.1.2 Nome, função, valor. Regras nacionais baseadas no WCAG 2.1 podem continuar a exigi-lo.

#Como cumprir os novos critérios do WCAG 2.2 num tema WordPress

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

Quando um componente recebe o foco do teclado, não pode ficar totalmente escondido por conteúdo criado pelo autor. A versão AAA (2.4.12) exige que nenhuma parte fique escondida.

• O problema: navega com Tab pela página. Um elemento recebe o foco, mas o cabeçalho fixo ou o banner de cookies tapa-o. O utilizador sabe que o foco está algures, mas não vê onde.
• A correção: use scroll-padding-top no elemento html para que os elementos focados se desloquem para a área visível abaixo do cabeçalho fixo.

html {
  scroll-padding-top: 80px; /* Altura do cabeçalho fixo */
}

Mantenha o banner de cookies na ordem de tabulação, com um botão de fechar visível, e evite overflow: hidden em contentores que cortem o contorno do foco.

#2.4.7 Foco visível e 2.4.13 Aparência do foco

Muitos temas removem o outline por estética e não o substituem. Isso falha o 2.4.7 Foco visível, que continua a ser nível AA. O critério 2.4.13 (AAA) dá uma meta mensurável: a área do indicador deve ser pelo menos igual à de um contorno de 2 píxeis CSS em volta do componente sem foco, com contraste mínimo de 3:1 entre os mesmos píxeis no estado com e sem foco.

Em temas de blocos, defina o estilo :focus-visible no theme.json ou numa folha de estilos pequena carregada no editor e no site.

#2.5.7 Movimentos de arrastamento (AA)

Qualquer função operada por arrastamento tem de poder ser feita com um único ponteiro sem arrastar, salvo se o arrastamento for essencial. Isto afeta menus ordenáveis, controlos deslizantes e construtores do tipo quadro. O Gutenberg oferece alternativas para muitas interações; blocos próprios que só respondem a eventos de arrastamento precisam de botões ou campos equivalentes.

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

Os alvos de ponteiro devem ter pelo menos 24 por 24 píxeis CSS. O critério admite cinco exceções:

• Espaçamento: um alvo menor passa se um círculo com 24 píxeis CSS de diâmetro centrado nele não intersetar outro alvo nem o círculo de outro alvo pequeno.
• Equivalente: a mesma função está disponível noutro controlo da página que cumpre o tamanho.
• Em linha: o alvo está numa frase ou o tamanho é limitado pela altura de linha do texto.
• Controlo do agente de utilizador: o navegador define o tamanho e o autor não o altera.
• Essencial: uma apresentação específica é essencial ou exigida por lei.

Na prática, verifique os pequenos botões «X» dos popups, as setas de paginação, as filas de ícones sociais, as caixas de verificação e os controlos de carrossel. Com padding, min-width e min-height a área de toque cresce sem alterar o ícone.

#3.2.6 Ajuda consistente (A)

Se os mecanismos de ajuda se repetem em várias páginas, têm de aparecer na mesma ordem relativa face ao resto do conteúdo. O critério abrange dados de contacto humano, um mecanismo de contacto humano, uma opção de autoajuda e um mecanismo de contacto totalmente automatizado, como um chatbot. No WordPress, mantenha o link de suporte ou o widget de chat na mesma parte do modelo em todas as páginas.

#3.3.7 Introdução redundante (A)

A informação que o utilizador já introduziu no mesmo processo tem de ser preenchida automaticamente ou ficar disponível para seleção. As exceções são quando voltar a introduzi-la é essencial, necessário por segurança ou quando o valor anterior deixou de ser válido. No WooCommerce, a opção «morada de faturação igual à de envio» cobre o caso mais comum.

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

Nenhum passo do início de sessão pode exigir um teste de função cognitiva, como memorizar uma palavra-passe ou resolver um puzzle, salvo se esse passo oferecer pelo menos uma destas opções: um método alternativo sem esse teste, um mecanismo de ajuda (por exemplo um gestor de palavras-passe), um teste de reconhecimento de objetos ou a identificação de conteúdo não textual fornecido pelo próprio utilizador. A versão AAA (3.3.9) elimina as duas últimas exceções.

• O impacto no WordPress: não bloqueie a colagem em campos de palavra-passe e de códigos de utilização única, para que os gestores de palavras-passe funcionem. Use links mágicos por e-mail ou WebAuthn e passkeys quando o produto o permitir. Reveja scripts de plugins de membros que bloqueiam a colagem e barreiras antibot de terceiros.

#Como usar HTML semântico para a acessibilidade

A maioria das correções duradouras é HTML correto, sem plugins nem sobreposições.

• Marcos (landmarks): use <main>, <nav>, <aside>, <footer>. Os utilizadores de leitores de ecrã saltam entre estas regiões. Não afogue tudo numa sopa de <div>.
• Títulos: h1 até h6 é uma hierarquia, não uma escolha de estilo. Não salte de h2 para h4 só porque quer uma letra mais pequena. Use CSS para o tamanho.
• Botões e links:
  • Vai para um novo URL? Use <a>.
  • Muda algo na página atual (abre um menu)? Use <button>.
  • Nunca use <div onClick="...">. Não recebe foco do teclado e os leitores de ecrã não o anunciam como elemento interativo.
• Imagens: imagens com conteúdo recebem alt, imagens decorativas recebem alt vazio.

O ARIA complementa o HTML quando o HTML nativo não chega. Um <button> real é melhor do que role="button" num span.

#Que blocos do Gutenberg mais falham nos testes de acessibilidade

Os blocos do núcleo e o editor de blocos melhoraram o suporte de teclado ao longo de várias versões. Isso não torna acessível cada página publicada. Padrões que continuam a falhar:

• Blocos Grupo e Capa com texto de baixo contraste sobre imagens. Verifique o contraste depois de aplicar a paleta do tema.
• Bloco Navegação com megamenus que só abrem ao passar o rato. Acrescente abertura com clique ou Enter e fecho com Escape.
• Blocos próprios com widgets interativos sem elementos focáveis ou com aria-expanded errado.
• Padrões de marketplaces com títulos mal aninhados ou h1 duplicado.

Para autores: confirme a ordem dos títulos na vista de lista antes de publicar e use os blocos nativos Imagem e Galeria para manter o campo alt editável. Para quem desenvolve temas: teste a tela do editor do site e o HTML publicado, porque nem sempre coincidem.

#Como testar temas clássicos e temas de blocos

Os temas PHP clássicos falham quando os modelos têm menus inacessíveis fixos no código ou quando o style.css remove os estilos de foco. Configurações híbridas (tema clássico com partes de modelo em blocos) precisam dos mesmos testes de elementos fixos e foco nos modelos PHP e HTML.

Os temas de blocos (theme.json, partes de modelo) centralizam cores e tipografia. Isso ajuda no contraste se a paleta tiver rácios AA. Também facilita publicar um cabeçalho fixo global que viola o 2.4.11 em todas as páginas: a correção faz-se uma vez, na parte de modelo do cabeçalho.

O WooCommerce e os plugins de formulários assentam no tema. Checkout, conta e formulário de contacto precisam cada um do seu teste com teclado.

#O que exige a etiqueta accessibility-ready a um tema WordPress

O diretório de temas do WordPress.org só atribui a etiqueta accessibility-ready depois de uma revisão adicional. O manual da equipa de temas enumera 18 requisitos obrigatórios:

1. link para saltar para o conteúdo;
2. marcos com funções e nomes significativos;
3. navegação completa por teclado;
4. controlos com nome, função e estado acessíveis;
5. campos de formulário com etiqueta;
6. títulos com estrutura significativa;
7. links sublinhados no texto;
8. sem textos de link ambíguos;
9. contraste suficiente de texto e controlos;
10. texto alternativo em imagens e gráficos;
11. áudio, vídeo e animações acessíveis;
12. suporte para refluxo, ampliação e alteração do espaçamento do texto;
13. sem mudanças de contexto inesperadas;
14. sem links que abram novas janelas ou separadores sem aviso;
15. conteúdo acessível ao passar o rato ou ao receber foco;
16. declaração de acessibilidade;
17. não recomendar nem exigir plugins inacessíveis;
18. suporte de texto só para leitores de ecrã.

A etiqueta não certifica o seu site, porque plugins, padrões e conteúdo podem estragar um tema revisto. Dá uma base revista e uma lista de verificação para temas próprios.

#As sobreposições (overlays) de acessibilidade funcionam

Já as viu: o pequeno ícone de uma pessoa num círculo, no canto, que abre um menu para mudar o contraste ou o tamanho da letra.

Não as use como caminho para a conformidade.

• Falsa segurança: prometem conformidade com uma linha de JavaScript, mas não corrigem o HTML semântico do tema.
• Atrito para o utilizador: os utilizadores cegos já têm os leitores de ecrã configurados. Uma sobreposição pode entrar em conflito com essas ferramentas.
• Risco regulatório: a 22 de abril de 2025, a Comissão Federal de Comércio dos Estados Unidos (FTC) aprovou uma ordem definitiva que obriga a accessiBe a pagar um milhão de dólares. A FTC considerou falsas, enganosas ou sem fundamento as afirmações de que o widget tornava qualquer site conforme com o WCAG.

A única solução real é código acessível desde o início ou a correção do código existente.

#Como testar a acessibilidade antes de cada lançamento

Não consegue automatizar a acessibilidade a 100 %. As ferramentas automáticas são o primeiro passo, mas não detetam a maioria das armadilhas de teclado nem muitos casos de foco escondido.

#Teste de acessibilidade em três passos

1. Automatizado: use o axe-core ou a auditoria de acessibilidade do Lighthouse na página inicial, arquivo, artigo, pesquisa, formulário e checkout. Isto apanha falta de texto alt, baixo contraste e atributos ARIA errados, e pode correr em cada implementação no pipeline de CI.
2. Manual com teclado: desligue o rato. Consegue percorrer o menu, abrir os submenus e enviar o formulário de contacto usando apenas Tab, Enter e Espaço? Confirme que o foco é visível, que a ordem de tabulação é lógica e que os modais fecham com Escape.
3. Leitor de ecrã: ligue o VoiceOver (Mac) ou o NVDA (Windows) no mesmo percurso. Os formulários têm etiquetas descritivas e as mudanças de estado são anunciadas?

Repita os testes depois de atualizar o tema, de atualizar plugins que mudam a marcação e de editar modelos no editor do site. Muitas regressões chegam com um commit de CSS que define outline: none. Descrevemos também um fluxo prático de auditoria de acessibilidade baseado nestes passos.

Ferramentas que encaixam num fluxo WordPress: axe DevTools no navegador, WAVE da WebAIM, Pa11y na linha de comandos em CI e o plugin Accessibility Checker no editor.

#Como criar formulários acessíveis no WordPress

Contact Form 7, Gravity Forms e formulários próprios seguem as mesmas regras.

• Etiquetas: cada campo precisa de uma <label> associada programaticamente. Os placeholders não são etiquetas, desaparecem quando escreve.
• Mensagens de erro: «Erro encontrado» é inútil. «O endereço de e-mail não tem o símbolo @» é acessível. Associe a mensagem ao campo com aria-describedby.
• Gestão de foco: quando o formulário volta com erros, mova o foco do teclado para o primeiro campo inválido ou para um resumo com links para os campos.
• Campos obrigatórios: use o atributo required, não apenas um asterisco vermelho.
• Colagem: não bloqueie a colagem em campos de palavra-passe e de códigos de utilização única.

#Como tornar acessíveis o WooCommerce e o WordPress headless

O checkout do WooCommerce tem de funcionar do início ao fim com teclado: adicionar ao carrinho, alterar quantidades, aplicar um cupão, pagar e ler a confirmação. As comparações de produtos precisam de <table> real com <th> e scope. Os avisos do carrinho devem usar aria-live="polite", para que o leitor de ecrã anuncie a alteração sem interromper o utilizador.

Os frontends headless em React, Next.js ou Astro têm um problema que os temas clássicos não têm: mudar de rota numa aplicação de página única não recarrega a página. Depois de cada mudança de rota, mova o foco para o conteúdo principal, anuncie o novo título através de uma região aria-live e atualize o document.title. A renderização no servidor ajuda, porque o conteúdo está no HTML inicial antes de o JavaScript correr.

#Lista de verificação WCAG 2.2 AA para sites WordPress

• Estilos :focus-visible visíveis em todo o tema, nunca tapados pelo cabeçalho ou por banners.
• Alvos de 24 por 24 píxeis CSS ou com o espaçamento que o 2.5.8 permite.
• Uma alternativa sem arrastamento para cada controlo arrastável.
• Ajuda na mesma ordem em todos os modelos.
• Sem introdução repetida dos mesmos dados no mesmo processo.
• Início de sessão que aceita palavras-passe e códigos colados.
• Avaliação do artigo 14.º documentada, segundo os critérios da Portaria 220/2023, se invocar encargo desproporcionado.

Se precisa de uma auditoria de acessibilidade WCAG de modelos, blocos ou do checkout, a WPPoland começa por uma auditoria documentada dos modelos que publica de facto, não pela instalação de uma sobreposição. Uma avaliação mais ampla das obrigações europeias está descrita na auditoria de conformidade UE.