Le , par Élie Sloïm - Accessibilité
Avertissement : cet article a été publié en 2012. Son contenu n'est peut-être plus d'actualité.
Nous poursuivons actuellement notre travail sur la check-list Accessibility first step. Bref rappel : cette liste initiée et portée par Aurélien Levy est un ensemble de tests à mener sur une page ou sur un template XHTML/CSS/JS pour vérifier si la page possède les pré-requis pour être accessible. Il s’agit de n’appeler l’expert accessibilité que lorsque ces pré-requis sont respectés. L’expert accessibilité, mais aussi toute personne formée sur ce sujet pourra alors intervenir sur l’accessibilité des contenus sans avoir à demander des modifications incessantes sur le code.
La version préparatoire de la check-list est disponible sur Opquast reporting, tous les tests sont automatisés (HTML, CSS et JS, et analyse du DOM - Document Object Model à la volée, y compris sur les échantillons multiples de pages, mais oui madame) et un atelier a été ouvert en vue de la production de la version 1 de la check-list.
Pour comprendre le chantier actuel, il faut savoir que l’ambition première d’Aurélien n’est pas de fournir une checklist d’évaluation rapide, mais de transmettre un ensemble de consignes ou d’instructions simples aux intégrateurs qui ne connaissent pas forcément ces fondamentaux. A ce sujet, je vous invite à lire un article d’Olivier Nourry, de Qelios, ainsi que les commentaires afférents.
D’après Aurélien, cette liste est en quelque sorte un manuel de survie. Cette observation doit vous permettre de comprendre pourquoi :
- Les intitulés actuels sont très directifs. “Mettre tel attribut”, “Ne pas mettre tel élément”. Ce n’est pas très sexy, c’est même à la limite du médiéval mais gageons que l’intégrateur pourra difficilement se soustraire à ces injonctions émises par un troisième dan de Kendo.
- La liste prévoit également un certain nombre de règles qui ne sont pas des erreurs d’accessibilité, mais plutôt des éléments qui, si nous n’y faisons pas attention, vont devenir des problèmes d’accessibilité. Des risques, en résumé.
La mise en place de cette check-list en tant qu’outil d’évaluation et la volonté d’en automatiser intégralement la vérification est un bonus que j’ai demandé et qui ne faisait pas partie du projet initial d’Aurélien. Nous sommes donc en train de réfléchir à la meilleure façon de combiner ces deux contextes : manuel d’instructions et checklist d’évaluation. Pour commencer à éclairer la question, j’ai proposé, dans une première étape, de séparer cette check-list en deux niveaux :
- Les erreurs sont des choses que vous pouvez corriger les yeux fermés ;
- Les risques sont des élément auxquels il faudra faire attention.
Aurélien a passé la liste en revue pour ventiler les critères en risques et en erreurs. Fabrice Bonny et moi-même, avions mis en place cette notion de risque et d’erreurs sur la version 0.9 (visible dans opquast reporting) et la version 1 actuellement en discussion dans l’atelier.
!Risques et erreurs
La bonne nouvelle, c’est qu’il y a 94 erreurs et seulement 30 risques, ce qui vous fait 94 erreurs à corriger sans réfléchir ;-) et 30 points à surveiller.
Si vous vous amusez un peu avec Opquast reporting (qui commence à devenir un outil fabuleux et ceux qui me connaissent savent que je ne me prive pas de le critiquer de temps en temps), vous verrez qu’il est très facile d’extraire les points en erreur et les points en risque.
Voici ce que donne l’analyse de l’accueil de Temesis.com avec Opquast reporting pour la check-list Accessibility first step, après avoir activé les filtres “Erreurs” et “Non conformes’ (vous pouvez cliquer sur les images pour les voir en grand) :
Et voici ce que ça donne sur le filtre “Risques” puis “Non conforme” :
Oui, je sais, un risque non conforme, c’est débile. Mais il faudra faire avec, car nous ne prévoyons pas de changer le libellé de “non conforme” en “Truc qu’on a évalué automatiquement et peut-être bien que si vous faisez pas gaffe des gens vont galérer pour accéder aux contenus”.
Sinon, vous ne le savez peut-être pas, Opquast reporting ne se contente pas seulement d’analyser le DOM, il vous dit à quel endroit du code se trouvent les erreurs. Je dis ça, je dis rien.
Le chantier de conception de la check-list n’est pas terminé mais vous avez déjà de quoi améliorer l’accessibilité de vos sites et de vos intégrations. N’est-ce pas?