Aller au contenu

Rendre votre app accessible

Deux agents travaillent ensemble : sonenta-surface (décide quelles surfaces existent) et sonenta-a11y (remplit + applique les valeurs). Installez : sonenta agents add sonenta-surface et sonenta agents add sonenta-a11y.

Prompt :

En utilisant sonenta-surface, audite ma configuration de surfaces et recommande quelles surfaces a11y activer.

Produit : une recommandation des surfaces à activer - a11y (aria_label, alt_text, screen_reader, plain_language) et device (desktop/mobile/tablet + personnalisées). Revue : config proposée montrée avant changement ; les surfaces actives apparaissent dans le tableau de bord. Application : à l'acceptation, il active/renomme les surfaces (config seulement, 0 crédit). Il passe ensuite le remplissage des valeurs à sonenta-a11y.

Prompt :

En utilisant sonenta-a11y, audite l'accessibilité de mon app et montre-moi le plan de remédiation.

Produit : un audit WCAG 2.2 conscient du code + un plan de remédiation, plus des scores de lisibilité/cognitifs locaux. Rien n'est encore écrit. Revue : le plan, les corrections par manque, et le taux de couverture avant. Application : rien avant votre acceptation.

Prompt :

Génère les aria-labels, textes alternatifs et réécritures en langage simplifié à partir du plan, puis soumets-les à ma revue.

Produit : des valeurs de surfaces a11y brouillons (0 crédit ; l'IA serveur est un repli opt-in). Revue : les variantes + scores cognitifs apparaissent dans la file de revue du tableau de bord - approuvez ou éditez. Les éléments rejetés sont régénérés à partir de votre motif de rejet. Application : approuver publie les surfaces.

Les surfaces aria_label / alt_text / screen_reader approuvées ne s'affichent que lorsque vos composants les lisent (via @sonenta/react-i18next).

Prompt :

Câble mes surfaces a11y publiées dans le code.

Produit : les liaisons de code uniques (aria-label={t.aria(key)}, alt={t.alt(key)}, nœuds lecteur d'écran) ajoutées aux composants qui rendent ces clés, de façon idempotente. Revue : un diff de code classique. Application : à l'acceptation. Ensuite, les futurs changements approuvés passent en ligne via le CDN sans nouveau câblage. (Le langage simplifié ne nécessite aucun câblage - il s'applique via le toggle FALC.)

Prompt :

Produis une déclaration de conformité WCAG 2.2 et une déclaration EAA / EN 301 549.

Produit : des déclarations de conformité + d'accessibilité formelles que vous pouvez publier.