Entgegen der Meinungen einiger Autoren in Texten zu barrierefreiem Webdesign, dass der Aufwand, alle möglichen Barrieren zu kompensieren in keinem Verhältnis zu den damit verbundenen Vorteilen und Ergebnissen stünde, kann es nach heutiger Sicht nicht mehr bloß darum gehen, Webinhalte so zu gestalten, dass sie "von der Mehrzahl der Internetnutzer genutzt werden" können. Vielmehr geht es darum, Webinhalte in Zukunft so zu entwickeln, dass keine Barrieren mehr existieren. Erst dann kann das Web zu einem Ort frei von Barrieren werden.
Um dieses Ziel erreichen zu können, müssen Gestalter und Entwickler gemeinsam bestimmte Grundsätze und Vorgehensweisen verstehen und verinnerlichen, denn letztlich geht es darum, Informationen für alle Menschen wahrnehmbar, verständlich und bedienbar zu machen. Webinhalte barrierefrei zu entwicklen muss keinen Mehraufwand bedeuten, es muss aber daran gearbeitet werden, dass Barrierefreiheit selbstverständlich wird und grundsätzlich gegeben ist.
Die nachfolgend genannten Ansätze, Probleme und Lösungen beziehen sich auf die Bedienung von Webinhalten im Frontund Backend mit einem Screenreader. Codebeispiele sind zu Teilen reduziert und einzelne Attribute nicht vorhanden, um die Darstellung auf die für den konkreten Anwendungsfall wichtigen Aspekte zu begrenzen.
Jede im Web basiert auf einer Dokumentenstruktur. Die Anwendung dieser Struktur und ihre Ausweisung im Code, bezeichnet im Web die Semantik.
Der semantische Webaufbau ist vergleichbar mit hierarchischen Formatierungen in Programmen zur Textverarbeitung, wie Microsoft Word oder Pages für macOS.
Durch die Ausweisung und Markierung einzelner Textstellen, lassen sich Funktionalitäten zuweisen. So können beispielsweise automatisiert Inhaltsverzeichnisse erstellt werden oder der Leser kann von einer Überschrift zur nächsten springen.
Selbst komplexe Webanwendungen, sollten letztlich hierarchisch darstellbar sein. Das Design und Layout einer Webanwendung, sollte sich daher stets an der dem Dokument zugrunde liegenden Struktur orientieren.
Bei der Umsetzung einer Website muss daher zwingend darauf geachtet werden, dass die ursprüngliche Funktionalität der Anwendung nicht durch den Einsatz von innovativen oder gar experimentellen Technologien verloren geht. Komplexe Strukturen, komplizierte Aufbauten und schwache Hierarchien führen häufig dazu, dass prinzipiell einfache Funktionsabläufe nicht mehr zugänglich sind.
Für den Entwickler beginnt die Umsetzung einer barrierefreien Anwendung beim Konzept. Bevor eine Anwendung wird und nachträgliche Änderungen Kosten entstehen lassen könnten, sollte das Konzept ausreichend durchdacht und getestet werden. Es muss darauf geachtet werden, dass die gewünschte Funktionalität erreicht werden kann und nicht durch komplexe Software blockiert wird. Für den Gestalter gilt es, bei aller Innovationskraft und Kreativität den Überblick nicht zu verlieren. Blinde Nutzer in Webdesign mit einzubeziehen bedeutet nicht, dass das Design nicht für Sehende ansprechend sein kann. "Ästhetik entscheidet darüber, wie wir ein wahrgenommenes Objekt bewerten", daher ist es die Aufgabe eines jeden Gestalters, die Brücke zwischen Funktionalität und ästhetischen Ansprüchen zu bilden. Neben vielen weiteren sind für beide Gruppen besonders die nachfolgend aufgeführten Aspekte und Ansätze wichtig (aus den nachfolgenden Ansätzen wurden aufgrund der Lesbarkeit für diese Version Codebeispiele entfernt – Anmerkung des Autors).
Semantisches Web basiert auf Technologien wie HTML5 und ARIA. HTML ist grundsätzlich hierarchisch aufgebaut. Einzelne Elemente können verschachtelt werden (Nesting), so lassen sich Eltern-Kind-Beziehungen darstellen. Durch den Zusatz von ARIA-spezifischen Tags, kann Elementen eine eigens gewählte Funktionalität hinzugefügt werden.
HTML5-Elemente verleihen dem Code also mehr Bedeutung, ARIA-Tags erweitern diese zusätzlich.
Liste von HTML5 Elementen: https://mzl.la/13RCWd4 Mehr Informationen zu ARIA: https://mzl.la/1PojHIe
Mithilfe von ARIA-Tags lassen sich HTML-Elementen benutzerdefinierte Rollen, Zustände und Eigenschaften zuweisen. So kann der Screenreader dem Nutzer Informationen über einzelne Elemente geben, die sonst nur auf visueller Ebene erkennbar sind.
Mit dem Attribut role lässt sich die "native Rolle eines Elements überschreiben". Die Notwendigkeit des Einsatzes von Aria-Rollen, ist seit der Einführung von HTML5 entsprechend reduziert. Über Aria-Zustände lassen sich Zustände von interaktiven Elementen darstellen. Beispiele: aria-enabled aktives Element aria-disabled inaktives Element aria-busy Element beschäftigt Mit Aria lassen sich verschiedenste Eigenschaften zuweisen. Beispiele: aria-label Beschreibung des Elements aria-required erforderliches Element aria-valuemax maximaler Wert eines Elements
Problemstellung
Screenreader erzeugen Linklisten. Dadurch werden Links aus dem Kontext gerissen und häufig verwendete Linktexte wie “Mehr erfahren” und “Weiterlesen” verlieren ihre Bedeutung. Solche Links können vermieden werden.
Lösung
Für die Erstellung von Inhalten ist in der Regel die Redaktion zuständig. Links zu einzelnen Artikeln werden häufig automatisch generiert, daher liegt die Verantwortung darüber, ob die vom Redakteur gelieferten Inhalt entsprechend eingesetzt werden, bei den Entwicklern.
Die einfachste Möglichkeit einen robusten Link zu erschaffen ist es, dem Redakteur neben dem Titel des Artikels auch eine kurze Beschreibung (\< 200 Zeichen) abzuverlangen. Der Link kann dann um das Teaser-Element gebaut werden.
Um Linktexte wie oder trotzdem verwenden zu können was aus Gestaltungsgründen durchaus sinnvoll sein kann -, kann dem Hyperlink über das HTML-Attribut title zusätzlich Information zugewiesen werden. Der title sollte im Mindesten den Titel des Artikels umfassen, kann aber auch in Kombination mit einem kurzen Teaser-Text verwendet werden. Letzteres ist nach Aspekten der Barrierefreiheit die optimale Lösung.
Das Ausfüllen eines Formulars kann für einen blinden Nutzer sehr schnell frustrierend werden. Bei der Bedienung von Formularen zeigt sich die Bedeutung des Zusammenspiels von Screenreader-Software, Browser und Nutzerkompetenz am deutlichsten.
Folgende Probleme traten beispielsweise bei der Durchführung der Umfrage über Google Forms auf (die folgenden Zitate sind anonymisiert und stammen aus Rückmeldungen von Teilnehmern der benannten Umfrage):
Die genannten Probleme traten teilweise mehrfach, teilweise in abgeänderter Form auf. Vor allem bei der Bedienung durch JAWS traten vermehrt Fehler auf, die zum Abbruch führten. Mit VoiceOver traten keine Probleme auf.
Grundsätzlich gilt es bei Formularfeldern und Schaltflächen drei Dinge zu beachten:
Damit auch komplexe Datensätze wie Tabellen für Blinde zugänglich sind, bedarf es nur weniger Anpassungen im Code. Durch das Hinzufügen einer caption kann die Tabelle auch ohne Kontext eingeordnet und verstanden werden. Zugehörigkeiten von Spalten und Zeilen in komplexen Tabellen werden über das Attribut scope gekennzeichnet.
Die Hauptnavigation einer Website ist wiederkehrendes Element, da sie in der Regel auf jeder Webseite in einer Website vorkommt. Für einen Blinden, der sich hierarchisch durch eine Webseite arbeitet, ist es teilweise sehr mühselig, zum eigentlichen Hauptinhalt zu gelangen, da die Hauptnavigation am Seitenanfang steht. Es sollte daher ein versteckter Menüeintrag an den Anfang der Hauptnavigation gesetzt werden, der den Nutzer über einen Anchorlink zum Hauptinhalt springen lässt. Der Link kann über CSS ausgeblendet werden.
Wichtig ist außerdem, dass die Navigation über die Tastatur steuerbar ist. Menüstrukturen, die über mehrere Ebenen verschachtelt sind, können über entsprechendes JavaScript zugänglich gemacht werden.
Was vor allem zur Steigerung der Suchmaschinenpräsenz genutzt wird, kann auch dem realen Nutzer nicht schaden. Über Breadcrumbs [Brotkrumen], einer Linkliste mit entsprechendem Markup, wird die Hierarchie zwischen den einzelnen Dokumenten einer Website dargestellt. Das erleichtert die Orientierung innerhalb der Anwendung.
Viele Gestalter scheuen sich, gerade bei offenen Layouts, Breadcrumbs überhaupt einzusetzen, dabei bieten sie dem Nutzer gerade bei komplexen und tiefen Hierarchien Orientierung und eine schnellere Navigation durch die einzelnen Schichten der Navigationsstruktur.
Breadcrumbs werden in der Regel durch ARIA-Tags unterstützt, die aktuelle Seite wird durch $aria-current$ definiert. In Kombination mit schema [Weitere Informationen zu schema auf schema.org] kann eine Breadcrumb Navigation so zu einer robusten und übersichtlichen Orientierungshilfe werden und Nutzern wie Suchmaschinen die hierarchischen Zusammenhänge erklären [Mehr Informationen zu schema BreadcrumbList hier: schema.org/BreadcrumbList, abgerufen am 01.07.2018].
Multimediale Inhalte wie Bilder, Tonaufnahmen, Videos und Animationen sind für nicht sehende Menschen fast genau so wichtig wie für sehende. Da Blinde offensichtlich keine Pixel wahrnehmen können, sind sie auf Alternativen angewiesen. Für Bilder kann ein alternativer Text über das Attribut alt angegeben werden, Videos und Animationen können mit einer zusätzlichen Tonspur versehen werden.
In vielen Fällen wird der alt Tag zwar genutzt, jedoch falsch eingesetzt. Häufig entstehen auch Verwirrungen über den Unterschied zwischen alt und title. In manchen Fällen ist sogar der Inhalt von alt der selbe wie der von title.
Natürlich muss bei der Erstellung eines Alt-Textes darauf geachtet werden, dass das Hauptmotiv nicht in den Hintergrund rückt, ansonsten darf die Beschreibung auch durchaus etwas länger sein, denn es geht letztlich darum, eine dem Bild gleichwertige Information anzubieten. Das heißt, ein beschreibender Text in ganzen Sätzen, der die Inhalte, Motive, Emotionen und Aussage des Bildes wiedergeben kann. Wichtig dabei ist, dass das Bild völlig losgelöst vom Kontext werden muss. Um ein Gefühl dafür zu bekommen, was einen guten Alt-Text ausmacht, empfiehlt sich die Website der Bundespartei BÜNDNIS 90/DIE GRÜNEN (www.gruene.de). Als Beispiel hier der Alt-Text des heutigen Titelbilds (https://www.gruene.de/startseite.html, © Erik Marquardt, abgerufen am 01.06.2018):
"Einige Menschen stehen an einer Bootsreling und schauen auf das Wasser. Dabei stützen sie sich zum Teil auf Rettungsringen auf, im Hintergrund sind Rettungsboote auf dem Schiff zu sehen."
Eine Grafik, die nur der Dekoration dient (z.B.: Icon, Banner), ist für einen Blinden uninteressant und störend. Mit dem ARIA-Tag aria-hidden kann ein solches Element gekennzeichnet werden. Screenreader werden dieses Element überspringen.
Eine besondere Herausforderung für die Entwicklung von barrierefreien Webinhalten, stellen interaktive Inhalte dar. Im Zuge einer Veränderung innerhalb des vorliegenden Dokuments, muss der Nutzer entsprechend darüber informiert werden.
Sobald der Nutzer den Button 'Kaufen' betätigt, wird der Tastaturfokus auf das Dialogfeld gesetzt. Der Screenreader beginnt die Ausgabe mit "Bestätigung, Dialog mit 3 Objekten". Daraufhin kann die Interaktion des Nutzers mit dem Dialogfeld beginnen.
Möglich wird diese Interaktion erst durch den Einsatz der Attribute tabindex, role und aria-label, sowie der Funktion confirm(), welche den Fokus des Nutzers auf das Dialogfeld setzt.
Sind die benannten Attribute role und aria-label nicht gesetzt, beinhaltet die Ausgabe über den Screenreader keine Informationen darüber, um welche Art von Element es sich handelt und in welchem Zusammenhang selbiges zum auslösenden Ereignis steht. Lediglich der Text indiziert noch die Charakteristik eines Dialogfeldes.
Lässt man nun noch das Attribut $tabindex$ weg, so ist das Dialogfeld nicht mehr fokussierbar. Die Ausgabe des Screenreaders bei der Betätigung des Buttons 'Kaufen' wäre: "Kaufen, Taste gedrückt". Der Nutzer müsste nun seinen eigenen Weg durch die HTML-Struktur der Webseite, in das zugehörige Dialogfeld finden.
Dies ist nur ein simples Beispiel für barrierefreie interaktive Inhalte. Besonders bei Änderungen von Inhalten auf einer Website ist präzise Planung und ausreichendes Testen erforderlich. Eine gesonderte Stellung bei der Auszeichnung von Rollen, Zuständen und Eigenschaften, nehmen ARIA-Tags ein.
Barrierefreies und zugängliches Design zu realisieren bedeutet auch, dass dieses in unter realen Bedingungen getestet werden muss. Um herauszufinden, wie robust das Design und die Struktur einer Website sind, seien im Folgenden verschiedene Methoden angeführt, die zur Überprüfung der Zugänglichkeit und der Usability einer Website geeignet sind.
Um sicherzugehen, dass die geplante Anwendung auch für Blinde zugänglich ist, empfiehlt es sich, die Bedienung mit mindestens einem Screenreader auszuprobieren. Das kann unter Umständen sehr kompliziert werden, zudem nicht jeder Screenreader eine gute Dokumentation hat und die Unterschiede in der Bedienung teilweise sehr groß sind.
Im Folgenden sei daher eine Übersicht über die wichtigsten Befehle [Bitte beachten Sie das Datum der Veröffentlichung dieser Informationen. Die Funktionalitäten und Tastenbelegungen können sich unter Umständen ändern.] zum Testen der Funktionalitäten eines Webprojekts mit geeigneten [Geeignet meint hier auf den jeweiligen Betriebssystemen vorinstallierten Screenreader bzw. wenn nicht vorhanden, eine Open-Source Alternative. Der Screenreader JAWS wird zwar häufig genutzt, ist aber nur in einer zeitlich begrenzten Testversion verfügbar und kann daher nicht ausreichend getestet werden.] Screenreadern aufgeführt. Neben herkömmlichen und bewährten Browsern wie Google Chrome und Mozilla Firefox, sollten die Funktionalitäten via Screenreader auch in Verbindung mit Microsoft Edge und Safari getestet werden, da diese bereits auf den zugehörigen Betriebssystemen vorinstalliert sind und von Blinden daher häufiger genutzt werden.
Sobald der Umgang mit dem Screenreader ausreichend geübt wurde, empfiehlt es sich ebenfalls, die Bildschirmhelligkeit zu reduzieren oder diesen gänzlich abzuschalten. Für einen einfachen Einstieg empfiehlt sich VoiceOver, da der Screenreader von Apple intuitiv und einfach zu bedienen ist - vor allem für Tests auf mobilen Endgeräten.
Kommentar: Die folgende Liste wurde aus Gründen der Lesbarkeit entfernt (Anmerkung des Autors)
Etwas komplizierter als der Selbsttest ist das Testen mit externen Testpersonen, das so genannte Usertesting oder Usability-Test. Ein solcher Nutzertest kostet Geld und Zeit und muss unter Umständen mehrfach durchgeführt werden, wenn Änderungen an der Software vorgenommen werden. Pribeanu führt an, dass es bei Nutzertests mit Blinden sinnvoll sei, auch eine sehende Testperson hinzuzunehmen, so kann sichergestellt werden, dass die blinde Testperson alle Bereiche der Website ausprobieren kann und nichts übergangen wird. Besonders wenn die Anwendung noch in einem früheren Stadium der Entwicklung steckt, ist es unter Umständen erforderlich, bestimmte Bereiche der Software manuell anzusteuern.
Der Nutzertest kann dabei nicht nur aufzeigen, wo technische Fehler die Bedienung einschränken, er zeigt vor allem auch das Verhalten und die Interaktion des Nutzers mit der Anwendung. Nicht alle Barrieren sind technisch bedingt. Auch komplexe oder unübersichtliche Strukturen können für Nutzer Schwierigkeiten darstellen.
Die Erfahrungen, die ein Blinder bei der Bedienung von Webinhalten mitbringt, können ein wertvoller Informationsquell für die Entwickler und Gestalter sein, wenn es darum geht, barrierefreies Design zu entwerfen. Bei einem Nutzertest mit einem Blinden geht es vor allem auch darum, standardisierte Abläufe, Konventionen in der Bedienung, Abkürzungen und Orientierungshilfen kennenzulernen, um sie in Relation zur getesteten Software stellen zu können.