Évaluer l'accessibilité numérique avec le RAWeb

Cette thématique compte 9 critères pour s’assurer de l’accessibilité des images. Le RAWeb distingue les images porteuses d’information, qui doivent absolument bénéficier d’une alternative lisible et vocalisable par les technologies d’assistance, des images décoratives destinées à être ignorées.

Le RAWeb compte deux critères destinés à valider les cadres introduits par des balises <frame> ou <iframe>, qui se focalisent sur la présence d’un attribut title et la pertinence de son intitulé.

Cette information permet à l’utilisateur d’un lecteur d’écran de juger de l’intérêt d’un contenu pour charger le cas échéant le document dans un nouvel onglet ou une nouvelle fenêtre de son navigateur.

Les 3 critères de la thématique Couleurs du RAWeb portent sur les niveaux de contraste et l’absence d’information véhiculée uniquement par la couleur.

Des contrastes trop faibles compliquent ou empêchent en effet la lisibilité du contenu pour les internautes présentant une basse vision ou des troubles de la vision.

Une information véhiculée uniquement par la couleur serait quant à elle inaccessible aux utilisateurs avec une affection comme le daltonisme.

Le RAWeb compte 17 critères dédiés aux contenus multimédias, contre 13 critères pour le RGAA.

Les 13 critères communs ont pour vocation de s’assurer qu’une alternative existe afin de répondre aux différents déficits sensoriels :

• Une personne malvoyante doit bénéficier d’une audiodescription ou d’une transcription textuelle vocalisable par son lecteur d’écran ;
• Une personne malentendante doit quant à elle bénéficier de sous-titres ou d’une transcription textuelle facilement accessible.

Les 4 critères supplémentaires permettent de répondre complètement aux exigences de la norme EN 301 549. Ils s’intéressent plus particulièrement au contrôle des sous-titres et aux options autour des sous-titres de traduction.

Les 8 critères de cette thématique du RAWeb distinguent bien les deux grands types de tableaux :

1. Les tableaux de données, que l’on pourrait qualifier de « véritables tableaux » ;
2. Les tableaux de présentation, dont le seul objectif est la mise en forme du contenu.

Les tableaux de données doivent pouvoir être facilement compréhensibles par les utilisateurs de lecteurs d’écran, avec notamment :

• L’association correcte et la pertinence du titre (si le tableau en comporte un) ;
• La présence d’un résumé pour un tableau de données complexe ;
• La déclaration des cellules d’en-têtes de colonnes et de lignes ;
• L’association technique appropriée entre les cellules et leurs en-têtes (notamment pour les tableaux complexes).

Les tableaux de présentation :

• Doivent être déclarés tels quels par un role="presentation" ;
• Ne doivent pas utiliser certaines balises comme <caption>, <th>, <thead>, <tfoot> ou certains attributs comme role="rowheader", role="columnheader", scope, headers et axis.
• Doivent pouvoir être linéarisés, ce qui signifie que la lecture par une technologie d’assistance doit demeurer compréhensible.

Les deux critères de cette thématique se focalisent sur l’intitulé du lien :

• Tout lien doit avoir un intitulé ;
• Cet intitulé doit être pertinent, c’est-à-dire qu’on peut comprendre la fonction et la destination du lien (seul ou en tenant compte du contexte).

Les 5 critères de cette thématique sont particulièrement importants pour les auditeurs en accessibilité web.

Chaque script doit notamment :

• Posséder un nom, un rôle, une valeur, un paramétrage et des changements d’état accessibles aux technologies d’assistance ;
• Être contrôlable au clavier ou par tout autre dispositif de pointage ;
• Avertir l’utilisateur en cas de changement de contexte ;
• Prévoir des messages de statut correctement restitués par les technologies d’assistance ;
• Offrir le cas échéant une alternative accessible pertinente.

Derrière ces attentes simples à comprendre se cachent des contraintes techniques délicates à analyser.

Les 10 critères de cette catégorie du RAWeb listent les éléments à prévoir dans vos pages web pour répondre à vos impératifs d’accessibilité.

Vous devez notamment :

• Définir le type de document ;
• Générer un code source valide ;
• Utiliser un titre de page (balise <title>) pertinent ;
• Spécifier une langue par défaut, en utilisant un code de langue pertinent et valide (norme ISO 639-1 ou ISO 639-2 et suivantes) ;
• Préciser tout changement de langue au sein du document, pour permettre une bonne vocalisation ;
• Ne pas détourner de balises à des fins de présentation (par exemple, en intégrant des balises <p></p> vides pour espacer deux paragraphes ;
• Signaler un changement de sens de lecture (très rare pour les sites francophones).

Cette thématique du référentiel RAWeb se concentre sur 4 aspects :

• La bonne utilisation des titres et intertitres pour structurer le contenu (balises <hn> ou balises dotées d’un attribut role="heading" et d’un aria-level) ;
• La bonne intégration des balises Landmarks  (<header>, <main>, <footer>, <search>, <nav>) ou de leurs équivalents WAI-ARIA ;
• La bonne intégration des listes à puces, à l’aide de balises <ul> ou <ol> et <li>, des attributs équivalents WAI-ARIA role="list" et role="listitem", ou le cas échéant des balises <dl> et <dt>/<dd> (listes de description) ;
• L’identification des citations avec une balise <q> ou <blockquote>.

La thématique 10 du RAWeb regroupe 14 critères destinés à garantir la flexibilité et la lisibilité des contenus textuels et graphiques.

Les feuilles de styles (CSS) doivent être utilisées impérativement pour gérer la mise en forme, ce qui traduit par une interdiction de certaines balises et attributs de présentation, comme par exemple les balises <center>, <basefont>, <big>, <blink> et <font>, ainsi que les attributs align, bgcolor, alink, background, border et cellpadding.

Les espaces ne doivent pas être utilisés pour la mise en forme du contenu : séparation entre les lettres d’un mot, simulation d’un tableau ou de colonnes, effet de marge ou d’alignement.

L’utilisateur doit également conserver le contrôle de son affichage : une personne malvoyante doit en effet pouvoir lire un texte avec un zoom à 200 %.

Les couleurs de police et de fond doivent être déclarées dans la CSS pour chaque élément, ou doivent être héritées d’un parent. En cas d’image de fond, une déclaration de couleur de fond doit être également déclarée.

La prise de focus doit toujours être visible, soit avec le style par défaut du navigateur, soit avec une définition CSS propre au site.

Les contenus cachés doivent être ignorés des technologies d’assistance. S’ils peuvent être affichés par l’utilisateur, ils doivent alors être également restituables par les technologies d’assistance.

L’information ne peut pas être uniquement donnée par la forme, la taille ou la position. Elle doit en effet être transmise à tous les utilisateurs, quel que soit le contexte. Des flèches de pagination, par exemple, doivent s’accompagner d’un intitulé explicite comme « page suivante » pour que l’information ne dépende pas uniquement de leur aspect visuel ou de leur orientation.

Enfin, le contenu doit s’adapter aux petits écrans (sans défilement horizontal en 320px de largeur).

La thématique 11 du RAWeb regroupe les critères dédiés à l’accessibilité des formulaires. C’est un enjeu crucial, car ces derniers constituent un moyen de contact incontournable, et parfois le seul disponible.

Chaque champ de saisie doit posséder une étiquette pertinente, visible et correctement liée, destinée à identifier sa fonction.

Les champs de même nature, tels que les boutons radio ou les cases à cocher, sont regroupés de manière cohérente, notamment via des structures de groupes et de légendes.

L’aide à la saisie est indispensable : les champs obligatoires ainsi que les formats attendus doivent être explicitement indiqués dès le départ. En cas d’erreur, des messages clairs, textuels et directement associés aux champs concernés doivent être fournis, accompagnés si nécessaire d’un exemple concret.

Le formulaire doit aussi prendre en charge l’autocomplétion des données personnelles.

Certains formulaires liés à la modification de données, à la réalisation d’examens ou de tests, ou se traduisant par des impacts financiers et juridiques, exigent une vigilance particulière pour prévenir les erreurs. Pour ces situations, il convient de permettre l’annulation des actions effectuées, d’offrir un moyen de vérification et de correction avant l’envoi, ou d’intégrer un mécanisme de confirmation explicite.

Navigation au sein d’une page ou d’un site pose de véritables défis en termes d’accessibilité.

La thématique 12 du RAWeb prévoit notamment la présence de deux systèmes de navigation différents, parmi les trois disponibles :

• Un menu de navigation ;
• Un plan du site pertinent (pas forcément exhaustif, tant que son utilisateur permet d’atteindre indirectement tous les pages du site) ;
• Un moteur de recherche (intégrant toutes les pages du site).

Le menu, les barres de navigation et le moteur de recherche doivent être toujours positionnés au même endroit sur chaque ensemble de pages, afin de ne pas perturber l’utilisateur.

Un lien d’évitement permet d’atteindre immédiatement la zone de contenu principal. Plus largement, les zones de regroupement de contenus présentes sur plusieurs pages doivent pouvoir être évitées ou atteintes, notamment par le biais d’un lien d’évitement ou d’un lien d’accès rapide placé directement.

La navigation au clavier est garantie par un ordre de tabulation cohérent, l’absence totale de pièges et la possibilité d’atteindre les contenus additionnels apparaissant au survol, à la prise de focus ou via un composant d’interface.

L’utilisateur doit pouvoir désactiver ou configurer les raccourcis clavier à une touche, à moins que le raccourci associé à un composant d’interface ne s’active uniquement lorsque celui-ci possède le focus.

La thématique 13 du RAWeb s’intéresse à plusieurs aspects de l’accessibilité web.

L’utilisateur doit tout d’abord conserver le contrôle des éléments affichés à l’écran, en ayant par exemple la possibilité de mettre en pause ou d’arrêter une vidéo, un carrousel ou une bande-son. De même, l’ouverture d’une nouvelle fenêtre doit résulter de sa seule décision et ne survenir que suite à une action explicite de sa part.

Les flashs lumineux et les changements brusques de luminosité peuvent poser problème à des internautes souffrant de certaines affections telles que l’épilepsie, et sont donc pris en compte par le RAWeb.

Les contenus cryptiques (art ASCII, émoticône, syntaxe cryptique) doivent être ignorés. S’ils sont porteurs d’information, ils doivent alors bénéficier d’une alternative accessible, à l’aide par exemple d’un attribut title ou d’une balise <abbr>.

Le contenu doit aussi supporter le changement d’orientation (portrait/paysage) de l’appareil. En effet, certains utilisateurs en situation de handicap ne peuvent pas modifier l’orientation de leur écran.

Cette thématique s’intéresse aussi aux gestes complexes et aux fonctionnalités impliquant un mouvement (par exemple, pincer pour réduire une fenêtre ou swiper pour changer de page). Les mêmes fonctionnalités doivent être accessibles par un mécanisme alternatif.

Les documents bureautiques sont également abordés : soit ils sont accessibles et compatibles avec les technologies d’assistance, soit vous proposez une solution alternative accessible (par exemple, une page web en alternative à un fichier PDF).

Le RAWeb 1.1 ajoute deux critères par rapport au RGAA 4.1.2 :

• Le maintien des informations d’accessibilité lors de la conversion d’un document d’un format à un autre, à condition que le format de destination le supporte. Par exemple, lors de l’exportation d’un document texte vers un format PDF, l’alternative textuelle d’une image ou la structure des niveaux de titres doivent être conservées.
• L’obligation de proposer une méthode alternative pour chaque fonctionnalité d’identification ou de contrôle reposant sur la biométrie. Par exemple, en cas d’identification par empreinte digitale, il convient de proposer également une identification par mot de passe.

Cette thématique du RAWeb 1.1 est absente du RGAA 4.1.2. Elle se focalise sur l’accessibilité de la documentation (page d’aide, déclaration d’accessibilité…). Celle-ci doit notamment : 

• Décrire les fonctionnalité d’accessibilité disponibles et les informations relatives à la compatibilité avec l’accessibilité ;
• Vérifier que les mécanismes d’activation des fonctionnalités d’accessibilité sont utilisables par les personnes concernées ;
• Être accessible en respectant les critères de conformité du RAWeb?

La thématique 15 du RAWeb 1.1, elle aussi absente du RGAA 4.1.2 encadre les outils d’édition du contenu.

Ceux-ci doivent intégrer des fonctionnalités natives pour faciliter la création de contenus accessibles, quel que soit le format de destination (Web, PDF, documents bureautiques ou applications mobiles) :

• En permettant de définir toutes les informations d’accessibilité requises ;
• En fournissant des aides à la création ainsi que des suggestions de correction automatiques ou semi-automatiques pour chaque erreur détectée ;
• En générant un résultat conforme aux règles d’accessibilité ;
• En fournissant au moins un gabarit accessible, clairement identifiable par l’utilisateur.

Un éditeur WYSIWYG doit par exemple offrir des fonctionnalités pour :

• Ignorer facilement une image décorative ;
• Intégrer un tableau de données accessible ;
• Signaler un changement de langue ;
• Insérer une liste à puces ou une citation ;
• Etc.

Le RAWeb consacre une thématique (absente du RGAA 4.1.2) aux services d’assistance.

Ceux-ci doivent être adaptés aux utilisateurs en situation de handicap et répondre à leurs besoins spécifiques :

• En fournissant des informations précises sur les fonctionnalités d’accessibilité du site, ses composants complexes et ses éventuelles limites ou non-conformités ;
• En garantissant des moyens de communication alternatifs et adaptés (comme un formulaire en ligne, une messagerie instantanée ou un service de relais avec interprétation en langue des signes) si l’assistance repose initialement sur un canal vocal ou téléphonique ;
• En veillant à ce que toute la documentation fournie par ce service soit elle-même accessible, quel que soit son format (Web, PDF ou document bureautique).

Un service d’assistance téléphonique doit par exemple offrir des modalités pour :

• Permettre l’envoi d’un courriel ou le remplissage d’un formulaire de contact ;
• Échanger par écrit via un tchat en direct ;
• Accéder à une transcription simultanée ou à un interprète en langue des signes ;
• Etc.

La 17e et dernière thématique du RAWeb 1.1 se focalise sur les modes de communication en temps réel (audio, texte ou vidéo), pour garantir qu’ils soient utilisables par les utilisateurs en situation de handicap, notamment les personnes sourdes, malentendantes ou aphasiques.

Les solutions intégrant l’audio, telles qu’un serveur interactif ou une messagerie vocale, doivent : 

• Offrir une bande passante d’au moins 7 000 Hz pour assurer une clarté optimale de la voix. 
• Proposer une alternative pour être utilisables sans obligation  d’écouter ou de parler.

Les services de communication écrite en temps réel (RTT) doivent :

• Proposer une fonctionnalité d’écrit par reconnaissance vocale avec une transmission quasi-instantanée ;
• Séparer visuellement les flux de messages envoyés et reçus ;
• Rendre ces messages accessibles aux technologies d’assistance ;
• Afficher par écrit l’identité des auteurs des messages textuels (y compris lorsqu’ils sont cités à l’oral).

Les solutions intégrant la vidéo en temps réel doivent :

• Assurer une qualité d’image suffisante pour la langue des signes (résolution minimale et fréquence de 20 images par seconde au moins) ;
• Limiter le décalage entre la vidéo et les paroles à 100 ms maximum ;
• Intégrer un indicateur visuel de l’activité orale ainsi qu’un mécanisme pour identifier l’activité d’un interlocuteur s’exprimant en langue des signes.