WCAG 3.3.5 : Aide

Ce que signifie cette règle

\n

Le critère de succès 3.3.5 Aide (niveau AAA) des WCAG stipule : « Une aide contextuelle est disponible. » Cela signifie que partout où une page web ou une application demande aux utilisateurs de saisir des informations, une aide appropriée doit être fournie pour clarifier ce qui est attendu. L’aide doit être contextuelle — c’est-à-dire qu’elle doit se rapporter directement au champ, à la tâche ou au processus dans lequel l’utilisateur est actuellement engagé, plutôt que d’être une page d’aide générique enfouie quelque part dans la navigation.

\n

Ce critère s’applique à tout composant d’interface utilisateur qui nécessite une saisie : champs de texte, menus déroulants, sélecteurs de date, contrôles de téléversement de fichiers, cases à cocher, boutons radio et formulaires en plusieurs étapes. L’aide contextuelle peut prendre de nombreuses formes, notamment des instructions en ligne, des libellés descriptifs, des indications dans les espaces réservés, des info-bulles, des icônes d’aide qui développent des explications, des liens vers des articles d’aide pertinents, ou même une assistance par chat en direct — tant que l’aide est disponible à proximité de la saisie qui en a besoin.

\n

Un succès est obtenu lorsqu’au moins l’un des éléments suivants est présent pour chaque saisie susceptible de provoquer une confusion chez l’utilisateur : un libellé clairement rédigé qui explique entièrement la saisie attendue ; un texte descriptif supplémentaire adjacent au champ (et pas seulement un espace réservé, qui disparaît lors de la saisie) ; un lien d’aide visible ou une info-bulle extensible qui fournit des explications supplémentaires ; ou un mécanisme d’aide facilement accessible (comme une icône en forme de point d’interrogation) qui révèle des indications spécifiques au contexte actuel. L’aide n’a pas besoin d’être identique pour tous les champs — l’exigence clé est que partout où un utilisateur pourrait être incertain de ce qu’il doit saisir, une aide soit réellement disponible et accessible.

\n

Un échec se produit lorsque les champs ne fournissent aucune explication sur ce qui est attendu, lorsque l’aide n’est disponible qu’après l’envoi et la survenue d’une erreur, lorsque les info-bulles ou les textes d’aide sont inaccessibles aux utilisateurs de clavier ou de lecteurs d’écran, ou lorsque les liens d’aide mènent à une FAQ générale plutôt qu’à un contenu pertinent pour la saisie spécifique. De manière critique, se reposer uniquement sur des messages d’erreur a posteriori ne satisfait pas ce critère — l’aide doit être disponible avant ou pendant la saisie, et pas seulement après qu’une erreur a été commise.

\n

WCAG 3.3.5 ne définit pas une méthode de mise en œuvre unique et stricte. Il reconnaît que l’aide contextuelle peut être mise en œuvre de nombreuses façons valides, offrant une flexibilité aux développeurs, mais l’intention est sans ambiguïté : les utilisateurs ne devraient jamais être laissés à deviner ce qu’un champ de formulaire attend. Il n’existe aucune exception officielle à ce critère — il s’applique universellement partout où une saisie utilisateur est demandée.

\n\n

Pourquoi c’est important

\n

Les formulaires comptent parmi les parties les plus difficiles de toute interface numérique. Pour les utilisateurs ayant des déficiences cognitives — y compris les personnes dyslexiques, ayant des troubles de l’attention, des déficiences intellectuelles ou des troubles de la mémoire — des champs de formulaire ambigus peuvent constituer un obstacle insurmontable. Sans aide claire et contextuelle, ces utilisateurs peuvent échouer à plusieurs reprises à accomplir des tâches, éprouver une frustration importante ou abandonner complètement le processus. Selon l’Organisation mondiale de la Santé, environ 1 personne sur 6 dans le monde vit avec une forme de handicap significatif, et les déficiences cognitives représentent une part substantielle de cette population.

\n

Les utilisateurs ayant une faible littératie numérique ou une expérience limitée des interfaces web bénéficient également énormément de l’aide contextuelle. Un utilisateur débutant sur un portail de e-services gouvernementaux, une personne âgée demandant une prestation de santé en ligne, ou un propriétaire de petite entreprise remplissant un formulaire fiscal peuvent ne pas savoir quel format est attendu pour un numéro d’identification fiscale, quels types de fichiers sont acceptés pour le téléversement de documents, ou ce que représente la différence entre deux champs aux noms similaires. Sans indications dans le contexte, ces utilisateurs sont exposés aux erreurs et à l’anxiété de ne pas savoir ce qu’ils ont mal fait.

\n

Considérons un scénario concret : une personne ayant une déficience cognitive demande un titre de transport subventionné via le portail web d’une autorité de transport municipale. Le formulaire demande un « Numéro de référence » sans explication. L’utilisateur dispose de plusieurs documents — sa carte d’identité nationale, sa carte de transport et une confirmation de demande précédente — chacun comportant des identifiants numériques différents. Sans aide contextuelle indiquant quel document spécifique ou quel format est attendu, l’utilisateur est susceptible de saisir le mauvais numéro, de déclencher une erreur de validation et potentiellement d’abandonner. Si une simple icône d’aide ou une description en ligne avait été présente — « Saisissez le numéro à 10 chiffres situé dans le coin supérieur droit de votre carte de transport » — l’interaction entière aurait réussi dès la première tentative.

\n

Pour les utilisateurs qui sont aveugles ou malvoyants, l’aide contextuelle est également importante. Les lecteurs d’écran peuvent annoncer le texte d’aide associé, les descriptions aria-describedby ou le contenu d’aide lié, mais seulement si ceux-ci sont correctement implémentés. Lorsque l’aide est transmise uniquement visuellement (comme un indicateur de couleur ou une icône sans texte accessible), les utilisateurs de lecteurs d’écran sont exclus. Veiller à ce que l’aide soit à la fois présente et accessible renforce l’inclusivité pour tous les groupes de personnes handicapées.

\n

Au-delà de l’accessibilité, l’aide contextuelle améliore l’ergonomie globale et les taux de conversion. Les sites web avec des indications claires dans les formulaires connaissent des taux d’abandon plus faibles, moins de demandes d’assistance et des taux de complétion de formulaires plus élevés. Pour les sites de commerce en ligne en particulier, chaque point de pourcentage d’amélioration de la complétion du paiement a un impact direct sur le chiffre d’affaires. Les moteurs de recherche récompensent également les pages au contenu clair et structuré, et des formulaires bien étiquetés et bien décrits contribuent positivement aux signaux de qualité de page.

\n\n

Règles Axe-core associées

\n

WCAG 3.3.5 nécessite des tests manuels car sa conformité dépend de la qualité, de la pertinence et de l’adéquation contextuelle du contenu d’aide — des facteurs que les outils automatisés ne peuvent pas évaluer. Un analyseur automatisé peut confirmer qu’un libellé existe ou qu’un attribut aria-describedby pointe vers un élément réel, mais il ne peut pas déterminer si le contenu de ce libellé ou de cette description est réellement utile, exact ou suffisant pour une saisie donnée.

\n

\n
• Revue manuelle — Présence d’une aide contextuelle : Les outils automatisés ne peuvent pas évaluer si le texte d’aide répond réellement aux questions probables de l’utilisateur concernant un champ spécifique. Un outil peut détecter qu’un élément <label> existe, mais ne peut pas juger si « Saisissez votre numéro » est suffisamment descriptif pour un champ qui attend un numéro de TVA dans un format particulier. Les testeurs manuels doivent évaluer si chaque saisie susceptible de provoquer une confusion est accompagnée d’indications qui réduisent réellement cette confusion.
\n
• Revue manuelle — Accessibilité de l’aide : Même si l’aide est visuellement présente, les outils automatisés peuvent ne pas signaler les cas où cette aide est inaccessible aux technologies d’assistance. Par exemple, une info-bulle déclenchée uniquement au survol de la souris, sans équivalent accessible au clavier, passe de nombreux contrôles automatisés mais échoue pour les utilisateurs réels. Les testeurs doivent vérifier que tous les mécanismes d’aide — info-bulles, sections extensibles, liens d’aide — sont atteignables et utilisables au clavier et sont correctement annoncés par les lecteurs d’écran.
\n
• Revue manuelle — Emplacement et proximité de l’aide : Les analyses automatisées ne peuvent pas évaluer si le texte d’aide est placé suffisamment près du champ concerné pour être significativement associé à celui-ci. Un paragraphe d’aide en bas de page, ou dans une fenêtre modale nécessitant plusieurs interactions pour y accéder, peut techniquement exister mais ne respecte pas l’esprit de l’aide contextuelle. La revue manuelle doit confirmer que l’aide est disponible au moment où l’utilisateur en a besoin.
\n
• Revue manuelle — Exhaustivité pour les formulaires complexes : Les formulaires complexes en plusieurs étapes introduisent des défis supplémentaires. Les outils automatisés vérifient les champs individuellement mais ne peuvent pas évaluer si l’aide cumulée fournie dans un assistant en plusieurs étapes est suffisante pour guider un utilisateur à travers un processus complexe. Des parcours manuels sont nécessaires pour identifier les lacunes dans les indications qui ne deviennent apparentes qu’en expérimentant le formulaire dans son ensemble.
\n

\n\n

Comment tester

\n

\n
1. Exécuter une analyse d’accessibilité automatisée comme base de référence. Utilisez axe DevTools (extension de navigateur ou CLI), Lighthouse dans Chrome DevTools, ou IBM Equal Access Checker sur la page contenant le formulaire. Bien que ces outils ne signalent pas directement les violations du critère 3.3.5, ils feront remonter des problèmes connexes tels que l’absence de libellés (élément label non associé à une saisie), l’absence de cibles aria-describedby, ou des implémentations d’info-bulles inaccessibles. Résoudre d’abord ces problèmes fondamentaux garantit que lorsque l’aide contextuelle est ajoutée, elle est également techniquement accessible.
\n
2. Auditer manuellement chaque champ de formulaire pour la disponibilité de l’aide. Pour chaque champ de saisie, demandez-vous : (a) Le libellé explique-t-il à lui seul complètement la saisie requise, y compris les exigences de format ? (b) Y a-t-il un texte d’aide supplémentaire visible adjacent au champ ? (c) Y a-t-il une icône d’aide, une info-bulle ou une section extensible qui fournit des indications supplémentaires ? (d) Y a-t-il un lien vers un contenu d’aide pertinent ? Si la réponse à toutes ces questions est non, et que le champ présente une quelconque ambiguïté, il s’agit d’un échec du critère 3.3.5.
\n
3. Tester l’accessibilité clavier de tous les mécanismes d’aide. Parcourez le formulaire en utilisant uniquement le clavier (sans souris). Vérifiez que chaque info-bulle, icône d’aide, description extensible ou lien d’aide est atteignable et activable au clavier. Les info-bulles doivent apparaître au focus ainsi qu’au survol. Les boutons d’aide doivent être déclenchés avec Entrée ou Espace. Tout mécanisme d’aide uniquement atteignable à la souris échoue à ce test.
\n
4. Tester avec NVDA + Firefox. Naviguez jusqu’à chaque champ de formulaire avec Tab. Écoutez ce que NVDA annonce pour chaque champ — annonce-t-il le libellé ? Annonce-t-il une description associée (via aria-describedby) ? Activez les icônes d’aide ou les info-bulles et confirmez que leur contenu est annoncé. Essayez d’atteindre le contenu d’aide lié et vérifiez qu’il est lié au champ actuel.
\n
5. Tester avec VoiceOver + Safari (macOS ou iOS). Utilisez VoiceOver pour parcourir le formulaire. Sur macOS, utilisez Tab pour passer d’un champ à l’autre et écoutez l’annonce complète pour chacun. Sur iOS, utilisez la navigation par balayage. Vérifiez que tout le contenu d’aide associé aux saisies est lu à voix haute, et que les déclencheurs d’aide (boutons, liens) sont accessibles et correctement étiquetés par VoiceOver.
\n
6. Tester avec JAWS + Chrome. Utilisez le mode formulaires de JAWS (activez-le avec Entrée lorsque vous êtes sur un élément de formulaire). Naviguez entre les champs avec Tab et vérifiez que JAWS lit les instructions et descriptions associées. Utilisez le curseur virtuel de JAWS pour vérifier que le contenu d’aide placé en dehors des associations de libellés standard est également atteignable.
\n
7. Réaliser un parcours cognitif. Demandez à une personne qui ne connaît pas le formulaire (ou simulez cela en le revoyant après une pause) d’essayer de le remplir sans aucune aide externe. Notez chaque point où elle hésite, pose une question ou commet une erreur en raison d’attentes peu claires. Chacun de ces points est un candidat pour une amélioration de l’aide contextuelle au titre du critère 3.3.5.
\n

\n\n

Comment corriger

\n

Champ de texte ambigu sans explication — Incorrect

\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

Champ de texte ambigu avec aide en ligne — Correct

\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

Icône d’aide avec info-bulle inaccessible aux utilisateurs de clavier — Incorrect

\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

Icône d’aide avec info-bulle accessible à tous les utilisateurs — Correct

\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

Formulaire complexe en plusieurs étapes sans aide au niveau des étapes — Incorrect

\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

Formulaire complexe en plusieurs étapes avec aide contextuelle par étape — Correct

\n\n

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