Les nouveautés des WCAG 2.1

WCAG 2.1, en route vers WCAG 3.0

Le travail sur les WCAG 2.1 est la première étape d’un processus très ambitieux qui doit permettre, à terme, de refondre intégralement les trois recommandations internationales – WCAG, ATAG ^[1] et UAAG ^[2] – dans un corpus commun.

Ce vaste projet de refonte tient à un constat : les WCAG 2.0, publiées en 2008, ne parviennent plus à couvrir la totalité des technologies, avec l’avènement du mobile, ni l’ensemble des besoins des utilisateurs, ceux des handicapés mentaux et cognitifs par exemple.

Après de longs débats pour savoir s’il fallait refondre les WCAG ou proposer des extensions, c’est la voie de la refonte qui a été choisie.

Les WCAG 2.1 sont donc la première pierre de l’édifice. Elles seront suivies d’une version 2.2, voire 2.3 si la WAI ne parvient pas rapidement à mettre en œuvre les WCAG 3.0. Il y aurait beaucoup à dire sur les risques d’une telle révolution alors même que les WCAG 2.0 ne parviennent toujours pas à s’imposer dans les pratiques de développement. Nous aurons l’occasion d’y revenir !

Pour le moment, détaillons les nouveaux critères que propose ce document de travail, présenté comme l’une des dernières versions.

3 nouvelles règles, 11 nouveaux critères

Trois nouvelles règles

Règle 2.5 : pointeur accessible

Cette règle est en discussion et pourrait disparaître. Elle devrait définir la façon dont les sites web doivent prendre en charge tous les types de pointeurs (souris, toucher, stylet…).

Elle est actuellement proposée à la suppression ou reportée sur le groupe de travail consacré aux WCAG 3. En effet, la problématique des pointeurs semble comprise dans celle plus générale des mécanismes d’interactions (« input mechanisms ») et dans un critère de succès, en création dans les WCAG 2.1. Ce critère propose de contrôler les mécanismes concurrents, et donc les différents modes de pointeurs, mais également les interactions réalisées grâce à des commandes vocales par exemple.

Règle 2.6 : capteurs de données supplémentaires

Cette règle est spécifiquement dédiée aux terminaux mobiles. Elle demande par exemple à ce que la consultation d’un contenu soit indépendante de l’orientation du terminal.

Règle 2.7 : vocal

Cette règle encadre un cas d’utilisation particulier : permettre aux utilisateurs qui naviguent à la voix de pouvoir prédire les noms des composants d’interface à énoncer. Elle requiert notamment que l’étiquette d’un composant interactif soit comprise dans le nom accessible de l’élément.

Onze nouveaux critères

SC 1.4.10 [AA] Zoom du contenu

Il s’agit de s’assurer que le contenu peut-être agrandi jusqu’à 400% sans perte de contenu et sans utilisation de l’ascenseur horizontal pour un contenu présenté verticalement, et inversement pour un contenu présenté horizontalement.

Ce nouveau critère vient en complément du critère 1.4.4 des WCAG 2.0 sur l’agrandissement des tailles de caractères. Il est spécifiquement destiné aux écrans d’ordinateur de bureau ou portable car le comportement du zoom sur mobile est différent.

Cela va nécessiter de généraliser les modes de conception responsive pour pouvoir gérer la recomposition de contenu (reflow).

En revanche, cela pose un problème important de rétrocompatibilité avec les WCAG 2.0. En effet, l’absence de barre de défilement horizontal à l’agrandissement des caractères était une exigence de niveau AAA dans les WCAG 2.0 (critère 1.4.8). Elle devient une exigence de niveau AA dans les WCAG 2.1. Il sera quasiment impossible d’adapter des sites déjà en ligne et qui ne sont pas conçus pour permettre un tel agrandissement de contenu.

SC 1.4.11 [AA] Contrastes des éléments graphiques

Très souvent réclamée, l’exigence de contraste pour les éléments graphiques est enfin introduite. En effet, jusqu’à maintenant, seuls les contrastes des textes étaient encadrés.

Ce critère concerne les éléments graphiques essentiels à la compréhension. Deux niveaux de contrastes sont requis : 4.5 en général et 3 pour les éléments dont les dimensions sont au moins égales à 3 pixels.

Simple et de bon sens mais attention ! Cette problématique pose beaucoup de questions quant à son application : notamment, la définition d’un « élément graphique essentiel à la compréhension » et la gestion des dérogations.

Certaines dérogations sont déjà prévues. C’est le cas des logos, des éléments graphiques utilisés pour créer une expérience visuelle spécifique ou des éléments graphiques dont la présentation particulière (e.g éventuellement insuffisamment contrastés) est essentielle à l’information présentée. Pas évident que ces trois cas génériques soient effectivement suffisants.

La mesure elle-même pourrait être complexe lorsque l’élément graphique fait appel à la combinaison de plusieurs couleurs, il faudra alors utiliser une moyenne.

Enfin, les nombreux aléas de la mesure de contraste sur les écrans électroniques pourraient rendre nécessaire le recours à des présentations alternatives, comme pour les contrastes de texte mais plus difficiles à mettre en place, le recours à CSS devenant en l’espèce insuffisant.

SC 1.4.12 [AA] Contrastes des composants d’interface utilisateur

Il s’agit d’un clone du critère précédent mais cette fois-ci appliqué aux composants interactifs, par exemple les boutons et les éléments de formulaire. Les niveaux requis sont les mêmes ; 4.5 en général et 3 pour les éléments dont les dimensions sont au moins égales à 3 pixels.

La seule différence réside dans les dérogations proposées :

• Les éléments désactivés ou inactifs ;
• L’utilisation des styles par défaut des composants proposés par le navigateur.

Cette dernière dérogation est quelque peu délicate parce que les styles par défaut peuvent être insuffisants (comme le curseur des sliders de Firefox) et le contraste, dépendant de la couleur environnante, pourrait être malgré tout insuffisant.

SC 1.4.13 [AA] Adaptation du texte

Il s’agit de vérifier que, lorsque l’utilisateur personnalise certaines caractéristiques du texte, il n’y a pas de perte de contenu. Les caractéristiques sont l’espacement des lignes, des paragraphes, des lettres ou des mots. La modification des polices et des couleurs de police ou d’arrière-plan est également en discussion.

Dans le cadre d’une production de contenu utilisant des méthodes habituelles, notamment celles permettant de s’assurer d’un design adaptable, cela ne devrait pas poser trop de problèmes.

En revanche, la prise en compte des changements de police pourrait poser problème pour l’utilisation des polices-icônes si ce n’est pas correctement fait.

On peut également se poser la question du choix du niveau car il s’agit ici clairement d’une optimisation, et donc plutôt de niveau AAA, dans l’esprit des niveaux WCAG.

SC 2.2.6 [AA] Interruption (minimum)

Ce critère élève le niveau d’exigence du critère 2.2.4 de niveau AAA : lorsqu’un processus est interrompu, par exemple par une alerte, l’utilisateur doit pouvoir reporter ou supprimer l’interruption à l’exception du cas où l’interruption invoque une situation d’urgence.

Ici il s’agit, dès le niveau AA, de s’assurer que les interruptions et les changements de contenu sont contrôlables par l’utilisateur avec deux cas de dérogations :

• Lorsque l’interruption est initiée par l’utilisateur ;
• Lorsqu’elle concerne un cas d’urgence.

Le focus donné sur les changements de contenu peut être très complexe à prendre en charge. Par exemple : le fait d’ajouter dans un processus de commandes des offres promotionnelles pourrait être considéré comme une non-conformité pour ce critère, parce que cela détourne l’utilisateur de la tâche initiale (commander un produit).

Dans ce cas, offrir un processus pour stopper ce qui serait considéré comme des « interruptions » reviendrait à exclure du champ du niveau AA une immense partie des sites web commerciaux.

Tel qu’il est rédigé actuellement, ce critère semble très problématique pour le niveau AA.

SC 2.2.7 [A] Authentification Accessible

Il s’agit de s’assurer qu’un processus d’authentification ne dépend pas uniquement de la capacité de l’utilisateur à se souvenir ou à retranscrire des informations. Pour faire simple, cela revient à dire qu’un processus d’authentification aussi habituel que la saisie d’un identifiant et d’un mot de passe doit être accompagné d’une méthode permettant à l’utilisateur de retrouver ou modifier son mot de passe facilement, ou d’utiliser un processus d’authentification alternatif.

Deux dérogations sont prévues :

• Lorsque les informations demandées sont basiques et facilement accessibles par l’utilisateur (nom, email, numéro de sécurité sociale) ;
• S’il existe une contrainte légale.

Il faudra sans doute préciser ce qui est entendu par « processus d’authentification » pour mesurer l’impact réel sur le développement des formulaires d’authentification. Cela dit, pour ce qui concerne les processus d’authentification habituels, un lien « Mot de passe oublié » devrait suffire.

SC 2.4.11 [A] Raccourcis clavier alphanumériques

L’utilisation de raccourcis clavier constitués d’une seule touche de caractère peut poser des problèmes aux utilisateurs de navigation vocale, qui peuvent déclencher accidentellement une action, ou une série d’actions, en dictant une phrase ou en utilisant des commandes spécifiques. Cela peut également affecter certains handicapés moteurs qui peuvent déclencher une action en appuyant par erreur sur une touche.

Ce nouveau critère requiert que, lorsque de tels raccourcis existent, l’utilisateur dispose d’une méthode pour désactiver le support de ces raccourcis clavier, ou pour les modifier en y associant une touche qui ne soit pas un caractère, par exemple Ctrl, Alt, Maj, etc.

Ne sont visés ici que les raccourcis clavier fournis par l’auteur dans le contenu. Ce critère ne concerne donc pas les raccourcis clavier propres à certains composants, comme les listes select, car on accède à ces composants par des combinaisons de touches et l’utilisation d’accesskey qui utilise nativement une combinaisons de touches.

SC 2.6.1 [AA] Orientation

Largement anticipé par l’état de l’art, ce critère vérifie que l’application ou son contenu sont utilisables dans les deux modes possibles de consultation sur mobile : en portrait et en paysage.

Il y a néanmoins une dérogation : lorsque l’orientation est essentielle à l’utilisation du contenu et des fonctionnalités.

SC 2.7.1 [A] Nom accessible

Le nom accessible d’un composant est le nom transmis aux API d’accessibilité. C’est le nom accessible qui permet d’identifier le composant et donc de déclencher son action via une commande vocale par exemple. L’exemple le plus simple est le label d’un champ de formulaire.

Il peut toutefois y avoir un problème lorsque le composant est associé visuellement à un texte visible qui ne fait pas partie du nom accessible. Par exemple : un bouton visuellement associé au mot « menu » qui utilise une propriété aria-label="Liste des rubriques". Pour déclencher l’action, l’utilisateur de commande vocale dira « menu » et, naturellement, rien ne se passera.

Ce critère vise à vérifier que, lorsqu’un composant est associé à un label visible, ce dernier est bien présent dans le nom accessible.

Dans l’exemple ci-dessus, la correction serait d’ajouter « menu » au contenu de la propriété aria-label : aria-label="menu : liste des rubriques".

Attention cependant : ce critère ne demande pas d’associer visuellement un texte à chaque contrôle qui utilise une image ou une icône par exemple.

SC 3.2.6 [A] Activation accidentelle

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.

Au moins une de ces méthodes doit être utilisée pour déclencher une action :

• L’action se déclenche à la fin de l’interaction (sur mobile par exemple, l’action se déclenche à la fin de l’événement touch) ;
• Un mécanisme est mis à disposition pour permettre à l’utilisateur de déclencher les actions à la fin de l’événement ;
• Un mécanisme de confirmation permet à l’utilisateur d’abandonner l’action ;
• Un mécanisme permet à l’utilisateur d’annuler l’action.

Une dérogation existe lorsque l’activation en début d’événement est essentielle. Par exemple : dans une application de piano, le fait que le son se déclenche quand on appuie sur une touche ou, dans un jeu, le fait de tirer à l’appui d’une touche.

SC 3.2.7 [AA] Changement de contenu

La problématique des changements dynamiques de contenu et de leur accessibilité est largement couverte par les WCAG, notamment par l’intermédiaire de la notion de changement de contexte ou de l’accessibilité des dispositifs JavaScript basés sur ARIA. Néanmoins, faute d’avoir dans les WCAG un critère spécifique aux changements dynamiques de contenu, certaines fonctionnalités pouvaient échapper à la vigilance des développeurs.

Ce critère comble ce manque et précise le besoin de pouvoir notifier certains types de changement de contenu comme : la mise à jour d’un panier, l’ordre de tri d’un tableau, la confirmation de la réussite ou de l’échec d’une action.

Ce critère est à double tranchant : il cadre un problème réel mais nécessite de bien comprendre les implications pour l’utilisateur et ce qui est attendu comme notification, sans quoi son application risque de produire des quantités de notifications inutiles et contre-productives.

Par exemple, le fait d’inverser la fonctionnalité d’un bouton de tri (tri de A-Z et tri de Z-A) paraît suffisant. On ne voit pas bien l’utilité d’ajouter une notification explicite, tel que « Les données ont été triées par ordre alphabétique », qui, généralisée sur l’ensemble d’une application, pourrait rendre son utilisation particulièrement indigeste.

Conclusion

Cette proposition d’évolution des WCAG 2.1 élève singulièrement le niveau d’exigence en prenant en charge des problématiques nouvelles, liées aux interfaces mobiles, et en mettant l’accent sur des problématiques utilisateurs peu traitées par les WCAG 2.0, comme le contrôle vocal ou certaines déficiences cognitives par exemple.

Certains critères vont être quasiment impossibles à prendre en charge sur des sites déjà en ligne sans en envisager une refonte totale, comme l’exigence de recomposition des contenus (reflow).

Plusieurs des nouveaux critères AA vont aussi considérablement compliquer la production ou la refonte de sites ou d’applications d’un point de vue technique ou budgétaire, ce qui pourrait poser des problèmes importants d’adaptation des normes d’accessibilité et des législations sur lesquelles elles sont basées.

Le critère sur les interruptions par exemple, tel qu’il est actuellement rédigé et à défaut d’explications plus précises sur la notion d’interruption initiée par un changement de contenu, apparaît comme le plus problématique car il représente une marche d’accès au niveau AA (niveau légal) quasiment infranchissable pour toute une catégorie de sites privés ou publics.

La marche forcée vers les WCAG 3 et la succession rapide de versions transitoires pourraient également rendre les adaptations techniques et réglementaires particulièrement complexes alors que les WCAG 2.0 peinent encore à s’imposer dans la réalité du développement.

Si les progrès des WCAG 2.1 sont indéniables, leur application et leur adaptation aux réalités du terrain constituent un véritable défi pour les années à venir.