Que vous construisiez dans une fenêtre de discussion avec Lovable, Bolt, v0 ou Replit, ou que vous laissiez un agent de code comme Claude Code, Cursor ou GitHub Copilot écrire dans votre propre projet, une chose ne change pas : l’IA construit ce que vous demandez. L’accessibilité, c’est-à-dire rendre un site utilisable par les personnes en situation de handicap, n’apparaît de façon fiable que si vous la demandez. Cette page en est la version courte : cinq habitudes, un bloc d’instructions à coller dans n’importe quel outil et une méthode pour vérifier le résultat. Les guides par outil, en bas de page, indiquent où placer les instructions et quels problèmes surveiller.
Pourquoi l’accessibilité passe à la trappe
Les modèles d’IA apprennent à partir des sites existants, et la plupart ne sont pas accessibles. Lors de l’analyse menée par WebAIM en 2026 sur le million de pages d’accueil les plus visitées, 95,9 % présentaient des problèmes détectables par des tests automatiques. Un outil qui apprend du site moyen en reprend aussi les habitudes : texte gris clair, boutons réduits à une icône, formulaires sans étiquettes.
Trois autres choses jouent contre vous :
- Vous jugez avec les yeux. Un créateur vous montre l’apparence de la page, pas ce qu’en dit un lecteur d’écran (un logiciel qui lit l’écran à voix haute) ni son comportement au clavier seul.
- Les conversations oublient. Une demande faite vingt messages plus tôt peut ne plus compter quand l’IA réécrit une page.
- Chaque modification peut défaire une correction. Une nouvelle section ou une refonte peut faire revenir un problème déjà réglé.
Cinq habitudes qui évitent la plupart des problèmes
1. Placez vos instructions à un endroit permanent
Tout outil sérieux propose un endroit pour des instructions permanentes, prises en compte à chaque demande : la « knowledge » ou les instructions de projet dans les créateurs par chat, un fichier d’instructions dans les agents de code. Mettez-y vos règles d’accessibilité une fois pour toutes au lieu de les répéter dans chaque prompt. Les guides par outil vous indiquent où se trouve cet endroit.
2. Demandez de vrais boutons, de vrais liens et des étiquettes visibles
Demandez du « HTML sémantique » : des éléments de page qui disent ce qu’ils sont. Un bouton doit être un vrai bouton, pas une zone qui réagit au clic, pour fonctionner avec la touche Tab et être annoncé par un lecteur d’écran. Chaque champ de formulaire a besoin d’une étiquette visible au-dessus, pas seulement d’un texte gris d’exemple qui disparaît dès qu’on tape.
3. Gardez le focus visible
Quand on parcourt une page avec la touche Tab, un cadre ou un soulignement montre où l’on se trouve. C’est l’indicateur de focus. Les designs « épurés » le suppriment souvent. Demandez un style de focus net sur chaque lien, bouton et champ, et ne laissez jamais l’IA le retirer sans le remplacer.
4. Vérifiez le contraste
Le contraste est la différence de luminosité entre un texte et son fond. Un texte normal demande un rapport d’au moins 4,5:1, un grand texte 3:1, selon les WCAG 2.2, les règles internationales d’accessibilité sur lesquelles s’appuient la plupart des lois, dont le RGAA en France. Le gris pâle sur blanc, le texte sur photo et les tons pastel sont les coupables habituels. Vérifiez aussi le mode sombre si votre site en a un.
5. Rédigez vous-même les descriptions d’images et les textes de liens
Le texte alternatif est la courte description qu’un lecteur d’écran lit à la place d’une image. L’IA peut le remplir, mais elle ne sait pas que la photo montre votre boutique ou que le graphique porte sur les réservations de l’année. Pour les liens, c’est pareil : six fois « En savoir plus » sur une page n’apprend rien à une personne qui utilise un lecteur d’écran. Relisez les deux vous-même à chaque nouvelle image ou nouveau lien.
Des instructions pour tous les outils
Collez ce bloc dans les instructions permanentes de votre outil avant de commencer. Dans un outil qui n’en a pas, collez-le en tête de votre premier message. Si votre site existe déjà, ajoutez-le, puis demandez à l’IA de revoir chaque page à sa lumière.
Règles d’accessibilité pour tout ce projet (objectif : WCAG 2.2 niveau AA). Respecte-les à chaque modification et signale-moi quand une demande les contredit. - HTML sémantique : header, nav, main, footer, de vrais button pour les actions et de vrais a pour les liens. Jamais de div, span ou carte cliquable à lui seul. - Chaque champ de formulaire a une étiquette visible qui lui est liée. Un placeholder n’est jamais la seule étiquette. Affiche les erreurs en texte à côté du champ, pas seulement dans un toast ou en couleur. - Chaque bouton ou lien réduit à une icône a un nom accessible dans la langue du site, par exemple "Ouvrir le menu". - Garde un style de focus bien visible sur chaque élément interactif. Ne supprime jamais le contour sans remplacement visible. - Contraste du texte d’au moins 4,5:1 (3:1 pour les grands textes, icônes, bordures de champs et focus), en mode clair et sombre. - Les images porteuses de sens ont un texte alternatif qui décrit leur rôle ; les images décoratives ont alt="". Demande-moi quand tu ne peux pas savoir ce que montre une image. - Le texte d’un lien dit où il mène. Pas de "cliquez ici" ni de "en savoir plus" répétés. - Indique la langue de la page sur l’élément html (lang="fr") et donne à chaque page un titre unique. Un seul h1 par page, titres dans l’ordre. - Tout fonctionne au clavier seul. Les boîtes de dialogue prennent le focus, se ferment avec Échap et le rendent ensuite. - Respecte prefers-reduced-motion. N’utilise jamais la couleur seule pour transmettre une information.
Vérifier, corriger, revérifier
Inutile de lire du code. Il vous faut une routine à répéter jusqu’à ce que les problèmes importants aient disparu.
- Publiez un aperçu à une adresse web publique. Un outil de vérification ne peut pas atteindre une page qui n’existe que dans le créateur ou derrière une connexion.
- Vérifiez la page avec ibin. Vous obtenez une liste de problèmes en langage clair, classés selon ce qu’il faut corriger en premier, avec une vue rapprochée de l’endroit concerné.
- Copiez la correction. Chaque problème a un bouton « Copier les instructions pour un outil d’IA ». Collez le résultat dans votre créateur ou votre agent. Il demande une réparation dans le site lui-même, pas un correctif posé par-dessus.
- Corrigez un problème à la fois. Des demandes courtes et ciblées marchent mieux qu’une longue liste.
- Revérifiez jusqu’à ce que les problèmes les plus urgents aient disparu. Connectez-vous ensuite pour vérifier jusqu’à 200 pages du même site, car les créateurs répètent partout le même menu, le même pied de page et les mêmes formulaires.
- Activez les vérifications hebdomadaires pour être prévenu quand une modification ultérieure fait revenir un problème.
Les vérifications automatiques trouvent environ un tiers à la moitié des problèmes. Faites donc aussi le test clavier en dix minutes sur votre page d’accueil et votre formulaire le plus important. Les guides de correction expliquent chaque problème en langage clair quand vous voulez comprendre une correction.
Ce qui demande encore un regard humain
Aucune IA et aucune vérification automatique ne peut décider si une description d’image est juste, si un texte de lien se comprend hors contexte, si vos textes se lisent facilement ou si un parcours de réservation paraît logique. Le second regard de l’IA, proposé en option par ibin, note les descriptions d’images, les textes de liens, l’utilisation au clavier et la langue de 1 à 5, pour vous montrer où regarder en premier. Ces notes sont des pistes, pas des verdicts. Si vous le pouvez, demandez à quelqu’un qui utilise chaque jour un clavier ou un lecteur d’écran d’essayer votre site.
Les guides par outil
Chaque guide présente ce que l’outil génère, où se trouvent ses instructions permanentes, un bloc à coller adapté à l’outil et des prompts de suivi pour ses problèmes typiques.
- Lovable : knowledge du projet et de l’espace de travail
- Bolt : knowledge du projet et hébergement de Bolt
- v0 : Instructions, via le bouton + de la zone de saisie
- Replit : le fichier d’instructions de l’agent Replit
- Agents de code : Claude Code, Cursor, GitHub Copilot et outils similaires
Pour une explication plus longue avec une liste complète de prompts de suivi, lisez Site créé avec l’IA ? Rendez-le accessible dès le premier prompt.
Vérifiez votre site créé avec l’IA
Publiez un aperçu et vérifiez gratuitement une page avec ibin. Utilisez « Copier les instructions pour un outil d’IA » sur chaque problème, collez-les dans votre créateur et revérifiez jusqu’à ce que les problèmes urgents aient disparu.
Voyez où en est votre site
Vérifiez gratuitement une page, sans compte. Vous recevez une liste claire de ce qu’il faut corriger en premier, avec des images de l’endroit où se trouve chaque problème.