Norme EN 301 549 et RGAA 4 : quelles différences dans les exigences techniques de la conformité ?

Depuis la transposition de la directive européenne 2106/2102 et le décret 2019-768 du 24 juillet 2019, la conformité est évaluée au regard de deux axes :

• l’évaluation du respect des exigences techniques (référentiel technique du RGAA ou norme européenne) ;
• l’évaluation des exigences de publication (déclaration d’accessibilité, moyen de contact, niveau d’accessibilité, schéma pluriannuel).

C’est le respect de l’ensemble de ces exigences qui permet d’évaluer si, oui ou non, un organisme respecte les obligations légales d’accessibilité numérique.

Dans cet article, nous nous attachons exclusivement à comparer le périmètre technique de l’évaluation du RGAA 4 et celui de la norme EN 301 549.

La norme européenne d’accessibilité numérique et l’évaluation des sites web

La norme européenne d’accessibilité numérique est construite en 10 sections de règles :

• Section 4 : Performances fonctionnelles
• Section 5 : Exigences génériques
• Section 6 : TIC (Technologie de l’Information et de la Communication) avec communication bidirectionnelle
• Section 7 : TIC avec capacités vidéo
• Section 8 : Matériel
• Section 9 : Web (note : cette section recopie la version des WCAG en cours, actuellement WCAG 2.1)
• Section 10 : Documents non-web (note : il s’agit par exemple des documents bureautiques PDF, fichier Word ou ODT, etc.)
• Section 11 : Logiciel
• Section 12 : Documentation et services d’assistance
• Section 13 : TIC offrant un service de relais ou d’urgence

Ces sections ne s’appliquent pas de manière exclusive à un seul type d’interface : elles définissent des critères qui peuvent s’appliquer, ou non, en fonction de l’interface (web, application mobile, logiciel, système d’exploitation, etc.).

Ce sont les annexes A et B qui listent les critères devant être pris en compte en fonction de l’interface évaluée.

Ainsi, le tableau A.1 (p. 90) nous donne le détail des exigences applicables pour les interfaces web, qui nous intéressent ici particulièrement. On découvre qu’en plus des sections 9 (qui correspond aux WCAG 2.1 actuellement) et 10 (pour les documents bureautiques), des critères issus des sections 5, 6, 7, 11 et 12 doivent également être pris en compte dans l’évaluation de la conformité pour répondre aux exigences européennes.

Nous allons donc nous attacher à lister de manière succincte des sections et critères de la norme qui s’appliquent aux interfaces web, en identifiant quelles exigences sont déjà présentes dans le RGAA et lesquelles ne le sont pas encore.

Nous écartons donc volontairement les sections 9 et 10, puisqu’elles sont déjà prises en charge par le RGAA.

Avertissement : cet inventaire est donné à titre d’illustration des différences qui existent entre le référentiel technique du RGAA et la norme européenne. Il n’est ni exhaustif, ni détaillé.

Section 5 : Exigences génériques

Pour les interfaces web, ce sont uniquement les critères 5.2, 5.3 et 5.4 qui s’appliquent.

5.2 : Activation des fonctionnalités d’accessibilité

Il s’agit ici de s’assurer que, si un dispositif d’accessibilité existe dans l’interface — tel un mécanisme d’amélioration des contrastes de couleur, par exemple, ce mécanisme doit pouvoir être activé, et donc perçu, sans avoir recours à l’activation du dispositif lui-même.

Ce critère existe déjà en partie dans le RGAA 4 avec les tests 3.2.5 et 3.3.4, qui exigent que le mécanisme de remplacement permettant de basculer vers un affichage assez contrasté d’une page soit lui-même assez contrasté avant sa propre activation.

Mais, dans la norme EN 301 549, ce principe doit s’appliquer de manière plus générique à tous les besoins utilisateurs, pas uniquement à la modification des couleurs.

Par exemple, si un composant d’interface permet d’augmenter la taille de la police (ce qui permet de respecter le critère 10.4 du RGAA 4), alors le texte qu’il contient doit être affiché par défaut avec une taille de police équivalent à 200 % de la taille de police initiale, pour permettre aux personnes malvoyantes de le percevoir avant même qu’elles n’adaptent la taille du texte au moyen de ce composant.

5.3 Propriétés biométriques

Ce critère cadre l’utilisation des capteurs biométriques pour l’identification des utilisateurs ou le déclenchement d’une fonctionnalité.

Cette exigence n’existe pas actuellement dans le RGAA.

Il est nécessaire de s’assurer qu’il existe toujours une alternative à la détection biométrique (reconnaissance vocale ou empreinte digitale pour saisir un mot de passe, par exemple) et qu’elle ne repose pas sur une caractéristique physique, ou bien qu’elle repose sur une caractéristique physique suffisamment différente de la caractéristique initiale.

Par exemple, certaines applications web permettent de choisir un mode de connexion biométrique après la première connexion. L’utilisateur peut dès alors choisir de se connecter par reconnaissance vocale ou par reconnaissance d’empreinte digitale (par exemple grâce aux systèmes Touch ID sur certains produits Apple, ou Windows Hello sur des ordinateurs de bureau) ^[2].

Dans ces cas-là, il sera essentiel de s’assurer que, bien que l’utilisateur ait choisi un mode de connexion biométrique, il lui est toujours proposé une alternative comme la saisie d’un mot de passe.

En effet, les caractéristiques physiques sollicitées par ces systèmes d’identification peuvent être soumises à des variations dans le temps, par exemple à la suite d’un accident, d’une dégénérescence ou encore des variations inhérentes à une maladie. Or, ces variations ne doivent bloquer personne : d’où l’importance d’une méthode pour s’identifier autrement.

5.4 Conservation des informations d’accessibilité pendant un processus de conversion

Le critère 5.4 veille à ce que, pour chaque fonctionnalité dont la finalité est de convertir une information, les informations d’accessibilité (sémantique, alternative d’images, sous-titres par exemple) soient préservées dans le résultat de cette conversion, si le format de destination possède les paramètres pour recevoir ces informations.

Cette exigence n’existe pas actuellement dans le RGAA.

Par exemple, si un outil en ligne propose de convertir un fichier PDF en fichier Word, le fichier Word généré doit disposer des mêmes informations que le PDF source.

Ainsi, si les images possèdent une alternative textuelle dans le PDF, alors les images reprises dans le fichier Word doivent posséder elles aussi une alternative.

Section 6 : TIC avec communication bidirectionnelle

Cette section s’applique spécifiquement aux interfaces de communication synchrone en ligne, comme les systèmes de conférence (Zoom, Microsoft Teams, Jitsi ^[3], Google Meet, etc.).

Aucun des critères n’est actuellement pris en charge dans le RGAA.

La majorité des critères décrit les alternatives essentielles pour que les personnes sourdes ou malentendantes puissent participer aux communications orales au moyen de ces systèmes de communication en ligne.

Une autre partie des critères cadre les alternatives aux informations visuelles pour les personnes aveugles.

Ces critères contrôlent :

• des éléments techniques comme la qualité d’encodage et décodage du son émis et reçu (6.1) ;
• la présence d’une fonctionnalité de communication en texte en temps réel (Real-time text ^[4]) comme moyen alternatif à la communication orale (6.2.1.1), répondant à un ensemble d’obligation fonctionnelle et d’affichage (6.2.1.2, critères de la section 6.2.2), à des délais de transmission (6.2.4) et à des règles d’interopérabilité avec les protocoles de télécommunication (6.2.3) ;
• la disponibilité d’alternatives visuelles pour toutes les informations audio (6.3, 6.5.5) et pour les fonctionnalités reposant exclusivement sur de l’information audio comme un répondeur (6.4, 6.5.6) ;
• un ensemble de propriétés techniques permettant de s’assurer de la transmission correcte des informations vidéo et de la synchronisation avec l’audio (6.5.2, 6.5.3, 6.5.4).

Section 7 : TIC avec capacités vidéo

Cette section cadre des obligations spécifiques aux composants qui permettent la manipulation de contenu vidéo : lecture, édition, conversion, enregistrement.

Elle s’applique donc autant aux lecteurs vidéo (par exemple un lecteur vidéo embarqué dans un site web) qu’aux applications d’édition vidéo.

La grande majorité de ces critères n’est actuellement pas prise en charge par le RGAA. Or, ces exigences devraient enrichir la thématique Multimédia du RGAA.

Les critères de cette section s’intéressent tout d’abord aux différents aspects des sous-titres en contrôlant :

• la présence sur le lecteur d’une fonctionnalité pour activer les sous-titres si une piste des sous-titres est présente (7.1.1), ainsi qu’une bonne synchronisation des sous-titres avec la vidéo (7.1.2) : ces exigences existent déjà dans le RGAA 4 (critères 4.4 et 4.11 du RGAA 4) ;
• la préservation des caractéristiques des sous-titres (diffusion, couleur, taille, etc.) dans tout processus de manipulation comme l’édition ou la conversion (7.1.3) ;
• la possibilité d’adapter la présentation des sous-titres, par exemple changer la couleur et la taille de la police (7.1.4) ;
• la possibilité d’accéder à des sous-titres vocalisés (7.1.5).

Il existe un cas particulier pour les sous-titres incrustés (open captions), qui ne sont pas concernés par ces critères.

Par ailleurs, une autre section, dédiée à l’audiodescription, contrôle quant à elle :

• la présence sur le lecteur d’une fonctionnalité pour activer l’audiodescription si une telle piste est présente (7.2.1). Cette exigence existe déjà dans le RGAA 4 (critère 4.5 du RGAA 4) ;
• la bonne synchronisation de l’audiodescription (7.2.2) ;
• la préservation des caractéristiques de l’audiodescription dans tout processus de manipulation comme l’édition ou la conversion (7.2.3).

Enfin, pour les contrôles permettant d’activer les sous-titres et l’audiodescription, ils doivent être disponibles au même niveau que les autres contrôles standards (lecture, volume par exemple) : cela signifie qu’il doit y avoir autant de manipulations nécessaires pour atteindre un contrôle standard que pour atteindre un contrôle de sous-titres ou d’activation d’audiodescription (7.3).

Par exemple, si le bouton de lecture est disponible depuis le lecteur vidéo sans devoir activer au préalable un autre composant, alors le composant des sous-titres doit être disponible depuis le lecteur sans avoir à activer un autre composant.

Section 11 : Logiciel

La section 11 contient des critères dont l’application est très diversifiée. S’y trouvent des critères liés à l’évaluation des outils d’édition (comme les CMS, Content Management Systems), des logiciels (clients lourds) ou encore des systèmes d’exploitation eux-mêmes.

Concernant les interfaces web, seules les sous-sections 11.7 et 11.8 sont applicables.

Aucun de ces critères n’est actuellement pris en charge dans le RGAA.

11.7 : Paramètres utilisateurs

Un premier critère contrôle que l’interface web respecte les paramètres de présentation et d’interaction que l’utilisateur aurait définie au niveau du navigateur (11.7).

Ce critère faisant référence a priori exclusivement aux logiciels, l’application de ce critère sur un contenu web est encore difficile à appréhender, d’autant qu’il semble encore en cours de révision au sein du groupe de travail ayant en charge la norme elle-même.

11.8.2 à 11.8.5 : Outils d’édition

Une sous-section, s’inspirant très largement de la norme ATAG 2.0 ^[5], cadre les outils d’éditions.

Il est question ici de CMS tout comme de n’importe quelle interface d’édition web mise à disposition d’une utilisatrice pour créer ou modifier du contenu qui a vocation à être consulté par d’autres personnes : formulaire de saisie d’un message dans un forum, formulaire de dépôt d’une annonce sur un site de vente (retrouvez la définition d’outils d’édition dans la norme ATAG 2.0 pour plus de détails).

Cette section contrôle notamment :

• la capacité de l’outil à créer du contenu accessible et à guider la création de contenu accessible (11.8.2). Par exemple, si l’outil d’édition permet d’insérer une image dans un contenu, alors il offre également à l’utilisatrice une méthode qui permet soit de renseigner une alternative, soit de déclarer l’image comme décorative ;
• la préservation des propriétés d’accessibilité dans tous les processus de transformation (11.8.3). Par exemple, si l’éditeur de texte permet de définir des alternatives aux images porteuses d’information, alors à la suite de l’enregistrement du contenu et de sa publication sur une page web, les alternatives sont présentes dans le code généré ;
• la présence d’aides à la correction (11.8.4) : si l’outil d’édition propose une méthode pour évaluer l’accessibilité du contenu intégré par les éditeurs, alors il leur fournit des aides à la correction. Par exemple, prenons un éditeur de texte qui dispose d’une fonctionnalité permettant d’évaluer les intitulés de liens. Si des liens vides sont identifiés, alors des solutions sont proposées à l’utilisatrice, comme l’ajout d’un texte, ou bien la définition d’une alternative à l’image contenue dans le lien ;
• la mise à disposition d’au moins un gabarit de publication accessible (11.8.5). Si l’outil propose des gabarits de publication par défaut, au moins un des gabarits doit être conforme aux sections 9 et 10, c’est-à-dire aux critères WCAG pour les contenus web et fichiers bureautiques en téléchargement.

Section 12 : Documentation et services d’assistance

12.1.1 et 12.1.2 : Documentation

Dans une première partie, cette section contrôle les supports de documentation de l’interface.

À noter : la section 12 ne s’applique que si une documentation est présente (page d’aide, tutoriel, etc.). Il n’y a donc pas d’obligation de fournir une documentation.

Dans ce cadre, la section 12 vérifie :

• l’accessibilité des éléments de documentation (12.1.2) : si un site dispose d’une documentation (par exemple un document PDF, ou bien un ensemble de pages web dédiées à cela), alors cette documentation devrait faire partie de l’échantillon à auditer ;
• la présence dans la documentation de description des fonctionnalités d’accessibilité disponibles dans le site et des informations liées à la compatibilité, par exemple avec les technologies d’assistance (12.1.1).

Cette problématique n’est pas prise en charge dans le RGAA actuellement, même si la documentation liée à la compatibilité à travers l’environnement de test décrit par le RGAA et les obligations de tests de restitution sur les composants complexes pourrait y répondre en partie

Néanmoins, le RGAA n’oblige pas à documenter les défauts de supports, mais uniquement à donner les détails techniques (nom et version) des outils utilisés pour réaliser ces tests.

Ces obligations pourraient être directement intégrées dans la section « Obligations légales » du RGAA plutôt que dans la méthode technique.

Notons qu’une déclaration d’accessibilité peut tout à fait être considérée comme un élément de documentation : ainsi, les obligations de documentation devraient toujours s’appliquer pour les sites web.

12.2.2 à 12.2.4 : Assistance

Dans une seconde partie, la section 12 définit les exigences qui incombent aux services d’assistance (c’est-à-dire de support) lorsqu’ils sont proposés par le site web.

Cette problématique n’est pas prise en charge dans le RGAA actuellement.

Les services d’assistance concernent par exemple les services d’aide en ligne (messagerie instantanée), les centres d’appel (hotline), les centres d’aide (service de ticketing en ligne), les services de formation, ou encore les services de relais.

Les critères de cette section vérifient notamment :

• la capacité du service d’assistance à renseigner les usagers sur les fonctionnalités d’accessibilité et la compatibilité du site web avec l’accessibilité (12.2.2) ;
• la capacité du service d’assistance à répondre aux besoins de communication des personnes handicapées directement, ou bien par l’intermédiaire d’un service de relais (12.2.3) ;
• l’accessibilité de la documentation fournie par le service d’assistance (12.2.4).

Néanmoins, pour les entités publiques françaises, l’article 78 de la loi de 2005 impose déjà des exigences spécifiques à l’accessibilité des centres d’appels :

« Les services d’accueil téléphonique destinés à recevoir les appels des usagers sont accessibles aux personnes sourdes, malentendantes, sourdaveugles et aphasiques par la mise à disposition d’un service de traduction simultanée écrite ».

Une partie des exigences devrait donc déjà être prise en charge par les entités publiques au moins.

Conclusion

Aujourd’hui, un site conforme au RGAA n’est pas forcément conforme aux exigences techniques de la norme européenne : ce faisant, il ne respecte donc pas les obligations techniques imposées par la directive européenne 2016/2102.

Néanmoins, pour une majorité de sites, cette différence dans les obligations a un impact marginal.

En effet, hormis les nouveaux critères concernant le multimédia et quelques exigences concernant la documentation, les autres critères relèvent de contextes très particuliers, comme les systèmes de visioconférence ou d’édition de contenu.

Or, ces contextes spécifiques ne concernent pas la grande majorité des sites web.

Cependant, la problématique est toute autre dès lors que l’interface web doit répondre des exigences beaucoup plus techniques des sections 6 (communication orale) et 11 (outils d’édition).

Si ces critères n’ont pas été pris en compte, l’impact sur la conformité et sur les correctifs à engager peut être très important.

La DINUM (Direction interministérielle du numérique), en charge du maintien du RGAA, devrait veiller à introduire l’ensemble de ces critères dans la prochaine évolution majeure du référentiel d’accessibilité numérique français.

Cette évolution devrait se faire en gardant de vue deux objectifs essentiels :

1. permettre l’évaluation de la conformité à la norme européenne ;
2. permettre la prise en main de ces nouveaux critères d’accessibilité numérique par les différentes parties prenantes d’un projet web : en effet, certains de ces nouveaux critères sont très particuliers, que ce soit sur un plan technique ou conceptuel.

À titre d’information, un certain nombre de ces critères a été transposé dans le Référentiel d’évaluation de l’accessibilité des applications mobiles (RAAM) édité par le Grand-Duché de Luxembourg avec l’aide d’Access42 ^[6] : n’hésitez pas à le consulter pour vous donner une idée un peu plus précise de ce que pourrait être leur application pratique pour les interfaces web dans le RGAA.