Il aura fallu attendre longtemps, mais la version 2.2 des lignes directrices pour l'accessibilité des contenus web (WCAG) est presque arrivée ! Non, vraiment, nous sommes sérieux cette fois-ci. Le 20 juillet, WCAG 2.2 s'est déplacée vers la Recommandation proposée par le W3C étape. Une proposition de recommandation signifie que le W3C l'a acceptée, et les membres du W3C vont maintenant voter sur la publication du document en tant que Recommandation du W3C. Bien que le vote se termine le 19 août 2023 et que l'on espère que le document sera prêt à être publié peu de temps après, il est important de noter que les commentaires des membres du W3C pendant le processus de vote pourraient nécessiter plus de travail. Toutefois, il est prévu que d'ici la fin du mois d'août, nous disposerons d'une nouvelle mise à jour des WCAG.
Quels sont les changements ?
Les WCAG 2.2 s'appuient sur les WCAG 2.1, tout comme les WCAG 2.1 s'appuient sur les WCAG 2.0 et étendent la série de directives WCAG 2.x. Il inclut tous les WCAG 2.1, moins 4.1.1 Parsing (nous y reviendrons plus tard), plus neuf nouveaux critères. Parmi ceux-ci, deux sont de niveau A, quatre de niveau AA et trois seront des critères de réussite (CS) de niveau AAA.
La plupart des organisations visent à atteindre le niveau AA des WCAG, ce qui signifie qu'elles ajouteront six nouveaux critères à leur liste. Comme les nouveaux critères de réussite seront des ajouts aux lignes directrices existantes, ils conserveront la compatibilité ascendante et le même modèle de conformité.
Tout comme les critères ajoutés à la version 2.1, ils viseront à aider les utilisateurs malvoyants, les personnes souffrant de troubles cognitifs et de troubles de l'apprentissage, ainsi que les personnes souffrant de handicaps moteurs, avec des avantages pour les utilisateurs souffrant de handicaps sur les appareils mobiles.
Nouveaux critères de réussite
Voyons ce qu'est chacun de ces nouveaux SC, leurs noms, leurs niveaux et leur impact sur les utilisateurs finaux.
Ligne directrice 2.4 Navigable
Sous la ligne directrice 2.4 Navigable se trouvent trois des nouveaux CS. La ligne directrice 2.4.11 "Focus Not Obscured (Minimum)" est un critère de niveau AA. Pour les personnes qui utilisent un clavier ou un dispositif similaire, il est important de connaître le point de focalisation actuel. Ce nouveau critère stipule que si un autre contenu chevauche un élément focalisé, ce dernier ne peut être masqué.
Les types de contenu typiques qui peuvent chevaucher les éléments focalisés, causant un problème d'accessibilité, sont les pieds de page ou les en-têtes collants. Lorsqu'un utilisateur parcourt la page, un pied de page collant, par exemple, masque certaines parties de l'élément ciblé.
2.4.12 Focus Not Obscured (Enhanced) est la version de niveau AAA de la précédente et indique simplement que lorsque l'on descend dans la page, l'élément focalisé n'est pas du tout recouvert par d'autres contenus.
L'autre CS relevant de la ligne directrice navigable est le point 2.4.13 "Focus Appearance". Ce point a fait l'objet de nombreuses discussions et a été modifié à plusieurs reprises au cours de la phase de rédaction, mais le groupe de travail pense avoir trouvé le bon équilibre.
Le débat et, en fait, l'incohérence de la manière dont le focus visible pour les indicateurs de focus clavier est déterminé comme accessible ou non est en cours depuis, eh bien, honnêtement, aussi longtemps que j'ai été dans l'industrie (c'est-à-dire 10 ans). Bien qu'il s'agisse d'un niveau AAA, ce nouveau CS met enfin un terme à tout débat et, honnêtement, il s'agit d'un ajout très bienvenu !
Plus important encore, ce critère de réussite tiendra compte des rapports de contraste des couleurs. Lorsque vous indiquez le focus, vous devez avoir un rapport de contraste d'au moins 3:1 et un périmètre de pixels CSS d'au moins 2. Cela permettra aux utilisateurs de clavier de voir facilement quel élément interactif est au centre de l'attention.
Ligne directrice 2.5 Modalités d'entrée
Les modalités d'entrée sont complétées par deux nouvelles CS avec les mouvements de traînée et une version de niveau AA de la taille de la cible.
2.5.7 Les mouvements de glissement sont considérés comme un critère de niveau AA qui garantit que les mouvements de glissement peuvent être effectués à l'aide d'un seul pointeur sans glissement, bien entendu, à moins que le glissement ne soit essentiel. Ce critère est similaire à celui des gestes du pointeur, qui parle de gestes directionnels basés sur le chemin et de gestes multi-points. La différence réside ici dans la définition de ce qu'est un mouvement de glissement. Dans le cas du glissement, seuls les points de départ et d'arrivée du mouvement importent, et non la trajectoire. Le concept est cependant le même, et c'est une bonne garantie que des alternatives sont disponibles pour les utilisateurs qui ne peuvent pas faire glisser du tout ou avec précision.
2.5.8 La taille minimale des cibles est un autre critère de niveau AA. Il s'agit ici de s'assurer que les cibles telles que les boutons ou les icônes liées peuvent être facilement activées sans activer accidentellement une cible voisine. Le fait de prévoir une taille et/ou un espacement suffisants entre les cibles réduira la probabilité d'activer accidentellement la mauvaise commande. Les cibles doivent avoir une taille d'au moins 24 x 24 pixels CSS. Cela peut inclure l'espace blanc autour de la cible.
Ligne directrice 3.2 Prévisible
Un SC est ajouté à la ligne directrice sur la prévisibilité au point 3.2.6 Aide cohérente, qui stipule que si des options d'aide sont disponibles, par exemple : chat, coordonnées d'une personne ou option d'auto-assistance, pour un ensemble de pages, alors l'accès à au moins une option est inclus dans le même ordre relatif sur chaque page de cet ensemble.
En d'autres termes, si vous disposez d'une option de dialogue en ligne, elle doit être facilement accessible au même endroit sur chaque page du parcours, par exemple en étant épinglée dans le coin inférieur droit, ce qui rend les options d'aide faciles à trouver. Il s'agit d'une exigence de niveau A.
Ligne directrice 3.3 Aide à la saisie
L'assistance à la saisie a fait l'objet de quelques ajouts importants. L'accent est mis sur la prise en compte de la charge cognitive liée au remplissage des formulaires et à l'authentification.
Commençons par le point 3.3.7 Saisie redondante, qui devrait être un critère de niveau A. Lorsque l'on remplit un formulaire et que l'on demande des données qui ont déjà été saisies plus tôt dans le formulaire, les données répétées doivent être disponibles par le biais du remplissage automatique ou pouvoir être sélectionnées. Cela réduit l'effort cognitif lorsque des informations sont demandées plusieurs fois au cours des étapes d'un processus. Cela réduit également la nécessité de rappeler les informations fournies lors d'une étape précédente. Il existe des exceptions pour la confirmation des mots de passe et les formulaires abandonnés.
Le point 3.3.8 Authentification accessible (minimum), un critère de niveau AA, stipule qu'un test cognitif ne doit pas être exigé dans le cadre d'un processus d'authentification. Bonne nouvelle pour la biométrie ! Pas de panique, vous pouvez toujours utiliser le nom d'utilisateur (ou l'adresse électronique) et le mot de passe comme méthode d'authentification, à condition que les navigateurs et les gestionnaires de mots de passe ne soient pas bloqués et qu'ils puissent être utilisés pour remplir les champs automatiquement ou que vous autorisiez le copier-coller pour réduire la charge cognitive liée à la ressaisie.
3.3.9 Authentification accessible (renforcée) Le niveau AAA est identique à la version minimale ci-dessus, mais sans exceptions pour la reconnaissance d'objets et le contenu fourni par l'utilisateur. Là encore, il s'agit de garantir l'existence d'une méthode accessible, facile à utiliser et sûre pour se connecter, accéder au contenu, etc.
Qu'en est-il de l'analyse ?
Pour la première fois dans la série des WCAG 2, le groupe de travail a déterminé qu'une CS était obsolète et a supprimé la section 4.1.1 Parsing. Cette décision a été prise en tenant compte de plusieurs facteurs.
Le groupe de travail a conclu que tout problème réel ayant un impact sur les utilisateurs handicapés qui serait pris en compte dans le point 4.1.1 serait/devrait être pris en compte par d'autres critères de réussite tels que 1.3.1 Info et relation ou 4.1.2 Nom, rôle et valeur. Les autres problèmes d'analyse syntaxique qui surviennent couramment ne créent plus d'erreurs d'accessibilité, compte tenu de la manière dont les navigateurs et les technologies d'assistance d'aujourd'hui restituent le code.
Il convient de souligner que l'analyse syntaxique relève du principe de robustesse des WCAG. Le principe de robustesse vise à garantir la compatibilité du contenu web avec les différentes technologies et les dispositifs d'assistance. Cela implique l'utilisation de pratiques de codage et de développement web qui prennent en charge les fonctions d'accessibilité et peuvent être utilisées par une variété d'agents utilisateurs.
Cette question a fait l'objet de plusieurs débats et a donné lieu à des conversations animées (sans jeu de mots). Voici quelques-unes de mes réflexions à ce sujet :
- L'échec du Parsing empêche les organisations de prétendre à la conformité ; cependant, si cela n'a aucun impact dans le monde réel, est-ce une bonne utilisation du temps de quiconque ?
- Les WCAG 2.2 sont censés rester rétrocompatibles, mais il reste encore beaucoup de zones d'ombre sur la façon dont ils fonctionneraient pour les WCAG 2.1 et 2.0 et les normes anciennes utilisées par la loi et les instances dirigeantes au niveau international. Cette question n'est pas insoluble, mais elle doit faire l'objet d'une réflexion et d'une discussion plus approfondies. Le groupe de travail y réfléchit déjà, mais cela vaut la peine d'être mentionné jusqu'à ce qu'une solution soit trouvée.
- J'ai toujours utilisé l'analogie selon laquelle nous ne créons pas de nouvelles technologies, d'assistance ou autres, sur la base d'un code erroné (ou d'une soupe alphabétique comme j'aime à l'appeler), alors en perdant l'analyse syntaxique, sommes-nous en train d'abaisser la norme HTML dans son ensemble ?
- Sommes-nous en train de faire des suppositions sur le nombre d'utilisateurs de technologies de l'information qui maintiennent les navigateurs et leurs technologies de l'information à jour ? S'agit-il d'un exemple de focalisation excessive sur les statistiques nord-américaines ou européennes relatives à l'utilisation des technologies de l'information ?
Documents d'appui
Le groupe de travail continue à créer des techniques qui documenteront des exemples de suffisance et d'échec pour la série de directives WCAG 2, en mettant l'accent sur la création de techniques pour les nouveaux critères des WCAG 2.2. D'autres documents d'appui, notamment How to Meet WCAG 2.2 et WCAG 2.2, ont été publiés. Comprendre les WCAG 2.2sont disponibles pour examen dès à présent.
Versions futures
Enfin, il est peu probable qu'il y ait des WCAG 2.3 ; cependant, comme je l'ai appris il y a longtemps, il ne faut jamais dire jamais. Après la publication de la version 2.2, on s'attend à ce que la majorité des efforts du groupe de travail soient consacrés à une future version des lignes directrices sur l'accessibilité, comme les WCAG 3.0 ou Silver, comme on l'appelle encore dans certains cercles d'accessibilité. La version 3.0 sera un successeur important des directives WCAG et ne sera pas rétrocompatible. Toutefois, il faudra encore attendre des années, ce qui fait de la compréhension de la version 2.2 une priorité absolue pour l'instant et dans un avenir plus ou moins proche.
