Qu’est-ce que l’accessibilité numérique & RGAA ?

Écrit par Victor Darras

J’ai vu le web — un outil pour une niche de passionnés et d’experts — devenir l’un des médias les plus indispensables et utilisé de notre époque. 

Cependant, le développement des nouvelles technologies informatiques a été d’une telle rapidité qu’elle s’est parfois faite au détriment de certains publics. Il en ressort également plusieurs problématiques dont la principale, à savoir :  

L’accessibilité numérique, en particulier sur le Web. 

Le RGAA est le meilleur outil que nous ayons en France autour de ce sujet. Nous ferons d’abord le tour des intérêts et contraintes de cette fameuse réglementation, puis nous verrons une partie plus orientée pratique / technique sur : 

• Comment faire une étude rapide ou complète d’un site web ? 
• Comment appliquer le tout ou une partie des corrections nécessaires à la complète accessibilité d’un site web ? 

Préambule 

RGAA : (Référentiel Général d’Amélioration de l’Accessibilité), est un ensemble de règles à appliquer pendant la conception puis le développement d’un site ou d’une application web, mais aussi d’application mobile ou de documents numériques (un PDF, un fichier Word, etc…). Je me concentrerais aujourd’hui sur le web; 

Ce référentiel a été créé et mis à jour par la DINUM (Direction Interministérielle Du Numérique) avec qui nous avons déjà eu l’occasion de travailler sur certains projets. Nous avons également collaboré avec l’Arcom (Autorité de Régulation de la Communication Audiovisuelle et Numérique), fusion de l’Hadopi et du CSA. Depuis 2023, ils contrôlent tout ce qui concerne l’accessibilité numérique en France : C’est donc l’institution qui enregistre, régule et sanctionne les cas de non-conformité d’un site ayant obligation légale de respecter le RGAA. 

Qu’est-ce que l’accessibilité Web ? 

L’accessibilité numérique consiste à rendre les contenus et services numériques compréhensibles et utilisables par le plus grand nombre, y compris par les personnes en situation de handicap ou ayant des troubles mentaux. Aujourd’hui on estime à environ 15% la population en situation de handicap. Cependant, un site doit particulièrement être accessible pour tous types de publics. 

• Troubles de la surdité :  personnes sourdes ou malentendantes 
• Troubles visuels : personnes aveugles ou malvoyantes 
• Déficience cognitive ou maladie psychologique 
• Déficience moteur 

En quelques exemples, un site accessible doit l’être dans ces quelques cas : 

• Une personne déficiente visuelle, qui zoom avec la loupe de son système d’exploitation, ou qui mets constamment son navigateur à 200% de zoom; 
• Une personne qui parcourt votre site avec un lecteur d’écran; 

• Une personne qui ne peut interagir qu’avec un clavier, ou un dispositif équivalent. 

Nous pouvons aussi inclure d’autres catégories d’utilisateurs, comme ceux dont l’écran n’est pas totalement fonctionnel, et/ou dans un environnement trop bruyant/trop ou peu lumineux, ou même des individus peu expérimentés en informatique comme les enfants ou les personnes âgées. 

Le site de l’Inria met en évidence quelques exemples de difficultés que des visiteurs peuvent rencontrer. 

Combien ça coûte ? 

Un argument que j’entends tous les jours depuis que je travaille sur ce domaine en particulier : “Oui, mais ça va nous coûter cher !”. Il est communément admis que rendre un site accessible demande du temps et des développeurs qualifiés mais j’estime que c’est une erreur de voir ça comme un coût supplémentaire. 

C’est d’abord s’ouvrir à un public plus large et des communautés engagées autour du numérique qui ne manqueront pas de faire parler de votre plateforme; J’ai en tête notamment un site de retail qui a particulièrement explosé pendant la crise du COVID car il était le seul accessible avec un lecteur d’écran pour faire ses courses en ligne dans une période où il était particulièrement difficile de sortir de chez soi. 

Si vous êtes une ESN comme Ouidou, c’est aussi un atout pour vos équipes de développement, qui ne manqueront pas d’apprécier travailler avec des méthodes et des standards de développements éprouvés et robustes. De plus,  ils auront le sentiment de participer à des projets un peu plus à taille humaine, chose  qui peut parfois manquer dans le monde du numérique. 

Faire les réparations nécessaires sur des systèmes complexes avec une grosse inertie coûtera plus cher que d’avoir pris en compte toutes les contraintes d’accessibilité dès le début de conception du site. C’est donc évidemment un sujet à prendre en considération/ en compte dès l’initiation d’un projet. 

À quoi ressemble ce fameux RGAA ?

C’est un site complet (disponible à cette adresse : https://accessibilite.numerique.gouv.fr/), qui décrit les principes mêmes de l’accessibilité numérique, ainsi qu’un ensemble de critères plus ou moins techniques classés par types, comme nous le verrons par la suite. Il est basé sur le WCAG niveau AA qui est la référence internationale (crée par le W3C) sur le sujet. 

Son champ d’application 

Les sites et clients potentiellement soumis par une obligation de conformité sont nombreux, et parfois plus qu’on ne pourrait le penser. Cela concerne l’ensemble des sites du gouvernement, des collectivités plus ou moins locales, mais aussi d’entreprises privées avec une mission publique ou simplement certaines entreprises à compter d’un seuil de chiffre d’affaires de 250 millions d’euros. 

Chez Ouidou, nous avons beaucoup de clients et partenaires concernés : l’ONF, TE44, Arcom, l’ensemble des projets que nous construisons avec la DINUM, etc… 

Déclaration d’accessibilité, mentions obligatoires, etc… 

A partir du moment où nous nous préoccupons de l’accessibilité (pour des raisons légales ou non), il est nécessaire de présenter les efforts fournis dans ce sens sur une page dédiée. Cette déclaration d’accessibilité obligatoire présente les moyens mis en place afin d’y parvenir, les différents outils utilisés, le pourcentage de respect du RGAA observé lors d’un audit ainsi que l’ensemble des acteurs ayant contribué à la mise en place ou la correction des critères d’accessibilité du RGAA. Elle doit être accompagné du schéma pluriannuel présentant la continuité du plan d’amélioration d’accessibilité sur 3 ans. Enfin, elle doit être accessible depuis la page d’accueil du site. 

Comment se déroule un audit ? 

Ensemble représentatif de pages 

La première étape d’un audit consiste à sélectionner les pages représentatives de l’ensemble du site audité. Pour exemple, peuvent être concernées : la page d’accueil, la page de contact, les pages présentes depuis la navigation principale, ainsi que les pages de mentions légales etc… 

Dans certains cas, prenons l’exemple d’un blog, nous aurions potentiellement des centaines de pages à auditer : une pour chaque article. Dans ce cas, nous pourrions prendre le parti de n’en choisir qu’une ou deux qui soit — encore une fois — représentative de la complexité d’une page d’article en moyenne. 

Une démarche rigoureuse 

Ensuite, vient le cœur de l’audit où il faudra parcourir 13 familles thématiques, lesquelles contiennent chacune des critères très précis qu’il convient de vérifier un à un. Nous allons voir ensemble toutes ces familles, avec à chaque fois un exemple concret de critère à vérifier. 

Pour chaque critère il faudra donc trouver le meilleur moyen d’inspecter le site. Que ce soit avec les outils de développement d’un navigateur, avec un lecteur d’écran ou même des extensions navigateurs dédiées. 

Des outils d’analyse 

Au-delà de la démarche pour faire l’analyse, il existe quelques outils qui nous permettent de le faire plus rapidement et plus facilement. Voyons-en quelques-uns ensemble. 

Google Lighthouse 

Intégré dans Chrome, il permet de faire un tour d’horizon des différents aspects plutôt visuels, utilisation des tags de structuration HTML, ordre des tabulations, respect d’un certain niveau de contraste, etc… Au-delà des retours plutôt clairs qu’il nous donne, il permet aussi d’avoir un score global, et par extension de pouvoir travailler à l’amélioration de ce score. 

Tanaguru 

Disponible notamment sous forme d’extension navigateur, Tanaguru est un projet open-source qui est spécialisé dans la vérification du RGAA. Il affichera donc des erreurs rangées dans les mêmes familles critères dont nous avons parlé. 

NVDA 

Plus qu’un outil d’audit, NVDA est surtout l’un des leaders sur le marché des lecteurs d’écran auprès de VoiceOver (Apple) ou JAWS (plutôt orienté Microsoft). Logiciel open-source, il est gratuit et plus facile à utiliser que JAWS. Nous nous en servons donc pour avoir un aperçu d’une expérience exclusivement sonore du web. 

Les critères du RGAA 

Prenons ensemble le temps de parcourir quelques exemples de critères : 

1. Images 

Chaque image de décoration est-elle correctement ignorée par les technologies d’assistance ? 

Toute image qui ne sert que de décoration doit être ignorée. On parle ici d’images de background, de motifs ou encore d’icônes qui viennent ajouter du contexte sans être indispensables à la compréhension de l’information. Pour s’assurer qu’elles sont bien ignorées nous ajouterons un attribut alt=”” (sans valeur donc) à ces images. 

2. Cadres 

Pour chaque cadre ayant un titre de cadre, ce titre de cadre est-il pertinent ? 

Un cadre est en réalité une iframe, comme pour les images ou les multimédias, il faut leur porter une attention particulière puisque leur contenu ne dépend souvent pas de notre codebase. On s’assurera que l’iframe a bien un attribut title=”Nom de l’iframe” avec une valeur explicite. 

3. Couleurs 

Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ? 

Prenons une liste de filtres affichés en tags, celui qui est sélectionné ayant un fond un peu plus sombre. L’objectif sur ce point est d’ajouter un détail plus explicite, par exemple une coche à côté du tag concerné. 

4. Multimédia 

Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ces sous-titres sont-ils pertinents ? 

Qu’est-ce qu’un média temporel ? C’est un son, une vidéo, un diaporama dont le contenu évolue avec le temps. Dans ce cas, il est nécessaire que l’on s’assure que les sous-titres soient pertinents, dans le fond comme dans la forme (lisibles, compréhensibles en fonction du public). 

5. Tableaux 

Pour chaque tableau de données, chaque en-tête de colonne et chaque en-tête de ligne sont-ils correctement déclarés ? 

La structure d’un tableau html est parfois complexe. Pour aider les outils de lecture d’écran, nous nous assurerons que ces entêtes soient bien des, ou aient un aria role=”columnheader”. Il en est de même pour les lignes (row). 

6. Liens 

Dans chaque page web, chaque lien a-t-il un intitulé ? 

Il arrive parfois que les tags présents dans vos pages ne contiennent pas d’intitulé. Par exemple dans le cas où le contenu du lien est une image qui n’a pas de ALT. 

7. Scripts 

Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ? 

Chaque message de statut qui indique la progression d’un processus (par exemple dans un formulaire en plusieurs étapes) doit utiliser l’un des attributs WAI-ARIA role=”log”, role=”progressbar” ou role=”status”. 

8. Éléments obligatoires 

Pour chaque page web ayant un titre de page, ce titre est-il pertinent ? 

Il n’est pas rare sur un site que l’ensemble des titres de chaque page soient identiques. Dans ce cas, il ne donne aucune indication pertinente à l’utilisateur. 

Plutôt que d’avoir toutes les pages nommées “Site Ouidou – Developpement web” nous préférons des titres comme : 

• Accessibilité Numérique – Ouidou 
• Blog Technique – Ouidou 
• Accueil – Ouidou 

9. Structuration de l’information 

Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ? 

Dans chaque page web, chaque liste est-elle correctement structurée ? 

Afin d’aider les outils de lecture d’écran, il est primordial de structurer le HTML de nos pages avec des tags spécifiques. Pour les titres il faudra utiliser correctement un h1 puis un ou plusieurs h2, h3, h4, etc… Ces derniers permettent au lecteur de résumer les informations de la page en section logique dont chaque sujet est présent dans le titre. 

De la même manière, il faudra être attentif à chaque liste. Si elle est bien déclarée avec

ou
• puis avec des
  1. , un screenreader aura la capacité de donner le nombre d’objets, où en est le lecteur dans le parcours, l’item suivant, etc… 

10. Présentation de l’information 

Dans chaque page web, le contenu visible porteur d’information reste-t-il présent lorsque les feuilles de styles sont désactivées ? 

il est parfois difficile de se projeter sur ce point en particulier en étant voyant. Ce dernierl s’assure surtout de cas particulier tel que : 

• Une image de background (affichée en CSS) qui affiche un contenu porteur d’informations. 
• Un pseudo-élément créé en CSS qui portait lui aussi une information. 

11. Formulaires 

Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ? 

C’est assez simple, mais on ne le dit jamais assez, les labels et inputs doivent être proches visuellement, sans toutefois porter à confusion ! 

12. Navigation 

Dans chaque ensemble de pages, le moteur de recherche est-il atteignable de manière identique ? 

Il peut arriver qu’un même élément d’interface ne se trouve pas deux fois au même endroit sur plusieurs pages. Dans le cas du moteur de recherche global au site, il est indispensable qu’on le trouve à un endroit prévisible (visuellement, mais aussi en terme de structure de document pour les lecteurs d’écran) 

13. Consultation 

Dans chaque page web, le contenu proposé est-il consultable quelle que soit l’orientation de l’écran (portrait ou paysage) (hors cas particuliers) ? 

Version un peu minimaliste d’une vision responsive de la page, il faut au moins s’assurer qu’elle soit lisible dans tous les sens de lecture de la plupart des terminaux. 

En conclusion, après vous avoir fait le tour d’horizon des différentes familles de critères, je vous invite également à parcourir l’ensemble de la documentation.

Des résultats à prendre avec des pincettes 

Même si certains points peuvent être sujets à interprétation, il faut viser le plus généraliste possible. Je conseillerais d’être toujours le plus exigeant possible quant à l’application d’un critère. Dans l’idéal, plusieurs audits peuvent être produits afin d’éviter toute confusions.  

Même si beaucoup de tests peuvent être effectués avec un navigateur et quelques outils basiques de développement web, la plupart doivent être testés avec un lecteur d’écran pour se rendre compte de l’expérience réelle de l’utilisateur. Dans l’objectif qu’un résultat soit valide légalement, il doit être réalisé par un organisme ou un expert certifié. 

C’est comme un contrôle technique, en fait ? 

En guise de conclusion, j’aimerais faire un parallèle entre un audit RGAA et le contrôle technique d’une voiture. D’une part, il devient obligatoire pour un nombre croissant de sites et permet de prévenir tout un ensemble de problèmes ou bugs futurs. D’autre part, il force les développeurs à prendre du recul sur la conception du site et à se poser la question de l’usage plus que de l’aspect technique. C’est aussi l’occasion de se projeter sur des comportements parfois inattendus ou peu utilisés et permet avec un peu de coordination de limiter les coûts de refonte ou de correction de tel ou tel critère. 

Enfin, et j’aimerais terminer là-dessus, n’oublions pas que l’amélioration de l’accessibilité est une mission d’utilité publique. Chaque personne devrait avoir les mêmes droits d’accès à l’information, à un travail ou à n’importe quel service. Le RGAA est le guide pour atteindre cet objectif dans le monde du numérique qui est le nôtre. 

Pour aller plus loin

Pour en savoir plus sur l’accessibilité numérique et découvrir comment Ouidou accompagne la mise en conformité de vos projets web, visitez notre page dédiée. Pour un cas concret d'accessibilité numérique, découvrez notre projet Banque de France sur notre site web.