WordPress et accessibilité : comment contourner les limites de l’éditeur par défaut pour gérer des besoins de contribution spécifiques ?

Pour terminer cette série d’articles consacrés à l’accessibilité des contenus sur WordPress, nous voyons maintenant les limites de l’éditeur WordPress par défaut pour contribuer de manière accessible et conforme au RGAA, et des pistes de solutions pour les contourner.

Certains critères d’accessibilité ne pourront pas être respectés si vous utilisez l’éditeur WordPress par défaut, que ce soit l’éditeur classique ou le nouvel éditeur Gutenberg. En effet, certains besoins d’accessibilité vont requérir un développement spécifique réalisé par les équipes techniques en charge de votre thème.

Heureusement, il existe parfois des solutions. Prenons quelques cas comme exemples, en lien avec les articles précédents.

Images légendées

Nous avons déjà vu qu’il est tout à fait possible d’ajouter des images légendées de manière accessible.

Cependant, le code généré lors de l’ajout de la légende ne correspond pas totalement au code recommandé par le RGAA.

Code demandé par le RGAA

<figure role="group" aria-label="Photo : le champ de mars en hiver, copyright Stockphotos">
	<img src="img.jpg" alt="Photo" />
	<figcaption>Photo : le champ de mars en hiver, copyright Stockphotos</figcaption>
</figure>

Code de l’éditeur classique

<figure id="attachment_456" aria-describedby="caption-attachment-456">
	<img src="img.jpg" alt="Forum Access Solutions SNCF" />
	<figcaption id="caption-attachment-456">Sylvie Duchateau au forum Access Solutions de SNCF. 
	Crédit photo : Maxime Huriez
	</figcaption>
</figure>

Code de l’éditeur Gutenberg

<figure class="wp-block-image size-full">
	<img src="img.jpg" alt="Photo" />
	<figcaption class="wp-element-caption">Sylvie Duchateau au forum Access Solutions de SNCF. 
	Crédit photo : Maxime Huriez
	</figcaption>
</figure>

Dans les deux cas, il manque par exemple le role="group", ainsi que la propriété aria-label demandée par le RGAA sur la balise figure.

Après vérification par notre collègue Sylvie Duchateau, les deux implémentations, si elles ne respectent pas ce qui est demandé par RGAA 4.1, sont bien supportées par les différents lecteurs d’écran de l’environnement de test RGAA. L’information est toujours bien restituée.

Il n’y a donc aucun impact utilisateur. En fonction de la charge de développement nécessaire à l’équipe technique, il semble raisonnable d’accorder ici une dérogation pour charge disproportionnée ou indue.

Référence RGAA 4

• Critère 1.9 [A] Chaque légende d’image est-elle, si nécessaire, correctement reliée à l’image correspondante ?

Infobulles (attribut title)

Une infobulle est un texte complémentaire sur un lien, visible au survol de la souris.

Cette fonctionnalité peut être très utile dans certains cas spécifiques quand elle est employée correctement, par exemple pour indiquer qu’un lien s’ouvre dans une nouvelle fenêtre.

Malheureusement, les infobulles sont souvent mal utilisées, au point que WordPress a fait le choix de la retirer des options sur ses versions récentes afin de limiter les erreurs d’accessibilité ! C’est pour cela que nous n’avons pas abordé ce sujet dans l’article « WordPress et accessibilité : comment rendre les liens accessibles ? ».

Si toutefois, lors d’un projet, vous ressentez la nécessité d’ajouter des infobulles, discutez-en avec l’équipe technique qui pourra mettre en place des solutions.

Par exemple, il est possible d’ajouter des extensions, comme Title and Nofollow For Links, disponible sur l’éditeur classique.

Cependant, veillez à manipuler l’ajout d’infobulle avec vigilance, pour s’assurer que l’information est bien restituée dans tous les cas aux personnes utilisant un lecteur d’écran, mais aussi pour ne pas créer de bruit inutile en se contentant de répéter certaines informations déjà présentes dans les intitulés des liens, par exemple.

N’hésitez pas à vous former ou à faire former vos équipes de contribution avant d’utiliser les infobulles, par exemple en suivant notre formation « Concevoir du contenu éditorial accessible pour le web ».

Citations

Concernant les citations, WordPress ne permet pas aujourd’hui d’ajouter des citations en ligne, comme nous l’avons évoqué dans l’article « WordPress et accessibilité : comment enrichir la structure d’un article ? ».

Cependant, si de nombreuses citations en ligne sont utilisées dans vos articles, il est là aussi possible de demander à l’équipe technique de mettre en place la fonctionnalité correspondante.

Par exemple, il est possible de demander deux solutions :

• créer un shortcode dédié aux citations en ligne dans votre thème ;
• ajouter un bouton dédié à l’éditeur de WordPress, par exemple avec l’extension AddQuicktag.

Référence RGAA 4

• Critère 9.4 [A] Dans chaque page web, chaque citation est-elle correctement indiquée ?

Changements de langue

Pour l’accessibilité, la langue principale de chaque page web doit être précisée dans le code HTML : cela permet aux lecteurs d’écran de lire le texte en utilisant la bonne langue et le bon accent, et donc de restituer correctement l’information aux personnes aveugles et très malvoyantes qui utilisent ces outils.

Si votre thème WordPress est bien fait, cette indication linguistique globale à la page est déjà présente dans votre page.

Cependant, il peut arriver, en plus, d’insérer des mots en langue étrangère au sein d’un article ou d’une page WordPress.

Cela concerne les mots d’origine étrangère d’usage courant, mais absents du dictionnaire, et les mots dont la prononciation en français par les lecteurs d’écran est problématique.

Dans ce cas, c’est à vous d’indiquer aux lecteurs d’écran que le mot ou l’expression est écrit dans une langue différente que la langue déclarée par défaut.

Cependant, WordPress ne permet pas encore de fournir ces indications de langue ponctuelles, bien que des alternatives existent :

• demander à l’équipe technique qui a développé votre thème d’ajouter cette option dans l’éditeur de WordPress ;
• ou utiliser une extension qui propose cette option, comme l’extension Juiz Lang Attribute, créée par notre confrère Geoffrey Crofte.

Références RGAA 4

• Critère 8.4 [A] Pour chaque page web ayant une langue par défaut, le code de langue est-il pertinent ?
• Critère 8.7 [AA] Dans chaque page web, chaque changement de langue est-il indiqué dans le code source (hors cas particuliers) ?
• Critère 8.8 [AA] Dans chaque page web, le code de langue de chaque changement de langue est-il valide et pertinent ?

Changements de sens de lecture

Enfin, tout comme les changements de langue, indiquer les changements de sens de lecture est important pour l’accessibilité. Cela permet aussi d’améliorer la restitution par les lecteurs d’écran.

Le sens de lecture de gauche à droite est implicite pour l’ensemble du site, si celui-ci est par défaut en français, ou toute autre langue se lisant de gauche à droite. Il n’est donc pas nécessaire de l’indiquer dans ce cas-là.

En revanche, si on ajoute un mot ou une phrase d’une langue se lisant de droite à gauche dans un texte qui se lit de gauche à droite, cela posera des problèmes d’accessibilité : en effet, la restitution de l’information par les lecteurs d’écran sera incompréhensible.

Hélas, il n’est pas encore possible d’ajouter les changements de langue de lecture de manière native avec l’éditeur de WordPress, que ce soit l’éditeur classique ou l’éditeur Gutenberg.

Mais vous pouvez vous rapprocher des équipes techniques ayant développé votre thème pour personnaliser l’éditeur de WordPress et y ajouter l’option correspondante.

Référence RGAA 4

• Critère 8.10 [A] Dans chaque page web, les changements du sens de lecture sont-ils signalés ?

Conclusion

Même si WordPress propose de nombreuses options d’accessibilité, ni l’éditeur classique ni l’éditeur Gutenberg ne permettent aujourd’hui de contribuer de manière totalement accessible en toute autonomie.

Ce sera peut-être le cas un jour ; en attendant, si vous avez des besoins et des problématiques spécifiques au niveau de la contribution, n’hésitez surtout pas à solliciter les équipes techniques ayant créé votre thème ou chargées de la maintenance technique de votre blog ou de votre site : elles sauront mettre en place des solutions, que ce soit pour générer du code conforme (ce qui n’est pas encore toujours le cas avec l’éditeur Gutenberg), ou encore installer des extensions.

Résumé de la série « WordPress et accessibilité numérique »

Contribuer de manière accessible est primordial, car c’est cela qui va permettre de garder un bon niveau d’accessibilité grâce à l’ajout de contenus accessibles.

Voici la liste des points à vérifier pour l’accessibilité de vos contenus (que vous utilisiez WordPress ou pas, d’ailleurs…) :

1. gérer correctement les alternatives d’images ;
2. s’assurer que les liens sont bien compris ;
3. structurer vos contenus web avec des titres, des paragraphes, des listes et des citations, si le contenu s’y prête ;
4. lier les cellules de chaque tableau à ses en-têtes.

Si vous concevez ou développez des thèmes WordPress, alors veillez aussi à :

• bien structurer les modèles de pages de votre thème WordPress ;
• faciliter la navigation sur votre thème WordPress.

Ne manquez pas non plus la conférence « Comment améliorer l’accessibilité de votre thème WordPress ? » donnée par notre collègue Marie Guillaumet à BlendWebMix, qui couvre tout le contenu de cette série d’articles, avec des exemples supplémentaires.

Quelles sont vos astuces, outils et bonnes pratiques pour améliorer l’accessibilité de vos contenus dans WordPress ? Partagez-les avec nous par e-mail, ou bien sur les réseaux sociaux : LinkedIn, Twitter. Nous serons heureuses de vous lire. À bientôt !