Sono AAC
Funktionen Lektionen Für wen Stimmen Leitfaden Datenschutz Support App holen
  • 🇬🇧 English EN
  • 🇩🇪 Deutsch DE
  • 🇮🇹 Italiano IT
  • 🇫🇷 Français FR
  • 🇪🇸 Español ES
  • 🇭🇷 Hrvatski HR
  • 🇨🇿 Čeština CS
  • 🇵🇱 Polski PL
  • 🇫🇮 Suomi FI
  • 🇸🇰 Slovenčina SK
  • 🇩🇰 Dansk DA
← Zurück zur Startseite

Barrierefreiheitserklärung – Sono AAC Communicator

Zuletzt aktualisiert: 25. Mai 2026


1. Geltungsbereich

Diese Barrierefreiheitserklärung gilt für:

  • Die mobile Anwendung Sono AAC Communicator für Android und iOS.
  • Die Werbe-Website von Sono AAC Communicator, sofern aus dem Projekt plugins/communicator/promo veröffentlicht.

Sono ist eine symbolbasierte Anwendung zur unterstützten und alternativen Kommunikation (AAC). Sie soll Menschen dabei helfen, mit Bildern, Satzbildung und Text-zu-Sprache zu kommunizieren.

1.1 Europäisches Barrierefreiheitsgesetz (Richtlinie (EU) 2019/882)

Das Europäische Barrierefreiheitsgesetz (“EAA”) und seine nationalen Umsetzungen gelten seit dem 28. Juni 2025. Unsere derzeitige Geltungsbereichsanalyse unter dem EAA ist wie folgt.

EAA-KategorieWahrscheinlicher Status für SonoHinweise
Verbraucher-EndgeräteNicht anwendbarSono ist Software, keine Hardware.
E-Commerce-DiensteWahrscheinlich im Geltungsbereich nur wenn Sono Verbrauchern in der EU zum Verkauf oder zum In-App-Kauf angeboten wird. Die derzeitige öffentliche Distribution (kostenloser Download über die Plattform-App-Stores, keine In-App-Käufe, kein vom Herausgeber betriebener Commerce-Flow) wird nicht als E-Commerce-Dienst im Geltungsbereich behandelt.Neu bewerten, wenn Preise, kostenpflichtige Stufen oder ein vom Herausgeber betriebener Checkout eingeführt werden.
Dienste, die Zugang zu audiovisuellen Mediendiensten bietenNicht anwendbarSono ist kein audiovisueller Mediendienst.
Software, die primär für den Zugriff auf audiovisuelle Mediendienste verwendet wirdNicht anwendbarSono ist nicht für den AVMS-Zugriff konzipiert.
Sonstige Software / mobile AnwendungenDas EAA legt keine allgemeine Barrierefreiheitsverpflichtung für jede mobile Anwendung fest, jedoch können Mitgliedstaaten weitergehende nationale Regelungen verabschieden. Wir betrachten die mobile Anwendung Sono als außerhalb des strikten EAA-Geltungsbereichs gemäß Richtlinie (EU) 2019/882 selbst, während wir uns freiwillig an WCAG 2.2 AA und EN 301 549 ausrichten, wie in Abschnitt 2 dargelegt.Wo eine spezifische Beschaffung (öffentlicher Sektor oder kommerziell) ein strengeres Regime auslöst — beispielsweise die Richtlinie über die Barrierefreiheit von Websites (EU) 2016/2102 für öffentliche Stellen — werden wir auf Anfrage ein angepasstes Konformitätsartefakt bereitstellen (siehe Abschnitt 11).

Kleinstunternehmen-Erwägung: Der Herausgeber agiert als Einzelpersonen-Kleinstunternehmen im Sinne des EAA und der EU-Empfehlung 2003/361/EG zur Definition von Kleinstunternehmen sowie kleinen und mittleren Unternehmen. Kleinstunternehmen, die Dienstleistungen erbringen, können von einer teilweisen Ausnahme gemäß Artikel 4 Absatz 5 EAA profitieren. Dies wird nur als Hintergrund vermerkt und reduziert nicht unsere freiwillige Ausrichtung an WCAG 2.2 AA / EN 301 549.

Nationales Recht: Die kroatische Umsetzungsgesetzgebung (das Zakon o pristupačnosti proizvoda i usluga osoba s invaliditetom i drugih osoba s teškoćama und verwandte Instrumente) hat Vorrang vor dieser allgemeinen Analyse. Wo es zusätzliche Verpflichtungen für diese App auferlegt, setzen sich diese Verpflichtungen durch.


2. Engagement für Barrierefreiheit

Wir möchten, dass Sono von Menschen mit einer breiten Palette an Kommunikations-, motorischen, kognitiven, visuellen, auditiven und Lernbedürfnissen verwendet werden kann.

Barrierefreiheit ist für eine AAC-App besonders wichtig, da sich Benutzer möglicherweise für die alltägliche Kommunikation darauf verlassen. Unser Ziel ist es, Sono mit Folgendem in Einklang zu bringen:

  • Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, wo zutreffend.
  • EN 301 549, wo auf mobile Anwendungen, Software und Webinhalte zutreffend.

3. Konformitätsstatus

Sono entspricht derzeit teilweise WCAG 2.2 Level AA und den anwendbaren Barrierefreiheitsanforderungen von EN 301 549.

“Teilweise konform” bedeutet, dass einige Teile der App und der Werbe-Website noch nicht vollständig dem Barrierefreiheitsstandard entsprechen.

Diese Erklärung basiert auf einer internen Barrierefreiheitsprüfung, die am 25. Mai 2026 durchgeführt wurde. Die Prüfung umfasste eine statische Codeinspektion gegenüber den Anforderungen von WCAG und EN 301 549. Sie wurde noch nicht mit einer vollständigen manuellen Prüfung unter Verwendung von VoiceOver, TalkBack, externer Tastaturnavigation, Schaltsteuerung, browserbasierten Barrierefreiheits-Tools oder Usability-Tests mit Menschen mit Behinderungen abgeschlossen.


4. Barrierefreiheitsfunktionen

Sono umfasst mehrere Design- und technische Entscheidungen, die die Barrierefreiheit unterstützen sollen:

  • Symbolbasierte Kommunikation mit großen visuellen Zielen.
  • Text-zu-Sprache-Ausgabe für zusammengestellte Nachrichten.
  • Offline-First-Betrieb nach der Installation.
  • Optionale Offline-Stimmen-Downloads.
  • Unterstützung für mehrere Sprachen.
  • Einige semantische Beschriftungen für Symbolkarten, Satzleisten-Steuerelemente und ausgewählte Zustände.
  • Unterstützung für systemweite Textskalierung in Teilen der Benutzeroberfläche.
  • Betreuungspersonen-Einstellungen zur Anpassung von Brettlayout, Stimme, Anzeigestil und Symbolinhalten.

Diese Funktionen unterstützen die Barrierefreiheit, garantieren aber noch keine vollständige Konformität.


5. Bekannte Barrierefreiheitseinschränkungen

Die folgenden Einschränkungen sind zum Datum dieser Erklärung bekannt.

5.1 Tastatur- und Schaltzugriff

Einige interaktive Steuerelemente sind als benutzerdefinierte Touch-Ziele implementiert und sind möglicherweise nicht über eine externe Tastatur, Schaltersteuerung oder eine Aktivierungsgeste einer assistiven Technologie erreichbar oder bedienbar.

Dies betrifft Teile des Symbolbretts, der Kategorienavigation, der Satzleiste, der Einstellungsauswahl, der Spiele, der Whiteboard-Steuerelemente und der Sprachauswahl der Werbe-Website.

Relevante Anforderungen umfassen WCAG 2.1.1 Tastatur, WCAG 2.4.7 Fokus sichtbar, WCAG 4.1.2 Name, Rolle, Wert sowie die entsprechenden anwendbaren Software-Anforderungen von EN 301 549.

5.2 Spiele und Whiteboard

Einige Spielinteraktionen und der Zeichenbereich des Whiteboards basieren auf Touchgesten. Äquivalente Tastatur-, Schalter- oder Nicht-Zeiger-Alternativen sind noch nicht für alle Spiel- und Whiteboard-Funktionen bereitgestellt.

Relevante Anforderungen umfassen WCAG 2.1.1 Tastatur, WCAG 2.5.1 Zeigergesten und WCAG 4.1.2 Name, Rolle, Wert.

5.3 Farbkontrast

Einige Kategoriefarben, ausgewählte Zustände, Icon-Farben und Theme-Farboptionen erfüllen möglicherweise nicht die Mindestkontrastanforderungen für Text- oder Nicht-Text-UI-Komponenten.

Relevante Anforderungen umfassen WCAG 1.4.3 Kontrast (Minimum) und WCAG 1.4.11 Nicht-Text-Kontrast.

5.4 Textgrößenänderung und Reflow

Einige Beschriftungen und Rasterlayouts verwenden feste Größen, einzeilige Beschriftungen oder Auslassungspunkte. Bei großen Systemtextgrößen kann einiger Text abgeschnitten, gekürzt oder schwer lesbar werden.

Relevante Anforderungen umfassen WCAG 1.4.4 Textgrößenänderung und WCAG 1.4.10 Reflow.

5.5 Bildschirmleser-Ansagen

Einige dynamische Aktualisierungen sind nur visuell und werden möglicherweise nicht automatisch von Bildschirmlesern angesagt. Dazu gehören Bestätigungsbanner für gesprochene Nachrichten, Änderungen der Suchergebnisanzahl und einige Lade- oder Verarbeitungszustände.

Relevante Anforderung: WCAG 4.1.3 Statusmeldungen.

5.6 Dialoge und Overlays

Einige benutzerdefinierte Dialoge und Overlays bieten noch keine vollständige modale Semantik, Fokusverwaltung, beschriftete Schließsteuerelemente oder vorhersehbare Tastaturfokus-Reihenfolge.

Relevante Anforderungen umfassen WCAG 2.4.3 Fokusreihenfolge, WCAG 2.4.7 Fokus sichtbar und WCAG 4.1.2 Name, Rolle, Wert.

5.7 Betreuungspersonen-Zugangstor

Der Zugang zu den Betreuungspersonen-Einstellungen kann das Lösen einer einfachen mathematischen Frage erfordern. Dies kann für einige Betreuungspersonen oder Benutzer eine unnötige kognitive Barriere darstellen.

Relevante Anforderung: WCAG 3.3.8 Barrierefreie Authentifizierung (Minimum), wo diese Interaktion als Authentifizierungs- oder Zugangskontrollschritt behandelt wird.

5.8 Lokalisierung barrierefreier Namen

Einige Barrierefreiheitsbeschriftungen und Unterstützungstexte sind derzeit fest auf Englisch codiert, auch wenn die App in einer anderen Sprache verwendet wird.

Relevante Anforderungen umfassen WCAG 3.1.2 Sprache von Teilen und WCAG 4.1.2 Name, Rolle, Wert.

5.9 Werbe-Website-Links und Sprachauswahl

Die Sprachauswahl der Werbe-Website verwendet benutzerdefinierte ARIA-Rollen, bietet aber noch keine vollständige Tastaturinteraktion. Einige App-Store-Links können auch Platzhalter sein, bis endgültige Store-Einträge verfügbar sind.

Relevante Anforderungen umfassen WCAG 2.1.1 Tastatur, WCAG 2.4.4 Linkzweck und WCAG 4.1.2 Name, Rolle, Wert.


6. Alternativen und Workarounds

Wo eine Funktion noch nicht vollständig barrierefrei ist:

  • Benutzer können möglicherweise das Haupt-Symbolbrett mit Touch-Eingabe verwenden, während der Tastatur- und Schalterzugriff verbessert wird.
  • Betreuungspersonen können Rastergröße, Anzeigestil, Stimme, Sprache und Symbolinhalte anpassen, um den Bedürfnissen des Benutzers besser zu entsprechen.
  • Benutzer, die Schwierigkeiten mit Spiel- oder Whiteboard-Interaktionen haben, können das zentrale Kommunikationsbrett weiterhin verwenden.
  • Benutzer und Betreuungspersonen können uns kontaktieren, um Unterstützung anzufordern, eine Barriere zu melden oder einen alternativen Zugangsweg zu erfragen.

7. Geplante Verbesserungen

Die aktuellen Prioritäten zur Behebung von Barrierefreiheit, Eigentümer und Zielfenster sind unten aufgeführt. Alle Eigentümer sind der Herausgeber (Matan Ljubas), sofern nicht anders angegeben. Zielfenster sind indikativ und werden im Laufe der Arbeit und nach Erhalt von Benutzerfeedback überarbeitet.

#PrioritätEigentümerZielfenster
1Touch-only-Steuerelemente durch barrierefreie Steuerelemente ersetzen, die Tastaturfokus, Aktivierung, Rollen, Namen, ausgewählte Zustände, deaktivierte Zustände und sichtbare Fokusindikatoren unterstützen.HerausgeberNächste zwei kleine Releases
2Vollständige Semantik und Tastatur-Alternativen für Spiele und Whiteboard-Tools hinzufügen, wo dies praktikabel ist.HerausgeberInnerhalb von 6 Monaten nach dieser Erklärung
3Farbkontrastverarbeitung zentralisieren, sodass Text und Icons automatisch eine barrierefreie Vordergrundfarbe wählen.HerausgeberNächstes kleines Release
4Unterstützung für großen Text verbessern und Abschneidung in Rastern, Tabs, Chips und Satzbildungs-UI reduzieren.HerausgeberInnerhalb von 6 Monaten nach dieser Erklärung
5Bildschirmleser-Ansagen für Statusmeldungen, Suchergebnisse, Ladezustände und Sprachfeedback hinzufügen.HerausgeberInnerhalb von 6 Monaten nach dieser Erklärung
6Fokusbehandlung, modale Semantik und beschriftete Schließaktionen in benutzerdefinierten Overlays verbessern.HerausgeberInnerhalb von 6 Monaten nach dieser Erklärung
7Das mathematische Tor für Betreuungspersonen durch eine barrierefreie Alternative gemäß WCAG 3.3.8 ersetzen oder ergänzen.HerausgeberInnerhalb von 6 Monaten nach dieser Erklärung
8Barrierefreiheitsbeschriftungen und Unterstützungstexte konsistent in allen unterstützten Sprachen lokalisieren.HerausgeberInnerhalb von 12 Monaten nach dieser Erklärung
9Vollständige manuelle Prüfung mit VoiceOver, TalkBack, externer Tastatur und Schaltersteuerung durchführen, idealerweise einschließlich Usability-Tests mit AAC-Benutzern.Herausgeber (engagiert externe Tester, wo dies möglich ist)Innerhalb von 12 Monaten nach dieser Erklärung
10Automatische und manuelle Barrierefreiheitsprüfungen zum Veröffentlichungsprozess hinzufügen.HerausgeberInnerhalb von 6 Monaten nach dieser Erklärung

Wenn eine Beschaffung, ein gewerblicher Kunde oder ein Käufer aus dem öffentlichen Sektor vor diesen Zeitfenstern einen formellen Accessibility Conformance Report oder ein VPAT-ähnliches Artefakt benötigt, werden wir auf Anfrage eines vorbereiten und teilen — siehe Abschnitt 11.


8. Bewertungsansatz

Diese Erklärung wurde durch Selbstbewertung erstellt.

Die Bewertung umfasste:

  • Statische Inspektion von Flutter-Widgets und Code der Werbe-Website.
  • Überprüfung anhand der WCAG 2.2 Erfolgskriterien.
  • Überprüfung anhand der anwendbaren Software- und Web-Anforderungen von EN 301 549.
  • flutter analyze für das Communicator-Paket.

Die Bewertung umfasste noch nicht:

  • Vollständige VoiceOver-Tests auf iOS.
  • Vollständige TalkBack-Tests auf Android.
  • Vollständige Tests mit externer Tastatur.
  • Schaltersteuerungstests.
  • Browserbasierte automatisierte Barrierefreiheitstests der Werbe-Website.
  • Benutzertests mit Menschen mit Behinderungen oder AAC-Benutzern.

9. Feedback, Kontakt und Eskalation

Wir begrüßen Feedback zu Barrierefreiheitsbarrieren in Sono.

Primärer Kontakt:

Matan Ljubas 10A Ul. Joze Krstića, Zadar, Zadarska županija 23000, Croatia E-Mail: lj.matan@gmail.com

Alternative barrierefreie Kontaktmethoden. Wenn E-Mail für Sie nicht zugänglich ist, können Sie den Herausgeber auch per Post unter der obigen Adresse erreichen. Wenn Sie einen alternativen Kanal benötigen (zum Beispiel aufgrund einer Behinderung oder aufgrund der Kompatibilität mit assistiver Technologie), geben Sie bitte den Kanal an, den Sie verwenden können — per Post, durch Bitten eines Dritten, in Ihrem Namen eine E-Mail zu senden, oder durch andere zumutbare Mittel — und wir werden unser Bestes geben, über einen für Sie passenden Kanal zu antworten.

Wenn Sie ein Barrierefreiheitsproblem melden, geben Sie bitte, wo möglich, Folgendes an:

  • Das Gerät und Betriebssystem, das Sie verwenden;
  • Die App-Version, sofern bekannt;
  • Die in der App ausgewählte Sprache;
  • Den Bildschirm oder die Funktion, wo das Problem auftrat;
  • Die verwendete assistive Technologie, sofern vorhanden;
  • Eine kurze Beschreibung dessen, was passiert ist und was Sie erwartet hatten.

Die Angabe dieser Informationen ist keine Voraussetzung für unsere Antwort — wir arbeiten mit dem, was Sie uns geben können.

Antworterwartungen. Wir streben an:

  • Barrierefreiheits-Feedback innerhalb von sieben (7) Kalendertagen nach Erhalt zu bestätigen;
  • Eine inhaltliche Antwort, einschließlich einer ersten Bewertung und eines indikativen Behebungszeitplans, innerhalb von dreißig (30) Kalendertagen zu liefern;
  • Barrieren zu priorisieren, die Kommunikation, Navigation oder die Kernnutzung der App verhindern.

Wo eine Barriere nicht schnell behoben werden kann, werden wir, wo dies vernünftigerweise möglich ist, einen vorläufigen Workaround vorschlagen (siehe Abschnitt 6).

Eskalation. Wenn Sie mit unserer Antwort auf eine Barrierefreiheitsbeschwerde nicht zufrieden sind, können Sie die Angelegenheit an die zuständigen kroatischen Behörden für Barrierefreiheit, Gleichbehandlung und Verbraucherschutz eskalieren — einschließlich, soweit zutreffend, des kroatischen Bürgerbeauftragten (Pučki pravobranitelj, ombudsman.hr), des Beauftragten für Menschen mit Behinderungen (Pravobranitelj za osobe s invaliditetom, posi.hr) und der entsprechenden Marktüberwachungsbehörde, die nach kroatischer Umsetzungsgesetzgebung für die Richtlinie (EU) 2019/882 (Europäisches Barrierefreiheitsgesetz) benannt ist.


10. Überprüfung und Aktualisierungen

Diese Erklärung wird nach wesentlichen Barrierefreiheitsänderungen und mindestens einmal jährlich überprüft.

Zukünftige Aktualisierungen sollten die Ergebnisse manueller Tests mit assistiver Technologie und alle abgeschlossenen Behebungsarbeiten enthalten.


11. Accessibility Conformance Report (ACR / VPAT)

Ein formeller Accessibility Conformance Report (auch häufig als VPAT — Voluntary Product Accessibility Template bezeichnet) wurde für Sono noch nicht veröffentlicht. Wo eine Beschaffung, ein gewerblicher Kunde oder ein Käufer aus dem öffentlichen Sektor ein ACR oder VPAT-ähnliches Artefakt benötigt, kann der Herausgeber auf Anfrage eines vorbereiten, das den Konformitätsstatus und die bekannten Einschränkungen widerspiegelt, die in den Abschnitten 3, 5 und 7 dieser Erklärung beschrieben sind. Anfragen sollten über die Kontaktdaten in Abschnitt 9 erfolgen und sollten den Standard angeben, gegen den die Konformität gemeldet werden soll (zum Beispiel WCAG 2.2 AA, EN 301 549 oder Section 508 des US Rehabilitation Act).


12. Formelle Genehmigung

Diese Barrierefreiheitserklärung ist genehmigt von:

Matan Ljubas
Herausgeber von Sono AAC Communicator


Diese Erklärung soll den aktuellen Stand der Barrierefreiheit von Sono AAC Communicator beschreiben. Sie ist keine Garantie für vollständige rechtliche Konformität und ersetzt keine Rechtsberatung für eine spezifische Rechtsprechung, einen Beschaffungsprozess oder eine regulatorische Verpflichtung.

Sono

Symbolbasierte AAC-App für Android

Rechtliches

DatenschutzerklärungNutzungsbedingungenCookie-RichtlinieBarrierefreiheitserklärung

Kontakt

lj.matan@gmail.com

© 2026 Sono AAC · Alle Rechte vorbehalten