Wie man dem Spuk der Barrierearmut ein Ende bereitet

Der Geist der Barrierefreiheit
Kommentare

Während der Entwicklungszeit einer neuen Webseite oder Webanwendung geistert in den Räumen von Fachseite, Designern und Entwicklern hin und wieder das Thema Barrierefreiheit umher. Immer mal wieder steht es hinter einem – schemenhaft und angsteinflößend – aber kaum dreht man sich um, ist der Geist weg. Es bleibt nur das beklemmende Gefühl, dass da was ist – etwas, das nach Aufmerksamkeit verlangt.

Meist ignorieren wir dieses Gefühl, denn das Beschäftigen mit dem Thema kostet uns nicht nur Zeit, sondern auch Geld. Das schöne Design könnte ja gebrochen werden müssen, oder die Entwickler müssen dreifach so viel Code produzieren. Und anstatt das Thema aktiv anzugehen, spukt es weiter. Aber was passiert, wenn man Geister zu lange ignoriert? Sie werden aggressiver. Was in unserem Fall bedeutet, dass es teurer wird, unsere Anwendungen nachzurüsten.

Je nachdem, in welchem Umfeld wir uns befinden, ist es heute allein schon von Gesetzeswegen unumgänglich, barrierefreies oder zumindest barrierearmes Design und HTML zu produzieren. So sorgt die „Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz“ (kurz BITV) von 2002 dafür, dass sich sämtliche digitale IT-Auftritte aller Behörden der Bundesverwaltung mit diesem Thema ausführlich beschäftigen müssen. Das BITV basiert ursprünglich auf dem WCAG 1.0 (von 1999), seit 2008 ist hier aber bereits die Version 2.0 der WCAG – Web Content Accessibility Guidelines veröffentlicht. Die WCAG-Richtlinien kategorisieren die Anforderungen nach drei Stufen. Anforderungen aus Level A müssen umgesetzt werden, während die Forderungen des Level AA umgesetzt werden sollten und Anforderungen der Einstufung in Level AAA realisiert werden können. 2011 trat dann auch die BITV2 in Kraft, die im Grunde die WCAG-2.0-Regeln umstrukturiert, in zwei anstelle von drei Stufen eingliedert. Aber warum gelten diese Regeln nur für Seiten von Bundesbehörden, und warum nicht auch für andere?

Ein Grund, weswegen viele Anbieter von Webinhalten das Thema vernachlässigen, basiert auf der Fehleinschätzung, dass es für digitale Medien nur Bildschirm und Drucker als Ausgabemedium gibt und daher gerade blinde und stark sehbehinderte Menschen diese nicht nutzen. Ein zweiter Grund ist das Unterschätzen der Größe des Personenkreises, der auf eingeschränkte Art und Weise Inhalte wahrnimmt. Laut der International Agency for the Prevention of Blindness (IAPB) sind ca. 285 Millionen Menschen weltweit visuell beeinträchtigt. Davon sind ca. 39 Mio. Menschen blind und 246 Mio. leiden unter mittlerer oder starker Sehbehinderung. Ist das wirklich ein zu kleiner Personenkreis?

Um ein Gefühl dafür zu bekommen, wie es sich anfühlt, durch starke Sehbehinderungen eingeschränkt zu sein, wird empfohlen, die Chrome-Erweiterung NoCoffee auszuprobieren. Besuchen Sie damit einige Ihrer Lieblingswebsites – es ist ernüchternd zu sehen (oder eher nicht zu sehen) wie schwer die schönen Designs zu erkennen sind. All die netten kleinen Graphiken, sorgfältig platzierte Elemente oder Aufmerksamkeit erregende Farbkontraste verlieren fast gänzlich ihre Wirkung. Für besonders Mutige: Versuchen Sie einmal, damit ein CAPTCHA zu lösen! Abbildung 1 und 2 zeigen eine Beispielwebsite einmal mit und einmal ohne Beeinträchtigung.

Abb. 1: Screenshot der Homepage von Accso ohne Beeinträchtigung

Abb. 2: Screenshot der Homepage von Accso mit verschwommener Sicht

Ab einer gewissen Schwere der Behinderung ist die Nutzung von Tools erforderlich, die den Zugang zu den Inhalten des Webs auch für schwer eingeschränkte Personen ermöglichen. Statistiken zu diesem Thema sind rar und oft nur eingeschränkt aussagekräftig. Die Studie „Web 2.0/barrierefrei“ der Aktion-Mensch kam zu folgenden Ergebnissen: 91 Prozent der blinden Befragten nutzen einen Screenreader für die Internetnutzung, 70 Prozent eine Sprachausgabe und 85 Prozent eine Braillezeile – ein Gerät, auf dem Text in Blindenschrift dargestellt wird. Das Gerät wird dabei oft durch einen Screenreader angesprochen, der die Inhalte des Bildschirms analysiert und für die Braillezeile aufbereitet. Bilder und Videos können hier nicht „übersetzt“ werden.

Eine Grundlage für die erfolgreiche Verwendung solcher Tools ist ein valider und korrekter Einsatz geeigneter Möglichkeiten von HTML. Eine vollständig barrierefreie Seite zu gestalten, ist mit den heutigen Anforderungen eines modernen und attraktiven Designs so gut wie nicht zu vereinbaren. Inhaltstragende Animationen, graphische Navigationselemente oder auch individuelle Eingabeformulare allein machen es Screenreadern schwer, den Inhalt strukturiert und umfassend wiederzugeben. Auch hier kann man sich schnell einen Eindruck verschaffen. Erforschen Sie doch mal Ihre Lieblingswebsite, oder aber eine Website, die gerade entwickelt wird, indem Sie einen Screenreader verwenden. Dabei hilft das Chrome-Plug-in ChromeVox oder das Open-Source-Produkt des NVDA Project. Das Ergebnis ist eine deutlich andere User Experience. Je umsichtiger das Design und der HTML-Code der Seite gestaltet sind, desto strukturierter und hilfreicher werden Ihnen die Informationen der Website übermittelt.

Wie können Designer und Redakteure helfen

Das Design einer Webanwendung oder Webseite hat großen Einfluss auf die Barrierefreiheit bzw. -armut. Hier kann über durchdachtes Strukturieren des Inhalts schon viel getan werden, um die Seite nutzerfreundlicher zu gestalten.

Text ist dabei mehr als nur das bloße Übertragen von Informationen. Auch wie der Text formuliert ist, hat Einfluss. So sollten Slangbegriffe, Kunstworte und nicht standardisierte Wörter vermieden werden. Ein Screenreader kann zum Beispiel mit dem Begriff n00b (ein Anfänger) nichts anfangen und wird das Wort aufgrund der Verwendung der Zahlen nicht korrekt vorlesen können.

Wir Designer sollten uns auch immer die Frage stellen, wie der Inhalt bei deaktiviertem CSS und/oder JavaScript dargestellt werden kann und sollte. Bei deaktiviertem CSS kann man gut die Reihenfolge der Elemente überprüfen, so wie diese ein Screenreader linearisieren würde. Wir müssen hierbei sicherstellen, dass wichtige Elemente (z. B. die Navigation) möglichst weit oben in der Reihenfolge platziert werden und dass diese verständlich und gut strukturiert sind. Werden die dynamischen Inhalte (z. B. Animationen) deaktiviert, muss die Seite weiterhin verwendbar sein. Hier können Austauschelemente helfen, die im NoScript-Fall dargestellt werden – auch diese sollten aber nach den Designkriterien gestaltet werden.

Farben und Kontraste sind auch ein wichtiges Thema. Browser und Betriebssysteme ermöglichen es Nutzern sehr leicht, das Farbschema anzupassen und damit unsere gut durchdachten Farbeffekte auszuhebeln. Durch geeignete Kontraste kann hier dennoch die Separierung von Abschnitten ermöglicht werden. Auf Beschreibungen wie „… im grünen Bereich finden Sie die Information zu …“ als Hinweise zur Navigation sollte dennoch verzichtet werden, denn dem Nutzer steht es frei, das Farbschema seinen Bedürfnissen anzupassen – im Extremfall ist dann Grün nämlich nicht mehr Grün.

Den Nutzern sollten für die medialen Inhalte alternative Texte angeboten werden. Mit Sicherheit ist es schon weit verbreitet, das alt-Attribut bei IMG-Tags zu verwenden. Oft werden hier aber unpräzise Texte vergeben wie Photo oder Navigation. Das hilft nur wenig weiter. Die alternativen Texte sollten mit wenig Worten den Inhalt des Bilds darstellen, z. B. „Portraitphoto von Max Mustermann, Geschäftsführer von GreatCompany“ oder „Unter diesem Bild ist ein Angebot dargestellt“. Oft wird hier auch Copyright-Information übermittelt. Diese sollte auch weiterhin im alt-Attribut stehen – eben als Ergänzung zum Beschreibungstext. Bilder, die keine inhaltlichen Informationen tragen, sollten dagegen mit einem leeren alt-Text versehen werden – diese müssen nicht vom Screenreader vorgelesen werden. Ebenso sollte das title-Attribute mit hilfreichen Informationen bestückt werden, nicht nur bei Bildern – auch bei Labels, Tabellen, Eingabefeldern usw. Folgend das Beispiel-Code-Snippet von title– und alt-Attributen vom IMG-Tags:

Portrait-Photo von Max Mustermann, Geschäftsführer von GreatCompany

Hilfeseiten und Tipps tragen ebenfalls zum Verständnis bei. Dabei können die Hilfeseiten zum Beispiel komplexe Elemente beschreiben oder auch Abläufe und Inhalte erklären. Auch wenn es für einen uneingeschränkten Nutzer eher überflüssig ist, zu sagen, wo sich zum Beispiel die Suche befindet, ist es doch hilfreich für seheingeschränkte Nutzer, wenn dies in ein paar Worten erklärt wird. Gerade beim Erstkontakt zwischen Nutzer und Website kann hier die Akzeptanz erhöht werden, wenn die Seite ausführlich erklärt wird. Besonders interaktive Elemente erfordern diese Orientierungshilfe. Dabei können Tipps (z. B. „Kennen Sie schon?“) auch dynamisch eingeblendet werden, um den Nutzer zu führen.

Die Nutzer können auch bei dem angebotenen Suchfeature mit phonetischen Korrekturfunktionen unterstützt werden. Dieses „Meinten Sie?“- oder auch „Did-You-Mean?“-Feature hilft bei Rechtschreibschwächen schnell weiter – auch auf mobilen Endgeräten, bei denen sich jeder schnell vertippen kann.

Auch Downloads und Inhalte, die nicht direkt im Browser wiedergegeben werden (z. B. Flash-Pop-ups) sollten barrierefrei sein. Für PDF-Dateien gibt es zum Beispiel einen ISO-Standard 14289-1:2012 („Document management applications – Electronic document file format enhancement for accessibility – Part 1: Use of ISO 32000-1 (PDF/UA-1)“), der durch den Ansatz der Universal Accessibility die Gestaltung von PDF-Dokumenten beschreibt.

Aufmacherbild: <a href="http://www.shutterstock.com/pic.mhtml?id=190449566&src=id" title="Reading Braille Fingers going across a page of Braille text von Shutterstock / Uhrheberrecht: schafar “ class=“elf-external elf-icon elf-external elf-icon“ rel=“nofollow nofollow“>Reading Braille Fingers going across a page of Braille text von Shutterstock / Urheberrecht: schafar [ header = Seite 2: Wie können Entwickler helfen ]

Wie können Entwickler helfen

Aber auch als Frontend-Entwickler haben wir viel Einfluss darauf, ob wir diesen Nutzern das Leben einfach oder schwer machen. Schon Kleinigkeiten können helfen. So sollte unser HTML und CSS so gestaltet sein, dass es bei übergroß skalierten Schriften weder zu versteckten Inhalten noch zu zerstörtem Layout kommt. Schon bei der Definition der Seite sollte darauf geachtet werden, dass auch die Sprache des Inhalts definiert ist, wie im folgenden Snippet in Spanisch:


Zur Übersichtlichkeit und Strukturierung sollten die definierten Elemente richtig verwendet werden. Verwendet werden sollen die

-Tags! Aus dem gestalterischen Gesichtspunkt gibt es fast nie einen Grund mehr, als sechs Überschriftkategorien zu verwenden. Also sollten die Headings per CSS direkt gestylt und nicht SPAN-Tags mit extra CSS-Klassen verwendet werden. Listing 1 zeigt das Beispiel-Code-Snippet für die Verwendung von HTML-Headings.

  
    ...
    
      body { background-color:#000000; color:#E0E0E0 }
      h1 { font-size: 18px; font-weight: bold; color:#00DD00 }
      h3 { font-size: 14px; font-weight: normal; color:#00DD00 }
      p { font-size: 12px; font-weight: normal; color:#FFFFFF }
    
    ...
  
  
    ...
    

News

...

News-Eintrag vom 20.04.2013

Neueste Nachrichten vom 20.04.2013


News-Eintrag vom 22.04.2013

...

News-Eintrag vom 25.04.2013

...

Die Steuerung per Tastatur wird ebenfalls gern vernachlässigt. Die Browser erlauben diese zwar, aber in welcher Reihenfolge die Elemente angesprochen werden und durch welche optische Hervorhebung wir den aktuellen Fokus wiederspiegeln, liegt in unserer Hand. :focus– und :hover-Style-Definitionen sollten möglichst dieselben sein und sich vom „normalen“ Zustand des Elements abheben. Zur Festlegung der Reihenfolge der Elemente sollten diese so mit dem Attribut tabIndex (und entsprechenden Werten) versehen werden, dass die Führung durch den Inhalt sinnvoll der gewünschten optischen Führung entspricht.

Eine große Unterstützung für Screenreader bietet das WAI-ARIA-Framework. Dessen Verwendung ist etwas aufwändiger, aber nicht weniger effektiv. Die Accessible Rich Internet Applications Suite (ARIA) der Web Accessibility Initiative (WAI) stellt Richtlinien bereit, die gerade bei komplexen dynamischen Webinhalten basierend auf AJAX, HTML, JavaScript und ähnlichen Technologien helfen, die Inhalte für Hilfsmittel zu strukturieren. Hier werden u. a. Navigationstechniken beschrieben, um so genannte Regionen und andere Strukturelemente (z. B. Menüs, Banner, Inhalt usw.) effektiv zu markieren. Das erlaubt zum Beispiel Browsern, gezielter mit Tastatursteuerung – und nicht nur durch TAB-Kanonaden – durch den Inhalt zu navigieren. Weiterhin können Steuerelemente (z. B. Buttons) und dynamische AJAX-Elemente und andere Events ausgezeichnet werden. Hierzu wird eine Menge von weiteren Attributen zur Verfügung gestellt. Einige wenige stellen wir Ihnen gezielt vor. Abbildung 3 zeigt das WAI-ARIA-Framework in der Übersicht.

Abb. 3: Einordnung des WIA-ARIA-Frameworks beim Zugriff auf eine Website

Mit Live-Regionen sind dynamische Anteile der Seite gemeint. Das können zum Beispiel laufende Uhrzeitangaben, Börsenticker, Fußballliveticker oder auch die Animation der aktuellen Wetterlage sein. Durch die Markierung einer solchen Region, kann der Screenreader verstehen, wann die Änderung des Inhalts mitgeteilt werden soll. Dafür wird das Attribut aria-live verwendet, für das es vier Werte gibt (Tabelle 1).

 Tabelle 1: Bedeutung der ARIA-Live-Regionen

Weiterhin kann man bei den Live-Regionen definieren, welche Elementveränderungen genau mitgeteilt werden müssen. So kann man bestimmen, ob nur das Element mit der echten Veränderung neu vorgetragen wird oder die Region darum, da sie zum Beispiel den Kontext zum Element definiert. So bringt das Vorlesen der aktualisierten Zahl 26 keinen Mehrwert. Im Kontext, dass es sich hier um die aktuelle Temperatur in meiner Stadt handelt, macht es dagegen schon mehr Sinn. Will man die gesamte Live-Region erneut vortragen lassen, muss das äußerste Element der Live-Region um das Attribut atomic mit dem Wert true erweitert werden. Wird dieses nicht gesetzt (oder auf false), dann wird der Screenreader nur die entsprechende Änderung innerhalb der Region vortragen.

Man kann ebenfalls konfigurieren, welchen Änderungstyp man beachten und welchen ignorieren möchte. So kann eingestellt werden, ob der Zuhörer benachrichtigt wird, wenn Inhalte entfernt oder hinzugefügt wurden, oder ob Text verändert worden ist. Dazu wird das Attribut relevant gesetzt, das die vier Werte aus Tabelle 2 annehmen kann.

 Tabelle 2: Bedeutung der ARIA-relevant-Optionen

Die Optionen können auch verkettet werden, so z. B. relevant=additions text„. Damit würde der Screenreader den Nutzer bei hinzugefügten Elementen sowie Textanpassungen informieren, nicht aber bei der Entfernung von Elementen. Das folgende Code-Snippet für die Markierung von Live-Regionen im ARIA-Framework:

  • Item 1
  • Item 2
  • item 3

Mithilfe des Rollen-Attributs können Elemente bzgl. ihres semantischen Sinnes markiert werden. So können Elemente als wichtig oder unwichtig für den Kontext (den Inhalt, der durch die aktuelle Seite präsentiert wird) eingestuft werden, oder einfach über ihren Inhalt Auskunft geben. Auch hierfür gibt es eine Menge von Optionen. In Tabelle 3 ist nur eine kleine Auswahl aufgeführt.

 Tabelle 3: Bedeutung der ARIA-Rollen-Optionen (Auswahl)

Grundsätzlich kann man Rollen in drei Typen einordnen (Tabelle 4). Rollen zur Navigation (Landmark-Rolle), Rollen zur Strukturierung (Struktur-Rolle) und Rollen für einzelne Fragmente (Widget-Rolle).

 Tabelle 4: Auflistung der ARIA-Rollen nach Typen

Die Verwendung der Rollenbeschreibung erfolgt analog der anderen ARIA-Attribute:

  • Kunden
  • Team
  • News

Hängen DOM-Elemente miteinander inhaltlich zusammen, kann dies durch die Attribute describedby oder auch labelledby signalisiert werden. Solche Beziehungen sind zum Beispiel relevant für Eingabefelder und zugehörige Beschreibungstexte (Label). Ebenso sollten Required-Informationen nicht nur „nebenbei“ erwähnt werden. Damit der Zusammenhang weiter gegeben ist, sollte das area-required-Attribut direkt am Element Verwendung finden. Das folgende Code-Snippet steht für die Markierung von Zusammenhängen zwischen DOM-Elementen im ARIA-Framework:

    

Die hier vorgestellten Attribute waren nur eine kleine Auswahl der ARIA-Suite. Mehr Informationen finden sich auf der Homepage des Projekts.

Nebenbei sei noch erwähnt, dass HTML5 bereits einen Schritt in die richtige Richtung geht, z. B. mit der erweiterten Verwendung von semantischen Auszeichnungen. Wenn man die ARIA-Elemente nur sparsam einsetzen möchte, können schon die neuen HTML5-Strukturelemente weiterhelfen. Im Folgenden sind ein paar HTML5-Elemente mit den entsprechenden Role-Attributen gegenübergestellt: •

entspricht: role=“article“
entspricht: role=“banner“

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -