Barrierefreiheit in Haiilo

Auf den ersten Blick scheint es einfach zu sein, alle Mitarbeiter zu erreichen. Allerdings umfasst "alle Mitarbeiter" nicht nur alle Schreibtisch- und Nicht-Schreibtisch-Mitarbeiter, sondern auch deine Mitarbeiter mit körperlichen Behinderungen.

In diesem Artikel beschreiben wir, wie wir bei Haiilo generell mit dem Thema Barrierefreiheit umgehen, wie wir Fortschritte in dieser Hinsicht sicherstellen und warum wir nur eine teilweise Einhaltung der offiziellen Web Content Accessibility Guidelines (WCAG) in Bezug auf deine Plattform gewährleisten können.

Allgemeine Barrierefreiheit

Laut den Web Content Accessibility Guidelines (WCAG) umfasst Barrierefreiheit "eine Vielzahl von Behinderungen, einschließlich visueller, auditiver, physischer, sprachlicher, kognitiver, sprachlicher, Lern- und neurologischer Behinderungen. [...] Diese Richtlinien machen Webinhalte auch für ältere Menschen mit sich ändernden Fähigkeiten aufgrund des Alterns zugänglicher und verbessern oft die Benutzerfreundlichkeit für alle Benutzer".

Die Umsetzung der WCAG 2.1 AA-Konformität für eine Anwendung ist eine Aufgabe, die nicht in einem Schritt erledigt werden kann; sie muss in kleinere Schritte aufgeteilt werden. Unser Ansatz besteht darin, diese Aufgabe in einzelne Komponenten aufzuteilen, ohne das große Ganze aus den Augen zu verlieren - beginnend mit den Funktionen, die für diese Nutzer im Fokus stehen.

Qualitätskontrolle Checkliste

Um sicherzustellen, dass alle neuen und aktualisierten Komponenten den WCAG-Standards entsprechen, verwenden unser Qualitätssicherungsteam und unser Softwareentwicklungsteam eine Checkliste, die auf den offiziellen W3 WCAG-Richtlinien basiert. Alle neuen oder aktualisierten Code-Elemente, die für den Benutzer sichtbar sind, werden anhand dieser Liste überprüft und abgelehnt, wenn sie nicht konform sind.

Die genannte Liste enthält folgende Punkte:

Textuelle Alternativen

  • Alle relevanten Bilder und Symbole haben eine angemessene, äquivalente textuelle Alternative.

Voice Over

  • Dekorative Bilder sind für Bildschirmleser ausgeblendet: Bilder, die nur dekorativ sind oder redundant (z. B. Avatar-Bilder neben einem Benutzernamen) haben ein area-hidden="true" gesetzt.
  • Bildschirmleser finden sinnvollen Inhalt auf Schaltflächen und Links: Formularschaltflächen und Links haben einen beschreibenden Wert, und Bildschirmleser finden sinnvollen Inhalt zum Vorlesen.
  • Formularelemente haben zugeordnete Beschriftungen: Beschriftungen sind mit Formularelementen verknüpft. Wenn keine Beschriftung verfügbar ist, haben die Formularfelder ein ARIA-Label, damit Bildschirmleser den Zweck des Formularelements vorlesen können.

Tastaturnavigation

  • Intuitive Tastaturnavigation: Die Lese- und Navigationsreihenfolge ist logisch und intuitiv. Benutzer können dem Fokus beim Navigieren über die Tastatur/Bildschirmleser folgen und verstehen.
  • Über die Tastatur zugänglich: Jede Komponente und Funktionalität ist über die Tastatur und einen Bildschirmleser zugänglich (mit Ausnahme von explizit ausgeblendeten Komponenten). Interaktive Elemente sind auch ohne Tastatur über die TAB-Taste zugänglich.
  • Aktive HTML-Elemente sind erkennbar: Es ist visuell wahrnehmbar, welches Element den Tastaturfokus hat, sobald der Benutzer mit der Tastatur/Bildschirmleser navigiert.

Kontraste

  • Ein Mindestkontrast von 3:1 sollte zwischen Vordergrund und Hintergrund für große Texte und Symbole und 4,5:1 für kleine und normale Texte eingehalten werden.
  • Deaktivierte Elemente sollten den Mindestkontrast beibehalten, wenn sie Informationen vermitteln. Der Kontrast zum Hintergrund und der Kontrast zu nicht deaktivierten Elementen mit demselben Aussehen sollten ausreichend sein (3,0:1).

Formularfelder und Fehlermeldungen

  • Formularelementen sind Labels zugewiesen: Labels sind mit Formularelementen verknüpft. Wenn kein Label verfügbar ist, haben die Formularfelder ein ARIA-Label, damit Bildschirmleser den Zweck des Formularelements vorlesen können.
  • Der Nutzer wird bei der Fehlerbehandlung unterstützt: Der Nutzer wird nach dem Absenden des Formulars intuitiv durch Fehlermeldungen geführt. Fehlermeldungen sind leicht zugänglich, und der Nutzer kann Fehler leicht beheben und das Formular erneut absenden.

WCAG-Tests und Regression

Um sicherzustellen, dass bereits optimierte Komponenten zugänglich bleiben und den Gesamtfortschritt bei der Erreichung des Ziels der WCAG 2.1 AA-Konformität dokumentieren, haben wir diese beiden Maßnahmen.

  • Regelmäßige WCAG-Tests von einem Dritten: Mindestens alle sechs Monate bestellen wir einen BITV/WCAG-Test, der vom BSVH durchgeführt wird. Die Ergebnisse geben uns einen Hinweis auf den Fortschritt und zeigen Lücken in der Zugänglichkeit von Haiilo auf. Kunden führen auch ihre eigenen internen Tests durch und senden uns ihre Ergebnisse.
  • Verstöße werden als Fehler behandelt: Jeder aufgedeckte Verstoß gegen die WCAG-Richtlinie einer bereits optimierten Komponente wird als Fehler behandelt und innerhalb der SLA-Lösungszeiten behoben. Die Lösungszeiten variieren je nach Schweregrad und Servicelevel des Kunden.

Partielle Einhaltung

Wie bereits erwähnt, sind wir grundsätzlich daran interessiert und arbeiten daran, eine umfassende Konformität mit dem WCAG-Standard zu erreichen. Es ist jedoch zu beachten, dass Haiilo stark anpassbar ist und große Mengen an nutzergenerierten Daten enthält. Aufgrund des erstellten Inhalts kann keine vollständige Konformität garantiert werden - daher wird sie teilweise konform sein. Dennoch streben wir an, so nah wie möglich an die Erfüllung zu kommen, damit Nutzer mit Behinderungen Haiilo nutzen können.

Farbkriterien

Haiilo ist stark anpassbar und kann an die Bedürfnisse eines Unternehmens angepasst werden. Eine Sache, die konfiguriert und geändert werden kann, ist Farbe und Design. Standardmäßig bieten wir ein Theme für Haiilo an, das alle Kriterien für Farbe und Kontrast erfüllt - insbesondere durch konsistente Hover- und Aktivzustände für Steuerelemente.

Sobald jedoch ein Unternehmen das Design ändert, um es an die Corporate Identity anzupassen, liegt es in der Verantwortung des Unternehmens, Farben und Farbschemata gemäß den WCAG-Richtlinien anzupassen.

Inhaltskriterien

Haiilo ermöglicht es Redakteuren und Nutzern, Inhalte zu generieren - Texte, Bilder, Videos oder eine Kombination. In diesem Fall liegt es in der Verantwortung des Nutzers/Redakteurs, Zugänglichkeitsstandards bereitzustellen. Wir werden den Nutzer bei diesem Thema unterstützen, soweit dies möglich und technisch machbar ist. Zum Beispiel erlauben wir Redakteuren nicht, H1-Elemente im Rich-Text-Editor zu verwenden, da pro Seite nur ein H1-Element vorgesehen ist, das für die Überschrift der Seite reserviert ist.

Bei Bildern bieten wir eine Alternative-Text-Option an, soweit dies möglich ist. Dies funktioniert bereits für die meisten von Redakteuren bereitgestellten Bilder, fehlt jedoch noch in einigen Widgets.

In Bezug auf Videoinhalte fungiert Haiilo ausschließlich als Plattform zur Verteilung und Anzeige von Videoinhalten. Die Bereitstellung zugänglicher Videos (z. B. durch Untertitel oder einen Gebärdensprachdolmetscher) obliegt der zugrunde liegenden Videoplattform oder muss vorab zum Videoinhalt hinzugefügt werden.

Fazit

Haiilo verbessert kontinuierlich die Zugänglichkeit der Anwendung und nimmt dieses Thema sehr ernst. Mit jeder neuen Version wird es in dieser Hinsicht Verbesserungen geben. Wir haben einen Prozess etabliert, der sicherstellt, dass unsere Komponenten gemäß den WCAG-Richtlinien getestet werden. Unsere Komponenten werden intern und von Dritten regelmäßig auf die Einhaltung der Richtlinien überprüft und gewartet.

Trotz der oben genannten Maßnahmen freuen wir uns über Dein Feedback, falls Du auf einen nicht den WCAG-Richtlinien entsprechenden Teil einer Komponente stößt. Bitte kontaktiere unseren Service Desk für Unterstützung.

War dieser Beitrag hilfreich?

0 von 0 fanden dies hilfreich