Mettre en conformité au RGAA son site web (Partie 1)

Le mois dernier, nous vous avons introduit à l’accessibilité numérique, ses grands principes et ses référentiels. Aujourd’hui nous vous proposons la première partie (sur 2), de notre dossier pour vous aider à mettre en conformité au RGAA votre site web. Nous prenons comme exemple notre propre site et nous vous donnons des conseils. 

Veuillez noter que le Référentiel général d’amélioration de l’accessibilité est un guide long et relativement technique. Il ne couvre pas moins de 106 critères répartis dans 13 thématiques.
Cet article n’a pas vocation à le remplacer, mais simplement à en synthétiser des points importants vous permettant de répondre à une grande partie des critères. De nombreuses exceptions / cas spécifiques existent, et vous devez donc consulter le référentiel pour aller plus loin.

1. Images

On dit souvent qu’une image vaut mille mots, mais pour vos utilisateurs utilisant un lecteur d’écran, c’est en général l’inverse ! Il est donc important d’offrir le même niveau d’information à ceux-ci qu’à vos utilisateurs n’ayant pas de handicap visuel.

Le RGAA demande que toutes les images porteuses d’information disposent d’une alternative textuelle pertinente. Bien souvent sur notre site, les images présentes le sont à titre illustratif. Cela signifie que le contenu textuel de la page transmet déjà toute l’information que nous souhaitons. Dans ces cas-là, l’attribut alt de l’image doit être présent mais vide. Il s’agit d’un point souvent non respecté du RGAA. Nombreux sont les sites qui remplissent systématiquement l’attribut alt, et nous en avions également abusé.

Dans les faits, il doit être rempli lorsqu’il donne une information complémentaire au texte ou bien s’il n’y a tout simplement pas de texte associé. Quelques exemples :

• Un schéma :  ce dernier est forcément explicite et graphique pour l’utilisateur voyant, mais il faut le décrire précisément pour que l’utilisateur en situation de handicap parvienne à se représenter le schéma à partir de sa description.
• Un bouton constitué uniquement d’une image, d’une icône. En l’absence d’un label clair, il faut bien sûr préciser l’alternative textuelle à l’image pour que le lecteur d’écran la retranscrive et que l’interaction soit comprise.
• Une image comportant du texte important : par exemple, sur de nombreux sites e-commerce, le texte est directement écrit dans les bannières. En l’absence d’alternative textuelle, impossible de connaître la fantastique promo en cours ou la dernière nouveauté présentée sur la bannière !

Autre point que nous avons corrigé, sur notre blog, la présence de légendes d’images. Si vous devez, comme nous, citer parfois les sources ou les copyrights d’un visuel, vous devez dès lors encapsuler votre image et légende dans une balise <figure> de cette façon : 

2. Cadres

Cette rubrique du référentiel contient seulement deux critères et ne concerne pas forcément tous les sites web. On y parle effectivement d’iframe, un élément HTML qu’on cherche en général à éviter mais qui sert néanmoins pour l’intégration de vidéos, de podcasts ou de posts issus de réseaux sociaux…

Pour être en conformité avec le RGAA, il suffit de donner un titre explicite à ces iframes.
Vous devez donc tout simplement définir l’attribut “title” en décrivant de manière synthétique le contenu de l’iframe.

3. Couleurs

Tout le monde n’a pas la même perception des couleurs et trois critères du RGAA sont là pour s’assurer que votre site soit compréhensible et lisible par tous. On retrouve deux grandes lignes directrices :

• Offrir des contrastes suffisants entre le texte / les éléments interactifs et le fond. Pour les textes inférieurs à 24px, il faut un rapport de contraste minimum de 4,5:1. Pour les textes supérieurs à 24px en regular ou à 18,5px en bold, il faut un contraste minimum de 3:1. Ces valeurs permettent d’offrir une bonne lisibilité des textes. Il est possible, pour des raisons artistiques, que vous désiriez tout de même ne pas respecter ces rapports de contraste. Dans ce cas vous devez impérativement proposer un module permettant de modifier l’apparence du site ou de la page de manière à afficher les contenus avec un ratio de contraste suffisant.
• Ne pas donner une information uniquement via la couleur. Cela signifie que si vous avez mis en avant une information importante d’un texte via une couleur, vous devriez aussi la mettre en gras ou lui ajouter une icône par exemple. Ainsi tous vos utilisateurs verront sa mise en avant. Il en va de même pour les liens : si ceux-ci sont simplement du texte en couleur, il serait également bon de les souligner ou d’y accoler une icône, pour les faire ressortir aux yeux de tous vos utilisateurs.

Sur notre site, nous avons du revoir quelques contrastes textes / fonds mais également ajouter une icône “erreur” aux messages d’erreur. Ceux-ci n’étaient en effet mis en avant que par la couleur rouge, ce qui est insuffisant pour être en conformité avec le RGAA.

Le site Contrast Checker de l’association WebAim est idéal pour connaître la conformité de vos contrastes de textes en fonction de leur taille.

4. Multimédia

Si la mise en place d’alternatives textuelles pour vos images porteuses d’informations peut prendre du temps, le faire pour des médias vidéo et audio est encore plus chronophage ! Néanmoins, c’est une obligation si vous souhaitez créer un site web accessible et ne laisser aucun utilisateur de côté.

Dans les grandes lignes, le Référentiel général d’amélioration de l’accessibilité vous propose plusieurs types d’alternatives en fonction des médias proposés.

• Pour les médias temporels de type audio, vous devez proposer une transcription textuelle.
• Pour les médias temporels de type vidéo, vous devez proposer, à minima, une transcription textuelle, ou une audio description, ou une alternative audio seulement. Vous devez aussi proposer des sous-titres synchronisés si la vidéo contient des dialogues.

Le plus important est que ces alternatives soient pertinentes. Bien que des logiciels de traduction automatique existent et s’améliorent rapidement grâce à l’IA, vous devrez probablement consacrer du temps à la relecture pour vous assurer du résultat final. 

À noter toutefois que vous n’êtes pas obligé de proposer des alternatives à des médias temporels utilisés à des fins décoratives ou bien si les médias sont eux-mêmes une alternative au contenu textuelle de la page visionnée.

Enfin, vous devez également porter la plus grande attention aux interactions avec les médias.
La navigation au clavier doit être possible. En plus des habituelles actions lecture, pause et stop, vos utilisateurs doivent pouvoir activer ou désactiver le son, l’audiodescription et les sous-titres. 

Sur notre site, les médias temporels sont peu nombreux. Toutefois si les contenus vidéo et/ou audio sont au coeur de votre projet, il va falloir réfléchir à un process efficace vous permettant de les rendre accessibles.

5. Tableaux

Évoquez les tableaux avec votre développeur front et vous êtes à peu près sûr de voir un rictus nerveux sur son visage ! Idéal pour mettre en forme des données (caractéristiques, comparatifs…) mais complexe à adapter sur mobile, les tableaux doivent eux aussi être accessibles.

Le référentiel demande avant tout un travail sémantique, et logique, sur vos tableaux. Il s’agit en réalité de bien associer les en-têtes aux cellules, de clairement indiquer le titre du tableau quand il existe mais également de résumer le tableau quand il est complexe.
Pour le RGAA, un tableau de données complexes est un tableau qui “contient des en-têtes qui ne sont pas répartis uniquement sur la première ligne et/ou la première colonne de la grille ou dont la portée n’est pas valable pour l’ensemble de la colonne ou de la ligne”. C’est dans ce cas précis que vous devez rédiger sa synthèse, soit dans l’élément <caption>, soit dans l’attribut “summary”, soit ailleurs dans votre page, auquel cas vous devez lier ce texte au tableau via l’attribut “aria-describedby”.

Attention toutefois, ces critères ne s’appliquent pas aux tableaux de mise en forme. C'est-à-dire des tableaux sans en-têtes servant à des fins de mise en page uniquement. Ces tableaux ne doivent avoir ni sommaire, ni caption, ni balises <thead>, <th> et <tfoot>. Puisque leur seul utilité est de présenter des informations sous une forme visuelle de tableau, vous devez ajouter sur votre balise <table>, l’attribut role="presentation”.

Sur notre site web, nous avons dû mettre aux normes quelques tableaux en indiquant plus précisément le scope des en-têtes. Nous avons des en-têtes de colonnes ou de lignes qui sont dans des éléments <th> et nous avons dû préciser leur scope en ajoutant scope="row” ou scope="col”. Cela permet d’indiquer clairement que l’en-tête concerne bien l’intégralité de la ligne ou de la colonne sur laquelle il se trouve.

Sur certains tableaux, nous avons également ajouté une balise <caption> pour bien définir le titre.

6. Liens

Concernant les liens, le RGAA demande que leur intitulé (également appelé “nom accessible”) soit explicite. Cela relève simplement du bon sens.

Ce nom accessible est obtenu selon l’ordre suivant :

• passage de texte associé par l’attribut WAI-ARIA aria-labelledby ;
• sinon, contenu de l’attribut WAI-ARIA aria-label ;
• sinon, contenu du lien ;
• sinon, contenu de l’attribut title.

Dans le cas d’un texte, si le contenu du lien est déjà explicite, vous êtes en conformité. Dans le cas d’un lien image, si un attribut “alt” explicite est renseigné, vous êtes en conformité. Si votre lien contient à la fois du texte et une image, le contenu textuel et/ou l’alternative textuelle de l’image doivent être suffisamment explicites.

Dans tous les cas où le contenu du lien n’est pas explicite, vous devez recourir à l’une des options listées ci-dessus pour créer un nom qui soit accessible. 

Quand un lien s’ouvre dans un nouvel onglet, il est pertinent de le préciser. Nous avons d’ailleurs ajouté un pictogramme symbolisant un lien sortant juste après chacun des liens de notre site ayant l’attribut target=”_blank”.

Globalement sur notre site web, nous avons ajouté des attributs “aria-label” à plusieurs endroits. D’abord quand le texte des liens n’était pas suffisamment explicite mais aussi, bien sûr, en l’absence de contenu textuel. Par exemple nous avons dans notre footer des liens vers nos réseaux sociaux prenant simplement la forme d’une icône. Pour le lien vers notre page Facebook, nous avons ajouté l’attribut “aria-label” suivant : Accéder à notre page Facebook (nouvelle fenêtre).

7. Scripts

Voilà une partie un peu plus technique puisqu’on parle de scripts. Concrètement le Référentiel général d’amélioration de l’accessibilité vous demande de rendre vos scripts accessibles ou bien de proposer des alternatives, en général via la balise <noscript>.

L’idéal c’est que “le nom, le rôle, la valeur, le paramétrage et les changements d’états” soient accessibles aux technologies d’assistance. Derrière cette phrase, il faut comprendre que vos composants interactifs doivent, en règle générale, posséder :

• un nom accessible clair (ex : “Déployer les informations de contact”)
• un rôle attribué (ex : qu’un bouton soit une balise <button> ou un élément HTML ayant l’attribut WAI-ARIA role="button")
• un ou des paramètres transmis aux API d’accessibilité (ex : un attribut arial-controls=”id-de-ma-section”)
• des changements d’état transmis aux API d’accessibilité (ex : un attribut aria-expanded ou attribut aria-hidden passant de false à true après une interaction de l’utilisateur)

Pour que vos scripts soient pleinement accessibles, il faut aussi que vos composants d’interface soient utilisables via le clavier. C’est-à-dire qu’en naviguant au clavier (touche Tab), vous devez pouvoir atteindre ces composants et les activer/désactiver (via la touche Entrée).

D’une manière générale, pour répondre aux critères du RGAA, testez systématiquement que la navigation au clavier est cohérente et appliquez des styles visuels différents au focus d’un élément, afin que l’utilisateur ait un feedback clair.

Un dernier critère lié aux scripts est la cohérence des messages de statut. L’attribut “role” va vous aider à catégoriser correctement les messages que vous affichez à l’utilisateur lors d’un événement (action utilisateur, changement d’état…). Les valeurs “status”, “alert” ou encore “progressbar” peuvent par exemple être utilisées lors de la soumission d’un formulaire.
D’abord pour indiquer à l’utilisateur que les données sont en cours de transmission puis ensuite pour lui confirmer la réussite ou l’échec de l’opération (si le formulaire comprenait des erreurs).

Sans surprise, plus votre site comporte de scripts et d’interactions complexes, plus vous aurez de travail pour être en conformité avec le RGAA. Sur notre site, nous avons ajouté quelques attributs WAI-ARIA manquants et nous avons revu quelques focus, pour les rendre plus visibles.

Et c’est terminé pour cette première partie de notre guide sur la mise en conformité RGAA de son site web. Nous avons déjà parcouru 42 critères mais bien d’autres sont à respecter.

Rendez-vous prochainement pour découvrir la seconde et dernière partie !