Labels visibles et noms accessibles – Concevoir des formulaires accessibles

Par Mylène Boyrie, 5 janvier 2022

Temps de lecture : 13 minutes

Mot(s) clé(s) :

Les formulaires sont des composants-clefs dans la conception de sites Web accessibles. Malheureusement, ils sont également souvent les plus malmenés, ce qui rend la navigation particulièrement compliquée, voire impossible, aux personnes en situation de handicap.
plac
Afin de vous aider à concevoir des formulaires accessibles, nous vous proposons une série d’articles dédiée. Nous y détaillerons les règles de conception accessible pour les champs de formulaires, en explicitant les critères et tests demandés par le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) et en vous proposant des exemples concrets et documentés d’implémentation accessible.

Commençons par le b.a.ba, à savoir l’accessibilité des étiquettes de champs.

De quoi parle-t-on ?

Avant même d’entrer dans les détails concernant l’accessibilité des étiquettes de champ, il semble utile de proposer un glossaire rapide des termes utilisés dans le RGAA, pour adopter un langage commun.

Qu’est-ce qu’une étiquette de champ ?

Une étiquette est un texte placé à proximité immédiate d’un champ de formulaire. Elle permet de comprendre ce que l’on doit saisir dans le champ, mais également le format des informations attendues, lorsque nécessaire.

Ces étiquettes doivent donc être rédigées de manière pertinente, cohérente et sans ambiguïté, afin de permettre aux utilisatrices et utilisateurs de comprendre quelles informations saisir.

Extrait du formulaire de contact du site du FIPHFP (Fonds pour l'Insertion des Personnes Handicapées dans la Fonction Publique)
Extrait du formulaire de contact du site du FIPHFP (Fonds pour l’Insertion des Personnes Handicapées dans la Fonction Publique) – Chaque champ dispose d’une étiquette pertinente. Source : http://www.fiphfp.fr/Contact

Techniquement, il existe plusieurs manières d’associer une étiquette à un champ de formulaire :

  • En utilisant une balise <label>, à laquelle on ajoute un attribut for pour la relier au champ (balise <input type="text" />) ;
  • En utilisant l’attribut WAI-ARIA(1) aria-label sur le champ ;
  • En reliant l’élément texte à son champ grâce à l’attribut WAI-ARIA aria-labelledby ;
  • En utilisant l’attribut title sur le champ de formulaire.

Dans le Codepen qui suit, vous trouverez les différentes implémentations d’un même champ de texte, selon chaque possibilité :


Accéder au Codepen Different Label implementations on text inputs (en anglais).

Pourquoi il faut systématiquement associer une étiquette aux champs de formulaires

Il ne s’agit pas uniquement de compléter le champ d’une indication visuelle. L’objectif est de relier les deux éléments techniquement, ce qui permettra aux personnes utilisant des technologies d’assistance (par exemple, un lecteur d’écran) d’obtenir l’information concernant la nature, le type et le format de saisie attendus.

L’étiquette visible

L’étiquette visible d’un champ correspond au texte affiché visuellement à proximité de celui-ci, donc associé via une balise <label> ou un passage de texte relié via l’attribut WAI-ARIA aria-labelledby.

Le formulaire de contact de la librairie Rare birds book comprend des étiquettes visibles

Note : l’utilisation de la balise <label> propose une fonctionnalité utile, d’un point de vue ergonomique. Lorsque l’on clique sur l’étiquette, le focus bascule automatiquement dans le champ. La zone d’interaction avec le champ est ainsi étendue, un plus non négligeable pour les personnes pour qui la sélection sur un point précis de l’écran peut s’avérer compliquée (polyarthrite, maladie de Parkinson, toute maladie provoquant des tremblements,…).

Le nom accessible

Le nom accessible d’un composant correspond à ce qui est restitué par les technologies d’assistance lorsque l’on navigue dessus. Il est déterminé par la manière dont l’étiquette du champ est implémentée.

La zone de recherche du site de France Culture utilise un attribut `aria-label` pour pallier le manque d'étiquette visible sur le champ texte.
La zone de recherche du site de France Culture utilise un attribut `aria-label` pour pallier le manque d’étiquette visible sur le champ texte. Source : https://www.franceculture.fr/

Lorsque plusieurs de ces techniques sont présentes sur un même champ, le « calcul » du nom accessible obéit à l’ordre suivant :

  • s’il est présent, le contenu du passage de texte relié au champ par l’attribut aria-labelledby sera utilisé en tant que nom accessible ;
  • s’il n’y a pas d’attribut aria-labelledby, le contenu de l’attribut aria-label prendra le relai ;
  • s’il n’y a pas d’attribut aria-label, le contenu de la balise <label> sera utilisé en tant que nom accessible ;
  • enfin, s’il n’y a pas de balise <label>, l’attribut title placé sur le champ sera restitué.

La pertinence de l’étiquette du champ sera également évaluée selon cet ordre. Par exemple, si un champ de formulaire possède une balise <label> et un attribut aria-labelledby, seul le passage de texte référencé par aria-labelledby sera pris en compte.

Exemple non-conforme

Le champ de formulaire ci-dessous dispose d’une balise <label> masquée visuellement via la pseudo-classe CSS sr-only et d’un attribut aria-labelledby. Seul l’attribut aria-labelledby est pris en compte dans le calcul du nom accessible. Puisque le contenu du passage de texte associé n’est pas pertinent en tant qu’étiquette de champ, cet exemple n’est pas conforme au RGAA.


<h2 id="newsletter-heading">Inscrivez-vous à notre newsletter !</h2>
<label class="sr-only" for="email">Votre adresse email</label>
<input id="email" name="email" type="text" aria-labelledby="newsletter-heading" />

Exemple conforme

Le champ de formulaire ci-dessous dispose également d’une balise <label> masquée visuellement via la pseudo-classe CSS sr-only et d’un attribut aria-labelledby. Le contenu du passage de texte associé est ici pertinent en tant qu’étiquette de champ, cet exemple est donc conforme au RGAA.

Note : nous reviendrons sur le sujet dans un prochain article, mais cet exemple devrait être optimisé afin d’éviter une double restitution aux internautes utilisant un lecteur d’écran.


<h2 id="newsletter-heading">Inscrivez-vous notre newsletter !</h2>
<label class="sr-only" for="email">Votre adresse email</label> <input id="email" name="email" type="text" aria-labelledby="newsletter-description" />
<p id="newsletter-description">Veuillez renseigner votre adresse email (exemple de format attendu : nom.prenom@email.com).</p>

L’attribut title

L’attribut universel title permet d’afficher un passage de texte relatif à l’élément auquel il est rattaché (lien, champ de formulaire, iframe…). Lorsque l’on survole un composant comprenant un attribut title, son contenu s’affiche dans une bulle d’information native au navigateur Web utilisé.

Le formulaire d'inscription à la newsletter du site service-public.fr utilise l'attribut title en lieu et place d'une étiquette visible.
Le formulaire d’inscription à la newsletter du site service-public.fr utilise l’attribut title en lieu et place d’une étiquette visible. Source : https://www.service-public.fr/

L’attribut title est cependant problématique pour un grand nombre d’internautes, qui n’auront pas accès à son contenu :

  • Les personnes qui utilisent des appareils à interface tactile ;
  • Les personnes qui naviguent au clavier ;
  • Les personnes qui naviguent en utilisant des technologies d’assistance comme des lecteurs d’écran, des loupes logicielles ou le pilotage à la voix ;
  • Les personnes ayant des troubles musculaires ou cognitifs.

Le placeholder

L’attribut placeholder permet d’afficher un passage de texte par défaut dans les champs de texte et zone de texte. Il s’efface dès lors que l’on commence à saisir du contenu à l’intérieur du champ, faisant perdre à l’internaute le lien avec l’information attendue. Pour cette raison, le placeholder d’un champ ne peut pas faire office d’étiquette.

La plateforme de réservation de rendez-vous médicaux Doctolib affiche un formulaire de recherche utilisant des attributs placeholder en tant qu'étiquettes.
La plateforme de réservation de rendez-vous médicaux Doctolib affiche un formulaire de recherche utilisant des attributs placeholder en tant qu’étiquettes, sur sa page d’accueil. Le formulaire est donc inaccessible. Source : https://www.doctolib.fr/

Placeholder et restitutions par les lecteurs d’écran

S’il est désormais souvent restitué par la plupart des lecteurs d’écran, le placeholder n’est pas pris en compte dans le calcul du nom accessible des champs de formulaire. Il peut cependant arriver que le placeholder d’un champ soit restitué en lieu et place de son attribut title. Par conséquent, lorsque ces deux attributs sont présents, ils doivent être identiques, afin d’éviter toute confusion dans la restitution du nom accessible.

Impact utilisateurs – Label visible

On l’a vu, une bonne (ou mauvaise) implémentation des étiquettes de champs de formulaires aura un impact sur un grand nombre d’internautes :

  • Personnes aveugles, malvoyantes, avec une déficience visuelle ;
  • Personnes ayant un handicap moteur ;
  • Personnes ayant des problèmes d’attention, ou une mémoire à court terme limitée ;
  • Personnes ayant un handicap cognitif, psychique…

C’est pourquoi il est primordial de prendre le temps de comprendre cette question et de réfléchir à l’intégration de nos formulaires en amont. Les référentiels d’accessibilité sont là pour nous guider dans cette tâche :

  • WCAG 2.1 (Web Content Accessibility Guidelines – recommandation internationale rassemblant les règles pour l’accessibilité des contenus web)
  • RGAA 4.1 (Référentiel Général d’Amélioration de l’Accessibilité – référentiel français lui-même basé sur les WCAG)

Ce que le RGAA 4.1 demande

La dernière grande mise à jour du RGAA a opéré quelques changements dans l’implémentation des étiquettes de champs. Tant et si bien qu’il peut s’avérer difficile de s’y retrouver dans ces règles. Petit tour d’horizon des critères du RGAA 4.1 spécifiquement dédiés aux étiquettes de champs de formulaire. Chacun réunit plusieurs tests permettant de vérifier la conformité au critère.

Critère 11.1 [A] Chaque champ de formulaire a-t-il une étiquette ?

La première exigence du critère 11.1 est la présence d’une étiquette correctement reliée à chaque champ de formulaire. On retrouve dans les tests 11.1.1 et 11.1.2 les différentes manières d’associer une étiquette à son champ dont nous avons parlé plus tôt (<label>, aria-label, aria-labelledby, attribut title). Si l’une d’entre elles est correctement implémentée, alors ces tests sont réussis.

La seconde exigence concerne les étiquettes dont le contenu n’est pas visible, ou placées trop loin du champ. Le RGAA propose plusieurs possibilités pour assurer l’accessibilité de ces étiquettes :

  • Proposer un passage de texte accolé au champ permettant de comprendre la nature de la saisie attendue
  • Proposer un passage de texte accolé au champ et devenant visible à la prise de focus sur celui-ci, ce qui permet de comprendre la nature de la saisie attendue
  • Compléter le contenu non-visible de l’étiquette par un bouton adjacent au champ, lui donnant ainsi une étiquette visible en complément du nom accessible
  • Ajouter un attribut title au champ de formulaire

Correspondances WCAG 2.1

Critère(s) de succès WCAG 2.1 : 1.3.1 Info and Relationships (A), 2.4.6 Headings and Labels (AA), 3.3.2 Labels or Instructions (AA), 4.1.2 Name, Role, Value (A).

Un champ sans étiquette visible mais comprenant un attribut placeholder est-il considéré comme conforme ?

Nous avons reproduit dans l’exemple Codepen ci-dessous un champ de formulaire disposant :

  • D’une étiquette sous forme de balise <label> masquée visuellement
  • Un attribut placeholder reprenant le contenu exact de l’étiquette


Accéder au Codepen Example : A text input with a hidden label and a placeholder (en anglais).

Dans le cadre du RGAA, cet exemple serait non conforme, car on ne peut considérer le contenu de l’attribut placeholder en tant que passage de texte accolé au champ pour lui donner un contexte. Du point de vue de la navigation, le problème reste la disparition du contenu du placeholder lorsqu’on débute la saisie.

Cet exemple est cependant conforme si le formulaire dispose d’un champ unique, et qu’il est complété d’un bouton de validation lui donnant une étiquette visible. Dans ce cas précis, c’est bien le bouton qui permet la conformité du formulaire, et non pas la présence de l’attribut placeholder.

L’analyse de nos pairs nous intéressait, nous avons donc effectué un petit sondage sur le sujet sur Twitter . Le sujet fait débat, la présence d’un attribut title permettant la conformité du critère, à la différence de l’attribut placeholder. Pourtant, tous deux présentent des problématiques similaires d’un point de vue de l’expérience utilisateur, avec une présence partielle lors de la navigation et/ou auprès des internautes.

Critère 11.2 [A] Chaque étiquette associée à un champ de formulaire doit être pertinente

Le critère 11.2 demande la pertinence des étiquettes de champs de formulaire. Il s’agit ici de permettre à l’internaute de comprendre exactement la fonction du champ auquel l’étiquette est associée, quelle que soit la manière de l’implémenter (<label>, aria-label, aria-labelledby, attribut title).

La seconde exigence de ce critère concerne l’intitulé visible du champ. Si une étiquette visible est présente, et qu’elle est complétée par un nom accessible, alors le nom accessible doit reprendre au minimum l’étiquette visible du champ.

Exemple non-conforme


<label for="email">Votre adresse email</label>
<input id="email" title="inscrivez-vous à notre newsletter par email !" name="email" type="text" />

Exemple conforme


<label for="email">Votre adresse email</label>
<input id="email" title="Renseignez votre adresse email" name="email" type="text" />

Cas particuliers

  1. Si la ponctuation et les lettres majuscules varient entre le texte de l’intitulé visible et le nom accessible, le nom accessible restera conforme.
    
    <label for="email">Votre adresse email</label>
    <input id="email" title="votre adresse email" name="email" type="text" />
    
  2. Lorsque le texte de l’intitulé visible sert de symbole, il ne doit pas être repris tel quel dans le nom accessible. Le nom accessible doit exprimer la fonction véhiculée par le symbole. Par exemple, dans le cas d’un éditeur de texte, le bouton « B » aura pour nom accessible « Mettre en gras ».
  3. Si l’étiquette visible représente une expression mathématique, les symboles peuvent être repris tels quels dans le nom accessible (ex. : « A>B »).

Correspondances WCAG 2.1

Critère(s) de succès WCAG 2.1 : 2.4.6 Headings and Labels (AA), 2.5.3 Label in Name (A), 3.3.2 Labels or Instructions (AA).

Critère 11.3 [AA] Dans chaque formulaire, chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages est-elle cohérente ?

Le critère 11.3 s’attache à la cohérence des champs de formulaires ayant une fonction identique au sein d’une interface. Ainsi, lorsqu’un champ de formulaire est repris plusieurs fois dans une page (par exemple la saisie d’un mot de passe) ou un ensemble de pages (le même formulaire repris plusieurs fois dans le site, comme une inscription à une newsletter), son étiquette doit être pertinente et cohérente.

Exemple non-conforme


<label for="email">Renseignez votre adresse email</label>
<input id="email" name="email" type="text" />
<label for="email-confirmation">Renseignez votre adresse courriel</label>
<input id="email-confirmation" name="email-confirmation" type="text" />

Exemple conforme


<label for="email">Renseignez votre adresse email</label>
<input id="email" name="email" type="text" />
<label for="email-confirmation">Confirmez votre adresse email</label>
<input id="email-confirmation" name="email-confirmation" type="text" />

Correspondances WCAG 2.1

Critère(s) de succès WCAG 2.1 : 3.2.4 Consistent Identification (AA).

Critère 11.4 [AA] Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ?

Le critère 11.4 s’intéresse à la position de l’étiquette vis-à-vis de son champ. Chaque étiquette doit être visuellement accolée à son champ. L’idée est de placer l’étiquette à proximité immédiate de celui-ci, afin que la relation entre les deux ne puisse pas prêter à confusion.

Exemples d'étiquettes situées trop loin de leurs champs et d'étiquettes correctement accolées à leurs champs.
Exemples d’étiquettes situées trop loin de leurs champs et d’étiquettes correctement accolées à leurs champs. Source : Using Style Guides for Accessibility, Webdesign.tutsplus.com (en anglais)

Pour tous les champs, exception faite des cases à cocher, boutons radio ou boutons de type « interrupteur » (role ARIA « switch »), l’étiquette doit être placée :

  • Sens de lecture de l’étiquette de gauche à droite : immédiatement au-dessus ou à gauche du champ de formulaire
  • Sens de lecture de droite à gauche : immédiatement au-dessus ou à droite du champ de formulaire.

Concernant les étiquettes de champs de type cases à cocher, boutons radio ou boutons de type « interrupteur » (role ARIA « switch »), l’étiquette doit être placée :

  • Sens de lecture de l’étiquette de gauche à droite : immédiatement au-dessous ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de gauche à droite.
  • Sens de lecture de droite à gauche : immédiatement au-dessous ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de droite à gauche.
Le site How many plants propose un système de filtres via des listes de cases à cocher.
Le site How many plants propose un système de filtres via des listes de cases à cocher. Source : https://howmanyplants.com/plant-guides

Cas particuliers

La notion de sens de lecture est considérée comme non applicable, lorsque :

  • l’étiquette du champ mélange une portion de texte qui se lit de droite à gauche avec une portion de texte qui se lit de gauche à droite.
  • un formulaire contient des étiquettes en plusieurs langues, se lisant de droite à gauche et inversement.
    • Exemple : un formulaire de commande en arabe, proposant une liste de cases à cocher de produits étiquetés en langue française ou mixant des produits en langue arabe et en langue française.
  • les champs de type cases à cocher, boutons radio ou boutons de type « interrupteur » (role ARIA « switch ») ne sont pas visuellement présentés sous forme de boutons radio ou de case à cocher.
  • les champs sont utilisés dans un contexte où il pourrait être légitime, du point de vue de l’expérience utilisateur, de placer les étiquettes de manière différente à celle requise dans les tests 11.4.2 et 11.4.3.

Correspondances WCAG 2.1

Critère(s) de succès WCAG 2.1 : 3.3.2 Labels or Instructions (AA).

Exemples pratiques

Les référentiels d’accessibilité couvrent un vaste champ de possibles. Cependant, dans la pratique, il reste encore compliqué de faire appliquer ces règles aux équipes de conception et techniques.

Les besoins clients vont parfois à l’encontre des besoins des utilisatrices et utilisateurs, et de ce que demande le RGAA. Dès lors, comment faire pour les concilier techniquement ou lors de la conception ?

L’écueil rencontré le plus régulièrement est le suivant : « on ne veut pas afficher le label ». Les raisons peuvent être multiples, mais hors de question de tout simplement se passer d’étiquettes de champs en arguant un contexte particulier !

La première question à poser serait « pour quelle(s) raison(s) » ? Espace disponible, contexte technique, vision esthétique – argument discutable, mais soit – autre ? à partir de la réponse, on pourra commencer à réfléchir à la ou les solutions du problème. Car il n’existe pas une manière unique de concevoir une interface ou un composant accessible.

Label invisible + champ avec attribut title


<input id="abo-newsletterSubscriber" title="Saisissez votre adresse électronique (exemple : nom@exemple.fr)" autocomplete="email" name="email" type="email" placeholder="exemple : nom@exemple.fr" aria-label="Saisissez votre adresse électronique (exemple : nom@exemple.fr)" />

Techniquement, cette solution sera conforme au RGAA 4.1, l’attribut title étant prévu dans les critères 11.1 et 11.2.

Problème : on l’a vu, l’attribut title n’est pas disponible pour tout le monde, lors de la navigation. L’étiquette sera donc inaccessible pour les personnes naviguant sur un écran tactile, au clavier, à l’aide de technologies d’assistance ou les personnes ayant des troubles musculaires ou cognitifs. Cette solution est donc un patch que nous ne recommandons pas.

Label visible + champ sans nom accessible


<label for="abo-newsletterSubscriber">Votre adresse email (exemple : prenom.nom@mail.fr)</label>
<input id="abo-newsletterSubscriber" autocomplete="email" name="email" type="email" />

Cette implémentation sémantique est recommandée et applicable dans une majorité de cas. L’étiquette est ainsi accessible à toutes les typologies d’internautes. Petit plus, côté expérience utilisatrices et utilisateurs, la présence d’une balise <label> reliée par l’attribut for à son champ permet d’étendre la zone de focus du champ :

  • lorsqu’on clique sur l’étiquette, le focus est automatiquement basculé à l’intérieur du champ
  • la pseudo-classe CSS :focus-within permet d’afficher la prise de focus sur le combo étiquette + label.


Accéder au Codepen Label + Input + focus-within (en anglais).

Simuler la présence d’un placeholder via l’affichage de l’étiquette

Sur le site e-commerce Back Market, l'étiquette du champ textarea est placée visuellement à l'intérieur de celui-ci, simulant un placeholder.
Sur le site e-commerce Back Market, l’étiquette du champ <textarea> est placée visuellement à l’intérieur de celui-ci, simulant un placeholder. Lorsque l’on prend le focus sur le champ, l’étiquette est déplacée visuellement au dessus de celui-ci. Dans la version HTML ci-après, on s’aperçoit que l’implémentation choisie correspond au combo balise <label> + champ.

<div class="_310FCbVM">
<label for="message" class="font-body text-2 leading-2 font-light X-jZ7yOZ">Entrez votre message…</label>
    <div class="font-body text-2 leading-2 font-light _3A2fXs6f">
        <textarea id="message" class="_2YJLmdZh" style="height: 48px;" rows="1"></textarea>
    </div>
</div>

Label invisible + champ

Le champ est complété par un texte adjacent

Si le champ ne dispose pas d’étiquette visible, il est possible de compléter celui-ci par un passage de texte adjacent, qui permettra de comprendre la nature de la saisie attendue. Dans la plupart des cas, cela signifie la perte du gain d’espace qui a amené le masquage initial du label, donc autant afficher l’étiquette par défaut.


Accéder au Codepen Hidden Label + Input + Visible aria-labelledby (en anglais).

Note : il est possible d’afficher ce passage de texte à la prise de focus sur le champ uniquement (cf. exemple suivant).

Le label devient visible à la prise de focus

Si masquer la balise <label> est inévitable, cette technique permet de l’afficher à la prise de focus sur le champ. Les internautes ont ainsi accès à l’étiquette au moment de saisir les informations attendues.

Si cette version est conforme, elle n’en reste pas moins insatisfaisante, car l’information est indisponible tant que l’internaute n’a pas interagi avec le champ. Nous recommandons plutôt d’utiliser l’exemple de Back Market présenté dans la partie précédente : le label est visible et simule un placeholder, puis déplacé au dessus du champ au moment de la saisie.


Accéder au Codepen Label visible on focus + Input (en anglais).

Le champ est complété par un bouton adjacent

Dans son encart d'inscription à la newsletter, le site e-commerce Rare birds books masque l'étiquette du champ.
Dans son encart d’inscription à la newsletter, le site e-commerce Rare birds books masque l’étiquette du champ, cependant le bouton adjacent permet d’en comprendre la fonction, en plus de son nom accessible. Source : https://rarebirdsbooks.com/#shopify-section-footer

Ce cas précis est plus adapté dans le contexte d’un formulaire à champ unique, et accompagné d’un bouton : par exemple un formulaire de recherche ou l’inscription à une newsletter. Le bouton de formulaire donnera une étiquette visible au champ, en complément de son nom accessible.


Accéder au Codepen Hidden label + input + button (en anglais).

À retenir

Comment étiqueter de manière accessible les champs de formulaire ? Récapitulons :

  1. On donne systématiquement une étiquette à chaque champ de formulaire ;
  2. On ne masque pas l’étiquette du champ à moins d’y être réellement obligé ;
  3. L’étiquette visible dispense d’ajouter un nom accessible au champ ;
  4. On limite donc au maximum le cumul des implémentations d’étiquettes. Une balise <label> OU un attribut aria-label OU un attribut aria-labelledby.
  5. L’attribut title n’est PAS nécessaire. Rester simple permet d’éviter une restitution trop verbeuse des technologies d’assistance.

Pour poursuivre ma réflexion, j’ai rédigé un second article Le contrôle de saisie – Concevoir des formulaires accessibles, dans lequel je me focalise sur les aides à la saisie et messages d’erreurs.

Notes

  1. WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) : spécification technique du W3C (en anglais) : www.w3.org/WAI/standards-guidelines/ariaRetour au texte ↑