Mettre en conformité au RGAA son site web (Partie 2)
Nicolas, Directeur artistique, UX / UI Designer 13 mars 2025
Dans la première partie de ce “guide”, nous avons vu ensemble les sept premières sections du Référentiel Général d’Amélioration de l’Accessibilité, soit 42 critères. Cette fois nous continuons et terminons notre synthèse avec les 64 autres ! Installez-vous confortablement, c’est parti !
8. Éléments obligatoires
Cette section du RGAA ne devrait pas spécialement vous poser de problèmes techniques. En effet les critères relèvent ici du bon sens et n’importe quel développeur web devrait en grande partie y répondre par défaut.
Il s’agit notamment de bien indiquer le type de document (balise <doctype>), la langue par défaut (attribut lang sur la balise <html>) ou encore le titre (balise <title>). Il s’agit aussi d’avoir un code source valide, c'est-à-dire des balises bien imbriquées, des attributs non doublés sur les balises, des ID uniques… Jusqu’ici rien de sorcier.
S’il y a un changement de langue ou de sens de lecture au sein d’une page, par exemple une citation en arabe, vous devrez l’indiquer via une balise ayant l’attribut lang ou bien dir. Pour rappel les valeurs autorisées pour l’attribut dir sont “rtl” (right to left) ou “ltr” (left to right).
Le RGAA impose également que les balises ne soient pas utilisées “uniquement à des fins de présentation”. Vous devez donc respecter le rôle sémantique des balises et ne pas les détourner. Une balise <p> doit servir exclusivement à un paragraphe, une balise <blockquote> doit servir uniquement à une citation, une balise <a> doit servir uniquement à un lien… Vous comprenez la logique.
Voici un petit exemple. Si vous souhaitez qu’une partie de votre texte qui n’est pas une citation ressemble à une citation, vous devez appliquer des styles CSS sur votre paragraphe et non utiliser la balise <blockquote>.
D’une manière générale sur vos sites web : utilisez au maximum les classes CSS pour styliser vos balises, et sélectionnez vos balises en fonction de la sémantique. Cela devrait vous garantir la conformité avec ce critère. Sur notre site, nous avons dû ajouter une balise <address> et quelques balises <p> oubliées.
9. Structuration de l’information
Toujours au niveau de la sémantique, n’oubliez pas non plus que les niveaux de titres (Hn) doivent être correctement imbriqués. Par exemple une balise <h3> doit être précédée d’une balise <h2>.
Vous ne pouvez pas passer de <h1> à <h3>.
Imbrication valide :
Imbrication non valide :
C’est une règle logique mais quand plusieurs personnes interviennent sur le contenu ou quand votre structure de page est assez dynamique, une erreur d’imbrication peut vite survenir. Nous avons dû d’ailleurs en corriger quelques unes sur notre site !
Nous avons aussi revu quelques listes textuelles qui n’avaient pas été correctement encadrées par des balises <ul> et <li>. N’oubliez pas en effet que les listes doivent elles-aussi être bien structurées, qu’ils s’agissent de listes non ordonnées, de listes ordonnées, listes de descriptions ou encore d’une liste… de liens ! En effet d’un point de vue sémantique, une liste d’éléments similaires doit être structurée via <ul>, et la navigation (menu, sous-menu) est donc concernée (cf : code ci-dessous).
Enfin c’est également la structure du document au sens large qui doit être cohérente. Par de réelles difficultés à ce niveau, il suffit d’utiliser correctement les balises <header>, <footer>, <nav> et <main> pour valider le critère.
10. Présentation de l’information
Avec pas moins de 14 critères, la section "Présentation de l’information" est la plus longue du RGAA.
Mais restez avec moi, je vais essayer de rendre ça digeste !
Le premier stipule que vous devez au maximum utiliser des feuilles de style de CSS pour gérer la présentation de l’information et non des balises (ex : <big>, <center>…) ou attributs de présentation (ex : align, border, color…). Il s’agit de bonnes pratiques qui devraient être respectées depuis de nombreuses années.
Les points 2 et 3 demandent que la page soit consultable et parfaitement compréhensible même en désactivant les styles CSS. Si vous utilisez les bonnes balises sémantiques et qu’elles sont correctement imbriquées, vous devriez répondre à ces critères sans problème.
Attention toutefois, en utilisant des structures en flex, certaines propriétés permettant de changer l’ordre visuel des éléments peuvent être perturbantes. En effet, l’ordre dans le dom et l’ordre perçu sera différent, provoquant des confusions lors de l’usage d’un lecteur d’écran ou bien si les styles CSS sont désactivés.
Côté texte, l’utilisateur doit pouvoir agrandir le texte jusqu’à 200% mais aussi augmenter l’espacement entre les lignes, entre les mots et entre les lettres. Tout cela sans perdre d’information. Si vous utilisez dans votre design des blocs ayant des dimensions fixes (largeur et/ou hauteur), il y a de fortes chances que vous ne répondiez pas à ce critère. Vous devrez alors rendre votre design plus fluide pour que tous les textes restent bien lisibles.
Point clé de cette partie, la prise de focus. Celle-ci doit être clairement visible. Vos utilisateurs naviguant au clavier doivent en permanence savoir où ils se trouvent sur la page. La propriété CSS “outline”, souvent supprimée en raison de sa personnalisation limitée, permet de mettre en avant les éléments ayant le focus. Si toutefois vous décidez de l’enlever, c’est à vous de styliser l’élément au focus. Dans ce cas, veillez à utiliser un contour, un soulignage ou/et un fond suffisamment contrasté (ratio minimum de 3:1) sur un élément recevant le focus. N’utilisez pas seulement un changement de couleur au focus puisque les personnes ne percevant pas ou mal les couleurs ne verraient pas la différence.
Parfois, des contenus additionnels (ex : un sous-menu) apparaissent lors de la prise de focus ou du survol de la souris. Vous devez alors pouvoir correctement naviguer à l’intérieur de ces éléments au clavier, mais également pouvoir facilement fermer ces contenus additionnels (par exemple avec la touche Echap). D’une manière générale, les éléments apparaissant au survol sur le site doivent l’être également à la prise de focus, et vice-versa. Sur le site de Novaway, nous avons du revoir plusieurs styles de focus mais également notre menu principal pour optimiser la navigation au clavier. Il vaut mieux penser à ces points dès la conception de votre projet.
Autre élément essentiel de cette partie 10, l’information ne doit pas être donnée uniquement par la forme, la taille ou la position. Par exemple, mettre un lien en couleur n’est pas suffisant. Indiquer la rubrique active avec une couleur n’est pas non plus suffisant. Nous avons dû effectuer des modifications sur notre site pour mieux répondre au RGAA et voici quelques tips :
- Mieux vaut toujours souligner les liens, surtout au sein d’un texte (c’est moins utile dans un menu clairement identifié comme tel). L’utilisateur s’attend à ce qu’un texte souligné soit un lien. Si vous combinez une couleur différente du texte environnant à un soulignage, vos liens seront clairement identifiables. Vous pouvez aussi ajouter une icône à côté du lien, par exemple pour indiquer un lien externe.
- N’altérez pas trop l’aspect des éléments interactifs tels que les boutons. Il faut que ça ressemble à un bouton pour que cela soit bien compréhensible par l’utilisateur. Gardez par exemple un fond de couleur ou un contour.
- Utilisez l’attribut title pour donner l’information. C’est un point important que nous avons beaucoup utilisé. Par exemple sur un lien externe (<a href=”url du lien” target=”_blank”></a>), vous pouvez préciser dans l’attribut title “Nom du lien (ouvre un nouvel onglet)”. Dans le menu, vous pouvez indiquer pour la page active un title de ce genre “Nom de ma page - Page active”. Même chose pour un onglet actif, une page active dans la pagination...
Vous comprenez le principe : donnez une information claire et utile pour que les personnes ayant un handicap visuel puissent comprendre au mieux la navigation.
Sans grande surprise, le RGAA demande également que le scroll de la page soit dans une direction unique. Le scroll horizontal étant peu conventionnel, évitez de l’utiliser. Quelques exceptions peuvent s’appliquer, elles sont listées sur le site du référentiel.
Enfin (ouf !), les contenus cachés par défaut mais qu’il est possible d’afficher via une interaction (survol, clic, focus clavier) doivent être correctement restitués par les technologies d’assistance. Par exemple, si vous faites une FAQ et que les réponses sont masquées par défaut, elles doivent cependant être affichées suite à une interaction et bien lues par les technologies d’assistance.
11. Formulaires
On en vient aux formulaires avec pas moins de 13 critères concernés ! Globalement le RGAA veut que vos formulaires soient les plus explicites possibles.
Cela signifie d’abord de bien étiqueter chaque champ avec une balise <label> accolée ou un attribut title, aria-label ou aria-labelledby sur le champ lui-même. Dans le cas où un passage de texte accolé au champ permet de bien comprendre la nature de la saisie attendue, vous pouvez éventuellement vous passer d’étiquette. Évidemment, vous commencez à en avoir l’habitude, le texte explicatif, quelle que soit sa forme, doit être pertinent. Sur notre site, nous avons ajouté quelques étiquettes manquantes pour être conforme au référentiel.
Si un champ de formulaire est répété plusieurs fois dans la page (ex : un champ email), les étiquettes associées doivent être cohérentes. L’utilisateur doit comprendre que les saisies attendues sont de nature identique.
Le référentiel vous demande ensuite de bien regrouper les champs de même nature.
- Soit dans une balise <fieldset> en ajoutant également une balise <legend> pertinente à l’intérieur.
- Soit via un attribut role=”group” ou role=”radiogroup” (dans le cas de champs de type radio). Vous devrez alors ajouter une légende pertinente via les attributs aria-label ou aria-labelledby.
Lorsqu’il s’agit d’un select, vous devez aussi regrouper les items de la liste d’une même nature au sein d’une balise <optgroup> possédant un attribut label pertinent. Et évidemment, les boutons présents dans vos formulaires doivent eux aussi avoir un intitulé pertinent.
Ensuite le référentiel comporte deux critères liés au contrôle de saisie. Pour les résumer, retenez que vous devez donner un maximum de feedbacks à vos utilisateurs. Les champs obligatoires doivent être correctement indiqués, vos messages d’erreurs doivent être clairs, et vous devez indiquer le type ou le format des données attendues, voire donner un ou des exemples de saisies possibles.
Imaginons que l’on ait un champ date, on peut donner le format attendu et un exemple comme ceci : Saisissez une date au format JJ/MM/AAAA (ex : 20/03/2025).
C’est l’un des points que nous avons le plus revu sur notre site. Même si nos formulaires sont peu nombreux, ils méritaient d’être plus clairs au niveau des messages d’erreurs et des données attendues.
Il existe aussi un critère particulier pour les formulaires “sensibles”. C’est-à-dire dans le cas où votre formulaire a pour finalité la suppression ou la modification de données, s’il transmet des réponses à un test ou à un examen, ou si sa validation peut avoir des conséquences financières ou juridiques.
Dans tous ces cas, vous devez vous assurer que l’utilisateur peut bien modifier à nouveau les données, annuler ses modifications, ou bien qu’il existe un mécanisme de confirmation explicite.
Par exemple avant de soumettre les réponses à un examen, l’utilisateur doit cocher une case stipulant du caractère définitif de la soumission.
Dernier point de ce chapitre 11 tentaculaire, vous devez proposer l’auto-complétion des champs se rapportant à une information concernant l’utilisateur (son nom, son adresse, son numéro de téléphone, etc). La liste des valeurs possibles pour l’attribut autocomplete est visible ici. Cela fait donc un grand nombre de champs concernés.
12. Navigation
L’utilisateur souhaite naviguer de façon fluide et logique et le RGAA vous demande évidemment d’aller dans ce sens.
Tout d’abord vous devez proposer à minima deux moyens de naviguer parmi les suivants : menu de navigation, plan du site et moteur de recherche.
Ces moyens de naviguer doivent être situés au même endroit sur toutes les pages, tant au niveau visuel que dans la structure HTML. Les moyens d’accéder à ces éléments de navigation doivent donc être identiques d’une page à l’autre.
Si vous proposez un plan du site, il doit comme d’habitude être pertinent. Attention, cela ne signifie pas que toutes les pages du site doivent y figurer mais il doit être suffisamment représentatif de l’architecture générale du site. Sur notre site, nous n’avons pas de moteur de recherche et nous ne pouvions naviguer que via le menu principal. Nous avons donc rajouté un plan de site clair pour être en conformité.
Ensuite l’utilisateur doit pouvoir facilement “atteindre ou éviter” les zones de regroupement de contenus (telles que <header>, <nav>, <main>, <footer>…). Plusieurs solutions sont possibles mais la plus simple est certainement de leur ajouter un attribut WAI-ARIA de type landmark. La liste est disponible par ici. Vous devez par exemple ajouter l’attribut role="navigation" sur votre navigation principale.
Par ailleurs il est demandé de mettre en place un lien pour éviter la zone de contenu principal ou y accéder. Sur le site de Novaway nous avons ajouté un bandeau en haut de page lorsque l’utilisateur appuie pour la première fois sur la touche Tab. Ce bandeau comporte deux liens :
- Aller au menu
- Aller au contenu principal
Sur la FAQ, nous proposons d’accéder directement à la liste des thématiques ou bien aux questions/réponses de la thématique en cours.
Les points 8 et 9 sont eux aussi cruciaux puisqu’il s’agit d’offrir une navigation parfaitement cohérente au clavier. Si vous n’y avez pas pensé dès le départ, il est possible que ce point vous demande quelques ajustements, surtout si votre structure HTML est complexe. Pour synthétiser, l’ordre de navigation doit être logique et il ne doit pas y avoir de piège au clavier. Si l’utilisateur doit utiliser des touches spécifiques du clavier pour naviguer, vous devez lui indiquer clairement. Évidemment les contenus additionnels (popin, infobulle, sous-menu…) qui sont masqués par défaut doivent être parfaitement atteignables et navigables au clavier.
Par exemple, nous avons dû retravailler notre menu principal pour une parfaite navigation. Auparavant, en naviguant avec la touche TAB, l’utilisateur accédait au premier élément de niveau 1 (Expertise), parcourait obligatoirement le menu de niveau 2 associé, avant d’atteindre enfin l’élément de niveau 1 suivant. Et ainsi de suite. Il était donc fastidieux d’atteindre le dernier élément de niveau 1 du menu (Echangeons sur votre projet).
Désormais en naviguant avec la touche TAB, l’utilisateur parcourt les éléments de niveau 1 directement.
Il doit appuyer sur Entrée pour manuellement ouvrir un menu de niveau 2 et le parcourir. Ce fonctionnement logique évite de perdre du temps.
Il existe pour terminer une condition particulière pour les raccourcis clavier n’utilisant qu’une seule touche (lettre minuscule ou majuscule, ponctuation, chiffre ou symbole). Imaginez que sur votre application ou site, vous avez indiqué que la touche “A” du clavier permet d’ouvrir l’aide. Problème : si vous souhaitiez remplir un champ de formulaire avec la lettre “A”, cela va à la place ouvrir l’aide. Ennuyeux n’est-ce pas ?
Pour éviter tout conflit, ces raccourcis n’utilisant qu’une seule touche doivent être désactivables ou modifiables par l’utilisateur. Idéalement, définissez des raccourcis ne fonctionnant qu’au focus d’un composant spécifique.
13. Consultation
Et nous voici arrivés à la dernière section du RGAA. Vous êtes encore là ? Félicitations, c’est la dernière ligne droite ! Elle est riche en critères parfois complexes, mais certains sont assez spécifiques et ne s’appliquent peut-être pas à votre site web.
Le premier point concerne les modifications de contenus telles que les rafraîchissements de l’affichage ou les redirections. L’utilisateur doit pouvoir arrêter ou lancer ces procédés ou, s’ils sont automatiques, il doit pouvoir augmenter de dix fois au moins la limite de temps avant le prochain déclenchement.
Par exemple si votre site intègre un flux RSS s’actualisant automatiquement, l’utilisateur doit avoir la main sur sa fréquence de rafraîchissement.
Aussi, si la limite de temps d’une session dure moins de 20 heures, il doit pouvoir supprimer ou augmenter cette limite.
Autre point, plus simple, l’ouverture d’une nouvelle fenêtre ne peut pas être automatique. Elle doit être déclenchée par une action de l’utilisateur. Vous ne devez donc pas ouvrir de pop-up ou pop-under automatiquement (fenêtre s’ouvrant sous la page web à laquelle on accède et qui devient visible lorsque la fenêtre initiale est réduite ou fermée).
Note : dans le cas d’une popin nécessitant une action obligatoire de l’utilisateur avant d’entrer sur un site, comme le fait d’accepter/refuser les cookies ou de certifier son âge, il faut que cet élément soit atteignable au clavier immédiatement, avant le parcours de la page elle-même.
Les points 3 et 4 pourraient bien être chronophages si votre site propose de nombreux documents téléchargeables. Pour être conforme au RGAA, vos documents doivent eux aussi être accessibles.
Soit le document d’origine est conforme, soit vous devez proposer une alternative conforme proposant le même niveau d’information (un document alternatif ou une version alternative en HTML). Suivant le format de votre document (PDF, doc, docx, odt, epub…), différents outils d’analyse de l’accessibilité font foi. Vous les trouvez plus en détail dans la partie 13.3.1 du référentiel.
Les points 5 et 6 sont liés et vous demandent de proposer une alternative pertinente aux contenus cryptiques, c’est à dire utilisant des caractères ASCII. Vous avez peut-être sur votre site des “illustrations” réalisées à partir d’une succession de caractères ASCII, ou bien tout simplement des émoticônes représentées sous cette forme. Par exemple un sourire :). Dans ce cas vous devez donner une alternative via un attribut title ou directement en donnant la description pour les lecteurs d’écrans dans le contenu lui-même.
- <span title=”Smiley souriant”>:)</span>
- :) <span class=”sr-only”>Smiley souriant</span> (ou .sr-only est une classe masquant le contenu visuellement mais le conservant pour les lecteurs d’écrans).
Les deux critères suivants vous demandent de limiter les changements brusques de luminosité, les effets de flash / clignotements et de mouvements. Pour les clignotements, leur fréquence doit être inférieure à 3 secondes ou limités à une surface restreinte. Pour les mouvements, ils doivent être inférieurs à 5 secondes, sinon l’utilisateur doit pouvoir les contrôler (arrêt, marche, masquage…). Prenons l’exemple d’un slider de bannière en haut d’un site e-commerce. Le défilement automatique d’une bannière à l’autre doit être bref.
Et c’est encore mieux si c’est l’utilisateur qui gère manuellement le défilement.
On continue avec la nécessité de proposer une alternative aux gestes complexes. Ils doivent tous pouvoir se faire via un geste simple (un clic, un appui…). Le référentiel donne l’exemple très parlant des contacts multipoint tels que le zoom en pinçant avec les doigts qui doit aussi pouvoir se faire via des boutons “plus” et “moins”. Dans le même ordre d’idée, les fonctionnalités disponibles en bougeant l’appareil (gyroscopie) ou en faisant un geste dans sa direction, doivent pouvoir être lancées et désactivées via un composant d’interface. D’ailleurs la détection de mouvement doit pouvoir être purement et simplement désactivée.
Ultime point du référentiel général d’amélioration de l’accessibilité, la possibilité d’annuler une action déclenchée au moyen d’un dispositif de pointage sur un point unique de l’écran. Par exemple lors d’un glisser/déposer, l’action est annulée si l’utilisateur relâche l’élément en dehors de la zone cible.
De même, si l’utilisateur clique sur un lien mais relâche le clic en dehors du lien, l’action doit être annulée (pas d’ouverture du lien).
Et voilà qui termine notre série d’articles sur la mise en conformité d’un site web au RGAA. Oui, c’était dense, mais malgré tout cela reste une synthèse des 106 critères. Une fois de plus je vous invite à parcourir intégralement le référentiel pour bien l’assimiler et vous assurer d’être en conformité.
