Quando as Suas Mensagens de Erro Excluem Utilizadores

O momento em que o formulário falha

Imagine a cena: um utilizador cego preenche um formulário de compra, submete-o e não ouve nada de útil do seu leitor de ecrã. Nenhum anúncio. Nenhuma explicação. A página assinalou visualmente cinco erros de validação a vermelho, mas o utilizador não faz a menor ideia. Volta a submeter. E outra vez. Acaba por desistir.

Este não é um cenário marginal. O tratamento inacessível de erros é uma das barreiras mais comuns que encontramos em auditorias reais, e é uma daquelas que tende a frustrar os utilizadores no pior momento possível — quando estão a tentar concluir uma transação ou submeter algo importante.

A boa notícia é que corrigi-lo é, em grande parte, uma questão de saber o que significa “bem feito”. As falhas são quase sempre os mesmos poucos padrões.

Por que as mensagens de erro são difíceis para utilizadores de tecnologia de apoio

Os utilizadores de rato com visão tendem a notar os erros de validação imediatamente — a borda vermelha, o ícone de aviso, o texto que aparece por baixo do campo. Mas os utilizadores que dependem de leitores de ecrã, de navegação por teclado ou de controlo por voz enfrentam uma experiência fundamentalmente diferente.

Quando um formulário é submetido e aparecem erros:

• Os utilizadores de leitores de ecrã podem não ouvir nada, a menos que o foco se mova para o erro ou que uma região dinâmica o anuncie
• Os utilizadores de teclado precisam de conseguir alcançar cada mensagem de erro a partir do teclado e de perceber a que campo pertence
• Os utilizadores de controlo por voz precisam de se referir aos campos por uma etiqueta visível e exata — se a etiqueta está errada ou em falta, ficam bloqueados

Nada disto acontece automaticamente. Tem de ser construído.

Os critérios WCAG aplicáveis

Quatro critérios de sucesso das WCAG 2.2 abrangem diretamente o tratamento de erros:

3.3.1 Identificação de Erros (Nível A) — Se um erro for detetado automaticamente, o item com erro é identificado e descrito ao utilizador em texto. Não pode transmitir erros apenas através da cor.

3.3.2 Etiquetas ou Instruções (Nível A) — Os campos que exigem um formato específico devem tornar esse requisito claro antes ou durante o preenchimento, não apenas depois de a submissão falhar.

3.3.3 Sugestão de Erro (Nível AA) — Se um erro for detetado e forem conhecidas sugestões de correção, forneça-as. “Data inválida” não é suficiente. “Introduza a data no formato DD/MM/AAAA” é.

3.3.4 Prevenção de Erros (Nível AA) — Para submissões com consequências (transações financeiras, acordos legais), dê aos utilizadores a possibilidade de rever, corrigir e confirmar antes de a ação se tornar permanente.

Existe também o critério 4.1.3 Mensagens de Estado (Nível AA), que abrange mensagens injetadas dinamicamente que não recebem foco — estas devem ser anunciadas pela tecnologia de apoio através de role="status" ou role="alert".

O que uma mensagem de erro acessível realmente exige

Acertar nas mensagens de erro exige atenção a quatro camadas distintas:

1. A ligação programática

Cada mensagem de erro deve estar ligada ao respetivo campo através de aria-describedby. Isto indica aos leitores de ecrã que devem anunciar o texto do erro quando o campo recebe o foco.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

O atributo aria-invalid="true" sinaliza que o campo está atualmente inválido, algo que a maioria dos leitores de ecrã anuncia quando o foco chega ao campo.

2. Gestão do foco após a submissão

Quando um formulário é submetido e existem erros, o foco deve mover-se para um local útil. Os dois padrões mais comuns:

• Mover o foco para um resumo de erros no topo do formulário que lista todos os erros com ligações para os campos relevantes
• Mover o foco para o primeiro campo com erro

Se o foco permanecer no botão de submissão ou em lado nenhum, os utilizadores de leitores de ecrã têm de descobrir os erros sozinhos, navegando pelo formulário — se é que sequer sabem que existem erros.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Anúncios em regiões dinâmicas para erros dinâmicos

Para erros que aparecem à medida que o utilizador escreve (validação inline em tempo real), use regiões dinâmicas ARIA para que a mensagem seja anunciada sem exigir que o foco se mova.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Use role="alert" / aria-live="assertive" para erros que exigem atenção imediata. Use role="status" / aria-live="polite" para feedback menos urgente que pode esperar até o utilizador fazer uma pausa.

4. A própria mensagem de erro

A linguagem importa. As mensagens de erro acessíveis são:

• Específicas: dizem o que está errado, não apenas que algo está errado
• Acionáveis: dizem ao utilizador exatamente o que fazer para corrigir
• Corteses: evitam linguagem acusatória como “introduziu um valor inválido”

Inacessível	Acessível
”Entrada inválida"	"O endereço de email deve incluir um símbolo @, por exemplo nome@exemplo.com"
"Erro"	"A data deve estar no formato DD/MM/AAAA"
"Campo obrigatório"	"O nome completo é obrigatório"
"Palavra-passe inválida"	"A palavra-passe deve ter pelo menos 8 caracteres e incluir um número”

Padrões para diferentes cenários de erro

Erros inline junto ao campo

O padrão mais comum. Uma mensagem de erro aparece diretamente por baixo do campo associado. Funciona bem em formulários simples. Requer aria-describedby e aria-invalid para ser anunciada corretamente.

Faixas de resumo de erros

Em formulários longos com múltiplos erros, coloque um resumo no topo que lista todos os problemas como ligações que saltam para o campo relevante. Mova o foco para aqui após uma submissão falhada. Este é o padrão utilizado pelo GOV.UK e amplamente recomendado para formulários complexos.

Notificações toast

As mensagens de curta duração que aparecem na margem do ecrã estão entre os padrões mais inacessíveis em uso corrente. Desaparecem antes de os utilizadores de leitores de ecrã as conseguirem alcançar, muitas vezes não são sequer anunciadas e não oferecem qualquer caminho de recuperação. Evite usar toasts para erros. Se os usar, combine-os com um estado de erro persistente no próprio formulário.

Erros de sistema

Quando algo corre mal do lado do servidor, diga ao utilizador em linguagem simples o que aconteceu e o que pode fazer a seguir. “Algo correu mal” sem mais orientação deixa os utilizadores sem saída.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

A lista de verificação de testes

Depois de implementar o tratamento de erros, verifique manualmente estes pontos — as ferramentas automáticas não detetam a maioria deles:

• Submeter um formulário obrigatório vazio move o foco para um resumo de erros ou para o primeiro campo com erro
• Cada mensagem de erro está ligada ao respetivo campo através de aria-describedby
• Os campos com erro têm aria-invalid="true"
• As mensagens de erro são anunciadas quando o foco chega ao campo afetado
• A validação em tempo real usa regiões dinâmicas
• As mensagens de erro usam linguagem específica e acionável — não apenas “inválido”
• A cor não é a única forma de indicar os erros (ícone ou etiqueta de texto além do vermelho)
• O erro pode ser alcançado por navegação com Tab a partir do teclado
• A ordem do foco após a submissão é lógica e não salta de forma imprevisível
• As mensagens toast estão combinadas com um estado de erro persistente

Por que as ferramentas automáticas falham a maior parte disto

Um verificador automático consegue confirmar se aria-describedby aponta para um elemento existente e se aria-invalid está presente. Não consegue verificar se o foco se move corretamente após a submissão, se o texto do erro é exato ou se uma notificação toast desaparece antes de poder ser lida. As nossas auditorias manuais de acessibilidade incluem testes específicos de formulários com tecnologia de apoio real — a única forma fiável de verificar que o tratamento de erros realmente funciona de ponta a ponta.

Se não tem a certeza de como estão os seus formulários, execute uma análise gratuita para identificar primeiro os problemas automatizáveis e avance a partir daí.