WCAG 2.2, BFSG e o Ato Europeu de Acessibilidade: a stack de conformidade WordPress para 2026
Três documentos definem o que um sítio WordPress tem de fazer em 2026 para ser legalmente acessível na União Europeia: as Web Content Accessibility Guidelines 2.2 do W3C, o Ato de Acessibilidade da UE (Diretiva 2019/882) e a Barrierefreiheitsstärkungsgesetz alemã. Não são intercambiáveis; empilham-se. Este artigo é o mapa de implementação.
A peça relaciona-se com o pilar de serviço headless WordPress onde se descreve a superfície técnica, e com a checklist padrões SEO para headless WordPress onde alguns padrões de acessibilidade também tocam o SEO.
TL;DR
- A WCAG 2.2 é a atual Recomendação do W3C, publicada a 2023-10-05.
- O Ato Europeu de Acessibilidade aplica-se a partir de 2025-06-28 em todos os Estados-Membros.
- A BFSG alemã implementa o EAA no direito federal na mesma data.
- As exceções para microempresas existem mas são mais restritas do que se assume.
- As coimas ao abrigo do parágrafo 37 da BFSG atingem o intervalo superior de cinco dígitos em euros.
As três camadas, por ordem
Três camadas legais e técnicas empilham-se para definir a obrigação do sítio:
Camada um, WCAG 2.2 (técnica). O conjunto de critérios de sucesso mensuráveis que definem conteúdo web acessível. Da autoria da Web Accessibility Initiative do W3C. A WCAG 2.2 foi publicada como Recomendação a 2023-10-05 e adiciona nove novos critérios de sucesso face à WCAG 2.1, incluindo aparência do foco, gestos de arrastar e ajuda consistente.
Camada dois, o Ato Europeu de Acessibilidade (UE). Diretiva 2019/882, adotada em 2019, aplicável a partir de 2025-06-28. Define que produtos e serviços têm de ser acessíveis e remete para a norma europeia EN 301 549, que incorpora a WCAG por referência. O EAA não diz literalmente “siga a WCAG 2.2”; remete para a norma harmonizada europeia, que atualmente incorpora a WCAG 2.1 nível AA. As transposições nacionais podem exigir a WCAG 2.2.
Camada três, transposição nacional (Estado-Membro). Cada Estado-Membro aprova a sua própria lei para transpor o EAA. A da Alemanha é a BFSG, em vigor na mesma data da aplicação do EAA. Outros Estados-Membros transpõem com nomes semelhantes e requisitos semelhantes (por vezes mais elevados). O sítio tem de cumprir a lei de transposição em cada mercado em que vende, não apenas no país de constituição.
A ordem importa. A WCAG é o limiar técnico. O EAA é o envelope legal ao nível da UE. A lei nacional é o instrumento local de aplicação. As auditorias seguem por esta ordem: técnica primeiro, legal depois, local em último.
O que a WCAG 2.2 efetivamente exige
A WCAG 2.2 tem 86 critérios de sucesso ao longo de 13 diretrizes sob 4 princípios (Percetível, Operável, Compreensível, Robusto). Três níveis: A, AA, AAA. O padrão legal e contratual é AA. AAA é aspiracional e nem sempre prático para sítios com muito conteúdo.
Os nove novos critérios da WCAG 2.2 face à WCAG 2.1:
- Aparência do foco (AA, nível AA apenas em 2.2)
- Foco não obscurecido mínimo (AA)
- Foco não obscurecido alargado (AAA)
- Gestos de arrastar (AA)
- Tamanho mínimo do alvo (AA, 24 by 24 CSS pixels)
- Ajuda consistente (A)
- Entrada redundante (A)
- Autenticação acessível mínima (AA)
- Autenticação acessível alargada (AAA)
Para um sítio WordPress que já visava WCAG 2.1 AA, o trabalho prático em 2026 é verificar os nove novos critérios, sendo o tamanho do alvo e os gestos de arrastar as lacunas mais comuns (ícones clicáveis pequenos, sliders apenas por arrastar).
EAA: âmbito, isenções, prazos
O EAA cobre uma lista definida de produtos e serviços colocados no mercado a partir de 2025-06-28. A lista relevante para a maioria dos operadores WordPress:
- Serviços bancários ao consumidor.
- Livros eletrónicos e software de leitura dedicado.
- Serviços de comunicações eletrónicas.
- Serviços de acesso a meios audiovisuais.
- Serviços de transporte de passageiros (interfaces web e móveis).
- Serviços de e-commerce (a categoria de captura para a maioria das lojas WooCommerce).
A diretiva define isenções para microempresas: menos de 10 trabalhadores E volume de negócios anual ou balanço total inferior a 2 milhões de EUR. Estas isenções aplicam-se a prestadores de serviços; o limiar para fabricantes de produtos é mais rigoroso. A leitura errada comum é “sítio pequeno, sem regras”; a regra real é “operador pequeno, obrigação mais restrita, isenção mais restrita”.
Período transitório: os contratos de serviço celebrados antes de 2025-06-28 podem continuar nos termos pré-EAA até, no máximo, 2030-06-28. Os terminais de autosserviço já em utilização podem continuar até ao fim da vida útil, com um teto rígido de 20 anos.
BFSG: a implementação alemã
A Alemanha aprovou a Barrierefreiheitsstärkungsgesetz (Lei de Reforço da Acessibilidade) para transpor o EAA. Entrou em vigor a 2025-06-28.
Três coisas que a BFSG acrescenta à base do EAA:
Primeiro, aplicação ao nível federal. A Bundesanstalt für Arbeitsschutz und Arbeitsmedizin e as autoridades federais de fiscalização do mercado supervisionam o cumprimento. As estruturas dos Estados-Membros variam; na Alemanha, a supervisão federal é o mecanismo.
Segundo, estrutura das coimas (parágrafo 37, BFSG). As sanções por não conformidade estão definidas no parágrafo 37 da BFSG. Tipos específicos de infrações atraem coimas no intervalo superior de cinco dígitos em euros por infração. A não conformidade repetida ou sistémica acumula-se.
Terceiro, requisito de declaração de acessibilidade. O sítio tem de publicar uma declaração de acessibilidade ligada a partir de um local descobrível (o rodapé é o convencional). A declaração indica o nível de conformidade, as exceções invocadas e um mecanismo de contacto para reclamações de acessibilidade.
Os operadores que vendem para a Alemanha sem registo alemão estão ainda sujeitos à BFSG quando os seus produtos ou serviços são colocados no mercado alemão. A defesa “não sou uma empresa alemã” não existe.
O que isto significa para um sítio WordPress
O trabalho de implementação divide-se em quatro colunas.
Tema e core. Escolha um tema marcado como accessibility-ready no WordPress.org e verifique-o face à WCAG 2.2 AA. Audite o painel WordPress, não apenas o front-end; a BFSG abrange também a interface utilizada por colaboradores se estiverem sujeitos a requisitos de emprego inclusivo. O core do WordPress está geralmente atento à acessibilidade (a equipa de Acessibilidade está ativa) mas plugins e código personalizado quebram regularmente o limiar.
Plugins. Audite o output front-end de cada plugin ativo. Padrões concretos de não conformidade que vemos auditoria após auditoria:
- Page builders (Elementor, Divi, WPBakery): emitem
<h1>para o texto hero em cada secção, quebrando a hierarquia de cabeçalhos. Falham WCAG 2.4.6 (Cabeçalhos e Rótulos) e 1.3.1 (Informação e Relações). Correção: sobrepor os níveis de cabeçalho ao nível do template do tema, ou migrar para o editor de blocos. - WooCommerce adicionar ao carrinho por defeito nos arquivos: apenas ícone com
aria-label, sem texto visível e sem indicador de foco visível. WCAG 2.4.7 (Foco Visível) e 2.5.8 (Tamanho Mínimo do Alvo, 24×24 píxeis CSS em WCAG 2.2). Correção: aumentar a área clicável para 24×24, anel de foco visível com contraste 3:1, restaurar texto visível onde possível. - Plugins de slideshow (Slick, Owl Carousel, MetaSlider, Smart Slider): sem suporte para teclas de seta, sem controlo de pausa nos slides em rotação automática. Falham WCAG 2.2.2 (Pausar, Parar, Ocultar) e 2.1.1 (Teclado). Correção: substituir por uma grelha estática de imagens onde possível; se necessário, adicionar botões visíveis de pausa e anterior/seguinte com rótulos adequados.
- Plugins de formulários (Contact Form 7, Gravity Forms, Ninja Forms): omitem associações
<label for>, usam o placeholder como único rótulo. Falham WCAG 1.3.1 e 3.3.2 (Rótulos ou Instruções). Correção:<label for="id">explícito, mensagens de erro viaaria-describedby, campos obrigatórios comaria-required="true".
Audite também o painel se for usado por pessoal não programador.
Conteúdo e disciplina editorial. A aplicação da WCAG ao nível editorial requer regras permanentes: cada imagem precisa de texto alternativo, cada hiperligação precisa de texto descritivo (não “clique aqui”), cada hierarquia de cabeçalhos é sequencial, cada vídeo tem legendas, cada PDF embebido numa página é ele próprio testado. O CMS torna a conformidade técnica possível; a equipa editorial faz com que efetivamente aconteça.
Declaração de acessibilidade e mecanismo de reclamação. A declaração é obrigatória na Alemanha ao abrigo da BFSG. O mecanismo de reclamação (um e-mail de contacto ou formulário) tem de ser funcional, não vestigial. As reclamações sobre acessibilidade têm de ser confirmadas e tratadas em tempo razoável.
Por que o headless WordPress não é automaticamente acessível
Uma construção headless WordPress com um front Astro ou Next.js não herda acessibilidade da origem WordPress. O framework de front-end é responsável pelo HTML renderizado, pelo modelo de interação por teclado, pela gestão do foco e pela semântica ARIA. Escolher o framework certo ajuda (tanto Astro como Next.js têm comunidades de acessibilidade fortes) mas o trabalho tem de ser feito explicitamente.
Conforme o nosso o nosso Tech Radar (Q3 2026), Astro 5+ e Next.js 15 estão ambos no anel Adopt. Nenhum é automaticamente conforme com a WCAG 2.2. A auditoria de acessibilidade é uma linha de trabalho separada da escolha de framework.
A construção headless oferece uma coisa: controlo por rota sobre o HTML renderizado, o que torna os patches de acessibilidade aterráveis e previsíveis. Uma construção WordPress monolítica mediada por um page builder pesado é mais difícil de remediar quando o builder é a fonte da marcação inacessível.
Cadência de auditoria e ferramentas
Duas auditorias, duas cadências:
Automatizada, em cada execução de CI. axe-core ou pa11y a correr contra uma amostra representativa de rotas. Quebra a build em qualquer nova violação. Apanha cerca de metade dos problemas WCAG; falha a metade que requer juízo humano (qualidade do alt-text, intenção da ordem de foco, intenção dos landmarks ARIA).
Manual, anualmente mais em alterações maiores. Testador de acessibilidade treinado a executar uma auditoria WCAG 2.2 AA completa com testes de tecnologia assistiva (leitor de ecrã, controlo por voz, apenas teclado). O resultado é um relatório de lacunas associado a critérios de sucesso específicos.
Um sítio que execute apenas a auditoria automatizada não está em conformidade com a WCAG 2.2 AA. Um sítio que execute apenas a auditoria manual deriva entre revisões anuais. Ambos são necessários.
Onde isto se enquadra
Este pilar ancora-se no cluster do serviço headless WordPress como dimensão de conformidade. Para escolha de framework, ver a matriz de decisão Next.js vs Astro. Para riscos de migração SEO (alguns padrões de acessibilidade afetam também o SEO, em particular a hierarquia de cabeçalhos e o texto das hiperligações), ver a checklist de padrões SEO. Para conformidade NIS2 e DORA, que aparecem frequentemente no mesmo scorecard de aquisição, ver o artigo dedicado a NIS2 e DORA em WordPress.
