accessibility

Vue d’ensemble de la skill accessibility

Ce que fait la skill accessibility

La skill accessibility vous aide à concevoir, implémenter et auditer des interfaces accessibles selon les WCAG 2.2 niveau AA. Elle sert à transformer une intention produit en choix sémantiques concrets : éléments natifs, rôles ARIA, libellés, aides textuelles, comportement du focus et attributs d’accessibilité propres au Web, à iOS et à Android.

À qui s’adresse cette skill accessibility

Cette skill accessibility convient particulièrement aux ingénieurs frontend, aux équipes design system, aux auditeurs UX et aux product designers qui ont besoin de recommandations directement exploitables en implémentation, plutôt qu’une simple checklist d’accessibilité générique. Elle est particulièrement utile pour l’accessibility dans des travaux d’UX Audit, quand il faut passer de « ce parcours semble risqué » à des remédiations précises.

Quel travail elle vous aide réellement à accomplir

Le vrai besoin ne se résume pas à « rendre l’interface conforme ». Il s’agit de faire correspondre correctement un composant ou un parcours à l’arbre d’accessibilité, afin que les utilisateurs de technologies d’assistance reçoivent le bon rôle, le bon nom, le bon état, le bon ordre et le bon modèle d’interaction. La skill met l’accent sur la cartographie sémantique, la gestion du focus, l’étiquetage et les principes POUR, plutôt que sur des résumés généraux de politiques d’accessibilité.

Pourquoi la choisir plutôt qu’un prompt classique

Un prompt classique produit souvent des conseils d’accessibilité vagues. Cette skill est plus utile lorsque vous avez besoin d’un raisonnement structuré, par exemple : identifier d’abord le rôle du composant, privilégier les sémantiques natives, puis définir les libellés, les états, le comportement clavier et le traitement du focus. Cela rend l’usage de la skill accessibility beaucoup plus actionnable pour les revues d’implémentation et les audits.

Comment utiliser la skill accessibility

Contexte d’installation et lecture à faire en premier

Installez la skill via votre workflow de skills, puis ouvrez d’abord skills/accessibility/SKILL.md. Cette skill ne contient ni scripts supplémentaires ni fichiers de référence annexes : l’essentiel des recommandations utiles se trouve donc dans ce document unique. Lisez ces sections dans cet ordre :

1. When to Use
2. Core Concepts
3. How It Works
4. l’étape sur l’identification du rôle du composant

L’installation de accessibility est légère : peu de friction au démarrage, mais il faut prévoir d’apporter vous-même le contexte produit manquant.

Les entrées dont la skill accessibility a besoin

La skill accessibility fonctionne au mieux si vous fournissez :

• la plateforme : Web, iOS ou Android
• le composant ou le parcours : button, modal, form, tabs, menu, carousel, etc.
• l’objectif utilisateur : ce que l’utilisateur essaie d’accomplir
• l’implémentation actuelle : HTML, JSX, SwiftUI/UIKit, Jetpack Compose/View XML, ou captures d’écran avec notes sur le comportement
• les contraintes : limites du design system, balisage legacy, widgets tiers
• la cible d’audit : WCAG 2.2 AA, support clavier, comportement avec lecteur d’écran, ordre du focus, taille des cibles, ou problèmes de nommage/état

Entrée faible : « Rends ça accessible. »
Entrée forte : « Audit this React modal for WCAG 2.2 AA. Check semantic role, accessible name, focus trap, escape behavior, initial focus, return focus, and screen reader announcement. Suggest corrected JSX. »

Transformer un besoin flou en prompt solide

Pour mieux exploiter la skill accessibility, utilisez une structure de prompt comme celle-ci :

• Identifiez le rôle UI et déterminez si un élément natif devrait remplacer l’élément actuel.
• Décrivez l’arbre d’accessibilité attendu.
• Listez les informations requises sur le label, le rôle, l’état, la valeur et les aides.
• Définissez le comportement clavier et du focus.
• Signalez les risques WCAG 2.2 AA.
• Retournez le code corrigé avec un bref résumé d’audit.

Exemple :
« Use the accessibility skill to review this custom dropdown on Web. First decide whether it should be a native select, button + listbox, or another pattern. Then provide the expected ARIA, keyboard interactions, focus movement, visible focus requirements, target size concerns, and revised code. »

Workflow conseillé pour l’audit et l’implémentation avec accessibility

Pour l’accessibility dans un UX Audit, commencez au niveau du parcours, puis descendez au niveau des composants :

1. nommer la tâche et le risque d’échec
2. identifier le rôle réel de chaque élément interactif
3. vérifier d’abord les alternatives sémantiques natives
4. valider les labels, noms, valeurs et états
5. revoir l’ordre clavier et la visibilité du focus
6. tester de manière conceptuelle les annonces du lecteur d’écran
7. demander du code corrigé ou des specs de remédiation

Si vous êtes en phase d’implémentation plutôt que d’audit, demandez à la skill des critères d’acceptation exploitables par l’ingénierie et la QA, pas seulement des conseils rédigés en prose.

FAQ sur la skill accessibility

Cette skill accessibility convient-elle aux débutants ?

Oui, à condition de déjà maîtriser les bases de la construction d’interfaces. La skill explique clairement les concepts fondamentaux de l’accessibility, mais ce n’est pas une formation complète d’initiation aux WCAG. Elle est plus pertinente comme support guidé à l’implémentation que comme unique ressource d’apprentissage.

Est-ce suffisant pour décider d’installer la skill accessibility ?

Dans l’ensemble, oui. La skill a un périmètre clair, un workflow concret et un vrai focus technique. Sa principale limite tient à la profondeur du packaging : il n’y a ni exemples compagnons, ni scripts de test, ni fichiers de référence spécifiques à chaque plateforme. Si vous cherchez beaucoup d’assets réutilisables, elle paraîtra assez légère ; si vous voulez des conseils rapides à adopter, elle est facile à prendre en main.

En quoi est-elle différente d’un prompt accessibility générique ?

La différence tient au cadrage. Ce guide accessibility met au centre l’identification des rôles, la cartographie sémantique, la logique d’arbre d’accessibilité, les libellés et la gestion du focus. Les prompts génériques passent souvent directement aux attributs ARIA, ce qui peut conduire à de la sur-ingénierie ou à des patterns inadaptés.

Quand ne faut-il pas utiliser cette skill ?

Ne vous appuyez pas uniquement sur cette skill accessibility pour une validation juridique, des tests de compatibilité complexes avec des technologies d’assistance, ou des cas limites très spécialisés sur plateformes natives. Elle est particulièrement efficace pour raisonner sur le design et le code, mais elle ne remplace pas des tests manuels sur appareils réels, avec lecteurs d’écran et navigation au clavier seule.

Comment améliorer la skill accessibility

Fournir un contexte UI plus riche, pas seulement des snippets de code

Le principal levier de qualité, c’est le contexte. Précisez la tâche utilisateur, indiquez si le contrôle change un état ou déclenche une navigation, décrivez ce qui apparaît visuellement et ce qui casse aujourd’hui. Les recommandations d’accessibility dépendent du comportement, pas du seul balisage. Un div peut correspondre à plusieurs patterns ; la skill est plus performante quand vous explicitez l’interaction visée.

Demander le choix du pattern avant de demander de l’ARIA

Un mode d’échec fréquent consiste à plaquer de l’ARIA sur le mauvais composant. Pour améliorer les résultats de la skill accessibility, posez d’abord la question : « Quel est réellement ce pattern ? » Par exemple, demandez un arbitrage entre native button, link, disclosure, tab, dialog ou listbox avant de lancer la remédiation. Cela évite souvent des widgets custom inutiles.

Demander une réponse structurée, prête à implémenter

Pour un usage plus solide de la skill accessibility, demandez une réponse structurée :

• problème identifié
• impact utilisateur
• point de vigilance WCAG 2.2
• pattern sémantique recommandé
• modification de code exacte
• étapes de test

Ce format est bien plus adapté à une transmission à l’ingénierie, à la QA ou aux responsables de design system qu’une réponse unique sous forme de long texte.

Itérer à partir de preuves réelles d’échec

Après une première passe, améliorez la sortie de la skill accessibility en réinjectant des éléments précis : texte annoncé par le lecteur d’écran, pièges clavier, absence de focus visible ou mesures de taille des cibles tactiles. La skill devient nettement plus utile quand vous l’utilisez comme boucle d’itération à partir de constats d’UX audit, plutôt que comme simple vérification ponctuelle de conformité.