EAA e WCAG 2.1, como implementar acessibilidade digital

#O que é a lei europeia de acessibilidade (EAA) e as WCAG 2.1

A partir de 28 de junho de 2025 aplicam-se as leis nacionais que transpõem a Lei Europeia de Acessibilidade (EAA). Não abrangem todos os sites da UE, mas sim os serviços ao consumidor enumerados na diretiva, entre eles o comércio eletrónico, a banca de retalho, as comunicações eletrónicas e partes do transporte de passageiros. As microempresas prestadoras de serviços estão isentas. A lista completa, as exceções e as coimas nacionais estão no guia de acessibilidade WordPress e WCAG 2.2. Este artigo trata de outra coisa: como decorre a implementação num site WordPress.

A diretiva não menciona as WCAG pelo nome, mas os seus requisitos assentam nos mesmos quatro princípios, por isso as auditorias medem-se pelos critérios das WCAG 2.1 ou 2.2 Nível AA, um conjunto de diretrizes que garantem que o conteúdo digital é acessível a pessoas com deficiência, idosos e utilizadores com limitações temporárias.

WCAG 2.1 (Diretrizes de Acessibilidade para Conteúdo Web) é uma norma internacional que define como desenhar e programar sites para serem percetíveis, operáveis, compreensíveis e robustos. O incumprimento das leis nacionais que transpõem a EAA tem consequências financeiras e legais.

#Por que é a acessibilidade digital tão importante

• Segundo a Comissão Europeia, 90 milhões de pessoas na UE vivem com uma deficiência, um grupo enorme de potenciais clientes e utilizadores para o seu site.
• Além das deficiências: A acessibilidade beneficia idosos, pessoas com lesões temporárias (ex: um braço partido), pessoas com distúrbios de atenção, ou simplesmente utilizadores em dispositivos móveis sob luz solar intensa.
• Melhor experiência de utilizador (UX): Acessibilidade significa navegação mais simples, conteúdo mais claro e uma interface intuitiva para todos.
• SEO: Muitos requisitos WCAG sobrepõem-se às boas práticas de SEO (responsividade, estrutura lógica de cabeçalhos, atributos ALT).
• Conversão: Processo de compra mais simples, formulários claros e melhor apoio ao cliente.
• Mitigação de riscos: As coimas são fixadas por cada Estado-Membro. Em Portugal, o Decreto-Lei n.º 82/2022 (artigo 29.º) prevê, para pessoas coletivas, entre 12 000 € e 24 000 € numa contraordenação grave e a partir de 24 000 €, até ao limite do regime geral das contraordenações, numa contraordenação muito grave.
• Imagem de marca: Constrói uma reputação como uma empresa socialmente responsável e moderna.

#O que significa a conformidade WCAG 2.1 AA na prática

Aqui estão os principais requisitos que deve implementar:

1. Navegação por teclado: Todo o site deve ser operável sem rato.
2. Compatibilidade com leitores de ecrã: Semântica HTML adequada, cabeçalhos, descrições de imagem (ALT) e etiquetas de formulário.
3. Contraste de cor: O texto deve ser legível para pessoas com deficiência visual (rácio mínimo de 4.5:1).
4. Multimédia: Legendas e transcrições para conteúdo de vídeo e áudio.
5. Estrutura clara: Uso correto de cabeçalhos H1-H6 e layouts de secção lógicos.
6. Gestão de erros: Mensagens claras em formulários explicando como corrigir erros.
7. PDF e outros documentos acessíveis: Formatados corretamente e legíveis por leitores de ecrã.
8. Responsividade: O site deve funcionar fluentemente em telemóvel, tablet e desktop.

Estudo de caso: No projeto uczelniadostepna.pl, focámo-nos em HTML semântico, formulários acessíveis e modos de alto contraste. O resultado foi um serviço amigável tanto para utilizadores com deficiência como para o público em geral.

#Como implementar WCAG 2.1 e EAA com wppoland.com

1. Auditoria de acessibilidade: Realizamos uma auditoria detalhada do seu site WordPress, combinando ferramentas automatizadas com verificação manual por especialistas usando leitores de ecrã.
2. Otimização de tema e plugins: Modificamos os seus componentes existentes ou recomendamos alternativas acessíveis para cumprir as normas desde a base.
3. Remediação: Implementamos alterações de código, corrigimos estruturas de cabeçalhos, melhoramos etiquetas de formulário e otimizamos ficheiros multimédia.
4. Formação e suporte: Ensinamos a sua equipa a criar conteúdo acessível (ex: como escrever bom texto ALT) e fornecemos suporte contínuo.
5. Declaração de acessibilidade: Ajudamo-lo a preparar a declaração e a implementar um mecanismo de feedback para utilizadores.

As secções seguintes desdobram estes passos em decisões concretas. A referência é a WCAG-EM 2.0, a metodologia de avaliação da conformidade com as WCAG que o W3C publicou como Group Note a 23 de julho de 2026. Divide a avaliação em cinco passos: definir o âmbito, explorar o site, selecionar uma amostra representativa, avaliar a amostra e relatar os resultados.

#Como definir o âmbito de uma auditoria de acessibilidade WordPress

O primeiro passo da WCAG-EM tem quatro elementos: o âmbito do site, o nível de conformidade pretendido, a base de suporte de acessibilidade e requisitos adicionais opcionais. Num site WordPress, cada um corresponde a uma decisão concreta.

Âmbito do site. É preciso indicar o que entra na avaliação: só o domínio principal ou também um subdomínio com a loja, a área de cliente, as versões linguísticas e as páginas de campanha. Numa instalação multisite, cada site da rede pode ter tema e plugins próprios, por isso um site excluído tem de ficar escrito de forma explícita.

Nível de conformidade pretendido. Para serviços abrangidos pela EAA, o objetivo prático é o nível AA. A escolha entre WCAG 2.1 e 2.2 deve constar do âmbito, porque define os critérios de sucesso que o auditor verifica. O próprio WordPress adotou WCAG 2.2 AA para o seu código, como descreve o guia sobre WCAG 2.2.

Base de suporte de acessibilidade. A WCAG-EM exige definir em que combinações de navegadores e tecnologias de apoio a avaliação se baseia. Por exemplo: NVDA com Firefox ou Chrome no Windows, VoiceOver com Safari no macOS e iOS, TalkBack com Chrome no Android. Sem esta lista, duas auditorias ao mesmo site podem dar resultados diferentes e nenhuma pode ser repetida.

Requisitos adicionais. Aqui entra o que vai além da conformidade, por exemplo a avaliação de critérios AAA selecionados ou um teste de usabilidade com pessoas com deficiência.

#Como selecionar páginas para a amostra de uma auditoria WCAG

O segundo passo da WCAG-EM é explorar o site: vistas comuns, funcionalidade essencial, tipos de página e tecnologias de que o conteúdo depende. A metodologia define vistas comuns como as que dizem respeito a todo o site, normalmente ligadas diretamente a partir do ponto de entrada: página inicial, ajuda, informação legal e contacto.

No WordPress compensa explorar segundo a hierarquia de modelos, porque um modelo gera centenas de endereços. Uma lista típica de tipos de página:

O terceiro passo é selecionar a amostra. A WCAG-EM combina três partes. A amostra estruturada cobre as vistas comuns, a funcionalidade essencial e um exemplo de cada tipo de página. A amostra aleatória corresponde, segundo a metodologia, a 10% do número de páginas da amostra estruturada e soma-se a ela: com 30 páginas na parte estruturada juntam-se 3 aleatórias. Os processos completos significam que, se uma página pertence a um processo, todos os passos desse processo entram na amostra, incluindo o ponto de partida, a sequência predefinida e as ramificações importantes.

Numa loja WooCommerce, o processo de compra completo é carrinho, dados do cliente, escolha de envio e pagamento, confirmação da encomenda e o percurso com um erro de validação. Num formulário de contacto é o formulário vazio, o formulário com erros e a mensagem depois do envio. Uma auditoria que salta o estado de erro salta o sítio onde um utilizador de leitor de ecrã mais vezes fica bloqueado.

#O que revelam os resultados da amostra aleatória

O quarto passo da WCAG-EM é avaliar as páginas e processos selecionados e depois comparar os resultados da parte estruturada com os da parte aleatória. Se as páginas aleatórias revelam problemas que não existiam na parte estruturada, a amostra não era representativa e tem de ser alargada. No WordPress isto acontece sobretudo quando a exploração deixou de fora um tipo de conteúdo: um artigo antigo do editor clássico, uma página feita com outro construtor de páginas ou um plugin que insere o seu próprio widget só em algumas páginas.

A metodologia pressupõe ainda que quem avalia conhece bem as WCAG 2, as tecnologias de apoio e a forma como pessoas com deficiência usam os sites. Correr uma ferramenta automática não cumpre esse pressuposto, porque a ferramenta não avalia se um texto alternativo descreve a imagem nem se a ordem do foco faz sentido.

#Como definir a ordem das correções depois de uma auditoria de acessibilidade

Um relatório de auditoria traz normalmente dezenas de erros. No WordPress, a ordem de correção define-se melhor pelo sítio onde o erro nasce do que pela ordem da lista.

1. Processos completos que bloqueiam o objetivo. Um erro que impede concluir uma encomenda ou enviar um formulário fecha o serviço a um grupo inteiro de utilizadores, por isso vem primeiro.
2. Partes comuns do modelo. Cabeçalho, menu, rodapé, banner de consentimento e pesquisa aparecem em todas as páginas. Uma correção numa parte do modelo ou no ficheiro do tema elimina o erro do site inteiro.
3. Componentes reutilizados. Blocos próprios, padrões, shortcodes e widgets de plugins. A pergunta aqui é: corrigir, substituir por uma alternativa acessível ou remover.
4. Conteúdo editorial. Textos alternativos, cabeçalhos dentro dos artigos, texto das ligações e ficheiros PDF. Esta parte é corrigida pela equipa editorial, por isso as correções devem ir acompanhadas de regras e exemplos.

Esta divisão tem também um efeito no orçamento: as correções dos pontos 2 e 3 fazem-se uma vez e valem para milhares de endereços, enquanto o ponto 4 cresce com o volume de conteúdo.

#Como testar o site com utilizadores de tecnologias de apoio

Uma auditoria pelas WCAG diz se o site cumpre os critérios. Não diz se é cómodo de usar. O W3C WAI recomenda, em «Involving Users in Evaluating Web Accessibility», envolver pessoas com deficiência ao longo do trabalho e não só no fim, e nota que verificações curtas e informais durante o projeto rendem mais do que um único teste formal.

Desse material resultam regras concretas para organizar o teste:

• Primeiro a revisão de especialista. As barreiras óbvias eliminam-se antes de convidar utilizadores, para que o tempo deles não se gaste em problemas que a auditoria já encontrou.
• Poucas pessoas, necessidades diferentes. O WAI recomenda incluir algumas pessoas com deficiência e também utilizadores idosos, se fizerem parte do público. O nível de experiência deve corresponder ao público: num serviço público contam também os principiantes no leitor de ecrã.
• Pensar em voz alta. O participante diz o que faz e o que espera, e quem conduz anota onde uma barreira provoca um erro.
• Conclusões prudentes. O WAI avisa: «Evite presumir que a opinião de uma pessoa com deficiência se aplica a todas as pessoas com deficiência» (W3C WAI, tradução própria). O problema pode estar no conteúdo, no navegador, na tecnologia de apoio ou no grau de familiaridade do participante com ela.

O teste com utilizadores não substitui a auditoria. O WAI escreve que, por si só, não permite determinar se um site é acessível, por isso combina-se com a avaliação pelas WCAG. Num projeto WordPress, um bom momento para o teste é quando as correções dos modelos já estão em staging e o conteúdo é real, não de teste.

#O que deve conter a declaração de acessibilidade de um site WordPress

O W3C WAI indica, no guia sobre declarações de acessibilidade, um mínimo: o compromisso com a acessibilidade, a norma aplicada (por exemplo WCAG 2.2) e os contactos para o caso de surgirem problemas. Recomenda ainda incluir limitações conhecidas, medidas tomadas pela organização, requisitos técnicos, ambientes em que o conteúdo foi testado e referências à legislação aplicável.

O gerador de declarações do W3C, gratuito, conduz por estes campos. A secção de limitações é a que dá mais trabalho, porque para cada problema conhecido o gerador pede cinco coisas: que parte do conteúdo afeta, em que consiste, porque acontece, o que a organização está a fazer e o que o utilizador pode fazer entretanto. Preenchê-la com honestidade exige os resultados da auditoria, por isso a declaração escreve-se depois da avaliação e não antes. O gerador tem também campos para o estado de conformidade (total, parcial, não conforme, não avaliado) e para o tipo de avaliação: autoavaliação ou avaliação externa.

Para serviços abrangidos pela EAA, soma-se uma obrigação da própria diretiva. O artigo 13.º, n.º 2, da Diretiva (UE) 2019/882 exige que o prestador prepare a informação de acordo com o anexo V e explique como o serviço cumpre os requisitos de acessibilidade. A informação deve estar disponível ao público por escrito e oralmente, incluindo de forma acessível a pessoas com deficiência, e ser conservada enquanto o serviço estiver em funcionamento. O anexo V diz que a informação consta das condições gerais do serviço ou de documento equivalente e, quando aplicável, inclui:

• uma descrição geral do serviço em formatos acessíveis,
• as descrições e explicações necessárias para compreender o funcionamento do serviço,
• uma descrição de como o serviço cumpre os requisitos de acessibilidade do anexo I.

Para uma loja em WordPress isto significa normalmente dois documentos: uma página com a declaração de acessibilidade para os utilizadores e uma secção nos termos e condições com a informação exigida pelo anexo V. Ambos devem ter ligação a partir do rodapé, para estarem acessíveis em todas as páginas.

#Como manter o site acessível depois das correções

A acessibilidade de um site WordPress muda a cada atualização do tema e dos plugins e a cada novo artigo. A diretiva prevê isto no artigo 13.º, n.º 3: o prestador tem de ter procedimentos que mantenham o serviço conforme os requisitos e de ter em conta as alterações no serviço, nos requisitos e nas normas a que se refere. O n.º 4 acrescenta que, em caso de não conformidade, o prestador toma medidas corretivas e informa de imediato as autoridades nacionais competentes.

Na prática, este procedimento num site WordPress tem alguns elementos fixos:

• Nova avaliação da amostra após alterações. A amostra da auditoria (vistas comuns, tipos de página, processos completos) torna-se uma lista de verificação depois de atualizar o tema, os plugins de formulários ou da loja e depois de alterar uma parte do modelo.
• Registo dos resultados. A WCAG-EM recomenda no quinto passo documentar os resultados de cada passo e, opcionalmente, um relatório em formato legível por máquina. A ferramenta gratuita WCAG-EM Report Tool conduz pelos passos da metodologia e gera um relatório que se pode comparar com a auditoria seguinte.
• Regras para a equipa editorial. A maioria dos erros novos depois da implementação vem do conteúdo: texto alternativo em falta, um nível de cabeçalho saltado, um PDF digitalizado como imagem.
• Tratamento de pedidos. O canal de contacto da declaração precisa de um responsável e de um prazo de resposta, porque o gerador do W3C pergunta precisamente pelo tempo típico de resposta.

Se uma empresa invocar o encargo desproporcionado do artigo 14.º, tem de documentar a avaliação e conservá-la durante cinco anos. Mais uma razão para guardar resultados de auditorias e decisões de correção num só sítio.

#Quem implementa acessibilidade EAA e WCAG num site WordPress

• Especialistas WordPress: Conhecemos o ecossistema WordPress por dentro e por fora, incluindo WooCommerce e portais complexos.
• Do PDF à página real: Não nos limitamos a “cumprir tabela”; visamos uma usabilidade genuína e conformidade a longo prazo.
• Segurança legal: Ajudamo-lo a navegar pelas complexidades da EAA para evitar coimas.
• Crescimento do negócio: A acessibilidade é também um trabalho de SEO e UX.

O prazo já passou. Contacte-nos através do formulário ou email para auditar o seu site e garantir que está aberto a todos.

A conformidade com a WCAG 2.1 raramente se resolve com um plugin: o contraste, a ordem de foco e o comportamento dos formulários vivem no tema e no código. Se quiser esse trabalho feito na origem, veja como abordamos o desenvolvimento de temas WordPress acessíveis.