European Accessibility Act (EAA) e WordPress: o que muda a sério e o que fazer já

O European Accessibility Act (EAA) deixou de ser uma data no calendário: já está em vigor. Desde 28 de junho de 2025, empresas que disponibilizam websites e serviços digitais a consumidores na União Europeia têm de garantir que essas experiências são acessíveis.

Para quem trabalha com WordPress – donos de sites, freelancers, agências e também quem desenvolve temas e plugins – isto marca uma mudança estrutural: a pergunta já não é se vale a pena investir em acessibilidade, mas como operacionalizar a conformidade (e como manter isso no dia a dia, sem depender de ações pontuais).

A seguir, organizo o essencial: a cronologia e as “janelas” de transição, como funciona a fiscalização, quais os riscos reais de não conformidade e um plano prático com cinco passos para começares a corrigir o teu site WordPress agora.

Cronologia do EAA: o que é imediato e o que é faseado

Apesar de o EAA já estar ativo, a implementação não é um botão on/off. Existe uma abordagem faseada que distingue serviços/produtos novos de serviços existentes.

Novos produtos e serviços: conformidade desde o primeiro dia

A regra é direta: qualquer novo produto ou serviço lançado após 28 de junho de 2025 tem de ser acessível no lançamento.

• Se vais lançar um novo site de e-commerce em outubro, ele tem de cumprir os requisitos de acessibilidade imediatamente.
• Se vais lançar um plugin novo em novembro, ele tem de ser acessível “out of the box” (pronto a usar, sem exigir adaptações por parte do utilizador).

Não há período de adaptação para novas ofertas. Isto força a acessibilidade a entrar no core de planeamento, design e desenvolvimento, em vez de aparecer no fim como “checklist”. Na prática, para profissionais de WordPress, passa a ser um requisito fundamental ao lado de segurança e responsividade mobile.

Serviços existentes: período de transição (até 28 de junho de 2030)

Para serviços que já existiam antes de 28 de junho de 2025, existe um período de transição: a conformidade total deve estar concluída até 28 de junho de 2030.

Só que chamar-lhe “período de graça” pode induzir em erro. Não é um passe livre para adiar; é uma janela para executar melhorias de forma sustentada e com evidência de progresso.

1. Esperar coloca-te em desvantagem. Sites acessíveis alcançam mais utilizadores, tendem a ter melhor performance em pesquisa e reforçam confiança na marca. Adiar significa perder esses ganhos durante anos.
2. Queixas podem desencadear ação mesmo antes de 2030. Se uma pessoa com deficiência apresentar uma queixa em 2026, as autoridades não vão “esperar até 2030”. Vão investigar e esperar ver um plano claro e sinais de melhoria. Ter um roadmap, progresso documentado e compromisso explícito é a melhor defesa. Não fazer nada aumenta o risco.
3. Atualizações grandes podem “resetar” o prazo. O período de transição pode deixar de se aplicar se fizeres “modificações substanciais” no serviço. O que é substancial pode ser zona cinzenta, mas um redesign completo, uma grande reformulação do e-commerce ou uma mudança relevante de funcionalidade pode ser interpretada como um serviço “novo”. Nesse caso, a exigência pode passar a ser conformidade imediata, e não em 2030.

Em resumo: 2030 é a data-limite máxima, não a data ideal para começar. A expectativa é progresso consistente e demonstrável a partir de agora.

O que acontece se o teu site não estiver conforme?

Ignorar o EAA tem consequências reais. A aplicação varia por país na UE, mas tende a seguir um padrão: não é uma “polícia da acessibilidade” a bater à porta, é um sistema estruturado e muitas vezes impulsionado por consumidores, desenhado para empurrar empresas para a conformidade.

Como a não conformidade costuma ser detetada

Normalmente, o site entra no radar por duas vias:

1. Queixas de consumidores: o gatilho mais comum. Se uma pessoa com deficiência não conseguir concluir uma compra, usar um serviço ou encontrar informação, passa a ter um caminho legal claro para reclamar junto da autoridade nacional competente no seu país.
2. Fiscalização de mercado (market surveillance): reguladores também fazem auditorias proativas, sobretudo em setores de maior impacto como e-commerce, banca e viagens. O teu site pode ser sinalizado numa dessas verificações.

O que acontece depois: um processo por etapas

O cenário típico não começa com uma multa imediata. A lógica do EAA é alcançar acessibilidade, não “punir por punir”. Se o teu site for sinalizado, o processo costuma evoluir assim:

1. Notificação de não conformidade: normalmente começa com um aviso formal. A autoridade nacional contacta-te, descreve os problemas encontrados e explica que partes do EAA estão a ser violadas.
2. Prazo para corrigir: junto com o aviso, é dado um prazo razoável para remediar os problemas identificados. Este prazo é específico e geralmente curto (não confundir com a transição até 2030). A duração varia consoante a complexidade das correções.
3. Escalada: se ignorares o aviso e não fizeres as alterações exigidas dentro do prazo, entram as consequências mais pesadas.

Penalizações possíveis

O EAA exige penalizações “efetivas, proporcionais e dissuasoras” – ou seja, suficientemente relevantes para levarem a sério. Na prática, pode incluir:

• Multas substanciais: a penalização mais comum. O valor varia bastante de país para país, podendo ir de alguns milhares de euros até uma percentagem do volume de negócios anual. Para pequenos negócios, mesmo uma multa “menor” pode ser um impacto sério; para empresas maiores, pode ser enorme.
• Proibição/restrição do serviço: em casos mais severos, autoridades podem ordenar que deixes de disponibilizar o serviço a consumidores naquele país até estares conforme. Para um negócio online, perder acesso a um país da UE pode ser devastador.
• Retirada de produtos do mercado: se vendes um produto digital (por exemplo, um plugin WordPress) e ele for considerado não conforme, podes ser obrigado a retirá-lo do mercado.

Há ainda um ponto crítico: responsabilidade pessoal e criminal pode existir em alguns Estados-Membros e em situações de reincidência ou violações graves. É raro, mas reforça o nível de seriedade com que a legislação pode ser tratada.

Para lá do risco legal: o custo reputacional

Mesmo quando não há penalização imediata, ser identificado publicamente como inacessível mina confiança e pode afetar a marca durante anos. No mercado atual, exclusão não é só não conformidade: é também mau negócio.

Há ferramentas comerciais que ajudam a gerir esta jornada (scanners, assistentes e widgets de usabilidade). Um exemplo no ecossistema Elementor é o Ally, focado em integrar a acessibilidade no fluxo de trabalho WordPress.

Porque todo o ecossistema WordPress tem de agir (e não só “o dono do site”)

O EAA é abrangente, mas as implicações para WordPress são imediatas porque a acessibilidade depende da soma de tema, plugins, conteúdo e customizações. E essa responsabilidade distribui-se pela cadeia inteira.

Donos de sites WordPress

Se o teu site serve utilizadores na UE, conformidade deixou de ser opcional – vendas, serviços ou até conteúdo direcionado a audiência europeia entram na conversa.

• A responsabilidade é tua: multas e medidas recaem sobre o negócio, não sobre as ferramentas usadas.
• Cada ponto de contacto conta: não é só a homepage. A acessibilidade tem de acompanhar toda a jornada: páginas de produto, formulários de contacto, checkout, suporte, etc.
• Terceiros contam: plugins de reservas, extensões de e-commerce, form builders… se introduzem barreiras, o impacto é no teu site. Tens de escolher temas e plugins com critério.

Acessibilidade passa a ser um requisito base do negócio, não uma funcionalidade “nice to have”.

Agências e freelancers

Para profissionais, o papel fica ainda mais relevante: clientes esperam sites bonitos, rápidos e funcionais – e agora também conformes.

• Proteger clientes: muitos não dominam o EAA nem os requisitos técnicos. Explicar e implementar acessibilidade protege o negócio deles e a tua reputação profissional.
• Diferenciação no mercado: equipas que demonstram competência em acessibilidade tendem a ganhar projetos mais competitivos.
• Ajustar workflow: acessibilidade tem de entrar em design, desenvolvimento e QA – desde a seleção do tema, à avaliação de plugins, até testes e validações.

Desenvolvedores de plugins e temas

No WordPress, temas e plugins são parte central da conformidade porque o HTML gerado e os padrões de interação saem diretamente do teu código.

• Fazes parte da cadeia de conformidade: se o teu plugin gera componentes inacessíveis (campos sem label, sliders que não funcionam por teclado, etc.), estás a criar risco para quem o usa.
• Procura do mercado está a mudar: agências e donos de sites procuram ferramentas “accessibility-ready”. Documentar conformidade (por exemplo, com um Accessibility Conformance Report) começa a ser argumento de venda.
• Risco de abandono: produtos que bloqueiam a conformidade vão ser evitados. Acessibilidade não é só boa prática – é crítica para adoção a longo prazo.

Para developers no espaço WordPress, o EAA não é um fardo; é uma oportunidade de mercado. Quem embutir acessibilidade no núcleo dos seus produtos não vai apenas cumprir: vai tornar-se a escolha por defeito para uma nova geração de builders que vê inclusão como inegociável.

Itamar Haim

Também aqui faz sentido olhar para ferramentas que ajudam equipas a sistematizar auditoria e correção, como o Ally.

5 passos práticos para donos de sites WordPress (para começar já)

A boa notícia é que dá para avançar com um processo claro e incremental. Não precisas de “resolver tudo hoje”, mas precisas de começar com método e com impacto.

Passo 1: Auditar o teu website

Não dá para corrigir o que não está identificado. Uma auditoria decente combina scans automatizados com testes manuais.

• Scans automatizados: ótimos para apanhar problemas comuns no código. Conseguem detetar rapidamente contraste insuficiente, imagens sem alt, campos de formulário sem label, etc. Há extensões de browser, serviços e plugins. Para WordPress, o Accessibility Assistant do Ally integra no workflow e faz scanning das páginas contra WCAG 2.1 AA (o standard técnico que está por trás do EAA), devolvendo um relatório claro de violações.
• Testes manuais: automatização não avalia se a experiência “faz sentido”. Para isso, testes manuais são essenciais. Checklist simples para começar:

• Navegação por teclado: consegues navegar o site inteiro só com a tecla Tab? Chegas a todos os links, botões e campos? O foco está sempre visível (para perceberes onde estás na página)?
• Testes com screen reader: usa um leitor de ecrã (NVDA no Windows, VoiceOver no Mac, TalkBack no Android) e percorre o site. O conteúdo faz sentido lido em voz alta? As imagens estão bem descritas? Links e botões têm rótulos claros?
• Verificação de conteúdo: a hierarquia de headings é lógica (H1, depois H2, depois H3)? O texto dos links é descritivo (por exemplo, “Ler o relatório completo de acessibilidade” em vez de “Clica aqui”)? O texto está escrito de forma clara e direta (plain language)?

O output desta fase deve ser uma lista de tarefas priorizada – não um “relatório bonito” que fica numa pasta.

Passo 2: Corrigir primeiro os problemas de maior impacto

Não é realista corrigir tudo de uma vez. Começa pelo que melhora a usabilidade para mais pessoas, mais rápido.

Áreas típicas de alto impacto:

• Alt text em imagens informativas: se a imagem transmite informação, precisa de texto alternativo descritivo para utilizadores de screen reader. É das correções mais fáceis e mais críticas.
• Contraste baixo: texto difícil de ler contra o fundo é barreira comum para pessoas com baixa visão. Usa um contrast checker e garante pelo menos 4.5:1 de rácio de contraste.
• Texto de link vago: elimina “clica aqui”, “saber mais”, “ler mais”. O próprio link deve descrever o destino/ação.
• Labels em formulários: todos os campos em formulários de contacto, login e checkout precisam de label devidamente associado. Essencial para screen readers entenderem o que é pedido.
• Acessibilidade por teclado: garante que todos os elementos interativos podem ser alcançados e operados pelo teclado.

Estes “quick wins” aumentam imediatamente a qualidade do site para um número grande de utilizadores.

Passo 3: Publicar uma Accessibility Statement (Declaração de Acessibilidade)

Uma declaração de acessibilidade é uma página pública que assume compromisso com inclusão – e é também um requisito importante sob o EAA. Deve ser fácil de encontrar (muitas vezes no footer) e incluir:

• O teu compromisso com acessibilidade.
• O standard de conformidade que estás a seguir (ex.: WCAG 2.1 Level AA).
• Problemas conhecidos que já identificaste e que estão em correção.
• Contactos para utilizadores reportarem barreiras ou dificuldades.

Isto faz duas coisas ao mesmo tempo: demonstra transparência e boa-fé (relevante para utilizadores e reguladores) e cria um canal de feedback valioso com quem realmente encontra obstáculos.

Passo 4: Avaliar temas e plugins (os que tens e os que pensas instalar)

Tema e plugins moldam a acessibilidade real do teu site.

• Temas: começa por um tema accessibility-ready, com HTML semântico, hierarquia de headings consistente e suporte a navegação por teclado. Se o tema atual tiver falhas graves, faz sentido ponderar a troca.
• Plugins novos: antes de instalar, procura na documentação sinais de compromisso com acessibilidade e WCAG. Se necessário, contacta o developer. Tem especial cuidado com plugins que dependem quase só de interação visual (sliders, pop-ups e afins) e que não sejam operáveis por teclado.
• Plugins existentes: revê o que já está instalado. Estão a criar problemas? Exemplos comuns: botões de partilha social sem foco/navegação por teclado; form builders que geram campos sem label.

Neste ponto, o mindset muda: tens de ser um consumidor exigente de ferramentas WordPress. Escolher bem é parte crítica de manter conformidade.

Passo 5: Monitorizar de forma contínua (não é projeto “one-off”)

Acessibilidade não é uma tarefa que concluis e esqueces. Cada novo post, nova página de produto ou update de plugin pode introduzir regressões.

O objetivo é integrar acessibilidade no teu ciclo normal de manutenção:

• Checklists de criação de conteúdo: para quem publica no site. Imagens com alt? Headings corretos? Links descritivos?
• Scans regulares: agenda varreduras automatizadas (mensal ou trimestral) para detetar problemas novos.
• Ferramentas no front-end para utilizadores: um widget de usabilidade pode permitir ajustar tamanho de texto, contraste e realce de links. Ajuda a experiência e também torna visível o teu compromisso com acessibilidade.

Ao tornares isto rotina, sais do modo reativo (corrigir quando há problema) e entras no modo preventivo (evitar que o problema apareça). É assim que a conformidade fica sustentável.

Fecho: a conformidade é agora – e importa por mais do que motivos legais

A fase de “preparação” acabou. O EAA já está a moldar como sites WordPress são construídos, geridos e estendidos.

O foco prático é: auditar, corrigir o que mais impacta, publicar uma declaração de acessibilidade e transformar acessibilidade em parte do workflow diário.

E mesmo olhando só para o lado pragmático: sites acessíveis chegam a mais pessoas, melhoram a experiência, reforçam reputação e tendem a beneficiar também SEO e confiança. Inclusão não é apenas o certo – é também estratégia.

Principais pontos a reter

• O EAA já está em vigor: desde 28 de junho de 2025, acessibilidade é obrigatória para websites/serviços que atendem consumidores na UE.
• Conformidade imediata vs faseada: serviços novos têm de nascer conformes; serviços existentes têm até 2030, mas com expectativa de progresso real.
• Fiscalização tem consequências: normalmente começa com aviso e prazo de correção, mas pode escalar para multas, restrições e retirada de produtos.
• A responsabilidade é partilhada: donos de sites, agências e developers de plugins/temas influenciam diretamente a conformidade.
• Há um caminho prático: auditar, corrigir issues de alto impacto, publicar a declaração, avaliar ferramentas e monitorizar continuamente.
• Acessibilidade é vantagem competitiva: melhora alcance, usabilidade, SEO e confiança.

FAQ: dúvidas comuns sobre EAA, WCAG e WordPress

1) O EAA aplica-se ao meu blog pequeno se eu não vender nada?

Depende do modelo. O EAA aplica-se a produtos e serviços oferecidos a consumidores na UE. Se o teu blog é hobby e não oferece serviços, é provável que fique fora do âmbito. Mas se o blog faz parte da tua atividade comercial (por exemplo, és consultor e o blog é canal de marketing) e serves ou direcionas clientes na UE, então sim. O critério chave é a natureza comercial da atividade.

2) Qual é a diferença entre EAA e WCAG?

Pensa assim: o EAA é a lei; as WCAG (Web Content Accessibility Guidelines) são o standard técnico usado para cumprir a lei. O EAA exige acessibilidade e aponta para padrões como WCAG 2.1 Level AA como referência de “como” atingir essa acessibilidade. Para cumprir o EAA, precisas de conformidade com WCAG.

3) Um único plugin consegue tornar o meu WordPress 100% conforme?

Não – e convém desconfiar de qualquer ferramenta que prometa isso. Conformidade total é combinação de tecnologia, conteúdo e design. Um plugin pode ajudar muito: fazer scanning, orientar correções, gerar uma declaração de acessibilidade e fornecer ferramentas para utilizadores. Mas nenhuma solução automatizada corrige tudo. Exemplo clássico: uma ferramenta deteta imagem sem alt, mas não sabe se o alt que escreveste é realmente correto e útil. Conformidade exige ferramentas + supervisão humana.

4) Tenho uma empresa nos EUA sem presença física na UE. O EAA aplica-se na mesma?

Sim, se ofereces produtos ou serviços a consumidores localizados na UE. O alcance do EAA é definido pela localização do consumidor, não pela localização do negócio. Se uma pessoa residente na UE consegue comprar, subscrever ou descarregar o teu produto/serviço, espera-se conformidade com o EAA.

5) Quanto custa tornar um site WordPress acessível?

Varia muito com o tamanho e complexidade do site, o estado atual de acessibilidade e a abordagem. Um site simples pode exigir um investimento mínimo (sobretudo tempo para aprender e aplicar correções). Já um e-commerce grande, com anos de conteúdo legado, tende a exigir um esforço maior. Ainda assim, investir cedo em boas ferramentas e incorporar acessibilidade no processo costuma ser bem mais barato do que uma remediação grande no fim – ou do que lidar com uma penalização.

6) Usei um scanner automatizado e ele diz que o site está 100% conforme. Estou seguro?

Não necessariamente. Scanners automatizados são essenciais, mas costumam detetar apenas cerca de 30–40% dos problemas de acessibilidade. São ótimos para problemas técnicos no código, mas não avaliam aspetos humanos de usabilidade: conteúdo confuso, fluxo ilógico de navegação por teclado, qualidade do alt text, etc. Tens de combinar scan automatizado com testes manuais.

7) O que é uma accessibility statement e preciso mesmo de uma?

É uma página pública no teu site que comunica políticas e compromisso com acessibilidade. Sim, precisas: é um requisito específico do EAA. Deve indicar o nível-alvo (ex.: WCAG 2.1 AA), listar problemas conhecidos em correção e fornecer um contacto para reportar barreiras. Demonstra transparência e esforço de boa-fé.

8) O meu tema diz que é “accessibility-ready”. Isso chega?

É um ótimo começo, mas não chega por si. Um tema accessibility-ready dá base sólida (código limpo, headings corretos, navegação por teclado), mas a acessibilidade final depende também do conteúdo que publicas, dos plugins que instalas e das customizações que fazes. É um primeiro passo crítico – não uma isenção de responsabilidade.

9) Com que frequência devo fazer auditorias de acessibilidade?

Acessibilidade é compromisso contínuo. Uma auditoria completa e profunda faz sentido a cada 12–18 meses ou após um redesign significativo. Mas deves adicionar checks frequentes ao workflow: por exemplo, scan automatizado trimestral e um teste rápido de teclado após updates relevantes de plugins ou publicação de features/conteúdo importante.

10) Onde encontro recursos fiáveis para aprender mais sobre acessibilidade web?

Há muitos recursos bons. As WCAG oficiais do W3C são a referência definitiva (apesar de técnicas). Para orientação mais prática, procura organizações como a Web Accessibility Initiative (WAI), a WebAIM (artigos e checklists excelentes) e blogs de especialistas em acessibilidade. Fornecedores de ferramentas (incluindo a própria Elementor através do ecossistema Ally) também publicam materiais educativos úteis.