Ist euer Intranet für wirklich alle zugänglich?

Wirklich alle Mitarbeitenden erreichen. Klingt erst einmal ganz einfach. Jedoch beinhaltet “alle Mitarbeitenden” nicht nur alle Mitarbeitenden am Schreibtisch und außerhalb des Schreibtisches, sondern u.a. auch eure Mitarbeitenden mit körperlichen Einschränkungen. Mit Haiilo bieten wir Unternehmen eine digitale Heimat, die von ihren Nutzern geliebt wird. Daher ist es auch unsere Aufgabe, es für wirklich alle zugänglich zu machen.

Dieser Artikel beschreibt, wie Haiilo generell mit dem Thema Barrierefreiheit umgeht, wie Haiilo Fortschritt diesbezüglich sicherstellt und warum wir die WCAG-Richtlinien in Bezug auf Haiilo nicht immer gewährleisten können.

Barrierefreiheit im Allgemeinen

Gemäß der Web Content Accessibility Guidelines (WCAG) umfasst Accessibility bzw. Barrierefreiheit „a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. […] These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general”.

Eine Anwendung WCAG 2.1 AA-konform zu gestalten ist demnach eine Aufgabe, die nicht in einem Schritt erledigt werden kann, sondern in viele kleinere Schritte aufgeteilt werden muss. Der von uns gewählte Ansatz besteht darin, diese Aufgabe in einzelne Komponenten aufzuteilen, ohne das große Ganze aus dem Auge zu verlieren – beginnend mit den Features, die für jene Benutzer im Fokus stehen.

Qualitätskontrolle

Um sicherzustellen, dass alle neuen und aktualisierten Komponenten mit den WCAG-Standards übereinstimmen, nutzt das Team für die Qualitätssicherung und die Softwareentwicklung eine Checkliste, die auf den offiziellen W3 WCAG-Richtlinien basiert.

Alle neuen oder aktualisierten Code-Elemente, die für Benutzer sichtbar sind, werden anhand dieser Liste überprüft und abgelehnt, wenn sie nicht den Richtlinien entsprechen.

Checkliste Barrierefreiheit

Die genannte Liste enthält die folgenden Punkte.

Textliche Alternativen

• Für alle Bilder und Icons, die für das Verständnis relevant sind, gibt es eine geeignete, gleichwertige Textalternative.

Sprachausgabe

• Dekorative Bilder werden für Screenreader ausgeblendet: Bilder, die nur dekorativ oder überflüssig sind (z. B. Avatarbilder neben einem Benutzernamen), werden mit aria-hidden=“true“ versehen.
• Screenreader finden sinnvolle Inhalte auf Schaltflächen/Links: Formularschaltflächen und Links haben einen beschreibenden Wert und/oder Screenreader finden sinnvolle Inhalte zum Vorlesen.
• Formularsteuerelemente haben Bezeichnungen zugewiesen: Den Formularelementen sind Bezeichnungen zugeordnet. Wenn keine Beschriftung vorhanden ist, haben die Formularfelder eine ARIA-Beschriftung, so dass Screenreader den Zweck des Formularsteuerelements vorlesen können.

Tastatur-Navigation

• Intuitive Tastaturnavigation: Die Lese- und Navigationsreihenfolge ist logisch und intuitiv. Die Benutzer können den Fokus verstehen und verfolgen, wenn sie über die Tastatur/den Screenreader navigieren.
• Barrierefreiheit über die Tastatur: Alle Komponenten und Funktionen sind über die Tastatur und einen Screenreader zugänglich (außer explizit ausgeblendete Komponenten). Interaktive Elemente sind über die TAB-Taste auch ohne Tastatur zugänglich.
• Aktive HTML-Elemente sind als solche deutlich: Es ist visuell erkennbar, welches Element den Tastaturfokus hat, sobald der Benutzer die Navigation mit der Tastatur/dem Screenreader beginnt.

Kontraste

• Ein Mindestkontrast von 3:1 sollte zwischen Vorder- und Hintergrund für großen Text und Icons und 4,5:1 für kleinen und normalen Text eingehalten werden.
• Deaktivierte Elemente sollten den Mindestkontrast beibehalten, wenn sie Informationen vermitteln. Sowohl der Kontrast zum Hintergrund als auch der Kontrast zu ähnlich dargestellten, nicht deaktivierten Elementen sollte ausreichend sein (3,0:1).

Formularfelder und Fehlermeldungen

• Formularsteuerelemente sind mit Bezeichnungen versehen: Beschriftungen sind mit Formularelementen verbunden. Wenn keine Beschriftung vorhanden ist, sind die Formularfelder mit einer ARIA-Beschriftung versehen, so dass Screenreader den Zweck des Formularsteuerelements auslesen können.
• Der Benutzer wird durch die Fehlerbehandlung geführt: Der Benutzer wird nach dem Absenden des Formulars intuitiv durch die Fehlerbehandlung geführt. Fehlermeldungen sind leicht zugänglich und der Benutzer kann Fehler leicht beheben und das Formular erneut senden.

WCAG-Tests und Regression

Um sicherzustellen, dass bereits optimierte Komponenten zugänglich bleiben und um den Gesamtfortschritt bei der Erreichung des Ziels, WCAG 2.1 AA-konform zu sein, zu dokumentieren, haben wir 2 Maßnahmen eingeführt.

• Regelmäßige WCAG-Tests durch eine dritte Partei: Mindestens jedes halbe Jahr bestellen wir einen BITV/WCAG-Test, der von BSVH durchgeführt wird. Die Ergebnisse geben uns einen Hinweis auf den Fortschritt und zeigen Lücken in der Barrierefreiheit von Haiilo auf. Darüber hinaus führen Kunden ihre eigenen internen Tests durch und senden uns ihre Ergebnisse zu.
• Verstöße werden als Bugs behandelt: Jeder aufgedeckte Verstoß gegen die WCAG-Richtlinie einer bereits optimierten Komponente wird als Fehler behandelt und daher innerhalb der geltenden SLA-Lösungszeiten behoben. Die Lösungszeiten variieren je nach Schweregrad und Servicelevel des Kunden.

Teilweise Einhaltung

Wie bereits erwähnt, sind wir generell an einer weitgehenden Übereinstimmung mit dem WCAG-Standard interessiert und arbeiten darauf hin. Allerdings ist zu bedenken, dass Haiilo sehr anpassungsfähig ist und große Mengen an benutzergenerierten Daten enthält. Vor allem wegen der von den Benutzern erstellten Inhalte kann eine vollständige Übereinstimmung mit dem Standard nicht gewährleistet werden – es wird also nur teilweise konform sein. Nichtsdestotrotz ist es unser Ziel, so nah wie möglich heranzukommen, damit Benutzer mit Beeinträchtigungen Haiilo nutzen können.

Farbkriterien

Haiilo ist sehr anpassungsfähig und kann an die Bedürfnisse des Unternehmens angepasst werden. Eine Sache, die konfiguriert und verändert werden kann, ist die Farbe und das Theme. Standardmäßig stellen wir ein Theme für Haiilo zur Verfügung, das alle Kriterien für Farbe und Kontrast erfüllt und insbesondere konsistente Hover- und Aktivzustände für Steuerelemente bietet.

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

Inhaltliche Kriterien

Hailo ermöglicht es Redakteuren und Benutzern, Inhalte zu erstellen – das können Texte, Bilder, Videos oder eine Kombination davon sein. In diesem Fall ist es Aufgabe des Benutzers/Redakteurs, die Zugänglichkeitsstandards zu gewährleisten. Wo es möglich und technisch machbar ist, werden wir versuchen, den Benutzer dabei zu unterstützen. Zum Beispiel erlauben wir Redakteuren nicht, H1-Elemente im Rich-Text-Editor zu verwenden, da es nur ein H1-Element pro Seite geben soll, das für die Überschrift der Seite reserviert ist.

Für Bilder arbeiten wir daran, wo immer möglich einen alternativen Text anzubieten. Dies funktioniert bereits bei den meisten Bildern, die von den Editoren bereitgestellt werden, fehlt aber noch bei einigen Widgets.

Was die Videoinhalte betrifft, so dient Haiilo lediglich als Plattform für die Verbreitung und Anzeige der Videoinhalte. Die Bereitstellung von barrierefreien Videos (z.B. durch die Anzeige von Untertiteln oder eines Gebärdensprachdolmetschers) ist Aufgabe der zugrunde liegenden Videoplattform oder muss dem Videoinhalt vorher hinzugefügt werden.

Fazit

Haiilo arbeitet kontinuierlich an der Verbesserung der Barrierefreiheit der Anwendung und nimmt dieses Thema sehr ernst. Wir haben einen Prozess implementiert, der sicherstellt, dass neue und aktualisierte Komponenten anhand der WCAG-Richtlinien getestet werden. Außerdem werden bereits aktualisierte Komponenten gewartet und regelmäßig intern und extern von Dritten auf die Richtlinien hin überprüft.

Ihr seid trotz des oben genannten Maßnahmenkatalogs über nicht-WCAG-konforme Teile schon aktualisierter Komponenten gestolpert? Wir freuen uns über euer Feedback. Lasst es uns gerne via Bug-Ticket wissen.