Auditeur d'accessibilité HTML

La plupart des vérifications rapides d'accessibilité se résument soit à une analyse superficielle par mots-clés, soit à une bibliothèque lourde à laquelle vous devez faire confiance comme une boîte noire. Cet outil emprunte une troisième voie : il analyse le code HTML que vous collez à l'aide du DOMParser intégré du navigateur — pas de axe-core, pas de bibliothèque d'accessibilité externe, aucun téléchargement — puis parcourt l'arbre DOM obtenu avec un ensemble de vérifications écrites maison qui reflètent les motifs d'échec réels et courants des WCAG 2.1. Cela signifie que la logique est entièrement inspectable et que l'audit s'exécute entièrement dans votre navigateur : le balisage que vous collez et toute paire de couleurs que vous testez ne sont jamais téléversés ni envoyés où que ce soit.

Les vérifications couvrent les échecs qui apparaissent le plus souvent dans les pages réelles : les éléments <img> sans aucun attribut alt (un véritable échec WCAG, distinct de l'attribut alt="" volontairement vide utilisé pour les images décoratives, qui est correctement laissé sans signalement), les champs de formulaire sans moyen pour les technologies d'assistance de savoir à quoi ils servent (vérifié par rapport à chaque chemin réel vers une étiquette — un <label for> correspondant, le fait d'être enveloppé dans une <label>, ou un attribut aria-label/aria-labelledby), les niveaux de titre qui sautent sans avertissement (un <h1> directement suivi d'un <h3>, ou un document sans aucun <h1>, ou avec plus d'un), les liens sans href ou avec un texte vague et hors contexte comme « cliquez ici » ou « lire la suite », et l'absence d'un attribut lang lorsqu'un document HTML complet (et non un simple fragment) est collé.

L'élément remarquable est le véritable calcul de contraste, pas une heuristique superficielle du type « semble lisible ». Pour tout élément portant un style color et background-color en ligne, l'outil lit les deux valeurs, les résout en véritables nombres RVB via le moteur CSS du navigateur (de sorte que les hex, rgb(), hsl() et les couleurs nommées comme « tomato » fonctionnent toutes à l'identique), puis calcule la luminance relative WCAG exacte pour chacune — L = 0,2126×R + 0,7152×V + 0,0722×B, chaque canal étant d'abord corrigé gamma à l'aide de la véritable courbe de transfert sRGB — avant de les combiner dans la formule officielle du rapport de contraste, (L la plus claire + 0,05) / (L la plus sombre + 0,05). La font-size et le font-weight propres de l'élément déterminent si les seuils plus stricts pour le « texte normal » ou les seuils plus indulgents pour le « grand texte » (18pt+, ou 14pt+ en gras) s'appliquent, et le résultat est comparé simultanément aux quatre vrais nombres WCAG : 4,5:1 et 3:1 pour le AA, 7:1 et 4,5:1 pour le AAA — jamais réduit à un unique verdict factice bon/mauvais.

Il s'agit d'un sous-ensemble délibérément honnête et pragmatique d'un audit d'accessibilité complet, pas d'un outil de certification : il n'évalue pas l'interactivité pilotée par JavaScript, les motifs de widgets ARIA au-delà de l'étiquetage de base, l'ordre de focus au clavier, ni tout ce qui nécessite de réellement afficher et exécuter la page. Considérez-le comme une première passe rapide qui détecte certains des échecs WCAG les plus courants et les plus lourds de conséquences — texte alternatif manquant, champs sans étiquette, hiérarchie de titres défaillante, texte à faible contraste et liens vagues — avant la publication d'une page, en complément (et non à la place) d'une revue manuelle complète ou d'un outil d'audit dédié pour tout ce qui est destiné à la production.