POUR en accessibilité

Qu'est-ce que POUR en accessibilité ?

POUR est l'acronyme anglais de Perceivable, Operable, Understandable et Robust (perceptible, utilisable, compréhensible et robuste). Ce sont les quatre principes qui structurent les Web Content Accessibility Guidelines. Chaque critère de succès WCAG relève de l'un d'eux : POUR permet donc de se demander rapidement ce qui bloque quand quelqu'un ne peut pas utiliser une page. La norme complète est présentée dans WCAG.

WCAG 2.2 compte quatre principes et 13 règles. Les principes forment le niveau supérieur, les règles disent quoi atteindre et les critères de succès sont les exigences testables.

Les quatre principes POUR

Perceptible (Perceivable)

L'information et les composants de l'interface doivent être présentés de façon que les utilisateurs puissent les percevoir. Cela couvre les alternatives textuelles aux images, les sous-titres pour l'audio et la vidéo, un contenu qui garde son sens quand la mise en page change, ainsi qu'un contraste et des couleurs suffisamment distincts. Règles 1.1 à 1.4. Voir les images accessibles.

Utilisable (Operable)

Les composants et la navigation doivent être utilisables. Tout doit fonctionner au clavier, les utilisateurs ont besoin de temps suffisant, rien ne doit clignoter d'une façon susceptible de provoquer des crises, les pages exigent des moyens clairs de navigation et les commandes doivent fonctionner autrement que par un clic précis de souris. Règles 2.1 à 2.5.

Compréhensible (Understandable)

Le contenu et le comportement de l'interface doivent être compréhensibles. La langue de la page est définie, la navigation se comporte de façon prévisible, et les formulaires étiquettent leurs champs et expliquent les erreurs par du texte. Règles 3.1 à 3.3. Voir les formulaires accessibles.

Robuste (Robust)

Le contenu doit être assez robuste pour que les navigateurs et les technologies d'assistance l'interprètent de façon fiable. En pratique, les commandes exposent un nom, un rôle et un état qu'un lecteur d'écran peut lire, en privilégiant le HTML natif et en recourant à ARIA quand le HTML n'a pas d'équivalent. Règle 4.1, la seule de ce principe.

Exemple : un formulaire de connexion, quatre défauts

• Perceptible : le logo n'a pas de texte alternatif, un lecteur d'écran annonce un nom de fichier.
• Utilisable : le bouton « Se connecter » est un div stylé qui ne réagit qu'au clic de souris, les utilisateurs du clavier ne peuvent pas valider.
• Compréhensible : une connexion échouée affiche « Saisie invalide » sans dire quel champ est en cause.
• Robuste : un menu de langue maison, fait d'éléments div sans étiquette, n'expose ni rôle ni nom aux technologies d'assistance.

Comment utiliser POUR

• Trier les constats d'audit. Rattachez chaque problème à son principe pour voir s'ils se concentrent, par exemple beaucoup de défauts d'utilisabilité dus à des widgets maison.
• Structurer les rapports. Un Accessibility Conformance Report suit les mêmes principes, critère par critère.
• Relire les maquettes tôt. Avant de construire, posez les quatre questions : cela se perçoit-il, s'utilise-t-il, se comprend-il et s'interprète-t-il par une technologie d'assistance ?

Erreurs fréquentes

• Traiter POUR comme une liste de quatre points. Il regroupe les critères, il ne remplace pas leur vérification.
• Lire un score Lighthouse parfait comme « terminé ». Les contrôles automatiques ne couvrent qu'une partie de WCAG et laissent à une personne des points comme l'ordre de tabulation ou le focus piégé. Voir sur le blog (en anglais) le comparatif des outils de test d'accessibilité.
• Réduire « robuste » à « HTML valide ». Robuste concerne des noms, rôles et états exploitables par les technologies d'assistance. WCAG 2.2 a supprimé l'ancien critère 4.1.1 Analyse syntaxique (Parsing).

Pour suivre la partie automatique dans le temps, la surveillance de la vitesse des pages de LoadFocus lance des audits Lighthouse planifiés et enregistre la catégorie Accessibility à côté de Performance, de sorte qu'une baisse après une version se voit. C'est une alarme de régression, pas un contrôle de conformité.

Questions fréquentes sur POUR

Que signifie POUR ?

Perceivable, Operable, Understandable et Robust : perceptible, utilisable, compréhensible et robuste.

Qui a défini les principes POUR ?

Ce sont les quatre principes de WCAG, publiés par la Web Accessibility Initiative du W3C.

POUR est-il la même chose que WCAG ?

Non. POUR est le niveau supérieur de la structure de WCAG. En dessous se trouvent les règles et les critères de succès des niveaux A, AA et AAA que l'on teste réellement.

Un score automatique parfait signifie-t-il qu'un site respecte POUR ?

Non. Les outils automatiques ne vérifient qu'une partie des critères de succès. L'usage du clavier, la gestion du focus et la clarté des messages d'erreur demandent des tests manuels.