C'est presque prêt ! Les WCAG 2.2 ne sont plus qu'à un petit pas de leur finalisation officielle !

Une nouvelle version des Directives pour l'accessibilité des contenus Web (WCAG) est sur le point d'être publiée. La version WCAG 2.2 devrait être finalisée en août 2023. Il s'agit d'une mise à jour mineure. Si vous connaissez déjà les versions WCAG 2.0 et/ou 2.1, vous vous posez sans doute un certain nombre de questions. Et nous avons les réponses les plus récentes !

• Pourquoi la norme WCAG 2.2 n’est-elle pas encore prête ? Pourquoi cela prend-il autant de temps ? Selon le calendrier du W3C, la version finale de la norme WCAG 2.2 devait être publiée le 31 août 2023. Pourquoi n’est-elle toujours pas prête ? Parce que la mise à jour de la norme mondiale d’accessibilité (même s’il s’agit d’une mise à jour « mineure ») est un processus complexe qui nécessite des travaux de recherche, des tests, des révisions et des votes de consensus.
• La norme WCAG 2.2 sera-t-elle rétrocompatible avec les normes WCAG 2.1 et 2.0 ?
  • En grande partie, oui !
    • Les normes WCAG 2.0 et WCAG 2.1 restent d'actualité et sont très utiles. La version WCAG 2.2 ajoutera 9 nouvelles exigences à celles déjà présentes dans les versions WCAG 2.1 et WCAG 2.0.
    • Pour la première fois dans l'histoire des WCAG :
      • Il est prévu de supprimer une exigence
        • 1.1 Le critère « Analyse syntaxique » est supprimé dans les WCAG 2.2. Pourquoi ? Parce que le critère 4.1.1 « Analyse syntaxique » avait été initialement adopté pour résoudre les problèmes que rencontraient les technologies d'assistance lors de l'analyse directe du code HTML. Or, ces technologies n'ont désormais plus besoin d'analyser directement le code HTML. Les problèmes d'analyse syntaxique ont donc soit disparu, soit sont désormais traités par d'autres critères. Ce critère n'ayant plus d'utilité, il est supprimé.
        • Bien que la règle 4.1.1 soit maintenue dans les versions 2.1 et 2.0 des WCAG, une note sera ajoutée afin de préciser que toute page créée en HTML est automatiquement conforme à cette règle.
          • Voir le demande de fusion concernant le nouveau projet de note de la section 4.1.1 « Analyse syntaxique » dans les versions 2.1 et 2.0 des WCAG :
            • « Ce critère de succès doit être considéré comme automatiquement satisfait pour tout contenu utilisant le langage HTML. Les navigateurs modernes disposent tous d’une correction automatique des erreurs d’analyse syntaxique, et les problèmes tels que les états ou les noms incorrects dus à un identifiant en double, ou les rôles manquants dus à des éléments imbriqués de manière inappropriée, sont couverts par d’autres critères de succès. Ce critère peut donc être ignoré car il est redondant. Il n’apporte plus en soi aucun bénéfice aux personnes en situation de handicap et ne doit pas être imposé ni exigé au titre de l’accessibilité. »
          • Pour rappel, tant que cette demande de modification n'aura pas été entièrement approuvée et intégrée, tout ce qu'elle contient est susceptible d'être modifié.
• La version 2.2 des WCAG continuera-t-elle à utiliser les niveaux de conformité A, AA et AAA des versions 2.1 et 2.0 des WCAG ? La version 2.2 des WCAG continuera à utiliser les mêmes niveaux de conformité A, AA et AAA.
• Les WCAG 2.2 sont-elles prêtes à être utilisées dès aujourd’hui par le grand public ? Presque ! Les WCAG 2.2 sont si proches de leur version définitive qu’il ne devrait plus y avoir de changements majeurs à ce stade. Mais rien n’est définitif tant que ce n’est pas terminé.
• Les passionnés d'accessibilité sont-ils prêts à explorer dès aujourd'hui les WCAG 2.2 ? Oui ! C'est le moment idéal pour les passionnés d'accessibilité de se familiariser avec les nouveaux critères de succès proposés pour les WCAG 2.2. Pourquoi ? Cela vous permettra de prendre une longueur d'avance pour déterminer l'impact de ces nouvelles exigences sur votre contenu numérique.
• Quand les WCAG 2.2 deviendront-elles une obligation légale ? Certains pays pourraient commencer à envisager d’adopter les WCAG 2.2 une fois qu’elles seront devenues une recommandation officielle définitive. N’oubliez pas que les WCAG 2.2 ne sont pas encore définitives et ne le seront pas avant fin août 2023 au plus tôt. Soyez assurés qu'aucun pays ne fera des WCAG 2.2 une obligation légale avant qu'elles ne soient définitives (et certains pays pourraient mettre des années à adopter la dernière version des WCAG).
• Combien d'étapes reste-t-il avant que la norme WCAG 2.2 ne soit définitivement adoptée ? Il ne reste plus qu'une seule étape d'approbation. Pour plus de détails, consultez l'explication du processus à la fin de cet article.

Qu'est-ce que les WCAG ?

Les Directives pour l'accessibilité des contenus Web (WCAG) constituent depuis plus de deux décennies la norme en matière d'accessibilité numérique à l'échelle mondiale. Le W3C espère publier la version 2.2 des WCAG avant la fin du mois d'août 2023. La version 2.2 des WCAG introduira plusieurs nouveaux critères de conformité visant à élargir les exigences pour les utilisateurs malvoyants, présentant des troubles cognitifs ou ayant des capacités motrices fines limitées.

Respecter les nouveaux critères de réussite proposés

La proposition WCAG 2.2 comporte actuellement neuf nouveaux critères de conformité. La liste des nouveaux critères de conformité, telle qu'elle figure dans la version de « recommandation proposée » publiée le 20 juillet 2023, est la suivante :

1. 1. 4.11 Mise au point non masquée (minimum) (niveau AA)
   2. 4.12 Mise au point non masquée (améliorée) (niveau AAA)
   3. 4.13 Apparence de « Focus » (niveau AAA)
   4. 5.7 Mouvements de glissement (niveau AA)
   5. 5.8 Taille de la cible (minimale) (niveau AA)
   6. 2.6 Aide cohérente (niveau A)
   7. 3.7 Entrée redondante (niveau A)
   8. 3.8 Authentification accessible (minimum) (niveau AA)
   9. 3.9 Authentification accessible (améliorée) (niveau AAA)

Une vision claire

Citation du personnage : « Hé, arrête de masquer le focus de mon clavier ! »

Ces deux critères de conformité aideront les utilisateurs voyants qui utilisent le clavier pour naviguer sur une page Web, en garantissant que le composant et son indicateur de focus ne soient pas masqués par d’autres contenus. Par exemple, les en-têtes fixes, les fenêtres contextuelles relatives aux cookies et les boîtes de dialogue non modales peuvent recouvrir la partie de la page sur laquelle se trouve actuellement le focus du clavier. L’exigence de niveau AA stipule qu’au moins une partie de l’élément ayant le focus doit être visible. Au niveau AAA, l’intégralité du composant et de son indicateur de focus doit être visible.

Focus : Apparence

Citation du personnage : « Mais où donc est le curseur de mon clavier ? »

Ce critère de succès AAA exigera la présence d’un « indicateur de focus » clairement visible, indiquant l’emplacement actuel du focus du clavier. Les utilisateurs voyants qui utilisent le clavier pour naviguer sur une page Web pourront ainsi déterminer visuellement où se trouve le focus de leur clavier. Cette exigence va au-delà de l'exigence 2.4.7 « Focus visible » existante, dans la mesure où elle définit une taille minimale pour l'indicateur de focus ainsi qu'un contraste minimal de 3:1. Elle va également au-delà de l'exigence 1.4.11 « Contraste des éléments non textuels » existante, en imposant une taille minimale pour l'indicateur de focus ainsi qu'un contraste minimal entre l'état « focus » et l'état « non focus ».

Petite parenthèse : il convient de noter qu’à un moment donné, la spécification 2.4.13 « Focus Appearance » avait été proposée au niveau AA, mais qu’elle avait été classée « à risque » en raison des inquiétudes exprimées par l’ensemble des parties prenantes. À l’heure actuelle, la spécification 2.4.13 « Focus Appearance » a été reclassée au niveau AAA.

Mouvements de glissement

Citation du personnage : « Euhhhhh ! Je n'arrive pas à faire ce glisser-déposer ! Il me faut une autre solution pour y arriver !!! »

Les actions de glisser-déposer exigent un geste assez précis et la capacité de maintenir la pression sur le bouton de la souris ou l'écran tactile sans le relâcher accidentellement. Cela peut s'avérer difficile pour certaines personnes souffrant de troubles moteurs. C'est pourquoi ce nouveau critère de conformité exige que le glisser-déposer ne soit pas le seul moyen d'effectuer une action à l'aide d'un seul pointeur (tel qu'une souris ou un doigt).

Taille cible (minimale)

Citation du personnage : « Il me faut des boutons assez gros pour que je puisse appuyer sur le bon ! »

L'activation d'un petit bouton sur un écran tactile représente un défi pour de nombreuses personnes, mais surtout pour celles qui ont des difficultés au niveau de la motricité fine des mains. Cela vaut également pour l'utilisation de la souris ou de tout autre dispositif de pointage. Ce critère de conformité définit la distance minimale que doivent respecter deux éléments interactifs l'un par rapport à l'autre afin de réduire le risque que l'utilisateur active accidentellement le mauvais élément. Ce nouveau critère de succès 2.5.8 « Taille de la cible (minimum) » nous donnera une exigence de niveau AA basée sur 24 pixels CSS. Vous pouvez également continuer à utiliser l’exigence 2.5.5 « Taille de la cible (améliorée) » basée sur 44 pixels CSS, qui a été ajoutée dans les WCAG 2.1 au niveau AAA.

Une aide cohérente

Citation d'un personnage : « Au secours ! Je ne trouve pas comment obtenir de l'aide sur ce site web ! »

Ce critère de succès permet aux utilisateurs qui ont besoin d'aide de la trouver plus facilement. Cette exigence stipule que lorsqu'une fonctionnalité d'aide (telle que des coordonnées ou une option d'auto-assistance) est disponible sur plusieurs pages d'un site web, elle doit apparaître au même emplacement relatif sur chacune des pages où elle figure. Cette exigence permettra à certaines personnes présentant des troubles cognitifs d'obtenir l'aide dont elles ont besoin pour mener à bien la tâche qu'elles souhaitent accomplir.

Entrée redondante

Citation du personnage : « Ne m'oblige pas à saisir, ne m'oblige pas à saisir deux fois les mêmes informations, deux fois les mêmes informations. »

Certains formulaires exigent que l'utilisateur saisisse plusieurs fois les mêmes informations, par exemple une adresse de livraison et une adresse de facturation. Remplir des formulaires comportant des informations redondantes peut s'avérer pénible pour certains utilisateurs, en particulier ceux souffrant d'un handicap moteur ou cognitif. Ce critère de conformité exige que les formulaires évitent les saisies redondantes ou facilitent la réutilisation des données déjà saisies.

Authentification accessible

Citation de Pesona : « Je suis dyslexique. Saisir manuellement les codes d’authentification à deux facteurs est très difficile, voire parfois impossible pour moi. Quand je peux copier le code envoyé sur mon téléphone portable et le coller (au lieu de le saisir à la main), ou mieux encore, simplement appuyer sur le code affiché sur mon téléphone, je parviens à me connecter ! »

Se connecter à un site web ou à une application peut s'avérer difficile. Il arrive que les utilisateurs oublient leur mot de passe, et la saisie manuelle des codes d'authentification envoyés sur leur téléphone peut être source d'erreurs. Ce critère de conformité exige que l'authentification soit possible sans recourir à de tels « tests cognitifs », par exemple en permettant aux utilisateurs de copier-coller leur mot de passe à partir d'un gestionnaire de mots de passe tiers. Cette exigence aidera les personnes souffrant de troubles moteurs ou de troubles cognitifs, notamment des troubles de la mémoire, de la dyslexie, de la dyscalculie, etc.

Et maintenant ?

Le W3C prévoit de publier la version officielle définitive des WCAG 2.2 avant la fin du mois d'août 2023. Il reste toutefois à mener à bien un vote d'approbation final et à respecter la procédure correspondante. Il est difficile de prédire avec précision à quel moment le vote d'approbation par consensus sera obtenu au sein du W3C concernant cette importante norme internationale.

Nous vous informerons dès que la version 2.2 des WCAG sera effectivement finalisée et stable, dès que nous aurons la certitude de la date de publication officielle.

En règle générale, Deque ajoute la prise en charge d’une nouvelle version des WCAG dans le mois qui suit l’obtention par la nouvelle norme du statut définitif de « RECOMMANDATION ». Toutefois, si le W3C procède à des révisions de dernière minute nécessitant des modifications du système, ce délai peut aller jusqu’à un trimestre. En interne, Deque se prépare depuis des mois à la mise en œuvre des WCAG 2.2. Nous avons même proposé https://dequeuniversity.com/ comme preuve de mise en œuvre démontrant qu’il est réellement possible de respecter les niveaux A et AA des WCAG 2.2. axe-core a une longueur d’avance, puisqu’il propose déjà une nouvelle règle WCAG 2.2 depuis l’automne 2022. Nous prévoyons également d’ajouter de nouvelles règles pour les WCAG 2.2 dans les tests guidés intelligents d’axe DevTools.

*Informations supplémentaires pour les passionnés de processus d'accessibilité

Poursuivez votre lecture si vous souhaitez connaître dans les moindres détails comment une recommandation de candidat devient une recommandation officielle/définitive.

Examinons les cinq grandes étapes ainsi que certaines des activités importantes à mener à chacune des étapes restantes :

1. 1. Premier projet de travail public (FPWD) publié
      • Il FAUT encourager une révision précoce et à grande échelle.
   2. Projet(s) de travail public révisé(s) (WD) publier zéro ou plusieurs
      • Nous pourrions publier d'autres versions préliminaires en fonction des commentaires reçus.
   3. Recommandation de candidat (CR) anciennement connu sous le nom de « Last Call Working Draft »
      • doit indiquer comment sera démontrée l'expérience suffisante en matière de mise en œuvre,
      • doit préciser la date limite de soumission des commentaires, qui doit être fixée au moins 28 jours après la publication, et devrait être plus longue pour les documents complexes,
      • doit démontrer que le cahier des charges a fait l'objet d'un examen approfondi, et
      • peut identifier certaines fonctionnalités du document comme « à risque ». Ces fonctionnalités peuvent être supprimées avant le passage au stade de « recommandation proposée », sans qu'il soit nécessaire de publier une nouvelle « recommandation candidate ».
   4. VOUS ÊTES ICI ! Proposition de recommandation (PR) demande d'examen – Demande officielle visant à obtenir l'approbation de la norme technique par le Comité consultatif du W3C.
      • doit intervenir au moins 28 jours après la publication du projet de recommandation et…
      • doit justifier d'une expérience suffisante en matière de mise en œuvre, sauf si une dérogation est accordée par le directeur,
      • doit démontrer que le document a fait l'objet d'un examen approfondi,
      • doit démontrer que toutes les questions soulevées au cours de la période d'examen de la recommandation de candidature, à l'exception de celles soulevées par les représentants du Comité consultatif agissant dans le cadre de leur fonction officielle de représentant du CC, ont été officiellement traitées,
      • doit recenser toutes les questions de fond soulevées depuis la clôture de la période d'examen de la recommandation de candidature par des parties autres que les représentants du Comité consultatif agissant dans le cadre de leur fonction officielle de représentant du CC,
      • a peut-être supprimé des fonctionnalités identifiées dans le document de recommandation candidate comme étant « à risque » sans republier la spécification sous la forme d'une recommandation candidate.
   5. Recommandation du W3C (REC) publié
      • La décision de faire passer un document au stade de « Recommandation » relève du W3C.
      • La norme a atteint sa pleine maturité. Il s'agit d'une recommandation officielle du W3C.