Étudier l’accessibilité d’un site une fois en ligne et en corriger les erreurs est bien, mais ce n’est pas la méthode la plus efficace pour faire un site accessible. Il est plus efficace d’étudier la capacité d’un outils de production à produire du contenu accessible. La publication du référentielle AccessiWeb CMS 1.0 apporte une méthodologie pour évaluer ces outils.
A l’instar du référentiel Accessiweb pour les WCAG 1.0, ce référentiel reprend les recommandations ATAG 1.0, et en donne une méthode d’évaluation complète permettant l’évaluation de la capacité des CMS à fournir des contenus compatibles avec le Label Accessiweb et par extension avec WCAG 1.0.
On retrouve la même structure avec les niveaux bronze, argent et or, et comporte 75 critères (43 de niveau Bronze, 22 de niveau Argent et 10 de niveau Or) et 136 tests (93 de niveau Bronze, 29 de niveau Argent et 14 de niveau Or), répartis en 15 thématiques (celles du référentiel Accessiweb, plus les thématiques Autres fonctionnalités et Général).
Travaillant beaucoup avec des CMS et plus particulièrement eZ Publish , j’ai déjà inscrit dans mon planning du mois de novembre une étude de l’accessibilité d’eZ Publish à l’aide de ce référentiel.
Rendez vous fin novembre pour mes conclusions
Concernant eZ Publish, il y a déjà eut quelques initiatives : http://pwet.fr/blog/ez_publish_et_l_accessibilite
C’est vrai qu’un travail à deja été effectué mais il se basait directement sur les guidelines pour le contenu de 1999. Donc, ce n’était ni sur un document qui en rapport avec le Web d’aujourd’hui ni sur la capacité de l’outils à produire du contenu accessible.
Certes mais je serais quand même étonné que les conclusions d’une étude basée sur les documents actuels soient fondamentalement différents.
J’avoue très franchement que je suis pas totalement en accord avec les études qui ont été faites, notamment celles de Rémi Farrot. Par ailleurs, l’accessibilité d’un site ne dépend pas uniquement de son éditeur WYSIWYG, il dépend également des autres champs. Il convient d’étudier chaque datatype, et de voir comment il faut les faire cohabiter pour produire un contenu accessible.
Par ailleurs, entre 1998 et aujourd’hui, des technologies sont apparus ( HTML 4.01, XHTML, DHTML, Ajax), mais la notion de multimedia (audio, video, animation, …) et les technologies d’assistance ont également évolués. Les critères ont donc évolués, mais surtout les techniques pour valider les critères ont également évolués (par exemple ARIA).
A mon sens, c’est un guide sur la bonne utilisation d’eZ Publish pour produire du contenu accessible. C’est la où il y a un travail intéressant à faire.
J’ai eu l’occasion de travailler sur un gros site avec comme besoin majeur l’accessibilité. Le niveau visé était bronze + (lire bronze + quelques points importants d’argent) du label d’accessiweb.
Le CMS utilisé était Typo3 avec un éditeur Wysiwyg customisé analysant le HTML généré et interdisant le code non accessible : 2 mois après le lancement du site, on nous a demandé d’être plus souple niveau vérification, car beaucoup trop de contrainte.
Il faut savoir qu’avoir un site accessible ne se limite pas à l’outil, mais à son utilisation : aucun développement ne peut empêcher de mettre un alt d’une image décorative. Les personnes / contributeurs doivent être formé à l’accessibilité.
Le pire est de sortir un site accessible, de s’en venter, et un mois après on se retrouve avec un site illisible pour les handicapés. Il suffit de voir le nombre d’entreprises ou d’intégrateur se disant « expert en accessibilité » et ne jamais avoir entendu parler des balises legend et caption …
Pour finir, j’avais eu des échos comme quoi les labels accessiweb n’avaient plus grandes valeurs … il faut avant tout faire en sorte que le site soit accessible, et non pas répondre à une liste de règle parfois inadéquat.
Bien sûr, la rédacteur est au final la seul personne qui pourra ou non garantir l’accessibilité. Cependant, il faut bien reconnaitre que les CMS disposent de méthode, de template qui ne sont pas compatible avec l’accessibilité, c’est sur ce point qu’il faut travailler en priorité.
Au vu de ce j’ai pu apprendre durant ma formation à Accessiweb, je peut difficilement dire que ce label n’a pas grande valeur. Après, il faut bien comprendre que le Label s’occupe aujourd’hui du web en tant que contenu (basé sur les WCAG 1.0 et bientôt sur les WCAG 2.0). Et, malheureusement beaucoup de gens transpose littéralement ces documents pour leurs applications Web. Or, il existe dans ce cas des référentiels plus adapté (ARIA).
Pour comparer, tu peut toujours chercher un email dans les pages blanches et dire il est nulle cette annuaire j’ai pas l’information que je veut. Par contre, si tu cherche un numéro de téléphone tu trouvera ton bonheur. Il faut juste savoir à quoi cela sert.
En ce qui concerne, l’interdiction de code non accessible dans un document WYSIWYG, je vois même pas comment c’est possible: interdit tu les changements de langue non marqué, les niveau de titres mal imbriqués, les liens non explicite, … . Peut tu donner plus de détails sur cette expérience, cela m’intéresse ?