Accessibilité

Le modèle

L'accessibilité dans Sonenta vit dans la couche de contenu, à côté de vos traductions. Le modèle repose sur trois éléments :

• Les clés typées : chaque clé a un type (bouton, titre, image, label...) qui décide quelles surfaces d'accessibilité elle doit porter et quel rôle ARIA elle joue.
• Le score cognitif : une mesure de lisibilité en langage clair, calculée en local, 0 crédit, qui repère les textes difficiles à comprendre.
• Les surfaces d'accessibilité : quatre couches de contenu, distinctes du texte visible. Voir aussi Surfaces.

Les quatre surfaces d'accessibilité

• aria_label : le nom accessible d'un élément interactif (bouton, icône, lien) quand le texte visible ne suffit pas.
• alt_text : le texte alternatif d'une image, sa signification.
• screen_reader : un texte réservé aux lecteurs d'écran (sr-only), pour le contexte qu'un voyant déduit visuellement.
• plain_language : une version en langage clair (FALC) de la valeur, pour la charge cognitive.

La couverture, et ce qu'elle n'est pas

Sonenta mesure le contenu d'accessibilité présent dans vos chaînes : textes alternatifs, noms accessibles, textes pour lecteurs d'écran et langage clair. Le rapport indique quelles surfaces sont remplies, dans quelles langues, et ce qui manque.

C'est un rapport de couverture, pas un audit de conformité. Il n'atteste aucun niveau WCAG. Que votre produit soit conforme dépend du DOM rendu, de l'accès clavier, de l'ordre de focus et de l'interaction, qu'une couche de contenu ne peut pas observer.

Il sert à l'European Accessibility Act d'une seule façon : il documente l'état du contenu accessible que vous publiez, ce qui est une entrée parmi d'autres dans une déclaration d'accessibilité que vous rédigez et dont vous répondez.

Les outils Sonenta

• Agents : sonenta-a11y génère les valeurs aria_label / alt_text / screen_reader et les reformulations en langage clair, puis les câble dans votre code (mode WIRE). sonenta-surface configure les surfaces (config-only).
• File de revue : chaque proposition passe par le tableau de bord, où vous approuvez, modifiez ou rejetez. Rien n'est publié sans validation.
• Rapport de couverture : l'état des surfaces d'accessibilité que vous publiez, exportable, à verser au dossier que vous constituez. Ce n'est pas un audit de conformité.

Le flux

1. Classer les key-types : assignez le bon type à chaque clé (les bons types font apparaître les bonnes surfaces).
2. Générer les surfaces : l'agent sonenta-a11y rédige les valeurs d'accessibilité et les versions en langage clair.
3. Relire : la file de revue du tableau de bord (approuver / modifier / rejeter).
4. Publier : les surfaces validées partent sur le CDN, reprises par votre app sans changement de code.
5. Appliquer : le mode WIRE câble aria_label / alt_text / screen_reader dans votre code (accesseurs t.aria / t.alt / t.a11y) ; plain_language s'applique via le toggle FALC global.

Crédits

Le score cognitif est calculé en local, 0 crédit. La génération et l'analyse côté serveur (par les agents) sont facturées.