Declaração de acessibilidade para WordPress: modelo + mapeamento EN 301 549

#Declaração de acessibilidade para WordPress: modelo + mapeamento EN 301 549

Uma declaração de acessibilidade é um entregável legal distinto de uma auditoria WCAG. É possível passar todos os testes automáticos num site WordPress e ainda assim não estar conforme com o Decreto-Lei n.º 82/2022 ou com o Decreto-Lei n.º 83/2018, porque ambos exigem a própria declaração: um estado de conformidade publicado, a norma testada, uma lista de limitações conhecidas e um mecanismo de comunicação funcional que um visitante possa usar para apresentar uma reclamação. Este artigo é uma peça de apoio dentro da pilha de conformidade da WCAG 2.2, BFSG e do Ato Europeu de Acessibilidade, focada especificamente no documento da declaração e em como as suas secções se mapeiam para a EN 301 549, a norma europeia que as equipas de contratação efetivamente citam.

#O que precisa de publicar, em resumo

• Uma página dedicada, ligada a partir do rodapé, não um parágrafo dentro da sua política de privacidade.
• Um estado de conformidade: total, parcial com exceções nomeadas, ou não conforme.
• A norma testada: na prática a WCAG 2.2 AA, referenciada face à EN 301 549 para audiências de contratação.
• Uma lista de limitações conhecidas com, sempre que possível, uma data de correção.
• Um contacto de comunicação que efetivamente chegue a uma caixa de correio monitorizada, mais uma via de fiscalização ou escalonamento.
• Uma data de preparação e um ritmo de revisão, porque “testámos isto uma vez em 2023” não é uma declaração atual.

Nada disto substitui uma auditoria técnica. Documenta o resultado de uma. Se ainda não realizou uma auditoria WCAG 2.2 AA, a declaração ou vai sobreafirmar a conformidade ou vai parecer um placeholder, e ambos os resultados atraem mais escrutínio do que não ter declaração nenhuma.

#Quando a declaração de acessibilidade é obrigatória na UE

Três bases jurídicas sobrepostas colocam uma declaração de acessibilidade na lista de obrigações de um operador WordPress, e não se dirigem todas à mesma audiência.

A Diretiva (UE) 2016/2102, a diretiva de acessibilidade da web, exige que os organismos do setor público publiquem e atualizem regularmente uma declaração de acessibilidade para cada sítio web e aplicação móvel que operam. Em Portugal, foi transposta pelo Decreto-Lei n.º 83/2018, de 19 de outubro, que exige conformidade com a norma EN 301 549 (equivalente técnico da WCAG 2.1 nível AA) e a publicação de uma declaração de acessibilidade, com a AMA - Agência para a Modernização Administrativa como entidade responsável pela monitorização. Isto antecede o EAA e aplica-se com independência de tudo o resto: um site de uma câmara municipal, o blogue de uma universidade pública, o portal de imprensa de um organismo estatal estão todos dentro do âmbito, independentemente do que se segue.

O Ato Europeu de Acessibilidade (Diretiva 2019/882), em vigor desde 2025-06-28, estende obrigações comparáveis a operadores privados de categorias específicas de produtos e serviços: comércio eletrónico, serviços bancários, transportes, livros eletrónicos e outros enumerados no anexo I da diretiva. Em Portugal, isto é implementado pelo Decreto-Lei n.º 82/2022, de 6 de dezembro, complementado pela Portaria n.º 220/2023, de 20 de julho, com efeitos plenos desde 28 de junho de 2025.

As transposições nacionais preenchem o detalhe operacional. O incumprimento do Decreto-Lei n.º 82/2022 pode originar coimas que, para pessoas colectivas, atingem 44 891,81 EUR, com um regime transitório até 2030 para contratos e instalações pré-existentes. Na prática, isto significa que uma declaração publicada é a forma mais simples de demonstrar que o processo de reclamações existe antes de chegar qualquer reclamação.

As isenções que vale a pena conhecer antes de escrever qualquer coisa: as micro empresas (menos de 10 trabalhadores, volume de negócios ou balanço anual inferior a 2 milhões de EUR) estão isentas de várias obrigações de serviços do EAA, embora a isenção seja mais restrita para os fabricantes de produtos. Os organismos públicos não têm qualquer isenção por dimensão ao abrigo do Decreto-Lei n.º 83/2018. As alegações de encargo desproporcionado existem em ambos os regimes, mas exigem uma avaliação documentada, não uma nota de rodapé a dizer “não aplicável”.

O artigo pilar sobre a WCAG 2.2, o BFSG e o Ato Europeu de Acessibilidade cobre a pilha de conformidade completa, incluindo o ritmo de auditoria que produz o estado de conformidade documentado nesta declaração.

#EN 301 549 vs. WCAG 2.2 AA: o que a contratação pública realmente pede

A WCAG 2.2 AA é aquilo contra o qual a sua equipa de desenvolvimento testa. A EN 301 549 é aquilo que um responsável de contratação, um caderno de encargos ou uma auditoria do setor público cita, porque é a norma europeia harmonizada para a acessibilidade das TIC em geral, não apenas para conteúdo web.

A versão atualmente em vigor é a EN 301 549 V3.2.1, publicada em março de 2021 e citada no Jornal Oficial da UE ao abrigo da Diretiva 2016/2102 através da Decisão de Execução (UE) 2021/1339 da Comissão. O seu capítulo dedicado à web, o capítulo 9, incorpora por referência os critérios de sucesso da WCAG 2.1 nível A e AA. Uma revisão que incorpore a WCAG 2.2 está em elaboração no organismo técnico conjunto ETSI/CEN/CENELEC, com publicação esperada em 2026 sob o mandato de normalização M/587 da Comissão Europeia, mas ainda não é a versão citada no Jornal Oficial.

Isto cria uma lacuna prática que os documentos de contratação raramente resolvem com clareza: a base legalmente referenciada é a WCAG 2.1 AA, enquanto o objetivo atual de melhor prática, e aquilo para que a maioria das agências (incluindo a nossa) efetivamente constrói, é a WCAG 2.2 AA. Como a 2.2 é um sobreconjunto estrito da 2.1 com nove critérios de sucesso adicionais, testar e documentar face à 2.2 AA também satisfaz a base 2.1 AA que a EN 301 549 referencia atualmente. Não há risco de desalinhamento de versão ao construir para o padrão mais recente; o risco corre no outro sentido, se construir apenas para a 2.1 e a revisão da EN 301 549 for publicada a meio do contrato.

Além do capítulo web, a EN 301 549 tem outros onze capítulos. Os três mais relevantes para uma implementação típica em WordPress além do próprio conteúdo web:

• Capítulo 10, documentos não web. Os PDF, folhas de cálculo e apresentações publicados através do site (listas de preços, relatórios anuais, documentos de concurso) precisam de etiquetagem correta, ordem de leitura e tabelas acessíveis, independentemente de quão acessível seja a própria página que os rodeia.
• Capítulo 11, software. Relevante quando o próprio painel de administração do WordPress é o produto avaliado, por exemplo uma equipa editorial do setor público que usa o editor de blocos como ferramenta de autoria, ou um plugin personalizado que expõe uma interface de formulário aos utilizadores finais.
• Capítulo 12, documentação e serviços de apoio. As páginas de ajuda, os guias de integração e os canais de apoio ligados a partir do site devem cumprir o mesmo nível de acessibilidade que o conteúdo principal, e a própria comunicação de apoio tem de estar disponível através de mais do que um canal.

#Secções do modelo com cabeçalhos prontos a copiar

A ordem de secções abaixo é a estrutura que aparece na maioria das declarações de acessibilidade da UE construídas sobre o quadro EN 301 549 / EAA / transposições nacionais. É ilustrativa: preencha-a com os resultados reais da sua auditoria, não com texto de substituição, e faça-a rever por quem gere a aprovação de conformidade na sua organização antes de a publicar.

# Declaração de acessibilidade para [nome do site]

## Estado de conformidade
[Nome do site] é [totalmente conforme / parcialmente conforme / não
conforme] com a WCAG 2.2 nível AA, avaliado face aos requisitos
referenciados na EN 301 549. [Escolha uma opção:]
- Totalmente conforme significa que o conteúdo cumpre integralmente a
  norma sem exceções.
- Parcialmente conforme significa que algumas partes do conteúdo não
  cumprem integralmente a norma, listadas em "limitações conhecidas"
  abaixo.

## Norma aplicável
Esta declaração baseia-se numa autoavaliação / numa avaliação realizada
por [nome ou função do avaliador] em [data], face a:
- Web Content Accessibility Guidelines (WCAG) 2.2, nível AA
- EN 301 549, [versão], capítulo 9 (Web)
[Liste os capítulos 10, 11, 12 aqui apenas se documentos não web,
software ou serviços de apoio também foram avaliados.]

## Limitações conhecidas
O seguinte conteúdo ainda não está totalmente acessível:
- [Limitação específica, ex.: "o widget de reserva incorporado em
  /contacto/ não pode ser operado apenas por teclado"], afetando [qual
  critério de sucesso], meta de correção: [data ou "em revisão"].
- [Repita para cada problema conhecido. Não resuma vários problemas
  numa linha vaga; liste-os individualmente.]

## Preparação desta declaração
Esta declaração foi preparada em [data] e revista pela última vez em
[data]. Foi preparada com base em [autoavaliação / auditoria de
terceiros], cobrindo [âmbito: ex.: "as páginas públicas em exemplo.com,
excluindo conteúdo incorporado de terceiros"].

## Contacto e informações de comunicação
Se encontrar uma barreira de acessibilidade neste site, contacte-nos:
- E-mail: [endereço monitorizado]
- [Opcional: telefone, URL do formulário de contacto]
Procuramos responder no prazo de [X] dias úteis.

## Procedimento de fiscalização
Se não ficar satisfeito com a nossa resposta, pode escalar para:
[Entidade nacional de fiscalização ou resolução de conflitos, com URL,
relevante para a jurisdição em que o operador está estabelecido ou
presta serviço.]

## Especificações técnicas
Este site depende das seguintes tecnologias para a conformidade:
HTML, CSS, JavaScript, WAI-ARIA.

Duas secções merecem mais cuidado do que um modelo genérico consegue dar. Limitações conhecidas é a secção que a maioria das declarações erra, seja omitindo-a por completo (afirmando conformidade total enquanto uma verificação automática mostra falhas), seja redigindo-a de forma tão vaga que não fornece nenhuma prova de uma avaliação real. Procedimento de fiscalização precisa de um destino real, não “contacte a sua autoridade nacional”, porque o objetivo da secção é que um visitante insatisfeito possa agir sobre ela sem investigação adicional.

#Tabela de mapeamento: requisito da EN 301 549 para implementação em WordPress

O capítulo 4 da EN 301 549 estabelece declarações de desempenho funcional (uso sem visão, uso com destreza manual limitada e semelhantes) usadas quando um critério de sucesso específico não se mapeia de forma limpa para uma interface nova. Para um front-end WordPress padrão, a maior parte do trabalho de mapeamento ocorre nos capítulos 9, 10, 11 e 12.

Esta tabela é a espinha dorsal de um relatório de conformidade ao estilo VPAT se um cliente do setor público o solicitar; cada linha torna-se num item com estado aprovado, parcial ou não aprovado depois de a sua auditoria ser executada.

#Onde publicar a declaração em WordPress: rodapé, página dedicada, schema

Ligação no rodapé, em todas as páginas. O sinal mais verificado numa revisão de fiscalização é se a declaração é acessível a partir de qualquer parte do site sem pesquisar. Uma ligação no rodapé, junto à política de privacidade e aos termos, satisfaz isto sem trabalho de desenvolvimento adicional. Se o rodapé do seu tema é gerido através de uma área de widgets ou de um modelo global de rodapé, adicione a ligação lá uma vez, não por página.

Página dedicada, com a sua própria URL. Não integre a declaração na política de privacidade ou nos termos de serviço. Dê-lhe uma URL independente como /declaracao-de-acessibilidade/, configurada através de uma página normal do WordPress (ou uma entrada de conteúdo MDX, neste stack), para que possa ser revista e versionada de forma independente do restante conteúdo legal.

Dados estruturados, opcionais mas úteis para auditorias de contratação. Um bloco JSON-LD do tipo WebPage na página da declaração, com o dateModified da página a corresponder à sua última data de revisão, dá a um rastreador automatizado ou a uma ferramenta de checklist de contratação uma confirmação legível por máquina de que a declaração existe e quando foi tocada por último. Isto não substitui o conteúdo legível por humanos; é um pequeno complemento que remove a ambiguidade quando alguém executa uma verificação automática de conformidade contra o seu domínio.

Ritmo de revisão, documentado na própria declaração. Indique com que frequência a declaração é revista (anualmente, ou após qualquer grande redesenho) e cumpra esse ritmo. Uma declaração datada de há três anos, com um campo “última revisão” que ninguém tocou, é uma das primeiras coisas que um auditor ou a equipa jurídica de um concorrente irá assinalar.

#Fluxo de reclamações e comunicação

O mecanismo de comunicação é a parte do Decreto-Lei n.º 82/2022 e do EAA que uma auditoria puramente de front-end não consegue satisfazer, porque é um requisito de processo, não de código.

1. Receção. Um endereço de e-mail monitorizado ou um formulário de contacto, distinto do apoio geral, para que as reclamações de acessibilidade não se percam numa fila genérica. Encaminhe-o para quem é responsável pela conformidade, não apenas para o webmaster.
2. Confirmação. Confirme a receção dentro de um prazo declarado (normalmente alguns dias úteis). A confirmação deve reformular a barreira reportada para que o visitante saiba que foi corretamente compreendida.
3. Investigação. Reproduza a barreira, verifique-a face ao critério de sucesso da WCAG relevante, e registe a conclusão, quer confirme uma limitação conhecida já listada na declaração, quer revele uma nova.
4. Resposta e plano de correção. Diga ao visitante o que foi encontrado e, se for uma barreira real, quando será corrigida ou porque não pode ser (encargo desproporcionado, conteúdo de terceiros fora do seu controlo e semelhantes, documentado em vez de apenas afirmado).
5. Via de escalonamento. Se o visitante não ficar satisfeito, encaminhe-o para a entidade de fiscalização ou resolução de conflitos relevante. Em Portugal, essa função cabe às entidades responsáveis pela fiscalização do Decreto-Lei n.º 82/2022 e, para o setor público, à AMA; outros Estados-Membros designam a sua própria autoridade de fiscalização do mercado ao abrigo do EAA.
6. Registo interno. Mantenha um registo de cada reclamação recebida e da sua resolução. Este registo é o que transforma “temos um processo” de uma afirmação na declaração num elemento de prova durante uma auditoria ou uma investigação de fiscalização.

Nenhum destes passos exige software novo. Uma caixa de correio partilhada, uma simples folha de cálculo ou uma etiqueta de ticket, e um responsável nomeado cobrem o requisito para a maioria dos operadores WordPress. O que importa é que o processo esteja documentado na declaração e seja efetivamente seguido quando chega uma reclamação, não inventado retroativamente depois de uma chegar.

#Como isto se encaixa na auditoria de conformidade UE

Uma declaração de acessibilidade é um entregável entre vários dentro de uma auditoria de conformidade UE para WordPress mais ampla, que também cobre o mapeamento de fornecedores NIS2/DORA e as obrigações de rotulagem de conteúdo do AI Act quando relevante. Dentro da parte de acessibilidade dessa auditoria, a declaração é o entregável que transforma um relatório técnico WCAG 2.2 AA em algo sobre o qual um responsável de conformidade, um revisor de contratação pública ou uma entidade de fiscalização pode agir sem ler o resultado subjacente da verificação.

A sequência que produz uma declaração defensável, pela ordem em que a executamos:

1. Auditoria técnica WCAG 2.2 AA, automática mais manual, sobre a amostra representativa de páginas descrita na pilha de conformidade WCAG/BFSG/EAA.
2. Lista de lacunas associada a critérios de sucesso concretos, não um resumo genérico de “alguns problemas encontrados”, porque a secção de limitações conhecidas da declaração precisa de itens concretos e identificados.
3. Rascunho da declaração usando a estrutura de secções acima, preenchido com o resultado real da auditoria em vez de uma afirmação de conformidade de substituição.
4. Configuração do fluxo de comunicação, ligado a uma caixa de correio real e a um responsável nomeado, testado com uma reclamação fictícia antes da publicação.
5. Publicação, ligada a partir do rodapé, na sua própria URL, com uma data de revisão definida para o próximo ciclo.

Se estiver a executar isto como parte de um projeto mais amplo de preparação EAA/WCAG, a visão geral do Ato Europeu de Acessibilidade e da WCAG é o ponto de partida para questões de âmbito (quem está isento, o que significa “colocado no mercado” para um contrato de serviços), enquanto este artigo cobre especificamente o documento da declaração depois de a auditoria subjacente estar feita.

#Leitura relacionada do agrupamento

• Pilar: WCAG 2.2, BFSG e o Ato Europeu de Acessibilidade: a pilha de conformidade 2026 para WordPress
• Ato Europeu de Acessibilidade e WCAG 2.1: como implementar a acessibilidade digital
• Auditoria de conformidade UE para WordPress: acessibilidade, NIS2/DORA, AI Act