Dans la contribution open source, il y a parfois des moments de fierté dont on se souvient. Comme par exemple quelques bouts de code que l’on a écrit de son côté pour un usage interne, puis qui se retrouvent ensuite dans le cœur du CMS qui propulse plus de 40% du web !
Aujourd’hui nous vous racontons l’histoire du bouton de formatage de langue présent dans l’éditeur de blocs Gutenberg depuis juillet 2023.
L’indication des changements de langues au sein de la page, une obligation pour l’accessibilité
Lorsqu’un contenu comprend une portion de texte écrit dans une langue différente de la langue de la page, il est nécessaire d’indiquer ce changement de langue. Cela permet notamment aux technologies d’assistance d’éviter de restituer le texte dans la langue de lecture principale du site, ou a minima de l’indiquer à l’internaute.
Pour indiquer le changement de langue de façon accessible, on utilise la plupart du temps l’attribut lang associé au code de la langue de la portion de texte.
Exemple simple d’implémentation HTML de cet attribut :
<p>WordPress est un logiciel <span lang="en">open source</span> !</p>Note : cela ne s’applique pas au terme « WordPress », même s’il est anglophone, car il s’agit d’un nom propre.
Une obligation légale de conformité au RGAA et une règle Opquast
C’est le critère 8.7 du RGAA qui stipule que tout changement de langue doit être indiqué programmatiquement : « Dans chaque page web, chaque changement de langue est-il indiqué dans le code source ? »
[1].
Du côté de la checklist Opquast, c’est la règle n°127 qui demande que « chaque changement de langue [soit] signalé »
[2].
À la suite de corrections issues d’audits RGAA nous nous sommes rendus compte qu’il n’était pas aisé de contribuer correctement du contenu validant ces règles dans WordPress, c’est à dire lorsque ce contenu comprend des portions de textes dans d’autres langues que la langue principale de la page.
Il s’agit bien souvent d’anglicismes, très communs dans notre secteur comme dans d’autres, et vous pouvez constater que cet article ne fait d’ailleurs pas exception 🙂
Avant, il était nécessaire d’ouvrir le code source HTML du bloc contenant le texte concerné pour modifier manuellement son balisage.
Une extension WordPress pour faciliter l’accessibilité des changements de langue
Suite à ce constat, j’ai travaillé avec l’aide de l’un de nos développeurs Guillaume sur la mise en place d’une option de formatage pour Gutenberg.
Cette option de formatage ajoute simplement un bouton d’indication d’un changement de langue, qui affiche une fenêtre modale permettant d’indiquer la langue en question, puis de restituer un code HTML conforme aux attentes du RGAA, des règles Opquast, et surtout des internautes utilisant des technologies d’assistance.
Après quelques tests fructueux, nous l’avons placée sur le répertoire officiel des extensions WordPress.org pour la rendre disponible à tout le monde.
Mais ne vous précipitez pas pour la télécharger : vous verrez dans la suite de cet article que cette extension est devenue totalement inutile !
L’intégration de notre extension dans Gutenberg, puis dans le cœur du CMS WordPress
Après quelques mois d’existence sur le répertoire des extensions, celle-ci a attiré l’attention de Ari, qui fait partie de l’équipe de contributeur·ices full time de Yoast.
Celui-ci a proposé une pull request sur le projet Gutenberg [3] afin d’intégrer notre extension directement dans le cœur du CMS. Cette proposition a été très rapidement acceptée par l’équipe de développement de Gutenberg.
Une amélioration pertinente : l’ajout de l’indication du sens de lecture
Suite à cet ajout au cœur du CMS, le copain grec de chez Yoast (Ari) a proposé de remplacer la balise span utilisée par notre extension par un élément <bdo> permettant aussi d’indiquer les changements de sens de lecture en fonction de la langue utilisée dans l’extrait de contenu [4]. Une excellente idée d’amélioration.
Adoption dans le cœur de WordPress
Cette nouvelle fonctionnalité ainsi que l’amélioration proposée par Ari ont été mises en ligne lors de la sortie de la version 15.9 de l’extension Gutenberg.
Cette version de Gutenberg a finalement été intégrée dans WordPress 6.3 « Lionel » qui est sortie le 8 août 2023.
Aujourd’hui en août 2025, le fonctionnement de cette option de formatage est implémenté depuis 2 ans, et il est même parfaitement décrit dans la documentation francophone de WordPress [5]. Donc il n’y a plus vraiment d’excuse pour que ce critère d’accessibilité ne soit pas conforme sur votre site !
Le projet WordPress sait intégrer les problématiques d’accessibilité lorsque celles-ci sont amenées par les acteurs de l’écosystème de façon coordonnée, légitime et argumentée.
Mon objectif avec cet article est de montrer un chemin idéal pour l’implémentation d’une fonctionnalité, en passant par la case extension.
Sur mes 10 années de contribution intensive à notre CMS préféré, j’ai rencontré de nombreux cas de figure, avec des dénouements plus ou moins heureux. J’essayerai de régulièrement proposer ce genre de retours d’expérience sur les dessous du cœur de WordPress.
Notes de l’article :
- [1] Consulter le critère 8.7 du RGAA
- [2] Consulter la règle Opquast n°127
- [3] Consulter la pull request sur le dépôt GitHub du projet Gutenberg (en anglais)
- [4] Consulter la pull request concernant l’utilisation de l’élément BDO (en anglais)
- [5] Consulter la section correspondante sur la documentation de WordPress en français
Laisser un commentaire