Champ d’autocomplétion

Un champ d’autocomplétion est une zone d’édition de texte qui déploie une liste de suggestions lors de la saisie. Les exemples qui accompagnent cette fiche illustrent un comportement d’autocomplétion de type « liste avec sélection manuelle » :

• Lorsque l’internaute saisit une chaîne de caractères dans le champ d’édition et que celle-ci correspond à un ou des éléments de la liste prédéfinie, ces éléments apparaissent dans une liste de suggestions;
• Aucune suggestion n’est automatiquement sélectionnée lors de l’affichage de la liste;
• Si l’internaute quitte le champ sans choisir une suggestion, le texte saisi devient la valeur finale du champ.

Cette approche flexible permet d’opter pour une valeur de la liste, tout en autorisant une saisie personnalisée.

Les champs d’autocomplétion ont gagné en popularité ces dernières années, mais leur intégration dans les pages Web comporte souvent des obstacles fonctionnels pour différentes clientèles. Par exemple, les personnes utilisatrices de lecteurs d’écran peuvent être confrontées à des champs d’autocomplétion non identifiés comme tels, ou ne pas percevoir l’apparition des listes de suggestions. De plus, les personnes qui naviguent par d’autres moyens que la souris (clavier, commandes vocales, pointeur, etc.) peuvent rencontrer des difficultés à accéder aux suggestions et à confirmer leur choix, si ces modes de navigation ne sont pas pris en compte.

Les exemples proposés visent à remédier aux obstacles d’accessibilité courants, avec une attention particulière portée aux interactions fonctionnelles et à la compatibilité avec les outils d’adaptation. Des aspects d’utilisabilité sont également pris en compte, afin de mieux soutenir une variété de besoins utilisateurs.

Dans ce qui suit, le mot « suggestions » désigne les correspondances qui apparaissent dans la liste déroulante de l’autocomplétion. Nous privilégions ce terme pour éviter toute confusion avec des résultats obtenus après la soumission d’un formulaire (ex. : champ de recherche avec autocomplétion).

Voici les principaux comportements attendus avec les outils d’adaptation (lecteurs d’écran, commandes vocales, etc.) ainsi que la navigation au clavier :

• Le champ d’autocomplétion est reconnu et annoncé comme tel par les outils d’adaptation.
  • Remarque : La plupart des lecteurs d’écran n’utilisent pas le mot « autocomplétion » pour désigner ce composant, mais annoncent la combinaison d’un champ d’édition et d’une liste déroulante.
• (Recommandé) Au focus du champ d’édition, des explications concernant la manière de naviguer dans l’autocomplétion sont fournies aux personnes utilisatrices de lecteur d’écran.
• Lors des interactions avec l’autocomplétion, les lecteurs d’écran transmettent les informations de contextualisation suivantes :
  • Sans quitter le champ d’édition :
    • La présence de suggestions sous forme de liste déroulante, ainsi que l’absence de correspondances, s’il y a lieu.
    • L’état étendu ou réduit de la liste de suggestions.
    • (Recommandé) Le nombre de suggestions disponibles.
    • Les changements dans le nombre de suggestions disponibles.
    • (Si applicable) La présence d’une valeur préremplie dans le champ d’édition.
    • (Si applicable) La présence d’une option actuelle définie par défaut dans la liste.
  • Lors de la navigation dans la liste de suggestions :
    • Le nombre de suggestions dans la liste.
    • La suggestion mise en focus (en surbrillance) dans la liste (ex. : « Option actuelle : Montréal »).
    • (Recommandé) La position de la suggestion qui reçoit le focus dans la liste (ex. : « Option actuelle : Montréal 1 sur 3 »).
  • Lors du choix d’une suggestion :
    • Le libellé de la suggestion validée par l’utilisateur et son report dans le champ d’édition.
• Le champ d’édition et la liste déroulante de suggestions sont utilisables au clavier, en suivant les interactions prévues :
  • Seul le champ d’édition reçoit le focus avec la touche Tabulation. La navigation dans la liste de suggestions s’effectue avec les touches Flèche haut et Flèche bas.
  • Lorsque l’internaute est dans la liste de suggestions, il peut confirmer le choix d’une option avec Entrée, Espace ou Tabulation.
    • Avec Entrée ou Espace : La valeur de l’option choisie est reportée dans le champ d’édition et le focus revient sur ce dernier. La liste déroulante se ferme.
    • Avec Tabulation : La valeur de l’option choisie est reportée dans le champ d’édition et le focus se déplace sur le prochain élément de la page pouvant accueillir le focus par tabulation. Puisque le focus se déplace hors du composant, les lecteurs d’écran pourraient interrompre l’annonce de certaines informations de contextualisation, telles que l’état réduit de la liste déroulante et le report de la valeur choisie dans le champ d’édition.
  • Lorsque la liste est étendue, la touche Échap ferme cette liste et le focus retourne sur le champ d’édition, s’il n’y était pas déjà.
• Le champ d’édition est sélectionnable à l’aide d’outils de commandes vocales, en dictant son libellé visible. La liste déroulante est également navigable à l’aide des commandes usuelles de ce type d’outil.
• La navigation dans la liste des suggestions et la sélection d’une valeur sont possibles à l’aide d’un seul pointeur (un doigt, une baguette de saisie, une souris, etc.). De même, ces actions sont possibles sans recourir à des mouvements de glisser-déposer ou à l’activation simultanée de plusieurs touches.
• Lorsque la liste de suggestions n’est plus visible, elle n’est pas exposée aux outils d’adaptation ni à la navigation au clavier.

Autres aspects à surveiller

Certains champs d’autocomplétion requièrent la saisie d’un nombre minimal de caractères pour obtenir des suggestions. La manière de communiquer cette information dépend du modèle d’interactions choisi. Dans nos exemples, les rétroactions visibles (liste de suggestions, message d’absence de suggestions) n’apparaissent que si le nombre de caractères minimal est atteint. L’approche suivante est donc utilisée :

• Avec un lecteur d’écran, en deçà du nombre minimal de caractères, un message d’état indique l’absence de suggestions et rappelle le nombre attendu de caractères. Ex. : « Veuillez saisir 2 caractères ou plus pour obtenir des suggestions. »
• Les personnes voyantes n’ont pas besoin de ce message d’état, car elles perçoivent l’absence de rétroactions de l’autocomplétion, jusqu’à l’atteinte du nombre requis de caractères. Cependant, une bonne pratique consiste à fournir une instruction de saisie qui indique la présence d’une fonctionnalité d’autocomplétion, tout en précisant le nombre de caractères minimal pour en bénéficier. La variante de champ d’autocomplétion illustre ce cas de figure.

La conception d’un champ d’autocomplétion accessible fait appel à un plus grand nombre de requis techniques que certains autres composants interactifs. Cette section fournit une vue d’ensemble des principaux points à surveiller. Pour mieux comprendre l’intégration de chaque élément, nous vous encourageons à examiner le code source des exemples fournis en parallèle à la lecture de cette section. Nous suggérons également de consulter la section Sources utilisées pour la création des exemples, qui donne notamment accès à la documentation du composant d’origine ayant servi de base à notre autocomplétion.

Rôles, états et propriétés ARIA

Champ d’édition

• Le champ d’édition utilise une balise <input> de type text. Il est dûment associé à son étiquette (<label>), laquelle possède un attribut for reprenant la valeur de l’identifiant (ID) du champ.
• Le champ d’édition reçoit également les attributs et valeurs suivants :
  • role="combobox" : déclare qu’il s’agit d’un champ de saisie accompagné d’une liste de suggestions prédéfinies.
  • aria-autocomplete="list" : indique qu’une liste d’options va s’afficher.
  • autocomplete="off" : empêche les navigateurs d’afficher leurs propres suggestions, pour ne pas interférer avec celles du composant.
  • aria-expanded : sa valeur est définie à true quand la liste de suggestions est visible (état étendu), et à false lorsqu’elle ne l’est pas (état réduit).
  • aria-controls : sa valeur reprend l’identifiant (ID) donné à la liste de suggestions. Cela permet d’établir un lien programmatique entre le champ d’édition et la liste de suggestions qu’il contrôle.
  • aria-activedescendant : sa valeur correspond à l’identifiant (ID) de l’option de la liste de suggestions qui se trouve actuellement en focus.
  • (Recommandé) aria-describedby : sa valeur correspond à l’identifiant (ID) donné au texte d’aide à la navigation pour les personnes utilisatrices de lecteur d’écran. Dans les exemples, cette description est masquée à tous les utilisateurs avec la mise en forme CSS display:none. Cela évite au lecteur d’écran de l’inclure dans le parcours régulier de lecture, mais lui permet tout de même d’en faire l’annonce au moment opportun, lors de la mise en focus du champ d’édition.

Liste de suggestions

• La liste de suggestions est codée avec la balise <ul> et englobe les différentes options balisées avec <li>.
• La liste de suggestions (<ul>) reçoit les attributs et valeurs suivants :
  • role="listbox" : déclare qu’il s’agit d’une liste à partir de laquelle un utilisateur peut sélectionner un ou plusieurs éléments.
  • aria-labelledby : sa valeur correspond à l’identifiant (ID) du champ d’édition. Cela permet de désigner le nom accessible de la liste de suggestions comme étant le même que son champ d’édition associé (ce champ ayant lui-même un nom accessible déterminé par son étiquette). Alternativement, il est aussi possible de donner un attribut aria-label à la liste de suggestions. Nous recommandons toutefois la première approche, qui maintient une meilleure cohérence dans les noms accessibles.
• Chaque option (<li>) incluse dans la liste de suggestions reçoit les attributs et valeurs suivants :
  • role="option" : déclare une option que l’on peut sélectionner dans la listbox.
  • aria-selected : sa valeur est définie à true quand l’option reçoit le focus clavier (ou tout événement équivalent au focus clavier lors de la navigation avec un outil d’adaptation). La valeur est définie à false quand l’option n’a pas le focus.
    • Remarque : La valeur true survient lorsque l’option est déclarée en focus via l’attribut aria-activedescendant donné au champ de saisie.
  • aria-setsize : sa valeur indique le nombre total d’éléments présents dans la liste qui contient cette option.
  • aria-posinset : sa valeur indique le positionnement (ordonnancement) de l’option par rapport aux autres options de la liste. L’attribut doit nécessairement être utilisé en combinaison avec l’attribut aria-setsize.

Messages d’état

• Des messages d’état (listés plus bas) sont injectés dans une zone à laquelle on assigne aria-live="polite". Cette zone est un <div> visuellement caché par un positionnement hors écran. Le paramètre de politesse permet d’attendre que l’utilisateur de lecteur d’écran ait interrompu sa saisie ou sa navigation pour annoncer le message d’état. Les éléments avec aria-live="polite" ont un rôle implicite status, qui peut être ou non présent dans le code.
• Voici un résumé des principaux types de messages d’état utilisés dans les exemples d’autocomplétion :
  • Lorsque le focus est dans le champ d’édition : le nombre de suggestions disponibles ou l’absence de suggestions. Si applicable, un rappel du nombre minimal de caractères à saisir pour obtenir des suggestions, quand l’utilisateur n’a pas atteint ce nombre.
  • Lors de la navigation dans la liste de suggestions : un rappel du nombre de suggestions disponibles, ainsi que l’option actuelle en focus et sa position dans la liste. Ces informations visent à complémenter le support inégal de certains attributs ARIA.

Autres considérations techniques

• Divers aspects de l’autocomplétion sont gérés par JavaScript, notamment :
  • L’ouverture et la fermeture de la liste de suggestions, ainsi que l’affichage des suggestions qui correspondent à la saisie.
  • Le changement dynamique des valeurs de plusieurs attributs ARIA : aria-expanded et aria-activedescendant (pour le champ d’édition); aria-posinset et aria-setsize (pour les options de liste).
  • Les comportements attendus lors d’une navigation au clavier, décrits dans les critères fonctionnels.
  • L’injection des différents messages d’état dans la zone aria-live.
• Un tabindex="-1" est donné à la balise <li> ayant le rôle option. Cela permet de programmer le positionnement du focus sur les options lors de la navigation dans la liste de suggestions, en évitant toutefois que le focus de Tabulation puisse s’y retrouver.
• Il faut éviter l’emploi de l’attribut aria-owns, donné au champ d’édition dans certains modèles d’autocomplétion. Il ne permet pas le parcours adéquat du focus dans la liste de suggestions avec certains lecteurs d’écran comme VoiceOver iOS en navigation tactile. L’emploi de aria-controls demeure l’approche la plus robuste pour l’association programmatique entre le champ et la liste de suggestions.
• La mise en forme CSS display:none est appliquée à la liste de suggestions lorsqu’elle est fermée. Cela permet de masquer ses contenus aux outils d’adaptation et à la navigation au clavier.

Pour les champs de recherche utilisant l’autocomplétion

La présence d’un bouton de soumission est fortement conseillée dans ce cas, pour renforcer l’utilisabilité :

• L’envoi de la requête et le résultat de l’action sont plus prévisibles. L’internaute contrôle le moment où la valeur est soumise et s’attend à une rétroaction.
• Lorsque des personnes emploient la touche Tabulation pour confirmer un choix d’autocomplétion, le bouton accueille le focus sortant. Cela évite que le focus se retrouve en dehors du contexte immédiat de la requête ou de la rétroaction.

Fournir un bouton de validation n’exclut pas la possibilité de permettre l’envoi des valeurs du champ avec la touche Entrée. Cela est d’ailleurs prévu dans l’exemple fourni.

Rappel d’accessibilité : Le bouton de validation doit être placé dans un ordre logique de lecture et de tabulation (à la suite du champ d’édition et de sa liste de suggestions).

L’autocomplétion comme aide à la saisie

Autant que possible, l’autocomplétion doit être un moyen de faciliter la saisie ou le choix d’une option, plutôt que de constituer une contrainte à la saisie.

Pour des champs de recherche avec autocomplétion, on recommande de laisser les internautes soumettre une requête même s’il n’y a aucune correspondance dans la liste de suggestions. Si une structure ou un format spécifique est attendu, il est préférable de gérer cette contrainte par des instructions et des rétroactions robustes, tout en offrant des solutions de rechange.

Par exemple, si la saisie d’une adresse postale ne renvoie aucune suggestion d’autocomplétion, les résultats de recherche pourraient inclure une liste d’adresses apparentées susceptibles de correspondre à la requête, ou la possibilité d’éditer soi-même l’adresse selon le format attendu.

Cette approche limite les frictions et abandons dans le parcours utilisateur. De plus, elle offre une flexibilité pour gérer des cas particuliers non pris en compte dans l’autocomplétion.

Dans le même esprit, les fonctionnalités de recherche approximative (en anglais, fuzzy search) rehaussent l’utilisabilité. Elles permettent d’obtenir des suggestions ou des résultats même quand la requête contient des erreurs de frappe, des fautes d’orthographe ou des variations.

Nos exemples d’autocomplétion intègrent en partie ces préoccupations. Les correspondances établies dans la liste de suggestions sont insensibles à la casse et aux accents. De plus, l’ajout accidentel d’espaces au début de la saisie ne compromet pas le rendu des suggestions. D’autres améliorations seraient possibles pour augmenter la tolérance à l’erreur. L’article suivant (en anglais) présente plusieurs pistes d’optimisation pour le composant qui a servi de base à notre exemple : Improvements to our autocompletes.

Nous avons relevé trois enjeux de l’autocomplétion avec certains outils d’adaptation. Ces problèmes sont causés par les outils eux-mêmes et demeurent à ce jour non résolus. Nous estimons que l’impact n’est pas suffisant pour renoncer à la présentation des exemples dans leur forme actuelle.

Avec Dragon : impossibilité de sélectionner une option de liste en dictant son libellé

• Environnement d’observation : Dragon 16 (logiciel de commandes vocales), avec les versions les plus récentes de Chrome et Firefox en date du 21 mars 2025.
• Résumé du problème : Il n’est pas possible de cliquer sur une option de la liste des suggestions en dictant son libellé visible. Pourtant, les zones de liste déroulante natives permettent cette méthode d’activation. Les utilisateurs s’attendent donc à pouvoir utiliser la même approche et sont confrontés à des incohérences dans les interactions.
• Comportement attendu : La liste de suggestions de l’autocomplétion, qui possède un rôle ARIA listbox, devrait permettre le même type d’interactions vocales qu’une zone de liste déroulante native, laquelle possède également le rôle implicite de listbox.
• Impact estimé : Modéré. Même si l’enjeu est irritant, il demeure possible de sélectionner l’option par d’autres moyens, notamment en simulant le déplacement des touches fléchées, ou à l’aide de l’option Grille.
• Décision : Ce bogue émane du logiciel Dragon. Un suivi sera effectué auprès des équipes de développement de cet outil.

Avec VoiceOver iOS : erreur de rétroaction d’état condensé en sortie du clavier virtuel

• Environnement d’observation : Versions les plus récentes de VoiceOver iOS, Safari iOS et Chrome iOS en date du 21 mars 2025.
• Résumé du problème : L’enjeu se produit dans Safari iOS, lorsque l’utilisateur sort du clavier tactile virtuel avec l’option OK, et que le focus revient dans le champ d’édition de l’autocomplétion. À ce moment, VoiceOver dit « condensé » même si une liste de suggestions est affichée. Par contre, si on survole le champ avec un doigt, le bon état est communiqué. Par ailleurs, dans Chrome iOS, le bon état est toujours annoncé en fermeture du clavier virtuel.
• Comportement attendu : VoiceOver iOS devrait toujours dire « Étendu » si une liste de suggestions est ouverte.
• Impact estimé : Modéré à important. Une annonce d’état erronée crée de la confusion. Cependant, le composant est codé pour annoncer le nombre de suggestions offertes sans quitter le champ d’édition. Par conséquent, la présence de suggestions demeure perceptible malgré le bogue.
• Décision : Le bon fonctionnement dans Chrome iOS est révélateur d’un bogue d’interaction spécifique entre VoiceOver iOS et Safari iOS. Un suivi sera fait auprès des équipes de développement et d’accessibilité d’Apple.

Avec JAWS et NVDA : nécessité d’activer deux fois la touche Échap pour fermer la liste de suggestions

• Environnement d’observation : Versions les plus récentes de JAWS, NVDA et Chrome en date du 21 mars 2025.
• Résumé du problème : Avec ces lecteurs d’écran, on doit appuyer deux fois sur Échap pour fermer la liste déroulante. La première activation entraîne la sortie du mode formulaire. La seconde activation ferme la liste, avec un retour adéquat du focus. Comme l’activation d’Échap ne produit pas immédiatement le comportement de fermeture, les utilisateurs peuvent penser que cette fonctionnalité n’est pas offerte.
• Comportement attendu : Une fermeture immédiate de la liste serait souhaitable, dès la première activation d’Échap. Ce comportement est bien reproduit par d’autres lecteurs d’écran (TalkBack, VoiceOver Mac et VoiceOver iOS), ainsi que lors d’une navigation au clavier sans lecteur d’écran.
• Pistes et analyses techniques : Dans JAWS et NVDA, la touche Échap est dédiée à la sortie du mode formulaire. Cela peut en partie expliquer l’enjeu, notamment pour le champ d’édition. Toutefois, les deux lecteurs d’écran adoptent le comportement attendu lors de la fermeture avec Échap d’une zone de liste déroulante native. On peut donc se demander pourquoi le comportement n’est pas similaire avec une liste déroulante d’autocomplétion, quand le focus est à l’intérieur de celle-ci.
• Impact estimé : Modéré. Une sensibilisation des utilisateurs à la prise en main d’une autocomplétion accessible pourrait atténuer cet impact.
• Décision : Le comportement observé ne dépend pas de notre composant, mais du paradigme d’interactions de JAWS et NVDA. Il est peu probable que des changements surviennent dans un proche avenir. Pour JAWS, l’enjeu est classé sans suite dans un ticket sur le profil GitHub de Freedom Scientific (en anglais). Cela est considéré comme une fonctionnalité du lecteur d’écran, plutôt qu’un bogue.

Les exemples fournis sont une adaptation du champ d’autocomplétion du gouvernement du Royaume-Uni. Ce composant a retenu notre attention pour plusieurs raisons :

• Il offre une base solide pour l’accessibilité, tant technique que fonctionnelle.
• Une attention particulière a été portée à l’expérience utilisateur lors de sa conception.
• Il a été testé auprès de profils variés de personnes en situation de handicap.
• Des tests comparatifs effectués avec d’autres modèles d’autocomplétion, dont ceux du W3C, suggèrent une meilleure prise en main du composant du Royaume-Uni. À ce sujet, voir notamment les constats de la société Orange.

En partant de cette base, nous avons effectué divers ajustements, qui tiennent compte des aspects traités dans cette fiche :

• Fermeture de la liste de suggestions avec Échap : Dans la version utilisée du composant (v3.0.1), le focus ne retourne pas correctement sur le champ d’édition lorsque la liste est fermée avec la touche Échap. Plusieurs ajustements JavaScript ont été nécessaires pour rétablir le comportement attendu sans altérer d’autres fonctionnalités. Pour plus de détails, voir les commentaires inclus dans le script de correctif de l’exemple.
• Flexibilité des correspondances : Nous avons bonifié le script de normalisation pour qu’il préserve le rendu des suggestions si l’internaute omet de saisir des accents, ou insère accidentellement des espaces avant l’expression recherchée. Pour d’autres possibilités d’amélioration, voir l’article suivant (en anglais) : Improvements to our autocompletes.
• Traduction des ajouts de contextualisation pour les lecteurs d’écran : Nous avons rencontré un défi pour traduire la notion d’élément de liste en surbrillance. La version anglaise prévoit une rétroaction telle que : « Montreal 1 of 6 is highlighted ». Les termes « surligné » ou « en surbrillance » posaient des enjeux de compréhension, en raison du niveau de langue et de la référence à une caractéristique visuelle. Nous avons également exclu l’emploi du mot « sélectionné », qui créait de la confusion sur l’état de l’élément. Au final, nous avons retenu la formulation « Option actuelle: Montréal 1 de 6 ». Cette dernière :
  • utilise des termes simples qui ne s’appuient pas sur un référent visuel;
  • demeure courte, avec une structure mieux adaptée aux longs énoncés;
  • donne moins l’impression que l’élément courant a été choisi ou appliqué au champ.
• Autres modifications terminologiques : L’autocomplétion d’origine emploie le terme « résultats » pour désigner les correspondances d’autocomplétion. Notre adaptation utilise plutôt « suggestions », pour les motifs expliqués dans la section Critères fonctionnels.
• Autres paramètres de personnalisation du composant :
  • À activer : confirmation en sortie de l’option courante  (ConfirmOnBlur: true).  Lorsque l’utilisateur sort de l’autocomplétion en appuyant sur Tabulation, cela confirme le choix de l’option courante (en surbrillance). Cette option est alors reportée dans le champ d’édition.
  • À désactiver : autosélection de la première option (Autoselect: false). Ce paramètre définit le premier élément de la liste comme option actuelle par défaut. Nous recommandons de l’éviter, car cela augmente les risques de sélections accidentelles. En effet, il n’est plus nécessaire de naviguer à l’intérieur de la liste de suggestions pour confirmer un choix d’option. Par ailleurs, le paramètre contient un bogue critique. Si l’utilisateur ferme la liste de suggestions avec Échap, le composant garde en mémoire la première option de la liste, qui peut être soumise sans égard au contenu du champ d’édition. D’éventuels correctifs nécessiteraient un travail important en amont et nous avons choisi de ne pas nous engager dans cette voie pour le présent exemple. Cependant, des démarches sont envisagées auprès des équipes de développement du composant.
• Création d’une variante : Le second exemple ajoute une instruction de saisie dans l’étiquette du champ (nombre de caractères pour obtenir des suggestions). Cette information profite alors à l’ensemble des utilisateurs, plutôt que seulement aux clientèles utilisatrices de lecteurs d’écran. Dans cette variante, il a fallu procéder à un ajustement pour éviter que l’instruction ajoutée produise des redondances avec certains messages d’état déjà présents dans l’exemple de base. Ainsi, nous attendons que la saisie soit amorcée avant de transmettre aux lecteurs d’écran un message qui rappelle le nombre de caractères minimal pour obtenir des suggestions.

Enfin, nous avons enrichi l’exemple de certaines fonctionnalités (confirmation du résultat de recherche, validation de formulaire) pour mieux contextualiser le composant et faciliter sa prise en main. Néanmoins, ces éléments ne font pas partie de l’autocomplétion.