Auditeur d'accessibilité HTML

La plupart des contrôles d'accessibilité rapides sont soit une analyse superficielle de 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é au navigateur - pas de noyau d'axe, pas de bibliothèque d'accessibilité externe, rien de téléchargé - puis parcourt l'arborescence DOM résultante avec un ensemble de vérifications écrites à la main qui reflètent les modèles d'échec courants et réels 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échargés ni envoyés nulle part.

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'alt="" délibérément vide utilisé pour les images décoratives, qui n'est pas correctement signalé), des contrôles de formulaire sans moyen pour la technologie d'assistance de savoir à quoi ils servent (vérifiés par rapport à chaque chemin réel vers une étiquette - un <label for> correspondant, enveloppé dans un <label> ou un attribut aria-label/aria-labelledby), un en-tête. des niveaux qui sautent sans avertissement (un <h1> directement vers un <h3>, ou un document sans <h1> du tout, ou plusieurs), des liens sans href ou avec un texte vague et hors contexte comme "cliquez ici" ou "lire la suite", et un attribut lang manquant lorsqu'un document HTML complet (pas seulement un fragment) est collé.

L'élément le plus marquant est de véritables mathématiques de contraste, et non une heuristique superficielle « qui semble lisible ». Pour tout élément portant une couleur en ligne et une couleur d'arrière-plan, l'outil lit les deux valeurs, les résout en nombres RVB réels via le propre moteur CSS du navigateur (donc hex, rgb(), hsl() et les couleurs nommées comme « tomate » fonctionnent toutes de la même manière), et calcule la luminance relative WCAG exacte pour chacune — L = 0,2126 × R + 0,7152 × G + 0,0722 × B, chaque canal étant d'abord corrigé en utilisant la correction gamma. la véritable courbe de transfert sRGB – avant de les combiner dans la formule officielle du rapport de contraste, (L plus clair + 0,05) / (L plus foncé + 0,05). La taille et le poids de la police de l'élément déterminent si les seuils de « texte normal » plus stricts ou les seuils de « texte volumineux » plus indulgents (18 pt+ ou 14 pt+ gras) s'appliquent, et le résultat est vérifié par rapport aux quatre vrais nombres WCAG à la fois : 4,5 : 1 et 3 : 1 pour AA, 7 : 1 et 4,5 : 1 pour AAA — ne s'est jamais réduit à un seul faux verdict bon/mauvais.

Il s'agit d'un sous-ensemble délibérément honnête et pragmatique d'un audit d'accessibilité complet, et non d'un outil de certification : il n'évalue pas l'interactivité basée sur JavaScript, les modèles de widgets ARIA au-delà de l'étiquetage de base, l'ordre de focus du clavier ou tout ce qui nécessite le rendu et l'exécution de la page. Considérez-le comme une première passe rapide qui détecte certains des échecs WCAG les plus courants et les plus conséquents (texte alternatif manquant, champs sans étiquette, hiérarchie de titres brisée, texte à faible contraste et liens vagues) avant qu'une page ne soit expédiée, aux côtés (et non à la place) d'une révision manuelle complète ou d'un outil d'audit dédié pour tout ce qui est envoyé en production.