IRA e achados WCAG: como estruturar os resultados

O que é um achado de acessibilidade e por que é tão importante documentá-lo bem?

Imagine que você é médico e, depois de realizar uma série de exames num paciente, anota no prontuário «not feeling well». Sem mais detalhes. Sem exames, sem dados, sem localização do problema. Esse prontuário seria útil para outro profissional que precise tratar o paciente? Obviamente, não. Pois exatamente a mesma coisa acontece com os achados de acessibilidade num Relatório de Remediação de Acessibilidade (IRA).

Um achado de acessibilidade é cada não conformidade, erro ou área de melhoria detetada ao avaliar um site ou aplicação face às diretrizes WCAG 2.1 do W3C. Mas o achado em si não vale nada se não estiver bem documentado. Um IRA com achados mal estruturados é como um mapa sem legenda: tecnicamente existe, mas não o leva a lado nenhum.

Pessoalmente, acredito que a qualidade de um IRA se mede diretamente pela qualidade dos seus achados. Já vi relatórios de 200 páginas que não serviam para nada porque os achados eram vagos, e já vi relatórios de 30 páginas que transformaram a acessibilidade de uma organização inteira porque cada achado era claro, acionável e bem priorizado.

Anatomia de um achado IRA bem estruturado

Que elementos deve ter cada achado para que seja realmente útil? Depois de anos a redigir relatórios de remediação de acessibilidade, cheguei a uma estrutura que funciona de forma consistente:

Parece-lhe demasiado detalhe? Pense nisso como uma receita de cozinha: se apenas diz «ponha coisas no forno», o resultado é imprevisível. Se diz «pré-aqueça a 180°C, coloque o tabuleiro na grelha central durante 25 minutos», qualquer pessoa pode replicar o resultado com sucesso.

Classificação de achados segundo níveis WCAG

Nem todos os achados têm a mesma gravidade. As diretrizes WCAG 2.1 do W3C estabelecem três níveis de conformidade, e o seu IRA deve refletir esta hierarquia:

Nível A: o básico imprescindível

Os critérios de Nível A representam o mínimo absoluto. Se o seu site não cumpre estes critérios, está a excluir ativamente pessoas com deficiência. Segundo dados do WebAIM no seu relatório anual WebAIM Million de 2025, 95,9% das páginas iniciais analisadas tinham pelo menos um erro de Nível A detetável automaticamente. Ferramentas como o axe DevTools da Deque Systems podem identificar muitos destes problemas de forma instantânea.

Exemplos típicos: imagens sem texto alternativo (1.1.1), vídeos sem legendas (1.2.2), formulários sem rótulos (1.3.1), conteúdo não navegável por teclado (2.1.1).

Nível AA: o padrão de referência

O Nível AA é o que a maioria das legislações exige, incluindo a Diretiva Europeia de Acessibilidade e o European Accessibility Act. Quando falamos em «cumprir WCAG», quase sempre nos referimos ao Nível AA. O seu IRA deve prestar especial atenção a estes critérios porque são os que determinam o cumprimento legal.

Exemplos: contraste de cor insuficiente (1.4.3), texto não redimensionável (1.4.4), navegação inconsistente (3.2.3), mensagens de erro sem sugestões (3.3.3).

Nível AAA: a excelência

O Nível AAA raramente é exigido legalmente, mas incluí-lo no seu IRA demonstra um compromisso real com a acessibilidade. Pessoalmente, recomendo documentar oportunidades de melhoria AAA como «achados de melhoria», diferenciando-os das não conformidades obrigatórias.

Ferramentas para detetar e documentar achados

Com que ferramentas pode identificar achados para o seu IRA? A realidade é que precisa combinar avaliação automática e manual:

Segundo a Deque Systems, ferramentas automáticas como o axe DevTools podem detetar entre 30% e 57% dos problemas de acessibilidade. O restante requer avaliação manual especializada. O seu IRA deve indicar claramente que metodologia foi utilizada para cada achado.

Priorização de achados: a chave de um IRA acionável

De que serve ter 150 achados documentados se a equipa de desenvolvimento não sabe por onde começar? A priorização é o que transforma um IRA de um documento passivo num roteiro ativo.

A matriz que utilizo e recomendo cruza duas variáveis:

• Impacto no utilizador: quanto é que este problema afeta a experiência das pessoas com deficiência?
• Esforço de remediação: quanto tempo e recursos são necessários para corrigi-lo?

Com este cruzamento obtém quatro quadrantes claros:

Pessoalmente, aconselho sempre começar pelos quick wins. Nada motiva mais uma equipa do que ver resultados rápidos. Um achado como «botão sem rótulo acessível» pode ser corrigido em cinco minutos e melhorar a experiência de milhares de utilizadores.

Erros comuns ao documentar achados num IRA

Quer saber o que diferencia um IRA mediocre de um excelente? Estes são os erros que vejo com mais frequência:

• Achados genéricos: escrever «problemas de contraste» sem especificar onde, que elementos nem que rácio de contraste foi encontrado.
• Falta de evidências: não incluir capturas de ecrã, fragmentos de código nem resultados de ferramentas como axe DevTools ou WAVE.
• Ausência de impacto no utilizador: descrever o problema técnico sem explicar como afeta pessoas reais.
• Não indicar a remediação: apontar o erro sem propor uma solução concreta. Um bom IRA é também um guia de solução.
• Misturar severidades: tratar todos os achados com a mesma urgência, o que paralisa a equipa de desenvolvimento.
• Ignorar achados positivos: um IRA completo também documenta o que funciona bem, não apenas os erros.

Modelo IRA: estrutura recomendada para achados

Se está a criar o seu primeiro IRA ou quer melhorar o seu modelo atual, esta é a estrutura que recomendo baseada na metodologia WCAG-EM do W3C:

• 1. Resumo executivo: visão geral do estado de acessibilidade com métricas-chave.
• 2. Âmbito da avaliação: páginas avaliadas, tecnologias, ferramentas utilizadas.
• 3. Metodologia: combinação de testes automáticos (axe DevTools, WAVE) e manuais.
• 4. Resumo de achados: tabela resumo com contagem por severidade e critério WCAG.
• 5. Achados detalhados: cada achado com a estrutura de 9 elementos descrita acima.
• 6. Achados positivos: elementos que já cumprem as WCAG 2.1.
• 7. Roteiro de remediação: priorização e calendário de correções.
• 8. Anexos: capturas de ecrã, resultados de ferramentas, referências WCAG.