Le WordPress d'aujourd'hui, décodé pour les développeurs

Accessibilité

Les quatre principes POUR du WCAG : d’où ils viennent et pourquoi ils tiennent encore

Perceptible, Utilisable, Compréhensible, Robuste : quatre mots choisis en 2008 qui structurent encore chaque audit d'accessibilité aujourd'hui. Voici d'où ils sortent.

Par WordPress Développement • 4 novembre 2020 • 5 min de lecture • Aucun commentaire
Les quatre principes POUR du WCAG : d'où ils viennent et pourquoi ils tiennent encore

Quatre mots, un acronyme retenu dans toutes les formations à l’accessibilité : Perceptible, Utilisable, Compréhensible, Robuste, POUR en français. Ce découpage n’a rien d’évident ni d’ancien : il date précisément de la publication de WCAG 2.0 par le W3C en décembre 2008, et il a été pensé comme une réponse directe aux limites de la version précédente de la norme.

Comprendre cette origine aide à mieux lire un rapport d’audit aujourd’hui. Quand un auditeur classe une anomalie sous « Perceptible » plutôt que sous « Compréhensible », ce n’est pas un détail de vocabulaire : c’est un rattachement à une architecture de norme construite pour rester valable quelle que soit la technologie utilisée pour produire le contenu.

Ce que la première version de la norme proposait

WCAG 1.0, publiée par le W3C en mai 1999, s’organisait autour de quatorze recommandations numérotées, chacune assortie de points de contrôle classés par priorité. Cette structure fonctionnait, mais elle restait fortement ancrée dans les pratiques HTML de la fin des années 1990 : certaines recommandations faisaient référence à des techniques ou à des balises devenues obsolètes à mesure que le web évoluait vers davantage de scripts et de contenus dynamiques.

Le groupe de travail chargé de la révision a constaté qu’une norme trop liée à une technologie précise vieillit mal. Le chantier de WCAG 2.0, entamé au début des années 2000, visait justement à produire un texte capable de s’appliquer à n’importe quelle technologie web, présente ou future, sans devoir être réécrit à chaque évolution du langage.

Pourquoi quatre principes, et pas une liste de règles

La solution retenue consiste à définir d’abord des principes généraux, indépendants de toute technique, puis à rattacher à chacun des critères de succès testables. Les quatre principes couvrent, dans l’ordre :

  • Perceptible : l’information et les composants d’interface doivent être présentables aux utilisateurs de façon qu’ils puissent les percevoir, quel que soit leur sens sollicité.
  • Utilisable : les composants d’interface et la navigation doivent pouvoir être utilisés, y compris sans souris, sans limite de temps imposée arbitrairement.
  • Compréhensible : l’information et l’utilisation de l’interface doivent rester compréhensibles, tant sur le plan du contenu que sur celui du fonctionnement.
  • Robuste : le contenu doit rester interprétable de façon fiable par une large variété d’agents utilisateurs, technologies d’assistance comprises.
L'essentiel à retenir : Les quatre principes datent de WCAG 2.0, publié en 2008 ; Ils remplacent une liste de 14 recommandations jugée trop rigide ; Chaque critère de succès se rattache à l'un des quatre

Une architecture à trois niveaux

Sous chaque principe, la norme décline des directives, plus concrètes, puis sous chaque directive des critères de succès, formulés de façon à pouvoir être vérifiés objectivement, vrai ou faux. C’est cette dernière couche, les critères de succès, que les référentiels nationaux comme le RGAA reprennent et déclinent en tests précis, souvent accompagnés de méthodologies de contrôle détaillées propres à chaque pays.

WCAG 2.0
├── Principe : Perceptible
│   ├── Directive 1.1 : Équivalents textuels
│   │   └── Critère de succès 1.1.1 : Contenu non textuel
│   └── Directive 1.3 : Adaptable
│       └── Critère de succès 1.3.1 : Information et relations
├── Principe : Utilisable
│   └── Directive 2.4 : Navigable
│       └── Critère de succès 2.4.7 : Visibilité du focus
├── Principe : Compréhensible
└── Principe : Robuste

Ce que cette architecture change concrètement

Un développeur qui corrige une page ne travaille jamais directement sur un principe : il répond à un critère de succès précis, situé plusieurs niveaux plus bas. Mais savoir sous quel principe ce critère est classé aide à comprendre son intention réelle. Un contraste de couleurs insuffisant relève du principe Perceptible, parce que le problème touche la capacité à percevoir l’information visuellement. Un piège au clavier relève du principe Utilisable, parce que le problème empêche d’agir sur l’interface, indépendamment de toute question de perception.

Cette distinction évite une confusion fréquente chez les équipes qui découvrent l’accessibilité : croire que tout se résume à des problèmes de contraste ou de texte alternatif. Les quatre principes rappellent que l’accessibilité couvre également la logique d’interaction, la clarté du contenu et la fiabilité technique du code produit.

Une structure reprise, jamais remplacée

Les révisions ultérieures de la norme n’ont jamais remis en cause cette architecture en quatre principes : chaque nouveau critère de succès ajouté vient simplement enrichir l’une des directives existantes, sans créer de cinquième principe. C’est un signe de la solidité du choix fait en 2008 : la structure a été conçue pour absorber des technologies encore inexistantes à l’époque de sa rédaction, sans qu’il soit nécessaire de la réécrire.

Un repère utile en formation interne : demander à une équipe de classer elle-même une anomalie sous l’un des quatre principes avant de chercher le critère RGAA correspondant. L’exercice révèle souvent une compréhension plus fine du problème que la seule recherche du bon numéro de critère.

En résumé

Les quatre lettres de POUR ne sont pas un slogan pédagogique inventé après coup : elles reflètent une décision architecturale prise en 2008 pour rendre la norme WCAG indépendante de toute technologie particulière. Cette même architecture, inchangée depuis, sert de fondation aux référentiels nationaux et continuera probablement de structurer les audits d’accessibilité pour encore longtemps.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi