Accessibility

The model

Accessibility in Sonenta lives in the content layer, alongside your translations. The model rests on three elements:

• Typed keys: each key has a type (button, heading, image, label...) that decides which accessibility surfaces it must carry and which ARIA role it plays.
• The cognitive score: a plain-language readability measure, computed locally, 0 credit, that spots texts that are hard to understand.
• Accessibility surfaces: four content layers, distinct from the visible text. See also Surfaces.

The four accessibility surfaces

• aria_label: the accessible name of an interactive element (button, icon, link) when the visible text is not enough.
• alt_text: the alternative text of an image, its meaning.
• screen_reader: text reserved for screen readers (sr-only), for context that a sighted user infers visually.
• plain_language: a plain-language (FALC) version of the value, for cognitive load.

Coverage, and what it is not

Sonenta measures the accessibility content in your strings: alternative texts, accessible names, screen-reader texts and plain language. The report tells you which surfaces are filled, in which languages, and what is missing.

It is a coverage report, not a conformance audit. It attests no WCAG level. Whether your product conforms depends on the rendered DOM, on keyboard operability, on focus order and on interaction, none of which a content layer can observe.

It is useful for the European Accessibility Act in one way only: it documents the state of the accessible content you ship, which is one input among others to an accessibility statement you write and own.

The Sonenta tools

• Agents: sonenta-a11y generates the aria_label / alt_text / screen_reader values and the plain-language rewrites, then wires them into your code (WIRE mode). sonenta-surface configures the surfaces (config-only).
• Review queue: each proposal goes through the dashboard, where you approve, edit, or reject. Nothing is published without validation.
• Coverage report: the state of the accessibility surfaces you ship, exportable, to file with the record you build. It is not a conformance audit.

The flow

1. Classify the key-types: assign the right type to each key (the right types surface the right surfaces).
2. Generate the surfaces: the sonenta-a11y agent writes the accessibility values and the plain-language versions.
3. Review: the dashboard's review queue (approve / edit / reject).
4. Publish: the validated surfaces go to the CDN, picked up by your app without any code change.
5. Apply: WIRE mode wires aria_label / alt_text / screen_reader into your code (accessors t.aria / t.alt / t.a11y); plain_language applies via the global FALC toggle.

Credits

The cognitive score is computed locally, 0 credit. The server-side generation and analysis (by the agents) are billed.