Quoi de neuf dans le projet WCAG 2.2 ?

W3C- Web Accessibility Initiative - WAI. Strategies, standards, resources to make the Web accessible to people with disabilities

Chez Koena, l’un de nos outils quotidiens s’appelle WCAG. Ce sont les règles d’accessibilité web internationales sur lesquelles est construit le référentiel français RGAA. Une nouvelle version des WCAG devrait sortir en avril 2023. Nous vous proposons une traduction en français de l’article original publié sur le site de la Web Accessibility Initiative et intitulé « What’s New in WCAG 2.2 ». Article assez technique, plutôt pour personnes initiées…

Résumé

Cette page énumère les nouveaux critères de réussite proposés pour  les “Web Content Accessibility Guidelines (WCAG) 2.2.

Elle comprend des citations de personnes fictives pour vous aider à comprendre certains aspects des critères de réussite. Elle contient également des liens vers des documents de compréhension qui expliquent les critères de réussite en détail et fournissent d’autres exemples.

Introduction, calendrier, changements

Pour une introduction aux Web Content Accessibility Guidelines (WCAG) et pour en savoir plus sur les versions 2.0, 2.1 et 2.2, consultez la présentation des WCAG.

Il est prévu que les WCAG 2.2 soient achevés et publiés en avril 2023. Versions actuelles :

L’objectif principal de la « Recommandation Candidate » (RC) est de s’assurer que la norme peut être mise en œuvre. Elle est stable à ce stade ; cependant, elle pourrait évoluer en fonction des retours des contributeurs. Plus précisément, l’article 2.4.11 Apparence du Focus est « à risque » et pourrait ne pas être inclus dans la publication finale.

Pour en savoir plus sur la recommandation candidate et le processus de finalisation des WCAG 2.2, consultez la section Comment la WAI développe les normes d’accessibilité à travers le processus du W3C (en anglais).

Implémentations et commentaires

En janvier 2023, nous traitons les implémentations et les commentaires des publications de la Recommandation Candidate (RC). Nous sommes à la recherche d’implémentations supplémentaires de la norme 2.5.7 Déplacements par glissement. Vous pouvez partager vos implémentations en vous connectant à votre compte W3C et en utilisant le formulaire d’information sur les implémentations WCAG. Vous pouvez également envoyer un courriel aux coprésidents du groupe de travail sur les directives d’accessibilité et au personnel du W3C à l’adresse suivante : group-ag-chairs@w3.org.

Nous espérons que le contenu normatif des WCAG 2.2 n’a pas besoin d’être modifié. Nous continuerons à mettre à jour les documents de compréhension en fonction des commentaires. Pour commenter, veuillez ouvrir un nouveau sujet dans le dépôt GitHub WCAG. Créez des problèmes GitHub distincts pour chaque sujet, plutôt que de commenter plusieurs sujets dans un seul problème. S’il ne vous est pas possible d’utiliser GitHub, envoyez vos commentaires par courrier électronique à l’adresse suivante : public-agwg-comments@w3.org.

Changements de WCAG 2.1 à WCAG 2.2

Les critères de succès 2.0 et 2.1 sont exactement les mêmes (verbatim, mot à mot) en 2.2, à 2 exceptions près :

  • 2.4.7 Focus Visible est passé du niveau AA dans les WCAG 2.1 au niveau A dans les WCAG 2.2.
  • 4.1.1 Analyse syntaxique est obsolète et supprimé de WCAG 2.2. De plus amples informations sont disponibles dans la FAQ WCAG 2.

Le projet WCAG 2.2 fournit 9 critères de succès supplémentaires par rapport à WCAG 2.1. Ils sont inclus sur cette page.

Modifications apportées au projet 2.2

Les modifications apportées entre la RC de septembre 2022 et la RC de janvier 2023 sont les suivantes :

  • 2.5.8 Taille de la cible (minimale) : Modification des exceptions (“Espacement” et “En ligne”). Ajout d’une note sur les cibles “En ligne” et la hauteur de ligne.
  • 3.2.6 Aide cohérente : Modification de la première note.
  • 3.3.8 Authentification accessible : Modification de la première note.
  • 3.3.9 Authentification accessible (sans exception) : Renommé en Authentification Accessible (Améliorée).
  • 4.1.1 Analyse syntaxique : supprimée. Ajout d’une note expliquant pourquoi elle est obsolète. Plus d’informations sont disponibles dans la FAQ WCAG 2.

Les modifications précédentes sont listées dans le journal des modifications.

Ligne directrice 2.4 Navigable

Fournir des moyens d’aider les utilisateurs à naviguer, à trouver du contenu et à déterminer où il se trouve.

2.4.11 Apparence du focus (AA)

Un journaliste ayant des troubles musculo-squelettiques, qui n’utilise pas de souris et un retraité ayant une faible sensibilité aux contrastes :

Problème : “Je ne peux pas savoir où se trouve le focus du clavier lorsque je me déplace dans une page web ou une application.”
Cela fonctionne bien : ”Je peux voir où se trouve le focus du clavier lorsque je me déplace sur une page web ou une application.”

WCAG :

Lorsque l’indicateur de prise de focus clavier est visible, l’une des deux conditions suivantes ou les deux sont remplies :

  1. L’indicateur de prise de focus répond à toutes les conditions suivantes :
  2. La zone d’indicateur de prise de focus répond à toutes les conditions suivantes :
    • est au moins aussi grande que la zone d’un périmètre de 1 pixel CSS d’épaisseur du composant ou sous-composant non focusé, ou est au moins aussi grande qu’une ligne de 4 pixels CSS d’épaisseur le long du côté le plus court du composant non focusé, et
    • présente un rapport de contraste d’au moins 3:1 entre les mêmes pixels dans les états focusés et non focusés, et
    • présente un rapport de contraste d’au moins 3:1 entre les couleurs adjacentes de l’indicateur non focusé, ou n’est pas plus mince que 2 pixels CSS.

Exceptions :

  • L’indicateur de prise de focus est déterminé par l’agent utilisateur et ne peut pas être modifié par l’auteur ; ou
  • L’indicateur de prise de focus et la couleur d’arrière-plan de l’indicateur ne sont pas modifiés par l’auteur.

Remarque : Ce qui est perçu comme le composant ou le sous-composant de l’interface utilisateur (pour déterminer le contour ou la taille) dépend de sa présentation visuelle. La présentation visuelle comprend le contenu visible du composant, sa bordure et son arrière-plan spécifique. Elle ne comprend pas les effets d’ombre et d’éclat en dehors du contenu, de l’arrière-plan ou de la bordure du composant.

Remarque : Les éléments d’un menu déroulant ouvert ou les cellules focusées d’une grille sont des exemples de sous-composants pouvant recevoir le focus.

Remarque : Les calculs de contraste peuvent être basés sur les couleurs définies dans la technologie (comme HTML, CSS et SVG). Les pixels modifiés par les améliorations de résolution de l’agent utilisateur et l’anticrénelage peuvent être ignorés.

Note de l’éditeur : Ce critère de réussite est à risque.

Comprendre l’apparence du focus

2.4.12 Focus non masqué (minimum) (AA)

Un journaliste ayant des troubles musculo-squelettiques, utilise un logiciel de reconnaissance vocale :

Problème : “Cette page a une grande bannière qui est toujours en bas. Lorsque je déplace le focus sur des éléments, certains sont cachés derrière la bannière et je ne peux pas les voir.”

Cela fonctionne bien : “Lorsque je déplace le focus sur les éléments, je peux tous les voir.”

WCAG :

Lorsqu’un composant de l’interface utilisateur reçoit le focus clavier, le contenu créé par l’auteur ne cache pas le composant. 

Comprendre la notion de « Focus non masqué » (minimum)

2.4.13 Focus non masqué (Amélioré) (AAA)

Un journaliste ayant des troubles musculo squelettiques, utilise un logiciel de reconnaissance vocale :

Problème : “Cette page a une grande bannière qui est toujours en bas. Lorsque je déplace le focus sur des éléments, certains sont cachés derrière la bannière et je ne peux pas les voir.”

Cela fonctionne bien : “Lorsque je déplace le focus sur les éléments, je peux tous les voir”.

WCAG :

Lorsqu’un composant de l’interface utilisateur reçoit le focus clavier, le contenu créé par l’auteur ne cache pas l’indicateur de la prise de focus..

Comprendre l’indicateur de focus non masqué (Amélioré)

Ligne directrice 2.5 Modalités d’entrée

Facilitez la tâche des utilisateurs en leur permettant d’utiliser les fonctionnalités par le biais de divers dispositifs d’entrée en plus du clavier.

2.5.7 Mouvements de glissement (AA)

Un retraité ayant des tremblements de la main :

Problème : “Je ne peux pas maintenir le bouton de la souris enfoncé et le faire glisser avec suffisamment de précision pour déplacer les éléments de cette liste.”

Cela fonctionne bien : “Lorsque je clique sur un élément de la liste, j’obtiens des flèches vers le haut et vers le bas et je peux cliquer sur celles-ci pour changer l’ordre.”

WCAG :

Toutes les fonctionnalités qui utilisent un mouvement de glissement pour fonctionner peuvent être réalisées par un simple pointeur sans glissement, sauf si le glissement est essentiel ou si la fonctionnalité est déterminée par l’agent utilisateur et non modifiée par l’auteur.

Remarque : cette exigence s’applique au contenu Web qui interprète les actions du pointeur (c’est-à-dire qu’elle ne s’applique pas aux actions nécessaires au fonctionnement de l’agent utilisateur ou de la technologie d’assistance).

Comprendre les mouvements de glissement

2.5.8 Taille de la cible (minimum) (AA)

Un retraité ayant des tremblements de la main :

Problème : “Les boutons sont si proches les uns des autres que j’appuie sur « Annuler » alors que je voulais « Envoyer ». Je dois alors tout recommencer.”

Fonctionne bien : “Il y a plus d’espace entre les boutons pour que je n’appuie pas sur le mauvais bouton même lorsque je suis dans le bus cahoteux.”

WCAG :

La taille de la cible pour les pointeurs d’entrée est d’au moins 24 par 24 pixels CSS, sauf dans les cas suivants :

  • Espacement : La cible est au moins à 24 pixels CSS de chaque cible adjacente ;
  • Équivalence : La fonction peut être réalisée au moyen d’un autre contrôle sur la même page, dont la surface est d’au moins 24 par 24 pixels CSS ;
  • En ligne : La cible se trouve dans une phrase ou un bloc de texte ;
  • Contrôle de l’agent utilisateur : La taille de la cible est déterminée par l’agent utilisateur et n’est pas modifiée par l’auteur ;
  • Essentielle : Une présentation particulière de la cible est essentielle ou est légalement requise pour l’information transmise.

Remarque : les cibles qui permettent de sélectionner des valeurs dans l’espace en fonction de la position dans la cible sont considérées comme une seule cible aux fins du critère de succès. Il s’agit par exemple de curseurs avec des valeurs granulaires, de sélecteurs de couleurs affichant un gradient de couleurs ou de zones modifiables où vous positionnez le curseur.

Comprendre la taille de la cible (minimum)

Ligne directrice 3.2 Prévisible

Faites en sorte que les pages Web apparaissent et fonctionnent de manière prévisible.

3.2.6 Aide cohérente (A)

Un assistant de supermarché ayant des troubles cognitifs :

Problème : “Chaque fois que j’utilise l’application en ligne pour planifier mes rendez-vous médicaux, je n’arrive pas à me souvenir de ce qu’il faut faire à chaque étape. J’ai vu une option de “Chat” à certains endroits, mais je ne la trouve plus.”

Cela fonctionne bien : “Lorsque j’ai besoin d’aide, je trouve facilement l’option de “Chat” qui se trouve toujours dans le coin inférieur droit de la page.”

WCAG :

Si une page Web contient l’un des mécanismes d’aide suivants, et que ces mécanismes sont répétés sur plusieurs pages au sein d’un ensemble de pages Web, ils se présentent dans le même ordre relatif par rapport aux autres contenus de la page, à moins qu’un changement ne soit initié par l’utilisateur :

  • Coordonnées de contact humain ;
  • Mécanisme d’aide humaine;
  • Option d’auto-assistance ;
  • Un mécanisme d’aide entièrement automatisé.

Remarque : l’accès aux mécanismes d’aide peut être fourni directement sur la page, ou être fourni via un lien direct vers une autre page contenant les informations.

Remarque : pour ce critère de succès, le même ordre relatif peut être considéré comme la façon dont le contenu est ordonné lorsque la page est linéarisée. La position visuelle d’un mécanisme d’aide est susceptible d’être cohérente d’une page à l’autre pour une même variation de page (par exemple, point de rupture CSS). L’utilisateur peut initier un changement, par exemple en modifiant le zoom ou l’orientation de la page, ce qui peut déclencher un affichage différent. Ce critère concerne l’ordre relatif entre les pages affichées dans une même variation (par exemple, même niveau de zoom et même orientation).

Comprendre l’aide cohérente

Ligne directrice 3.3 Aide à la saisie

Aidez les utilisateurs à éviter et à corriger les erreurs.

3.3.7 Authentification accessible (AA)

Un assistant de supermarché ayant des troubles cognitifs :

Problème : “Je ne me souviens jamais de mon mot de passe, c’est vraiment difficile d’entrer dans cette application.”

Fonctionne bien : “Pour accéder à cette application, je peux indiquer mon adresse e-mail. Ensuite, je reçois un message électronique, et je peux cliquer sur un lien dans l’e-mail pour accéder à l’application.”

WCAG :

Un test de fonction cognitive (comme se souvenir d’un mot de passe ou résoudre un puzzle) n’est pas requis pour une étape quelconque d’un processus d’authentification, sauf si cette étape fournit au moins l’un des éléments suivants :

  • Alternative : Une autre méthode d’authentification qui ne repose pas sur un test de fonction cognitive.
  • Mécanisme : Un mécanisme est disponible pour aider l’utilisateur à réaliser le test de fonction cognitive.
  • Reconnaissance d’objets : Le test de fonction cognitive consiste à reconnaître des objets.
  • Contenu personnel : Le test des fonctions cognitives consiste à identifier le contenu non textuel que l’utilisateur a fourni au site Web.

Remarque : Les objets à reconnaître et le contenu fourni par l’utilisateur peuvent être représentés par des images, des vidéos ou du son.

Remarque : Voici des exemples de mécanismes qui satisfont à ce critère :

  1. la prise en charge de la saisie du mot de passe par des gestionnaires de mots de passe afin de réduire le besoin de mémoire
  2. le copier-coller pour réduire la charge cognitive de la ressaisie.

Comprendre l’authentification accessible

3.3.8 Authentification accessible (sans exception) (AAA)

Un assistant de supermarché ayant des troubles cognitifs :

Problème : “Je ne me souviens jamais de mon mot de passe, c’est vraiment difficile d’accéder à cette application.”

Fonctionne bien : “Pour accéder à cette application, je peux indiquer mon adresse e-mail. Ensuite, je reçois un message électronique, et je peux cliquer sur un lien dans l’e-mail pour accéder à l’application.”

WCAG :

Un test de fonction cognitive (comme se souvenir d’un mot de passe ou résoudre un puzzle) n’est pas requis pour une étape quelconque d’un processus d’authentification, sauf si cette étape fournit au moins l’un des éléments suivants :

  • Alternative : Une autre méthode d’authentification qui ne repose pas sur un test de fonction cognitive.
  • Mécanisme : Un mécanisme est disponible pour aider l’utilisateur à réaliser le test de fonction cognitive.

Comprendre l’authentification accessible (sans exception)

3.3.9 Saisie redondante (A)

Un assistant de supermarché ayant des troubles cognitifs :

Problème : “Chaque fois que j’utilise l’application en ligne pour prendre mes rendez-vous médicaux, je dois retaper certaines informations que j’ai saisies lors d’une étape précédente.”

Cela fonctionne bien : “L’application remplit automatiquement les informations que j’ai saisies lors des étapes précédentes.”  

WCAG :

Les informations précédemment saisies par l’utilisateur ou qui lui ont été fournies et qui doivent être saisies à nouveau au cours du même processus sont soit :

  • remplies automatiquement, ou
  • disponibles pour que l’utilisateur les sélectionne.

Sauf lorsque :

  • la ressaisie de l’information est essentielle,
  • l’information est nécessaire pour assurer la sécurité du contenu, ou
  • les informations saisies précédemment ne sont plus valables.

Comprendre la saisie redondante

À propos des citations des personnes fictives

Les liens présents sur le rôle des personnes fictives mènent vers les Histoires d’utilisateurs du Web. Cette page contient d’autres exemples d’utilisateurs avec des handicaps différents. Nous pourrions en ajouter d’autres à l’avenir.

Nous prévoyons d’ajouter des citations d’utilisateurs dans les documents « Understanding WCAG ».

Partager

Voir aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *