eZ Publish et Opquast
1. Critères conformes
Bonne pratique n°9 : Le code source des pages contient les informations relatives au jeu de caractères employé.
Avec une installation par défaut d'eZ publish, on obtiendra obligatoirement une balise comme celle-ci dans l'en-tête du document html généré :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
En effet, pour générer une page web, eZ publish utilise un modèle défini dans pagelayout.tpl qui appelle invariablement le modèle d'en-tête page_head.tpl qui contient entre autre ces instructions:
{section name=HTTP loop=$site.http_equiv}
<meta http-equiv="{$HTTP:key|wash}" content="{$HTTP:item|wash}" />
Dans un état de fonctionnement correct, eZ publish trouvera obligatoirement la valeur $site.http_equiv et complétera ainsi là ou les balises <meta http-equiv="..." content="..." />.
Bonne pratique n°11 : Le site n'emploie aucune technique destinée à bloquer ou gêner l'affichage et/ou la lecture du code source.
Il m'est impossible d'affirmer qu'un système eZ publish de base ne contienne aucun mécanisme bloquant ou gênant la lecture du code source n'ayant pas le temps matériel de vérifier tous les templates l'un après l'autre, car il y en a beaucoup trop. Cependant, je n'ai jamais vu quoi que ce soit qui se rapproche de près ou de loin à une telle activité qui serait d'ailleurs contradictoire avec la politique open source d'eZ Systems.
Bonne pratique n°12 : Le code source de toutes les pages contient une déclaration de type de document (doctype) conforme à la syntaxe définie par le W3C.
Le modèle de page par défaut défini dans le template "pagelayout.tpl" commence par la ligne suivante :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Cette doctype qui est bien conforme aux recommandations du W3C se retrouve donc sur toute page générée par eZ publish.
Bonne pratique n°21 : Les données financières sont exprimées dans une unité monétaire conforme à la norme internationale.
|
|
Comme en attestent les images ci-dessus, eZ publish gère différents types de devises et les templates par défaut les affichent sans problème.
Bonne pratique n°32 : Le format (extension du fichier ou lecteur logiciel) des fichiers proposés en téléchargement est indiqué.
Voici comment s'affiche, par défaut, un lien de téléchargement de fichier sous eZ publish:
L'extension du fichier est bien indiquée ainsi que sa taille.
Bonne pratique n°34 : La taille des fichiers proposés en téléchargement est indiquée.
Voir la bonne pratique n°32 ci-dessus.
Bonne pratique n°36: En cas de rejet des données saisies dans un formulaire, les champs contenant les données rejetées sont indiqués à l'utilisateur.
Observons ce qui se passe lorsque nous essayons d'envoyer un formulaire de contact sans renseigner aucun champ :
Par défaut, tous les champs incorrects sont indiqués dans un message d'erreur. Ce mécanisme est totalement intégré à eZ publish. En effet, chaque attribut de classe (ici "Sender Name", "Subject", "Message" et "Email") est configuré pour être soit facultatif, soit obligatoire. Dans le cas présent, tous sont obligatoires. Le message d'erreur est généré par le système d'erreur d'eZ publish et ne dépend pas du formulaire d'envoi de mail, il n'est donc pas nécessaire de vérifier ce fonctionnement sur chaque formulaire disponible dans le système.
Bonne pratique n°42 : Le nom du site et/ou le nom de l'auteur sont indiqués sur chaque page.
Le modèle de page standard défini dans le template "pagelayout.tpl" affiche le nom du site (ou son logo) en haut de la page et dans la balise <title>, donc le nom du site apparaît par défaut sur chacune des pages.
Bonne pratique n°46 : Les hyperliens de même nature ont des couleurs, des formes et des comportements identiques sur toutes les pages.
Toutes les règles d'apparence dans eZ publish sont définies dans des feuilles de style. Tous les éléments de même nature s'affichent donc de la même manière. Ce principe s'applique aussi aux liens.
Bonne pratique n°47 : Les hyperliens sont visuellement différenciés du reste du contenu.
Les feuilles de style inclues dans eZ publish affichent la plupart des hyperliens dans un bleu bien distinct et sous-lignés de manière à bien différencier les liens du contenu et ce, même sur des périphériques d'affichage limités en nombre de couleurs ou bien même si le visiteur souffre de daltonisme.
Bonne pratique n°61 : Sauf opération irréversible spécifiée, les boutons de navigation (précédent, suivant) permettent le déplacement dans l'historique des pages.
Rien ne me permet d'affirmer cela, car il faudrait là aussi vérifier les templates un à un, mais malgré tout le temps que j'ai pu passer sur des installations eZ publish, je n'ai jamais eu l'occasion de voir un tel comportement. J'avance donc que la bonne pratique n°61 est respectée mais reste à être prouver.
Bonne pratique n°63 : La consultation et la navigation sont possibles sur un écran configuré en 256 couleurs.
Voici la page d'accueil d'une version d'eZ publish 3.9.3 fraîchement installée vue en 256 couleurs:
En dehors, de l'aspect dénué d'esthétique, il reste cependant tout à fait possible de naviguer sur un tel site.
Bonne pratique n°70 : L'emplacement du menu principal de navigation est identique sur toutes les pages.
L'affichage du menu principal est directement géré par "pagelayout.tpl". Dans ce cas aussi, chaque page se comportera de la même manière en ce qui concerne l'affichage du menu principal et ce dernier sera toujours au même emplacement.
Bonne pratique n°73 : Le nombre de polices utilisées sur le site est inférieur ou égal à trois (sauf présentation de travaux ou produits graphiques).
Toute l'apparence d'un site eZ publish est, par défaut, dans les feuilles de style. Les polices utilisées sont définies dans une seule feuille de style: "core.css", et voici les lignes où elles apparaissent:
body
{
...
font-family: Arial,Helvetica,sans-serif;
...
}
pre, code
{
font-family: "Courier New",Courier,monospace;
...
}
input, select
{
font-family: Arial,Helvetica,sans-serif;
}
textarea
{
font-family: Arial,Helvetica,sans-serif;
...
}
input.button, button, input.defaultbutton
{
...
font-family: Verdana,Arial,Helvetica,sans-serif;
...
}
On distingue donc trois groupes d'éléments qui auront toujours la même police:
- "body", "input", "select" et "textarea"
- "pre" et "code"
- "input.button", "button", et "input.defaultbutton"
Il n'y aura donc jamais plus de trois polices à l'écran lorsque l'on utilise les feuilles de style fournies par défaut.
Bonne pratique n°82 : Le serveur envoie une page d'erreur 404 personnalisée.
Par défaut, eZ Publish retourne une page indiquant que celle demandée n'existe pas. Cela nécessite cependant que le serveur soit configuré comme il se doit et gère la réécriture d'URL. De plus à l'origine, cette bonne pratique doit être directement gérée par le serveur lui-même. eZ publish respecte donc cette bonne pratique, mais même si ce n'était pas le cas on ne pourrait pas le lui reprocher et cette bonne pratique compterait comme "non applicable" dans la nomenclature Opquast.
Bonne pratique n°86 : Chaque page comporte un titre significatif et représentatif du contenu du site.
Le titre de chaque page comporte le nom de la page, ainsi que les noms des éléments qui la contienne, ce qui à mon sens est assez significatif. Exemple: "Mon site / Mon Blog / Mon billet". L'ordre choisi permet même d'éviter de confondre les titres des pages dans les favoris lorsque le nom devient trop long.
Par exemple, si le sens était inversé, on pourrait avoir des fois:
- Mon site / Mon Blog / Mo...
- Mon site / Mon Blog / Mo...
- Mon site / Mon Blog / Mo...
Or par défaut, on aura:
- Mon billet 1 / Mon blog / ...
- Mon billet 2 / Mon blog / ...
- Mon billet 3 / Mon blog / ...
Bonne pratique n°156 : Si le site impose des pop-ups, celles-ci contiennent un bouton "fermer".
Toutes les pop-ups observées contiennent des boutons "annuler" qui ferme la fenêtre automatiquement et conservent les icônes habituelles "minimiser", "agrandir" et "fermer" en haut à droite.
Bonne pratique n°163 : Le soulignement est réservé aux hyperliens.
Si l'on parcourt les feuilles de styles par défaut, voici les seuls éléments ayant l'attribut "text-decoration: underline;" correspondant au soulignement:
- a
- a:hover
- div#sidemenu div.contentstructure li.currentnode a
- div#sidemenu div.contentstructure li.topchapter-selected li.currentnode a
Ces quatres éléments désignent tous des liens hypertextes.
Bonne pratique n°170 : Une famille générique de police est indiquée comme dernier élément de substitution.
Référez-vous à la bonne pratique n°73. Les seuls éléments pour lesquels les feuilles de style par défaut définissent une police de caractère sont soit "body", "input", "select", "textarea","input.button", "button" et "input.defaultbutton" qui ont tous la famille générique "sans-serif" pour dernière valeur de l'attribut "font-family", soit "pre" et "code" qui ont la famille générique "monospace" pour dernière valeur de cet attribut.
2. Critères non applicables
Bonne pratique n°1 : Le contenu alternatif de toutes les images est correctement indiqué.
Bien que les templates par défaut d'eZ Publish incluent l'attribut "alt" dans chaque balise image, le choix de remplir cette balise avec un contenu correspondant à l'image n'appartient qu'à l'utilisateur.
Bonne pratique n°57 : Le site propose au moins un moyen de contacter l'auteur et/ou le webmestre.
Bien que le site comporte par défaut une classe formulaire de contact, il n'appartient qu'à l'utilisateur de l'utiliser ou non. Le respect de cette bonne pratique dépend donc uniquement du bon vouloir de la personne qui s'occupe du site.
Bonne pratique n°176 : Les hyperliens adjacents sont toujours séparés par au moins un caractère imprimable ou une image.
Le fait que les templates par défaut d'eZ publish respectent cette bonne pratique est difficile à tester. Là aussi, il faudrait vérifier chaque template afin de savoir s'il ne peut pas exister un cas dans lequel deux liens hypertextes puissent ne pas être séparés par au moins un caractère imprimable ( par opposition à un caractère non imprimable comme l'espacement ou la tabulation) cependant l'expérience me donne envie de dire qu'il n'y a pas de tels cas dans les templates. En revanche, je ne peux pas considérer qu'eZ publish soit conforme à cette pratique, car en laissant la possibilité à des rédacteurs d'écrire deux liens hypertextes à la suite, il devient impossible de garantir le respect de celle-ci.
Bonne pratique n°185 : Le pays est précisé dans toutes les adresses postales.
L'utilisation de coordonnées personnelles dans une installation standard d'eZ publish n'est pas destinée à la partie publique du site. De ce fait, s'il existe bien une gestion de telles données, son évaluation n'est pas pertinente. Les seules coordonnées qui pourront être affichées seront celles que l'utilisateur aura rédigé grâce aux outils mis à sa disposition. Nous nous retrouvons donc encore dans un cas où le respect de la bonne pratique dépendra avant tout de l'utilisateur et non pas du système utilisé.
Bonne pratique n°186 : L'indicatif téléphonique du pays est précisé devant chaque numéro de téléphone.
Résultat identique à la bonne pratique n°185
3. Critères non conformes
Bonne pratique n° 38 : Les champs obligatoires des formulaires sont indiqués.
Bien qu'il soit possible de le faire de manière automatique, les champs obligatoires ne sont pas indiqués par défaut. Ils le sont dans l'interface d'administration, mais malheureusement pas encore lorsque l'on utilise la barre d'outils de l'eZ Website Interface en "front office".
Bonne pratique n°155 : Si le site impose des pop-ups, celles-ci n'apparaissent qu'une seule fois.
Malheureusement, je dois être honnête. Avec une installation standard eZ publish 3.9.3, l'extension eZ Website Interface 1.2.0 qui permet d'éditer du contenu en front office, c'est-à-dire sans devoir se rendre dans l'interface administrateur, oblige à utiliser des pop-up lors de l'ajout d'éléments dans un autre. Par exemple, lors de l'ajout d'une image à l'intérieur d'un article. Ce qui a, de temps en temps, pour conséquence (et j'en ai d'ailleurs fait l'expérience, sous firefox 2.0, en rédigeant ce rapport) de faire afficher une nouvelle pop-up lors de certaines opérations dans celle créée juste avant. Le problème a certainement dû être corrigé depuis, mais toujours est-il qu'il est présent dans la version étudiée.
Bonne pratique n°196 : Les informations destinées à des espaces publics peuvent être prévisualisées avant leur envoi définitif.
La perfection n'est pas de ce monde. La dernière bonne pratique de cette catégorie n'est pas respectée et celui qui en est le responsable, c'est le formulaire d'ajout de commentaire. Réservé à un espace public, il ne permet, cependant, que l'annulation du travail en cours ou bien son envoi.
4. Conclusion
Nous avons passé au crible toutes les bonnes pratiques de niveau 1 Opquast pour un site web standard réalisé à l'aide d'eZ publish.
Le résultat est élogieux: 86% de conformité . Il suffirait de résoudre les trois petites faiblesses de rien du tout pour obtenir le 100% tant convoité et passer la seconde étape, sachant que deux d'entre elles sont facilement modifiables par n'importe quel développeur php. Mais qu'en sera-t-il pour le problème des pop-ups?
Maintenant, deux questions se posent:
- eZ publish obtiendra-t-il le même score dans les catégories "E-commerce" et "Syndication" ?
- Quel serait le score d'un autre CMS soumis à la même évaluation?
