Pages générées par l’IA d’un constructeur : l’audit d’accessibilité qui fâche

« Dans chaque page web, l’information est-elle structurée par l’utilisation appropriée de titres ? » Cette question, c’est le critère 9.1 du RGAA, et c’est la première que pose un auditeur devant une page issue d’un assistant IA de constructeur. Cet article ouvre le volet accessibilité de la série « IA et constructeurs de pages » : il ne traite pas de la performance, sujet du suivant, mais d’une grille de contrôle précise, critère par critère, applicable à Elementor, Divi ou tout autre outil qui génère des sections, des textes et des images à partir d’une consigne.

Ce que l’on peut affirmer, et ce que l’on doit vérifier

Commençons par une précaution de méthode. Aucun éditeur ne publie, à notre connaissance, d’engagement de conformité RGAA sur le contenu que son assistant génère. Les conditions d’utilisation de l’IA d’Elementor, par exemple, indiquent que les services « peuvent produire des résultats inattendus ou inexacts » (version consultée en septembre 2026, mention « Last updated: December 2023 »). Cet article ne prétend donc pas décrire ce que tel outil produit : il décrit ce qu’il faut contrôler, parce que rien ne garantit que le résultat soit accessible.

Le cadre réglementaire mérite lui aussi une mise au point. Le référentiel en vigueur est le RGAA 4.1.2, dont chaque critère renvoie aux critères de succès de WCAG 2.1. Le site officiel du RGAA annonce une version 5 en cours de rédaction, avec une publication prévue fin 2026. Conséquence pratique : les critères ajoutés par WCAG 2.2, comme la taille minimale des cibles tactiles de 24 pixels CSS (2.5.8) ou le focus non masqué (2.4.11), ne figurent pas dans les tests du RGAA 4.1.2. Ils restent de bonnes pratiques à contrôler, mais vous ne pouvez pas les présenter à un client comme un critère RGAA.

Dernier point de cadrage : l’audit ci-dessous porte sur le code réellement rendu dans le navigateur, pas sur le contenu de l’éditeur. Une page générée puis retouchée à la main doit être auditée dans son état final.

Titres et structure : les critères 9.1, 9.2 et 8.9

Un assistant qui compose une page choisit le niveau de titre pour des raisons visuelles plus que structurelles. Le critère 9.1 du RGAA se décline en trois tests : la hiérarchie entre les titres est pertinente (9.1.1), leur contenu est pertinent (9.1.2) et tout passage qui joue le rôle de titre est balisé comme tel (9.1.3). Notez que le texte du critère n’impose pas un unique h1 : il demande une hiérarchie pertinente. Ne condamnez donc pas une page sur ce seul motif, mais un saut de h2 à h5 ou un titre visuel réalisé avec un paragraphe en gras tombe sous 9.1.1 ou 9.1.3.

Le critère 9.2 demande une structure de document cohérente : header, nav, main visible unique et footer. Le critère 8.9 interdit d’utiliser des balises uniquement à des fins de présentation. Une imbrication de conteneurs anonymes n’est pas fautive en soi, mais un titre réalisé avec un div stylé l’est.

Pour ne pas relire la page à l’œil nu, ce script s’exécute dans la console des outils de développement du navigateur et liste les titres avec leur niveau.

const niveau = (el) =>
  /^H[1-6]$/.test(el.tagName) ? el.tagName[1] : el.getAttribute('aria-level');

const titres = [...document.querySelectorAll('h1, h2, h3, h4, h5, h6, [role="heading"]')]
  .map((el) => ({ niveau: niveau(el), texte: el.textContent.trim().slice(0, 60) }));

console.table(titres);

Lisez ensuite la colonne des niveaux comme un plan : chaque saut de plus d’un niveau vers le bas est à examiner, de même qu’un titre dont le texte est vide ou générique.

Images et textes alternatifs : les critères 1.1, 1.2 et 1.3

Le RGAA distingue trois questions. Chaque image porteuse d’information a-t-elle une alternative textuelle (1.1) ? Chaque image de décoration est-elle correctement ignorée par les technologies d’assistance (1.2) ? Quand une alternative existe, est-elle pertinente (1.3) ? Une génération automatique peut échouer sur les trois : pas d’attribut alt, un alt rempli pour une image purement décorative (qui sera alors lue pour rien), ou un alt qui décrit la scène fabriquée par le modèle au lieu de la fonction de l’image dans la page.

Le cas typique à surveiller est l’image générée à partir de la consigne elle-même : son texte alternatif reprend parfois la consigne d’origine, qui décrit une intention visuelle et non le contenu utile. Le critère 1.3 ne se contrôle pas par script, puisqu’il demande un jugement de pertinence. Le script suivant ne fait que dresser la liste des cas à relire.

const images = [...document.querySelectorAll('img')].map((img) => ({
  src: img.currentSrc.split('/').pop(),
  alt: img.getAttribute('alt'),
  suspect:
    img.getAttribute('alt') === null ||
    /\.(jpe?g|png|webp|avif|svg)$/i.test(img.getAttribute('alt') || '') ||
    (img.getAttribute('alt') || '').length > 150,
}));

console.table(images.filter((i) => i.suspect));

Un alt vide n’est pas une erreur : c’est la bonne réponse pour une image décorative. Le script ne signale que l’absence de l’attribut, un nom de fichier utilisé comme texte et un texte manifestement trop long. Le reste, c’est votre lecture.

Contrastes, boutons et liens : critères 3.2, 3.3, 6.1 et 11.9

Pour le contraste du texte, le critère 3.2 fixe un rapport d’au moins 4,5:1 pour le texte sans graisse de moins de 24 pixels et pour le texte en gras de moins de 18,5 pixels, et 3:1 au-delà de ces tailles. Le critère 3.3 applique 3:1 aux composants d’interface et aux éléments graphiques porteurs d’information. Un assistant qui choisit une palette d’après une consigne comme « moderne et pastel » produit facilement un texte clair sur un fond clair, ou un texte posé sur une image dont le contraste varie d’un point à l’autre. Le sélecteur de couleur des outils de développement affiche le rapport calculé ; pour un texte sur image, contrôlez le point le plus défavorable.

Pour les boutons, la situation est plus subtile qu’elle n’en a l’air. Le critère 11.9 du RGAA porte sur les boutons des formulaires. Un bouton en dehors d’un formulaire, par exemple une icône de menu ou un bouton de fermeture, relève de la règle WCAG 4.1.2 (nom, rôle et valeur) et, dans le RGAA, peut être rattaché au critère 7.1 sur la compatibilité des scripts avec les technologies d’assistance. Les liens suivent le critère 6.1 : l’intitulé seul, ou additionné au contexte, doit permettre de comprendre la fonction et la destination. Une série de boutons « En savoir plus » identiques est un classique des sections générées.

• Un bouton ou un lien dont le seul contenu est une icône, sans aria-label, sans texte masqué visuellement et sans title, n’a pas de nom accessible.
• Un nom accessible qui ne reprend pas l’intitulé visible viole le critère 11.9.2 pour les boutons de formulaire.
• Un div ou un span muni d’un écouteur de clic n’est ni focalisable au clavier ni annoncé comme bouton.
• Un lien « Cliquez ici » répété dix fois, sans contexte distinct, échoue au critère 6.1.

const interactifs = [...document.querySelectorAll('a[href], button, [role="button"]')];

const sansNom = interactifs.filter((el) => {
  const texte = el.textContent.trim();
  const altImage = el.querySelector('img[alt]:not([alt=""])');
  return !texte && !altImage &&
    !el.getAttribute('aria-label') &&
    !el.getAttribute('aria-labelledby') &&
    !el.getAttribute('title');
});

console.log(sansNom);

Ce filtre est une approximation : il ignore les noms fournis par du contenu CSS et les icônes en svg munies d’un titre interne. Pour le nom réellement calculé, consultez l’onglet d’accessibilité des outils de développement du navigateur, qui affiche le nom accessible de l’élément sélectionné.

Ordre de lecture et de tabulation : critères 10.3 et 12.8

Les mises en page à base de conteneurs flexibles rendent possible un écart entre l’ordre visuel et l’ordre du code, par exemple avec flex-direction: row-reverse ou la propriété order. Le critère 10.3 du RGAA teste ce point en demandant de désactiver les feuilles de style et de vérifier que l’information reste compréhensible : c’est l’équivalent du critère WCAG 1.3.2 sur la séquence significative. Le critère 12.8 demande que l’ordre de tabulation soit cohérent. Sa note précise qu’il n’est pas obligatoire que la tabulation suive l’ordre de lecture naturel, tant que les éléments sont atteints dans un ordre cohérent.

Le protocole est court. Désactivez les styles, lisez la page de haut en bas. Puis parcourez-la avec la touche de tabulation et Maj+Tab : le focus doit rester visible (critère 10.7) et ne jamais disparaître dans un menu ou une fenêtre masqués. Si une section générée contient un menu mobile ou une fenêtre modale, vérifiez aussi qu’à l’ouverture le focus se repositionne (test 12.8.2).

Une page générée n’est pas plus suspecte qu’une page écrite à la main, mais elle n’a pas été relue par quelqu’un qui connaît le critère : c’est à vous de jouer ce rôle avant la livraison.

Quand ne pas appliquer cette méthode, et comment la cadrer

Les scripts de cet article ne remplacent pas un audit. Ils repèrent des indices, pas des conformités : un titre correctement balisé peut être absurde, un alt présent peut être faux. Sur un site de plusieurs dizaines de pages, contrôlez un échantillon représentatif de gabarits plutôt que chaque page, puis corrigez au niveau du modèle.

N’utilisez pas non plus une seconde passe de l’assistant comme correctif unique : Elementor décompte par exemple 20 crédits par correctif d’accessibilité par IA, alors que ses analyses d’accessibilité ne consomment aucun crédit (tableau de consommation publié sur sa page de tarifs). Une correction automatique se relit comme n’importe quelle génération. Enfin, si la page relève d’une obligation légale, l’audit doit s’appuyer sur les tests officiels du RGAA, pas seulement sur ce parcours abrégé.

Conclusion

Retenez cinq contrôles rapides : plan des titres, textes alternatifs, contrastes, noms accessibles des boutons et des liens, ordre de lecture et de tabulation. Chacun correspond à un critère précis du RGAA 4.1.2, et aucun n’est garanti par le seul fait que la page vient d’un assistant. Cet article fait partie de la série « IA et constructeurs de pages » ; le suivant mesure ce que coûte une page générée en poids et en Core Web Vitals. Pour les critères cités, les sources de référence sont la liste officielle des critères et tests du RGAA et les critères de succès de WCAG, dont le texte de WCAG 2.2.