Étude de l'accessibilité d'eZ Publish

Étude de l'accessibilité d'eZ Publish

Comme vous le savez sans doute, je travaille depuis plus d’un an et demi avec le CMS eZ Publish dans le cadre de mon travail. C’est un CMS Open Source, sa particularité est de permettre de structurer de manière très complexe les contenus en différents attributs. Parmi les 135 critères beaucoup ne dépendent pas directement d’eZ Publish mais ce sont soit des composants externes (par exemple pour les videos, le flash, … ), soit des choix graphiques, ergonomiques et la manière dont ont été construits les templates. Il est donc impossible de savoir si eZPublish et compatible ou non avec ces critères, tout dépendra des différents choix qui auront été fait et des technologies tierces mises en places. Il me parait pas utile de tester les templates par défault car bien qu’il fournissent une base au développeur ne sont que très rarement utilisable en l’état. Et comme nous le verrons, une réécriture totale s’impose. Je vais simplement présenté la capacités d’eZ Publish à répondre aux critères d’accessibilité dont il est directement responsable, et le moins qu’on le puisse dire c’est qu’il y a du travail.

Les images

Le datatype image

eZ Publish dispose d’un datatype pour les images qui permet de saisir une alternative textuelle. On pourrait croire que les critères sur les alternatives sur les images vont passé haut la main. En fait pas du tout, les images sont généralement regroupés dans une médiathèque, et donc l’alternative peut en aucun cas être renseigné en fonction du contexte d’affichage. L’alternative est commune à tous les contextes donc elle est inexploitable. Ce problème n’est pas propre à eZ Publish mais à tous les CMS utilisant une médiathèque. Néanmois, si l’on se fixe comme règle que chaque image présent dans la médiathèque n’est utilisé que dans un seul contexte, il est possible d’utiliser ce mode de fonctionnement mais on perd tout l’intéret d’une médiathèque. Malheureusement, c’est la seul solution avec cet outil.

Image dans les blocs XML

L’insertion dans les blocs XML d’une image devrait permettre de contextualiser l’alternative en fonction du contenu. Cette fonctionnalité n’est pas présente par défault mais il est parfaitement possible de configurer eZOE à l’aide custom_attribute pour permettre de saisir l’alternative. Il faut donc modifier tous les templates disponible par défault pour pouvoir renseigné correctement l’attribut HTML alt.

La description longue

Dans le cas des descriptions longues nécessaire par exemple sur les graphiques, organigrammes ou autres images qui portent beaucoup d’information, il est également possible d’utiliser un custom_attribute mais il faut dans ce cas renseigné une URL en dur. Cette méthode n’est vraiment pas dans l’esprit d’eZ Publish, on aurait préférer voire une relation d’objet vers un objet de type description_longue ou voir un attribut de type bloc XML directement dans le bloc XML.

Les tableaux

Tableaux dans les blocs XML

Meta-information sur les tableaux

Ici encore, les custom_attributes nécessaire pour rendre accessibles les tableaux ne sont pas présent, en fait pour être précis ils sont commentés dans les settings (!!!). Il suffit de modifier les fichiers ini pour faire apparaitres les attributs summary et abbr et la balise caption, et encore une fois il faut surcharger les templates par défaut.

Marquer les en-tetes

Bon point, eZ OE permet de marquer simplement les en-têtes de tableaux.

Marquer les relations entre les cellules et les en-têtes

Il est possible moyennant quelques modification de spécifier les attributs row et cols de manière automatique. Par contre, il est extrement difficile de positionner les relations headers et ids. Pour les tableaux à 1 ou 2 entrés sans colonnes fusionner c’est possible de les faire accessibles. Dans les autres cas, il faut passer par une classe dédiés qui représentera un modèle de tableau. Le datatype ezMatrix nous permettra de stockés les données.

Modèles de tableaux

eZ Publish fournit le datatype matrix permettant de modéliser des tableaux. Il suffit alors d’encapsuler ce datatype dans des classes enveloppes et faire les overrides qui vont bien pour obtenir des templates qui soient parfaitement accessibles.

Les liens

La gestion des titres de liens (attribut title) sous eZ Publish est mauvaise, il faut absolument modifier tous les templates qui l’utilisent (grosso modo tous les templates par défault). Dans l’éditeur WYSIWYG, il faut également rajouter un custom_attributes du même nom pour pouvoir mettre un title sur les liens.

Éléments Obligatoires

Mettre un titre unique et pertinent à chaque page

Mettre un titre pertinent est plus complexe qu’il n’y parait. Il faut par exemple faire figurer les numéros de page dans le titre lors de parcours de listes, l’expression recherché lors d’une recherche, … . L’utilisation de la persistent_variable permet de résoudre ce problème et de faire remonté au niveau de la vue full du noeud en cours de visualisation le titre qu’il faut donner à la page. Malheureusement, cette technique à ces limites et ne fonctionne pas dans les moteurs de recherches mais comme le suggère Damien, on trouve dans eZ Web interface les opérateurs ezpagedata_* qui permettent de contourner cette limitation. On regrettera simplement que ces opérateurs ne se trouvent directement dans le kernel d’eZ Publish.

Marquer les changements de langue

Gros point noir d’eZ Publish, bien qu’il soit possible de spécifier un changement de langue dans les blocks XML au moyen d’un custom_attribute, il n’est pas possible de le faire pour les champs textuels simples. Il faudrait remplacer tous les champs textuels par des blocks XML sauf pour le champ qui génére l’URL. Ce qui me semble totalement irréaliste. Les changements de langue sont plus fréquent qu’on ne le croit dans le mesure où le français ne traduit pas les mots étranger mais les intégrent directement. L’exemple du mot “Newsletter” est le plus emblématique, il est prononcé “Nestlé Thé” par les synthèses vocales. Il est primordial de marquer ce mots comme étant de langue anglaise ou américaine pour avoir une prononciation qui soit simplement compréhensible.

Marquer les changements de sens de lecture

On a exactement le même problème que pour les changements de langue dans les lignes de textes ou les blocs de textes mais il faut bien avouer que l’on rencontre rarement des sites nécessitant des changements de sens de lecture.

Marquer les citations

Pour les citations, il faut ajouter un custom_tags par type de citation, un pour les citations en ligne et un autre pour les blocs de citations. Il faut également configurer tous les attributs qu’il est nécessaire de renseigner pour ces différentes balises.

Marquer les abréviations

Autres points noir d’eZ Publish, bien qu’il soit possible de spécifier les abréviations et les acronymes dans les blocks XML au moyen d’un custom_attribute, il n’est pas possible de le faire pour les champs textuelles simples. Il faudrait remplacer tous les champs textuelles par des blocks XML sauf pour le champs qui génére l’URL. Ce qui me semble totalement irréaliste. Ce cas de figure est également très fréquent. WCAG 2.0, et par extension Accessiweb 2 et le RGAA donnent plus de souplesse pour définir les abbréviations soit en donnant la forme complète dans le contexte adjacent, soit par l’utilisation d’un glossaire, soit par le balisage.

Conclusion

Bien entendu, tous les autres critères sont également à respecter pour avoir un site accessible et conforme à la législation en vigueur. Hormis, les changements de langue (Argent en WCAG 2) et les changements de sens de lecture (Bronze en WCAG 2), il est parfaitement possible de faire un site accessible avec eZ Publish.

On regrettera simplement le nombre de configuration qu’il est nécessaire de faire pour obtenir une configuration cohérente. Beaucoup de modification ne sont que des redéveloppement de plugins qui sont présent dans TinyMCE sur lequel s’appuie eZOE. Les opérateurs ezpagedata_* de ezwebin devrait être intégrer dans le coeur d’eZ et les templates par défault devrait s’appuyer sur ces éléments. J’espère que dans les prochaines versions les déclarations de bonnes intentions faites sur la liste Accessiweb vont devenir réalité.

comments powered by Disqus

Voir aussi

eZ Publish 4.2 intégrera Star Rating : un système de notation accessible

eZ Publish 4.2 intégrera Star Rating : un système de notation accessible

L’extension starrating est un système de notation d’article, de commentaire, ou de n’importe quel objet de contenu pour reprendre la …

Quels balisages pour un nuage de tag accessible ?

Quels balisages pour un nuage de tag accessible ?

Les nuages de tags est un type de menu qui a mis du temps à s’imposer comme mode de navigation. L’article de Sébastien Billard …

Et vous savez vous faire des liens ?

Et vous savez vous faire des liens ?

Élément de base du Web, le lien permet de naviguer d’une page à l’autre, d’un site à l’autre. Faire une lien parait …

Les 12 meilleurs plugins pour Wordpress

Les 12 meilleurs plugins pour Wordpress

Wordpress propulse mon blog depuis près d’un année, j’ai recherché à de nombreuses reprise les plugins qui pouvait m’être le plus …

A la une
  • Rencontre du numérique 2019 - Nîmes
  • référencement naturel d'un hôtel
  • Développeur eZ Platform
  • Tech lead Symfony
  • Expert Qualité Web

Copyright - Sylvain FIX

2009 - 2019