POUR

POUR est le cadre conceptuel sur lequel repose WCAG. Chaque critère de succès de WCAG 2.x se rattache à exactement l’un des quatre principes. Mémoriser POUR est le chemin le plus court pour comprendre pourquoi une règle donnée existe.

Les quatre principes

Perceptible. Les informations et les composants de l’interface doivent être présentables aux utilisateurs d’une manière qu’ils puissent percevoir. En pratique : alternatives textuelles pour les contenus non textuels (images, vidéos), sous-titres et transcriptions pour l’audio, contraste des couleurs suffisant, contenus qui s’adaptent aux utilisateurs de lecteurs d’écran et aux mises en page zoomées. Si un utilisateur voyant peut voir quelque chose qu’un utilisateur aveugle ne peut pas percevoir, il s’agit d’un écart de perceptibilité.

Utilisable. Les composants de l’interface utilisateur et la navigation doivent être utilisables. Les grandes règles relevant de ce principe : accès complet au clavier (aucune fonctionnalité ne doit dépendre de la souris), temps suffisant pour lire et accomplir les tâches, absence de contenu provoquant des crises (les flashs supérieurs à 3 fois par seconde constituent la limite absolue), navigation claire et ordre de focus prévisible. Les nouveaux critères de WCAG 2.2 sur la visibilité du focus et les alternatives au glisser-déposer relèvent du principe Utilisable.

Compréhensible. Les informations et le fonctionnement de l’interface doivent être compréhensibles. Cela couvre des éléments tels que les schémas de navigation prévisibles, le libellé cohérent d’une page à l’autre, les instructions claires et la récupération utile en cas d’erreur. Les recommandations du groupe de travail sur l’accessibilité cognitive s’inscrivent dans ce principe, même lorsque WCAG lui-même s’arrête avant de les rendre obligatoires.

Robuste. Le contenu doit être suffisamment robuste pour être interprété de manière fiable par une grande variété d’agents utilisateurs, y compris les technologies d’assistance. En pratique, c’est le principe le plus restreint, avec essentiellement une seule règle — 4.1.2 Nom, rôle, valeur — mais cette règle couvre une surface considérable : elle exige que chaque contrôle d’interface personnalisé expose ce qu’il est, ce qu’il fait et dans quel état il se trouve, d’une manière lisible par les technologies d’assistance. La règle 4.1.2 justifie l’existence d’ARIA.

Comment utiliser POUR de manière opérationnelle

Lorsqu’un problème d’accessibilité est identifié, il convient de demander quel principe il enfreint :

• Un attribut alt manquant relève du principe Perceptible.
• Un piège clavier relève du principe Utilisable.
• Un message d’erreur confus relève du principe Compréhensible.
• Un menu déroulant personnalisé qui ne s’annonce pas comme une combobox relève du principe Robuste.

Ce mapping aide à prioriser : les défaillances Perceptible et Utilisable bloquent généralement complètement les utilisateurs ; les défaillances Compréhensible et Robuste dégradent souvent l’expérience sans la bloquer. La plupart des équipes concentrent donc leur premier passage d’audit sur P et U.

POUR aide également à repérer les lacunes. Une équipe qui corrige avec acharnement les problèmes Perceptibles (texte alternatif, contraste) mais ignore les problèmes Utilisables (ordre de focus, pièges clavier) présente un profil de défaillance reconnaissable et courant. POUR rend visible ce déséquilibre.