Bonjour à tous ! Je suis de retour pour vous parler plus en détail des WCAG 2.1 et de leur dernierprojet de travail daté du 7 décembre. Aujourd’hui, nous allons nous concentrer sur les dix nouveaux critères de succès liés à l’accessibilité sur les appareils mobiles. Lors de nos sessions précédentes, nous avons abordé en détail les questions de basse vision et de troubles cognitifs, mais il est désormais temps de nous plonger dans les critères de succès relatifs aux appareils mobiles.
N'hésitez pas à suivre la vidéo ci-dessous :
Critère de conformité 2.4.11 : Raccourcis clavier pour les caractères
Le premier critère concerne les raccourcis clavier composés de touches alphabétiques, proposés au niveau A. Si cette fonctionnalité n’est pas correctement mise en œuvre et qu’une personne tente d’utiliser la reconnaissance vocale, celle-ci risque de déclencher une action qu’elle ne souhaitait pas. La citation type à ce sujet est : « Oh non, ordinateur, ce n’est pas ce que je voulais que tu fasses ! » Le texte spécifique du critère de conformité (SC) à ce stade stipule : « Si un raccourci clavier se compose exclusivement d’une ou plusieurs touches de caractères et est implémenté dans le contenu, un mécanisme doit être disponible pour le désactiver ou le remapper vers un raccourci pouvant être utilisé avec au moins une touche autre qu’une touche de caractère. » Ce critère de conformité ne s’applique pas si le raccourci clavier d’un composant d’interface utilisateur n’est actif que lorsque ce composant a le focus. De manière générale, l’objectif de ce critère est de permettre aux personnes qui utilisent la reconnaissance vocale sur leurs appareils mobiles de s’en servir sans déclencher d’actions par erreur.
Critère de conformité 2.4.12 : Étiquette dans le nom
Le deuxième critère de succès concerne également la conversion de la parole en texte. Il s’intitule « label in name » ( nom de l’étiquette) et correspond à une exigence de niveau A dans la proposition. Imaginez que vous parliez à votre ordinateur – ce qui est très courant de nos jours – et que vous essayiez de valider un formulaire. Cependant, vous ne savez pas comment l’ordinateur souhaite que vous désigniez ce bouton de validation. La citation du persona à ce sujet est la suivante : « Ordinateur, valide le formulaire, ordinateur, juron. Pourquoi tu ne fais pas ce que je t’ai dit ? Pourquoi tu ne fais pas ce que je veux ? » Cela s’explique par le fait que les WCAG 2.0 ne contiennent aucune exigence précisant comment on doit verbalement demander à l’ordinateur d’effectuer une action. L’exigence relative au « nom de l’étiquette » stipule : « pour les composants d’interface utilisateur dont les étiquettes comprennent du texte ou des images représentant du texte, le nom doit contenir le texte affiché. » Nous connaîtrons ce nom car nous pouvons le voir à l’écran si nous voyons bien, ou bien une personne utilisant un lecteur d’écran pourra l’entendre, car cette étiquette correspondra à ce qu’elle entend.
Critère de conformité 2.5.1 : Gestes de pointage
Le critère de succès suivant porte sur les gestes du pointeur. La citation du personnage type pour celui-ci est : « Vous voulez que je fasse ce geste complexe avec la main ? Vous vous moquez de moi ? C’est quoi ça, les Jeux olympiques des doigts ? » Car si certains d’entre nous n’ont aucun mal à effectuer certains gestes de la main sur nos appareils mobiles ou tout autre appareil à écran tactile, cela peut s’avérer impossible à réaliser pour les personnes souffrant d’un handicap moteur. Ce nouveau critère de conformité « gestes du pointeur », recommandé dans les WCAG 2.1, vise donc à garantir que ces gestes soient accessibles à tous. Le libellé spécifique de ce critère est le suivant : « Toutes les fonctionnalités qui utilisent des gestes multipoints ou basés sur un tracé pour leur fonctionnement doivent pouvoir être utilisées avec un seul pointeur, sauf si ces gestes multipoints ou basés sur un tracé sont essentiels. » Il s’agit d’un critère de conformité très important qui comble une lacune des WCAG 2.1.
Critère de conformité 2.5.2 : Suppression des pointeurs
Le critère de succès suivant concerne également les pointeurs. L’annulation du pointeur est une proposition de niveau A unique. Imaginez que vous utilisiez votre appareil mobile — que vous souffriez ou non d’un handicap moteur — et que, tout à coup, alors que vous essayiez simplement d’effectuer une action, vous ayez accidentellement validé quelque chose. Vous essayiez simplement de vous déplacer ou d’explorer quelque chose à l’écran, mais vous avez accidentellement validé une action. L’annulation du pointeur vise à corriger ce genre de situations. La citation du personnage type pour ce critère est : « Bon sang, je ne voulais pas faire ça ! » Le texte du SC pour ce critère particulier est le suivant : « Pour les fonctionnalités pouvant être actionnées à l’aide d’un seul pointeur, au moins l’une des conditions suivantes doit être remplie : que cela ne se produise pas lors d’un événement de pression vers le bas, qu’il existe un moyen de l’annuler, et que le fait de faire glisser vers le haut inverse l’action, ou qu’il existe une exception essentielle. » Ce critère nous sera très utile à tous.
Critère de conformité 2.5.3 : Taille de la cible
Le critère suivant s'appelle « taille cible » ; il concerne les appareils mobiles et est classé dans la catégorie « AA » (recommandé). Vous est-il déjà arrivé d’utiliser votre appareil mobile et d’essayer d’appuyer sur un élément, mais qu’il soit si proche d’un autre que vous appuyez par erreur sur ce dernier ? C’est parce que parfois, les icônes actives à l’écran sont si petites qu’il est vraiment impossible d’y poser le doigt, ou qu’il est très difficile de viser précisément cet élément-là. La citation du persona à ce sujet est : « Mais qu’est-ce que c’est que ça ? Comment suis-je censé toucher quelque chose d’aussi petit ? Pour qui me prenez-vous ? Ant-Man ? Mes doigts sont de cette taille-là. » Les exigences relatives à ce critère de succès sont les suivantes : « La taille de la cible pour les entrées au pointeur est d’au moins 44 × 22 pixels CSS, sauf s’il existe un équivalent. » En d’autres termes, il existe un autre moyen de le faire ailleurs sur l’écran, avec une zone plus grande, ou bien cette solution a été fournie par l’agent utilisateur. Ce critère de succès sera apprécié par chacun d’entre nous lorsque nous utilisons nos appareils mobiles. Il exigera que l’on puisse réellement toucher un élément avec le doigt et déclencher l’action souhaitée.
Critère de conformité 2.5.4 : Amélioration de la taille des éléments cibles
La « taille de la cible », critère de succès mentionné ci-dessus, dispose d’une version AAA appelée « taille de la cible améliorée ». En substance, il s’agit du même concept, mais au lieu que la taille de la cible pour les entrées au pointeur soit de 22 × 44 pixels CSS, ne serait-ce pas formidable qu’elle soit de 44 × 44 pixels CSS ? En résumé, cette exigence augmente la dimension de 44 dans les deux sens. Tout ce que vous voyez classé en niveau AAA correspond à une bonne pratique.
Critère de conformité 2.5.5 : Mécanismes de saisie simultanée
Le prochain SC, intitulé « Mécanismes de saisie simultanée », est en cours d’élaboration au niveau AAA. Ce SC concerne les situations où, lorsque vous utilisez un appareil mobile ou un ordinateur portable, vous souhaitez passer d’un périphérique de saisie à un autre. En d’autres termes, vous souhaitez passer de l’écran tactile à la commande vocale ou ajouter un clavier au milieu d’un flux de travail. Le critère de conformité « mécanismes de saisie simultanés » vise à résoudre ce problème. La citation du persona pour ce critère est la suivante : « Permettez-moi de passer d’un périphérique de saisie à l’autre selon mes besoins. » Le libellé spécifique de la norme relative aux mécanismes de saisie simultanée est le suivant : « Le contenu Web ne restreint pas l’utilisation des modalités de saisie disponibles sur une plateforme, sauf lorsque cette restriction est essentielle, nécessaire pour garantir la sécurité du contenu ou requise pour respecter les paramètres de l’utilisateur. » Même s’il s’agit d’une exigence de niveau AAA, c’est un aspect auquel nous devons prêter attention lorsque nous nous soucions de l’ergonomie de nos sites, car il s’agit d’une excellente bonne pratique.
Critère de conformité 2.6.1 :Déclenchement par mouvement
Le critère de succès suivant concerne l’activation par mouvement et se situe au niveau A. Il a été difficile de trouver la formulation adéquate. Ce critère exige que l’utilisateur n’ait pas à incliner ni à secouer l’appareil. Il vise la réalité augmentée et la réalité virtuelle. Il s’agit de garantir que, à mesure que nous évoluons vers ces domaines, ils soient pleinement accessibles à tous. La citation du personnage type est : « S’il vous plaît, ne m’obligez pas à incliner ou à secouer l’appareil. J’aurai peut-être besoin d’effectuer cette action d’une autre manière. À l’aide d’un clavier, par la voix. Donnez-moi d’autres options. » Le texte spécifique de cette exigence de conformité est le suivant : « Les fonctionnalités pouvant être activées par le mouvement de l’appareil ou de l’utilisateur doivent également pouvoir être activées via des composants de l’interface utilisateur et pouvoir être désactivées pour empêcher toute activation accidentelle, sauf si cela est nécessaire pour l’accessibilité ou si cela est essentiel. » À l’heure actuelle, il est important de veiller à ce que l’on puisse empêcher toute activation accidentelle par inclinaison ou secousse, ou de permettre à chacun d’activer ces fonctionnalités potentielles.
Critère de conformité 2.6.2 : Orientation
Le critère suivant s’intitule « orientation » et relève du niveau d’exigence AA. Il est essentiel de ne pas obliger une personne à utiliser son appareil dans une orientation particulière, qu’il s’agisse du mode portrait, paysage, etc. La citation du persona pour ce critère est : « Ne m’obligez pas à faire pivoter mon appareil mobile. » Pourquoi est-ce important ? Imaginez que vous soyez une personne souffrant d’un handicap moteur, peut-être en fauteuil roulant, et que vous disposiez d’un appareil mobile très précieux et utile fixé à votre fauteuil. Cet appareil est fixé dans une orientation donnée et ne peut pas être déplacé. Le texte du critère d’évaluation concernant l’orientation est le suivant : « Le contenu ne limite pas son affichage et son fonctionnement à une seule orientation d’écran, telle que le mode portrait ou paysage, sauf si une orientation d’écran spécifique est indispensable. » Si vous avez une très bonne raison d’exiger qu’un appareil soit en mode portrait ou paysage, ne vous inquiétez pas, vous bénéficierez de l’exception essentielle. Cependant, veuillez ne pas restreindre cette fonctionnalité dans les autres cas.
Critère de conformité 3.2.6 :Changements d'état
Le dernier critère de conformité (SC) pour les appareils mobiles s’intitule « Changements d’état » et il est proposé de lui attribuer le niveau AA. La citation de mon persona est simplement : « Je ne sais pas si quelque chose s’est passé. » Si vous utilisez un lecteur d’écran et qu’un changement est intervenu à l’écran, il est parfois difficile de s’en rendre compte. Parfois, le lecteur d’écran n’a pas reçu cette information supplémentaire qu’une personne capable de voir l’écran a pu percevoir. Par exemple, lorsqu’un message contextuel apparaît à l’écran. Les utilisateurs de lecteurs d’écran et les personnes présentant un handicap cognitif peuvent ne pas avoir pris conscience de cet élément particulier. Même une personne sans handicap peut l’avoir manqué, simplement parce qu’il était difficile à voir. Mais pour les personnes présentant un handicap visuel ou cognitif, cela constitue un obstacle majeur.
Le texte des Critères de succès (SC) pour ce point précis est le suivant : « Dans les contenus mis en œuvre à l’aide de langages de balisage, les messages d’état peuvent être déterminés par programmation via un rôle ou des propriétés, de sorte qu’ils puissent être présentés à l’utilisateur par une technologie d’assistance sans recevoir le focus. » Je pense que ce sera là un autre point à aborder plus en détail ultérieurement, car beaucoup de gens considèrent peut-être déjà cela comme une lacune des WCAG 2.0, alors qu’il ne s’agit pas d’une lacune du langage normatif, mais malheureusement des WCAG 2.0 elles-mêmes. Cela s’inscrit certes dans l’esprit des WCAG 2.0, mais les WCAG 2.1 ont pour but de combler cette lacune et de garantir que nous puissions qualifier cela de lacune dans les WCAG 2.1.
Conclusion
Nous avons abordé les critères de succès relatifs à la basse vision, aux fonctions cognitives et aux appareils mobiles. N’oubliez pas qu’il y a au total 20 nouvelles propositions à l’étude. Le groupe de travail WCAG vise une date butoir fin janvier, date à laquelle nous pourrions voir apparaître une « recommandation candidate », qui est une version plus formelle des WCAG 2.1. Restez à l’écoute pour plus d’informations ! Nous avons également hâte de vous présenter plus en détail « Silver », cette mise à jour majeure qui porte sur les directives d’accessibilité à plus long terme. Un grand merci de nous accompagner dans cette aventure.
