Acessibilidade web significa um website que as pessoas com deficiência conseguem perceber, utilizar e compreender, e com o Ato Europeu da Acessibilidade passou a ser uma obrigação legal para muitas empresas que vendem a consumidores na UE. Na prática, o Ato remete para a norma harmonizada EN 301 549, que por sua vez assenta nas Web Content Accessibility Guidelines (WCAG) do W3C, ao nível AA. Este guia explica quem está abrangido e desde quando, o que as normas exigem, as falhas que encontramos com mais frequência e como corrigi-las, um processo de auditoria numerado, a declaração de acessibilidade e como funciona a fiscalização nos Estados-Membros.
Última atualização: 27 de outubro de 2026.
O que é o Ato Europeu da Acessibilidade?
O Ato Europeu da Acessibilidade é a Diretiva (UE) 2019/882, adotada a 17 de abril de 2019. Define requisitos comuns de acessibilidade para uma lista de produtos e serviços em todo o mercado único da UE, para que uma empresa cumpra um só conjunto de regras em vez de um diferente em cada país.
Por ser uma diretiva, cada Estado-Membro teve de a transpor para a lei nacional até 28 de junho de 2022 e aplicar essas regras a partir de 28 de junho de 2025. Desde 28 de junho de 2025, o Ato Europeu da Acessibilidade aplica-se aos produtos abrangidos colocados no mercado e aos serviços abrangidos prestados a consumidores. O que uma empresa tem de fazer, em concreto, está definido em cada lei nacional, que segue de perto a diretiva mas acrescenta as suas próprias entidades de fiscalização e sanções.
O Ato existe ao lado de um texto mais antigo, a Diretiva relativa à acessibilidade da Web, que abrange os websites e as apps dos organismos do setor público. É o Ato Europeu da Acessibilidade que chega às empresas privadas.
Em resumo: se vende determinados serviços a consumidores na UE, o seu website e a sua app têm de ser acessíveis. A referência é a EN 301 549, que usa o nível AA das WCAG. As microempresas de serviços estão isentas. Cada país aplica a sua própria versão das regras.
Na Odduel, uma agência de criatividade e tecnologia em Barcelona e São Paulo, a acessibilidade entra em cada website desde o primeiro wireframe, e é assim que definimos o âmbito do nosso trabalho de criação de websites. O resto deste guia é o que dizemos aos clientes que nos perguntam em que situação estão.
Quem tem de cumprir o EAA?
O Ato abrange produtos e serviços nomeados, não todos os websites. Do lado dos serviços, os que tocam a maioria dos websites e apps são:
- Serviços de comércio eletrónico: qualquer serviço prestado a consumidores à distância através de um website ou de uma aplicação móvel, e é por isso que a maioria das lojas online fica abrangida.
- Serviços bancários para consumidores, incluindo os websites e as apps através dos quais são oferecidos.
- Livros eletrónicos e o software usado para os ler.
- Serviços de comunicações eletrónicas e os serviços que dão acesso a meios de comunicação audiovisual.
- Elementos de serviços de transporte de passageiros aéreo, rodoviário, ferroviário e por via navegável: websites, apps, bilhetes eletrónicos e informação de viagem em tempo real.
Do lado dos produtos estão artigos como computadores, smartphones, leitores de livros eletrónicos, terminais de pagamento, caixas multibanco e máquinas de venda de bilhetes. Se os fabrica ou importa, o Ato aplica-se ao equipamento e ao seu software, não só a um website.
Uma empresa fora da UE não fica fora do alcance: o que conta é que o serviço seja oferecido a consumidores na UE. Uma empresa que vende apenas a outras empresas, sem serviço dirigido ao consumidor, fica em geral fora do âmbito do comércio eletrónico, embora muitos websites sirvam ambos, e nesse caso a parte destinada ao consumidor está abrangida.
A isenção das microempresas
A diretiva isenta as microempresas que prestam serviços. Na definição da diretiva, uma microempresa emprega menos de dez pessoas e tem um volume de negócios anual ou um balanço total abaixo de um limite baixo fixado no texto. Um pequeno estúdio que vende serviços online pode, por isso, estar fora da obrigação.
Há dois pontos que muitas vezes escapam. A isenção é só para serviços: uma microempresa que fabrica ou vende produtos abrangidos continua a ter de cumprir os requisitos dos produtos, com menos papelada. E estar isento hoje não faz de um website inacessível uma boa ideia, porque uma empresa que cresce para lá do limite passa a estar abrangida, e os clientes com deficiência são clientes de qualquer forma.
Conteúdos e contratos com tratamento especial
A diretiva deixa alguns conteúdos fora dos requisitos: áudio e vídeo pré-gravados publicados antes de 28 de junho de 2025, documentos de escritório publicados antes dessa data, conteúdos arquivados que não foram editados desde então, mapas online em que a informação essencial é disponibilizada de forma acessível, e conteúdos de terceiros que a empresa não financia nem controla. Os contratos de serviços celebrados antes de 28 de junho de 2025 podem continuar inalterados até terminarem, por um máximo de cinco anos.
Uma empresa pode ainda alegar que um requisito imporia um encargo desproporcionado ou alteraria fundamentalmente o serviço. Essa alegação tem de ser avaliada e documentada segundo os critérios da diretiva, e as autoridades podem pedir para a ver. Não é uma dispensa geral.
Que norma se aplica?
A diretiva descreve a acessibilidade em termos funcionais: os conteúdos têm de ser percetíveis, operáveis, compreensíveis e robustos. Para transformar isso em testes, a UE recorre a normas harmonizadas, e para websites e apps a relevante é a EN 301 549, a norma europeia de acessibilidade das tecnologias da informação e comunicação. Cumprir uma norma harmonizada cuja referência está publicada para o Ato dá uma presunção de conformidade.
Para conteúdos web, a EN 301 549 incorpora os critérios de sucesso das Web Content Accessibility Guidelines do W3C nos níveis A e AA. A versão atual da norma assenta nas WCAG 2.1. As mais recentes WCAG 2.2, recomendação do W3C desde outubro de 2023, mantêm os critérios da 2.1 (exceto um critério de análise sintática obsoleto) e acrescentam mais nove, seis deles nos níveis A e AA.
O nosso conselho é construir e testar segundo as WCAG 2.2 AA. Um website que as cumpre cumpre também os critérios 2.1 que a norma testa hoje, e fica pronto para a próxima revisão da EN 301 549 em vez de precisar de uma segunda volta.
| WCAG 2.1 AA | WCAG 2.2 AA | |
|---|---|---|
| Estado | Recomendação do W3C, 2018 | Recomendação do W3C, outubro de 2023 |
| Usada hoje pela EN 301 549 | Sim | Ainda não |
| Foco visível e não oculto | O foco tem de ser visível | O foco também não pode ficar totalmente escondido por barras fixas ou faixas |
| Controlos pequenos | Sem tamanho mínimo no nível AA | Alvos de pelo menos 24 por 24 píxeis CSS, ou espaçamento suficiente |
| Ações de arrastar | Não abrangido no nível AA | Uma alternativa de um só ponteiro ao arrastar |
| Formulários | Etiquetas e ajuda com erros | Também sem voltar a escrever informação já dada |
| Início de sessão | Não abrangido | Nenhum teste de memória ou quebra-cabeças sem alternativa |
| Ajuda | Não abrangido | Opções de ajuda no mesmo lugar em todas as páginas |
O que significam as WCAG 2.2 AA na prática?
As WCAG estão escritas como critérios de sucesso testáveis, agrupados em quatro princípios. Traduzido para o que um visitante vive, o nível AA pede aproximadamente o seguinte:
- Percetível: as imagens têm alternativas em texto, os vídeos têm legendas, o texto tem contraste suficiente com o fundo (4,5 para 1 no texto corrido, 3 para 1 no texto grande e nos elementos de interface), e a página continua a funcionar quando o texto é ampliado para 200% ou o ecrã é estreito.
- Operável: tudo pode ser feito só com o teclado, o foco está sempre visível, nada pisca de forma perigosa, os conteúdos em movimento podem ser parados e os visitantes têm tempo suficiente para agir.
- Compreensível: a página declara o seu idioma, a navegação comporta-se de forma coerente, os formulários têm etiquetas e explicam os erros, e nada muda de contexto sem aviso.
- Robusto: o código expõe corretamente nomes, funções e estados às tecnologias de apoio, como os leitores de ecrã, e as mensagens de estado são anunciadas.
Nada disto exige um website simples ou aborrecido. Os websites que construímos têm movimento, tipografia grande e cor forte; o que muda é que o movimento respeita a preferência de movimento reduzido do visitante, a cor nunca transmite significado sozinha e cada interação tem um caminho pelo teclado. A acessibilidade funciona melhor quando faz parte das regras da identidade: um manual de marca que define pares de cores acessíveis poupa discussões mais tarde.
Quais são as falhas de acessibilidade mais comuns e como se corrigem?
A maioria das auditorias encontra as mesmas falhas vezes sem conta. Vêm de decisões de design tomadas sem as regras em mente e de componentes copiados de um projeto para o seguinte. A tabela lista as que vemos com mais frequência e o que as corrige.
| Falha | Quem afeta | Critério WCAG | Solução |
|---|---|---|---|
| Texto com pouco contraste, sobretudo cinzento sobre branco ou branco sobre cor viva | Baixa visão, visitantes mais velhos, qualquer pessoa ao sol | 1.4.3 Contraste (mínimo) | Definir pares de cores acessíveis nos tokens de design e medir cada novo par |
| Imagens sem texto alternativo útil | Utilizadores de leitores de ecrã | 1.1.1 Conteúdo não textual | Descrever as imagens informativas; dar às decorativas um alt vazio |
| Campos de formulário sem etiqueta, ou com o texto de exemplo como única etiqueta | Utilizadores de leitores de ecrã e de controlo por voz | 1.3.1, 3.3.2, 4.1.2 | Uma etiqueta visível ligada a cada campo; erros em texto junto ao campo |
| Controlos que só funcionam com o rato | Utilizadores de teclado e de manípulos | 2.1.1 Teclado | Usar botões e links verdadeiros; testar cada percurso só com o teclado |
| Contorno de foco removido ou escondido atrás de um cabeçalho fixo | Utilizadores de teclado | 2.4.7, 2.4.11 | Um estilo de foco forte; margem de deslocamento para que o foco nunca fique tapado |
| Títulos usados pelo tamanho, não pela estrutura | Utilizadores de leitores de ecrã | 1.3.1 Informação e relações | Um H1, títulos por ordem, estilos aplicados por classe |
| Links que dizem apenas “clique aqui” ou “ler mais” | Utilizadores de leitores de ecrã | 2.4.4 Finalidade do link | Texto de link que nomeia o destino |
| Vídeos sem legendas | Visitantes surdos e com perda auditiva | 1.2.2 Legendas | Legendas em cada vídeo com fala; transcrições para o áudio |
| Faixas de cookies e janelas que prendem ou saltam o foco | Utilizadores de teclado e de leitores de ecrã | 2.1.2, 2.4.3 | Levar o foco para a janela, mantê-lo lá e devolvê-lo ao fechar |
| Botões de ícone minúsculos e muito juntos | Limitações motoras, utilizadores de telemóvel | 2.5.8 Tamanho do alvo (mínimo) | Alvos de pelo menos 24 por 24 píxeis CSS, ou espaço à volta |
| Animações que não se podem parar | Perturbações vestibulares, dificuldades de atenção | 2.2.2 Colocar em pausa, parar, ocultar | Um controlo de pausa; respeitar a preferência de movimento reduzido |
As ferramentas automáticas apanham algumas, como texto alternativo em falta, pouco contraste e etiquetas em falta. Não conseguem dizer se um texto alternativo faz sentido, se a ordem do teclado é lógica ou se uma mensagem de erro ajuda. É por isso que o processo abaixo junta ferramentas e testes manuais.
Como auditar e corrigir a acessibilidade de um website?
Uma auditoria só é útil se terminar em correções e continuar válida depois da publicação seguinte. É este o processo que seguimos, seja o website nosso ou herdado.
- Definir o objetivo e o âmbito. Acorde as WCAG 2.2 AA e liste os modelos e percursos a testar: página inicial, uma página de conteúdo, uma página de produto ou de serviço, pesquisa, carrinho e checkout, início de sessão, formulários de contacto e a faixa de cookies. Na maioria dos websites, uma dúzia de modelos cobre quase todas as páginas.
- Correr verificações automáticas. Use um motor de regras reconhecido em todos os modelos e em cada versão de idioma. Registe os problemas por critério, não por página, porque a falha de um componente repete-se em todo o lado.
- Testar só com o teclado. Faça cada percurso essencial sem rato: chegar a cada controlo, ver sempre o foco, abrir e fechar menus e janelas, enviar os formulários com erros e sem erros.
- Testar com leitor de ecrã e ampliação. Ouça os percursos principais com pelo menos um leitor de ecrã no computador e outro no telemóvel; depois amplie o texto para 200% e veja numa largura estreita. Verifique títulos, regiões, etiquetas e anúncios.
- Rever conteúdos e multimédia. Verifique textos alternativos, redação dos links, legendas, documentos para descarregar e linguagem simples nas instruções e nos erros.
- Priorizar pelo impacto. Corrija primeiro o que impede uma tarefa (um checkout que não se consegue concluir com o teclado), depois o que a dificulta, depois o resto. A maioria das correções pertence a componentes partilhados e aos tokens de design, por isso uma alteração repara muitas páginas.
- Corrigir e voltar a testar. Repita os mesmos testes nos modelos corrigidos e guarde os resultados com datas, para poder mostrar o que foi encontrado e quando foi corrigido.
- Publicar a declaração e mantê-la no processo de publicação. Escreva a declaração de acessibilidade (abaixo) e acrescente verificações de acessibilidade a cada publicação, ao lado do resto da sua checklist de QA de websites.
Testar com utilizadores com deficiência acrescenta o que nenhuma checklist consegue: saber se o website é, de facto, agradável de usar. Quando o orçamento o permite, uma ronda curta de sessões sobre os percursos principais vale mais do que mais uma análise automática.
A acessibilidade também se cruza com a manutenção. Plugins e temas atualizados sem revisão podem estragar a gestão do foco ou as etiquetas, por isso a mesma disciplina que mantém um website seguro, descrita no nosso guia de segurança WordPress, mantém-no acessível.
Precisa de uma declaração de acessibilidade?
Segundo o Ato Europeu da Acessibilidade, os prestadores de serviços têm de disponibilizar informação sobre a forma como o seu serviço cumpre os requisitos de acessibilidade, nos termos e condições gerais ou noutro local fácil de encontrar, e num formato acessível. A maioria das empresas cumpre isto com uma declaração de acessibilidade ligada a partir do rodapé de todas as páginas.
Uma declaração clara inclui:
- a norma que procura cumprir (WCAG 2.2 AA, através da EN 301 549) e até que ponto o website a cumpre;
- as lacunas conhecidas, com a razão e uma data de correção quando a tiver;
- os conteúdos fora dos requisitos e qualquer encargo desproporcionado documentado;
- como e quando o website foi avaliado pela última vez;
- um contacto através do qual os visitantes possam comunicar um problema ou pedir conteúdos noutro formato, e em quanto tempo responde;
- onde um visitante pode apresentar queixa se a resposta não o satisfizer, o que depende da sua autoridade nacional.
Escreva-a com simplicidade e mantenha-a atualizada. Uma declaração que afirma conformidade total num website com falhas evidentes faz mais mal do que uma honesta que lista o que ainda está a ser corrigido.
Como é aplicado o EAA e quais são as sanções?
Cada Estado-Membro designa as suas próprias autoridades de fiscalização do mercado e fixa as suas próprias sanções, que a diretiva exige que sejam efetivas, proporcionadas e dissuasivas. As entidades, os procedimentos e o nível das sanções variam, por isso, de país para país, e algumas leis nacionais permitem também que organizações de consumidores ou particulares avancem com ações.
Para uma empresa que vende em vários países da UE, a resposta prática é cumprir a norma comum em todo o lado, em vez de acompanhar cada variação nacional. Se precisar das regras exatas de sanções de um mercado, leia a lei de transposição desse país ou pergunte a um advogado que exerça lá: os valores são nacionais e não os citamos aqui.
O que as autoridades podem em geral pedir são provas: a norma que seguiu, os resultados dos testes, a sua declaração e qualquer avaliação de encargo desproporcionado. O registo da auditoria do processo acima é essa prova.
Perguntas frequentes
O Ato Europeu de Acessibilidade aplica-se ao meu website?
Aplica-se se o seu website ou a sua app prestam um serviço abrangido a consumidores na UE, como comércio eletrónico, serviços bancários para consumidores, livros eletrónicos, comunicações eletrónicas ou informação sobre transporte de passageiros. Um website empresarial puramente informativo pode estar fora do âmbito, e as microempresas que prestam serviços estão isentas. Confirme com a lista da diretiva e com a lei de transposição do seu país.
As WCAG 2.2 AA são obrigatórias por lei?
A lei exige acessibilidade, e a norma harmonizada EN 301 549 dá uma presunção de conformidade. Essa norma usa hoje as WCAG 2.1 AA para conteúdos web. As WCAG 2.2 AA incluem esses critérios e acrescentam mais alguns, por isso construir segundo as WCAG 2.2 AA cumpre a norma atual e prepara o website para a próxima revisão.
Um overlay ou plugin de acessibilidade torna o meu website conforme?
Não. Os overlays e as barras de ferramentas mudam a forma como uma página se vê ou se lê, mas não corrigem o código, as etiquetas, a ordem do teclado nem os conteúdos, e alguns interferem com os leitores de ecrã que os visitantes já usam. Um website conforme precisa de ter os modelos e os componentes corrigidos. Os plugins podem ajudar nas verificações durante a edição, mas não substituem o trabalho.
Quanto tempo demora uma auditoria de acessibilidade a um website?
Depende do número de modelos e percursos, mais do que do número de páginas, porque a maioria das falhas está em componentes partilhados. Um website pequeno com poucos modelos pode ser auditado depressa; uma loja grande com contas, pesquisa e checkout demora mais. Um plano fechado surge depois de uma breve análise do website e dos seus percursos essenciais.
O que acontece se o meu website não for acessível?
Arrisca uma ação da autoridade nacional de fiscalização do mercado, que pode exigir correções e aplicar sanções ao abrigo da lei nacional, e em alguns países queixas de consumidores ou de organizações. Igualmente importante: perde clientes que não conseguem concluir uma compra. Corrija primeiro os problemas que bloqueiam e publique uma declaração honesta enquanto o resto é feito.
Se não tem a certeza de que o seu website cumpre o Ato Europeu da Acessibilidade, comece por uma auditoria aos modelos e percursos que mais importam e depois corrija os componentes partilhados que causam a maioria das falhas. Construímos websites acessíveis desde o primeiro wireframe e reparamos os herdados no âmbito do nosso trabalho de criação de websites. Fale connosco sobre o seu website e dizemos-lhe com franqueza em que situação está.
Leituras recomendadas: Checklist de auditoria UX: o que verificar e como fazê-la em sete passos.
