ACESSIBILIDADE ≠ OVERLAY · 35

A acessibilidade não se prova com uma pontuação: prova-se quando as pessoas conseguem utilizar o seu site

📅 6 de novembro de 2026   ·   ⏱ 6 min de leitura

Uma pontuação perfeita não garante uma experiência acessível.

01. O significado real de uma pontuação

Uma pontuação representa o resultado de verificações específicas, realizadas num momento e num contexto determinados. Não descreve todas as pessoas nem todos os percursos de um site. Uma página inicial pode obter cem por cento e o processo de compra continuar inacessível. A pergunta importante é se o visitante consegue atingir o objetivo com autonomia.

As pontuações são úteis para acompanhar alterações técnicas, mas não devem ser apresentadas como garantias absolutas. Um bom resultado não substitui uma avaliação dos conteúdos, dos formulários, dos componentes dinâmicos e das tarefas que as pessoas realmente procuram realizar.

02. O valor das verificações automáticas

As ferramentas automáticas encontram problemas objetivos, como imagens sem alternativa, determinados contrastes insuficientes, campos sem etiquetas e erros de semântica HTML. Permitem analisar várias páginas com rapidez e detetar regressões depois de atualizar um tema ou componente.

O seu contributo é importante numa estratégia de qualidade, sobretudo quando se repetem verificações regularmente. Contudo, é necessário analisar diferentes modelos de página e estados da interface. Um relatório da página inicial não representa necessariamente um formulário de inscrição ou uma janela de diálogo.

03. Os limites da automatização

Uma ferramenta não consegue avaliar com fiabilidade se uma alternativa textual transmite o propósito da imagem ou se as instruções são compreensíveis para quem não vê a disposição visual. Também não reproduz todas as combinações de tecnologias de apoio e dispositivos.

Uma ligação com o texto «clique aqui» pode funcionar tecnicamente e continuar a ser ambígua quando alguém consulta apenas a lista de ligações. A correção exige compreender o contexto e indicar claramente o destino, não apenas satisfazer uma regra de validação.

04. Um exemplo de falsa segurança

Imagine uma loja virtual que apresenta uma pontuação perfeita. Os botões têm nomes e as imagens têm descrições, mas o carrinho abre numa janela que não recebe o foco. Quem utiliza teclado não consegue fechar a janela nem concluir a compra.

Noutro caso, um erro pode ser indicado apenas a vermelho, ou uma confirmação desaparecer antes de ser lida. A página parece correta numa captura, mas a tarefa falha. Por isso é fundamental testar o processo completo, incluindo os estados que surgem após cada interação.

05. Testar a navegação por teclado

Afaste o rato e percorra a página com Tab e Shift+Tab. Verifique se consegue alcançar todas as ligações, botões e campos, se o foco é visível e se a ordem faz sentido. Experimente menus, calendários, janelas de diálogo e outros componentes interativos.

Não basta alcançar um elemento: é preciso ativá-lo, utilizá-lo e sair dele. Se o foco desaparece, fica preso ou salta inesperadamente, existe uma barreira. Documente os passos exatos para que a equipa consiga reproduzir e corrigir o problema.

06. Ouvir a página com leitor de ecrã

Um leitor de ecrã permite perceber como são anunciados títulos, regiões, ligações e mensagens. Um texto visualmente grande não substitui um título semântico. Um botão representado apenas por um ícone precisa de um nome que explique a sua função.

Ouça também as mudanças de estado. O erro do formulário é anunciado? O campo afetado é identificado? A confirmação da ação é comunicada? Estas verificações mostram problemas que um resultado numérico não consegue representar adequadamente.

07. Formulários e percursos completos

Os formulários devem explicar antecipadamente os dados necessários, identificar campos obrigatórios e oferecer mensagens de erro claras. As pessoas precisam de compreender o que aconteceu e como corrigir a situação sem perder informação já introduzida.

Avalie o percurso desde a primeira página até à confirmação final. Uma descrição acessível de um serviço não chega se o calendário de marcações exigir rato. O objetivo é concluir a tarefa, não apenas navegar até ao formulário.

08. Contraste, ampliação e compreensão

Verifique o contraste real entre texto e fundo, a visibilidade do foco e o tamanho dos elementos interativos. Amplie a página e confirme que a informação essencial continua disponível, sem cortes ou deslocações desnecessárias em duas direções.

A linguagem clara também importa. Títulos descritivos, instruções diretas e uma navegação consistente ajudam a antecipar resultados. Não dependa exclusivamente da cor para indicar erros ou estados, pois nem todas as pessoas percebem essas diferenças da mesma forma.

09. WCAG 2.2 e conformidade

As WCAG 2.2 oferecem critérios verificáveis para orientar desenvolvimento, auditoria e correção. Contudo, uma pontuação automática não é uma declaração de conformidade. Nenhum analisador isolado comprova todos os critérios aplicáveis.

Utilize as recomendações juntamente com revisão manual, testes funcionais e participação de utilizadores. Uma declaração de acessibilidade responsável deve refletir as condições reais do serviço e as limitações conhecidas, em vez de prometer perfeição sem provas.

10. Testes com pessoas reais

As pessoas com deficiência identificam dificuldades que podem passar despercebidas à equipa. Observe tarefas reais, escute os comentários e evite assumir que uma pessoa representa todas as necessidades. Diferentes perfis e tecnologias revelam problemas diferentes.

Prepare cenários como encontrar uma informação, fazer uma reserva ou descarregar um documento. Registe o ponto de bloqueio e o impacto na tarefa. Dê prioridade aos obstáculos que impedem a conclusão e confirme posteriormente se a correção funciona.

11. Porque um overlay não resolve

Um overlay pode disponibilizar controlos de apresentação, mas não substitui HTML semântico, formulários corretos ou navegação funcional por teclado. Também não consegue determinar se as instruções são claras ou se um processo complexo pode ser concluído.

A instalação de um widget não torna automaticamente o site conforme às WCAG 2.2. A própria camada adicionada pode introduzir novas dificuldades. A solução sustentável consiste em corrigir o produto original e manter as melhorias ao longo do tempo.

12. Um plano de melhoria contínua

Identifique os percursos mais importantes e as páginas que os suportam. Combine verificações automáticas com testes de teclado, leitor de ecrã, ampliação, estrutura e formulários. Registe cada problema com passos reproduzíveis e responsável pela correção.

Inclua estas verificações nas publicações e atualizações futuras. Reveja componentes partilhados e volte a testar as tarefas essenciais. O objetivo não é exibir um número num relatório: é permitir que mais pessoas utilizem o serviço com independência.