O que o EAA e a WCAG 2.1 significam para sites WordPress
Desde 28 de junho de 2025, o Ato Europeu de Acessibilidade (EAA, Diretiva 2019/882) aplica-se a produtos e serviços colocados no mercado da UE por pessoa pela primeira vez. Para um site ou uma aplicação web, isso significa cumprir a WCAG 2.1 AA, uma norma do W3C que define como o conteúdo digital deve ser percetível, operável, compreensível e robusto. O EAA não especifica os critérios de sucesso da WCAG diretamente; remete para a norma europeia harmonizada EN 301 549, que atualmente incorpora a WCAG 2.1 nível AA. A WCAG 2.2 é hoje a recomendação atual do W3C, mas o piso legal que a maioria dos sites WordPress tem de cumprir hoje continua a ser a 2.1 AA - e é precisamente por isso que vale a pena compreendê-la nos seus próprios termos antes de avançar.
Este artigo é o ponto de partida. Explica quem está realmente abrangido, quais isenções se sustentam e quais não, como é a WCAG 2.1 AA num projeto WordPress real, e para onde ir a partir daqui. Saiba mais sobre os serviços de desenvolvimento WordPress da WPPoland se precisar de uma equipa que constrói projetos acessíveis, e não apenas os auditoria.
Dois números explicam por que este não é um tema de nicho. Cerca de 15% da população da UE vive com alguma forma de deficiência, e uma parcela muito maior beneficia de forma situacional: pessoas mais velhas, alguém com uma lesão temporária, qualquer pessoa a usar um ecrã pequeno sob luz solar intensa. O trabalho de acessibilidade também se sobrepõe fortemente aos fundamentos de SEO - estrutura semântica, texto alternativo descritivo e markup limpo ajudam tanto os motores de busca e os motores de resposta de IA como as tecnologias de apoio. Ambos os fios conduzem o resto deste guia.
Datas-chave e quem está abrangido
A data de aplicação do EAA é fixa, mas “abrangido” não é uma resposta simples de sim ou não - depende da categoria do produto ou serviço, da data do contrato e do tipo de cliente servido. A tabela abaixo é o resumo prático; as nuances jurídicas em casos-limite pertencem a um advogado, não a um artigo de blogue.
| Prazo | O que abrange | Nuance B2C vs. B2B |
|---|---|---|
| 2025-06-28 | Os requisitos de acessibilidade do EAA aplicam-se a produtos e serviços colocados no mercado da UE por pessoa pela primeira vez: comércio eletrónico, banca de retalho, e-books, comunicações eletrónicas, serviços de acesso a serviços de comunicação social audiovisual e interfaces de transporte de passageiros (anexo I) | A categoria de comércio eletrónico é definida em torno de um contrato com consumidor (artigo 3(30)); outras categorias, como banca e comunicações eletrónicas, não têm essa mesma limitação a consumidores |
| 2025-06-28 a 2030-06-28 | Janela transitória: os contratos de prestação de serviços celebrados antes de 2025-06-28 podem continuar nos termos originais até esta data no máximo | Aplica-se independentemente do tipo de cliente - o que conta é a data do contrato, não se o comprador é consumidor ou empresa |
| Data de instalação + até 20 anos | Terminais de autoatendimento (multibancos, máquinas de bilhetes, quiosques de check-in) já instalados antes do prazo podem manter-se em serviço até ao fim da sua vida útil, com limite de 20 anos | Sobretudo uma questão de hardware para terminais físicos; raramente relevante para um projeto puramente WordPress, salvo se este controlar um quiosque numa loja física |
| Contínuo, por exercício fiscal | Reavaliação de micro empresa: se o número de trabalhadores ou o volume de negócios de um prestador de serviços exceder o limiar do artigo 4(5), a isenção deixa de se aplicar a partir desse exercício fiscal | Aplica-se apenas a prestadores de serviços - as obrigações do lado do produto nunca foram cobertas por esta isenção, seja qual for a dimensão |
| Datas nacionais de transposição | A maioria dos Estados-Membros transpôs a diretiva perto da data da UE - em Portugal, o Decreto-Lei n.º 82/2022 entrou em vigor a 7 de dezembro de 2022, produzindo efeitos plenos a partir de 28 de junho de 2025 - mas os organismos de fiscalização, as estruturas de coima e as regras da declaração de acessibilidade variam de país para país | Aplica-se ao mercado onde o produto ou serviço é colocado, não ao país de sede do operador |
A leitura prática: se um site WordPress vende a consumidores da UE, opera um checkout WooCommerce, ou presta um serviço numa das categorias do anexo I, o prazo já passou e a obrigação já está ativa agora, não é algo a planear para “mais tarde”.
Isenções e âmbito das micro empresas
Esta é a secção mais mal interpretada. “Somos pequenos, por isso estamos isentos” é uma suposição comum, e está errada com mais frequência do que certa. A Diretiva 2019/882 define várias exceções estreitas, não um passe geral para pequenas empresas.
| Isenção | Quem a pode invocar | Condições | O que NÃO cobre |
|---|---|---|---|
| Isenção de micro empresa (artigo 4(5)) | Empresas com menos de 10 trabalhadores E volume de negócios anual ou balanço total inferior a 2 milhões de EUR | Ambas as condições têm de ser cumpridas simultaneamente; a isenção perde-se a partir do exercício fiscal em que qualquer um dos limiares é excedido | Isenta apenas serviços. As obrigações de fabricação, importação ou distribuição de produtos aplicam-se independentemente da dimensão da empresa |
| Encargo desproporcionado (artigo 14, anexo VI) | Qualquer operador económico, de qualquer dimensão | Exige uma avaliação documentada segundo os critérios do anexo VI, ponderando custo face ao benefício para os utilizadores; deve ser renovada pelo menos de cinco em cinco anos e apresentada às autoridades a pedido | Não é uma isenção geral - o operador continua obrigado a aplicar todos os requisitos que não se demonstre serem desproporcionados |
| Alteração fundamental (artigo 14) | Qualquer operador económico, de qualquer dimensão | Aplica-se apenas quando cumprir um requisito alteraria fundamentalmente a natureza do produto ou serviço | Raramente aplicável a funcionalidades típicas do WordPress (navegação, formulários, conteúdo); mais relevante para hardware especializado ou software feito por medida |
| Contratos de serviços pré-existentes (artigo 32) | Qualquer dimensão | Contratos de prestação de serviços celebrados antes de 2025-06-28 podem continuar nos termos originais até 2030-06-28 no máximo | Não se estende a novos contratos assinados após o prazo, mesmo com um cliente já existente |
| Terminais de autoatendimento em uso (artigo 32) | Qualquer dimensão, tipicamente operadores de hardware | Terminais já instalados antes do prazo podem continuar até ao fim da sua vida útil, com limite de 20 anos | Não se aplica a novos terminais comprados ou instalados após o prazo |
| Conteúdos pré-gravados publicados antes de 28 de junho de 2025 (artigo 2(4)) | Qualquer dimensão | Os conteúdos temporais (áudio/vídeo) publicados antes do prazo estão fora do âmbito retroativamente | Novos conteúdos temporais publicados após o prazo têm de cumprir os requisitos desde o primeiro dia |
Um caso real de delimitação de âmbito, explicado passo a passo. Considere uma loja WooCommerce com quatro trabalhadores e volume de negócios bem abaixo dos 2 milhões de EUR, que vende diretamente a consumidores. Ao abrigo do artigo 4(5), é uma micro empresa de serviços, pelo que as obrigações de acessibilidade para o próprio serviço de compra e checkout não se lhe aplicam. Essa isenção termina no momento em que a loja contrata o quinto a décimo trabalhador e ultrapassa dez, ou o volume de negócios passa os 2 milhões de EUR - a diretiva em si não prevê nenhum período de carência, por isso a suposição de planeamento mais segura é perder a isenção a partir do exercício fiscal em que o limiar é excedido, e não a partir de uma data de renovação posterior.
Agora mude um facto: a mesma loja de quatro pessoas, mas a operar como fornecedor grossista ao abrigo de um contrato negociado com uma empresa maior, sem qualquer checkout direto ao consumidor. Aqui acontecem duas coisas distintas, não uma. Primeiro, a categoria de comércio eletrónico no EAA está definida em torno da celebração de um contrato com consumidor (artigo 3(30), considerando 42) - um canal de venda exclusivamente B2B pode ficar fora dessa categoria só por essa razão, independentemente da isenção de micro empresa. Segundo, e esta é a parte que mais confunde: estar fora da obrigação de comércio eletrónico do próprio EAA não significa que a loja fica livre de requisitos de acessibilidade nessa relação. Se o comprador maior estiver ele próprio sujeito ao EAA, ao NIS2 ou a cláusulas de acessibilidade em contratação pública, o seu próprio programa de conformidade pode exigir contratualmente ferramentas de fornecedores conformes com a WCAG, independentemente de o fornecedor ser uma micro empresa ou estar fora da categoria de comércio eletrónico no direito da UE. A isenção do EAA protege contra a fiscalização do próprio EAA; não faz nada contra uma cláusula contratual de acessibilidade de um cliente.
Em Portugal, isto tem uma data e um enquadramento concretos: o Decreto-Lei n.º 82/2022, de 6 de dezembro, que transpõe a Diretiva 2019/882, entrou em vigor a 7 de dezembro de 2022, com a Portaria n.º 220/2023, de 20 de julho, a definir os requisitos de acessibilidade e os critérios para avaliar o caráter desproporcionado de um encargo. Os efeitos plenos aplicam-se desde 28 de junho de 2025 aos produtos colocados no mercado e aos serviços prestados a consumidores a partir dessa data, com um regime transitório até 2030 para contratos e instalações pré-existentes. O incumprimento pode originar coimas que, para pessoas colectivas, podem atingir 44 891,81 EUR por infração.
Isto é um enquadramento factual, não aconselhamento jurídico - se uma classificação concreta estiver em disputa, ou se a matemática da receita estiver próxima do limiar, confirme com um advogado antes de se apoiar numa isenção numa declaração pública ou numa resposta a um concurso.
A WCAG 2.1 AA na prática em WordPress
A WCAG 2.1 AA não é uma checklist que se marca uma vez; é um conjunto de critérios de sucesso testáveis que passam ou falham numa dada página, formulário ou componente. Quatro áreas representam a maior parte do trabalho real num site WordPress.
Operabilidade por teclado. Cada elemento interativo - menu, dropdown, modal, controlo de carrossel, botão de adicionar ao carrinho - tem de ser alcançável e operável apenas com Tab, Shift+Tab, Enter e as teclas de seta, com um indicador de foco visível em cada passo. É aqui que os construtores de páginas e os plugins de slider mais falham: uma apresentação de slides que só avança ao passar o rato, ou um mega-menu que abre ao hover mas nunca ao foco, bloqueia silenciosamente quem não pode usar um rato. A correção raramente é uma reescrita; normalmente é adicionar os manipuladores de eventos de teclado que faltam e um estilo :focus visível com contraste suficiente.
Contraste de cor. A WCAG 2.1 AA exige um rácio de contraste de pelo menos 4,5:1 para texto normal e 3:1 para texto grande em relação ao fundo. Paletas de marca desenhadas para um logótipo, não para texto corrido, são a falha mais comum: um cinzento claro sobre branco que parece elegante num mockup mas não cumpre o rácio para quem tem baixa visão. As falhas de contraste são baratas de corrigir depois de sinalizadas e caras de deixar sem correção, porque afetam todas as páginas que herdam as definições de tipografia do tema.
Formulários. Cada campo precisa de uma etiqueta associada de forma programática (<label for="id">, não apenas um texto de placeholder que desaparece ao focar), cada campo obrigatório precisa de anunciar que é obrigatório, e cada erro de validação precisa de ser descrito em texto junto ao campo, não apenas transmitido por uma borda vermelha. Os formulários de checkout e de contacto são as superfícies de maior risco aqui, porque um formulário que um utilizador de leitor de ecrã não consegue preencher é uma transação perdida, não apenas uma lacuna de conformidade.
Meios de comunicação. O vídeo precisa de legendas, o áudio precisa de transcrição, e cada imagem com significado precisa de texto alternativo que descreva a sua função ou conteúdo em vez de repetir o nome do ficheiro. As imagens decorativas (texturas de fundo, espaçadores) devem ter um alt="" vazio, para que a tecnologia de apoio as ignore em vez de anunciar ruído. Esta é uma das áreas em que a disciplina editorial importa tanto como o código: um programador pode construir um componente de imagem acessível, mas só um editor de conteúdo treinado mantém cada novo upload conforme.
Padrões comuns de falha em WordPress que vemos em auditorias
Alguns padrões repetem-se em quase todas as auditorias WordPress que fazemos, independentemente do tema ou nicho. A hierarquia de cabeçalhos falha primeiro: os construtores de páginas emitem frequentemente um <h1> ou <h2> para o texto hero de cada secção, independentemente do seu lugar real na estrutura do documento, pelo que uma página pode ter cinco tags h1 e nenhuma aninhação lógica de h2/h3 por baixo. Os utilizadores de leitores de ecrã navegam pela estrutura de cabeçalhos; uma estrutura quebrada torna a página muito mais difícil de percorrer do que os utilizadores com visão jamais notariam.
Os controlos apenas com ícone vêm depois - um botão de adicionar ao carrinho ou de pesquisa renderizado como um ícone nu sem texto visível e, frequentemente, sem aria-label também, deixa a tecnologia de apoio sem nada para anunciar. Os carrosséis com rotação automática são um terceiro caso muito próximo: sem controlo de pausa, sem navegação por teclado, e conteúdo que muda de quatro em quatro segundos independentemente de o leitor ter terminado de ler o slide atual.
O quarto padrão é mais discreto, mas igualmente consequente: banners de consentimento de cookies e modais de newsletter que capturam o foco do teclado. Um utilizador tabula para dentro do modal e nunca consegue tabular de volta para o conteúdo da página, porque o programador nunca ligou uma armadilha de foco que liberte com Escape ou com uma ação de fecho. É invisível numa passagem de QA orientada por rato e imediatamente óbvio na primeira vez que alguém testa apenas com teclado.
Nenhum destes é um bug exótico. São o resultado direto e repetível de plugins e temas populares usados da forma como a maioria dos sites os usa, o que é exatamente por que uma auditoria encontra o mesmo punhado de padrões em projetos não relacionados. O artigo sobre a pilha de conformidade 2026 percorre a lista de falhas plugin por plugin - construtores de páginas, templates WooCommerce, plugins de slider, plugins de formulário - com o critério de sucesso específico da WCAG que cada um viola e a correção concreta para cada caso.
Caminho de implementação: auditoria, correção, declaração, monitorização
Transformar “precisamos de cumprir” num resultado entregue e defensável segue o mesmo percurso de quatro etapas em todos os projetos que realizamos.
Auditoria. Comece com uma revisão delimitada da WCAG 2.1 AA sobre as jornadas reais dos clientes do site - página inicial, navegação, pesquisa, formulários e todos os passos de checkout críticos para a receita - não apenas uma verificação automática executada na página inicial. As ferramentas automatizadas (axe-core, Lighthouse, WAVE) detetam aproximadamente metade dos problemas reais; o resto precisa de um testador humano com teclado e leitor de ecrã.
Correção. Corrija pela ordem que protege primeiro as jornadas de maior valor: armadilhas de teclado e controlos de checkout sem etiqueta antes de ajustes cosméticos de contraste num link do rodapé. Uma única correção num componente partilhado - o estilo de foco do tema, o markup de etiquetas do plugin de formulário - resolve frequentemente dezenas de resultados repetidos de uma só vez, e é por isso que a correção deve visar primeiro os templates partilhados antes das páginas individuais.
Publique uma declaração de acessibilidade. Uma declaração que indique o nível de conformidade, quaisquer limitações conhecidas e um canal de contacto funcional para queixas de acessibilidade é obrigatória segundo várias leis nacionais de transposição (Portugal entre elas) e boa prática em todos os outros casos. Também dá às equipas de contratação algo concreto para o processo.
Monitorização. A acessibilidade degrada-se no momento em que uma nova atualização de plugin, um novo template de construtor de páginas, ou um novo editor de conteúdo entra sem formação. Uma verificação automatizada em CI apanha regressões em cada implementação; um reteste manual anual apanha o que a automação não consegue ver.
Para a pilha jurídica completa - os nove novos critérios de sucesso da WCAG 2.2, a relação entre o EAA e as leis nacionais, e os detalhes de correção ao nível de plugin - leia a pilha de conformidade 2026 para WordPress. Se quiser uma auditoria delimitada e escrita em vez de uma checklist de autoatendimento, a auditoria de conformidade UE para WordPress abrange a acessibilidade juntamente com a exposição a NIS2/DORA e ao AI Act numa única contratação, com orçamento individual baseado no âmbito real do seu site.
Por que a acessibilidade se sobrepõe ao SEO e à legibilidade para IA
A maior parte do trabalho técnico por detrás da WCAG 2.1 AA é também, separadamente, bom SEO e boa higiene para motores de resposta de IA, razão pela qual os orçamentos de acessibilidade são mais fáceis de justificar do que parecem à primeira vista. Uma hierarquia de cabeçalhos limpa e sequencial é exatamente o que os crawlers dos motores de busca e os modelos de linguagem que resumem conteúdo usam para entender o que uma página realmente trata; a mesma correção que ajuda um utilizador de leitor de ecrã a navegar numa página também ajuda um sistema de IA a extrair a secção certa ao responder a uma pergunta sobre ela. O texto alternativo descritivo faz um duplo serviço - como sinal de pesquisa de imagens e como descrição de reserva que qualquer sistema de IA a ler o markup da página pode usar quando a própria imagem não é processada.
O HTML semântico - elementos <button> e <nav> reais em vez de uma sopa de <div> estilizada, associações <label> corretas em formulários - produz markup que é simultaneamente acessível e mais fácil de analisar de forma fiável por sistemas automatizados, seja esse sistema um leitor de ecrã, um crawler de pesquisa, ou um pipeline de recuperação por detrás de um assistente de IA. Nada disto é coincidência: tanto a acessibilidade como a legibilidade por máquina convergem para o mesmo requisito subjacente, que é conteúdo que transporta a sua própria estrutura e significado no markup, em vez de depender inteiramente do estilo visual. Tratar um projeto de correção WCAG apenas como um custo legal ignora que uma boa parte do trabalho se paga a si mesmo em visibilidade orgânica.
Para onde ir a seguir
Pronto para passar da avaliação à ação? Contacte-nos para delimitar uma revisão de acessibilidade do seu site WordPress, ou comece pelo recurso que corresponde ao ponto em que está:
- Precisa do mapa jurídico e técnico mais profundo, incluindo a WCAG 2.2? Leia o artigo sobre a pilha de conformidade 2026.
- Precisa de uma auditoria delimitada e escrita com um backlog de correção que pode entregar a um programador? Consulte a auditoria de conformidade UE para WordPress.
- Precisa de uma equipa que construa a correção, e não apenas a diagnostique? Explore os nossos serviços de desenvolvimento WordPress.
