4Max/shutterstock.com

13. Juni 2013 / von Ulrike Heidler

Let’s make

it a

better

world!

Vor kurzem habe ich an einem sehr interessanten Vortrag auf der JAX 2013 zum Thema Barrierefreiheit im Web teilgenommen. Aber: Auf einer sonst gut besuchten JAX fanden neben mir nur weitere 12 Zuhörer dieser Session interessant. Im Ernst? 12? Ist das für alle anderen schon ein alter Hut und nur für mich nicht? Ich bin darüber sehr erschrocken, da dieses Thema mehr Endnutzer betrifft als die meisten Entwickler wohl erwarten würden.  Laut der International Agency for the Prevention of Blindness („IAPB“, siehe  [Q1]) sind ca. 285 Millionen Menschen weltweit visuell beeinträchtig.

Screenshot der Homepage von Accso (ohne Beeinträchtigung)
Screenshot der Homepage von Accso (ohne Beeinträchtigung)

Davon sind ca. 39 Mio. Menschen blind und 246 Mio. leiden unter mittlerer oder starker Sehbehinderung. Um ein Gefühl dafür zu bekommen, wie es sich anfühlt durch starke Sehbehinderungen eingeschränkt zu sein, empfehle ich Ihnen, die Chrome Erweiterung „NoCoffee“ (siehe [Q2]) auszuprobieren. Besuchen Sie damit einige Ihrer Lieblings-Web-Sites – es ist ernüchternd zu sehen (oder eher nicht zu sehen) wie schwer die schönen Designs zu erkennen sind. All die netten kleinen Grafiken, sorgfältige platzierten Elemente oder Aufmerksamkeit erregenden Farbkontraste verlieren fast gänzlich Ihre Wirkung. Für besonders Mutige: Versuchen Sie einmal, damit ein CAPTCHA1 zu lösen! Screenshot der Homepage von Accso mit verschwommener Sicht

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 % der blinden Befragten nutzen einen Screenreader2 für die Internetnutzung, 70 % eine Sprachausgabe und 85 % eine Braillezeile3 (Statistik aus [Q3]). 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 Eingabe-Formulare machen es Screenreadern schwer den Inhalt strukturiert und umfassend wiederzugeben. Auch hier kann man sich schnell einen Eindruck verschaffen. Ich darf präsentieren: Die Lesung von „Accso – die Homepage“ gelesen von „male3“ – der Stimme aus dem  NVDA Project (NonVisual Desktop Access Project) [Q4]:

Lesung der Accso Seite

Erforschen Sie doch mal Ihre Lieblings-Website, oder aber eine Website, die gerade von Ihnen entwickelt wird, indem Sie einen Screenreader verwenden. Das OpenSource-Produkt des NVDA Project bietet dazu eine optimale Möglichkeit (siehe [Q4]).  Sie werden eine deutlich andere User-Experience erleben. Je umsichtiger der HTML-Code der Seite gestaltet ist, desto strukturierter und hilfreicher werden Ihnen die Informationen der Website übermittelt.

Als Frontend-Entwickler haben wir viel Einfluss darauf, ob wir diesen Hilfsmitteln das Leben einfach oder schwer machen. Schon Kleinigkeiten können helfen. Ein paar davon möchte ich Ihnen im Folgenden vorstellen. Nebenbei sei noch erwähnt, das HTML5 bereits einen Schritt in die richtige Richtung, z.B. mit der erweiterten Verwendung von semantischen Auszeichnungen, geht. Wenn man die Elemente sparsam einsetzen möchte, können schon die neuen HTML5-Strukturelemente weiterhelfen. Da dies aber nicht Inhalt dieses Beitrags sein soll, verweise ich an der Stelle an SelfHTML5 [Q7].

Alternative-Texte für Bilder: Mit Sicherheit ist es schon weit verbreitet, das „alt“-Attribut beim 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 Bildes darstellen, z.B. „Portrait-Photo von Jürgen Artmann, Geschäftsführer von Accso“ 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.

<img src=“images/artmann.jpg“ alt=“Portrait-Photo von Jürgen Artmann, Geschäftsführer von Accso“ title=“Portrait-Photo von Jürgen Artmann, Geschäftsführer von Accso“ />
<img src=“images/separator.jpg“ alt=““ title=“Trenner-Linie“/>

Listing 1: Beispiel-Code-Snippet von title- und alt-Attributen vom IMG-Tags

HTML-Headings: Verwenden Sie die <H1> – <H6>-Tags! Aus dem gestalterischen Gesichtspunkt gibt es fast nie einen Grund mehr als 6 Überschrift-Kategorien zu verwenden. Also stylen Sie bitte die Headings per CSS direkt und verwenden nicht SPAN-Tags mit extra CSS-Klassen.

<html>
  <head>
…
    <style type="text/css">
      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 }
    </style>
…
  </head>
  <body>
…
    <h1>News</h1>
…
    <h3> News-Eintrag vom 20.04.2013 </h3>
    <p>Neueste Nachrichten vom 20.04.2013</p>
    <hr />
    <h3> News-Eintrag vom 22.04.2013 </h3>
…
    <h3> News-Eintrag vom 25.04.2013 </h3>
…
  </body>
</html>

Listing 2: Beispiel-Code-Snippet für die Verwendung von HTML-Headings

WAI-ARIA: Nach diesen zwei doch recht einfachen und schnellen Quick-Wins ist die Anwendung des WAI-ARIA-Frameworks [Q5] 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 Web-Inhalten basierend auf AJAX, HTML, JavaScript (oder ähnlichen Technologien) helfen, die Inhalte für Hilfsmittel zu strukturieren. Hier werden u.a. Navigations-Techniken beschrieben, um sogenannte „Regionen“ und andere Struktur-Elemente (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 möchte ich Ihnen gezielt vorstellen.

Live-Regionen: Damit sind Teile der Seite gemeint, die sich dynamisch verändern. Das kann zum Beispiel die Darstellung des Spielstands bei einem Fußball-Live-Ticker sein, oder die Animation der aktuellen Wetterlage. Durch die Markierung einer solchen Region, kann dem Screenreader übermittelt werden, wann die Änderung des Inhalts mitgeteilt werden soll. Dafür wird das Attribut „aria-live“ verwendet, für das es vier Werte gibt:

  • „off“: Die Screenreader soll Aktualisierungen dieser Region nicht signalisieren
  • „polite“: Der Screenreader soll die Aktualisierung mitteilen, sobald der Nutzer keine Aktionen mehr ausführt.
  • „assertive“: Der Screenreader soll die Änderung so bald wie möglich mitteilen
  • „rude“: Die Mitteilung soll sofort gemacht werden.

Weiterhin kann man bei den Live-Regionen definieren, welche Änderungen genau mitgeteilt werden müssen. Muss die gesamte Live-Region erneut vorgetragen werden, dann 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.

Auch die Art der Änderung kann konfiguriert werden, denn nicht alle Änderungen in den Live-Regionen müssen relevant sein. So kann eingeschränkt werden, ob der Zuhörer benachrichtigt werden sollen, wenn Inhalte entfernt oder hinzugefügt wurden oder ob Text verändert worden ist. Dazu wird das Attribut „relevant“ gesetzt, welches die folgenden vier Werte annehmen kann:

  • „removals“: Das Entfernen von HTML-Knoten soll vorgetragen werden.
  • „additions“: Das Hinzufügen von HTML-Knoten soll vorgetragen werden.
  • „text“: Veränderte Texte sollen vorgetragen werden, dies inkludiert neben den „offensichtlichen Texten“ auch Textäquivalente wie zum Beispiel das „alt“-Attribut bei Bildern.
  • „all“: Sämtliche Änderungen sollen durch den Screenreader wiedergegeben werden.

Die Optionen können auch verkettet werden, so z.B. relevant=“additions text“, welches Signalisiert, das hinzugekommenen Knoten und veränderte Textbausteine durch den Screenreader signalisiert werden sollen.

<ul aria-live="polite" aria-atomic=”true” aria-relevant=”additions text”>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>item 3</li>
</ul>

Listing 3: Beispiel-Code-Snippet für die Markierung von Live-Regionen im ARIA-Framework

Rollen: Mit Hilfe des „Rollen“ Attributes können Elemente bzgl. ihres semantischen Sinnes markiert werden. So können Elemente als unwichtig oder wichtig 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. Im Folgenden ist nur eine kleine Auswahl aufgeführt:

  • „alert“: Dieser DOM-Knoten ist besonders wichtig und muss sofort dem Nutzer vorgetragen werden. Beispielsweise kann man dies zur Darstellung von blockierenden Fehlern verwenden.
  • „status“: Knoten, die damit markiert sind, haben implizit eine Live-Region- Einstufung „polite“. [k1] Diese Informationen sind demnach wichtig, aber sind nicht so dringend, wie Elemente mit der role=“alert“.
  • „timer“: Wie der Name vermuten lässt sollten hiermit Elemente markiert werden, die Rest-Zeiten oder RestStückzahlen verdeutlichen. Ein Element mit dieser Rolle versteht sich implizit als eine Live-Region mit der Einstufung „off“.
  • „marquee“: Hier werden hoch-dynamische Elemente als Kontext-unwichtig markiert. Das bedeutet, Änderungen in diesem Bereich müssen nicht vorgetragen werden. Das können zum Beispiel Werbebanner sein.
  • „menu“/“menuitem“: Damit werden Navigations-Menüs bzw. deren Einträge markiert.
  • „navigation“: Mit dieser Rolle werden Links oder ähnliche Navigations-Elemente markiert.
  • „tooltip“: DOM-Knoten die Tooltips für Eingabe-Felder darstellen können mit dieser Rolle versehen werden.
<ul role="navigation">
  <li href="customer">Kunden</li>
  <li href="team">Team</li>
  <li href="news">News</li>
</ul>

Listing 4: Beispiel-Code-Snippet für die Markierung mit Rollen im ARIA-Framework

Zusammenhänge: Hängen DOM-Elemente miteinander inhaltlich zusammen kann dies durch das Attribut „describedby“ signalisiert werden. Solche Beziehungen sind zum Beispiel Eingabefelder und zugehörige Beschreibungstexte.

<input type="text"  id="name_input" name="name_input"
onmouseover="showTooltip(event, this, 'tooltipDiv');"
onfocus="showTooltip(event, this,  'tooltipDiv');"
aria-describedby="tooltipDiv"
aria-required="true"/>
<div id="tooltipDiv" role="tooltip">Bitte geben Sie Ihren Namen ein.</div>

Listing 5: Beispiel-Code-Snippet für die Markierung Zusammenhängen zwischen DOM-Elementen im ARIA-Framework
Was ich Ihnen hier vorgestellt habe, ist nur eine kleine Auswahl an Optionen der ARIA-Suite. Für mehr Informationen schauen Sie doch einfach mal auf der Homepage des Projektes vorbei (siehe [Q5]).

Ich hoffe, mit diesem Artikel konnte ich ein wenig verdeutlichen, wie einfach es doch ist, Nutzern mit Behinderungen den Zugang zu Web-Inhalten mit Hilfe von Unterstützungs-Tools und einfachen HTML-Kniffen zu erleichtern. Abgesehen davon, dass es durch Gesetze wie dasWCAG – Web Content Accessibility Guidelines (siehe [Q6]) in den meisten Fällen vorgeschrieben ist, sollte es auch immer ein Ziel für uns Entwickler sein, unseren Code dementsprechend zu gestalten bzw. zu verbessern, um damit alle unsere Nutzer abzuholen.

Immer im Sinne von „Jeden Tag eine gute Tat“.

 

Footnote:

1. CAPTCHA – das sind diese kleinen Abfragen die man immer zusätzlich richtig beantworten möchte, wenn man zum Beispiel ein Anmeldeformular ausfüllt oder einen Forums-Beitrag abgeben will.

2. Screenreader – das ist ein Software Applikation, die den Inhalt eines Bildschirms identifiziert und versucht laut vorzulesen.

3. Braillezeile – das ist ein Hardware Gerät, auf dem Text in Blindenschrift dargestellt wird. Das Gerät wird dabei oft durch einen Screenreader angesprochen, der den Inhalt des Bildschirms analysiert und für die Braillezeile aufbereitet. Bilder und Videos können hier nicht „übersetzt“ werden.

Referenzen:

[Q1] – Homepage der „International Agency for the Prevention of Blindness“

[Q2] – Chrome Extension „NoCoffee“

[Q3] – Aktion-Mensch: Studie „Web 2.0/barrierefrei“

[Q4] – Screenreader Software: NonVisual Desktop Access Project (NVDA)

[Q5] – Webseite des WAI-ARIA Projekts

[Q6] – WCAG – Richtlinien für die Barrierefreiheit von Webinhalten

[Q7] – SelfHTML5 – http://www.selfhtml5.org

Autor

Ulrike Heidler
Ulrike Heidler
Weitere Artikel

Das könnte Sie auch interessieren