accessibility-compliance

Vue d’ensemble de la skill accessibility-compliance

Ce que fait la skill accessibility-compliance

La skill accessibility-compliance aide un agent à produire des recommandations d’accessibilité directement exploitables pour l’implémentation d’interfaces web et mobile, avec un fort accent sur WCAG 2.2, l’usage d’ARIA, l’accès au clavier, la compatibilité avec les lecteurs d’écran et l’accessibilité mobile. Elle convient surtout aux équipes qui travaillent sur de vraies interfaces, pas simplement à celles qui veulent rédiger une checklist d’accessibilité générique.

À qui s’adresse l’installation de accessibility-compliance

Cette skill est particulièrement adaptée à :

• des auditeurs UX qui ont besoin de accessibility-compliance for UX Audit
• des ingénieurs frontend qui corrigent des problèmes d’accessibilité dans des composants
• des équipes design system qui définissent des patterns d’interaction accessibles
• des équipes produit qui livrent des formulaires, des boîtes de dialogue, des menus et d’autres interfaces interactives
• des équipes mobile ou cross-platform qui ont besoin de recommandations tenant compte de VoiceOver et TalkBack

Si votre besoin concret est de « transformer cet écran ou ce composant pour le rapprocher d’une conformité WCAG avec des corrections précises », cette skill sera plus utile qu’un prompt de design généraliste.

Pourquoi cette skill se distingue d’un prompt générique

La principale valeur de la accessibility-compliance skill, c’est qu’elle oriente le modèle vers des patterns d’implémentation d’accessibilité concrets, plutôt que vers des principes vagues. Le repository inclut des références ciblées dans :

• references/wcag-guidelines.md
• references/aria-patterns.md
• references/mobile-accessibility.md

Elle est donc mieux armée pour des tâches comme privilégier le HTML sémantique à ARIA, structurer des formulaires accessibles, améliorer les comportements clavier ou vérifier les recommandations sur les zones tactiles en mobile.

Ce que les utilisateurs veulent savoir avant d’installer

La plupart des utilisateurs qui évaluent accessibility-compliance install veulent savoir :

• si la skill fournit des corrections concrètes orientées code plutôt qu’un discours de conformité ou de gouvernance
• si elle couvre à la fois les enjeux web et mobile
• si elle aide autant pour l’audit que pour l’implémentation
• si elle prend clairement position sur la préférence pour la sémantique native par rapport à ARIA
• si elle peut réduire les allers-retours lors des revues de composants UI

Sur ces points, la skill paraît solide. Sa principale différence tient à son périmètre pratique : elle regroupe dans un même package les concepts WCAG, les patterns ARIA et l’accessibilité mobile.

Cas d’usage idéaux et cas où elle convient mal

Cas d’usage idéaux :

• auditer des composants interactifs
• corriger des problèmes d’accessibilité dans du code existant
• planifier un comportement accessible pour des dialogues, accordéons, formulaires et systèmes de navigation
• passer en revue l’ordre de focus, les labels, les annonces et la prise en charge de la réduction des animations

Cas où elle convient mal :

• l’interprétation juridique de la conformité dans une juridiction donnée
• la mise en place d’une stratégie de tests automatisés à elle seule
• la critique visuelle au pixel près sans lien avec l’accessibilité
• des API natives très spécifiques à une plateforme au-delà des recommandations référencées

Comment utiliser la skill accessibility-compliance

Contexte d’installation et invocation

Le SKILL.md source ne fournit pas de commande d’installation, donc les utilisateurs du directory l’ajouteront généralement depuis le repo :

npx skills add https://github.com/wshobson/agents --skill accessibility-compliance

Ensuite, invoquez-la avec une tâche d’accessibilité concrète, pas simplement « check accessibility ». La skill fonctionne le mieux quand la demande porte sur un composant, un flux ou un écran avec assez de structure pour être réellement évalué.

Fichiers à lire en priorité

Pour une adoption rapide, commencez ici :

1. plugins/ui-design/skills/accessibility-compliance/SKILL.md
2. plugins/ui-design/skills/accessibility-compliance/references/wcag-guidelines.md
3. plugins/ui-design/skills/accessibility-compliance/references/aria-patterns.md
4. plugins/ui-design/skills/accessibility-compliance/references/mobile-accessibility.md

Cet ordre de lecture reflète bien la façon dont travaillent la plupart des équipes : d’abord la cible de conformité, ensuite les patterns d’implémentation, puis les cas limites propres aux plateformes.

Les informations à fournir pour que la skill accessibility-compliance fonctionne bien

La qualité d’usage de accessibility-compliance usage dépend fortement de la précision de vos entrées. Fournissez :

• le type de composant ou de page
• le code ou le markup actuel
• le framework (React, Next.js, Vue, plain HTML, React Native)
• le comportement d’interaction attendu
• la norme cible, généralement WCAG 2.2 AA
• le périmètre device : desktop web, mobile web, iOS, Android
• les problèmes déjà détectés par des outils d’audit ou des tests utilisateurs

Entrée faible :

• « Make this accessible. »

Entrée solide :

• « Review this React modal for WCAG 2.2 AA. Check keyboard trap behavior, focus return, accessible name/description, escape handling, and screen reader announcements. Suggest code changes before release.”

Transformer un objectif flou en bon prompt

Un bon prompt de accessibility-compliance guide comporte généralement cinq éléments :

1. l’UI cible
2. les interactions utilisateur
3. la cible de conformité
4. le livrable attendu
5. les contraintes

Exemple :

• « Use the accessibility-compliance skill to audit this checkout form for WCAG 2.2 AA. Identify failures by issue, explain user impact, and provide corrected JSX for labels, error messaging, field grouping, and keyboard flow. Keep the current visual design if possible.”

C’est plus efficace que de demander simplement des « best practices », car cela pousse le modèle à produire une sortie réellement corrigeable.

Meilleur workflow pour un audit UX avec accessibility-compliance

Pour accessibility-compliance for UX Audit, utilisez cette séquence :

1. demander l’identification des problèmes
2. demander la sévérité et l’impact utilisateur
3. demander le mapping vers les corrections
4. demander une version révisée du markup ou du code du composant
5. demander une checklist de re-test

Cette séquence évite un écueil fréquent : une première réponse trop conceptuelle. La skill devient particulièrement utile quand vous la faites passer des constats d’audit aux détails d’implémentation.

Utilisez-la sur les composants, pas seulement sur les pages

La skill est particulièrement performante sur les patterns d’interaction réutilisables. Exemples de bonnes cibles :

• dialogues et focus traps
• accordéons
• menus et disclosures
• formulaires et validation
• tabs
• carousels
• boutons icône
• zones tactiles mobile

C’est précisément sur ces sujets que les prompts génériques abusent souvent d’ARIA ou oublient les comportements clavier et lecteur d’écran.

Ce que les références impliquent concrètement

Les références incluses suggèrent trois règles de fonctionnement importantes :

• préférer le HTML sémantique avant d’ajouter ARIA
• considérer WCAG 2.2 AA comme niveau de référence par défaut
• prendre en compte l’accessibilité mobile, pas uniquement l’usage clavier sur desktop

En pratique, c’est décisif. Un bon prompt devrait demander explicitement à l’agent de limiter l’usage d’ARIA au strict nécessaire et de justifier chaque attribut ARIA ajouté.

Modèle de prompt pour des sorties plus solides

Utilisez un format de demande comme celui-ci :

• Context: “This is a React checkout drawer.”
• Target: “Meet WCAG 2.2 AA.”
• Review scope: “Keyboard access, focus order, visible labels, error association, live region announcements.”
• Constraints: “Do not rewrite the design system API.”
• Deliverable: “Return prioritized issues, corrected JSX, and a manual test checklist.”

Cette structure produit de manière fiable un meilleur accessibility-compliance usage que des demandes de revue trop ouvertes.

Ce que vous devez attendre de la sortie

Une bonne réponse de la accessibility-compliance skill devrait inclure :

• une liste de problèmes reliés à leur impact utilisateur
• des références à des principes ou critères d’accessibilité
• des changements précis dans le markup ou le code
• des notes sur le comportement clavier et la gestion du focus
• des recommandations sur le nommage et les annonces pour lecteurs d’écran
• des remarques spécifiques au mobile quand c’est pertinent

Si la sortie s’arrête à des principes généraux sans correction au niveau du code, c’est que votre prompt est trop large.

FAQ sur la skill accessibility-compliance

accessibility-compliance est-elle adaptée aux débutants ?

Oui, à condition de déjà comprendre la structure de base d’une interface. La skill apporte davantage de valeur si vous pouvez fournir du markup, des composants ou des résultats d’audit. Les débutants peuvent quand même l’utiliser, mais doivent s’attendre à poser des questions de suivi pour comprendre pourquoi certains choix sémantiques ou ARIA comptent.

Est-ce mieux qu’un prompt d’accessibilité classique ?

En général oui, pour les travaux d’implémentation. Un prompt classique peut répondre avec des conseils génériques du type « add alt text » ou « ensure keyboard navigation ». La accessibility-compliance skill a plus de chances de rester ancrée dans WCAG 2.2, les patterns ARIA et les enjeux d’accessibilité mobile présents dans les références du repository.

Remplace-t-elle les tests automatisés d’accessibilité ?

Non. Elle complète les outils automatisés et la revue manuelle. Utilisez-la pour interpréter les problèmes, proposer des corrections et examiner des comportements de composants que les outils statiques ratent souvent, comme la gestion du focus, le timing des annonces ou certains détails d’interaction mobile.

Quand ne faut-il pas utiliser accessibility-compliance ?

Évitez-la si vous avez besoin de :

• conseils juridiques ou décisions de certification
• scans entièrement automatisés à l’échelle d’un codebase
• détails natifs mobile très spécifiques au-delà des patterns référencés
• critique UX sans rapport avec l’accessibilité

C’est une skill d’accompagnement, pas une garantie de conformité.

Gère-t-elle bien l’accessibilité mobile ?

Plutôt bien pour une AI skill. La référence dédiée mobile-accessibility.md couvre la taille des zones tactiles, l’espacement et les enjeux liés aux lecteurs d’écran sur iOS et Android. Cela rend cette skill plus crédible pour des revues mobile que des prompts d’accessibilité centrés uniquement sur le web desktop.

Puis-je l’utiliser pour du design system ?

Oui. Elle est bien adaptée à la définition de comportements accessibles par défaut pour des composants réutilisables, en particulier quand la sémantique, la gestion clavier, l’état ARIA et la gestion du focus doivent rester cohérents entre plusieurs produits.

Comment améliorer la skill accessibility-compliance

Donnez à la skill de vrais artefacts, pas des résumés

Le moyen le plus rapide d’améliorer les résultats de accessibility-compliance est de fournir du vrai JSX, du HTML, du code React Native, des captures annotées ou une description pas à pas des interactions. La skill ne peut pas déduire de façon fiable l’ordre de focus, les labels ou les annonces à partir de résumés produit vagues.

Demandez un mapping des problèmes, pas seulement des recommandations

Une demande plus solide ressemble à ceci :

• « List each issue, affected users, violated principle or criterion, and exact fix.”

Cela pousse le modèle à produire une sortie auditable. Sans cette structure, les réponses dérivent facilement vers des conseils génériques.

Indiquez le niveau de changement acceptable

Les corrections d’accessibilité impliquent souvent des compromis avec les contraintes d’un design system. Précisez si l’agent peut :

• modifier uniquement le markup
• ajouter ARIA seulement quand c’est nécessaire
• restructurer la hiérarchie du composant
• modifier le wording pour plus de clarté
• changer les patterns d’interaction si le design actuel est inaccessible

Cela influence la qualité du résultat bien plus que la plupart des utilisateurs ne l’imaginent.

Échec fréquent : surutiliser ARIA

Un problème prévisible en accessibilité consiste à ajouter ARIA là où le HTML natif ferait mieux. Pour améliorer la sortie, dites explicitement :

• “Prefer native semantic elements and only use ARIA when native semantics are insufficient.”

Cette consigne est alignée avec la référence ARIA du repository et réduit les corrections de faible qualité.

Échec fréquent : oublier les changements d’état

Beaucoup de premières réponses repèrent les labels et le focus, mais ratent le comportement dynamique. Demandez explicitement :

• focus entry and return
• expanded/collapsed state announcements
• validation error association
• async status messaging with live regions
• reduced motion and high contrast considerations where relevant

Ces détails améliorent concrètement l’utilité du accessibility-compliance guide.

Itérez après la première réponse

Après l’audit initial, enchaînez avec l’une de ces demandes :

• “Rewrite the component with the fixes applied.”
• “Prioritize only release-blocking issues.”
• “Convert this into QA test steps.”
• “Explain what should be tested with screen readers.”
• “Separate WCAG AA requirements from nice-to-have AAA improvements.”

C’est ce qui transforme la skill d’un simple reviewer en véritable aide à la livraison.

Utilisez les références du repository de façon ciblée

Ne commencez pas par lire tout le repository. Si votre problème concerne :

• la structure sémantique ou la cible de conformité : commencez par references/wcag-guidelines.md
• le comportement des widgets ou les rôles : ouvrez references/aria-patterns.md
• les zones tactiles ou les technologies d’assistance mobile : ouvrez references/mobile-accessibility.md

Ce parcours de lecture ciblé accélère l’adoption et rend accessibility-compliance install plus rapide à prendre en main.

Renforcez la confiance en demandant la justification

Demandez à la skill d’expliquer pourquoi chaque correction compte pour les utilisateurs clavier, les utilisateurs de lecteurs d’écran, les personnes malvoyantes ou les utilisateurs sensibles aux mouvements. Cela permet de repérer les corrections superficielles et aide les équipes à justifier le travail d’implémentation lors des revues.

Meilleure façon d’obtenir une sortie prête pour la production

Pour obtenir la plus forte valeur de accessibility-compliance usage, demandez en une seule passe :

• des constats priorisés
• du code corrigé
• la justification
• une checklist de vérification manuelle
• les risques ou hypothèses restants

C’est exactement le package dont la plupart des équipes ont besoin pour passer de « il faudrait améliorer l’accessibilité » à « on peut l’implémenter et le vérifier maintenant ».