Collez du HTML ou ouvrez un fichier pour obtenir les observations. La navigation au clavier et la mise en page affichée nécessitent un examen de l’interface.
Fonctionne localement dans votre navigateurCet audit au niveau source ne peut pas inspecter la disposition calculée, le comportement du clavier, les états dynamiques ou l'arborescence d'accessibilité réelle dans une application en cours d'exécution.
Utilisez les résultats comme liste de contrôle de révision, puis testez l'interface rendue avec un clavier, une arborescence d'accessibilité du navigateur et des personnes qui utilisent une technologie d'assistance.
Collez un document HTML ou un fragment dans l’éditeur, ou choisissez un fichier local, puis cliquez sur Auditer localement. Le rapport est construit uniquement à partir du balisage : ids en double, attribut lang absent ou vide, repère main manquant, titres H1 absents ou multiples, niveaux de titre qui sautent une étape, images sans attribut alt, champs sans label ni nom accessible, boutons et liens sans nom, textes de lien génériques, tableaux de données sans cellules d’en-tête, titres vides et iframes sans titre.
Le panneau de droite répond à une autre question : le rapport de contraste entre deux couleurs, calculé selon la définition du WCAG. Les deux panneaux fonctionnent dans cet onglet, la page marche donc hors ligne et aucun balisage, fichier ou couleur n’est téléversé.
Les points à vérifier sont des défauts démontrables à partir du texte : un id présent deux fois, une image sans attribut alt, un champ sans label, aria-label, aria-labelledby ni title exploitable, un bouton ou un lien sans nom accessible, un titre vide, une iframe sans titre et un élément role=button qui ne peut pas recevoir le focus clavier. Un label englobant, le nom par défaut qu’un navigateur donne à un champ submit ou reset et l’alt d’un champ image comptent comme des noms : le balisage valide n’est donc pas signalé.
Les informations dépendent du contexte : un document sans repère main, un ordre de titres qui saute un niveau, un lien dont tout le texte est « click here » et un tableau sans cellules th. Elles méritent un coup d’œil sans être toujours fautives. Quand plus aucun point à vérifier ne subsiste, le rapport le dit ; cela concerne cette liste de contrôle et ne prouve pas la conformité WCAG.
Chaque couleur est convertie en luminance relative avec la formule sRGB du WCAG (canal divisé par 255, puis / 12,92 ou ((c + 0,055) / 1,055) ^ 2,4) et le rapport vaut (L1 + 0,05) / (L2 + 0,05) : noir sur blanc donne 21:1 et une couleur sur elle-même 1:1. L’ordre des deux valeurs n’a pas d’importance.
Les niveaux affichés sont les seuils du WCAG : 4,5:1 pour le texte normal (AA), 3:1 pour le grand texte ainsi que pour les composants d’interface et les graphiques (AA), et 7:1 pour le texte normal en AAA. La taille, la graisse et le rendu réel ne font pas partie du calcul : la page indique donc le niveau atteint plutôt qu’un verdict. Seules les valeurs hexadécimales de 3 ou 6 chiffres sont acceptées ; rgb(), HSL et les noms de couleur reçoivent une indication au lieu d’un rapport.
L’audit lit le balisage et ne rend jamais le document. Le contraste réellement affiché, l’ordre de tabulation, les pièges au clavier, les états hover et focus, les régions live, les changements d’état ARIA, les sous-titres et tout ce qui n’existe que dans une application en cours d’exécution lui échappent. Les règles automatiques ne couvrent en outre qu’une partie du WCAG : les tests au clavier et au lecteur d’écran, le zoom et les espacements de texte restent manuels.
Le panneau de couleur vérifie une paire à la fois et ignore la taille de police : prenez le niveau comme un signal pour inspecter l’élément réel. Si une couleur ne peut pas être interprétée, la ligne de contraste du résumé revient à un tiret et le message sous les champs indique le format attendu.