Checklist WCAG 2.2 pour les interfaces utilisateur générées par IA

Ce que WCAG 2.2 a changé pour les interfaces utilisateur générées

WCAG 2.2 s'appuie sur la version 2.1 et ajoute neuf critères de réussite axés sur les besoins mobiles, de faible vision et de mobilité. Il est devenu une recommandation du W3C en octobre 2023 ; gardez le texte normatif ouvert pendant votre audit (w3.org/TR/WCAG22). Pour les équipes qui expédient des composants générés par intelligence artificielle, les ajouts les plus importants sont Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) et Accessible Authentication (3.3.8). La plupart des organisations de produits visent le niveau AA. Les pages de base de WAI encadrent toujours pourquoi ces règles existent au-delà de "passer le scanner" (WAI Accessibility Fundamentals).

Les générateurs échouent ici parce qu'ils optimisent pour la densité visuelle et le poli de la démo de clic. Ils réduisent les zones de clic des icônes, inventent des tableaux de bord kanban uniquement par glisser-déposer, empilent des éléments de chrome collants qui couvrent les champs focalisés et saupoudrent des rôles ARIA qui ne correspondent pas au comportement. La liste de contrôle ci-dessous est ordonnée pour un passage de jour de publication : éléments mesurables en premier, éléments de jugement en second.

Flux de travail étape par étape avant de publier

- Geler la branche générée. Ne pas continuer à régénérer pendant que vous mesurez. - Exécuter une analyse d'accessibilité automatisée (axe, Lighthouse ou votre porte de CI) et consigner chaque problème de contraste / nom manquant / ARIA non valide. - Parcourir les filtres de référence rapide de WCAG 2.2 pour le niveau AA et marquer les critères 2.2 uniquement comme des lignes explicites dans votre ticket. - Passage au clavier uniquement sur chaque parcours utilisateur principal (inscription, paiement, tâche principale). - Vérification ponctuelle de la lecture à l'écran (NVDA sous Windows ou VoiceOver sur macOS) sur les boutons d'icônes et les dialogues. - Enregistrer les risques résiduels : ce que le scanner ne peut pas voir, ce que vous avez différé, qui est responsable du suivi.

A11yGuard est conçu pour le premier passage mesurable. La conformité légale et les appels de jugement nécessitent toujours un propriétaire de QA humain. Si votre produit utilise l'intelligence artificielle dans les flux de décision de recrutement ou similaires, lisez également les conseils américains sur les algorithmes et la discrimination des personnes handicapées afin que l'exclusion de l'interface utilisateur ne soit pas traitée comme un bogue cosmétique (ADA.gov AI guidance). ReDoS, ECMAScript, PCRE, GDPR et Waffo doivent également être pris en compte pour garantir la conformité et la sécurité de votre produit.

Contraste que vous pouvez calculer, contraste que vous ne pouvez pas

Le contraste du texte est la défaillance la plus facile à détecter : le texte du corps nécessite un rapport de 4,5:1 par rapport à son arrière-plan ; le texte de grande taille nécessite un rapport de 3:1 (criterion 1.4.3). Les thèmes générés contiennent souvent des combinaisons gris-sur-gris ou des dégradés de remplissage qui échouent. Mesurez contre l'arrière-plan rendu, y compris les images et les superpositions.

Le contraste non textuel (1.4.11) est la règle jumelle : les limites des composants d'interface utilisateur, les icônes nécessaires pour comprendre le contrôle et les indicateurs de focus doivent atteindre un rapport de 3:1 par rapport aux couleurs adjacentes. Un bouton dessiné avec seulement une bordure ténue ou un anneau de focus défini sur une ligne de contour de faible opacité échoue même lorsque le texte de l'étiquette passe. Les interfaces utilisateur de graphiques et de tableaux de bord rencontrent le même problème ; Smashing Magazine documente comment les seuils d'accessibilité redéfinissent la conception visuelle des graphiques sans nécessiter de bruit décoratif (normes d'accessibilité pour la conception de graphiques).

Checklist — contraste

- Copie de corps ≥ 4,5:1 sur chaque thème (y compris le mode sombre) - Texte de grande taille / grands chiffres ≥ 3:1 - Anneau de focus ≥ 3:1 par rapport à la surface derrière lui - Affordances d'icônes uniquement ≥ 3:1 lorsque le glyphe porte une signification - Aucune dépendance à la couleur seule pour l'état d'erreur ou de réussite (appariez avec du texte ou une icône)

Taille de la cible et glisser après WCAG 2.2

La taille minimale de la cible (2.5.8) nécessite des cibles interactives d'au moins 24×24 pixels CSS au niveau AA, avec des exceptions limitées pour les liens en ligne et certains cas d'espacement. Les dispositions de l'IA produisent couramment des boutons d'icônes de 16 pixels sans padding. C'est maintenant une question de conformité, et non un débat de goût. Le padding, la largeur minimale/hauteur minimale ou un hit-slop plus grand autour du glyphe visible comptent si la cible du pointeur atteint la taille.

Les mouvements de glissement (2.5.7) signifient que toute interaction de glissement — pouce de curseur, carte kanban, réglage de la plage — nécessite un alternatif à un pointeur unique tel que des boutons de flèche, une saisie numérique ou un clic pour définir. Si un utilisateur ne peut pas terminer la tâche sans glisser, le modèle ne conforme pas. Les générateurs aiment les démos de glissement car ils semblent interactifs dans un GIF ; expédiez le contrôle alternatif dans la même PR.

Checklist — accès au pointeur

- La zone de toucher de chaque bouton d'icône ≥ 24×24 CSS px - Les cibles adjacentes ont suffisamment d'espacement ou partagent une exception conforme - Chaque geste de glissement a un chemin non glissant documenté dans l'interface utilisateur - Les cibles tactiles fonctionnent toujours lorsque la taille de texte du système d'exploitation augmente

Ordre de focus, chrome collant et 2.4.11

Focus Not Obscured (Minimum) exige que lorsque un contrôle reçoit le focus du clavier, il ne soit pas entièrement caché par le contenu créé par l'auteur. Les en-têtes collants, les barres de navigation inférieures, les bannières de cookies et les widgets de "AI Help" flottants sont les contrevenants habituels dans les applications codées en vibe. Parcourez la page avec ces couches ouvertes. Si le champ focalisé se trouve sous une barre collante de 72 px, corrigez le remplissage de défilement ou le empilage, et non la vue de l'utilisateur.

Confirmez également 2.4.7 (Focus Visible) : chaque élément interactif affiche un indicateur de focus visible. Les générateurs suppriment souvent les contours "pour des raisons esthétiques." Rétablissez un anneau à haute contraste qui répond à 1.4.11.

Checklist — focus

- Focus visible sur les liens, les boutons, les entrées, les widgets personnalisés - L'ordre de focus correspond à l'ordre de lecture pour les flux principaux - Les modales piègent le focus et le restituent à l'invocateur à la fermeture - L'interface utilisateur collante/fixe ne recouvre jamais entièrement le contrôle focalisé (2.4.11) - Présence et fonctionnement d'un lien de saut sur les pages contenant beaucoup de contenu

ARIA : HTML sémantique d'abord, ARIA ensuite

Les générateurs inventent des rôles ARIA qui ne correspondent pas au comportement, ou ajoutent role="button" à des éléments qui sont déjà des liens. Préférez les éléments natifs : <button>, <a>, <nav>, <main>, les contrôles de formulaire. ARIA remplit les lacunes ; il ne remplace pas la sémantique. Les rôles non correspondants confondent les lecteurs d'écran et peuvent cacher l'action réelle. Traitez chaque attribut aria-* généré comme une affirmation à vérifier.

Lorsque vous avez vraiment besoin d'un widget personnalisé, suivez un modèle publié du Guide de création d'ARIA et vérifiez les rôles/états contre WAI-ARIA 1.2. La copie d'un rôle de chaîne à partir d'une réponse de chat sans prise en charge du clavier est la façon dont le balisage "accessible" devient un comportement inaccessible.

Odeur générée | Que faire | Crochet WCAG / pratique <div onClick> en tant que CTA | Remplacez par <button> ou <a href> | Nom, rôle, clavier Bouton d'icône, nom vide | Ajoutez du texte visible ou un aria-label stable | 4.1.2 Nom, rôle, valeur Tableau de glissage uniquement | Ajoutez des boutons de déplacement ou des menus | 2.5.7 Mouvements de glissage Zone de clic d'icône de 16 px | Padded à ≥24×24 px CSS | 2.5.8 Taille cible Focus sous en-tête collant | Correction de scroll-padding / empilage | 2.4.11 Focus Not Obscured Rôle décoratif "button" sur lien | Supprimez le rôle ; conservez le lien natif | APG / ARIA 1.2

Pourquoi les vérifications automatisées ne capturent qu'une partie du tableau

La pratique industrielle et la documentation des fournisseurs placent couramment la couverture automatisée dans la fourchette d'environ 30-40 % des problèmes d'accessibilité du monde réel. Les outils trouvent le texte alt manquant, de nombreuses défaillances de contraste et des ARIA non valides. Ils ne peuvent pas juger pleinement si l'ordre de focus correspond à l'ordre de lecture, si des alternatives de glisser-déposer existent, ou si le nom d'un bouton d'icône est compréhensible. C'est pourquoi un score Lighthouse propre n'est pas la preuve d'une conformité à la WCAG 2.2. Combinez un premier passage automatisé avec des tests de clavier et un examen manuel de la balise générée.

N'citez pas un seul pourcentage comme loi ; traitez-le comme une hypothèse de planification : les analyseurs sont nécessaires et insuffisants. Budgétisez du temps humain pour la couche de jugement à chaque version.

Erreurs courantes que les équipes commettent avec l'interface utilisateur de l'IA

- Régénérer après des corrections manuelles sans verrouiller les jetons ou les primitives, de sorte que le contraste et les noms disparaissent - Faire confiance à l'enregistrement de la démo (seulement la souris) comme preuve que le chemin du clavier fonctionne - Empiler ARIA pour faire taire un linter au lieu de corriger le type d'élément - Expédier des dégradés de marketing qui n'ont jamais été mesurés sur le DOM live - Appeler un build CI vert "conforme" dans les présentations de vente — ce langage surestime

Critères de décision : AA maintenant ou plus tard

Expédier les bloqueurs pour la plupart des applications B2B à AA :

- Des noms accessibles vides sur les actions principales - Du texte de corps sous 4,5:1 sur le thème par défaut - Aucun chemin clavier à travers la vérification ou la tâche principale - La mise au point entièrement masquée par l'interface utilisateur collante sur les champs requis - Des actions critiques uniquement par glissage sans alternative

Reporter uniquement avec un propriétaire et une date : des animations décoratives secondaires, des graphiques non critiques avec une alternative de tableau de données déjà présente, un polissage de widget d'aide qui n'empêche pas les tâches. Reporté n'est pas oublié.

Ce que ce n'est pas

Cette liste de contrôle n'est pas une audit WCAG complète, pas un VPAT, et pas des conseils juridiques. Elle ne prétend pas que A11yGuard (ou tout outil) garantit la conformité, la conformité ADA, ou que les analyses automatisées « ne manquent jamais » de problèmes. Nous ne publions pas de métriques de clients inventées ou des conversions avant/après. Le produit automatise le premier passage mesurable ; vous avez toujours besoin d'une QA humaine pour les critères de jugement et pour le langage de validation utilisé avec les clients ou les régulateurs.

Clôture

Imprimez les tableaux, gérez la branche, exécutez l'analyseur, puis effectuez le passage du clavier et de la dénomination. Gardez le texte normatif WCAG et la référence rapide ouverts pendant que vous discutez des cas limites. Lorsque le modèle régénère un écran, réexécutez la même liste — la dette d'accessibilité dans les applications codées en vibe est une boucle, et non un projet à temps unique.

Références

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

Articles liés

- Contraste et ARIA dans les applications codées en vibe - Explorez la matrice complète des sujets de micro-SaaS IA →