WCAG 2.2: Guia em Português com Checklist AA para Entidades Públicas

A WCAG 2.2 é a versão actual das regras internacionais que dizem quando um site pode ser usado por pessoas com deficiência: quem não vê e ouve a página num leitor de ecrã, quem não ouve e depende de legendas, quem não consegue usar um rato, quem amplia o texto para o conseguir ler. Em Portugal, estas regras deixaram de ser boa prática há anos. Para as entidades públicas são uma obrigação legal desde 2019, e para uma parte das empresas privadas passaram a sê-lo em junho de 2025.

O problema é que quase tudo o que existe em português sobre o tema está escrito para o Brasil, pára na versão 2.1, ou explica os princípios sem nunca chegar ao que um responsável de informática precisa de saber na segunda-feira de manhã: que critérios tem de cumprir, que lei o obriga a quê, e como se testa. Este guia faz esse caminho, com a norma do W3C e a legislação portuguesa citadas na fonte, e termina numa lista de verificação com os 55 critérios de nível AA, organizada para ser usada numa auditoria.

O Que É a WCAG

A WCAG não é uma lista de boas intenções. Cada critério é escrito para ser testado com um resultado de passa ou falha, e é por isso que a legislação europeia se apoia nela: um regulador consegue verificar um critério, não consegue verificar uma recomendação vaga.

Quem Publica a WCAG e Porque Há Várias Versões

A norma é publicada pelo W3C como Recomendação, o estatuto mais alto que o consórcio dá a um documento. A WCAG 2.2 foi publicada a 5 de outubro de 2023, e a versão em vigor da Recomendação tem data de 12 de dezembro de 2024. A anterior, a WCAG 2.1, é de junho de 2018.

As versões somam-se em vez de se substituírem. O próprio W3C escreve que o conteúdo conforme à WCAG 2.2 é também conforme à 2.0 e à 2.1, e que a publicação da 2.2 não revoga as anteriores, embora aconselhe a usar a versão mais recente. Na prática, isto quer dizer que quem constrói hoje para a 2.2 cumpre automaticamente o que a lei portuguesa pede, e fica preparado para quando a referência legal subir.

Critérios de Sucesso, Técnicas e Falhas

A WCAG tem três camadas, e confundi-las é a causa de metade das discussões sobre relatórios de acessibilidade:

• Critérios de sucesso: são a norma. Cada um tem um número (por exemplo, 1.4.3), um nível (A, AA ou AAA) e um texto que decide se a página passa ou falha.
• Técnicas: são formas documentadas de cumprir um critério, com códigos como H44 (associar etiquetas a campos com o elemento label). São recomendações. Uma página pode cumprir o critério por outro caminho.
• Falhas: são padrões documentados que fazem falhar um critério, com códigos como F65 (imagem sem atributo alt). Se a falha está lá, o critério falha.

Por cima disto, o W3C publica as regras ACT (Accessibility Conformance Testing), que dizem como se verifica cada critério de forma repetível. É por isso que duas ferramentas sérias devem chegar ao mesmo veredicto sobre a mesma página. Quando um relatório diz que uma técnica não foi seguida, isso sinaliza um problema; quando diz que uma regra ACT falhou, o critério falhou.

Os Quatro Princípios da WCAG

Os critérios da WCAG estão organizados em quatro princípios. A lei portuguesa copia-os quase à letra: o artigo 5.º do Decreto-Lei n.º 83/2018 obriga as entidades públicas a tornar os sites e aplicações móveis perceptíveis, operáveis, compreensíveis e robustos, com uma alínea para cada um.

Perceptível

A informação tem de chegar ao utilizador por pelo menos um sentido que ele tenha. Uma fotografia da presidente da câmara num evento precisa de texto alternativo para quem não a vê; um vídeo da sessão da assembleia municipal precisa de legendas para quem não o ouve; um texto cinzento-claro sobre branco tem de ter contraste suficiente para quem vê mal. São 20 critérios de nível A e AA, e é aqui que estão as falhas mais frequentes nos sites municipais, como se verá abaixo.

Operável

Tudo o que se faz com rato tem de se conseguir fazer com teclado, e ninguém pode ficar preso. Menus que só abrem ao passar o rato, janelas de cookies que não fecham com a tecla Escape, carrosséis que andam sozinhos sem botão de pausa, e sessões do balcão online que expiram sem aviso são falhas deste princípio. Também são 20 critérios de nível A e AA.

Compreensível

O conteúdo e o funcionamento têm de ser previsíveis. A página tem de declarar a língua em que está escrita, os formulários têm de dizer o que esperam e explicar os erros, e a navegação tem de aparecer pela mesma ordem em todas as páginas. É o princípio que mais cresceu na 2.2, com três dos nove critérios novos. São 13 critérios de nível A e AA.

Robusto

O código tem de ser lido de forma fiável pelos navegadores e pelas tecnologias de apoio. Na prática, cada controlo tem de anunciar o que é (botão, ligação, caixa de verificação), como se chama e em que estado está, e as mensagens que aparecem sem mudar de página («formulário enviado», «3 resultados») têm de chegar ao leitor de ecrã. Com a saída do critério 4.1.1, ficam 2 critérios de nível A e AA.

Níveis A, AA e AAA: O Que Cada Um Exige

Cada critério tem um nível, e os níveis são cumulativos. Uma página é conforme ao nível A quando cumpre todos os critérios de nível A; ao nível AA quando cumpre todos os de A e de AA; ao nível AAA quando cumpre todos os três. Não há conformidade parcial a um nível: uma página com um único critério AA por cumprir não é conforme ao nível AA, por melhor que seja o resto.

Como Se Conta a Conformidade

A norma tem regras sobre o que se avalia, e três delas mudam a forma como se planeia um projecto:

• Páginas inteiras: a conformidade é da página completa, e não se consegue excluindo uma parte dela. Um widget de terceiros que falha faz falhar a página onde está.
• Processos completos: se uma página faz parte de uma sequência (um requerimento online em quatro passos, um pagamento), todas as páginas da sequência têm de ser conformes. Um passo inacessível torna o processo inteiro não conforme.
• Todas as variações: uma página responsiva conta como todas as versões que apresenta. A versão de telemóvel tem de ser conforme tal como a de computador.

Porque Ninguém Exige o Nível AAA

O próprio W3C escreve, na secção de conformidade da norma, que não recomenda exigir o nível AAA como política geral para sites inteiros, porque há conteúdos em que não é possível cumprir todos os critérios AAA. Um exemplo: o critério 1.2.6 pede interpretação em língua gestual para todo o vídeo pré-gravado. Faz sentido num vídeo de serviço ao munícipe; não faz sentido exigi-lo a cada vídeo de arquivo. Por isso a legislação europeia fixa o nível AA, e os critérios AAA tratam-se como melhorias a aplicar onde servem.

O Que Mudou na WCAG 2.2

Segundo a página What’s New in WCAG 2.2 do W3C, a nova versão acrescenta nove critérios de sucesso e retira um. Os restantes critérios da 2.0 e da 2.1 ficam essencialmente iguais.

Os Nove Critérios Novos da WCAG 2.2

Seis dos nove são de nível A ou AA, e portanto entram numa auditoria AA feita contra a 2.2:

Os nomes em português são tradução nossa; a referência normativa é sempre o número do critério.

O Critério 4.1.1 Saiu da Norma

O critério 4.1.1 (Parsing) pedia que o HTML não tivesse erros de construção, como atributos duplicados ou elementos mal fechados. O W3C retirou-o na 2.2 e explica porquê na própria norma: foi criado porque as tecnologias de apoio liam o HTML directamente, isso deixou de acontecer, e os problemas que ele cobria desapareceram ou são apanhados por outros critérios. Um HTML com erros continua a ser mau sinal; deixou de ser, por si só, uma falha de conformidade na 2.2.

WCAG 2.2 ou WCAG 2.1: Qual Seguir em Portugal

A referência legal em Portugal continua a ser a WCAG 2.1 (a secção seguinte explica porquê). A recomendação prática é construir e testar contra a 2.2 e reportar contra a 2.1. Como a 2.2 inclui toda a 2.1, um site conforme à 2.2 cumpre a lei. O único cuidado vem do próprio W3C: quem está obrigado por uma política a reportar contra a 2.1 pode ter de continuar a testar o 4.1.1, porque para a 2.1 ele ainda conta. A declaração de acessibilidade de uma entidade pública deve, por isso, continuar a referir a WCAG 2.1 AA.

O Que a Lei Exige em Portugal

Há dois diplomas, com universos e mecanismos diferentes. Tratá-los como se fossem o mesmo leva a erros nos dois sentidos: empresas que julgam estar abrangidas pelo regime das entidades públicas, e entidades públicas que julgam que a lei de 2022 lhes deu mais prazo.

Entidades Públicas: O Decreto-Lei n.º 83/2018

O Decreto-Lei n.º 83/2018, de 19 de outubro, transpõe a Directiva (UE) 2016/2102. O artigo 2.º aplica-o ao Estado, às regiões autónomas, às autarquias locais, aos institutos públicos, às entidades administrativas independentes, às fundações e associações públicas, ao sector público empresarial, a organizações não governamentais que prestam serviços essenciais ao público ou dirigidos a pessoas com deficiência, a instituições de ensino com financiamento público (no conteúdo relativo a funções administrativas essenciais) e aos organismos de direito público definidos no Código dos Contratos Públicos.

O âmbito é largo também no conteúdo. O artigo 3.º inclui texto, imagens, documentos e formulários descarregáveis, multimédia, mapas, processos de autenticação, serviços, meios de pagamento e formulários online. Um PDF de um edital está abrangido tanto quanto a página que o liga. As excepções estão no mesmo artigo, e incluem documentos de escritório publicados antes de 23 de setembro de 2018 (salvo se forem necessários para processos administrativos pendentes), vídeo pré-gravado publicado antes de 23 de setembro de 2020, conteúdos transmitidos em directo e conteúdos de terceiros que a entidade não financia nem controla.

O decreto não escreve «WCAG 2.1 AA» no texto. O caminho é este:

• o artigo 7.º presume que um site cumpre os requisitos se cumprir as normas harmonizadas publicadas pela Comissão Europeia no Jornal Oficial da União Europeia;
• a Decisão de Execução (UE) 2021/1339 da Comissão, em vigor, fixa como norma harmonizada para sites e aplicações móveis a EN 301 549 V3.2.1 (2021-03);
• a cláusula 9 dessa norma, na versão publicada pelo ETSI, diz que a conformidade com a WCAG 2.1 de nível AA equivale a cumprir as cláusulas 9.1 a 9.4 e os requisitos de conformidade da 9.6.

É por isso que a acessibilidade web do sector público português se mede contra a WCAG 2.1 AA. A entidade que o decreto encarrega do acompanhamento, a AMA (hoje ARTE, Agência para a Reforma Tecnológica do Estado), usa essa referência nos requisitos do Selo de Usabilidade e Acessibilidade, que falam em «avaliação automática da norma WCAG 2.1 AA».

Quanto a datas, o artigo 19.º pôs a obrigação a produzir efeitos a 23 de setembro de 2019 para sites publicados a partir de 23 de setembro de 2018, a 23 de setembro de 2020 para os mais antigos, e a 23 de junho de 2021 para todas as aplicações móveis. Não há hoje nenhum site público em período de transição.

O decreto obriga ainda a publicar uma declaração de acessibilidade, a avaliar o site pelo menos uma vez por ano e a disponibilizar um mecanismo para qualquer pessoa reportar problemas. Tudo isso está detalhado no nosso guia da declaração de acessibilidade e do Selo. O decreto não fixa coimas próprias, mas o incumprimento tem consequências, que explicamos mais abaixo, em «O Que Custa Não Cumprir».

Empresas Privadas: O Decreto-Lei n.º 82/2022

O Decreto-Lei n.º 82/2022, de 6 de dezembro, transpõe a Directiva (UE) 2019/882, conhecida como Acto Europeu da Acessibilidade. Produz efeitos desde 28 de junho de 2025 para os produtos colocados no mercado e os serviços prestados aos consumidores a partir dessa data.

Do lado dos serviços, o artigo 2.º abrange os serviços de comunicações electrónicas, o acesso a serviços de comunicação social audiovisual, os sites, aplicações e bilhética electrónica do transporte de passageiros aéreo, de autocarro, ferroviário, marítimo e fluvial, os serviços bancários e financeiros destinados a consumidores, os livros electrónicos e o comércio electrónico. As microempresas que prestam estes serviços estão excluídas.

Há três diferenças em relação ao regime das entidades públicas:

• O decreto não nomeia a WCAG nem a EN 301 549. Presume a conformidade de quem cumprir normas harmonizadas publicadas no Jornal Oficial (artigo 15.º). A referência técnica que o mercado usa para sites é a EN 301 549, que corresponde à WCAG 2.1 AA; não conseguimos confirmar a publicação no Jornal Oficial de uma norma harmonizada específica ao abrigo deste regime.
• A informação vai para os termos e condições. O Anexo II obriga o prestador a explicar, nos termos e condições gerais ou em documento equivalente, como o serviço cumpre os requisitos de acessibilidade.
• Há fiscalização sectorial. O artigo 28.º distribui-a: a ANACOM para o comércio electrónico e as comunicações electrónicas, o Banco de Portugal para a maior parte dos serviços bancários, a CMVM para os serviços de investimento, entre outras.

Quem Está Obrigado a Quê

O Que Custa Não Cumprir

Os dois regimes tratam o incumprimento de forma diferente, e os valores também são diferentes.

Entidades públicas. O Decreto-Lei n.º 83/2018 não fixa coimas próprias. O seu artigo 13.º liga-o à Lei n.º 46/2006, que proíbe a discriminação em razão da deficiência. Um serviço online que uma pessoa com deficiência não consegue usar pode constituir prática discriminatória: o artigo 4.º dessa lei inclui «a recusa de fornecimento ou o impedimento de fruição de bens ou serviços» e «a adopção de medidas que limitem o acesso às novas tecnologias». O artigo 9.º, n.º 2, pune a prática por uma pessoa colectiva, de direito público ou privado, com coima de 20 a 30 vezes a retribuição mínima mensal garantida. Com os 920€ fixados para 2026 no continente pelo Decreto-Lei n.º 139/2025, são 18.400€ a 27.600€. A reincidência eleva os dois limites para o dobro, 36.800€ a 55.200€ (artigo 11.º), a negligência também é punível (artigo 9.º, n.º 3), e o artigo 10.º admite sanções acessórias, entre elas a publicidade da decisão condenatória. As queixas podem ser apresentadas ao Instituto Nacional para a Reabilitação, que as encaminha para a entidade competente (artigo 13.º do DL 83/2018). O «pode» conta: a coima exige que se demonstre uma prática discriminatória num caso concreto.

Empresas abrangidas pelo DL 82/2022. Aqui há um regime próprio, no artigo 29.º do Decreto-Lei n.º 82/2022. Prestar um serviço que não cumpre os requisitos de acessibilidade é contraordenação muito grave (n.º 1, alínea a), e n.º 4): para uma pessoa colectiva, a coima vai de 24.000€ até ao máximo do regime geral das contraordenações, 44.891,81€ (artigo 17.º, n.º 2, do Decreto-Lei n.º 433/82). Não elaborar a informação de acessibilidade exigida no anexo II é contraordenação grave, de 12.000€ a 24.000€. Por negligência, os limites descem para metade (n.º 6), e a condenação é sempre publicada em dois jornais de âmbito nacional, a expensas do infractor (n.º 9). A fiscalização é sectorial (artigo 28.º): a ANACOM no comércio electrónico e nas comunicações electrónicas, o Banco de Portugal e a CMVM nos serviços financeiros, a AMT e a ANAC nos transportes de passageiros.

Lista de Verificação WCAG 2.2 AA para Entidades Públicas

A lista seguinte tem os 55 critérios de nível A e AA da WCAG 2.2, pela ordem da norma, com o que verificar num site municipal e a forma de o testar. «Ferramenta + manual» quer dizer que um validador de acessibilidade como o AccessMonitor assinala parte das falhas, e o resto exige confirmação humana; «Manual» quer dizer que só uma pessoa a usar o site as encontra. Os critérios marcados como novos entram só numa auditoria contra a 2.2.

Como Testar a Acessibilidade de um Site

O Decreto-Lei n.º 83/2018 define no artigo 9.º a metodologia que as entidades públicas têm de seguir: uma avaliação automática e uma avaliação manual são obrigatórias, e os testes com pessoas com deficiência são recomendados. As três fazem coisas diferentes, e nenhuma substitui as outras.

Avaliação Automática: O Que o AccessMonitor Apanha

O decreto pede uma avaliação automática a uma amostra que inclua, no mínimo, a página inicial e todas as páginas ligadas a partir dela. A ferramenta oficial é o AccessMonitor, gratuito, que assenta no motor QualWeb da Faculdade de Ciências da Universidade de Lisboa e dá uma pontuação de 0 a 10 por página. Outras ferramentas usadas no mercado incluem o axe DevTools, o WAVE e o Lighthouse do Chrome.

Avaliação Manual: Teclado, Zoom e Leitor de Ecrã

O decreto manda fazer a avaliação manual com a lista de verificação publicada pela ARTE, a checklist «10 aspetos críticos de acessibilidade funcional», disponível no kit do Selo no GitHub. São 23 verificações em dez áreas: menus de navegação, títulos, tabelas de dados, formulários, imagens, contraste, leitores multimédia, estrutura da página, janelas modais e ficheiros PDF. Cada verificação indica os critérios WCAG a que corresponde.

Para ir além da checklist, este é o percurso mínimo que fazemos numa auditoria manual, página a página:

1. Percorrer a página só com teclado.Tab do início ao fim, Shift+Tab para trás, Enter e Espaço nos controlos, Escape nas janelas. Anotar onde o foco desaparece, fica preso ou salta sem lógica.
2. Ampliar até 400%.Num portátil, o zoom de 400% equivale aos 320 píxeis CSS do critério 1.4.10. Nada pode obrigar a deslizar para os lados, e nada se pode sobrepor.
3. Ler a página com um leitor de ecrã.NVDA no Windows (gratuito) ouVoiceOver no Mac e no iPhone. Navegar por títulos, por ligações e por campos de formulário, e ouvir se cada coisa se anuncia pelo que é.
4. Medir o contraste onde a ferramenta não chega.Texto sobre fotografia, texto de exemplo nos campos, ícones e setas de carrossel, estados de foco e de erro.
5. Completar os processos de ponta a ponta.Um requerimento, uma inscrição, um pagamento. A conformidade conta-se no processo inteiro, e é nos passos do meio que aparecem as falhas.
6. Abrir os documentos.Um PDF digitalizado sem texto seleccionável falha o primeiro requisito do ponto 10 da checklist: no mínimo, tem de ser possível extrair o texto.

Testes com Utilizadores

O artigo 9.º recomenda testes de usabilidade com pessoas com deficiência, com pelo menos uma tarefa e uma tipologia de utilizadores. O Selo Ouro torna-os obrigatórios: mínimo de 6 participantes, 4 deles com deficiência, de preferência da mesma tipologia. São os testes que encontram o que nenhuma lista prevê, porque medem se a pessoa consegue fazer a tarefa, e não se o código cumpre um critério.

Falhas Comuns, com Exemplos Reais

Os números desta secção vêm do estudo que publicámos em agosto de 2026 sobre os sites dos 308 municípios portugueses. Não são estimativas: são falhas medidas, com a data e o método publicados no próprio estudo.

O Que as Ferramentas Encontram

Na avaliação automática que corremos à página inicial das 70 entidades com operação financiada, a 19 de agosto de 2026, as regras de conformidade que mais falharam repetem-se de câmara para câmara:

• Contraste de texto abaixo do mínimo (critério 1.4.3): 28 de 70. Quase sempre texto cinzento-claro, texto branco sobre fotografia, ou a cor da marca aplicada a texto pequeno.
• Ampliação bloqueada em dispositivos móveis (critério 1.4.4): 23 de 70. Uma linha no cabeçalho da página, user-scalable=no ou maximum-scale=1, impede o munícipe de ampliar no telemóvel. Corrige-se num minuto.
• Componentes ARIA sem a estrutura que a norma exige (critérios 1.3.1 e 4.1.2): 14 de 70. Separadores e menus que declaram um papel sem ter os elementos que esse papel pressupõe.

O Que Só Aparece a Quem Usa o Site

A 2 de agosto de 2026 abrimos os 308 portais e usámo-los como um munícipe os usaria: com Tab, com Escape, com a janela estreita e com a preferência de movimento reduzido ligada. Destes, 298 puderam ser percorridos até ao fim. Nenhuma destas barreiras aparece num relatório automático:

• Controlos feitos como ligação em vez de botão, em 157 de 298 sites. O leitor de ecrã anuncia uma ligação que leva a outra página, e não leva (critério 4.1.2).
• Conteúdo que muda sozinho sem comando de pausa, em 59 de 298 (critério 2.2.2).
• Página que não se reajusta num ecrã estreito, em 57 de 298 (critério 1.4.10).
• Campos cuja única etiqueta é o texto de exemplo, em 43 de 298: desaparece quando se começa a escrever (critério 3.3.2).
• Foco do teclado invisível, em 26 de 298 (critério 2.4.7).
• Janelas sobrepostas que não fecham com Escape, em 16 de 298, e que não fecham de maneira nenhuma, em 11.
• Foco preso sem saída, em 4 de 298 (critério 2.1.2), a falha mais grave que existe para quem navega por teclado.

Há ainda um caso que mostra bem o limite das ferramentas: 10 dos 308 sites declaram a língua errada, um código inválido ou nenhuma língua. Seis portais em português declaram-se em inglês, e um leitor de ecrã lê «Câmara Municipal» com fonética inglesa. As regras automáticas verificam se a página declara uma língua, não se é a língua em que está escrita. Falha o critério 3.1.1, de nível A, e corrige-se com um atributo no modelo do site.

Por Onde Começar numa Câmara Municipal

Se é responsável pelo site de uma entidade pública e não sabe em que ponto está, a sequência que recomendamos tem quatro passos, e os três primeiros não custam nada:

• Medir a página inicial e as ligadas a partir dela no AccessMonitor, e guardar o relatório com data. É a avaliação automática que o artigo 9.º exige.
• Fazer a checklist dos 10 aspetos críticos sobre uma amostra de páginas que inclua os formulários e os processos de serviço online.
• Publicar ou actualizar a declaração de acessibilidade com esses dois resultados, pelo gerador oficial. O nosso guia da declaração de acessibilidade explica cada campo.
• Corrigir no modelo do site, e não página a página, começando pelas falhas de nível A.

Se preferir começar com uma segunda opinião, fazemos uma análise gratuita da acessibilidade do site de entidades públicas, com o mesmo motor da ferramenta oficial e a verificação manual que as ferramentas não fazem. Pode pedi-la pela nossa página de serviços para o setor público. Quando o problema está no próprio site, o nosso serviço de web design pode construir o site novo para o nível AA desde o primeiro modelo.

Perguntas Frequentes sobre a WCAG