Sites créés par IA : sont-ils vraiment accessibles ?

En partie. Les générateurs IA produisent du HTML sémantique, ce qui couvre gratuitement une part de l'accessibilité : titres, liens et champs de formulaire natifs. Ce qu'ils ratent presque toujours sans consigne explicite, c'est le contraste, l'ordre de focus au clavier et les étiquettes des composants sur mesure. Un site généré est un point de départ, pas un audit.

Cette réponse est plus utile qu'un oui ou un non, parce que l'accessibilité n'est pas un interrupteur. C'est un ensemble de propriétés concrètes qu'une page possède ou ne possède pas, et le code généré en possède certaines tout en ratant les autres selon un schéma assez prévisible.

Que veut dire « accessible » en pratique ?

Cela veut dire qu'une personne peut utiliser votre page avec un lecteur d'écran, au clavier plutôt qu'à la souris, avec un zoom navigateur à 200 %, avec une vision basse ou avec une gêne motrice qui rend le pointage imprécis. La référence de travail, ce sont les WCAG, organisées en niveaux A, AA et AAA.

Pour la plupart des projets, la cible réaliste est le niveau AA. C'est là que vivent les exigences que les gens remarquent vraiment : un contraste suffisant sur le texte, un indicateur de focus visible, une étiquette sur chaque champ, une alternative textuelle sur les images porteuses de sens et une page utilisable sans souris.

Il faut séparer deux questions qu'on mélange systématiquement. La première : votre page est-elle utilisable par un visiteur en situation de handicap ? C'est une question de produit. La seconde : remplissez-vous une obligation légale ? Cela dépend de votre pays, de votre secteur et de la taille de votre organisation. Un générateur aide beaucoup sur la première question et ne peut rien répondre sur la seconde.

Qu'est-ce que le code généré réussit déjà ?

Plus que ne l'imaginent les sceptiques, parce que ces réussites viennent du HTML lui-même et non d'une ruse du modèle. Les pages générées sont assemblées avec des éléments standards, et les éléments standards arrivent avec un comportement déjà intégré.

Rien de tout cela n'est garanti sur une construction précise. C'est le socle : ce qui sort correct par défaut parce que le balisage sous-jacent était déjà correct. Le travail réel commence juste au-dessus de ce socle.

Où le code généré échoue-t-il ?

Les défauts se regroupent en quatre endroits, et ils viennent tous d'une décision de design plutôt que d'un balisage bâclé.

Le contraste. Vous demandez « une palette douce et feutrée » et vous l'obtenez : du gris clair sur du blanc. C'est reposant sur votre écran et cela disparaît pour toute personne dont la sensibilité au contraste est réduite. Le niveau AA demande un rapport minimum de 4,5:1 sur le texte courant, et rien dans un prompt qui parle d'ambiance ne dit au modèle de vérifier ce nombre.

Le focus visible. Beaucoup de designs modernes suppriment l'anneau de focus du navigateur parce qu'il jure avec l'esthétique. Si rien ne le remplace, la personne qui navigue au clavier ne voit plus où elle se trouve, et la page cesse d'être utilisable sans souris.

Les composants sur mesure. Accordéons, onglets, fenêtres modales et carrousels bâtis avec des div et des gestionnaires de clic ont l'air corrects et n'annoncent rien. Il faut ici des rôles ARIA, une gestion du clavier et un piégeage du focus, et c'est précisément là que le code généré s'arrête le plus souvent à mi-chemin.

Les images et les icônes. Les icônes décoratives arrivent souvent sans attribut alt au lieu d'un alt vide, et les images porteuses de sens reçoivent un texte alternatif générique parce que le modèle ignore quelle image vous mettrez finalement. Un bouton uniquement composé d'une icône et sans nom accessible reste le défaut le plus fréquent.

Comment demander l'accessibilité dans le prompt ?

Avec des propriétés vérifiables. « Rends-le accessible » est trop abstrait pour changer grand-chose au résultat ; nommer les propriétés change beaucoup, parce que chaque phrase se traduit en une décision précise que le générateur doit prendre.

Un prompt qui fonctionne ressemble plutôt à ceci : « Page d'atterrissage pour un cabinet de kinésithérapie. Texte courant avec un contraste d'au moins 4,5:1 sur le fond, contour de focus visible sur chaque élément interactif, un vrai <label> sur chaque champ, et un nom accessible sur chaque bouton qui ne contient qu'une icône. »

Ce sont quatre exigences contrôlables, pas une impression. Sur Zugo, ces mêmes phrases fonctionnent aussi comme modification sur un projet déjà généré, ce qui est en général l'ordre le moins cher : vous obtenez d'abord le design qui vous plaît, puis vous dépensez une modification sur la passe d'accessibilité, au lieu de vous battre avec les deux en même temps. La façon d'écrire la description de départ et de corriger ensuite dans le chat est détaillée dans créer une application sans code avec l'IA.

Comment contrôler un site généré en dix minutes ?

Pas besoin d'un spécialiste pour attraper les défauts habituels. Cinq vérifications couvrent l'essentiel de ce qui casse, et toutes se font dans un navigateur que vous avez déjà.

Deux contrôles supplémentaires méritent d'être ajoutés une fois que la base passe : parcourir la page avec le lecteur d'écran fourni par votre système d'exploitation, et vérifier qu'une fenêtre modale rend bien le focus à l'élément qui l'a ouverte.

Qu'est-ce qu'un générateur IA ne peut pas faire à votre place ?

Trois choses, et il vaut mieux les dire franchement, parce que l'écart entre « le code généré a bonne allure » et « il a passé un audit » est exactement l'endroit où les gens se font surprendre.

Il ne peut pas juger l'intention. Savoir si une image est décorative ou porteuse de sens est une question sur votre contenu, pas sur votre balisage. Le modèle devine ; vous, vous savez.

Il ne peut pas tester avec une technologie d'assistance réelle. Les contrôles automatiques repèrent les étiquettes manquantes et le contraste insuffisant. Ils ne repèrent pas une hiérarchie de titres techniquement valide et sémantiquement absurde, ni un parcours utilisable mais épuisant.

Il ne peut pas trancher une question juridique. Les obligations varient selon la juridiction et le type d'organisation. Si votre site tombe sous une réglementation précise, traitez le résultat généré comme un brouillon qu'un spécialiste relit.

Les limites de Zugo appartiennent à la même liste. Chaque construction est lancée dans un bac à sable avant de vous être remise, et une construction qui ne s'ouvre pas est signalée comme échouée plutôt que livrée comme un produit fini. Cette vérification confirme que la page a chargé et s'est dessinée. Ce n'est pas un audit d'accessibilité et cela ne prétend pas l'être. Zugo ne remplace pas non plus une équipe de développement sur un produit complexe : une logique très spécifique se règle par modifications successives, pas en un seul prompt.

Combien coûte une passe d'accessibilité sur Zugo ?

Elle coûte une modification, soit 3 crédits. Une construction complète en coûte 6. Le mode Hi-Fi double les deux : 12 crédits pour une construction, 6 pour une modification.

Les 5 crédits du plan gratuit sont inférieurs au coût d'une construction complète, donc ce plan sert à découvrir l'outil plus qu'à terminer un projet. Les 200 crédits de Pro représentent environ 33 constructions, ou 66 modifications, ou 16 plateformes multipages. Autrement dit, la passe d'accessibilité est une des dépenses les plus rentables du lot.

Par où commencer ?

Commencez par tester quelque chose que vous avez déjà publié. Parcourez la page avec Tab, mesurez le contraste du texte courant et comptez combien des cinq vérifications passent. La plupart des sites en ratent deux ou trois, qu'ils aient été écrits par une personne ou par un modèle.

Corrigez ensuite les défauts là où ils coûtent le moins cher, c'est-à-dire dans un générateur où une correction est une phrase et non un ticket. Le cycle qui fonctionne reste le même : construire, contrôler, corriger.

Pour le contexte plus large, créer un site avec l'IA couvre le passage en production étape par étape, et brancher un domaine personnalisé explique ce qui se passe une fois l'adresse définitive en place. Vous pouvez essayer tout cela sur zugo.dev, publier sur un lien .zugo.run et refaire les cinq vérifications sur la page en ligne avant de brancher un domaine.