Digitale Teilhabe und Zugänglichkeit

Gerade auch in unserem Projekt setzen wir uns mit Teilhabe und Zugänglichkeit auseinander. Und das nicht nur über Ländergrenzen hinweg, sondern auch bezüglich von Barrieren, die aufgrund von Alter, Be_hinderungen, technischen Mitteln und Sprache entstehen können. Ein wichtiger Schritt für uns ist das Testen unserer Websites auf Barrieren. Im Folgenden Beitrag geben wir einen kleinen Einblick in die verwendeten Tools und unsere momentanen Ergebnisse.

WHY IT MATTERS

Digitale Teilhabe und Zugänglichkeit sind ein wichtiges Thema für jede*n, der*die Inhalte im Internet erstellt oder mit digitalen Tools arbeitet. Aktion Mensch schreibt dazu: “Barrierefreies Internet ist in einer Gesellschaft, die in rasantem Tempo immer älter und vielfältiger wird, die wichtigste Grundlage, um erfolgreich zu kommunizieren.”

Dabei geht es auch um soziale Verantwortung und die Frage, wie ein gleichberechtigter und barrierearmer Zugang für alle, fernab von Herkunft, Sprache oder der Technik, die verwendet wird, möglich gemacht werden kann. Aktion Mensch benennt eine Website als barrierefrei, wenn “(…) sich Einschränkungen beim Sehen, Hören, Bewegen oder beim Verarbeiten von Informationen nicht negativ darauf auswirken, wie wir die Website nutzen.”

Beispiele für Barrieren sind unter Anderem Formularfelder dich sich nur gering vom Hintergrund abheben, Videos die keine Untertitel enthalten oder fehlende Alternativtexte für Bilder oder Formulare.

HOW TO: TESTEN

Es gibt verschiedene Online-Tools mit denen die Barrierearmut von Websites getestet werden kann. Wir haben uns mit folgenden drei näher beschäftigt: WAVE, Accessibility Insights for the web (Chrome-Erweiterung) und Tota11y.

Alle drei Tools sind einfach zu benutzen. WAVE erfordert lediglich das Kopieren und Einfügen einer URL, ohne dass die Software installiert werden muss, während Accessibility Insights for the Web und Tota11y ein Plug-in oder eine Erweiterung erfordern, die im Webbrowser installiert werden muss. Es gibt jedoch auch eine Desktop-Version, die heruntergeladen werden kann. In allen drei Fällen erscheint eine Liste der Fehler mit einigen Erklärungen in Verbindung mit dem HTML-Code, sodass es einfach ist, sie im Code zu finden.

Einfache Erklärungen zur Installation oder Anwendung der Tools findet man zusätzlich auf Youtube:

Kurzes Erklär-Video zur Einführung von Accessibility Insights für Windows.

Weitere Unterschiede sind: In WAVE und bei Tota11y wird ein Panel auf derselben Webseite angezeigt. Die Erklärung ist jedoch sehr kurz und bietet keine Vorschläge zur Behebung des Problems. In Insights hingegen wird der Test in einem zweiten Fenster durchgeführt. Dies kann zwei Monitore erfordern, um die Website und die Ergebnisse zu vergleichen, bietet dadurch aber mehr Informationen und Verbesserungsvorschläge. Darüber hinaus ist es in Insights möglich, die Ergebnisse zu exportieren und einen manuellen Navigationstest durchzuführen (Tabstopps). Festgehalten werden muss jedoch: Bei keinem der Tools ist es möglich, sich eine Liste mit allen Fehlern und Verbesserungsvorschlägen herunterzuladen.

DIE UMSETZUNG IM PROJEKT

Die Zugänglichkeit und Barrierearmut der Webauftritte des Projekts haben wir mit mithilfe von WAVE und Accessibility Insights for the web (Chrome-Erweiterung) getestet. Getestet wurde u. a. auch dieser Hypotheses-Blog, worauf wir im Folgenden näher eingehen wollen. Die Hauptfehler, die beide Programme fanden, waren:

  • Kontrastfehler, d. h. fehlende farbliche oder andere graphische Kontraste bei Seitenelementen, die die Erkennbarkeit und Lesbarkeit einschränken.
  • Strukturfehler, insbesondere bezüglich der Textgliederung durch Überschriften und des Fehlens von Alternativtexten bei Videos und Bildern.

Kontrastfehler fanden sich u.a. bei Buttons oder Textfeldern, in denen sich Schrift- und Feldfarbe nicht genug voneinander oder dem Seitenhintergrund unterschieden (bspw. Weiß und Hellblau), was die Lesbarkeit der Schrift oder die Erkennbarkeit des Buttons einschränken kann. Zur Verbesserung könnten hier schwarze Rahmen um die Buttons oder kontrastreichere Schrift- und Hintergrundfarben eingesetzt werden.

Die Strukturfehler in der Textgliederung können sehr einfach behoben werden, da der WordPress Block Editor im Navigationsbereich “Text” die Möglichkeit bietet, verschiedene Überschriften zu verwenden, die hierarchisch geordnete Textebenen graphisch anzeigen. Hier ist nur wichtig, nachzuprüfen, ob für die verschiedenen Ebenen im Text – Titel, Untertitel, Überschrift etc. – auch die richtigen Überschriften verwendet werden.

Auch bezogen auf die fehlenden Alternativtexte bei den Videos und Bildern kann sehr gut mit dem WordPress Block Editor gearbeitet werden. So gibt es für Bilder die Möglichkeit, Texthinweise zu verfassen. Dazu steht beim WordPress Block Editor: “Hinweise können Untertitel, Beschriftungen, Kapitel oder Beschreibungen sein. Sie tragen dazu bei, deine Inhalte für eine größere Anzahl von Benutzern besser zugänglich zu machen.” Bei Videos kann eine kleine Beschriftung unter das Video angebracht werden, die in leichter Sprache kurz den Inhalt erklärt.

Kurzes Video das die vereinfachte Durchführung eines Tests mit Accessibility Insights zeigt.

Für uns bedeutet das nun die Überarbeitung unseres digitalen Auftritts in Hinblick auf barrierefreies Design. Wir beachten neben der Anpassung des Wegdesigns noch andere Schritte, die für eine barrierefreie Kommunikation wichtig sind. Folgende Liste, erarbeitet von unserem Kollegen Antonio Rojas Castro, dient uns dabei als Hilfestellung:

  1. Im ersten Schritt kann sich über die aktuellen rechtlichen Anforderungen und Richtlinien der eigenen Einrichtung und/oder von Partnereinrichtungen informiert werden. Wenn Teammitglieder noch nicht mit dem Konzept der Barrierearmut vertraut sind, kann ein*e Expert*in und/oder eine externe Beratung hinzugezogen werden.
  2. Im zweiten Schritt können schon vorab unter der Berücksichtung von barrierearmen Designs, Websiten erstellt werden die die wichtigsten technischen Aspekte berücksichtigen. Diese sind:
    • Erklärung der Sprache
    • Überschriften und Strukturelemente
    • Zugängliche Links
    • Alt-Text (Alternativtext) für Bilder
    • Farbkontrast
    • Zugänglichkeit von eBooks und PDFs
    • Soziale Medien (Mehr hier: https://barrierefreiposten.de/barrierefreiPosten.html)
  3. Wenn Sie für Ihr Projekt externe Dienste oder Anbieter in Anspruch nehmen, informieren Sie diese über Ihre Anforderungen an die Barrierefreiheit. Dazu lohnt es sich, die eigene Zugänglichkeitsrichtlinie (siehe Schritt 6) zu teilen.
  4. Testen der Website während der Entwicklungsphase und eventuell zu späteren Zeitpunkten:
    • Mit unterstützenden Technologien wie Narrator und VoiceOver.
    • Mit Bewertungstools wie WAVE und Accessibility Insights.
    • Mit be_hinderten Nutzer*innen in deren eigener Arbeitsumgebung.
  5. Manuelle Überprüfung von Code-Fehlern, Erstellung einer Roadmap mit einer Prioritätenliste und Zuweisung von Zeit und Ressourcen für die Fertigstellung.
  6. Verfassen einer Zugänglichkeitsrichtlinie, die auf der eigenen Website veröffentlicht wird. Zusätzlich dazu: Benennen einer Kontaktperson für Fragen bezüglich Barrierearmut und Zugang.

Empfehlenswerte Lektüren zum Thema Testen von Barrierearmut:

Empfohlende weiterführende Links zum Thema Testen von Barrierearmut:

julianahutai, „Digitale Teilhabe und Zugänglichkeit“ in: Proyecto Humboldt Digital (ProHD), 10/03/2023, URL: https://habanaberlin.hypotheses.org/?p=4204.


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
julianahutai (10. März 2023). Digitale Teilhabe und Zugänglichkeit. Proyecto Humboldt Digital (ProHD). Abgerufen am 21. Juli 2024 von https://doi.org/10.58079/peop


Suche in OpenEdition Search

Sie werden weitergeleitet zur OpenEdition Search