Bonne nouvelle, l’heure du WCAG 2.2 a sonné. Cela ne change pas la cohérence du standard du WCAG 2.1, mais ajoute quelques informations essentielles.
Cet article fait suite à notre précédent article de 2021, dont certains éléments seront donc repris, et mis à jour.
Nous allons analyser ensemble les nouveaux critères et ce qui doit être retenu et compris.
Commençons par les critères A (simple A) :
3.2.6 Cohérence de l'aide
Le critère : pour une page web ou un ensemble de pages qui présente une aide à l’utilisateur, cette aide ou l’accès à celle-ci doit être positionnée de façon cohérente et être placé au même endroit. Les mécanismes d’aide possible sont les suivants :
- Les coordonnées de contacts (téléphone, email, heures d’ouverture du service) ;
- Un dispositif de contact comme un système de messagerie, chat, formulaire de contact, réseaux sociaux ;
- Une FAQ, page support ou mécanisme équivalent ;
- Un mécanisme de contact complètement automatisé comme un chatbot.
L’accès à ces mécanismes pourra être directement intégré sur chacune des pages du site web ou bien via un lien à la page qui contient cette information.
Commentaire : ce critère doit permettre aux utilisateurs de retrouver facilement l’aide quelle que soit la page du site consulté.
L’aide est un élément essentiel pour toute personne sur un site internet. Rendre cohérent le positionnement et l’accès aux aides est un principe de conception à adopter au-delà du numérique accessible. L’ajout de ce critère est un gage d’amélioration des interfaces et d’amélioration de l’expérience utilisateur.
Remarque : ce critère ne demande pas qu’un support soit proposé. Il demande que lorsque l’aide est disponible, celle-ci soit disponible de la même manière sur chaque page.
3.3.7 Entrées redondantes
Le critère : les informations précédemment saisies ou fournies par l’utilisateur ne doivent pas être saisies une nouvelle fois pour le même processus ou dans la même session utilisateur.
Ces informations sont alors :
- Soit automatiquement remplies
- Soit sélectionnables par l’utilisateur.
Ce critère ne s’applique pas lorsque :
- La ressaisie des informations est indispensable
- Les informations sont nécessaires pour assurer la sécurité du contenu (exemple : accès à son compte bancaire)
- Les informations entrées précédemment ne sont plus valides.
Commentaire : outre la plus-value concernant l’accessibilité, ce critère diminue la charge mentale de n’importe quel utilisateur dans le remplissage de formulaires, par exemple. L’expérience utilisateur se voit donc améliorée pour tous. Le respect de ce critère facilite également grandement lors du remplissage des formulaires sur mobiles ou la saisie est plus difficile.
Les critères AA (double A) :
2.4.11 Apparence du focus - Visibilité du focus
Le critère : S’assurer que le focus du composant actif est bien partiellement contrasté.
Commentaire : La création de composants « sticky » (fixes) comme une bannière, des éléments en side-panel (panneaux latéraux) peut provoquer une perte du focus lors de la navigation utilisant le clavier. Par ailleurs, beaucoup de sites utilisent ce type de composants. Il est donc nécessaire de traiter ces cas-là dans ce critère. Attention à la superposition de modales type cookies, qui peuvent obstruer le focus du composant qui est en arrière-plan !
2.5.7 Mouvement de glissement
Le critère : toutes les fonctionnalités nécessitant un mouvement de glissement pour réaliser une action doivent pouvoir être réalisées également sans glisser et par un seul pointeur. Ce critère n’est pas valable si le mouvement est indispensable à la réalisation de l’action.
Commentaire : sur des sites qui jouent beaucoup sur l’interactivité, le glissé-déposé est souvent employé sans alternative. C’est une bonne résolution que de demander une alternative fonctionnelle au glissé-déposé, très présent dans les habitudes des utilisateurs. Ce critère est également axé sur l’usage au clavier.
La prise en compte de ce critère demande un changement conséquent des habitudes de conception en intégrant comme élément de spécification, la navigation clavier au même titre que la navigation à la souris ou tactile.
Remarque : Attention à faire la différence entre le Dragging (glissement) et le pointure gesture (action dépendant de suivre un chemin précis).
Le pointure gesture inclut le swipe, le mouvement des sliders, et les carrousels… Tout ce dont une action bien précise doit être réalisée. A contrario du glissement où le chemin n’est pas spécifié en particulier.
2.5.8 Taille des éléments cliquables
Le critère : les cibles ont une superficie d'au moins 24 x 24 pixels CSS, sauf dans les cas suivants :
- La taille de l’élément ajouter et l’écart entre les élément cibles adjacentes fait au moins 24 pixels CSS ;
- L’élément cible est dans une phrase ou un bloc de texte ;
- Une présentation particulière de l’élément cible est essentielle à l'information véhiculée.
Commentaire : ce critère, souvent recommandé, est désormais inscrit dans la mise à jour du WCAG 2.2. Auparavant, seul le critère triple A (AAA) 2.5.5 Taille cible (améliorée) existait. Ce nouveau critère permet de donner un niveau supplémentaire pour l’intégration de recommandations à destination des personnes ayant des difficultés dans l’atteinte des cibles trop petites.
Le respect de ce critère doit permettre aux utilisateurs d’activer facilement une zone sans activer accidentellement une zone adjacente.
3.3.8 Authentification accessible
Le critère : pour chaque étape d'un processus d'authentification qui repose sur un test cognitif, au moins un mécanisme est disponible pour aider l'utilisateur à effectuer le test.
Les éléments conformes proposées au test cognitif sont :
- Un moyen non cognitif:
Un autre moyen d’authentification ne nécessitant pas un test cognitif.
- Un Mécanisme
Un mécanisme est disponible afin d’aider la personne à réaliser le test cognitif. Exemple : Autorisation d’utiliser le copié/collé d’un logiciel de se sauvegarde de mots de passe.
- Reconnaissance d’objets
Il faut ici réaliser un test de reconnaissances d’objet : vidéos, sons, images.
- Contenu non-textuel
Identifier des contenus non-textuels sur l’interface : images, sons, vidéos.
Pour information, un test cognitif est une tâche qui requiert une mémorisation, une manipulation ou une transcription d’information de la part de l’utilisateur.
Ex : faire un calcul mathématique pour vérifier son identité, transcrire un texte…
Une alternative peut donc être de faire un copier-coller pour les transcriptions.
Commentaire : sur une majorité de site, les authentifications demandées ne sont pas accessibles à une partie de la population et bloquent tout simplement l’usage même du site. L’absence de prise en compte de l’accessibilité est donc critique pour les utilisateurs en situation de handicap. On peut noter, par exemple, les CAPTCHA visuels qui ne sont pas accessibles aux personnes malvoyantes ou aveugles, utilisant un lecteur d’écran, aucune alternative à ces méthodes d'authentification n'est proposée. Vous pouvez regarder cette vidéo de test cognitif, très récent, qui montre un manque d’alternative et un manque d’inclusivité sur la plateforme HBO Max (En anglais).
Lors de la mise en œuvre de ce genre d’authentification, la réflexion autour de la présence d'alternatives doit devenir un réflexe et une obligation dans tout projet, et s’inscrit complètement dans une étude UX (Expérience Utilisateur).
Pour les critères AAA (Triple A) :
2.4.12 Apparence du focus - Apparence du focus Obscurci (Amélioré)
Le critère : Ici une attention particulière est intégrée au critère 2.4.11 où la totalité du focus doit être visible.
Commentaire : Dans ce cadre, aucune exception n’est possible. L’intégralité du focus doit être visible, que ce soit pour les composants sticky, panneaux latéraux…
2.4.13 Apparence du focus - Apparence du focus (Amélioré)
Le critère : Ici, nous allons plus loin sur le critère de couleur et de taille du focus :
Il faut que quand le focus du clavier est visible :
- le rapport de contraste entre les couleurs de l’état focussé et non focussé est de 3 :1 minimum ET,
- que le focus soit au minimum plus large qu’une zone de 2 CSS px autour du composant non focussé or du sous-composant associé (exemple : un menu/et un sous menu).
Commentaire : Ici, intégrer un focus qui a 2 CSS px de large est suffisant. Cela est nécessaire pour les personnes malvoyantes, par exemple, pour identifier plus facilement les éléments focussés sur l’interface. Attention, cependant, à intégrer une couleur de focus qui soit pertinente par rapport aux standards (contraste de couleur minimum de 3.0 entre le focus et l’arrière-plan). Les deux conditions sont obligatoires.
3.3.9 Authentification accessible (Amélioré)
Le critère : Ici, par rapport au critère 3.3.8. Les seuls moyens d’authentifications recommandés sont :
- Un moyen non cognitif:
Another authentication method that does not rely on a cognitive function test.
- Un Mécanisme
Un mécanisme est disponible afin d’aider la personne à réaliser le test cognitif. Exemple : Autorisation d’utiliser le copié/collé d’un logiciel de se sauvegarde de mots de passe.
Commentaire : En complément du commentaire sur le critère AA, ici, nous nous basons uniquement sur de réelles alternatives à un test cognitif, qui réduirait considérablement la charge mentale des utilisateurs d’une interface.
Il est donc pertinent de sensibiliser les acteurs projets sur ces alternatives dès le début de la conception, car plus faciles à mettre en place que des systèmes de reconnaissances.
