Malgré son caractère obligatoire, l’accessibilité WEB est sujette à de nombreux préjugés. De par cette méconnaissance, il peut paraître compliqué de mettre en place des politiques pour rendre un site WEB accessible. Pourtant, il suffit de respecter quelques critères simples pour garantir un niveau d’accessibilité basique. Nous allons voir à travers cet article quels référentiels de critères existent. Chaque critère sera explicité et complété par des bonnes pratiques. Enfin, des outils pour pouvoir tester le respect des règles dans une application sont présentés.
Appliquer cet ensemble de critères, c’est améliorer l’expérience de tous les utilisateurs. C’est également permettre que le WEB puisse être consulté et conçu par tous. C’est permettre de partager la connaissance partout, quels que soient les profils des utilisateurs et leurs contextes d’utilisation des applications.
L’accessibilité WEB, définition et utilité
L’accessibilité du web a pour objectif que “les sites web, les outils et les technologies soient conçus et développés de façon à ce que les personnes handicapées puissent les utiliser, en naviguant, interagissant et contribuant aux applications web.” [2]
Les handicaps peuvent être multiples (auditif, cognitif, neurologique, physique, linguistique ou visuel).
Cependant, les personnes en situation de handicap ne sont pas les seules concernées par l’accessibilité. En effet, toute personne, qu’elle présente un handicap ou non, peut présenter différents niveaux d’attention (Thomas, 2005) :
- Attention flottante : Le sujet ne prête pas d’attention à son environnement jusqu’à ce qu’il aperçoive des éléments récréatifs, pour les contempler. L’attention est peu mobilisée, naïve.
- Attention centrée : L’attention est mobilisée en permanence, puis elle est concentrée sur des événements atypiques. L’utilisateur n’a pas d’objectif ni de réactivité.
- Attention distribuée : Le sujet balaie son environnement à la recherche d’informations ou d’évènements. L’attention est fortement mobilisée.
- Attention focalisée : Le sujet a un objectif, il est attentif à tout son environnement. L’attention est fortement mobilisée, l’utilisateur ne se laisse pas distraire et est focalisé sur un objectif.
En résumé, l’accessibilité vise à prendre en considération tous les utilisateurs, quels que soient :
- leur âge
- le support de navigation (tablette, mobile, montre connectée…)
- leur éducation
- leurs capacités
- leur environnement (pas d’audio, utilisation en plein soleil)
- leur niveau d’attention
- la stabilité de leur connexion
Que dit la loi sur l’accessibilité WEB?
En France, les recommandations internationales pour l’accessibilité sur Internet doivent obligatoirement être appliquées pour les services de communication publique en ligne. Ceci depuis le 11 février 2005, avec la “loi pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées”.
De plus, depuis le 24 juillet 2019, le décret relatif à “l’accessibilité aux personnes handicapées des services de communication au public en ligne” dispose que toutes les applications ci-après doivent être accessibles :
- les sites internet, intranet et extranet
- les applications mobiles
- les progiciels
- les mobiliers urbains numériques
Référentiels de règles pour l’accessibilité WEB
Comment mesurer l’accessibilité d’une application ?
Il existe trois entités à ne pas confondre : les WCAG, le RGAA et Accessiweb.
WCAG : Web Content Accessibility Guidelines
Les WCAG sont les recommandations rédigées par la WAI (Web Accessibility Initiative). Ce sont elles qui font foi internationalement. Il existe deux versions, la première publiée en 1999, la deuxième en 2008.
Selon les WCAG, les applications Web peuvent être classées en trois niveaux. Ces niveaux sont définis suivant le nombre de critères qu’elles respectent (chaque règle étant composée de plusieurs critères) :
- Niveau A : l’application respecte tous les critères de priorité 1. L’accès aux informations est minimal. Exemple : Toute information véhiculée par la couleur est également perceptible sans couleur.
- Niveau AA : l’application respecte tous les critères de priorité 1 et 2. L’accès aux informations est correct. Exemple : Les contrastes de couleurs entre avant-plan et arrière-plan sont suffisants dans les images.
- Niveau AAA : l’application respecte tous les critères de priorité 1, 2 et 3. L’accès aux informations est excellent. Exemple : Les contrastes de couleurs entre avant-plan et arrière-plan sont suffisants dans les textes.
Remarque : Selon les WCAG 2.0, il existe quatre grands principes. Chaque principe est décomposé en plusieurs règles. Chaque règle peut être décomposée en critères de niveau 1, 2 ou 3.
Les règles des WCAG ont été traduites par l’association BrailleNet et sont disponibles sur le Web : http://www.w3.org/Translations/WCAG20-fr/.
RGAA : Référentiel Général d’Accessibilité pour les Administrations
Le RGAA sert à mesurer le déploiement des WCAG.
En France, depuis la loi du 5 février 2005, tous les sites Internet des services publics se doivent d’être accessibles. Le RGAA liste des tests à réaliser pour se positionner par rapport aux WCAG 2.0.
La dernière version du RGAA a été arrêtée par la ministre chargée des personnes handicapées et le ministre chargé du numérique le 20 septembre 2019 [1].
Le RGAA permet distinguer trois niveaux :
- Bronze (55 critères bronze respectés)
- Argent (tous les critères Bronze et 23 critères Argent respectés)
- Or (tous les critères Bronze et Argent et 14 critères Or respectés)
Le RGAA n’évolue que très peu au fil des années.
Accessiweb
Accessiweb est un label et un centre de ressource créé en 2003 par l’association BrailleNet. Comme le RGAA, il propose une méthode pour tester l’application des recommandations WCAG 2.0. Même si les critères Accessiweb ont été conçus pour correspondre aux critères RGAA, la méthode Accessweb est plus stricte que celle proposée par le RGAA.
Les critères à prendre en compte pour l’accessibilité WEB
D’après les WCAG 2.0, il existe quatre grands principes, chacun étant définis par des règles.
L’application se doit d’être perceptible, utilisable, compréhensible et robuste.
Principe 1 : Perceptible
Règle 1.1 : Équivalents textuels
L’objectif est de proposer des équivalents textuels à tout contenu non textuel. Ces équivalents peuvent prendre différentes formes (des grands caractères, du braille, de la synthèse vocale, des symboles ou un langage simplifié).
Les éléments non textuels sont de différentes natures :
- les images
- les contenus visuels animés
- les zones cliquables
- les contenus multimédia (vidéos, etc.)
- les boutons graphiques
- les champs de formulaire
- les contenus sonores
- les émoticônes
- les éléments non textuels générés par javascript
Par quoi remplacer ces éléments non textuels ?
- Quand l’élément est décoratif ou non informatif : pas d’alternative
- Alternative textuelle reproduisant l’information véhiculée par l’élément
- Alternative textuelle permettant de comprendre l’action déclenchée
- Une description longue quand on ne peut résumer le contenu (graphique, etc.)
Sont principalement concernés par cette règle :
- Les personnes handicapées visuelles qui utilisent la synthèse vocale d’un lecteur d’écran,
- Les utilisateurs ayant désactivé l’affichage des éléments graphiques ou multimédias. Leur objectif étant de réduire les temps de téléchargement des pages en bas débit.
Règle 1.2 : Média temporel
L’objectif est de proposer des versions textuelles de remplacement aux médias temporels (vidéo et audio).
Pour un élément uniquement visuel, sa retranscription doit reprendre les éléments visuels (par exemple les actions, attitudes ou gestes).
Utilisateurs principalement concernés :
- Les personnes ayant une déficience auditive pour le contenu sonore
- Les personnes ayant une déficience visuelle pour le contenu vidéo
Règle 1.3 : Adaptable
L’objectif est de rendre l’information indépendante de sa mise en forme visuelle ou sonore. Classiquement, la structure d’une page se voit visuellement. Par exemple, la couleur est différente pour la barre menu ou les informations de même nature sont regroupées par couleur. Ce type d’information structurelle doit pouvoir être restituée à tous les utilisateurs y compris les non voyants.
Ce qu’il faut faire :
- Utiliser le texte plutôt qu’une mise en forme pour transmettre de l’information
- Séparer le contenu de la forme par le biais de CSS
- Privilégier les balisages sémantiques pour les titres, les titres de hiérarchie, les citations, les tableaux de données ou les champs de formulaires.
À ne pas faire :
- Générer du contenu via les feuilles de styles
- Utiliser la couleur comme seul moyen de transmettre de l’information
- Détourner les éléments HTML de leur rôle structurel à des fins de présentations
Règle 1.4 : Distinguable
L’objectif est de faciliter la perception visuelle et auditive du contenu par l’utilisateur, notamment en séparant le premier plan de l’arrière-plan.
Pour que les personnes aveugles ou malvoyantes puissent accéder à l’information, il faut que l’application puisse être utilisée avec :
- une feuille de style personnalisée
- un écran monochrome
- un nombre de couleurs limité.
Il faut donc prévoir autre chose que la couleur qui permette de savoir qu’un élément
On peut accompagner la couleur par :
- une alternative textuelle
- une modification du balisage
- un graphisme différent
- une iconographie différente.
Il faut que l’utilisateur comprenne qu’il puisse effectuer une action ou qu’il perçoive l’information voulue sans s’appuyer seulement sur la couleur.
Principe 2 : Utilisable
Règle 2.1 : Accessibilité au clavier
L’objectif est de rendre toutes les fonctionnalités accessibles au clavier.
Des personnes avec un handicap moteur ou visuel n’utilisent que le clavier ou un périphérique adapté pour naviguer.
Tous les événements déclenchés par la souris doivent être doublés par des actions au clavier.
Règle 2.2 : Délai suffisant
L’objectif est de laisser à l’utilisateur suffisamment de temps pour lire et utiliser le contenu.
Suivant les capacités de l’utilisateur, il peut avoir besoin de plus de temps pour lire un texte, comprendre une action à effectuer, remplir un formulaire, etc.
Règle 2.3 : Crises
L’objectif est de ne pas concevoir de contenu susceptible de provoquer des crises de type épileptique.
Ainsi, il faut proscrire les animations qui peuvent provoquer :
- des changements brusques de luminosité
- des changements brusques de couleurs
- certains effets stroboscopiques.
Règle 2.4 : Navigable
L’objectif est de fournir à l’utilisateur des éléments d’orientation pour naviguer, trouver le contenu et se situer dans le site.
Il faut faciliter les lectures linéaires et le fait de pouvoir sauter des informations.
À privilégier : ajouter un menu de navigation, une zone avec un moteur de recherche, le plan du site et les contacts. Dans la page en elle-même, intégrer des balises pour pouvoir identifier les grosses parties facilement. Le but est que l’utilisateur puisse accéder ou éviter rapidement une partie.
Principe 3 : Compréhensible
Règle 3.1 : Lisible
L’objectif est de rendre le contenu textuel lisible et compréhensible.
Indiquer dans quelle langue le contenu de la page est rédigé. Le but est de pouvoir indiquer aux synthèses vocales et autres aides techniques de lire avec la bonne langue le contenu. Si cela n’est pas indiqué, une autre langue par défaut peut-être utilisée. Par exemple, une page écrite en français peut être lue avec une prononciation anglaise par un dispositif d’aide si aucune langue n’est indiquée.
En HTML, un attribut “lang” existe.
Règle 3.2 : Prévisible
L’objectif est de faire en sorte que les pages apparaissent et fonctionnent de manière prévisible.
L’utilisateur doit pouvoir anticiper les actions qu’il peut effectuer. Pour cela, on peut :
- ajouter un texte pour expliquer le résultat d’une action accessible
- ajouter un bouton de validation qui permet de finaliser une action
- éviter l’ouverture de nouvelles fenêtres sans action de l’utilisateur
Règle 3.3 : Assistance à la saisie
L’objectif est de permettre aux utilisateurs d’être alertés en cas d’erreur de saisie et d’identifier celle-ci. Idéalement, le message d’erreur est le plus précis possible, avec l’erreur en question, sa cause et sa conséquence. Un simple message “Une erreur est survenue” ne suffit pas pour faire comprendre à l’utilisateur les actions à faire pour corriger son erreur.
Par exemple, si un formulaire comprend des champs obligatoires que l’utilisateur ne complète pas, le message d’erreur doit lister les champs manquants à compléter.
Principe 4 : Robuste
Règle 4.1 : Compatible
L’objectif est d’optimiser la compatibilité avec les agents utilisateurs actuels (les navigateurs Web, les lecteurs de média, les modules d’extensions, …) et futurs, y compris avec les technologies d’assistance.
Le contenu de la page Web se doit d’être suffisamment robuste. En d’autres termes, il doit par exemple avoir toutes ses balises complètes (début et fin), des ID uniques ou encore des attributs non dupliqués.
Ainsi, le contenu sera interprété de manière fiable par une majorité d’agents utilisateurs.
Quelques outils pour évaluer ou tester l’accessibilité WEB
Pour tester les couleurs
- CONTRAST-FINDER : https://contrast-finder.tanaguru.com/, évalue le contraste de ratio couleur texte/fond et propose des couleurs de remplacement
Pour tester la complexité d’un texte
- ONLINE UTILITY : https://www.online-utility.org/, en anglais uniquement
- Scolarius : https://www.scolarius.com/, en français uniquement
Pour tester les risques photosensibles (épilepsie)
- PEAT : https://trace.umd.edu/PEAT/, outil à télécharger sur Windows,
Pour des tests plus généraux
- http://www.accessiweb.org/, les textes de lois, une barre outil, liste des outils
- http://www.w3.org/WAI/ER/tools, références internationales, liste de tous les outils, même ceux sur la complexité de lecture
- Sonar, un outil développé par Microsoft, qui permet de tester l’accessibilité d’un site, mais également son interopérabilité (possibilité de communiquer avec d’autres systèmes), ses performances, son design (peut-il s’adapter à différentes tailles d’écran) et sa sécurité.
Résumé
- L’accessibilité permet ainsi à l’application Web de s’adapter aux différents utilisateurs, handicapés ou non, quel que soit le contexte d’utilisation.
- En France, tous les sites publics doivent être accessibles.
- Les WCAG 2.0 sont des recommandations à respecter pour qu’un site soit dit accessible.
- Le RGAA et Accessiweb proposent des méthodes pour évaluer l’accessibilité d’un site en se basant sur les WCAG.
- Il existe 4 grands principes, chacun définit par plusieurs règles :
| Principes | Règles associées | Objectif |
| 1- Perceptibles | 1.1 – Équivalents textuels | Proposer des équivalents textuels à tout contenu non textuel |
| 1.2 – Média temporel | Proposer des versions textuelles de remplacement aux médias temporels (vidéo et audio) | |
| 1.3 – Adaptable | Rendre l’information indépendante de sa mise en forme visuelle ou sonore | |
| 1.4 – Distinguable | Faciliter la perception visuelle et auditive du contenu par l’utilisateur | |
| 2- Utilisable | 2.1 – Accessibilité au clavier | Rendre toutes les fonctionnalités accessibles au clavier |
| 2.2 – Délai suffisant | Laisser à l’utilisateur suffisamment de temps pour lire et utiliser le contenu | |
| 2.3 – Crises | Ne pas concevoir de contenu susceptible de provoquer des crises de type épileptique | |
| 2.4 – Navigable | Fournir à l’utilisateur des éléments d’orientation pour naviguer, trouver le contenu et se situer dans le site | |
| 3- Compréhensible | 3.1 – Lisible | Rendre le contenu textuel lisible et compréhensible |
| 3.2 – Prévisible | Faire en sorte que les pages apparaissent et fonctionnent de manière prévisible | |
| 3.3 – Assistance à la saisie | Permettre aux utilisateurs d’être alerté en cas d’erreur de saisie et d’identifier celle-ci | |
| 4- Robuste | 4.1 – Compatible | Optimiser la compatibilité avec les agents utilisateurs actuels et futurs |
- Des outils en ligne permettent de tester facilement et rapidement l’accessibilité d’un site, en analysant les couleurs utilisées ou encore la complexité des textes.
Cet article vient en complément de l’article “L’accessibilité face aux préjugés, encore des efforts à fournir” que vous pouvez également consulter sur notre blog.
Sources
[1] Direction Interministérielle du NUMérique. (2021, 18 février). Accueil – RGAA. numerique.gouv.fr. Consulté le 12 décembre 2021, à l’adresse https://www.numerique.gouv.fr/publications/rgaa-accessibilite/
[2] Shawn Lawton Henry., W. C. W. A. (2019, 5 juin). Introduction à l’accessibilité du web. Web Accessibility Initiative (WAI). Consulté le 12 décembre 2021, à l’adresse https://www.w3.org/WAI/fundamentals/accessibility-intro/fr
[3] Thomas, R. (2005). Les trajectoires de l’accessibilité. À la croisée.