Analyser automatiquement des pages Web, ça semble simple mais c’est très compliqué. Il y a quelques semaines, Karl Groves, consultant américain a comparé plusieurs outils d’analyse d’accessibilité. Les résultats sont assez flatteurs pour Opquast reporting et pour une raison simple : Opquast reporting teste le DOM. Le quoi ?
C’est quoi le DOM ?
Le DOM c’est le Document Object Model. Au départ, ce terme peut vous sembler compliqué, je vais essayer de vous expliquer de quoi il retourne.
Pour faire simple, une page Web est constituée de contenus structurés. Le contenu, c’est du français, de l’anglais, des images, des vidéos… et la structure c’est du HTML.
Par exemple, je peux écrire
<p>Bonjour</p>
, mettre en place ce contenu structuré dans une page HTML, l’envoyer sur un serveur connecté au Web et le rendre ainsi disponible à des utilisateurs.
Maintenant, nous allons compliquer un peu : il se trouve qu’il est possible d’envoyer d’autres choses en plus de ce contenu structuré. Tout d’abord, il est possible et nécessaire d’envoyer de la mise en forme, avec des feuilles de style CSS mais aussi des interactions (les trucs qui permettent que ça remue, que ça secoue, que ça gigote) avec Javascript.
Dans le cas des CSS mais surtout de Javascript, il faut savoir deux choses :
- La prise en compte des CSS et l’exécution du code va s’exécuter sur le poste du client ;
- Il est parfaitement possible et fréquent de modifier grâce à Javascript le code HTML envoyé par le serveur.
Je peux donc envoyer un code HTML depuis un serveur, puis le modifier avec Javascript sur le code du client. Je peux ainsi ajouter des titres, des contenus alternatifs, enfin bref, faire ce que je veux. Je pourrais même envoyer une page presque vide et la remplir exclusivement avec Javascript.
Le code modifié qui s’affiche chez le client s’appelle le DOM. C’est celui que voit l’utilisateur. C’est le seul qui est vraiment important.
Opquast reporting, l’un des seuls outils à analyser le DOM
Karl Groves le sait bien et, pour vérifier que les outils d’évaluation de l’accessibilité (mais ce serait également vrai pour la qualité, le SEO, la performance…) fonctionnent correctement, il a construit une page Web dont le code HTML contient de multiples erreurs mais qui sont corrigées à l’aide de Javascript. Le HTML contient des défauts mais, grâce au Javascript, le DOM n’en contient plus.
Karl a étudié 13 outils en ligne et leur a demandé d’analyser cette fameuse page, appelée Mother Effing Tool Confuser. Les résultats sont à la fois sans appel et très flatteurs pour Opquast reporting, puisque nous sommes un des deux seuls outils testés au niveau international à analyser le DOM.
Nous ne trouvons aucune erreur d’accessibilité sur cette page.
On dit un grand merci à Olivier Meunier et Fabrice Bonny qui ont fait un boulot incroyable pour réussir ce tour de force. Et si Opquast reporting vous remonte des erreurs alors que le validateur W3C ne vous les signale pas, maintenant, vous savez pourquoi.
P.S. : Opquast reporting peut se planter sur certains tests, mais c’est un autre problème 😉
C’est entre autres pour cela que Opquast reporting vous signale des erreurs si vous avez un plugin jQuery fait à la va-vite qui va mettre des styles en ligne n’importe comment. 😉
J’ai l’impression que le lien vers l’article de Karl Groves a été oublié.
http://www.karlgroves.com/2013/09/0…
PS: Karl’s solidarschnock!
@Karl : ah mais non mais non, le lien est bien présent dans l’article (sur l’image). Mais les revendications de l’association des Karls a été entendue, j’ajoute des liens supplémentaires.