À propos de l'analyse

Ce qu'elle vérifie

Deux choses. D'abord si une déclaration d'accessibilité existe et si elle contient ce qu'exige l'annexe V : comment les exigences sont satisfaites, un moyen de signaler un obstacle, l'autorité de contrôle, la preuve d'un suivi, et si une charge disproportionnée est invoquée. Ensuite un petit ensemble de défauts de code auxquels le HTML statique répond avec certitude, tel un attribut de langue absent ou une image dépourvue de tout attribut alt.

La déclaration est recherchée dans les liens de la page puis, à défaut, aux adresses conventionnelles employées dans la langue de la page.

Ce qu'elle ne peut pas vérifier

Le contraste des couleurs, la navigation au clavier, la visibilité du focus et la redistribution à 320 pixels exigent une page affichée avec ses feuilles de style, alors que ceci lit le HTML renvoyé par votre serveur. Ces critères sont nommés dans chaque rapport afin que leur absence ne soit pas prise pour une réussite.

Si un site est dessiné par JavaScript, les vérifications de code n'ont examiné qu'une coquille. Le rapport le dit, plutôt que d'annoncer un résultat propre qu'il n'a pas mérité.

Refusé n'est pas absent

Les protections anti-robots des grandes enseignes analysent fréquemment la connexion plutôt que l'agent utilisateur : une requête ordinaire est donc refusée là où un navigateur réussit. Dans ce cas, le rapport indique que nous n'avons pas pu conclure, jamais qu'aucune déclaration n'existe. Présenter un refus comme une absence serait une accusation que l'analyse ne peut soutenir.

Son comportement

• Une page, plus cinq requêtes au maximum pour trouver une déclaration.
• Délai de huit secondes par requête, plafond de deux mégaoctets par réponse.
• S'identifie dans l'agent utilisateur, avec un lien vers cette page.
• Refuse les adresses privées et réservées : elle ne peut donc servir à atteindre quelque chose à l'intérieur d'un réseau qui ne le doit pas.
• Lecture seule. Elle ne soumet aucun formulaire et ne suit aucune action.