Unser Engagement für Barrierefreiheit

Lioma verpflichtet sich, die digitale Barrierefreiheit für Menschen mit Behinderungen sicherzustellen. Wir verbessern kontinuierlich das Nutzererlebnis für alle und wenden die einschlägigen Standards für Barrierefreiheit an.

Wir streben die Einhaltung der Standards der Web Content Accessibility Guidelines (WCAG) 2.1 Stufe AA an, wie sie vom Americans with Disabilities Act (ADA) in den USA und vom European Accessibility Act (EAA) in der EU gefordert werden.

Ergebnisse des Barrierefreiheits-Audits

Im März 2026 haben wir die Anwendung anhand aller 50 Erfolgskriterien der Stufen A und AA geprüft. Im Juli 2026 haben wir die öffentlichen Seiten (Startseite, Rechtstexte, Support und die Kontoseiten) mit automatisierten Werkzeugen und manuell erneut geprüft.

Was das Audit im Juli 2026 ergeben hat, und was wir behoben haben

Die erneute Prüfung fand auf den öffentlichen Seiten vier tatsächliche Mängel. Alle vier sind behoben:

Kontrast der Überschriften (WCAG 1.4.3): Hauptüberschriften standen im Markenton Lachs und erreichten gegenüber dem Seitenhintergrund nur 2,4:1, erforderlich sind 4,5:1. Alle Überschriften nutzen jetzt das Akzent-Navy, mit 10,4:1.
Fehlender Hauptbereich (WCAG 1.3.1): Die öffentlichen Seiten stellten ihre Inhalte außerhalb jeder Landmarke dar, sodass Screenreader-Nutzende beim Navigieren nach Landmarken nichts fanden. Jede öffentliche Seite hat nun genau ein <main>.
Sprunglink (WCAG 2.4.1): Der Link zum Überspringen der Navigation existierte in der angemeldeten App, aber nicht auf den öffentlichen Seiten, auf denen die meisten Besuchenden ankommen. Er ist jetzt auf jeder öffentlichen Seite vorhanden.
Bedienelement ohne Namen (WCAG 4.1.2): Ein zurückgezogener FAQ-Eintrag auf der Supportseite wurde weiterhin als leere Akkordeon-Zeile ausgegeben: eine per Tastatur erreichbare Schaltfläche ohne zugänglichen Namen. Leere Einträge werden nicht mehr ausgegeben.

Was gut funktioniert

Formularbarrierefreiheit: Alle Formulare verwenden korrekte Beschriftungen, über aria-describedby verknüpfte Inline-Fehlermeldungen und aria-invalid-Zustände für die Validierungsrückmeldung
Tastaturnavigation: Alle interaktiven Elemente sind native Schaltflächen und Links, vollständig per Tastatur bedienbar und ohne Tastaturfallen
Fokus-Sichtbarkeit: Alle interaktiven Elemente zeigen sichtbare Fokusringe unter Verwendung des focus-visible-CSS-Musters, für Mausnutzer ausgeblendet
Skip-Links: Skip-to-Main-Content-Link für Tastaturnutzer verfügbar (WCAG 2.4.1)
Touch-Ziele: Alle Schaltflächen und interaktiven Elemente erfüllen die Mindestgröße von 44x44 px
Bewegungseinstellungen: Alle Animationen sind in prefers-reduced-motion-Media-Queries eingebettet
Dialog-Barrierefreiheit: Modale Dialoge verwenden role="dialog", aria-modal, Schließen per Escape-Taste und korrektes Fokusmanagement
Screenreader-Unterstützung: Umfassende Nutzung von ARIA-Labels, Live-Regionen (aria-live), semantischen HTML-Landmarks und visuell ausgeblendetem Text
Live-Regionen: Toast-Benachrichtigungen, Gesprächsprotokolle, Änderungen des Aufnahmestatus, Ladezustände und Offline-Anzeigen kündigen Aktualisierungen für Screenreader an
Semantische Struktur: Navigations-Landmarks mit aria-label, Article-Elemente für Reflexionseinträge, Sprecheridentifikation bei Gesprächsnachrichten
Mobile Barrierefreiheit: Safe-Area-Unterstützung für Geräte mit Notch, natives Tastaturerlebnis, je Feldtyp optimierte Eingabemodi
Dynamische Sprache: Das HTML-lang-Attribut aktualisiert sich automatisch, wenn der Nutzer die Sprache wechselt (WCAG 3.1.1)
Icon-Schaltflächen: Alle reinen Icon-Schaltflächen enthalten beschreibende ARIA-Labels für Screenreader
Automatisierte Durchsetzung: ESLint-jsx-a11y-Plugin mit über 20 Regeln, die zur Build-Zeit durchgesetzt werden, sowie axe-core-Laufzeitprüfung während der Entwicklung

Bereiche mit laufender Verbesserung

Farbkontrast: Wir testen Farbkombinationen regelmäßig auf die Einhaltung des Kontrastverhältnisses von 4,5:1 (WCAG 1.4.3)
Überschriftenhierarchie: Wir verfeinern die Überschriftenebenen über kartenbasierte Layouts hinweg für eine klarere Dokumentstruktur
Fehlervorschläge: Wir erweitern die Formularvalidierung, um spezifischere Korrekturvorschläge zu liefern

Funktionen zur Barrierefreiheit

Navigation

Skip-Link, um die Navigation zu überspringen und direkt zum Hauptinhalt zu gelangen
Einheitliche Navigationsstruktur mit beschrifteten Nav-Landmarks
Überschriftenhierarchie (H1, H2, H3) für eine einfache Dokumentnavigation
Landmark-Regionen (Header, Main, Footer, Nav) mit aria-labels für die Screenreader-Navigation
Mehrere Wege, um alle Inhalte zu erreichen (Navigationsleiste, Direktlinks, Suche)

Visuell

Text erreicht das WCAG-AA-Mindestkontrastverhältnis von 4,5:1 gegenüber seinem Hintergrund
Text kann ohne Funktionsverlust bis auf 200 % vergrößert werden
Kein Inhalt verlässt sich zur Informationsvermittlung ausschließlich auf Farbe
Animationen können über die Systemeinstellungen deaktiviert werden (prefers-reduced-motion)
Inhalte fließen bei allen Viewport-Größen korrekt um, ohne horizontales Scrollen

Interaktion

Alle interaktiven Elemente verwenden native HTML-Schaltflächen und -Links für volle Tastatur- und Assistenztechnologie-Unterstützung
Sichtbare Fokusindikatoren auf allen interaktiven Elementen (für Mausnutzer ausgeblendet)
Keine Tastaturfallen; Nutzer können sich frei mit Tab und Escape bewegen
Touch-Ziele sind auf allen Plattformen mindestens 44x44 Pixel groß
Formulareingaben haben sichtbare Beschriftungen, Inline-Fehlermeldungen und aria-invalid-Zustände
Wischgesten haben stets Tastaturalternativen (Escape-Taste zum Schließen von Modals)

Assistenztechnologie

Kompatibel mit gängigen Screenreadern (VoiceOver, NVDA, JAWS)
ARIA-Attribute werden für dynamische Inhalte, Dialoge und Formularvalidierung angemessen verwendet
Live-Regionen kündigen Änderungen des Aufnahmestatus, Ladezustände, neue Nachrichten und Benachrichtigungen an
Bilder haben geeigneten Alternativtext; dekorative Bilder werden vor Screenreadern verborgen
Gesprächsnachrichten identifizieren den Sprecher („KI-Assistent sagt", „Sie sagen") für den Screenreader-Kontext

KI-Sprachfunktion

Unsere KI-Coaching-Funktion unterstützt sowohl Sprach- als auch Textinteraktion:

Textalternative: Alle Sprachkonversationen werden transkribiert und in Echtzeit als Text angezeigt
Aufnahme-Ankündigungen: Screenreader werden über assertive Live-Regionen benachrichtigt, wenn die Aufnahme startet und stoppt
Stummschaltoption: Die KI-Audioausgabe kann in den Einstellungen stummgeschaltet werden, wenn Sie eine reine Textinteraktion bevorzugen
Transkriptverlauf: Vollständige Gesprächsprotokolle werden gespeichert und sind in Ihren Reflexionen zugänglich

Bekannte Einschränkungen

Obwohl wir vollständige Barrierefreiheit anstreben, bestehen einige Einschränkungen:

Inhalte Dritter: Einige eingebettete Inhalte (Zahlungsformulare über Stripe) folgen ihren eigenen Barrierefreiheitsstandards
KI-generierte Bilder: KI-generierte Reflexionsillustrationen verfügen möglicherweise nicht über vollständig beschreibenden Alt-Text
Echtzeit-Sprache: Live-Sprachkonversationen erfordern Audiofähigkeit; Textalternativen sind stets verfügbar

Testmethoden

Wir testen die Barrierefreiheit mit:

Manuellen Tests der reinen Tastaturnavigation
Screenreader-Tests (VoiceOver unter macOS/iOS)
Automatisierten Tests mit dem ESLint-jsx-a11y-Plugin (über 20 zur Build-Zeit durchgesetzte Regeln)
axe-core-Barrierefreiheitsprüfung zur Laufzeit während der Entwicklung
Werkzeugen zur Farbkontrastanalyse
Barrierefreiheits-Audits mit Browser-Entwicklertools

Feedback & Kontakt

Wir freuen uns über Ihr Feedback zur Barrierefreiheit von Lioma. Wenn Sie auf Barrieren stoßen oder Verbesserungsvorschläge haben, kontaktieren Sie uns bitte:

E-Mail: info@lioma.eu
Antwortzeit: Wir bemühen uns, innerhalb von 5 Werktagen zu antworten

Bitte geben Sie bei Ihrer Kontaktaufnahme Folgendes an:

Die URL oder den Ort, an dem das Problem aufgetreten ist
Eine Beschreibung des Problems
Die von Ihnen verwendete Assistenztechnologie (falls zutreffend)
Ihre bevorzugte Kontaktmethode

Durchsetzung & Beschwerden

EU-Nutzer: Wenn Sie mit unserer Antwort nicht zufrieden sind, können Sie eine Beschwerde bei Ihrer nationalen Durchsetzungsstelle nach dem European Accessibility Act einreichen.

US-Nutzer: Wenn Sie der Ansicht sind, dass Lioma die Anforderungen an die Barrierefreiheit nicht erfüllt, können Sie eine Beschwerde beim U.S. Department of Justice einreichen oder andere nach dem Americans with Disabilities Act verfügbare Rechtsmittel verfolgen.

Technische Spezifikationen

Die Barrierefreiheit von Lioma stützt sich auf die folgenden Technologien:

HTML5
WAI-ARIA 1.2
CSS3
JavaScript (React)

Diese Technologien werden für die Konformität mit WCAG 2.1 Stufe AA vorausgesetzt.

Kontinuierliche Verbesserung

Wir verpflichten uns, die Barrierefreiheit kontinuierlich zu verbessern. Unsere Maßnahmen umfassen:

Regelmäßige Barrierefreiheits-Audits
Schulungen zur Barrierefreiheit für unser Entwicklungsteam
Einbindung der Barrierefreiheit in unseren Design- und Entwicklungsprozess
Beobachtung des Nutzerfeedbacks und umgehende Behebung von Problemen

Erklärung zur Barrierefreiheit