Comprendre les WCAG 2.1

WCAG 2.1. Les Règles pour l'accessibilité des contenus Web

Les Règles pour l’accessibilité des contenus Web (ou Web Content Accessibility Guidelines – WCAG) présentent un large éventail de recommandations pour rendre les contenus Web plus accessibles.

Suivre ces règles rendra les contenus accessibles à une plus grande population de personnes en situation de handicap, incluant les personnes aveugles et malvoyantes, sourdes et malentendantes, ayant des troubles d’apprentissage, des limitations cognitives, des limitations motrices, des limitations de la parole, de la photosensibilité et les personnes ayant une combinaison de ces limitations fonctionnelles. Suivre ces règles rendra aussi les contenus Web souvent plus faciles d’utilisation aux utilisateurs en général.
Le 5 juin 2018, les WCAG 2.1 sont devenues une recommandation officielle du W3C (World Wide Web Consortium). 17 nouveaux critères ont été intégrés, concernant des problématiques liées au mobile, à la basse vision et au handicap cognitif ; ils sont répartis sur les trois niveaux de complexité définis par le W3C : A, double A (AA) et triple A (AAA).

Cette nouvelle version des WCAG n’enlève ou ne modifie aucun critère de la version précédente, cela signifie qu’un site conforme WCAG 2.1 sera donc conforme WCAG 2.0. Par conséquent, pour l’instant en France, le référentiel RGAA 3 (Référentiel Général d’Accessibilité pour les Administrations), qui est une transposition des WCAG 2.0, ne permet pas encore de se conformer à cette nouvelle version des WCAG 2.1.

Liste des nouveaux critères

Attention, les exemples cités ci-dessous ne représentent pas l’intégralité des cas d’utilisation des critères, mais uniquement des mises en situation assez significatives pour appréhender facilement les critères WCAG 2.1.

1.3.4 Orientation (AA)

Le contenu ne limite pas sa vue et son fonctionnement à une seule orientation d’affichage, telle que le portrait ou le paysage, à moins qu’une orientation d’affichage spécifique soit essentielle (par exemple une application de piano ou une application de diffusion de contenu sur un distributeur bancaire).

1.3.5 Identify Input Purpose (AA)

Permettre à l’utilisateur d’identifier les champs de formulaire collectant des informations personnelles de façon programmatique (via une présence de balises ou d’attributs).

Nos confrères d’Access 42 ont publié sur leur blog un article dédié à ce critère, nous vous invitons à le consulter.

1.3.6 Identify Purpose (AAA)

Dans le contenu implémenté à l’aide des langages de balisage, l’objectif des composants d’interface utilisateur, des icônes et des régions, peut être déterminé par programme. Le RGAA répond déjà en partie à cette question via les critères suivants :

Seul ajout notable, l’utilisation des microformats (ou de nouveaux attributs ARIA) pourrait être exigée afin d’identifier des zones de la page (liens importants, icônes d’actions, etc.). Le but étant de permettre à l’utilisateur de personnaliser programmatiquement les informations sur ces zones, tel que des remplacements d’icônes, l’ajout d’information de contexte ou la suppression d’information “annexes”.

1.4.10 Reflow (AA)

Il s’agit de permettre un zoom jusqu’à 400 % sans faire apparaître de barre de défilement contraire au sens de lecture. En d’autres termes, la construction d’un site selon les règles du responsive web-design (RWD) va devenir quasiment obligatoire car elle permet de restructurer l’affichage des blocs de contenu en fonction de la taille de l’écran, mais aussi de gérer les points de rupture, non plus en fonction d’une taille fixe, mais en fonction d’une taille relative, comme l’explique Nicolas Hoffmann dans son article de blog.

1.4.11 Non-text Contrast (AA)

À l’instar du critère WCAG 1.4.3 (ou de son équivalent RGAA, le critère 3.3) sur le contraste des éléments textuels, ce critère s’applique donc aux éléments non textuels (indication de menu actif, bordure de champ de formulaire, etc.). Le contraste minimum demandé est de 3:1.

1.4.12 Text Spacing (AA)

Il s’agit de faire en sorte que les textes soient toujours lisibles, même si l’utilisateur a décidé d’en personnaliser l’affichage (en modifiant la police de caractère par exemple). Ce critère impose donc des espacements spécifiques entre chaque paragraphe/ligne/mot/lettre (par exemple, un espacement entre 2 paragraphes doit être au moins 2 fois celui de la taille de la police).

1.4.13 Content on Hover or Focus (AA)

Ce critère permet de gérer tous les contenus s’affichant au survol du pointeur ou lors d’une tabulation. L’utilisateur doit alors pouvoir déplacer son pointeur sur le contenu affiché, masquer ce contenu sans avoir à déplacer son curseur ni à tabuler, et enfin ce contenu doit être masqué lorsque le pointeur ou la tabulation n’est plus sur l’élément déclencheur.

Ce critère a donc une incidence directe sur les contenus du type menu déroulant et autres bulles d’aide en tout genre.

2.1.4 Character Key Shortcuts (A)

Il s’agit de pouvoir activer/désactiver ou reprogrammer les raccourcis clavier présents dans le site (composés d’une seule touche) afin que les utilisateurs ne puissent pas les déclencher par erreur (utilisateur dictant un texte lettre par lettre ou mauvaise manipulation clavier).

2.2.6 Timeouts (AAA)

Les utilisateurs sont avertis de la durée de toute inactivité pouvant entraîner une perte de données lorsqu’il ne réalise aucune action, à moins que les données ne soient conservées pendant plus de 20 heures.

2.3.3 Animation from Interactions (AAA)

À l’inverse du critère WCAG 2.2.2 (ou de son équivalent RGAA 13.17) sur l’affichage des contenus en mouvement déclenchés automatiquement, ce critère s’applique aux contenus affichés suite à l’action de l’utilisateur et doivent pouvoir être désactivés.

Par exemple, le scroll est considéré comme une action de l’utilisateur ; les effets de parallax sont ainsi soumis à ce critère et non pas au critère WCAG 2.2.2, autorisant les effets de moins de 5 secondes. Ils doivent donc pouvoir être désactivés.

2.5.1 Pointer Gestures (A)

Toutes les fonctionnalités utilisant des gestes multipoints ou des trajectoires pour réaliser une action doivent aussi pouvoir être réalisées avec un seul pointeur et sans trajectoire.

Prenons l’exemple d’un site Web disposant d’une carte fonctionnant à l’aide d’un geste de pincement des doigts pour effectuer un dézoom, et d’un geste de glissement pour déplacer la zone visible. Le site devra donc mettre à disposition des boutons [+] et [-] pour effectuer un zoom avant et arrière ainsi que des boutons fléchés pour effectuer un déplacement sur la carte.

2.5.2 Pointer Cancellation (A)

Ce critère a pour objectif de s’assurer que les actions ne peuvent pas se déclencher accidentellement du fait d’une mauvaise gestion de l’événement déclencheur. Donc les événements déclenchés par un seul gestion/clic doivent être activés à la fin de l’action du clic, ou, pour les événements au clavier, au relâchement de la touche (événement onkeyup en javascript). Cela permet aux utilisateurs d’annuler l’action s’ils décident de relâcher la touche ou leur mécanisme de pointeur en dehors de la zone cliquée.

2.5.3 Label in Name (A)

Pour les composants d’interface ayant un nom accessible (calcul accessible des noms et des descriptions) différent du nom affiché, il faut que le nom accessible reprenne au moins le nom affiché, ceci afin que les utilisateurs de commande vocale puissent faire interagir le composant d’interface.

2.5.4 Motion Actuation (A)

Toute fonctionnalité pouvant être commandée par le mouvement de l’appareil ou le mouvement de l’utilisateur, peut également être commandée par des composants de l’interface utilisateur.

Par exemple, si, dans un jeu, je dois incliner mon périphérique pour aller dans une direction, il doit y avoir une fonctionnalité équivalente via un composant de l’interface.

2.5.5 Target Size (AAA)

La taille des éléments cliquables doit être au moins de 44 par 44 px, à l’exception :

  • des composants ayant un équivalent à la bonne dimension dans la page ;
  • des liens contenus dans un paragraphe ;
  • des composants dont la taille est déterminée par l’agent utilisateur ;
  • des composants dont la taille de la cible est essentielle à la transmission de l’information.

Fournir un mécanisme pour modifier la taille de la cible indépendamment du grossissement peut s’avérer suffisant.

2.5.6 Concurrent Input Mechanisms (AAA)

Il s’agit pour le site Web de ne pas restreindre l’utilisation de plusieurs types de saisie pour renseigner une information, sauf si la restriction est essentielle, requise pour garantir la sécurité du contenu ou pour respecter les paramètres de l’utilisateur.

Divers mécanismes de saisie peuvent être utilisés lors d’une interaction avec un contenu Web. Ceux-ci peuvent être une combinaison de mécanismes – tels qu’un clavier ou des interfaces de type clavier – et des dispositifs de pointage – tels qu’une souris, un stylet ou un écran tactile. À titre d’exemple, ce critère devrait empêcher les sites de détecter la présence d’un écran tactile et d’un ordinateur portable tactile, ou sur une tablette avec un clavier et une souris physiques couplés, et simplement supposer que le toucher est le seul mécanisme d’entrée souhaité.

4.1.3 Status Messages (AA)

Ce critère correspond aux messages d’état devant être présentés à l’utilisateur sans que ce dernier ait à déplacer le focus sur le message lié à l’état courant de l’action, ou la mise à jour de contenu effectué.

En d’autres termes, ce critère revient à exiger que des messages tels que des alertes, notifications, changement de statut ou tout autre message apparaissant à l’écran, soient vocalisés à l’utilisateur en s’appuyant sur les role= »alert » ou bien les régions dynamiques aria-live.

Conclusion

Les progrès de cette version WCAG 2.1 pour l’inclusion sont indéniables, avec la prise en compte plus importante des interfaces mobiles, de la commande à la voix ou bien de certains handicaps cognitifs. En revanche, on peut s’interroger sur l’opportunité d’ajouter de nouveaux critères au WCAG 2.0 alors que les critères de base ne sont déjà peu appliqués, en tout cas en France.

Ceci dit, l’évolution récente du Web et des technologies ne peut que nous encourager ;  les WCAG 2.0 sont sortis il y a 10 ans (décembre 2008), leur appropriation par la communauté a été lente tout comme l’évolution des technologies. Prenons l’exemple de la recommandation HTML5, officiellement sortie en 2014 (bien qu’utilisée avant cette date par de nombreux de sites Web), ou encore l’évolution récente des nombreuses bibliothèques javascript et les communautés grandissantes de développeurs souhaitant partager des ressources accessibles (van11y, liste des repository github traitant de l’accessibilité, corrections de composants Jquery-ui par  Hans Hillen, etc.).

En attendant, WCAG 2.0 est toujours une norme valide et la transposition de cette norme via le RGAA 3 toujours applicable. La future transposition de la directive européenne sur l’accessibilité numérique, en septembre 2018, devrait logiquement incorporer cette nouvelle version des WCAG, mais, nous ne le savons hélas que trop, les décrets d’application des lois peuvent parfois mettre du temps a être publiés.

Le défi que représente l’appropriation et la diffusion des WCAG 2.1 n’en est qu’à son début, mais ce bouillonnement est très stimulant !

Quelques ressources complémentaires :