Como auditar a acessibilidade do teu site em 2 horas: stack open-source e checklist EAA

Pela equipa da Kiwop · Agência Digital especializada em Desenvolvimento de Software e Inteligência Artificial aplicada · Publicado a 7 de maio de 2026 · Última atualização: 7 de maio de 2026

TL;DR — O prazo da European Accessibility Act foi 28 de junho de 2025. A maioria dos sites continua sem cumprir. Este post dá-te o framework prático: 5 ferramentas open-source que cobrem ~70% das falhas automatizáveis, uma auditoria completa em 2 horas, e um checklist EAA priorizado por impacto legal. Sem consultores, sem orçamento especial. Apenas stack testado e comandos copiáveis.

Quando a European Accessibility Act entrou em vigor a 28 de junho de 2025, a reação mais comum nas equipas técnicas foi: "vemos isso semana que vem". Dez meses depois, a maioria desses sites continua igual. O relatório WebAIM Million 2024 confirmou-o antes mesmo do prazo: 94,8% das páginas de início analisadas tinha falhas WCAG detetáveis automaticamente.

O problema não é falta de vontade. É falta de um ponto de entrada claro. Sabes que tens de cumprir WCAG 2.2 AA, sabes que há ferramentas, mas não tens claro por onde começar, quanto tempo requer, nem como priorizar o que encontrares.

Este artigo é esse ponto de entrada. Se já leste o nosso guia sobre a normativa EAA, prazos e sanções, isto é o passo seguinte: o procedimento técnico concreto. Se não o leste, fá-lo primeiro — aqui assumimos que tens claro o que a lei te exige e focamo-nos em como o executar.

Porque auditar AGORA (e não semana que vem)

O estado real do cumprimento EAA em 2026

O prazo passou. Não é uma ameaça futura: a EAA já é lei aplicável em todos os estados membros da UE que transpuseram a diretiva antes de 28 de junho de 2025. E os números de cumprimento são alarmantes.

O WebAIM Million 2024 analisou as 1.000.000 páginas de início mais visitadas. Resultado: 94,8% tinha pelo menos uma falha WCAG 2.1 AA detetável automaticamente — e isso antes de contar as falhas que só aparecem na revisão manual. Os erros mais comuns: baixo contraste de cor (81% das páginas), texto alternativo ausente (54,5%), etiquetas de formulário em falta (48,6%), links vazios (44,6%) e botões sem nome acessível (28,2%).

Dito de outra forma: quase com certeza o teu site tem todos esses problemas. A pergunta não é se cumpres, mas quantos critérios incumpres e com que gravidade.

O risco legal concreto

O portal oficial da Comissão Europeia sobre a EAA é claro: a normativa aplica a qualquer empresa que ofereça produtos ou serviços digitais a consumidores na UE, independentemente da sua sede. As sanções são fixadas por cada estado membro, mas a diretiva exige que sejam "efetivas, proporcionadas e dissuasoras". Em vários países já se contemplam multas de até 100.000 euros por infração.

Para além das multas: qualquer pessoa com deficiência que não consiga aceder ao teu serviço pode apresentar uma queixa formal junto do organismo de supervisão do seu país. O ónus da prova recai sobre a empresa — tens de demonstrar que cumpres, não são eles que demonstram que não cumpres.

O que exige o regulador (e o que não exige)

O que exige é conformidade com WCAG 2.2 nível AA e uma declaração de acessibilidade pública. O que não exige é perfeição total nem uma auditoria anual assinada por uma empresa certificadora. Exige um nível de diligência razoável, documentado.

O que não te salva: um overlay JavaScript que se sobrepõe ao teu site prometendo acessibilidade automática. A FTC multou a accessiBe em 1 milhão de dólares por publicidade enganosa exatamente nesse ponto. Nenhum organismo regulador aceita um overlay como evidência de cumprimento.

O primeiro passo real dessa diligência é a auditoria. E podes fazê-la em 2 horas com as ferramentas certas.

O stack: 5 ferramentas open-source que cobrem ~70% do WCAG 2.2 AA

Antes de ver o processo, compreende o limite fundamental de qualquer ferramenta automática: detetam aproximadamente 30-40% dos problemas reais de acessibilidade. É o que diz o guia de auditorias de acessibilidade do W3C. O resto requer revisão manual — navegação por teclado, leitores de ecrã, julgamento humano.

Porque começar então com ferramentas automáticas? Porque te permitem eliminar sistematicamente a camada mais grossa de erros em minutos, libertando tempo para a revisão manual onde está realmente o valor.

axe-core (Deque) — o motor padrão da indústria

axe-core é a biblioteca open-source da Deque Systems que hoje alimenta praticamente todas as ferramentas de testing de acessibilidade da indústria. É usado pelo Chrome DevTools, Storybook, Playwright, Cypress e dezenas de frameworks de CI. Não é uma opção entre muitas: é o motor.

A sua principal vantagem não é a cobertura — é a taxa de falsos positivos praticamente zero. Quando axe reporta um erro, é um erro real. Quando não reporta nada, não significa que estás limpo; significa que os erros que não deteta estão nesse 60-70% que precisa de revisão manual.

Podes usar axe de três formas:

Como extensão de navegador (axe DevTools Free): instala a extensão no Chrome ou Firefox, abre a tua página, executa a análise. Resultado em segundos. Zero configuração. Ideal para o primeiro contacto.

Como biblioteca em testes: integra axe-core diretamente na tua suite de testes com Playwright ou Cypress:

Via CLI com @axe-core/cli:

Lighthouse — o complemento gratuito do Chrome

Lighthouse inclui uma auditoria de acessibilidade no seu relatório padrão, baseada também em axe-core, mas com cobertura adicional de métricas de desempenho e algumas verificações próprias.

A sua pontuação de acessibilidade (0-100) não equivale a percentagem de cumprimento WCAG. É uma medida relativa que serve como referência. O que é realmente útil é a lista de issues categorizada que gera.

Podes executá-lo a partir de:

• Chrome DevTools → Lighthouse → Categoria "Acessibilidade"
• CLI: npx lighthouse https://o-teu-site.com --only-categories=accessibility --output json
• PageSpeed Insights: https://pagespeed.web.dev/ (gratuito, sem instalar nada)

A documentação oficial de Lighthouse de acessibilidade da Google documenta exatamente o que verifica cada critério e como calcula a pontuação. Lê-a uma vez para não interpretar mal os resultados.

Pa11y — auditoria a partir de CLI/CI

Pa11y é a ferramenta de linha de comandos desenhada para se integrar em pipelines de CI/CD. Pode auditar uma única URL, um sitemap completo ou uma lista de páginas, e exportar resultados em múltiplos formatos.

Pa11y usa htmlcs por defeito, mas pode configurar-se para usar axe-core como motor:

A vantagem do Pa11y sobre executar axe manualmente é que gere bem páginas com JavaScript assíncrono, autenticação básica e sites de múltiplas páginas sem ter de escrever scripts próprios.

NVDA + VoiceOver — os leitores de ecrã reais

Nenhuma ferramenta automática pode substituir passar 20 minutos a navegar no teu site com um leitor de ecrã. Os resultados são sempre reveladores — e sempre diferentes do que esperavas.

NVDA (Windows, gratuito): o leitor de ecrã mais usado em ambientes Windows. Descarrega-o em nvaccess.org. Os atalhos fundamentais para uma auditoria rápida:

VoiceOver (macOS/iOS, incluído no sistema): ativa-o com Cmd + F5. Para uma auditoria rápida em macOS:

O que procuras com ambos os leitores: anuncia corretamente o tipo de cada elemento (botão, link, campo)? Os formulários têm etiquetas? As imagens têm alt útil? A ordem de leitura faz sentido?

WAVE (extensão de browser) — verificações visuais rápidas

A extensão WAVE da WebAIM sobrepõe ícones visuais diretamente sobre a página indicando erros, alertas e elementos estruturais. É a forma mais rápida de ter uma visão visual dos problemas sem sair do navegador.

Especialmente útil para:

• Ver de relance a hierarquia de headings (saltas de H1 para H4?)
• Detetar zonas de baixo contraste em contexto visual
• Identificar formulários sem label antes de executar axe
• Verificar que os landmarks ARIA estão bem definidos (header, nav, main, footer)

Não a uses como ferramenta principal — tem mais falsos positivos do que axe. Usa-a como primeiro olhar visual antes de executar as outras.

Passo a passo: a tua primeira auditoria em 2 horas

Este protocolo cobre as páginas mais críticas do teu site: home, uma página de listagem, uma página de detalhe, e o fluxo de conversão principal (contacto, registo ou compra). Com as 2 horas distribuídas assim:

Minuto 0-15: setup → Minuto 15-45: automatização → Minuto 45-90: revisão manual → Minuto 90-120: priorização e relatório

Minuto 0-15: setup

Antes de lançar ferramentas, define exatamente que páginas vais auditar. Uma auditoria que tenta cobrir todo o site de uma vez acaba sem cobrir nada bem.

Lista mínima recomendada para uma primeira auditoria:

1. Home (/)
2. Uma página de listagem ou categoria representativa
3. Uma página de detalhe ou serviço representativa
4. Página de contacto ou formulário principal
5. Uma página de checkout ou registo (se aplicável)

Com essa lista, instala as ferramentas:

Instala também a extensão WAVE no Chrome ou Firefox, e descarrega NVDA se estás em Windows (ou ativa VoiceOver em macOS com Cmd + F5).

Minuto 15-45: execução automatizada (axe + Lighthouse + Pa11y)

Executa as três ferramentas sobre cada URL da tua lista. A ordem importa: começa com axe porque o seu output é o mais limpo, depois Lighthouse para a vista de desempenho + acessibilidade combinada, e Pa11y para validar com um segundo motor.

Enquanto os scripts correm, abre cada URL no Chrome com a extensão WAVE ativa. Anota visualmente os padrões que vês antes de leres os relatórios.

Quando terminarem os scripts, abre os JSON com qualquer visualizador ou simplesmente conta as violações:

Minuto 45-90: testes manuais com leitores de ecrã

Esta é a parte que mais acrescenta e que mais costumam saltar. Não a saltes.

Protocolo de 20 minutos com NVDA ou VoiceOver (repete para cada página crítica):

1. Navega apenas com Tab desde o início da página. O primeiro elemento é "saltar para o conteúdo principal" (skip link)? O foco é visível em todo o momento? A ordem faz sentido lógico?

1. Abre a lista de headings (Insert + F7 no NVDA, rotor no VoiceOver). Há um H1? A hierarquia é coerente? Há headings em elementos que visualmente não são headings?

1. Ativa o modo formulário se houver formulários. Preenche o formulário usando apenas o teclado. Cada campo anuncia a sua etiqueta? Os erros de validação são anunciados corretamente? Consegues enviar o formulário?

1. Navega pelos links (tecla K no NVDA). Todos os links têm texto descritivo fora de contexto? Nenhum diz "clica aqui", "ver mais" ou "ler"?

1. Ouve as imagens. Quando o foco chega a uma imagem, o texto alternativo descreve o seu conteúdo ou função? As imagens decorativas são ignoradas (alt="")?

Documenta cada problema que encontrares com: URL, elemento afetado, critério WCAG que incumpre, e prioridade (veremo-la no passo seguinte).

Minuto 90-120: priorização e relatório

Tens duas fontes de issues: os relatórios automáticos e as tuas notas manuais. O trabalho agora é unificá-los e priorizá-los por impacto legal e de utilizador.

Não tentes resolver nada ainda. O objetivo das 2 horas é diagnóstico, não remediação.

Para o relatório, cria um documento com esta estrutura mínima:

Como interpretar os resultados: priorização por impacto legal

O maior erro ao interpretar uma auditoria de acessibilidade é tratar todos os issues da mesma forma. Um baixo contraste num texto de rodapé tem consequências muito distintas de um formulário de registo que não seja operável com teclado.

A matriz de priorização combina dois eixos: severidade para o utilizador (bloqueia o uso?) e exposição legal (afeta fluxos críticos que o regulador examinaria primeiro?).

Issues críticos (bloqueiam o cumprimento)

Um issue é crítico quando impede completar uma tarefa a um utilizador com deficiência ou quando afeta um fluxo que o regulador examinaria prioritariamente (registo, compra, contacto, acesso a serviço).

Os candidatos habituais:

• Formulários não acessíveis por teclado: o critério WCAG 2.1.1 (Teclado) é de nível A — o nível mínimo. Não cumpri-lo no formulário de contacto é um bloqueio de cumprimento direto.
• Imagens funcionais sem alt: uma imagem que é um link ou um botão sem texto alternativo deixa o utilizador de leitor sem informação para agir. Critério 1.1.1.
• Botões sem nome acessível: <button><svg>...</svg></button> sem aria-label. O botão existe, o utilizador sabe que está lá, mas não sabe o que faz. Critério 4.1.2.
• Vídeo com áudio sem legendas: se tens vídeos com informação em áudio, o critério 1.2.2 exige legendas sincronizadas. A ausência é bloqueante e de alta visibilidade.

Issues maiores (alto risco de queixa)

Um issue é maior quando dificulta significativamente o uso mas não o bloqueia completamente, ou quando afeta páginas de alta visibilidade embora o impacto individual seja parcial.

• Baixo contraste no texto principal: critério 1.4.3. Um rácio inferior a 4,5:1 no corpo de texto afeta utilizadores com baixa visão e utilizadores em condições de luz difícil (que não são apenas pessoas com deficiência declarada).
• Hierarquia de headings quebrada: saltar de H1 para H4, usar headings apenas por estilo visual, ou não ter H1. Afeta leitores de ecrã e utilizadores cognitivos que navegam por estrutura. Critério 1.3.1.
• Foco visível ausente: se o outline do foco está eliminado globalmente com *:focus { outline: none; }, a navegação por teclado torna-se opaca. Critério 2.4.7 (AA) e 2.4.11 (AA no WCAG 2.2).
• Mensagens de erro sem ARIA live regions: quando um formulário valida e mostra erros, o leitor de ecrã anuncia-os automaticamente? Se não, o utilizador não sabe que algo correu mal. Critério 3.3.1.

Issues menores (melhorias)

Um issue é menor quando tem impacto limitado, afeta elementos secundários, ou requer julgamento de contexto para determinar se é realmente um problema.

• Alt descritivo mas impreciso em imagens decorativas ou de apoio.
• Contraste ligeiramente inferior ao mínimo em textos de rodapé ou avisos legais.
• Roles ARIA redundantes que não causam dano mas não acrescentam valor.
• Textos de link contextuais (que fazem sentido com o texto ao redor, embora não sozinhos).

Não ignores os menores indefinidamente — acabam por acumular-se. Mas não bloqueies a remediação dos críticos por resolver primeiro os menores.

O que as ferramentas NÃO detetam (e tens de fazer manualmente)

Aqui está o 60-70% que axe, Pa11y e Lighthouse não veem. Este bloco é o que diferencia uma auditoria real de um check automático e um clique em "partilhar". A documentação do W3C sobre avaliação de acessibilidade detalha-o com rigor; aqui vai a versão prática.

Texto alternativo "decorativo" mal usado: axe verifica que as imagens têm alt, mas não consegue saber se o texto alternativo descreve corretamente o conteúdo. "Imagem 1" ou o nome do ficheiro passam o check automático e são uma falha real.

Ordem de tabulação lógica: Tab percorre os elementos interativos na ordem do DOM. Se o teu CSS reordena visualmente os elementos, a ordem de tabulação pode ser caótica. Nenhuma ferramenta o deteta — só navegando com Tab.

Etiquetas de formulário corretamente associadas: axe deteta labels ausentes, mas não deteta labels que estão no HTML mas não estão associadas ao campo correto (seja por for/id incorretos ou por proximity association mal implementada).

Textos de link contextuais: WCAG permite links cujo texto ("ver mais") faz sentido em contexto graças ao texto ao redor (critério 2.4.4 — Em Contexto). Axe não consegue avaliar se esse contexto é suficiente. Apenas um humano o pode julgar.

Leitura do fluxo no leitor de ecrã: a ordem de leitura de um leitor de ecrã segue o DOM, não a apresentação visual. Layouts com CSS Grid ou Flexbox que reordenam elementos visualmente podem gerar um fluxo de leitura incompreensível que nenhuma ferramenta automática deteta.

Legendas e transcrições de vídeo: axe deteta se existe um elemento <track> num <video>, mas não consegue verificar se as legendas são precisas, completas ou estão bem sincronizadas. Isso requer revisão humana.

Gestos complexos sem alternativa: se a tua interface tem funções ativadas por gestos de múltiplos dedos (pinch, swipe) sem alternativa de teclado ou toque simples, é uma violação do critério 2.5.1. As ferramentas de desktop não o detetam.

ARIA mal usado: axe deteta ARIA inválido, mas não deteta ARIA tecnicamente válido que quebra a semântica. Um role="presentation" num elemento interativo, ou um aria-hidden="true" em conteúdo relevante, passam o check automático e são falhas graves.

Reportar em formato de cumprimento EAA

Uma auditoria que não gera documentação útil é uma auditoria a meias. O regulador não pede um teste de axe; pede evidência de diligência. A GOV.UK accessibility guidance — referência do setor embora seja de âmbito UK — documenta o padrão de facto para declarações de acessibilidade que vários reguladores europeus adotaram como referência.

Estrutura do relatório que a administração pede

Um relatório de auditoria de acessibilidade que possas apresentar ao regulador (ou que te sirva de base para a tua declaração) deve incluir:

1. Âmbito: que páginas foram auditadas, por que se escolheram essas, e que tecnologias de assistência se usaram para a revisão manual.
2. Metodologia: ferramentas automatizadas (versões exatas), processo de revisão manual (leitores de ecrã, versões de navegador).
3. Padrão avaliado: WCAG 2.2 nível AA / EN 301 549.
4. Descobertas: lista de critérios incumpridos, com evidência (capturas, fragmentos de HTML), classificados por severidade.
5. Estado de cumprimento: conformidade total, parcial ou não conforme — com justificação.
6. Exceções documentadas: se há conteúdo de terceiros incontrolável (widget externo, mapa incorporado), documentá-lo como exceção temporária com plano de resolução.
7. Data da auditoria e frequência de revisão.

Modelo de declaração de acessibilidade

A declaração de acessibilidade é o documento público que a EAA exige publicar no teu site (habitualmente numa URL como /acessibilidade ou no rodapé). Estrutura mínima:

Como documentar exceções temporárias

Se tens conteúdo que não cumpre mas não consegues remediar imediatamente (widget de chat de terceiro, mapa incorporado, PDF legado), a EAA permite documentá-lo como exceção temporária com condições:

• Descrever o conteúdo afetado e o critério WCAG incumprido.
• Justificar por que é um encargo desproporcionado resolvê-lo imediatamente.
• Indicar a data prevista de resolução ou a alternativa acessível disponível.
• Atualizar a declaração quando se resolver.

Uma exceção documentada é proteção legal. Uma exceção sem documentar, não.

Manter o cumprimento: integração em CI

A auditoria pontual diz-te onde estás hoje. A integração em CI diz-te se o que publicas amanhã quebra o que reparaste ontem. Sem CI de acessibilidade, a remediação é um balde com furos.

axe-core no GitHub Actions / GitLab CI

O bloco de CI mais básico com axe e Playwright:

E o teste correspondente:

Se o teu projeto usa React ou qualquer outro framework SPA, certifica-te de que o teste espera que o conteúdo dinâmico seja renderizado antes de executar axe — usa page.waitForSelector ou page.waitForLoadState('networkidle').

Pa11y dashboard

Pa11y tem um dashboard web open-source que permite monitorizar a acessibilidade de um site completo ao longo do tempo e ver a evolução dos issues por página. É especialmente útil para:

• Sites com muitas páginas geradas dinamicamente (blogs, e-commerce).
• Equipas onde os resultados são consultados por pessoas não técnicas.
• Auditorias programadas semanais ou mensais sem intervenção manual.

Para projetos mais pequenos, Pa11y CI com output JSON e um ficheiro de configuração versionado no repositório costuma ser suficiente:

O parâmetro threshold permite fixar um número máximo de violações aceitável antes de falhar o build — útil quando estás em processo de remediação e queres evitar regressões sem bloquear cada PR.

Pull request gating

A forma mais eficaz de manter o cumprimento é bloquear merges de PRs que introduzam novas violações. O fluxo recomendado:

1. O workflow de CI executa axe sobre as páginas afetadas pelo PR.
2. Se há novas violações (em comparação com a rama base), o check falha.
3. O PR não pode ser fundido até que as novas violações sejam resolvidas ou se documente a exceção.

A chave é auditar apenas páginas afetadas — auditar todo o site em cada PR é demasiado lento. Uma estratégia prática: mapear que componentes afeta cada PR e auditar as páginas que usam esses componentes.

Este modelo de QA automation integrado no ciclo de desenvolvimento é o mesmo que aplicamos a outros tipos de qualidade: desempenho, segurança, cobertura de testes.

Métricas a monitorizar

As métricas que realmente importam para o acompanhamento de acessibilidade ao longo do tempo:

Erros comuns na remediação

A auditoria é metade do trabalho. A remediação é onde mais equipas cometem erros que criam novos problemas ou dão falsa sensação de cumprimento.

Erro 1: corrigir apenas o que axe deteta

Se remedias apenas os issues automáticos, estás a cobrir 30-40% do problema e a deixar os 60-70% sem tocar. O regulador não aceita "passámos axe sem erros" como evidência de cumprimento WCAG. Passa o check automático E a revisão manual.

Erro 2: texto alternativo automático com IA sem revisão

Várias ferramentas de acessibilidade e CMS oferecem geração automática de alt text com IA. O resultado pode ser tecnicamente presente (o que satisfaz axe) mas semanticamente inútil ou incorreto. Um alt gerado por IA que descreve "uma pessoa a usar um computador portátil num escritório" quando a imagem mostra um diagrama de arquitetura técnica passa o check automático e falha o critério real. Revê sempre os alts gerados.

Erro 3: ARIA roles desnecessários que quebram a árvore

O antipadrão mais comum ao tentar "melhorar" a acessibilidade: acrescentar roles ARIA a elementos que já têm semântica nativa correta. <button role="button"> é redundante. <nav role="navigation"> é redundante. Mas <div role="button"> em vez de <button> quebra a árvore de acessibilidade porque o div não tem o comportamento de teclado do botão nativo. A regra geral: usa HTML semântico nativo antes de acrescentar ARIA. ARIA é para casos que o HTML não cobre, não para decorar HTML existente.

Erro 4: mudar markup sem re-testar com NVDA

Cada mudança de HTML que afete estrutura, roles, landmarks ou ordem de elementos pode mudar a experiência no leitor de ecrã de forma não óbvia. Uma mudança que melhora a pontuação de axe pode piorar a navegação real. Re-testa com NVDA ou VoiceOver sempre que modificas a estrutura semântica de uma página, não apenas quando fazes mudanças específicas de acessibilidade.

Erro 5: corrigir sem entender o critério

"Acrescenta aria-label aos botões" é uma instrução que pode interpretar-se literalmente e aplicar-se em excesso. Se um botão já tem texto visível descritivo, acrescentar aria-label pode contradizê-lo e confundir o leitor de ecrã (o critério 2.5.3 — Label in Name — exige que o aria-label contenha o texto visível). Antes de aplicar uma correção, lê o critério WCAG que justifica a mudança na spec oficial do W3C.

Perguntas frequentes

É suficiente com WCAG AA ou preciso de AAA?

A EAA exige WCAG 2.2 nível AA. O nível AAA não é obrigatório por lei. Dito isto, alguns critérios AAA são muito simples de implementar e oferecem melhorias significativas para certos grupos de utilizadores (como o critério 2.4.12 — Focus Appearance — que exige maior visibilidade do foco). Se chegas ao AA sem esforço extra, revê se algum critério AAA específico é relevante para a tua audiência. Mas não convertas AAA num objetivo de cumprimento normativo — não o é.

O que acontece se tenho um widget de terceiros que não cumpre?

É um dos cenários mais comuns e mais incómodos. Se o widget está num fluxo crítico (chat de suporte, gateway de pagamento, formulário de registo), tens três opções: substituí-lo por um acessível, fornecer uma alternativa acessível equivalente, ou documentá-lo como exceção temporária com data de resolução. O que não podes fazer é ignorá-lo — a lei faz-te responsável pela experiência completa que ofereces ao utilizador, incluindo os componentes que não controlas diretamente. Se o fornecedor do widget não tem roadmap de acessibilidade, esse é um critério de seleção de fornecedor.

Quanto custa uma auditoria profissional?

Uma auditoria profissional independente — a que gera um relatório formal com valor legal para apresentar ao regulador — oscila geralmente entre 3.000 e 15.000 euros para um site de tamanho médio, dependendo do número de páginas, da complexidade das interações e se inclui testing com utilizadores reais com deficiência.

A auditoria de 2 horas descrita neste post não é equivalente a uma auditoria profissional. É um diagnóstico de alto nível que te permite saber onde estás e priorizar. Serve como base para a remediação interna. Se precisas do relatório formal para apresentar ao regulador ou para um processo legal, precisas de uma auditoria profissional. Na Kiwop fazemos auditorias formais de acessibilidade — se estás nesse ponto, falamos.

A auditoria deve repetir-se?

Sim, e em dois níveis. O nível automático (axe em CI) deve executar-se com cada PR que modifique componentes de UI. O nível completo (automatização + revisão manual com leitores de ecrã + revisão de fluxos) deve repetir-se pelo menos uma vez por ano e sempre que haja mudanças significativas de design, novas funcionalidades principais, ou mudança de tecnologia de renderização.

A acessibilidade não é um estado que se alcança e se mantém sozinho. É um processo contínuo — exatamente como o desempenho ou a segurança.

Os meus documentos PDF também devem cumprir?

Sim. A EAA não aplica apenas ao HTML. Os documentos descarregáveis (PDF, Word, Excel) que fazem parte de um serviço digital também devem ser acessíveis se contêm informação relevante para o utilizador. Os PDFs acessíveis requerem estrutura de cabeçalhos, ordem de leitura correta, alt text em imagens, e texto real (não imagem digitalizada). Ferramentas: PAC 2024 (PDF Accessibility Checker, gratuito) e o verificador de acessibilidade integrado no Adobe Acrobat. Se o teu site oferece documentação, contratos, faturas ou formulários em PDF, inclui-os na auditoria.

Conclusão: o cumprimento é um processo, não um evento

Se há uma lição que resume tudo o que foi dito é esta: a acessibilidade mantém-se como o software — com testes automatizados que detetam regressões, revisões periódicas que validam o que a automatização não vê, e documentação que demonstra diligência.

O prazo da EAA passou. Não podes desfazer isso. O que podes fazer é começar hoje, com o stack que tens, em 2 horas, e construir a partir daí. Uma auditoria imperfeita feita hoje é infinitamente mais valiosa do que uma auditoria perfeita que nunca se executa.

O caminho é: diagnóstico (este post) → remediação priorizada → integração em CI → auditoria formal se a tua exposição legal o exigir.

Se em algum ponto do caminho precisares de apoio externo — uma auditoria formal, uma remediação complexa, ou integrar a acessibilidade no processo de Desenvolvimento de Software da tua equipa desde o início — na Kiwop fazemos exatamente isso. Conta-nos onde estás e dizemos-te por onde começar.