Cas d’usage
Contenu accessible
L’European Accessibility Act s’applique depuis juin 2025, et la partie de l’accessibilité qui vit dans le contenu peut être traitée là où le contenu vit déjà.
Le problème
- Les textes alternatifs et les libellés ARIA sont écrits en fin de projet, quand le contexte a été oublié.
- Ils sont écrits dans une seule langue, puis traduits sans être relus.
- Personne ne sait quelle proportion du contenu en est pourvue.
Ce que Sonenta change
- Quatre surfaces d’accessibilité vivent à côté de la clé :
aria_label,alt_text,screen_reader,plain_language. - L’agent les génère depuis le texte visible et son contexte, dans toutes vos langues, pendant le développement.
- Un score de lisibilité est calculé en local, sans appel serveur.
- L’outil MCP
wcag_reportmesure la couche de contenu critère par critère, et le rapport de couverture s’exporte.
Le point de départ
// les surfaces vivent à côté de la clé
t("checkout.pay") // « Payer »
t("checkout.pay", { surface: "aria_label" })
t("checkout.pay", { surface: "plain_language" })
// depuis l'agent, via MCP
generate_a11y_variant key=checkout.pay surface=aria_label
wcag_report // mesure de la couche de contenuLimites connues, et elles comptent
- Sonenta ne délivre ni certification ni rapport de conformité. Ce que vous obtenez est un rapport de couverture du contenu accessible, pas un verdict sur votre application.
- Le DOM, le clavier et le focus ne sont pas observés. L’accessibilité d’une application ne se réduit pas à son contenu, et la partie qui reste est la vôtre.
- La déclaration d’accessibilité EAA est un document que vous publiez. Sonenta aide à réunir la matière, il ne l’atteste pas.
Pour aller plus loin
Jusqu'au dernier mot.
Prêt à adapter votre produit à chaque utilisateur ?
Commencez gratuitement en quelques minutes. Sans carte de crédit, sans engagement, avec vos exports toujours ouverts.