Anwendungsfall
Barrierefreie Inhalte
Der European Accessibility Act gilt seit Juni 2025, und der Teil der Barrierefreiheit, der im Inhalt lebt, lässt sich dort bearbeiten, wo der Inhalt ohnehin liegt.
Das Problem
- Alt-Texte und ARIA-Labels werden am Projektende geschrieben, wenn der Kontext vergessen ist.
- Sie werden in einer Sprache geschrieben und dann ohne Prüfung übersetzt.
- Niemand weiß, welcher Anteil des Inhalts sie überhaupt hat.
Was Sonenta ändert
- Vier Barrierefreiheits-Surfaces liegen neben dem Schlüssel:
aria_label,alt_text,screen_reader,plain_language. - Der Agent erzeugt sie aus dem sichtbaren Text und seinem Kontext, in allen Ihren Sprachen, während der Entwicklung.
- Ein Lesbarkeitswert wird lokal berechnet, ohne Serveraufruf.
- Das MCP-Tool
wcag_reportmisst die Inhaltsschicht Kriterium für Kriterium, und der Abdeckungsbericht lässt sich exportieren.
Der Einstieg
// 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 contenuBekannte Grenzen, und sie zählen
- Sonenta stellt weder eine Zertifizierung noch einen Konformitätsbericht aus. Was Sie bekommen, ist ein Abdeckungsbericht für barrierefreie Inhalte, kein Urteil über Ihre Anwendung.
- DOM, Tastatur und Fokus werden nicht beobachtet. Die Barrierefreiheit einer Anwendung geht nicht in ihrem Inhalt auf, und der Rest bleibt bei Ihnen.
- Die EAA-Barrierefreiheitserklärung ist ein Dokument, das Sie veröffentlichen. Sonenta hilft, das Material zusammenzutragen, es bescheinigt es nicht.
Bis zum letzten Wort.
Bereit, Ihr Produkt an jeden Nutzer anzupassen?
Starten Sie kostenlos in wenigen Minuten. Ohne Kreditkarte, ohne Verpflichtung, mit Ihren stets offenen Exporten.