Actualités

Projets en cours

Dernière mise à jour : 31 octobre 2026

En cours

v3 : Une suite complète d'assurance qualité

27 septembre 2026

Présentation à la DrupalCon Europe 2026

Principales nouveautés

• Fusion du noyau de tests avec Sa11y. Le nouveau jeu de règles, développé conjointement, ajoute des tests pour les développeurs, la vérification du contraste et un score de lisibilité aux règles de base sur le contenu.
• Prise en charge de plusieurs langues
• Constructeur de règles personnalisées
• Outils de maintenance du tableau de bord
• Un outil d'exploration du site pour ajouter de nouveaux résultats.
• Permet à certains tests (ce PDF est-il accessible ?) de masquer les alertes à l'échelle du site pour certains rôles.
• Configuration séparée : tests et vues de rapports par rôle, distincts pour les développeurs et pour les auteurs de contenu.

Et, peut-être surtout, pour l'avenir du projet :

• Obtention d'une subvention pour lancer cette organisation de parrainage, afin d'accompagner les utilisateurs actuels et de financer le travail sur de futures idées de projet.

v2 : Masquage des alertes et rapports

2 mars 2023

Il y a deux ans, nous avons présenté le vérificateur d'accessibilité Editoria11y : un module clé en main pour Drupal offrant aux auteurs un retour automatique et instantané, avec des conseils utiles pour améliorer leur contenu.

Nous pensions répondre ainsi à un besoin non satisfait. Les options existantes exigeaient toutes une formation et une utilisation assidue pour être utiles, et l'expérience nous avait montré qu'essayer de former et de suivre des milliers d'auteurs de contenu au sein d'une grande organisation n'était pas une façon efficace de s'attaquer au problème. Pour réussir, un programme devait selon nous être largement automatisé et offrir poliment aux auteurs de contenu une « formation juste à temps » lorsqu'il détectait des erreurs courantes.

Et ça a marché.

À Princeton, cela a largement inversé le sens de mes communications. Sur les plateformes où il était installé, nous sommes passés de l'envoi de courriels répétitifs aux auteurs de contenu pour réclamer un texte alternatif ou l'amélioration d'un lien ou d'un titre, à la réception de questions d'auteurs demandant comment améliorer leur rédaction pour qu'elle soit moins souvent signalée.

À l'extérieur, la réaction a été l'euphorie :

Rédiger des conseils autonomes

Pour les conseils de la v1, nous avions adopté une approche « résumé et détails » : une brève explication du problème et un lien vers plus de détails.

C'était une amélioration par rapport aux outils écrits pour les développeurs : les conseils étaient courts et clairs. Mais le choix de la page vers laquelle renvoyer posait toujours problème. Plusieurs utilisateurs du secteur public et de l'enseignement supérieur ont jugé nécessaire de modifier les conseils pour retirer les liens vers la documentation de Princeton, ce qui leur donnait du travail supplémentaire. Nous avons donc réécrit les conseils par défaut pour les rendre autonomes, avec des exemples intégrés.

La distinction entre les alertes rouges (problèmes avérés) et les avertissements jaunes (problèmes possibles) s'est révélée déroutante, et parfois agaçante.

Nous avons donc converti les avertissements jaunes en « vérifications manuelles » pour en clarifier le sens, et ajouté des boutons permettant aux auteurs de masquer les alertes. Les alertes « ignorées » ne sont masquées que pour la personne qui a cliqué ; les alertes « marquées comme OK » sont masquées pour tous les éditeurs du site. Les administrateurs du site choisissent qui a le droit de faire quoi.

Créer un tableau de bord

Les propriétaires de sites déploraient souvent que l'outil fasse un excellent travail pour trouver des problèmes partout sur le site, sans qu'il soit possible d'en consulter un rapport d'ensemble.

La réécriture ajoute une option pour synchroniser les résultats avec la base de données du site. Les propriétaires de sites peuvent désormais parcourir les résultats par page ou par problème, voir quels problèmes ont été ignorés ou marqués comme OK – et les rétablir s'ils ne sont pas d'accord !

Visite du code de la v2 pour les développeurs

La v2 est une réécriture presque complète. Parmi les nouvelles fonctionnalités :

• La suppression de la dépendance à jQuery permet de l'installer sur davantage de plateformes et double ses performances.
• Le vérificateur peut désormais être configuré pour examiner plusieurs parties indépendantes de la page (par exemple, le contenu de l'article et le pied de page).
• Le vérificateur peut désormais tester les éléments à l'intérieur du shadow DOM, utilisé par divers composants Web et bibliothèques JavaScript.
• De nombreux nouveaux paramètres facilitent l'intégration aux plateformes : on peut par exemple ignorer automatiquement tous les problèmes sur certaines pages pour certains utilisateurs, s'ils ne sont pas responsables du contenu de ces pages mais souhaitent tout de même consulter les résultats à la demande.
• Le vérificateur est désormais livré avec plusieurs thèmes de base et des paramètres de personnalisation des couleurs.
• Des tests automatisés aident à prévenir les régressions du code.

A11yTalks 2024

11 juin 2024

Drupal GovCon 2023

27 octobre 2023

DrupalCamp NJ 2023

28 mars 2023

v1 : Aide contextuelle

11 mars 2021

Créer du contenu Web hautement accessible est compliqué, et cela commence généralement par beaucoup de formation.

Des pratiques familières doivent être découragées :

• Les tableaux ne doivent pas servir à créer de fausses colonnes
• Le texte courant ne doit être ni centré ni justifié
• Il ne faut pas compter sur une mise en forme purement visuelle (graisse et taille de police) pour transmettre du sens aux utilisateurs, qui peuvent écouter le contenu ou le consulter en « mode lecture »

De nouvelles pratiques doivent être encouragées :

• Les images ont besoin d'un texte alternatif pertinent dans leur contexte
• Les pages ont besoin d'une vraie structure
• Les liens doivent avoir des intitulés significatifs

Certes, certaines de nos formations existent parce que nous enseignons des concepts nouveaux, mais il faut bien se poser la question à un moment donné : quelle part du besoin de nouvelles compétences vient de la nouveauté des concepts, et quelle part vient du fait que nous imposons de nouvelles attentes sans mettre à jour nos outils ? Ce n'est pas parce qu'une chose est nouvelle qu'elle ne peut pas être intuitive.

Les leçons de l'histoire de l'orthographe

Phase 1 : Blâmer l'auteur

Depuis l'aube de l'histoire écrite jusqu'au début des années 1980, c'est l'auteur que l'on blâmait quand il écrivait mal un mot. C'était à lui qu'il incombait d'apprendre à bien orthographier.

Comment améliorait-on son orthographe ? Cela va vous sembler familier :

1. On suivait des formations, auprès d'un précepteur ou en classe
2. On recevait des listes, des consignes et des dictionnaires à étudier, une tradition qui remonte aux anciens lexiques cunéiformes gravés dans l'argile.

Phase 2 : Blâmer le dictionnaire

Mais quelque chose a changé dans les années 1980 : appelons cela la « phase 2 de l'orthographe ». Les traitements de texte les plus populaires ont intégré la correction orthographique.

Et qu'est-il advenu du petit jeu des reproches ? Presque du jour au lendemain, le blâme s'est déplacé vers l'outil :

• Vous ne savez pas comment s'écrit un mot ? Tentez votre chance en espérant qu'une correspondance soit trouvée. Sinon, blâmez le dictionnaire.
• Vous employez un vrai mot que le dictionnaire signale parce qu'il ne le connaît pas ? Pestez, puis décidez d'ignorer le soulignement ou de faire un clic droit pour ajouter le mot au dictionnaire.

La correction orthographique a-t-elle réglé tous nos problèmes d'orthographe ? Certainement pas. Mais elle nous a aidés. Et elle a transféré une grande partie du fardeau et de la responsabilité de l'auteur vers la machine.

Mais ce n'était pas la fin de l'histoire…

Phase 3 : Blâmer l'outil de rédaction

Ces dernières années ont apporté une nouvelle avancée : les ordinateurs se sont mis à écrire à notre place :

• Les algorithmes prédictifs tentent de deviner le mot suivant, l'expression suivante, voire une réponse entière à un SMS.
• Les outils de mise en forme automatique tentent de convertir les astérisques, les chiffres et les lettres en listes, les codes courts en caractères spéciaux et en emojis, etc.
• Les outils de dictée tentent de reconnaître le sens pour choisir entre des homonymes.

Et qui est blâmé quand tout cela déraille ? L'outil !

Les agrégateurs de réseaux sociaux adorent les captures d'écran embarrassantes du genre « Ce n'est pas ce que je voulais dire ! ».

Editoria11y, un pas vers la phase 2

Dans nos formations, nous parlons beaucoup de tests et présentons plusieurs très bons outils de test. Aucun ne peut tout détecter : des principes comme « éviter d'expliquer des concepts par des références chromatiques ou spatiales » doivent être vérifiés par un humain, et les outils détectent généralement un peu moins de la moitié des problèmes réels d'un site. Mais ils font du très bon travail pour repérer de nombreuses erreurs courantes dans le contenu éditorial.

Trois problèmes, toutefois :

1. La plupart sont des outils manuels. Le créateur de contenu doit avoir appris à s'en servir, doit se souvenir de leur existence au moment de rédiger et doit penser à les lancer une fois son travail terminé. Ces trois points de défaillance se liguent pour laisser une bonne partie (la majeure partie ?) du contenu sans vérification.
2. Ils signalent trop de choses. Ils ne marquent pas seulement les erreurs que l'auteur vient de commettre : ils marquent aussi les problèmes de couleur laissés par le designer, les problèmes techniques laissés par le développeur, des éléments structurels à titre informatif, etc. La formation n'en devient que plus exigeante : les auteurs doivent non seulement comprendre l'outil, mais aussi apprendre à ignorer toute une liste de faux positifs ou de problèmes bien réels qu'il ne leur revient pas de corriger aujourd'hui, pendant qu'ils rédigent cet article précis.
3. Les outils automatisés suivent généralement le paradigme « explorer le site, consulter le tableau de bord ». Là encore, cela suppose qu'un auteur a appris à consulter le tableau de bord et qu'il pensera à le faire.

Princeton a donc entrepris de créer quelque chose de nouveau : un vérificateur automatique, intégré au site Web, qui ne s'intéresserait qu'aux erreurs éditoriales courantes.

L'automatique, c'est… pas si simple.

1. Les vérificateurs automatiques doivent être discrets : trop insistants, ils interrompent et agacent l'auteur ; trop polis, ils deviennent vite un bruit de fond que l'on ignore.
2. Les vérificateurs automatiques doivent être très performants : si la page tressaute ou hésite pendant leur exécution, les auteurs leur en voudront et les désactiveront.
3. Les vérificateurs automatiques ont besoin de conseils adaptés aux débutants. Pour beaucoup d'auteurs, ce sera la première fois qu'ils entendent parler du balisage, de la structure et du langage qui rendront leur contenu plus accessible. Les alertes doivent être rédigées dans une langue simple et non technique, avec des conseils pratiques pour améliorer le contenu.

Nous avons donc commencé par l'outil le plus proche de ces objectifs que nous ayons pu trouver : Sa11y, issu de la Toronto Metropolitan University. Nous avons repris son architecture de tests et son approche conviviale, associant panneau d'information et infobulles, puis consacré six mois à adapter l'outil pour que les tests s'exécutent toujours automatiquement, à optimiser ses performances, à peaufiner les infobulles et à créer une longue liste d'options de configuration permettant à un développeur de l'adapter rapidement à n'importe quelle plateforme.

Voici à quoi il ressemble aujourd'hui :

Lorsqu'un auteur est connecté à son site, le bouton bascule d'Editoria11y indique le nombre et le type de problèmes (aucun problème, vérifications manuelles requises, problèmes probables détectés) sur chaque page. Il peut cliquer pour afficher le surlignage dans le contenu et les conseils. Si l'erreur est nouvelle, parce qu'il consulte une page qu'il vient de modifier, le panneau s'ouvre automatiquement.

En mars 2021, cela signifie que plus de 400 sites Web de Princeton vérifient automatiquement :

• Un bon plan de document
  • Niveaux de titres sautés
  • Titres vides
  • Titres très longs
  • Citations étrangement courtes qui pourraient en réalité être des titres.
• Alternatives textuelles
  • Images sans texte alternatif
  • Images dont le texte alternatif est un nom de fichier
  • Images dont le texte alternatif est très long
  • Texte alternatif contenant des mentions redondantes comme « image de » ou « photo de »
  • Images dans des liens dont le texte alternatif semble décrire l'image plutôt que la destination du lien
  • Visualisations intégrées qui nécessitent généralement une alternative textuelle
• Liens significatifs
  • Liens sans texte
  • Liens dont l'intitulé est un nom de fichier
  • Liens dont l'intitulé n'est qu'un texte générique : « cliquez ici », « en savoir plus », « télécharger », etc.
  • Liens qui s'ouvrent dans une nouvelle fenêtre sans icône de lien externe
• Assurance qualité générale
  • Vérification que la mise en forme de liste est utilisée plutôt que des astérisques, des chiffres et des lettres
  • GRANDES QUANTITÉS DE TEXTE EN MAJUSCULES
  • Tableaux sans en-têtes et tableaux utilisant des titres de document (« Titre 3 ») au lieu d'en-têtes de tableau (<th>)
  • Liens vers des PDF et d'autres documents, rappelant à l'utilisateur de tester l'accessibilité du téléchargement ou de fournir un autre format accessible
  • Vidéos intégrées, rappelant à l'utilisateur d'ajouter des sous-titres
  • Fichiers audio intégrés, rappelant à l'utilisateur de fournir une transcription
  • Contenus de réseaux sociaux intégrés, rappelant à l'utilisateur de fournir des éléments alt

Nous avons publié la bibliothèque JavaScript pour la communauté, créé une intégration Drupal clé en main et commencé à travailler sur une intégration WordPress clé en main.

Vers la phase 3 : L'accessibilité par défaut

À bien des égards, Editoria11y est une solution provisoire. La plupart des erreurs qu'il détecte sont dues au fait que nous avons imposé de nouvelles attentes aux auteurs de contenu (« structurez correctement votre contenu »), tout en leur donnant des outils qui encourageaient le contraire.

La voie à suivre consiste à rendre la création de contenu accessible plus facile et aussi automatique que possible. Ce à quoi cela ressemblera n'est pas encore évident, mais cela passera probablement par des choses comme :

• Repenser les options proposées. Par exemple : si nous répétons sans cesse aux utilisateurs de ne pas justifier le texte sur le Web, n'est-il pas temps de mettre à la retraite ce bouton « justifier le texte » ?
• Repenser les options par défaut. Par exemple : le tableau par défaut de la plupart des systèmes de gestion de contenu n'a pas d'en-têtes. C'est à l'utilisateur de savoir qu'il faut cliquer sur « propriétés » et ajouter les fonctions d'accessibilité ; il est peut-être temps d'inverser la logique ?
• Réfléchir à la mise en forme prédictive et aux « indications au fil du travail ». Si un utilisateur met toute une ligne en gras, pouvons-nous lui suggérer d'en faire un titre ? S'il s'apprête à choisir un titre, pouvons-nous deviner les niveaux qu'il souhaite plutôt que de lui proposer six options ? Pouvons-nous offrir une formation juste à temps sur les concepts difficiles ?