# Audit d’accessibilité assisté par IA : ce qui marche vraiment > Nous avons fait auditer trois sites clients par un LLM et par un expert accessibilité, puis comparé les résultats. Verdict nuancé, loin du remplacement pur et simple. - Auteur : Clément Hadrot - Publié le : 2024-11-19 - Mis à jour le : 2024-11-19 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/audit-accessibilite-assiste-ia/ ## L’essentiel - Le LLM repère vite le contraste et l'ordre de tabulation - Il manque les problèmes de contexte d'usage réel - L'expert reste indispensable sur les composants complexes Un client nous a demandé un audit d'accessibilité rapide avant une mise en conformité RGAA. Plutôt que de lancer directement notre expert, nous avons voulu tester une hypothèse : un modèle de langage capable d'analyser du HTML et des captures d'écran peut-il produire un audit exploitable, seul ou en complément d'un humain ? Nous avons choisi trois sites WordPress de tailles différentes, une boutique WooCommerce, un site vitrine et un site associatif, et fait tourner les deux méthodes en parallèle. Ce n'est pas un article sur la génération de textes alternatifs : nous l'avons déjà traité ailleurs. Ici, il s'agit du reste de l'audit — structure de page, navigation clavier, contraste, formulaires, ARIA — et de la fiabilité d'une IA pour ce travail précis. ## La méthode de test Pour chaque site, nous avons soumis le DOM rendu, une capture d'écran de chaque page clé et le CSS calculé à un modèle multimodal, avec une consigne détaillée reprenant les critères du WCAG 2.1 niveau AA. En parallèle, notre expert accessibilité a réalisé un audit manuel classique avec un lecteur d'écran, la navigation clavier et l'outil axe DevTools. Nous avons ensuite recoupé les deux listes d'anomalies, en classant chaque écart en trois catégories : détecté par les deux, détecté par l'IA seule, détecté par l'humain seul. ## Ce que l'IA détecte bien Sur les problèmes qui se lisent directement dans le balisage ou les valeurs de couleur, le modèle est efficace : ratios de contraste insuffisants sur les boutons secondaires, absence de `label` associé à un champ, hiérarchie de titres qui saute un niveau, liens au texte non explicite comme « cliquez ici ». Il a aussi correctement signalé un `tabindex` positif qui cassait l'ordre logique de tabulation sur le site associatif, une erreur que notre expert a confirmée en quelques secondes une fois le repère donné. > L'essentiel à retenir : Le LLM repère vite le contraste et l'ordre de tabulation ; Il manque les problèmes de contexte d'usage réel ; L'expert reste indispensable sur les composants complexes ## Ce qu'il rate systématiquement Les limites apparaissent dès qu'il faut juger un comportement dynamique. Un menu qui s'ouvre au clic mais reste inaccessible au clavier parce que le focus ne se déplace pas : le modèle voit le HTML statique, pas l'exécution du JavaScript, donc il passe à côté sauf si on lui fournit une trace d'interaction. Idem pour les messages d'erreur de formulaire injectés dynamiquement sans région `aria-live` : invisibles dans une capture, ils échappent complètement à l'analyse. Sur la boutique WooCommerce, l'IA n'a pas repéré que le sélecteur de variation de produit perdait le focus après sélection, un vrai problème pour un utilisateur au clavier. ### Le piège du faux positif Autre écueil : le modèle signale parfois des anomalies qui n'en sont pas, par exemple un contraste jugé insuffisant sur un texte en état `:hover` qui n'est jamais visible par défaut. Il faut un relecteur humain pour trier le bruit, sous peine de faire perdre du temps à l'équipe de développement sur des correctifs inutiles. ## Un protocole hybride qui fonctionne Notre conclusion pratique tient en un enchaînement simple : l'IA passe en premier sur l'ensemble du site pour produire une liste large d'anomalies statiques, classées par gravité. L'expert humain reprend cette liste, élimine les faux positifs, puis concentre son temps sur les parcours interactifs — formulaires multi-étapes, menus, composants accordéon, carrousels — qui restent son terrain de prédilection. Sur les trois sites testés, ce protocole a réduit le temps d'audit manuel d'environ un tiers, sans perte de qualité sur le rapport final. > Un audit IA sans relecture humaine donne un faux sentiment de conformité. Le vrai gain, c'est le temps gagné sur le tri, pas l'élimination de l'expertise. ## Ce que cela change pour un projet WordPress Concrètement, nous recommandons d'intégrer une passe IA automatisée dès la recette, avant même de solliciter un expert externe. Sur les thèmes personnalisés, cela permet de corriger les erreurs les plus évidentes — contraste, structure de titres, labels manquants — avant la revue humaine, qui se concentre alors sur les interactions complexes et le test réel avec un lecteur d'écran comme NVDA ou VoiceOver. - Passe IA automatisée sur le DOM rendu et les feuilles de style - Tri humain des anomalies et élimination des faux positifs - Audit manuel ciblé sur les composants interactifs et dynamiques - Nouvelle passe IA après corrections pour vérifier la régression ## En résumé Un audit d'accessibilité assisté par IA accélère le travail sans le remplacer. Sur nos trois sites tests, le modèle a retrouvé environ 61 % des anomalies critiques identifiées par l'expert, mais aucune des anomalies liées au comportement dynamique n'a été détectée sans intervention humaine. Le bon usage reste un pipeline en deux temps : l'IA pour le débroussaillage, l'humain pour le jugement sur l'expérience réelle.