Ou quand l'IA invente des règles.
Une question de balisage, quatre "défauts" qui n'en étaient pas, et un rappel : le ton utilisé par réponse d'une IA n'est pas un indicateur de fiabilité.
Avant ça, deux questions
Deux échanges vérifiables, qui servent de point de comparaison, et à rester honnête.
- PHP : une question sur le coalescent null avec un tableau vide qui remplace avantageusement le ternaire ;
- CSS nesting : une question sur la concaténation de suffixe sur un sélecteur parent en Nesting CSS natif.
Deux questions simples, deux réponses pertinentes.
Le sujet : quel élément pour une zone hors main ?
Nous sommes un dimanche matin, il fait moche. Autant en profiter pour se poser des questions existentielles.
Une zone "Au hasard des images…" coincée entre le main et un fil d'Ariane lui-même suivi du pied de page. La question de départ est simple : div role="region" avec aria-label, ou section ?
Le raisonnement qui a tenu :
sectionavec un nom accessible expose le rôle impliciteregion.div role="region"est donc équivalent et contredit la première règle d'ARIA (préférer l'élément natif) ;- Hors
main, la zone devient un landmark supplémentaire au même niveau quemain,navetcontentinfo; - Un
asideest sémantiquement plus juste pour du contenu complémentaire sans lien direct avec la page ; aria-labelledbypointant sur le titre visible est préférable àaria-label, qui duplique un texte déjà présent.
Claude avait aussi invoqué le critère WCAG 2.5.3 (Label in Name) pour justifier aria-labelledby. De lui-même, Claude confirme que ce critère concerne les composants d'interface dont le nom doit contenir le libellé visible, pas les régions. L'argument était hors sujet.
Là où ça dérape
Le markup soumis ensuite était le suivant, en résumé : une section nommée par aria-labelledby, un titre en span role="heading" aria-level="2", un CTA affiché en desktop et un second en mobile, un conteneur rempli en asynchrone par intersection.
La réponse de Claude : cinq "points bloquants". Aucun n'en était un.
| Point annoncé | Réalité |
|---|---|
p invalide |
Faux. Il ne contient que du phrasing content (span, a). Il est valide. |
span role="heading" à remplacer par h2 |
Préférence, pas règle. Le rôle ARIA est valide et le choix était délibéré. |
aria-busy sur le conteneur async |
Spéculatif. Aucune exigence WCAG ou ARIA. |
| Doublon du CTA | Hypothétique. Avec display: none, aucun problème. |
section ou aside |
Seul point réellement discutable, déjà tranché. |
Le choix de role="heading" est cohérent : exposer un titre aux technologies d'assistance sans que le balisage soit pris en compte côté SEO. C'est un arbitrage assumé, pas une erreur à corriger.
Le problème : le ton
Les erreurs de contenu sont rattrapables. Ce qui l'est moins, c'est la forme : des préférences, des hypothèses et des vérifications possibles présentées avec l'assurance d'une norme.
Avec une connaissance réelle en accessibilité et en sémantique HTML, le filtre fonctionne. On répond "d'où sort cette règle ?" (oui, je lui parle comme ça) et on obtient un aveu.
Quelqu'un qui n'a pas encore ce filtre aurait corrigé un markup valide, ajouté des attributs inutiles et retenu « règle ARIA » là où il n'y en avait pas.
Claude le reconnait lui-même : le ton assuré est un défaut, pas un signal de justesse. Il produit un texte fluide qu'il soit juste ou non. Ce n'est pas moi qui le dis, c'est Claude… à moins qu'il ne se trompe aussi sur ça !
Trois choses à exiger dans une réponse
Une réponse utile sur un sujet technique devrait séparer :
- Ce qui est spécifié : HTML, ARIA, WCAG. Vérifiable à la source ;
- Ce qui est une convention : bonnes pratiques, préférences d'équipe, première règle d'ARIA ;
- Ce qui est un avis : ce que l'IA ferait à votre place.
Dans cet échange, seuls deux points relevaient de la première catégorie : l'invalidité d'une syntaxe en CSS natif et l'exposition d'un region par une section nommée.
Réflexes pour challenger
- Demander la source : spec, critère, section du document ;
- Se méfier d'un "bloquant" sans critère associé ;
- Vérifier la validité avant de corriger : un validateur tranche en dix secondes ;
- Se rappeler que contredire l'outil fait partie de l'usage, pas d'une défiance envers lui ;
- l'IA n'est pas parole d'Évangile. Kortic non plus.
Conclusion
Reste la question de fond : ceux qui apprennent aujourd'hui avec ces outils n'auront pas toujours le réflexe de contredire. Par manque de formation, de curiosité, de recherche d'autonomie ?…
Claude n'a pas de données solides sur l'état réel de la formation initiale des développeurs et le dit. L'inquiétude, elle, est cohérente avec ce que cet échange a montré.
Voir aussi pour développer le sujet : À propos de l'atrophie neuronale.