Accessibilité Web et Normes WCAG

WCAG 2.1 est organisé autour de quatre principes, mémorisés par l'acronyme POUR. Perceptible : les utilisateurs doivent pouvoir percevoir toutes les informations et les composants de l'interface utilisateur (UI) par au moins un sens. Exigences : toutes les images ont un texte alternatif descriptif ; tout le contenu vidéo a des sous-titres ; la couleur n'est pas le seul moyen de transmettre des informations (par exemple, les états d'erreur utilisent du texte ou des icônes en plus de la couleur rouge) ; le texte maintient un contraste de couleur suffisant par rapport à son arrière-plan (rapport 4,5:1 pour le texte normal ; 3:1 pour le texte grand à la conformité AA). Utilisable : toutes les fonctionnalités doivent être utilisables uniquement au clavier (les utilisateurs ayant des handicaps moteurs qui ne peuvent pas utiliser une souris doivent pouvoir naviguer, activer et compléter tous les flux de travail en utilisant Tab, Entrée, les touches fléchées et Échap). Exigences : les états de focus sont clairement visibles ; pas de pièges au clavier (l'utilisateur peut toujours sortir de n'importe quel élément de l'interface utilisateur) ; liens de saut de navigation pour les utilisateurs de lecteurs d'écran. Compréhensible : l'interface doit être compréhensible dans son langage, son comportement et sa gestion des erreurs. Exigences : la langue de la page est spécifiée dans le HTML ; les champs de formulaire ont des étiquettes visibles ; les messages d'erreur identifient clairement ce qui n'a pas fonctionné et comment le corriger ; le comportement de l'interface utilisateur est prévisible (pas de changements de contexte inattendus lors du focus). Robuste : le contenu doit être interprété de manière fiable par les technologies d'assistance. Exigences : HTML sémantique (utiliser la hiérarchie des titres, les éléments de repère, les rôles ARIA de manière appropriée) ; les éléments de formulaire ont des étiquettes associées ; les composants interactifs personnalisés implémentent le bon modèle ARIA.

Les tests d'accessibilité nécessitent une combinaison de balayage automatisé et de tests manuels — les outils automatisés trouvent environ 30 à 40 % des problèmes WCAG ; les tests manuels avec des technologies d'assistance et la recherche utilisateur auprès de personnes handicapées trouvent le reste. Outils de test automatisés : Axe (extension de navigateur + intégration CI — l'outil automatisé le plus largement utilisé et le plus précis) ; WAVE (extension de navigateur de WebAIM — bon pour l'annotation visuelle des problèmes) ; Lighthouse (intégré aux Chrome DevTools — inclut un audit d'accessibilité). Les tests automatisés devraient être exécutés dans le pipeline CI à chaque pull request, faisant échouer la build si de nouvelles violations d'accessibilité sont introduites. Protocole de test manuel : audit de navigation au clavier (naviguer dans chaque flux de travail en utilisant uniquement le clavier — Tab pour avancer, Shift+Tab pour reculer, Entrée/Espace pour activer, Échap pour fermer). Documenter tout piège ou chemin brisé. Test avec lecteur d'écran : tester avec NVDA + Firefox (Windows, gratuit) et VoiceOver + Safari (macOS, intégré). Naviguer à travers les flux utilisateurs principaux et identifier tout élément qui n'est pas annoncé correctement, qui manque de contexte ou qui crée de la confusion. Vérification du contraste des couleurs : utiliser un outil d'analyse de contraste des couleurs (ColorContrastChecker, Colour Contrast Analyser app) sur toutes les combinaisons texte/arrière-plan dans le système de design et le produit. Tests utilisateurs avec des personnes handicapées : des sessions d'utilisabilité trimestrielles avec 2 à 3 utilisateurs ayant des handicaps pertinents (visuels, moteurs, cognitifs) fournissent les informations qualitatives que les outils automatisés ne peuvent pas générer.

Un Voluntary Product Accessibility Template (VPAT) est un document standardisé — publié par l'Information Technology Industry Council (ITI) — qui décrit comment un produit répond à chaque critère WCAG 2.1 et aux exigences de la Section 508 (la loi fédérale américaine sur l'accessibilité). Les équipes d'approvisionnement des entreprises et des gouvernements exigent un VPAT complété (formellement appelé Accessibility Conformance Report, ACR) dans le cadre de l'évaluation des fournisseurs. Sans VPAT, de nombreuses transactions dans les secteurs gouvernemental, de la santé, des services financiers et de l'éducation sont automatiquement disqualifiées — c'est l'équivalent du questionnaire de sécurité pour l'accessibilité. Sections du VPAT : pour chaque critère de succès WCAG, le VPAT enregistre : Prend en charge (le produit répond entièrement au critère) ; Prend en charge partiellement (le produit répond à certaines exigences mais pas toutes, avec explication) ; Ne prend pas en charge (le produit ne répond pas à ce critère, avec explication) ; et Non applicable (le critère ne s'applique pas à ce type de produit). Honnêteté et précision du VPAT : un VPAT qui prétend « Prend en charge » pour des critères que le produit ne respecte pas constitue une responsabilité légale. Le VPAT doit être préparé avec une combinaison de résultats d'audit d'accessibilité (tests automatisés + manuels) et de révision juridique. Le Product Ops coordonne la production du VPAT — en engageant un consultant externe en accessibilité pour l'audit, l'équipe juridique pour la révision, et en maintenant une cadence de mise à jour trimestrielle à mesure que le produit évolue (un VPAT de plus de 12 mois sans mises à jour est considéré comme peu fiable par les équipes d'approvisionnement).