Philosophische Fakultät – Blog Digitale Lehre und Forschung

Trends aus E-Learning, eScience und Technologie

E-Accessibility: Web-Inhalte barrierefrei gestalten

Beim barrierefreien Zugang von Menschen mit Behinderung zu Gebäuden oder Transportmitteln hat sich einiges getan, seit im Januar 2004 das Bundesgesetz über die Beseitigung von Benachteiligungen von Menschen mit Behinderungen (Behindertengleichstellungsgesetz, BehiG) in der Schweiz in Kraft getreten ist – sowohl bei der Anpassung von Infrastrukturen als auch im Bewusstsein der Öffentlichkeit.1

Weit weniger Beachtung erhielt dagegen ein anderer, in unserer modernen Welt aber genauso wichtiger Lebensbereich, nämlich die Zugänglichkeit von digitalen Inhalten. Neben dem klassischen Webauftritt mit Webseiten zählen dazu zum Beispiel Mobile Apps, PDF- und Word-Dateien, Formulare oder – gerade im universitären Kontext ein wichtiges Thema – E-Learning. Häufig fehlt noch das Bewusstsein für die Hürden, mit denen Menschen mit Behinderungen konfrontiert werden, wenn sie auf digitale Inhalte zugreifen möchten, um sich zu informieren oder mit anderen zu interagieren. Die Schweizer Accessibility-Studie 2016 stellt fest, dass „sich weiterhin ein sehr ernüchterndes Bild hinsichtlich der Zugänglichkeit von Schweizer Web-Angeboten und -Dienstleistungen“ zeige.2Die E-Accessibility, so lautet das Stichwort, ist bei uns noch lange nicht angekommen.

Dieser Beitrag versucht für dieses wichtige Thema, das bei der Erstellung von digitalen Inhalten heute noch leicht vergessen geht, zu sensibilisieren. Obwohl das Feld der E-Accessibility sehr komplex und anspruchsvoll werden kann, lassen sich viele Massnahmen bereits mit wenig Aufwand umsetzen und digitale Information und Kommunikation für alle besser zugänglich machen. Dies soll nachfolgend am Beispiel von zwei der wichtigsten digitalen Informations- und Kommunikationsmedien, nämlich von Webseiten und PDF-Dokumenten, illustriert werden.

 

Technologische Voraussetzungen

Bevor man sich näher mit den Problemen der E-Accessibility, also der barrierefreien Zugänglichkeit von Informations- und Kommunikationstechnologien für Menschen mit Behinderung und ältere Menschen3, auseinandersetzt, lohnt es sich, sich kurz mit der technischen Seite des Themas zu beschäftigen.

Menschen mit Behinderung präsentieren sich digitale Inhalte ganz anders als dem Gros der Internetnutzerinnen und -nutzer. In zunehmendem Masse lebt die digitale Welt von grafischen und multimedialen Elementen, Animationen, Audio- und Videoaufnahmen oder zoombaren Karten – alles Inhalte, die von Menschen zum Beispiel mit einer Seh- oder Hörbehinderung nur mit Mühe genutzt werden können.

Braille-Display

Braille-Display (von Sebastien.delorme, via Wikimedia Commons)

Man muss sich bewusst machen, wie die Betroffenen auf diese Inhalte zugreifen. Menschen mit Sehbehinderung benutzen einen Screenreader, ein Vorleseprogramm, das alle Inhalte einer Webseite oder eines PDF-Dokuments in Sprache umwandelt und in linearisierter Form vorliest oder in Computerbraille ausgibt. Dazu bewegt es sich von Seitenelement zu Seitenelement, zum Beispiel von Überschrift zu Überschrift. Menschen mit motorischer Behinderung sind darauf angewiesen, dass die gesamte Funktionalität eines digitalen Dokuments nicht nur mit der Maus, sondern per Tastatur oder einem alternativen Eingabegerät (wie speziellen Tastaturen oder Steuerung des Cursors mit Mund, Kopf oder Augen) bedient werden kann. Menschen mit kognitiven Behinderungen profitieren von klar strukturierten Webseiten, die mit der sogenannten leichten Sprache arbeiten.4

Demonstration eines Screenreader:

 

Digitale Inhalte barrierearm gestalten

Inzwischen gibt es international anerkannte Standards, die die barrierearme Zugänglichkeit von digitalen Inhalten regeln oder zumindest Empfehlungen dafür aussprechen. Die wichtigsten sind die W3C Web Content Accessibility Guidelines (WCAG) 2.05 für Webinhalte und PDF/UA (ISO 14289-1:2014 ) für PDF-Dateien.

Beispiele für WCAG:

  • 1.1: Text-Alternativen für Nicht-Text-Inhalte bereitstellen.
    Bsp.: Alternativtexte für Bilder
  • 1.2: Alternativen für zeitbasierte Medien bereitstellen.
    Bsp.: Audiodeskription, Untertitel
  • 2.1 Sämtliche Funktionalität ist per Tastatur zugänglich.
  • 3.1 Textinhalte müssen lesbar und verständlich sein.
    Bsp.: leichte Sprache

Eines der grössten Probleme im Zusammenhang mit E-Accessibility ist die Bedienung von grafischen Benutzeroberflächen, wie sie bei digitalen Inhalten sehr häufig vorkommen. Technologische Hilfsmittel wie Screenreader oder alternative Eingabegeräte können beispielsweise Abbildungen, komplexe Tabellen oder dynamische Widgets nicht oder nur unzureichend beschreiben und ansteuern. Um diese Problematik zu lösen, erstellen Anwendungen einen sogenannten Accessibility Tree6, auf den technologische Hilfsmittel zugreifen können.

Accessibility Trees stellen grafische Informationen auf einer semantischen Ebene dar. Sie schlüsseln die Elemente und Unterelemente etwa einer Webseite auf und setzen sie in linearer Form zueinander in Beziehung. Die so entstehende Baumstruktur erlaubt es alternativen Ausgabegeräten, die einzelnen Bestandteile einer Webseite oder eines PDF-Dokuments zu identifizieren, in der richtigen Reihenfolge auszugeben und zu bedienen. Mithilfe eines Accessibility Tree erstellt zum Beispiel ein Screenreader die linearisierte Version einer Webseite, die er dann vorliest.

Accessibility Tree:

Accessibility Tree des Blogs der DLF

Ausschnitt aus dem (suboptimalen) Accessibility Tree des DLF-Blogs.

 

Webseiten barrierearm gestalten

Die WCAG 2.0 empfehlen Massnahmen in vier Kernbereichen. Digitale Inhalte müssen:

1. und 2. wahrnehmbar („perceivable“) und bedienbar („operable“) sein: Die NutzerInnen müssen in der Lage sein, Inhalte und Benutzeroberflächen überhaupt wahrzunehmen und zu bedienen, zum Beispiel über einen Screenreader.

3.  verständlich („understandable“) sein: Die angebotenen Informationen müssen so dargeboten werden, dass sie verstanden werden, zum Beispiel unter Verwendung von Leichter Sprache und übersichtlicher Struktur.

4. robust („robust“) sein: Webseiten müssen mit möglichst allen aktuellen und kommenden Endbenutzertechnologien verwertet werden können.

Diese Vorgaben sowie eine detaillierte Aufstellung zweckmässiger Massnahmen, um diese umzusetzen, finden sich in den WCAG 2.0. Doch Bereits einige wenige Anpassungen können den Bedürfnissen von Menschen mit Behinderung stark entgegenkommen:7

  • Die Inhalte einer Webseite müssen semantisch, also auf Ebene der HTML-Tags, so aufbereitet sein, dass alle Informationen von einem Screenreader oder einem anderen technischen Hilfsmittel problemlos erfasst und verständlich dargestellt werden können. Folgende Beispiele mögen zur Veranschaulichung genügen: In den Metainformationen einer Webseite muss die verwendete Sprache vermerkt sein. Andernfalls kann es sein, dass der Screenreader eine Webseite in deutscher Sprache als Englisch interpretiert und entsprechend vorliest – auf Kosten der Verständlichkeit, wie dieses Video deutlich macht. Ein anderes Beispiel sind Abbildungen, die ein Screenreader natürlich nicht beschreiben kann. Vielmehr ist er auf einen passenden Alternativtext (alt-Attribut) angewiesen, den er stattdessen vorlesen kann.
  • Da sich Screenreader an Überschriften orientieren, sollten Überschriften auch als solche ausgezeichnet und die Überschriftenhierarchie eingehalten werden. Wenn zum Beispiel ein Inhaltsabschnitt, der von der Logik her mit einer Überschrift 1 versehen werden müsste, mit einer Überschrift 4 betitelt wird, bloss weil deren kleinere Schriftgrösse besser ins Layout passt, ist das für einen durchschnittlichen Internetuser kein Problem, weil er oder sie das grafische Gesamtbild erkennt und richtig deuten kann. Für die Interpretation mit einem Screenreader aber kann diese inhaltlich-logische Fehlzuordnung sehr verwirrend sein.
  • Für HTML5 wurden zudem die sogenannten ARIA-Attribute eingeführt. ARIA steht für Accessible Rich Internet Applications.8 Es handelt sich um eine semantische Erweiterung von HTML, die das Layout einer Webseite nicht verändert, aber die Zugänglichkeit von Webinhalten für technische Hilfsmittel  verbessert. Ermöglicht wird dies durch (grafisch nicht angezeigte) Zusatzinformationen, die in herkömmlichem HTML nicht vorgesehen sind, zum Beispiel Angaben zu Sildern, Buttons, Java Script-Widgets, Statusinformationen von Eingabefeldern oder Beschreibungen von dynamischen Seitenelementen (wie die Darstellung eines Aktienkurses). ARIA ermöglicht also im Wesentlichen eine Erweiterung des eingangs erwähnten Accessibility Tree um Attribute, die HTML von Haus auf nicht bietet.
  • Die Lesereihenfolge von Seitenelementen sollte logisch festgelegt sein.
  • Seitenelemente sollten per Tastatur angesteuert werden können.
  • Komplizierte und wenig aussagekräftige Datei- und Linknamen (wie 1736489376gross.jpg) sollten vermieden werden. Da diese Bezeichnungen von Screenreadern genau so vorgelesen werden, wird die Benutzung der Seite deutlich erschwert. Besser eignen sich kurze, sprechende Benennungen.
  • Videos sollen stets untertitelt werden.
  • Die Farbgebung der Seite sollte über ausreichende Kontraste verfügen – hellblaue Schrift auf weissem Grund kann für Menschen mit Behinderung nicht mehr erkennbar sein.
  • Wenn die Zielgruppe es erfordert bzw. erlaubt, muss die Sprachkomplexität angepasst werden, z. B. unter Verwendung von leichter Sprache.

Web Accessibility for Designers infographic with link to text version at WebAIM.orgHinweise für die Gestaltung von Webseiten (Quelle: WebAIM – Web Accessibility für Designer, © WebAIM).

Neben diesen noch einfach zu berücksichtigenden Empfehlungen, kann die barrierearme Gestaltung von Webseiten sehr komplex werden, besonders dann, wenn die Accessibility-Thematik beim Design nicht von Anfang an berücksichtigt wurde. Eine gute und detaillierte Einführung ins barrierearme Webdesign findet sich auf der Webseite Barrierefreies Webdesign.

Vergleich der Zugänglichkeit einer Webseite vor und nach der Neugestaltung:

 

PDF- und Word-Dateien barrierearm gestalten

Der internationale Standard für barrierefreie PDF-Dokumente ist ISO 14289-1:2014 oder etwas griffiger PDF/UA (für PDF Universal Access). Die Richtlinien für PDF/UA legen fest, wie ein valides, barrierefreies PDF-Dokument auszusehen hat, wie Texte, Grafiken, Bilder oder Formularfelder gestaltet werden müssen, um für Menschen mit Behinderung mit ihren technischen Hilfsmitteln einfach zugänglich zu sein.9

Das Prinzip, das dahintersteht, gleicht demjenigen für barrierearme Webseiten. Dort sorgen geeignete HTML-Tags für die Darstellbarkeit der Informationen etwa durch Screenreader. Auch PDF/UA-Dateien liegt eine solche Tag-Ebene zugrunde, die die Struktur des Dokuments für alternative Endgeräte fassbar macht. Auch in PDF’s sollten Überschriften als solche gekennzeichnet, alle Aktionen mit der Tastatur ausführbar, die Sprache des Dokuments korrekt eingestellt, grafische Inhalte mit Alternativtexten versehen oder die Lesereihenfolge logisch eingerichtet sein. Damit ein PDF aber überhaupt sinnvoll per Screenreader dargestellt werden kann, muss es auf einem durchsuchbaren Text und nicht auf einem eingescannten Bild basieren. Müssen trotzdem Scans verwendet werden, sollten diese eine hohe Auflösung (300 oder besser 600 dpi) aufweisen und, wenn möglich, mithilfe von OCR durchsuchbar gemacht werden.

Viele Erfordernisse eines barrierearmen PDF’s können bereits bei der Erstellung des Dokuments in Textverarbeitungsprogrammen wie Word berücksichtigt werden, indem zum Beispiel Formate konsequent angewendet (Definition von Überschriften!) und für die Erstellung von Links, Listen, Verzeichnissen oder Alternativtexten für Grafikelemente die jeweiligen Werkzeuge des verwendeten Textverarbeitungsprogramms genutzt werden. Wenn das Dokument dann als PDF exportiert wird, werden diese Einstellungen ebenfalls ins PDF übertragen. Dies funktioniert aber nur, wenn das Dokument explizit exportiert und nicht über die „Als PDF drucken“-Funktion ausgegeben wird!

Gleichwohl ist in der Regel noch eine Nachbearbeitung zum Beispiel mit Acrobat Professional nötig, da die gängigen Textverarbeitungsprogramme wie Microsoft Word oder Adobe InDesign bei der Erstellung von barrierearmen PDF’s (noch) Schwächen haben.10 Die Nachbereitung eines PDF-Dokuments ist ein relativ aufwändiger Prozess, weshalb an dieser Stelle nicht ausführlich darauf eingegangen werden kann. Im Netz und insbesondere auf Youtube finden sich inzwischen aber unzählige Anleitungen und Hinweise, wie mit den gängigen Textverarbeitungsprogrammen barrierearme Dokumente erstellt werden können. An dieser Stelle mögen zwei Verweise genügen, einmal auf die Hilfeseite von Adobe und einmal auf ein zwar älteres, aber hinsichtlich der Grundidee nach wie vor lehrreiches Video auf Youtube.

Einführung in die Nachbearbeitung von PDF-Dateien:

Einführung in die Erstellung barrierefreier Word- (und PDF-)Dokumente:

 

E-Accessibility testen: Tools und Links

Allgemeine Informationen

Fachstelle Studium und Behinderung UZH

W3C Web Content Accessibility Guidelines (WCAG)

W3C Web Accessibility Initiative (WAI)

WebAIMWeb Accessibility In Mind – Gemeinnützige Organisation, angesiedelt am Center for Persons with Disabilities der Utah State University.

Leitfaden EDI „Barrierefreie digitale Kommunikation“

Stiftung „Zugang für alle“

Projekt „Barrierefreiheit im Internet“

Barrierefreies Webdesign: Detaillierte Tipps zur barrierearmen Gestaltung von digitalen Inhalten.

E-Accessibility, EDI: E-Accessibility-Portal des Eidgenössischen Büros für die Gleichstellung von Menschen mit Behinderungen.

Tools und Hilfsmittel

W3C WAI – Evaluating Web Accessibility: Allgemeine Informationen über die Prüfung der Web Accessibility mit umfangreicher Linkliste.

WebAIM – Resources: Ressourcen- und Toolliste von WebAIM.

HTML5 Accessibility: Testet HTML5-Features hinsichtlich ihrer Web Accessibility.

Projekt WAVE: Überprüft Webseiten auf ihre Web Accessibility und macht Anpassungsvorschläge.

WebAIM Color Contrast Checker: Überprüft die Farbkontraste von Webseiten.

WebAIM – WCAG 2.0 Checkliste: Checkliste für die Erstellung WCAG 2.0-konformer Web-Inhalten.

WebAIM – Web Accessibility für Designer: Checkliste für das Design von Web-Inhalten.

Teilen:

  1. Vgl. EDI: Evaluation des Behindertengleichstellungsgesetzes.
  2. Schweizer Accessibility Studie 2016. Bestandesaufnahme der Zugänglichkeit bedeutender Schweizer Internet-Angebote, hg. von der Schweizerischen Stiftung zur behindertengerechten Technologienutzung „Zugang für alle“, 2016, S. 135  (Zugriff: 10.4.2018).
  3. Für die Definition vgl. Aktionsplan E-Accessibility 2015-2017, hg. v. Generalsekretariat EDI, 2014, S. 5, Anm. 1 (Zugriff: 12.4.2018).
  4. Weitere Informationen und Hilfsmittel zur leichten Sprache: Eidgenössisches Departement des InnerenNetzwerk Leichte Sprache, Hurraki – Wörterbuch für leichte Sprache.
  5. Die WCAG 2.0 sind auch ISO-Standard (ISO/IEC 40500:2012). Die WCAG 2.1 sind zur Zeit in Entwicklung und sollen noch 2018 veröffentlicht werden.
  6. Vgl. W3C Core Accessibility API Mappings 1.1, Google Developers: The Accessibility Tree.
  7. Eine detaillierte Einführung findet sich auf der sehr informativen Seite Barrierefreies Webdesign, vgl. auch die WAI-ARIA Authoring Practices sowie Using ARIA.
  8. Ausführlich zu ARIA die Seite Barrierefreies Webdesign. Vgl. die WAI-ARIA Authoring Practices sowie Using ARIA.
  9. Eine gute Einführung ins Thema findet sich auf der Webseite Barrierefreies Webdesign.
  10. Schweizer Accessibility Studie 2016, S. 34-36; allgemeine Informationen finden sich bei der Stiftung Access for all. Unter Windows steht das Word-Plugin „axesPDF“ zur Verfügung, das eine Nachbearbeitung unnötig macht.

Abgelegt unter: E-Accessibility
Tags:


Keine Kommentare vorhanden

  • Es gibt noch keine Kommentare.

Kommentar schreiben

*