Étude sur l'accessibilité des contenus générés par les éditeurs WYSIWYG du CMS eZ publish 4.0

Sommaire

• Introduction à l'étude
• Synthèse
• Étude

Introduction à l'étude

L’étude qui suit répond à la problématique suivante : dans quelle mesure un éditeur WYSIWYG (intégré à un CMS) délivre-t-il un contenu accessible ? Techniquement, l’éditeur est-il en mesure de délivrer un contenu accessible, et si oui, à quel degré (inévitablement accessible, probabilité forte d’être accessible, peu de chances d’être accessible).

J’ai réalisé un contenu parfaitement accessible, sur une page HTML. Il s’agit d’un article traitant des cycles économiques. On y trouve tous les éléments susceptibles d’être utilisés par un rédacteur : balises, liste, tableaux de données, textes en gras et en italique, liens, ancres, images, graphiques. J’ai ensuite tenté de reproduire cet article le plus fidèlement possible en me mettant dans la peau d’un rédacteur soucieux de l’accessibilité et des WCAG, et cela dans chacun des éditeurs WYSIWYG testés. J’ai ensuite réalisés les tests définis auparavant sur chacun des contenus obtenus.

Cette étude fait partie intégrante d'un ensemble d'études dont l'objet est d'étudier l'accessibilité globale du CMS.

Bien sûr, cette évaluation est ouverte aux commentaires. Ajustements et propositions seront bienvenus, soit en la commentant sur Tentatives Accessibles, soit en contactant directement les auteurs à l'adresse suivante : r.farot[at]gmail[point]com .

Critères de l'étude

Pour cette étude, il n’était pas nécessaire de tester tous les critères WCAG. J’ai donc retenu des WCAG l’essentiel à tester. En effet, cette étude n’a pas une visée d’audit, mais a pour finalité de cerner les faiblesses globales d’un CMS. De plus, s’appliquant au contenu réalisé par un éditeur WYSIWYG, certains critères des WCAG ne sont pas pertinents. Pour cela, à partir des WCAG 1.0, une liste de tests globaux a été dressée. Chaque test est associé à une contrainte technique (balise utilisée, attribut, longueur de l’attribut…) qui servira de repère à la validation ou non du test. Concrètement, chaque test correspond à une série de critères WCAG, et on regarde si l’éditeur WYSIWYG permet de valider cette série de critères ou non.

Comme expliqué en deuxième partie, il n’est pas très pertinent d’effectuer une notation de type binaire. Dans cette étude, trois états de validation sont possibles pour chacun des tests.

Il est « possible » de valider les critères WCAG correspondants.

Ce niveau de validation est positif, non seulement il est possible de faire que le contenu généré soit conforme aux critères WCAG, mais en plus il est possible de le faire manière pertinente, le rédacteur étant relativement aidé dans cette démarche.

État « intermédiaire »

Ce niveau de validation est également positif, mais là, s’il est possible de faire que le contenu généré soit conforme, cela n’est pas intuitif, et la conformité finale du contenu dépend de la démarche d’accessibilité du rédacteur. Ainsi, dans ce cas, un rédacteur non « initié » à l’accessibilité est susceptible de passer à côté de pas mal de critères.

Il est « impossible » de valider les critères WCAG correspondants.

Ce niveau de validation est négatif. Il est impossible pour le rédacteur, initié ou non à l’accessibilité, de valider les critères WCAG correspondants. Même en cherchant la fonction désirée, on ne la trouve pas. Pour l’éditeur WYSIWYG, c’est une grosse faille.

Synthèse

eZ publish 4.0 est un CMS (Système de Gestion de Contenus) open source développé par la société norvégienne eZ Systems. eZ publish est aussi bien disponible en téléchargement gratuit sous Licence GPL, que sous licence propriétaire accompagnée d'un support commercial. On peut souligner le fait que ce CMS est loin d'être médiocre au niveau de l'accessibilité de son panneau d'administration, ce qui lui confère une certaine impression de rigueur, notamment vis-à-vis de l'accessibilité. (Je vous invite d'ailleurs à consulter l'étude qui concerne le panneau d'administration pour constater cela.) On est amenés à penser que cet étude ne révèlerait que peu de failles d'accessibilité au niveau des contenus générés par les éditeurs WYSIWYG.

Pourtant, il n’en est rien. L’étude sur 2 éditeurs WYSIWYG intégrés à eZ publish montre un nombre de critères non validés très important.

Globalement, les tests révèlent des lacunes communes à tous les éditeurs WYSIWYG testés :

• Il est impossible de renseigner le titre d’un tableau de données, pour que celui-ci soit inséré dans une balise caption, ce qui est dommage, car non seulement ce renseignement est important d’une part « syntaxiquement » : on voit de plus en plus de graphiques ou de tableaux sans titre sur le web, ce qui est une faute de présentation pure. De plus, il s’agit d’un véritable fardeau pour un utilisateur doté d’un dispositif de lecture d’écran, qui devra attendre et comprendre les informations du tableau avant de juger si son contenu l’intéresse, ce qui lui préjudiciable.
• Dans un tableau de données, abréger les en-têtes de cellules est impossible. L’intérêt d’abréger les en-têtes de cellules en utilisant l’attribut abbr est encore une fois lié aux dispositifs de lecture d’écran. Lorsque ces derniers lisent un tableau, ils répètent pour chaque cas l’entête correspondant, selon la direction du tableau. Si l’en-tête amenée à être répétée plusieurs fois est longue, cela est extrêmement désagréable pour l’utilisateur, il est donc préférable d’abréger certaines expressions.
• Dans la structuration du contenu, on note que le rédacteur du contenu n’est jamais accompagné dans sa démarche. Je veux dire par là que l’utilisation des balises <h1> à <h6> est parfaitement possible, mais que leur signification n’est pas du tout expliquée lors de leur insertion par exemple. Les balises <hn> ont un sens autre que la mise en forme qu’elles entraînent, qu’il est important de ne pas négliger : elles structurent l’information. Ainsi, l’importance et la pertinence de la hiérarchie des <hn> n’est jamais rappelée.
• Souvent, la démarche d’accessibilité n’est pas facilitée, on peut passer à côté de pas mal de validations… en effet, certaines notions ne sont pas évidentes à saisir pour un rédacteur novice en la matière.

Les 2 éditeurs WYSIWYG testés pour eZ publish révèlent des résultats plutôt catastrophiques au niveau de l'accessiblité, et même sur des critères a priori évidents. Ils se reposent beaucoup trop sur le systèmes de balises custom, mais celui-ci reste difficile à utiliser et ne résout rien quand à la capacité à assister le rédacteur dans la démarche d'accessiblité.

Retour en début de page

Étude

Etude de l'accessibilité du contenu généré par des éditeurs WYSIWYG du CMS eZ publish 4.0, selon les critères WCAG 1.0

Intitulé du test	Contrainte technique	Online editor (eZ publish 4.0)			Commentaire	Online editor (eZ publish 4.1)			Commentaire	WCAG 1.0
										Critères	Niveau
Gestion des tableaux de données
Ajouter un résumé au tableau	attribut summary				"On peut aparamment ajouter des ""propriétés"" au tableau Comment?"				La version 2.0.9 de TinyMCE permet pourtant nativement cette fonctionnalité.	5.5	AAA
Ajouter un titre au tableau	balise caption									5.5	AAA
Identifier les en-têtes de colonnes et de lignes	balises th								Passe par la modification du tag html. La fonctionnalité n'est donc pas abordable pour un simple rédacteur.	5.1	A
Relier les en-têtes aux cellules	attributs scope (row et col)									5.2	A
	attributs headers et id									5.2	A
Abréger les en-têtes de cellules	attributs abbr									5.6	AAA
Identifier des zones dans le tableau (en-têtes, pied de tableau, contenu)	balises thead, tbody, tfoot									5.1, 5.2	A
Capacité à assister l'utilisateur dans la saisie d'un tableau	longueur des en-têtes, aide dans l'attribution des en-têtes									Directive 3 de l'ATAG 2.0: Encourager l'auteur dans la production d'un contenu accessible
Gestion des images
Attribuer une alternative textuelle à l'image	attribut alt								La version 2.0.9 de TinyMCE permet pourtant nativement cette fonctionnalité. Une alternative vide est générée automatiquement, traitant ainsi l'image comme une image décorative.	1.1	A
Attribuer une description détaillée à l'image	attribut longdesc									1.1	A
Redimensionner les images					Pour redimensionner une image, on a le choix entre plusieurs tailles prédéfinies, puis on peut redimensionner l'image à la main.					14.3	AAA
Capacité à assister l'utilisateur dans l'insertion d'une image	longueur de l'alternative succinte, explicite et adaptée								On peut renseigner le titre de l'image, en vue d'afficher une légende. C'est un choix judicieux puisqu'on peut ainsi afficher une information supplémentaire à tout le monde, mais ne peut pas se substituer à l'alternative et à la description. (notions différentes)	Directive 3 de l'ATAG 2.0: Encourager l'auteur dans la production d'un contenu accessible
Gestion des liens
Attribuer un titre au lien	attribut title									6.3	A
Préciser la langue de destination	attribut hreflang									4.1	A
Créer des ancres (navigation interne, sommaire, retour en haut de page...)	ancres (#)									13.5	AAA
Capacité à assister l'utilisateur dans l'insertion d'un lien	longueur du titre et de l'intitulé succints, explicites et adaptés								Aucune aide n'est fournie à l'utilisateur pour savoir comment renseigner le titre du lien. La création d'ancres n'est pas intuitive.	Directive 3 de l'ATAG 2.0: Encourager l'auteur dans la production d'un contenu accessible
Structuration du contenu
Hiérarchiser l'information	balises hn									3.5	AA
Créer des listes ordonnées	balises ol et li									3.6	AA
Créer des listes non-ordonnées	balises ul et li									3.6	AA
Créer des paragraphes	balise p									3.1	AA
Capacité à assister l'utilisateur dans la structuration de l'information	importance et pertinence de la hiérarchie									Directive 3 de l'ATAG 2.0: Encourager l'auteur dans la production d'un contenu accessible
Divers
Mettre en avant des portions de texte	balises strong et em								Utilisation de balises de style dépréciées (b et i au lieu de strong et em)	3.1	AA
Créer et utiliser des balises diverses pour présenter et structurer l'information	balises blockquote, q, cite								On peut utiliser un certain nombre de balises. Elles sont limitées par défaut (liste balises). Il serait intéressant d'en rajouter nativement.	3.1	AA
Préciser les acronymes et abréviations	balises acronym et/ou abbr								Grâce aux balises Custom, on peut y remédier.	4.2	AAA
Informer des changements de langue	attribut lang								Grâce aux balises Custom, on peut y remédier.	4.1	A
Capacité à assister l'auteur dans l'utilisation de ces diverses fonctionnalités										Directive 3 de l'ATAG 2.0: Encourager l'auteur dans la production d'un contenu accessible
Résultats		8	1	17		8	2	16

Les correspondances avec les critères WCAG sont données à titre informatif. La liste n'est pas exhaustive, certains tests pourront en effet correspondre à plusieurs critères WCAG.

Retour en début de page


Tous les documents de ce site sont mis à disposition par Rémi Farot selon les termes de la licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France.