Test de 3 vérificateurs d’accessibilité en ligne

Date de publication : 2012-02-15, par [courrier électronique]Patrice Bourlon.

Partagez cet article sur Twitter WebAccessibilite.fr - Articles et cas pratiques accessibilité (format RSS 2.0)

Avertissement : cet article est publié seulement aujourd’hui, 15 février 2012, mais il a été écrit fin décembre 2011. Il est donc possible qu’entretemps, les outils ou les sites testés aient évolué. La réflexion a également progressé depuis le début 2012 sur certains des sujets abordés dans cet article au travers des projets [externe]Mipaw (piloté par AccessiWeb) ou [externe]Accessibility First Step (société Temesis).

Résumé : la vérification de l’accessibilité des pages Web repose en grande partie – les experts du domaine vous le confirmeront – sur une inspection manuelle des pages et du code source. Il existe cependant plusieurs outils, proposés sous la forme de services en ligne ou d’extensions des navigateurs, qui permettent d’inspecter ou d’auditer les pages sur une base automatique. J’ai testé 3 de ces outils ([externe]Opquast Reporting Inspecteur de pages, [externe]Tanaguru AXS et [externe]Wave) et présente ici les résultats de ces tests. Cet article est assez long ; si vous voulez aller à l’essentiel, vous pouvez sauter directement à la conclusion.

Sommaire de l’article

Champ d’application et limites de ces outils

Les vérificateurs d’accessibilité sont par nature limités à la réalisation des tests qui peuvent être automatisés : ils pourront par exemple, détecter la présence ou l’absence d’un attribut alt sur une image ; mais, pour poursuivre avec cet exemple, ils ne sauront par contre pas déterminer si le contenu de l’attribut alt d’une image est correct, ou non, au regard du contexte dans lequel cette image est utilisée – sauf bien entendu à élaborer un algorithme pertinent et cela risque, dans ce cas, de ne pas être simple !

Outre la vérification formelle des critères automatisables, ces outils peuvent également signaler à l’attention de l’évaluateur, les différentes composantes de la page susceptibles d’être concernées par la problématique de l’accessibilité et requérant une inspection manuelle plus approfondie.

Tout en reconnaissant les limites de ces outils, ceux-ci peuvent toutefois constituer une aide précieuse à plusieurs titres : dans le cadre de la préparation d’un audit ou d’une labellisation, pour dégrossir le travail d’analyse des pages ; pour fournir des indicateurs primaires permettant de mesurer et de suivre l’évolution de l’accessibilité d’un site ; et pour certains de ces outils (par exemple, Opquast Reporting Inspecteur de pages ou Tanaguru AXS), pour pouvoir évaluer un gros volume de pages (industrialisation du processus de vérification d’un site ou d’un parc de sites)…

Sommaire

Présentation succincte des 3 outils testés

Opquast Reporting Inspecteur de pages

Éditeur : [externe]Temesis.

L’inspecteur de pages Opquast Reporting est un service en ligne, en français, qui analyse le code « généré », tel qu’il est vu par les utilisateurs, après application des scripts et feuilles de styles. L’inspecteur évalue la page sur 321 critères de qualité et d’accessibilité, dont 79 critères pour le Référentiel général d’accessibilité pour les administrations (RGAA) (version 2.2.1) et 57, pour le référentiel AccessiWeb (version 2.1). L’outil établit ensuite un rapport détaillé montrant les résultats de l’inspection. L’inspecteur de page fait partie de la plate-forme Opquast Reporting.

Nouveau : Temesis a ajouté le 22 décembre dernier une nouvelle checklist Accessibility First Step de 122 critères automatisables dans son inspecteur de pages. Comme le mentionne [externe]Élie Sloïm dans son article de présentation de cet outil : « Cette liste n’a pas pour objectif de dire si votre site est accessible. Elle vous permettra de savoir si les fondamentaux de l’accessibilité sont en place. »

Dans le cadre de ces tests, j’ai utilisé la [externe]version gratuite de l’inspecteur Opquast Reporting proposée par l’éditeur (critères RGAA et AccessiWeb).

Tanaguru AXS

Éditeur : [externe]Open-S.

Tanaguru AXS est un service en ligne, en français, qui permet d’auditer l’accessibilité des pages Web (sur la base du code source « auteur ») au regard de 39 critères du référentiel AccessiWeb (version 2.1).

L’outil établit un rapport détaillé et produit un score exprimé en pourcentage : le score brut « initial » traduit les résultats pour les seuls critères qui peuvent être validés ou invalidés de façon automatique ; le score « pondéré » prend en compte les critères pour lesquels une analyse complémentaire humaine est requise, selon une formule propre à l’outil.

Dans le cadre de ces tests, j’ai utilisé la [externe]version gratuite de démonstration de Tanaguru AXS proposée par l’éditeur.

Wave

Éditeur : WebAIM.

Wave est un service en ligne gratuit, proposé en anglais ou en espagnol, qui permet de tester les pages au regard des exigences WCAG 2.0  sur la base du code source auteur. Cet outil prend en compte les éléments WAI-ARIA inclus dans les pages.

Dans le cadre de ces tests, j’ai utilisé dans un premier temps la [externe]version en ligne de Wave et, dans un second temps, la [externe]barre d’outils Wave (extension du navigateur Firefox). Si la version en ligne analyse le code source auteur, la version barre d’outils analyse le code source généré dans le navigateur de l’utilisateur.

Sommaire

Les tests ont porté sur un échantillon de 5 pages d’accueil : la page d’accueil de WebAccessibilite.fr (que je connais bien :-)) et 4 autres pages sélectionnées dans la liste des sites présentés sur le tout nouveau site « Observatoire Accessibilité » de la société Open-S : [externe]Office du tourisme du Beauvaisis, [externe]Lafarge.fr, [externe]Office du tourisme de Narbonne et [externe]Vinci.com.

Chacune de ces pages a été soumise aux 3 outils. J’ai ensuite cherché à vérifier manuellement la justesse des analyses automatiques réalisées. Voici les résultats pour chacune des 5 pages.

Sommaire

Résultats pour la page d’accueil de WebAccessibilite.fr

Opquast Reporting Inspecteur de pages

Date du test : 21 décembre 2011.

Le [externe]rapport d’inspection Opquast donne les résultats suivants pour les 79 tests RGAA :

L’outil relève une erreur d’accessibilité : « Validité du code HTML / XHTML au regard de la DTD déclarée » (ce qui correspond au [externe]test 9.4 du RGAA).

Inspection manuelle : l’inspection du code source confirme l’erreur relevée par l’outil ; le type de document déclaré est XHTML 1.0 strict, mais la page met en œuvre un certain nombre d’éléments ARIA qui ne font pas partie de la spécification.

Le rapport Opquast ne signale aucune erreur concernant les 57 critères testés du référentiel AccessiWeb 2.1 (liste non déployée).

Tanaguru AXS

Date du test : 21 décembre 2011.

Le rapport d’audit Tanaguru AXS donne un score brut de 100 % et un score pondéré de 75 %.

Pour les 39 critères AccessiWeb testés par l’outil, les résultats sont les suivants :

Il faut noter que la validité du code au regard du type de document déclaré ([externe]critère AccessiWeb 8.2) n’est pas testée dans cette version de l’outil.

Wave

Date du test : 21 décembre 2011.

Le [externe]rapport produit par Wave ne relève aucune erreur d’accessibilité dans la page et indique par ailleurs les dispositions prises en matière d’accessibilité (tels que par exemple, les éléments ARIA inclus dans la page), ainsi que les points requérant une évaluation humaine complémentaire.

La barre d’outils Wave ne signale aucune erreur d’accessibilité.

Sommaire

Résultats pour la page d’accueil de l’Office du tourisme du Beauvaisis

Opquast Reporting Inspecteur de pages

Date du test : 21 décembre 2011.

Le [externe]rapport d’inspection Opquast donne les résultats suivants pour les 79 tests RGAA :

L’outil relève ainsi 4 non-conformités :

  1. Échec sur le critère « Présence de l’attribut alt » ([externe]test 4.1 du RGAA) : au moins un élément <img> ne possède pas d’attribut alt.
  2. Échec sur le critère « Validité du code HTML / XHTML au regard de la DTD déclarée » ([externe]test 9.4 du RGAA).
  3. Échec sur le critère « Absence d’attributs ou d’éléments HTML de présentation » ([externe]test 7.8 du RGAA) : il a été trouvé au moins un attribut align dans la page analysée.
  4. Échec sur le critère « Absence de liens sans intitulé » ([externe]test 6.16 du RGAA) : au moins un élément a sans contenu textuel.

Inspection manuelle :

Le rapport Opquast relève en outre 4 erreurs d’accessibilité pour les 57 critères testés du référentiel AccessiWeb 2.1 (liste non déployée) : 3 de ces 4 erreurs recoupent celles déjà relevées en utilisant le RGAA, mais une nouvelle erreur d’accessibilité, la cinquième au total pour cette page, est cependant signalée sur le critère « Chaque champ de formulaire a-t-il une étiquette ? » ([externe]critère 11.1 AccessiWeb).

Cette cinquième erreur est confirmée par une inspection manuelle du code de la page : plusieurs éléments <select> de la page ne possèdent ni attribut title ni élément <label> (ex. <select id="OsSelChoixMoteur425">)

Tanaguru AXS

Date du test : 21 décembre 2011.

Le rapport d’audit Tanaguru AXS donne un score brut de 100 % et un score pondéré de 75 %.

Pour les 39 critères AccessiWeb testés par l’outil, les résultats sont les suivants :

Commentaire : pourquoi Tanaguru AXS ne mentionne-t-il aucune des 5 erreurs relevées par l’inspecteur de pages Opquast ?

Wave

Date du test : 21 décembre 2011.

Le [externe]rapport produit par Wave relève 2 erreurs d’accessibilité (2 liens sans intitulé, les 2 ancres déjà mentionnées) dans la page et indique par ailleurs les dispositions prises en matière d’accessibilité, ainsi que les points requérant une évaluation humaine complémentaire.

La version barre d’outils de Wave signale pour sa part 54 (!) erreurs d’accessibilité sur la page analysée (code source généré) : les erreurs sont concentrées sur le formulaire de réservation en ligne (absence d’étiquettes sur les éléments de formulaires) mais l’outil signale également l’absence d’attribut alt sur l’image, pointée par l’inspecteur Opquast ; de façon peu compréhensible, la version barre d’outils ne signale par contre pas l’erreur sur les 2 liens sans intitulé, relevée par la version en ligne.

Sommaire

Résultats pour la page d’accueil de Lafarge.fr

Opquast Reporting Inspecteur de pages

Date du test : 22 décembre 2011.

Le [externe]rapport d’inspection Opquast donne les résultats suivants pour les 79 tests RGAA :

L’outil relève ainsi 2 non-conformités :

  1. Échec sur le critère « Validité du code HTML / XHTML au regard de la DTD déclarée » ([externe]test 9.4 du RGAA).
  2. Échec sur le critère « Pertinence du résumé du tableau de données » : l’outil signale qu’il existe dans la page au moins un élément <table> avec un attribut summary vide ou non unique ([externe]test 11.10 du RGAA).

Inspection manuelle :

Le rapport Opquast relève en outre 2 erreurs d’accessibilité pour les 57 critères testés du référentiel AccessiWeb 2.1 (liste non déployée). La première erreur concerne le [externe]critère AccessiWeb 5.2 (attribut summary non pertinent) ; la seconde erreur concerne le [externe]critère AccessiWeb 5.6 (absence de cellules d’entêtes <th> dans les tableaux de données). Considérant qu’il n’y a pas de tableau de données dans la page, le critère 5.2 devrait être validé et le critère 5.6, non applicable.

Tanaguru AXS

Date du test : 22 décembre 2011.

Le rapport d’audit Tanaguru AXS donne un score brut de 93 % et un score pondéré de 71 %.

Pour les 39 critères AccessiWeb testés par l’outil, les résultats sont les suivants :

L’échec relevé par Tanaguru AXS concerne le [externe]critère AccessiWeb 6.2 et plus précisément le test 6.2.1 « Pour chaque lien texte ayant un titre de lien (attribut title), le contenu de cet attribut est-il pertinent ? ». L’inspection manuelle confirme les informations données par Tanaguru : au moins un lien texte dans la page est invalide sur le test 6.2.1 (titre de lien identique à l’intitulé du lien « hydromedia™, le nouveau béton drainant lafarge »).

Comme déjà mentionné plus haut, la validité du code au regard du type de document déclaré n’est pas testée ; l’erreur de codage relevée dans l’analyse Opquast n’est donc pas restituée par Tanaguru.

Wave

Date du test : 22 décembre 2011.

Wave ne relève aucune erreur d’accessibilité dans la page, que ce soit dans la version en ligne ([externe]voir le rapport) ou avec la barre d’outils.

Sommaire

Résultats pour la page d’accueil de l’Office du tourisme de Narbonne

Opquast Reporting Inspecteur de pages

Date du test : 23 décembre 2011.

Le [externe]rapport d’inspection Opquast donne les résultats suivants pour les 79 tests RGAA :

L’outil relève une erreur d’accessibilité : « Validité du code HTML / XHTML au regard de la DTD déclarée » (ce qui correspond au [externe]test 9.4 du RGAA).

Inspection manuelle : l’inspection du code source confirme l’erreur relevée par l’outil ; la page utilise un certain nombre d’attributs qui ne font pas partie de la spécification déclarée (XHTML 1.0 Strict).

Le rapport Opquast ne signale aucune erreur concernant les 57 critères testés du référentiel AccessiWeb 2.1 (liste non déployée).

Tanaguru AXS

Date du test : 22 décembre 2011.

Le rapport d’audit Tanaguru AXS donne un score brut de 92 % et un score pondéré de 71 %.

Pour les 39 critères AccessiWeb testés par l’outil, les résultats sont les suivants :

L’échec relevé par Tanaguru AXS concerne le [externe]critère AccessiWeb 6.2 et plus précisément le test 6.2.1 « Pour chaque lien texte ayant un titre de lien (attribut title), le contenu de cet attribut est-il pertinent ? ».

L’inspection manuelle confirme les informations données par Tanaguru : plusieurs liens ont un attribut title vide (ex. <a href="http://www.narbonne-tourisme.com/contact" title="">Contact</a>.

Wave

Date du test : 23 décembre 2011.

Wave ne relève aucune erreur d’accessibilité dans la page, que ce soit dans la version en ligne ([externe]voir le rapport) ou avec la barre d’outils.

Sommaire

Résultats pour la page d’accueil de Vinci.com

Opquast Reporting Inspecteur de pages

Date du test : 22 décembre 2011.

Le [externe]rapport d’inspection Opquast donne les résultats suivants pour les 79 tests RGAA :

L’outil relève une erreur d’accessibilité : échec sur le critère « Présence d’au moins un titre de hiérarchie de premier niveau (h1) » ([externe]test 10.1 du RGAA).

Le rapport Opquast signale la même erreur d’accessibilité au regard du référentiel AccessiWeb ([externe]critère 9.1 AccessiWeb).

Inspection manuelle : l’échec est confirmé, il n’y a pas de titre <h1> dans la page.

Tanaguru AXS

Date du test : 22 décembre 2011.

Le rapport d’audit Tanaguru AXS donne un score brut de 90 % et un score pondéré de 70 %.

Pour les 39 critères AccessiWeb testés par l’outil, les résultats sont les suivants :

L’échec relevé par Tanaguru AXS est identique à celui relevé par l’inspecteur Opquast.

Wave

Date du test : 22 décembre 2011.

Wave ne relève aucune erreur d’accessibilité dans la page, que ce soit dans la version en ligne ([externe]voir le rapport) ou avec la barre d’outils.

Sommaire

Conclusion

Quels enseignements tirer de ces tests ? Trois aspects me semblent intéressants à commenter à l’issue de ces tests, limités mais cependant suffisamment significatifs pour se former un premier avis sur :

La justesse des résultats

Le tableau ci-dessous récapitule les résultats obtenus par les différents outils sur l’échantillon de 5 pages.

Abréviations utilisées dans le tableau :

Nombre de non-conformités détectés par les outils testés
IPOR TAXS WAVA WAVB VIME
WebAccessibilite.fr 1 0 0 0 1
Beauvaistourisme.fr 5 0 2 54 5
Lafarge.fr 4 1 0 0 2
Narbonne-tourisme.com 1 1 0 0 2
Vinci.com 1 1 0 0 1

Sur cet échantillon de 5 pages, l’inspecteur Opquast et Tanaguru AXS arrivent sensiblement à égalité quant à la justesse des résultats : chaque outil signale bien des erreurs confirmées par l’inspection manuelle, mais omet aussi de signaler des erreurs, pourtant détectées par l’autre outil et confirmées par l’inspection manuelle. Un échantillon plus large pourrait peut-être faire apparaître des différences plus marquées sur ce point…

Mais, et ce n’est pas neutre pour la performance globale comparée de ces 2 outils – à leur stade de développement actuel, sans préjuger des améliorations à venir –, il y a 2 aspects qui peuvent faire la différence à l’avantage de l’inspecteur Opquast :

Concernant Wave :

Analyse du code source auteur ou du code source généré ?

La question de savoir quelle est la nature du code analysé (auteur ou généré) est importante pour la crédibilité d’un outil de vérification automatique. L’exemple de la page de l’Office du tourisme du Beauvaisis est parlant sur ce point. L’inspecteur Opquast détecte 5 erreurs d’accessibilité, alors que Tanaguru AXS n’en détecte aucune, et pour cause : 3 de ces 5 erreurs ne peuvent être détectées en analysant le seul code source auteur.

Il me semble peu pertinent de se contenter de l’analyse du code source auteur pour un outil de ce type : d’une part, de plus en plus de sites font un recours de plus en plus massif aux scripts pour intégrer des modules de type widgets ou autres ; d’autre part, l’accessibilité n’est typiquement pas une problématique qu’on peut se limiter à analyser du coté auteur (mon code est-il propre ?), mais pour laquelle il faut impérativement se placer du coté utilisateur (les contenus et fonctionnalités servis sont-ils bien accessibles ?).

La production automatisée d’un indicateur d’accessibilité…

On ne peut bien entendu pas réduire la vérification du niveau réel d’accessibilité d’un site à l’obtention d’un score plus ou moins élevé sur une batterie de tests automatiques : outre le caractère non exhaustif des tests automatisables, déjà mentionné, les erreurs d’accessibilité n’ont pas toutes le même impact pour l’utilisateur (diversité des handicaps, des outils, des contextes d’utilisation, etc.). Mais comme le mentionnent [externe]plusieurs spécialistes de la question, on peut aussi considérer que la corrélation est forte entre un faible niveau d’accessibilité observé avec des tests automatiques et celui observé avec des tests manuels.

Pour résumer, ce n’est pas parce qu’on ne trouve aucune erreur de façon automatique, qu’une page est forcément accessible… mais on sait quasiment à coup sûr que si un vérificateur automatique trouve de nombreuses erreurs sur une page, cette page va poser des problèmes d’accessibilité.

Dans cet esprit, un indicateur global qui permettrait d’évaluer ponctuellement et de suivre dans la durée les progrès réalisés en matière d’accessibilité par un site ou un parc de sites, serait le bienvenu ; et si cet indicateur pouvait être produit automatiquement, ce serait idéal dans une perspective d’industrialisation…

Au moins 3 conditions

Élaborer un indicateur d’accessibilité pertinent et fiable à partir d’une vérification automatique reste cependant très délicat et repose à mon avis sur au moins 3 conditions (en plus de la nécessité d’analyser le code généré, déjà abordée plus haut) :

L’indicateur produit par Tanaguru AXS

C’est à ce besoin d’un indicateur du niveau d’accessibilité d’un site, qu’a semble-t-il essayé de répondre l’équipe Open-S avec l’outil Tanaguru AXS : c’est le seul des 3 outils testés qui produit effectivement un score – et ce n’est pas un moindre mérite que de se lancer dans cette entreprise !

Dans sa version actuelle, le score produit par Tanaguru AXS me semble toutefois peu pertinent et de ce fait assez peu utilisable : nombre trop limité de critères pris en compte ; pas de pondération en fonction du poids relatif des différents critères ; pas de prise en compte du facteur de répétition des erreurs.

Le score affiché par l’outil pourrait même être « trompeur » et finalement devenir contre productif dans une perspective d’amélioration de l’accessibilité

Ainsi par exemple, dans l’échantillon analysé, la page d’accueil de l’Office du tourisme du Beauvaisis affiche un score non pondéré de 100 %, et un score pondéré de 75 %. Outre les 5 erreurs d’accessibilité qui ne sont pas détectées par l’outil (analyse du code source auteur), le nombre trop restreint de critères n’est pas significatif (39 critères testés sur un référentiel qui compte 305 tests unitaires) pour permettre de construire un indicateur.

Au mieux, on pourrait déduire des tests réalisés par l’outil que cette page d’accueil a un taux de conformité au référentiel utilisé (AccessiWeb 2.1), égal à 9 % (14 critères validés + 14 critères non applicables, sur un total de 305 tests), bien loin des 100 % affichés – et ce résultat ne voudrait pas dire grand-chose : les 305 tests unitaires ne sont bien entendu pas automatisables et cette approche resterait peu pertinente car elle ne prendrait pas en compte les autres conditions déjà mentionnées pour la production d’un indicateur.

Bref, le chantier reste largement ouvert !

Droit de réponse : je publierai avec plaisir à la suite de cet article, les éventuels remarques et commentaires que pourraient m’adresser les éditeurs ou utilisateurs des outils testés.