Contraste et ARIA dans les applications codées en vibe

Comment les mathématiques de contraste sont vraiment cassées dans les thèmes générés

Lorsqu'un modèle invente une palette, il copie généralement une mood board : texte slate doux, puces pastel, cartes translucides. Cela semble bien sur l'écran d'un designer et échoue aux ratios dans la version 2.2 de la WCAG dès que du contenu réel est ajouté. Le texte du corps nécessite un rapport de contraste de 4,5:1 par rapport à son arrière-plan (criterion de réussite 1.4.3) pour atteindre le niveau AA. Le texte de grande taille peut utiliser 3:1. Les générateurs ne font pas ce calcul ; ils choisissent des valeurs hexadécimales qui leur semblent secondaires.

Un deuxième mode de défaillance est l'arrière-plan que vous ne pouvez pas voir dans l'exportation Figma. Le texte sur une image de héros, un lavis de gradient ou un panneau de glassmorphism nécessite l'arrière-plan rendu, et non le jeton nommé bg-surface. Échantillonnez le pixel sous le glyphe, ou vous verrez échouer un audit de jeton et vous allez toujours expédier une copie illisible. Les graphiques et les encres de données ont le même piège ; l'article de Smashing Magazine sur le contraste des graphiques montre comment les seuils standard changent les choix de conception visuelle sans transformer chaque graphique en arc-en-ciel (normes d'accessibilité pour la conception de graphiques).

Le contraste non textuel est le jumeau silencieux

Le critère de réussite 1.4.11 (Contraste non textuel) demande un rapport de 3:1 pour les limites des composants d'interface utilisateur, les objets graphiques nécessaires pour comprendre le contenu et les états tels que les indicateurs de focus. Une bordure faible de 1 px qui semble "premium" échoue souvent. Un anneau de focus défini sur outline: 2px solid rgba(15,118,110,.35) échoue même lorsque le texte de l'étiquette passe 4,5:1. Les commandes icon-only qui s'appuient sur un glyphe gris clair sur fond blanc sont le même type de bogue. Traitez les couleurs de bordure, d'icône et de focus comme des jetons de première classe avec des rapports publiés, et non comme des après-pensées décoratives. La référence rapide à la version 2.2 de la WCAG est l'endroit le plus rapide pour vérifier quels critères s'appliquent au niveau AA.

Les jetons battent les correctifs hexadécimaux ponctuels

La solution durable est ennuyeuse : définissez des jetons de couleur sémantiques (texte-principal, texte-estompé, bordure-forte, anneau de focus) avec des rapports mesurés par rapport à chaque arrière-plan autorisé, puis interdisez au modèle d'inventer des chaînes hexadécimales dans les fichiers de composants. Mettez la règle d'interdiction dans l'invite et dans le CI. Si la régénération peut réécrire la couleur : #94a3b8 dans un libellé de bouton, votre "correction" n'a jamais été une correction. Associez les jetons à une couche de variable CSS pour que le mode sombre et les thèmes marketing héritent des mêmes contraintes.

Les noms accessibles ne sont pas des étiquettes visibles

Les lecteurs d'écran annoncent le nom accessible d'un contrôle, et non les données de chemin SVG. Un bouton d'icône qui affiche un glyphe de corbeille sans contenu textuel, sans aria-label et sans étiquette associée <label> devient "bouton" sans but. C'est une défaillance de nommage, et non une défaillance de contraste, c'est pourquoi les audits de couleur restent verts tandis que les utilisateurs du clavier s'arrêtent.

L'ordre de calcul du nom est défini par l'arbre d'accessibilité : texte de contenu, références étiquetées, puis étiquettes fournies par l'auteur telles que aria-label. Les générateurs émettent souvent le glyphe et une classe Tailwind et s'arrêtent. Ils inventent également des noms en double ("Fermer" sur chaque contrôle de suppression dans une pile de modales) ou des noms qui décrivent la métaphore de l'icône au lieu de l'action ("corbeille à ordures" au lieu de "Supprimer la facture"). Préférez un langage d'action qui correspond à l'affordance visible.

Lorsque les noms disparaissent après la régénération

La régénération efface les valeurs aria-label intégrées qui ont été ajoutées à la main car le modèle les traite comme du bruit facultatif. Survivez à cela en :

- Conservant des cartes d'icônes dans un module qui associe toujours glyphe + chaîne de nom - Utilisant du texte visible à côté des icônes lorsque l'espace le permet (le nom vient gratuitement) - Faisant échouer le CI lorsqu'un élément interactif a un nom accessible vide - Rejetant les PR qui introduisent <div onClick> sans rôle et paquet de nom

L'aperçu des fondamentaux de la WAI est toujours le meilleur court guide sur pourquoi les noms, les rôles et les états doivent voyager ensemble (WAI Accessibility Fundamentals).

Lorsque ARIA aide — et lorsqu'il cache le bug

Le HTML natif expose déjà des rôles, un comportement de clavier et de nombreux états. Un véritable <button> est focusable, active sur Entrée et Espace, et participe aux formulaires. Un <div role="button" tabindex="0"> que le modèle colle toujours nécessite ces gestionnaires de clés, un état pressé ou désactivé lorsqu'il est pertinent, et un nom accessible. Omettez l'un de ces éléments et les technologies d'assistance annoncent un bouton qui ne fait rien sur Espace. Le guide de création ARIA (APG) existe pour les cas où vous avez vraiment besoin d'un widget personnalisé ; il ne s'agit pas d'une licence pour restyler un div en chaque contrôle.

Erreurs ARIA courantes dans le code vibe

- Rôle sur l'élément incorrect : role="button" sur un <a href>, ou role="link" sur un bouton qui soumet un formulaire - ARIA décoratif : aria-label qui duplique le texte visible et confond certaines combinaisons de technologies d'assistance - État obsolète : aria-expanded="true" laissé derrière après un rendu client qui bascule un panneau fermé - Spam de repère : cinq régions role="navigation" sans nom, donc les listes de saut deviennent du bruit - Régions en direct pour la vanité : aria-live="polite" sur chaque toast afin que la page bavarde

La recommandation WAI-ARIA 1.2 décrit l'ontologie des rôles et des propriétés ; utilisez-la lorsque vous devez étendre au-delà du HTML, et non comme couche par défaut sur chaque nœud (WAI-ARIA 1.2).

Situation | Préférer | Éviter Action principale | <button type="button"> | <div role="button"> sans clés Navigation vers une URL | <a href> | Bouton qui n'appelle que router.push sans URL Contrôle d'icône uniquement | Texte visible ou aria-label stable à partir d'une carte | SVG nu avec titre manquant Combo personnalisé | Modèle APG + carte de clavier | Rôles inventés copiés d'une réponse de chat

Chemins de clavier que le générateur oublie

L'ordre de focus, le focus visible et les liens de saut disparaissent des dispositions à un seul coup. Le critère 2.4.7 nécessite un indicateur de focus visible. Le critère 2.4.11 (Focus Not Obscured — Minimum), nouveau dans WCAG 2.2, nécessite que les en-têtes collants, les bannières de cookies et les widgets de chat flottants ne cachent pas complètement le contrôle focus. Tabulez la page générée de haut en bas. Confirmez que l'ordre correspond à l'ordre de lecture. Confirmez qu'aucun contrôle n'est laissé derrière un superposition. Confirmez que l'anneau de focus répond à 1.4.11 contre ce qui se trouve derrière.

Un court passage manuel de clavier (15 minutes)

- Débranchez la souris. Ouvrez la page dans un profil propre. - Tabulez depuis le chrome du navigateur jusqu'au document. Y a-t-il un lien de saut qui fonctionne? - Atteignez chaque action principale sans folklore de clavier que le composant n'a jamais implémenté. - Ouvrez et fermez chaque modal avec Échap. Le focus revient-il à l'invocateur? - Déclenchez l'en-tête collant et la bannière de cookies. Pouvez-vous toujours voir le contrôle focus? - Appuyez sur chaque bouton d'icône avec un lecteur d'écran (NVDA ou VoiceOver). Le nom correspond-il à l'action?

Ce passage attrape ce que Lighthouse ne fera pas. Les outils automatisés sont un premier filtre ; ils ne constituent pas un certificat de conformité. Pour les outils d'embauche et de décision automatisés, les directives américaines rappellent également aux constructeurs que les fonctionnalités d'IA peuvent créer des risques de discrimination en matière de handicap si les interfaces excluent les personnes qui utilisent des technologies d'assistance (guidance ADA.gov AI). L'interface utilisateur du produit n'est pas exonérée de cette réflexion simplement parce qu'un modèle a écrit le JSX.

Faire survivre la vérification à la régénération

Parce que la régénération efface les correctifs manuels, un contrôle durable ressemble à une infrastructure :

- Des jetons de conception avec une contraste mesurée, vérifiée dans un test unitaire ou un plugin stylelint - Des primitives de composants (IconButton, TextField) qui émettent toujours des styles de nom et de focus - Une passerelle d'accessibilité CI (axe ou équivalent) sur les demandes d'extraction, qui échoue en cas de noms vides et de contraste - Des contraintes de prompt qui interdisent les hex bruts et les div-en-tant-que-bouton sans un drapeau d'exception explicite - Un passage clavier humain sur chaque verticale avant la publication, enregistré comme un élément de liste de contrôle, et non comme une vibe

Traitez le code de balisage généré comme une sortie de brouillon non fiable. Examinez-le de la même manière que vous examinez une demande d'extraction junior qui arrive d'un hackathon de week-end : supposez des noms manquants, supposez une ARIA théâtrale, supposez du texte pastel.

Critères de décision : corriger dans les jetons, les primitives ou le code de page?

Utilisez cet ordre lorsque rapport de bogue arrive :

- Si de nombreuses pages partagent la mauvaise couleur de texte muet, corrigez le jeton et remesurez les ratios. - Si un type de contrôle manque de noms (tous les boutons d'icône), corrigez la primitive et supprimez les correctifs locaux. - Si un seul héros marketing échoue sur une photo, corrigez le surimpression ou le traitement de texte de cette page. - Si l'ARIA a été collé sur le mauvais élément, remplacez-le par un contrôle natif avant d'écrire plus d'attributs.

Les correctifs ARIA au niveau de la page sont les moins durables. Ce sont également ceux que les sessions de vibe-coding adorent émettre. Pousser les correctifs vers le haut.

Ce que cela n'est pas

Cet article n'est pas un certificat de conformité WCAG pour votre produit. Il ne s'agit pas de conseils juridiques et il ne prétend pas que l'exécution d'A11yGuard (ou tout autre analyseur) rend un site « conforme à l'ADA » ou « 100 % accessible ». Les vérifications automatiques de contraste et d'ARIA détectent les échecs mesurables ; ils manquent les appels de jugement sur l'ordre de lecture, les alternatives de glissage et si un nom est compréhensible. Nous n'inventons pas les logos des clients, les augmentations de conversion ou les garanties « ne jamais manquer un bogue de contraste ». Le rôle honnête du produit est un premier passage rapide plus une liste de contrôle que vous possédez toujours.

Clôture

Les mathématiques de contraste et les noms accessibles échouent de manière indépendante et se régénèrent ensemble. Verrouillez les jetons, préférez les contrôles natifs, vérifiez ARIA contre APG lorsque vous devez personnaliser et conservez un passage clavier dans le rituel de publication. Utilisez les références ci-dessous lorsque une affirmation concernant un ratio ou un critère est contestée — le texte de spécification l'emporte sur la mémoire d'un modèle de chat.

Références

- WCAG 2.2 - Référence rapide WCAG 2.2 - Fondamentaux de l'accessibilité de la WAI - Guide de création ARIA (APG) - WAI-ARIA 1.2 - Smashing Magazine — normes d'accessibilité et conception de graphiques - ADA.gov — orientation sur la discrimination des personnes handicapées et l'IA

Articles liés

- Liste de contrôle WCAG 2.2 pour l'interface utilisateur générée par l'IA (2026) - Explorer la matrice complète des sujets de micro-SaaS d'IA →