Normes

WAI-Adapt

Voir aussi : Personalisation Semantics, WAI Personalization Semantics, Adapt

Vocabulaire W3C en cours d'élaboration pour la sémantique de personnalisation — permettant aux utilisateurs d'adapter le contenu à leurs préférences cognitives, sensorielles et motrices via des métadonnées déclaratives plutôt que du CSS personnalisé.

WAI-Adapt (anciennement « Personalisation Semantics ») est un effort du W3C visant à donner aux auteurs un moyen de déclarer ce que le contenu signifie — quel type d’élément il est, quel symbole pourrait le représenter, à quel point il est distrayant — afin que les agents utilisateurs et les technologies d’assistance puissent adapter le rendu aux besoins de l’utilisateur.

Le projet est encore au stade de brouillon de travail en 2026. L’adoption est précoce. Mais le cadre conceptuel est suffisamment important pour que le terme apparaisse dans les feuilles de route d’accessibilité, notamment autour de l’accessibilité cognitive.

Pourquoi le W3C l’a lancé

Le modèle d’accessibilité actuel repose largement sur l’initiative de l’utilisateur : celui-ci personnalise son navigateur, installe des extensions, configure son lecteur d’écran, et espère que le site s’affiche correctement avec ces personnalisations. WAI-Adapt inverse cette logique : c’est le contenu qui déclare sa sémantique, et l’agent utilisateur peut transformer le rendu pour s’adapter à l’utilisateur sans modifier ce que le contenu signifie.

Un exemple simple : un formulaire web demande « prénom » et « nom ». WAI-Adapt permettrait à l’auteur de baliser ces champs avec des attributs sémantiques indiquant « ce champ correspond à un nom de personne ». Un utilisateur présentant un handicap cognitif pourrait alors demander à sa technologie d’assistance de substituer des invites basées sur des symboles (« 👤 votre nom ») aux libellés textuels — sans que l’auteur du site ait à livrer les deux versions.

Les trois modules

Le brouillon se divise en trois modules :

  1. Module Content — vocabulaire pour baliser la sémantique du contenu dont l’agent utilisateur a besoin pour l’adapter. data-purpose, data-action, data-destination, etc.
  2. Module Help and Support — attributs pour déclarer des variations de contenu d’aide (forme longue, langage simplifié, support par symboles, version simplifiée).
  3. Module Tools — interopérabilité avec les technologies d’assistance proposant des fonctions de personnalisation (systèmes de jeux de symboles, outils de texte prédictif, aides à la concentration et à l’attention).

Positionnement par rapport aux autres spécifications

WAI-Adapt est complémentaire à WCAG, ARIA et aux travaux du groupe de travail sur l’accessibilité cognitive. Il ne remplace aucun d’eux. WCAG définit le plancher d’accès ; ARIA définit l’interface avec les technologies d’assistance ; WAI-Adapt définit le canal de personnalisation.

Il est également complémentaire à WCAG 3, qui va plus loin sur l’accessibilité cognitive que ne l’a jamais fait WCAG 2.x. WAI-Adapt est l’un des mécanismes sur lesquels les résultats de WCAG 3 pourront s’appuyer.

Ce que cela signifie pour les équipes d’ingénierie aujourd’hui

Pour la plupart des équipes, la réponse est : rien d’opérationnel pour l’instant. Le vocabulaire est encore instable. La prise en charge par les agents utilisateurs est quasi nulle. Il n’existe pas de règle Pa11y, ni de règle axe-core, ni d’audit Lighthouse pour les attributs WAI-Adapt.

Mais le cadre conceptuel mérite d’être connu. Lorsque vous livrez un site permettant aux utilisateurs de basculer en « vue simplifiée » ou d’« afficher des symboles », vous inventez — localement — ce que WAI-Adapt cherche à standardiser. À mesure que la spécification se stabilise au cours des 2 à 3 prochaines années, attendez-vous à voir la première vague d’outils de création générer des attributs WAI-Adapt par défaut.