WCAG 3.3.5: Ajuda

O Que Esta Regra Significa

\n

O Critério de Sucesso 3.3.5 Ajuda (Nível AAA) das WCAG afirma: \"Ajuda sensível ao contexto está disponível.\" Isso significa que, sempre que uma página da web ou aplicação pedir que usuários insiram informações, deve ser fornecida ajuda apropriada para esclarecer o que é esperado. A ajuda deve ser contextual — isto é, deve se relacionar diretamente ao campo, tarefa ou processo em que o usuário está engajado no momento, em vez de ser uma página genérica de ajuda escondida em algum lugar da navegação.

\n

O critério se aplica a qualquer componente de interface de usuário que exija entrada: campos de texto, menus suspensos, seletores de data, controles de upload de arquivo, caixas de seleção, botões de opção e formulários em várias etapas. A ajuda sensível ao contexto pode assumir muitas formas, incluindo instruções em linha, rótulos descritivos, orientações em placeholders, tooltips, ícones de ajuda que expandem explicações, links para artigos de ajuda relevantes ou até suporte por chat ao vivo — desde que a ajuda esteja disponível em proximidade ao campo que a exige.

\n

Um aprovado é alcançado quando pelo menos um dos seguintes está presente para cada entrada que possa causar confusão ao usuário: um rótulo claramente escrito que explique totalmente a entrada esperada; texto descritivo suplementar adjacente ao campo (não apenas um placeholder, que desaparece ao digitar); um link de ajuda visível ou tooltip expansível que forneça explicação adicional; ou um mecanismo de ajuda facilmente acessível (como um ícone de ponto de interrogação) que revele orientações específicas para o contexto atual. A ajuda não precisa ser idêntica em todos os campos — o requisito principal é que, sempre que um usuário possa ficar incerto sobre o que inserir, a ajuda esteja genuinamente disponível e acessível.

\n

Uma falha ocorre quando os campos não fornecem nenhuma explicação do que é esperado, quando a ajuda só está disponível após o envio e a ocorrência de um erro, quando tooltips ou textos de ajuda são inacessíveis a usuários de teclado ou leitores de tela, ou quando links de ajuda levam a uma página geral de FAQ em vez de conteúdo relevante para a entrada específica. De forma crítica, depender apenas de mensagens de erro depois do fato não satisfaz este critério — a ajuda deve estar disponível antes ou durante a entrada, não apenas depois que um erro foi cometido.

\n

As WCAG 3.3.5 não definem um único método de implementação rígido. Elas reconhecem que a ajuda sensível ao contexto pode ser implementada de muitas maneiras válidas, dando flexibilidade aos desenvolvedores, mas a intenção é inequívoca: usuários nunca devem ficar adivinhando o que um campo de formulário espera. Não há exceções oficiais para este critério — ele se aplica universalmente sempre que uma entrada de usuário é solicitada.

\n\n

Por Que Isso Importa

\n

Formulários estão entre as partes mais desafiadoras de qualquer interface digital. Para usuários com deficiências cognitivas — incluindo pessoas com dislexia, transtornos de déficit de atenção, deficiências intelectuais ou comprometimentos de memória — campos de formulário ambíguos podem ser uma barreira intransponível. Sem ajuda clara e contextual, esses usuários podem falhar repetidamente em concluir tarefas, experimentar frustração significativa ou abandonar o processo por completo. De acordo com a Organização Mundial da Saúde, aproximadamente 1 em cada 6 pessoas no mundo vive com algum tipo de deficiência significativa, e comprometimentos cognitivos representam uma parcela substancial dessa população.

\n

Usuários com baixa literacia digital ou experiência limitada com interfaces web também se beneficiam enormemente da ajuda sensível ao contexto. Um usuário de primeira viagem de um portal de serviços eletrônicos do governo, uma pessoa idosa solicitando um benefício de saúde online ou uma pessoa dona de pequena empresa preenchendo um formulário de imposto podem não saber qual formato é esperado para um número de identificação fiscal, quais tipos de arquivo são aceitos para upload de documentos ou qual é a diferença entre dois campos com nomes semelhantes. Sem orientação no contexto, esses usuários ficam vulneráveis a erros e à ansiedade de não saber o que fizeram de errado.

\n

Considere um cenário concreto: uma pessoa com deficiência cognitiva está solicitando um passe de transporte subsidiado por meio do portal web de uma autoridade municipal de transporte. O formulário pede um \"Número de Referência\" sem qualquer explicação. A pessoa tem vários documentos — seu documento de identidade nacional, seu cartão de transporte e uma confirmação de solicitação anterior — cada um com identificadores numéricos diferentes. Sem ajuda sensível ao contexto indicando qual documento específico ou formato é esperado, é provável que a pessoa insira o número errado, acione um erro de validação e possivelmente desista. Se um simples ícone de ajuda ou descrição em linha estivesse presente — \"Digite o número de 10 dígitos no canto superior direito do seu cartão de transporte\" — toda a interação teria sido bem-sucedida na primeira tentativa.

\n

Para usuários que são cegos ou têm baixa visão, a ajuda sensível ao contexto também é importante. Leitores de tela podem anunciar texto de ajuda associado, descrições via aria-describedby ou conteúdo de ajuda vinculado, mas apenas se estes forem implementados corretamente. Quando a ajuda é transmitida puramente de forma visual (como um indicador de cor ou um ícone sem texto acessível), usuários de leitores de tela são excluídos. Garantir que a ajuda esteja presente e seja acessível reforça a inclusão em todos os grupos de deficiência.

\n

Além da acessibilidade, a ajuda sensível ao contexto melhora a usabilidade geral e as taxas de conversão. Sites com orientação clara em formulários apresentam menores taxas de abandono, menos solicitações de suporte e maiores taxas de conclusão de formulários. Para sites de comércio eletrônico em particular, cada ponto percentual de melhoria na conclusão do checkout tem impacto direto na receita. Mecanismos de busca também recompensam páginas com conteúdo claro e estruturado, e formulários bem rotulados e bem descritos contribuem positivamente para sinais de qualidade da página.

\n\n

Regras Relacionadas do Axe-core

\n

As WCAG 3.3.5 exigem testes manuais porque sua conformidade depende da qualidade, relevância e adequação contextual do conteúdo de ajuda — fatores que ferramentas automatizadas não conseguem avaliar. Um scanner automatizado pode confirmar que um rótulo existe ou que um atributo aria-describedby aponta para um elemento real, mas não pode determinar se o conteúdo desse rótulo ou descrição é realmente útil, preciso ou suficiente para uma determinada entrada.

\n

\n
• Revisão Manual — Presença de Ajuda Sensível ao Contexto: Ferramentas automatizadas não conseguem avaliar se o texto de ajuda realmente responde às prováveis dúvidas do usuário sobre um campo específico. Uma ferramenta pode detectar que existe um elemento <label>, mas não pode julgar se \"Digite seu número\" é suficientemente descritivo para um campo que espera um número de registro de IVA formatado. Testadores manuais devem avaliar se cada entrada que possa causar confusão é acompanhada por orientações que reduzam de forma significativa essa confusão.
\n
• Revisão Manual — Acessibilidade da Ajuda: Mesmo que a ajuda esteja presente visualmente, ferramentas automatizadas podem não sinalizar casos em que essa ajuda é inacessível a tecnologias assistivas. Por exemplo, um tooltip acionado apenas ao passar o mouse, sem equivalente acessível por teclado, passa em muitos testes automatizados, mas falha para usuários reais. Testadores devem verificar se todos os mecanismos de ajuda — tooltips, seções expansíveis, links de ajuda — são alcançáveis e operáveis via teclado e são anunciados corretamente por leitores de tela.
\n
• Revisão Manual — Posicionamento e Proximidade da Ajuda: Varreduras automatizadas não conseguem avaliar se o texto de ajuda está colocado suficientemente perto do campo relevante para ser associado de forma significativa a ele. Um parágrafo de ajuda no final da página, ou em um modal que exige múltiplas interações para ser acessado, pode existir tecnicamente, mas falha no espírito da ajuda sensível ao contexto. A revisão manual deve confirmar que a ajuda está disponível no ponto de necessidade.
\n
• Revisão Manual — Integralidade em Formulários Complexos: Formulários complexos em várias etapas introduzem desafios adicionais. Ferramentas automatizadas verificam campos individuais isoladamente, mas não conseguem avaliar se a ajuda cumulativa fornecida ao longo de um assistente de várias etapas é suficiente para guiar um usuário por um processo complexo. Percursos manuais são necessários para identificar lacunas na orientação que só se tornam aparentes ao experimentar o formulário como um todo.
\n

\n\n

Como Testar

\n

\n
1. Execute uma varredura automatizada de acessibilidade como linha de base. Use axe DevTools (extensão de navegador ou CLI), Lighthouse no Chrome DevTools ou IBM Equal Access Checker na página que contém o formulário. Embora essas ferramentas não sinalizem diretamente violações de 3.3.5, elas destacarão problemas relacionados, como rótulos ausentes (elemento label não associado a uma entrada), destinos aria-describedby ausentes ou implementações de tooltip inacessíveis. Resolver primeiro esses problemas fundamentais garante que, quando a ajuda sensível ao contexto for adicionada, ela também seja tecnicamente acessível.
\n
2. Audite manualmente cada campo do formulário quanto à disponibilidade de ajuda. Para cada campo de entrada, pergunte: (a) O rótulo por si só explica completamente qual entrada é necessária, incluindo quaisquer requisitos de formato? (b) Há texto de ajuda suplementar visível adjacente ao campo? (c) Há um ícone de ajuda, tooltip ou seção expansível que forneça orientação adicional? (d) Há um link para conteúdo de ajuda relevante? Se a resposta a todas essas perguntas for não, e o campo tiver qualquer ambiguidade, isso é uma falha de 3.3.5.
\n
3. Teste a acessibilidade por teclado de todos os mecanismos de ajuda. Percorra o formulário usando apenas o teclado (sem mouse). Verifique se todos os tooltips, ícones de ajuda, descrições expansíveis ou links de ajuda são alcançáveis e ativáveis via teclado. Tooltips devem aparecer ao foco, bem como ao passar o mouse. Botões de ajuda devem ser acionados com Enter ou Espaço. Qualquer mecanismo de ajuda que só seja alcançável com mouse falha neste teste.
\n
4. Teste com NVDA + Firefox. Navegue até cada campo do formulário usando Tab. Ouça o que o NVDA anuncia para cada campo — ele anuncia o rótulo? Ele anuncia alguma descrição associada (via aria-describedby)? Ative quaisquer ícones de ajuda ou tooltips e confirme se seu conteúdo é anunciado. Tente acessar o conteúdo de ajuda vinculado e verifique se ele se relaciona ao campo atual.
\n
5. Teste com VoiceOver + Safari (macOS ou iOS). Use o VoiceOver para navegar pelo formulário. No macOS, use Tab para se mover entre os campos e ouça o anúncio completo de cada um. No iOS, use navegação por gestos de deslizar. Verifique se todo o conteúdo de ajuda associado às entradas é lido em voz alta e se os gatilhos de ajuda (botões, links) são acessíveis e corretamente rotulados pelo VoiceOver.
\n
6. Teste com JAWS + Chrome. Use o modo de formulários do JAWS (ative com Enter quando estiver em um elemento de formulário). Navegue entre os campos com Tab e verifique se o JAWS lê as instruções e descrições associadas. Use o cursor virtual do JAWS para verificar se o conteúdo de ajuda colocado fora das associações padrão de rótulo também é alcançável.
\n
7. Conduza um walkthrough cognitivo. Peça a uma pessoa não familiarizada com o formulário (ou simule isso revisando o formulário após uma pausa) que tente preenchê-lo sem qualquer orientação externa. Anote cada ponto em que ela hesita, faz uma pergunta ou comete um erro devido a expectativas pouco claras. Cada um desses pontos é um candidato a ajuda sensível ao contexto aprimorada sob 3.3.5.
\n

\n\n

Como Corrigir

\n

Campo de Texto Ambíguo Sem Explicação — Incorreto

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Campo de Texto Ambíguo com Ajuda em Linha — Correto

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Ícone de Ajuda com Tooltip Inacessível a Usuários de Teclado — Incorreto

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Ícone de Ajuda com Tooltip Acessível a Todos os Usuários — Correto

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

Formulário Complexo em Várias Etapas Sem Orientação em Nível de Etapa — Incorreto

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Formulário Complexo em Várias Etapas com Ajuda Contextual por Etapa — Correto

\n\n

(Content truncated due to token limit — please retry this article.)