2 articles
L'accessibilité numérique se mesure d'abord avec des outils dédiés (axe-core, Lighthouse, Pa11y) qui inspectent le DOM et les rôles ARIA. Mais une partie significative des règles WCAG se vérifie aussi visuellement : ratio de contraste texte/fond conforme à la norme AA, focus visible suffisamment apparent au clavier, taille des cibles tactiles atteignant 44 pixels, hiérarchie visuelle qui reflète la hiérarchie sémantique. Le test visuel n'est pas un substitut à un audit d'accessibilité, mais il en est un complément naturel et souvent négligé.
Les articles de cette page explorent ce croisement : comment détecter une régression de contraste introduite par une refonte de palette, comment vérifier que le focus state n'a pas disparu après une mise à jour CSS, comment tester systématiquement les modes sombres et les thèmes alternatifs sous l'angle de l'accessibilité, comment combiner un linter axe-core dans la CI avec un test visuel dédié aux états interactifs. On y aborde aussi les limites honnêtes — un test visuel ne dira pas si un aria-label est mal rédigé, ni si un screen reader interprète correctement la structure — mais il rattrape efficacement la classe de bugs où le code reste valide tandis que le rendu devient inutilisable. Une approche complémentaire, pas concurrente, des outils d'accessibilité spécialisés.
Comment le test visuel automatisé détecte les régressions d'accessibilité WCAG : contraste, taille de texte, focus visible, espacements. Guide complet avec FAQ.
Lire la suite →Comment le test visuel améliore-t-il la conformité WCAG ? Régressions de contraste, taille de texte et masquage d'éléments sont signalées tôt.
Lire la suite →