Immer weiter

Mittlerweile gehört die Entwicklung barrierefreier Webangebote zu einer der etablierten Disziplinen der Internettechniken und ist für zahlreiche Anbieter gesetzlich verordnet. Zur Zielgruppe gehören zum einen Menschen mit Einschränkungen in Motorik, Sehen und Hören. Unter den allgemeinen Begriff der Zugänglichkeit von Internetangeboten (engl.: Accessibility) fallen außerdem Nutzer mobiler Ausgabemedien, die ein leicht erreichbares Webangebot erwarten. Und nicht zuletzt hilft gute Zugänglichkeit Webcrawlern beim Durchsuchen des Internetangebots. Dies wiederum unterstützt die Search Engine Optimization (SEO), da die gute Strukturierung es Suchmaschinen erleichtert, die wesentlichen Bestandteile einer Internetseite zu identifizieren. Das in Vorbereitung befindliche HTML5 verspricht eine Stärkung von Barrierefreiheit, soll diese doch als integriertes Konzept in den neuen Standard einfließen und dadurch selbstredend Verbesserungen mit sich bringen.

Menschen mit Behinderungen, denen „ohne die Erfüllung zusätzlicher Bedingungen die Nutzung der Informationstechnik nur eingeschränkt möglich ist, den Zugang dazu zu eröffnen“ ist Ziel der „Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz“ (BITV, [a]). Hiernach müssen seit Ende des Jahres 2005 alle öffentlich erreichbaren Internetangebote der Behörden der Bundesverwaltung barrierefrei umgesetzt sein. Für diese Zielgruppe ermöglicht das Internet eine Vereinfachung alltäglicher Aufgaben, indem es beispielsweise den Zugang zu behördlichen Instanzen erleichtert.

Mit dem bisherigen Webstandard HTML 4 beziehungsweise XHTML 1 lassen sich die Anforderungen zur Bedienung dieser Zielgruppe weitgehend umsetzen. Allerdings birgt das bisherige Auszeichnungsset Schwachstellen. So sind bei der Textstrukturierung HTML-Fragmente erforderlich, die die Übersichtlichkeit des Quelltextes reduzieren, was wiederum zu Konflikten mit Screenreadern führen kann. Außerdem können Webautoren nur bestimmte HTML-Elemente mit Tastaturkürzeln belegen.

Typische Optimierungen der Accessibility

Besucher mit visuellen Einschränkungen erschließen sich den Inhalt einer Webseite beispielsweise über Screenreader, die den Inhalt per Sprachausgabe wiedergeben. Da ein Screenreader den Inhalt der HTML-Datei gewöhnlich von oben nach unten vorträgt, sollten deren Elemente so angeordnet sein, dass der Kerninhalt der Seite zuerst im HTML-Code erscheint, vor zusätzlichen Informationen – selbst wenn der normale HTML-Elementfluss, der neben der vertikalen die horizontale Richtung beinhaltet, dies anders fordert. Ein Beispiel für diese Optimierung liefert der Internetauftritt des Bundesministeriums für Bildung und Forschung. Auf Artikelseiten werden in der CSS-freien Variante die Hauptnavigation und das Servicemenü nach dem Hauptinhalt der Seite dargestellt – im Gegensatz zur CSS-Version der Seite (siehe [c]).

Schwierigkeiten stecken bei der barrierefreien Optimierung oft in Details. So ist es bei komplexen Tabellen erforderlich, besonders sauber zwischen Überschriften- und Datenzellen zu unterscheiden und die Übersichtlichkeit kritisch zu hinterfragen. Deutlich wird diese Notwendigkeit bei solch komplexen Tabellendaten wie im Überblick zu Förderungsvoraussetzungen auf der Internetseite „stipendium plus“ ([e], siehe Abb. 1). Würden hier durch die explizite Referenz auf die Spaltenüberschriften „Studienförderung“ und „Promotionsförderung“ die Verweise für die nicht visuellen Ausgabemedien fehlen und ein Screenreader stur zum Vorlesen von links oben nach rechts unten gezwungen, ginge nach wenigen Zeilen der Überblick verloren.

Außerdem wird empfohlen, genaue Beschreibungen für den Alternativtext von Bildern und Grafiken zu formulieren. Eine Barriere stellt ebenfalls Videomaterial dar, zu dem man einen beschreibenden Text als Alternative anbieten sollte.

Motorische Einschränken führen bei Webseitenbesuchern dazu, dass statt der Maus nur die Tastatur als Navigationsmittel zur Verfügung steht. Die hiermit verbundenen Optimierungen decken sich zum Großteil mit den oben beschriebenen. Darüber hinaus kommen hier die Tastaturkürzel zum Tragen, mit denen Elemente direkt über die Browserfunktionen navigierbar werden. Daneben ist eine sinnvolle Reihenfolge bei Benutzung der Tabulatortaste angeraten. Für die Verwendung von Tastaturkürzeln als Metanavigation liefert die Internetpräsenz des Frauenrats ein plakatives Beispiel [f]. Auf dieser Seite ist, wie in Abbildung 2 zu sehen, das als AccessKey-Pad bezeichnete Navigationselement mit zehn Shortcuts auf wichtige Unterseiten belegt – jeweils per Maus oder mit Alt-Shift-Ziffer (Firefox) zu erreichen.

Für gehörlose Menschen dürfen Webautoren nicht vergessen, Audiomaterial durch eine Inhaltsbeschreibung in Textform zu ergänzen. Zusätzlich sollten sie für wesentliche Funktionen auf JavaScript verzichten, da das vor allem für Screenreader eine unüberwindliche Barriere darstellen kann.

Bei allem Aufwand, den diese Maßnahmen mit sich bringen, sollten Designer immer daran denken, dass eine barrierefreie Umsetzung Webcrawlern die Erschließung und Analyse der Webseiteninhalte vereinfacht und die Präsentation auf unterschiedlichen Ausgabemedien unterstützt. Eine gute Richtlinie, auf was man alles bezüglich Barrierefreiheit achten sollte, liefern die Prüfkritierien des Biene-Award, der seit 2003 barrierefreie Angebote im Internet auszeichnet.

Neuerungen durch HTML5

HTML5 definiert als Ziel bezüglich der Barrierefreiheit nicht weniger als einen Philosophiewechsel. So sollen Zusatzinformationen nicht länger in unsichtbaren Attributen wie alt oder summary untergebracht, sondern vielmehr im normalen HTML-Body platziert werden. Denn diese Zusatzinformationen sind zum einen tendenziell für alle Zielgruppen interessant, und sie nötigen den Seitenbetreiber darüber hinaus zur konstanten Aktualisierung. Im Fokus stehen somit nicht unbedingt zahlreiche neue Funktionen, sondern vielmehr punktuelle Verbesserungen.

Eine der spektakulären Neuerungen in HTML5 ist die Forderung, dass Browser Video- und Audiomedien ohne zusätzliche Software (Plug-ins) durch den Browser wiedergeben (über die beiden Elemente video und audio). Allein dies beseitigt letztlich die Barriere, zusätzliche Software installieren und korrekt zuordnen zu müssen. Beiden Elementen gemeinsam ist die grundsätzliche Auszeichnungsmethode, zwischen öffnendem und schließendem Tag die Quellen über das Element source anzugeben.

Leider führt die Beseitigung der einen Barriere direkt zu einer neuen: Denn die unterstützten Medienformate weichen zwischen den Browsern deutlich voneinander ab. Nicht jeder Hersteller möchte das populäre MP3-Format lizenzieren. So kann Chrome solche Dateien wiedergeben, Firefox dagegen nicht, weil Mozilla auf das offene OGG-Format setzt. Anbietern von Video- und Audiodateien auf Internetseiten bleibt dadurch nur, mehrere Quellen in unterschiedlichen Formaten anzubieten, um sicherzugehen, dass der Webseitenbesucher Zugang hierzu erhält.

Bei Videos sollten Webentwickler für Menschen mit visuellen Einschränkungen durch Screenreader auswertbare Informationen hinterlegen, die den Inhalt der Datei beschreiben. Das kann man zwar durch eine zusätzliche textliche Beschreibung auf der Seite erreichen, aber es existiert kein Standard, wie solcher Text mit dem Video zu verknüpfen wäre. Diese Barriere verringert HTML5 nur geringfügig, denn innerhalb des Video-Blocks fehlt die Option, eine Beschreibung hinzuzufügen. Zwar existiert das Attribut kind innerhalb des Elements track, über das man Untertitel einbinden kann, jedoch erfordern diese das Nachladen einer externen Datei und funktionieren derzeit nicht ohne JavaScript – was wiederum eine Kernforderung der Barrierefreiheit ist.

Bei Audioinformationen ist für die Zugänglichkeit wichtig, dass ein Fallback für gehörlose Nutzer den Inhalt des Mediums als textliche Beschreibung anbietet. Genau wie beim Videoelement findet sich aber in HTML5 kein Platz dafür. Der Aufbau ist im Wesentlichen gleich: Innerhalb des umschließenden Elements audio definieren Autoren die Quellen. Um sicherzugehen, dass die wichtigen Browser das Medium wiedergeben können, sollten sie wie beim Videoelement mehrere Dateiformate einstellen. Weil die Option einer textlichen Beschreibung fehlt, können Webcrawler den Inhalt von Audio- und Videoelementen nicht identifizieren.

Überarbeitete Formulare

Eine deutliche Verbesserung steckt in den neuen Formularmöglichkeiten von HTML5. Das Attribut autofocus ermöglicht eine gezielte Lenkung des Besuchers auf das Formular und vermeidet eventuelle Orientierungsschwierigkeiten im Kontext einer komplexen Internetseite. Das Attribut können Webautoren pro Seite genau einem Formularfeld zuweisen. Es sorgt dafür, dass dieses Element nach dem Laden der Seite zuerst in den Fokus kommt. Ein weiteres neues Attribut heißt placeholder. Es bewirkt Musterdaten in Eingabefelder und verringert Irrtümer bezüglich des Formats angeforderter Daten. Diese beiden Neuerungen in Kombination mit dem seit HTML 4 bestehenden tabindex-Attribut – hiermit ist die Reihenfolge der Formularelemente beim Anspringen per Tabulatortaste gezielt steuerbar – ist vor allem bei komplexen Formularen mit einer hohen Anzahl von Elementen die Bedienbarkeit per Tastatur stark vereinfachbar.

Reihenfolge per tabindex

In Listing 1 legt das tabindex-Attribut die Reihenfolge beim Navigieren per Tabulatortaste fest: erst das input-Element mit „b“ als Inhalt von name, danach das mit „a“ und schließlich das mit „vorwahl“. Im Attribut placeholder ist Text eingetragen (siehe Abb. 4), der verschwindet, wenn das Element aktiv ist und wieder erscheint, wenn es leer gelassen wird.

Eine Steigerung der Übersichtlichkeit bei längeren Formularen, die über mehrere Seiten übergreifend Daten abfragen, ist durch Statusanzeigen realisierbar. Mit HTML5 steht hierfür das Element progress zur Verfügung.

Attribute für Bedeutungen

Häufig stellt es sich bei der Auszeichnung mit HTML als schwierig dar, für unterschiedliche Textarten wie Fließtext, Kontaktdaten oder Kalenderinformationen keine adäquaten Elemente verwenden zu können. Im reinen HTML sind Texte nicht in ihrer Art voneinander zu unterscheiden; erst durch die Klassenvergabe zur CSS-Gestaltung ist eine Clusterung definierbar. Dies unterstützt jedoch Besucher, die auf Stylesheets verzichten, nicht bei der Erkennung von Textarten. Zur identifizierbaren Auszeichnung von typischen Daten auf einer Internetseite stehen mit HTML5 die sogenannten Mikrodaten zur Verfügung.

In seinem Entwurf dazu beschreibt das W3C die Mikrodaten-Logik als einen einfach zu definierenden Weg zur Einbettung von durch Maschinen lesbaren Daten in ein HTML-Dokument. Derzeit ist es noch nicht gesichert, dass sie als Standard in HTML5 einfließen, denn außer den Mikrodaten [i] liegt beim W3C mit RDFa [j] eine Alternative vor, sodass zwar momentan noch nicht endgültig abzusehen ist, wohin die Reise geht, aber man davon ausgehen kann, dass sich das Konzept der Mikrodaten wegen ihrer Bedeutung und Logik durchsetzen werden. In HTML5 dürfte ein mächtiger Satz an Mikrodaten einfließen. So stehen allein für die Auszeichnung einer elektronischen Visitenkarte knapp fünfzig Datentypen zur Verfügung. Mikrodaten sind stets nach dem Schlüssel-Wert-Prinzip aufgebaut, wie Listing 2 zeigt: eine Visitenkarte mit HTML5-Mikrodaten. p mit dem Attribut itemscope leitet den Datensatz ein, und die itemprop-Attribute deklarieren die standardisierten Bezeichner (Properties) zu den nachfolgenden Inhalten.

Da die Daten einer Internetseite durch die Mikrodaten klarer strukturierbar sind, ist bei deren konsequenter Verwendung von einer erleichterten Zugänglichkeit auszugehen. So bekommen maschinelle Besucher einer Seite, Screenreader und Robots Unterstützung angeboten, Texte eindeutig einordnen zu können. Speziell bei der Publizierung per Content-Management-Systemen, die solche Blöcke aus Vorlagen heraus erzeugen, sind die Auszeichnung und automatisierte Befüllung leicht umzusetzen.

Das bezüglich Barrierefreiheit oft erwähnte Attribut accesskey erfährt mit HTML5 eine wesentliche Aufwertung. War es in HTML 4 nur auf die Formularelemente input, textarea, label, legend und button sowie a und area anwendbar, kann man nun jedes HTML-Element damit valide auszeichnen. Über dieses Attribut ist ein direktes Ansteuern per Tastaturkürzel definierbar, was vor allem motorisch eingeschränkten (Tastatur-)Usern zumindest teilweise zugute kommt. Die Einschränkung auf „teilweise“ begründet sich in der Komplexität der Tastaturkürzel, die tatsächlich eine weitere Herausforderung an die Motorik darstellen und darüber hinaus zwischen den Browsern deutliche Unterschiede aufweisen. Bei manchen wie Safari reicht mit Strg eine weitere Taste in Kombination mit dem accesskey aus, beim Firefox (Alt-Shift) sowie beim Opera (Shift-Esc) sind es aber insgesamt drei Tasten, die Anwender zur Navigation gleichzeitig drücken müssen.

Fazit

HTML5 führt vieles ein, das unabhängig von der Zugänglichkeit ist, manches hat aber einen Effekt in dieser Richtung: Verbesserungen ergeben sich beispielsweise durch die vermehrten Optionen, den Aufbau einer Webseite zu strukturieren. Dies sollte Anwendern mit Einschränkungen das Surfen erleichtern, indem etwa Screenreader eher in die Lage versetzt werden, die Wichtigkeit eines Seitenbereichs zu identifizieren. Solche Elemente sind Abschnitte (section), Header-Bereich (header), footer, nav (siehe Listing 3), article sowie die Seitenleiste für Nebeninformationen (aside).

Evolution statt Revolution – so lassen sich die Neuerungen durch HTML5 bezüglich Barrierefreiheit überschreiben. Einige Verbesserungen wie die Optimierung der Formularbedienung sind tatsächlich zu identifizieren. Ein grundlegendes Konzept oder eine Art Richtlinie für die Unterstützung der Zugänglichkeit durch Mensch und Maschine ist jedoch nur ansatzweise zu erkennen. HTML5 bietet zwar die Möglichkeit, weitere neue Elemente und Attribute zum Sprachsatz hinzuzufügen, was allerdings die Weiterentwicklung dezentralisiert – mit der Gefahr eines Element- und Attributwildwuchses. Und tatsächlich kann erst die Praxis beantworten, welche neuen Barrieren sich auftun, denen selbst die, zugegeben hilfreichen, Verbesserungen durch HTML5 keine Vereinfachung entgegensetzen können.

Helmut Moritz

arbeitet als Produkt-Manager bei der 1&1 Internet AG.

Literatur

[1] Stefan Münz, Clemens Gull; HTML5 Handbuch; Poing (Franzis) 2010

Alle Links: www.ix.de/ix1106054

 <form method="post" action="#">
   <input type="text" name="a" tabindex="2"><br />
   <input type="text" name="vorwahl" tabindex="3" 
                                           placeholder="0221"><br />
   <input type="text" name="b" tabindex="1" autofocus><br />
 </form> 

 <p itemscope itemtype="http://microformats.org/profile/hcard">
   <span itemprop="fn">Max Mustermann</span><br />
   <span itemprop="street-address">Musterstraße 123</span><br />
   <span itemprop="country-name">D</span>-
   <span itemprop="postal-code">12345</span>
   <span itemprop="locality">Musterstadt</span><br />
   <span itemprop="tel" itemscope>
      <span itemprop="voice">+49 1234 567890</span><br /> 
      <span itemprop="cell">+49 4321 567890</span><br />
   </span>
   <a itemscope="email" href="mailto:#">#</a><br />
   <a itemscope="url" href="#">#</a>
 </p> 

 <nav>
   <a href="#" accesskey="h">Home</a>
   <a href="#" accesskey="a">About</a>
   <a href="#" accesskey="c">Contact</a>
 </nav> 

In der Printausgabe iX 6/2011 lesen Sie außerdem einen umfangreichen Artikel über die Neuerungen in HTML5 sowie einen zu den geplanten Websockets, der direkten Kommunikation zwischen Browser und Server. (hb)