Audit d'accessibilité de l'interface d'administration du CMS eZ publish 4.0

Sommaire

• Présentation
• Synthèse
• Étude

Présentation

eZ publish 4.0 est un CMS 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 commerical.

L'interface d'administration d'eZ publish, aussi appelée back-office est un ensemble de pages Web au travers desquelles un administrateur du site peut configurer ses composants, un rédacteur peut y rédiger et organiser ses contenus... On parle du back-office, ou back-end par opposition au front-office, ou front-end, qui constitue la partie du site visible par les internautes ou utilisateurs.

Dans cette étude, il s'agit d'évaluer l'accessibilité de l'interface d'administration d'eZ publish 4.0 selon les critères WCAG 1.0.

Panneau d'administration de eZ publish 4.0

Cet audit fait partie intégrante d'un ensemble d'études dont l'objet est d'étudier l'accessibilité globale du CMS. En plus de cette étude, d'autres concernent d'une part l'accessibilité du front-office en sélectionnant un design par défaut du CMS, d'autre part la capacité à générer du contenu accessible via l'éditeur WYSIWYG du CMS.

Bien sûr, cette évaluation est ouverte aux commentaires. Ajustements et propositions seront bienvenus, soit en la commentant sur le blog de Miura Conseil, soit en contactant directement les auteurs à l'adresse suivante : r.farot[at]miura-conseil[point]com .

Synthèse

L'objectif de cette évaluation est premièrement d'aider la communauté travaillant autour d'eZ publish à rendre l'interface d'administration plus accessible. Ensuite, elle peut servir dans le cadre d'une comparaison avec d'autres CMS sur le plan de l'accessibilité de leur back-office.

Pour satisfaire cet objectif, l'audit se base sur 3 niveaux de validation des critères WCAG 1.0. Le niveau "Valide" indique que le critère est validé. Cet audit constituant une base à une réflexion plûtot qu'un jugement, nous avons trouvé judicieux de distinguer deux niveaux de critères non-validés. Dans certains cas, on ne peut pas valider un critère, mais on se rend compte qu'il y a peu de moyen à mettre en oeuvre pour pouvoir valider ce critère. Ainsi, nous avons décidé de qualifier ce type de conformité d'intermédiaire, et le cas échéant, d'argumenter ce choix en faisant des suggestions. La deuxième partie de critères non validés n'est pas exempte de suggestions, mais nous considèrerons qu'il s'agit d'une réelle faille d'accessibilité. Enfin, il faudra bien noter que certains critères ne sont pas vérifiables, puisque les techniques permettant de valider ces critères ne sont pas applicables.

A l'issue de cet audit, on peut dire que le code est propre, et qu'il valide un grand nombre de critères testables (plus de la moitié). Autre fait positif, parmi les critères non validés, la moitié consiste en des critères dits "intermédiaires". En revanche, on peut se montrer bien plus perplexe sur d'autres points. Certaines fonctionnalités primordiales de l'interface qui contribuent d'ailleurs grandement à la praticité et CMS, révèlent de gros défauts d'accessibilité, comme les menus contextuels ou l'usage de javascript obstructif. Ainsi, l'utilisation du CMS peut-être rendue impossible à certains utilisateurs.

Étude

Etude de l'accessibilité du panneau d'administration du CMS eZ publish 4.0, selon les critères WCAG 1.0

						Remarques	Suggestions	Priorité
Directive 1. Fournir des alternatives équivalentes au contenu visuel et auditif.
1.1	Fournir un équivalent textuel à chaque élément non-textuel (par exemple via " alt ", " longdesc ", ou dans le contenu des éléments).					Et ces équivalents textuels expliquent clairement l'élément.	Dans l'arborescence de gauche, il serait mieux de préciser la classe de l'élément (folder ou article) dans une alternative quand l'arborescence est générée en Javascript. Il serait également mieux d'ajouter une alternative textuelle aux images de type "panneaux Attention".	A
1.2	Fournir des liens textes redondants pour chaque région active d’une carte cliquable côté serveur.					Il n'y a pas de carte cliquable.		A
1.3	Jusqu’à ce que les agents utilisateurs soient en mesure de lire automatiquement à haute voix l’équivalent textuel d’une piste visuelle, fournir une description auditive des informations importantes de la piste visuelle d’une présentation multimédia.					Il n'y a pas de présentation multimédia.		A
1.4	Pour toute présentation multimédia temporisée (par exemple un film ou une animation), synchroniser les alternatives équivalentes (par exemples les sous-titres ou la description auditive des pistes visuelles) avec la présentation.					Il n'y a pas de présentation multimédia.		A
1.5	Jusqu’à ce que les agents utilisateurs soient en mesure de restituer les équivalents textuels des liens des cartes cliquables côté client, fournir des liens textuels redondants pour chaque région active d’une carte cliquable côté client.					Il n'y a pas de carte cliquable.		AAA
Directive 2. Ne pas s’en remettre exclusivement aux couleurs.
2.1	S’assurer que toute information convoyée par des couleurs est également accessible sans couleur, par exemple à partir du contexte ou de balises.					Lorsqu'on regarde la page avec un écran noir et blanc, l'information est toujours disponible.		A
2.2	S’assurer que la combinaison de couleurs entre le premier plan et l’arrière-plan utilise suffisamment de contraste lorsqu’elle est utilisée par des personnes souffrant d’un déficit de perception des couleurs ou sur un écran noir et blanc.					Voir le tableau d'analyse des contrastes.		AA ou AAA
Directive 3. Utiliser le balisage et les feuilles de style, et cela de façon appropriée.
3.1	Quand un langage de balisage approprié existe, utiliser des balises plutôt que des images pour convoyer l’information.					Usage pertinent des balises <h1> à <h6>.		AA
3.2	Créer des documents qui sont validés par des grammaires formelles publiées.					Il y a un DOCTYPE.		AA
3.3	Utiliser des feuilles de style pour contrôler la mise en page et la présentation.					Utilisation du CSS, mais aussi dans le code html, par l'attribut style="…"		AA
3.4	Utiliser des unités relatives plutôt qu’absolues dans les valeurs d’attributs du langage et les valeurs de propriétés des feuilles de style.					Les tailles de police et de paddings sont toutes renseignées en unités relatives. Les seules valeurs en pixels sont les épaisseurs de bordures.		AA
3.5	Utiliser les éléments d’en-tête pour convoyer la structure du document, et les utiliser en conformité avec les spécifications.					L'information balisée par un <h2> correspond à une sous-partie de <h1>.	Il faudrait tout de même revoir l'arborescence des <hn>, qui n'optimise pas la navigation.	AA
3.6	Marquer les listes et les éléments de listes correctement.						Faire une liste pour le menu "configuration rapide".	AA
3.7	Baliser les citations. Ne pas utiliser le balisage correspondant aux citations pour obtenir des effets de présentation comme l’indentation.					Il n'y a pas de citations, ni d'utilisation abusive de balises correspondant aux citations.		AA
Directive 4. Vérifier l’utilisation du langage naturel.
4.1	Identifier clairement les changements survenus dans le langage naturel du texte d'un document et équivalents (par exemple les légendes).					Quand un élément n'est pas traduit dans la langue courante, il est affiché dans la langue par défaut, mais ce changement de langue n'est pas reporté dans le code.		A
4.2	Spécifier la forme complète de toutes les abbréviations ou acronymes employés dans le document lors de la première utilisation.					Sur la page d'administration, l'acronyme RAD devrait être précisé.		AAA
4.3	Identifier le langage naturel principal du document.					L'attribut lang est clairement indiqué dans le code HTML.		AAA
Directive 5. Créer des tableaux qui se transforment de façon élégante.
5.1	Pour les tableaux de données, identifier les en-têtes de lignes et de colonnes.					Utilisation de balise <th> à la place des balises <td> pour les en-têtes de colonne.		A
5.2	Pour les tableaux de données qui ont deux niveaux logiques d'en-tête de colonne ou de ligne ou plus , utiliser des balises pour associer les cellules de données et les cellules d'en-tête.					Les en-têtes de colonnes doivent avoir l'attribut scope=col et les en-têtes de lignes l'attribut scope=row (les champs textes ne sont pas associés à un en-tête de ligne).		A
5.3	Ne pas utiliser les tables pour la mise en page, à moins qu'elles n'aient un sens lorsqu'elles sont déchiffrées en mode linéaire. Autrement, si la table n'a pas de signification, prévoir une version alternative (qui pourra être une version linéaire).					Les tableaux ne sont pas utilisés pour de la mise en page.		AA
5.4	Dans le cas ou une table est employée pour la mise en page, il ne faut pas utiliser de balises structurelles dans un but de formatage visuel.							AA
5.5	Créer des sommaires pour les tableaux.					Le sommaire n'est pas indiqué.		AAA
5.6	Prévoir des abbréviations pour les étiquettes d'en-têtes.							AAA
Directive 6. S’assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante.
6.1	Organiser les documents de manière à ce qu'ils puissent être lus sans feuilles de style. Par exemple, lorsque un document HTML est restitué sans la feuille de style lui étant associée, il doit rester lisible.					Les menus du côté droit de la page sont situés au début du code source, et comme il n'y a pas de liens d'évitement, la navigation est pénible pour un utilisateur qui utilise un lecteur d'écran, ou qi navigue uniquement à l'aide du clavier. De plus, même quand la feuille de style n'est pas appliquée, la source contient l'ensemble des menus pop-up dans une version factice, avec des noms incohérents (XXX).		A
6.2	S'assurer que les équivalences pour le contenu dynamique soient mises à jour lorsque ledit contenu dynamique change.							A
6.3	S'assurer que les pages soient visibles lorsque les scripts, les applets ou autres artefacts programmables sont désactivés ou non supportés. Lorsque ce n'est pas possible, fournissez une information équivalente sur une page alternative.					Il n'y a pas d'alternative aux menus contextuels quand le javascript est désactivé.		A
6.4	Pour les scripts et les applets, faites en sorte que les gestionnaires d'événements soient indépendants du dispositif d'entrée.					Pour les menus contextuels, l'évènement est "onclick", donc l'évènement n'est pas indépendant du périphérique. Les évènements internes du menus ne sont pas disponible si l'on utilise pas de souris.		AA
6.5	S'assurer que le contenu dynamique reste accessible, ou fournir une présentation alternative de la page.					Mauvaise transformation des scripts		AA
Directive 7. Assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps.
7.1	Jusqu'à ce que les agents-utilisateurs permettent à l'utilisateur de contrôler les changements brusques de luminosité, il convient d'éviter de causer de tels changements sur l'écran.					Il n'y a pas de changement brusque de luminosité dans les pages du site.		A
7.2	Jusqu'à ce que les agents-utilisateurs permettent de désactiver le clignotement, éviter de faire clignoter le contenu (par ex. Changer une présentation à intervalles régulier, comme une activation ou une désactivation).					Il n'y a pas de contenus clignotants.		AA
7.3	Jusqu'à ce les agents-utilisateurs permettent de geler le contenu mobile, éviter les mouvements sur les pages.					Il n'y a pas de contenus mobiles.		AA
7.4	Jusqu'à ce que les agents-utilisateurs permettent de stoper les mises à jour, éviter de créer des pages se mettant à jour automatiquement.							AA
7.5	Jusqu'à ce que les agents-utilisateurs permettent de désactiver la fonction de redirection automatique, ne pas utiliser de commandes pour rediriger automatiquement les pages. Configurez plutôt le serveur pour accomplir cette fonction.							AA
Directive 8. Assurer un accès direct aux interfaces utilisateur intégrées.
8.1	Concevoir les éléments programmables tels que scripts et appliquettes de manière à ce qu'ils puissent être directement accessibles ou compatibles avec les différentes technologies d'assistance aux utilisateurs.					Les menus contextuels ne sont pas accessibles.		AA
Directive 9. Conception respectant l’indépendance par rapport au périphérique.
9.1	Prévoir des cartes cliquables côté client au lieu de cartes côté serveur, sauf lorsque les régions ne peuvent être définies par des formes géométriques disponibles.							A
9.2	S'assurer que tout élément qui possède sa propre interface peut être activé d'une manière indépendante du dispositif.							AA
9.3	En ce qui concerne les scripts, il importe de spécifier les gestionnaires d'événements logiques plutôt que des gestionnaires d'événements dépendants de l'interface.					Il y a une erreur dans les sous-menus des menus contextuels: l'évènement onmouseover est déclaré, mais pas le onclick (qui assure une indépendance évènements/périphériques).		AA
9.4	Développer un ordre logique de tabulation, pour les liens, éléments de formulaires et objets.					La navigation à l'aide de la touche tabulation n'est vraiment pas pratique, à cause du fait que dans le code source, les menus ne sont pas disposés de manière logique.		AAA
9.5	Prévoir des raccourcis clavier pour les liens importants (y compris ceux derrière les cartes cliquables côté client), les champs de formulaires, groupés ou individuels.					Il n'y a pas de raccourcis clavier.	Les pages peuvent contenir beaucoup d'informations, aussi il pourrait être utile de placer des liens d'évitement au début de la page.	AAA
Directive 10. Utilisation de solutions intermédiaires.
10.1	Jusqu'à ce que les agents-utilisateurs permettent aux utilisateurs de fermer les fenêtres générées, ne pas produire de fenêtre successives ou à ouverture automatique, et ne pas modifier la fenêtre active sans prévenir l'utilisateur.					Il n'y a pas d'attributs target, ni de frames.		AA
10.2	Jusqu'à ce que le agents-utilisateurs supportent les associations explicites entre étiquettes et contrôles de formulaires, s'assurer que les étiquettes sont correctement positionnées pour tous les contrôles de formulaire avec étiquettes implicitement associées.					Les étiquettes sont correctement positionnées.		AA
10.3	Jusqu'à ce que les agents utilisateurs (comprenant les technologies d'assistance) puissent restituer des textes adjacents correctement, prévoir une alternative en mode texte linéaire (sur la page concernée ou sur une autre) pour toutes les tables qui formattent le texte en colonnes parallèles et qui ajustent le texte sur la largeur de la colonne.							AAA
10.4	Jusqu'à ce que les agents-utilisateurs puissent gérer correctement les contrôles vides, placer du texte pour occuper l'espace dans les champs vides des formulaires [boîtes de textes et lignes d'entrée de texte].					Ce critère est deprécié.		AAA
10.5	Jusqu'à ce que les agents utilisateurs (comprenant les technologies d'assistance) puissent gérer correctement les liens hypertextes adjacents, insérer entre ces liens des caractères imprimables non-hypertextes.					Les liens sont groupés par listes et <div>.	L'utilisation de l'attribut tabindex pourrait rendre la navigation plus pratique.	AAA
Directive 11. Utilisation des technologies et directives du W3C.
11.1	Utiliser les technologies du W3C lorsque elles sont disponibles et adaptée à une tache. Utilisez les dernières versions supportées.						On trouve parfois des identifiants identiques.	AA
11.2	Eviter d'utiliser les options des technologies du W3C qui ne sont plus supportées.							AA
11.3	Fournir des informations de manière à ce que les utilisateurs puissent recevoir les documents selont les préférences qu'ils ont spécifiées. (par ex. la langue, le type de contenu, etc.)					Il n'y a pas de téléchargement.		AAA
11.4	Si, malgré vos efforts vous ne parvenez pas à produire une page accessible, créez un lien vers une autre page accessible, qui utilise les technologies du W3C, et qui présente une information (ou fonctionnalité) équivalente, et est mise aussi régulièrement que la page (originale) innacessible.							A
Directive 12. Fourniture d’informations de contexte et d’orientation.
12.1	Donner un titre à chaque cadre pour faciliter l'identification et la navigation entre cadres.					Il n'y a pas de cadres.		A
12.2	Décrire l'objectif des cadres et la manière dont les cadres interagissent les uns avec les autres, si ce n'est pas évident à la la seule lecture des titres.					Il n'y a pas de cadres.		AA
12.3	Lorsque c'est approprié, diviser les grands blocs d'information en groupes plus petits et plus facilement manipulables.					Dans les listes de classes, les classes pourraient être groupées par groupes de classes.		AA
12.4	Associer les étiquettes avec leurs éléments de contrôle de manière explicite.					Les étiquettes ne sont pas explicitement associées avec leurs éléments de contrôle, il n'y a pas d'attribut for.	Les étiquettes devraient être utilisées avec l'attribut id, pour être compatibles avec IE6.	AA
Directive 13. Fourniture de mécanismes de navigation clairs.
13.1	Identifier clairement la cible de chaque lien.					Certains liens n'ont pas de title. Les liens des menus contextuels ont des title identiques, alors qu'ils ne pointent pas la même cible.	Le title pourrait être dans le lien plutôt que dans l'image.	AA
13.2	Prévoyez des meta-données pour ajouter des informations d'ordre sémantique aux pages et aux sites.					Les méta-données sont indiquées.		AA
13.3	Fournir des informations concernant la mise en page générale d'un site. (par ex. la carte d'un site, ou une table présentant le contenu).					Les blocs de contenu sont bien identifiés mais les titres ne sont pas assez pertinents.	Ajouter un plan de l'interface d'administration, pour voire toutes les fonctionnalités en un coup d'œil.	AA
13.4	Utiliser les mécanismes de navigation de manière cohérente.						Préférer les liens internes.	AA
13.5	Prévoir des barres de navigation pour mettre en avant et donner accès aux mécanismes de navigation.							AAA
13.6	Regrouper les liens de même nature, identifier le groupe (pour les agents-utilisateurs), et jusqu'à ce que les agents utilisateurs le permettent, donner un moyen de s'affranchir du groupe.					Les liens de même nature sont groupés (top navigation bar), mais il n'y a pas de moyen de s'affranchir du groupe.	Liens internes.	AAA
13.7	Si l'on prévoit des fonctions de recherche, il convient de rendre possibles plusieurs types de recherches, correspondant à différents niveaux de compétances et à différents choix.							AAA
13.8	Placer des informations distinctives au début des en-têtes, des paragraphes, des listes etc.							AAA
13.9	Fournir des informations sur les regroupements de documents (par ex. les documents qui comprennent plusieurs pages, etc.).						Dans le head, balise "link" vers "prochain/précédent".	AAA
13.10	Prévoir des moyens pour s'affranchir de l'art ASCII prenant plusieurs lignes.					Il n'y a pas d'art ASCII.		AAA
Directive 14. S’assurer que les documents sont clairs et simples.
14.1	Utiliser le langage le plus clair et le plus simple possible adapté au contenu de votre site.							A
14.2	Associer du contenu visuel ou audio au texte, lorsque cela peut faciliter la compréhension d'une page.					Du texte supplémentaire n'est pas utile.		AAA
14.3	Créer un style de présentation cohérent pour toutes les pages.							AAA

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.