Barrierefreiheit in HTML5

Aus Winfwiki

1 Einleitung

1.1 Problemstellung

Nach mittlerweile 14 Jahren und noch kommenden weiteren geschätzten 11 Jahren ^[1] seit der Verabschiedung des HTML-Standards in der Version 4 kündigt sich für 2022 die fünfte Version an.

In HTML5 sind einige neue Elemente in den Standard aufgenommen worden, welche eine semantische Bedeutung besitzen. Hiermit werden weitere semantische Bedeutungen, die bisher nur visuell oder sprachlich erkennbar waren, maschinenlesbar gemacht. Diese Erweiterungen haben großes Potential, um eine enorme Verbesserungen für die sog. Search-Engine-Optimization (SEO) und auch für die Barrierefreiheit zu ermöglichen.

Es gibt mittlerweile viele Erweiterungen, die als Teil von HTML5 verstanden werden, obwohl sie es eigentlich nicht sind. So wird z.B. MicroData oder Geo-Location als Bestandteil von HTML5 gesehen.

Leider unterstützen noch nicht alle Browser HTML5 und auch das World-Wide-Web-Consortium (W3C) rät von der Nutzung der neuen Elemente in Produktivumgebungen ab ^[2].

Viele Betreiber sind der Meinung, dass Barrierefreiheit nur dazu dient blinden Menschen den Zugang zu ihrer Internetseite zu ermöglichen und sehen keinen Sinn darin etwas mehr Mühe in die Konzeption ihres Internetauftritts zu investieren. Barrierefreiheit beschränkt sich aber nicht nur auf blinde Menschen und die Gruppe der eingeschränkten Personen ist ein wertvoller Kundenstamm, der nicht zu vernachlässigen ist.

1.2 Zielsetzung und Aufbau der Arbeit

In dieser Arbeit soll auf die neuen Elemente von HTML5 und ihre semantische Bedeutung eingegangen werden. Außerdem soll eine Abgrenzung zwischen dem eigentlichen Standard, wie er vom World-Wide-Web-Consortium (W3C) oder von der Web Hypertext Application Technology Group (WHAT-WG) verstanden wird, und dem Marketingbegriff HTML5 unterschieden werden. Nachfolgend sollen Beispiele für die sinnvolle Verwendung der neuen Elemente sowie Randtechnologien erarbeitet werden. Im Fazit wird der Nutzen der neuen Elemente gegen die Kompatibilitätsprobleme mit alten Browsern abgewogen und eine Empfehlung für oder gegen die Nutzung von HTML5 formuliert.

1.3 Abgrenzung

Die Elemente und Techniken, die für die Semantik eines Dokumentes bzw. für die Barrierefreiheit keine Bedeutung haben werden in dieser Arbeit nicht berücksichtigt oder nur oberflächlich behandelt.

2 Begriffsdefinitionen

2.1 HTML(5)

HTML5 ist die Weiterentwicklung bzw. Überarbeitung der gängigen (X)HTML Standarts, mit Blick auf eine Applikationsbezogene Internet- und Browsernutzung. Sie geht dabei von der durch die W3C angestrebten XML basierten Entwicklung zurück zur HTML als Basis für weitere Überlegungen. Eine XML Syntax ist dennoch erwünscht. Diese trägt den Namen XHTML5.

2.2 Barrierefreiheit

Unter Barrierefreiheit wird gemeinhin die Optimierung und Anpassung von Webseiten verstanden, die zum Ziel hat, Menschen mit Behinderungen und motorischen, wie visuellen Einschränkungen den Zugang zu den angebotenen Inhalten zu erleichtern, bzw. in einigen Fällen überhaupt erst zu ermöglichen. Im Zuge dieser Optimierungen verbessert sich allerdings auch die Nutzbarkeit für uneingeschränkte Nutzer und ermöglicht über eine Standardisierung der Vorgänge und syntaktischen Vergehensweise eine allgemeine Vereinfachung der Informationsbeschaffung für ältere und mit der Webtechnologie weniger vertraute Nutzer.

2.3 Organisationen

2.3.1 W3C

Das World Wide Web Consortium (kurz: W3C) ist das Gremium zur Standardisierung der das World Wide Web betreffenden Techniken und wurde im Oktober 1994 am MIT Laboratory for Computer Science in Cambridge (Massachusetts) von Tim Berners-Lee gegründet. Vorsitzende sind Tim Berners-Lee und der CEO Jeffrey Jaffe. Das W3C entwickelt technische Spezifikationen und Richtlinien mittels eines durchgehend entwickelten Prozess, um maximalen Konsens über den Inhalt eines technischen Protokolls, hohe technische und redaktionelle Qualität und Zustimmung durch das W3C und seiner Anhängerschaft zu erzielen. Selbsterklärtes Ziel ist es, das Web zu seinem vollen Potential zu verhelfen.^[3]

2.3.2 WHATWG

WHATWG steht für "Web Hypertext Application Technology Working Group" Die WHATWG wurde 2004 von Apple, Mozilla Foundation und Opera Software zum Zweck der Weiterentwicklung von HTML gegründet und erfreut sich laut eigenen Angaben einer wachsenden Community ^[4]. Derzeit arbeitet die WHATWG neben der Entwicklung neuer HTML Standarts und Web Application APIs, an Projekten wie: Web Workers, Web Storage, Web Sockets API und Server-Sent Events.

3 Grundlagen

3.1 HTML5-Geschichte & Idee

Da die Gründer der WHATWG den Entwicklungsfokus des W3C auf XHTML als zu weit von der, zu der Zeit, „aktuellen Internet und Browserrealität“ ^[5] sahen, stellten sie einen „Web Applications 1.0“ genannten Arbeitsentwurf zusammen, der eine Weiterentwicklung von HTML als Basis hatte. Dieser Entwurf wurde später als HTML5 bekannt und gängig. Im Herbst 2006 wurde eine W3C Arbeitsgruppe zu HTML5 gegrüdet, die ihre Arbeit im Frühjahr 2007 aufnahm und die von der WHATWG stammenden Vorschläge unter der bekannten „Konsens Arbeitsweise“ fortführte. Zu erwähnen sei hier, dass das W3C die Entwicklungen zu XHTML2.0 keines Wegs fallen ließ, sondern beide Entwicklungen parallel liefen. Da die Inhalte von HTML5 allerdings auch als XML Syntax umgesetzt werden sollten, kam die Bezeichnung XHTML5 auf. Dies stellt allerdings keine Weiterführung der Entwürfe zu XHTML2.0 dar, sondern eine eigenständige Umsetzung der HTML5 Standarts, die zu HTML4.01 und XHTML1.0 abwärts kompatibel sein sollte.

Die WHATWG hat allerdings nicht aufgehört, weitere eigene Entwürfe und Ideen zu entwickeln. So laufen von beiden Gruppierungen Entwicklungen parallel, wobei die HTML5 Spezifikationen des W3C nach Aussage der WHATWG nur den Teil der stabileren WHATWG-HTML Standarts enthalten.^[6]

Die Neuentwicklungen in HTML5 beinhalten unter anderem, aber nicht ausschließlich, neue Elemente zur semantischen Auszeichnung von Blogs und Zeitungsartikeln, Navigationsbereich, Dialogen, Bildunterschriften und Multimediadaten, die in HTML bis dato über das globale Element div eingebunden und über class und id näher bestimmt werden. Einige Änderungen betreffen auch Formulare und erweitern bestehende Attribute um Funktionalitäten oder führen gänzlich neue Attribute für Elemente ein. Als Beispiel seien hier die Attribute min und max zur Festlegung von Minimal- und Maximalwerten innerhalb des input-Elements genannt.

Es sollen allerdings nicht nur neue, zusätzliche Elemente entstehen, sondern auch Elemente entfernt werden. Als Beispiel seien hier Frames (mit Ausnahme von Iframes) genannt.

Es stehen noch andere Element und Funktionalitäten auf der „nicht mehr gewünscht“ Liste, allerdings würde ein weglassen selbiger zu Problemen bei der Abwärtskompatibilität, sowie in der Funktionalität von WYSIWYG-Editoren führen.^[7]

Daher sollen zwei unterschiedliche Spezifikationen herausgegeben werden. Zum einen für Browserhersteller, die noch die alten Elemente enthält, sowie eine für Webentwickler, in der sie bereits nicht mehr aufgeführt werden sollen.

Der derzeitige Umfang von HTML5 und die im "Volksmund" hinzugerechneten Randtechnologien werden in der nebenstehenden Grafik veranschaulicht.

Abbildung 1: HTML5-Technologien

3.2 Barrierefreiheit

„Barrierefrei sind […] Systeme der Informationsverarbeitung […], wenn sie für behinderte Menschen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und nutzbar sind.“ (Behindertengleichstellungsgesetz)

Eine barrierefreie Webseite ermöglicht es auch Menschen mit Behinderungen und cognitiven Einschränkungen auf die angebotenen Inhalte zu zu greifen. Obwohl viele Firmen und Institutionen, die eine barrierefreie Webseite betreiben, dies unter dem Aspekt des Imagegewinns durch soziales Engagement und “Political Correctness” kommunizieren, darf man den wirtschaftlichen Aspekt einer solchen Webseite nicht ausser acht lassen, denn eine barrierefreie Internetpräsenz zu betreiben bedeutet eigene Angebote für eine nicht zu unterschätzende Menge zusätzlicher Nutzer – und im Sinne eines Unternehmens potentieller neuer Kunden – zugänglich zu machen.

Zahlen und Fakten:

Allein in Deutschland leben laut Bundesamt für Statistik (letzte Erhebung 2009) 7,1 Millionen Schwerbehinderte und Kriegsinvaliden mit einem Behinderungsgrad von mehr als 50%. Bei den unter 15 Jährigen liegt der Anteil dabei bei knap über 120.000 und die der Personen über 65 bei knapp 3,86 Millionen. Somit werden mehr als 3 Millionen Menschen im erwerbsfähien Alter – nur in Deutschland alleine – bei der Planung der meissten Webseiten nicht als Zielgruppe berücksichtigt. In Europa sind dies ca 39 Millionen Menschen.

Laut Dave Wilton von der britischen Legal&General würde das Unternehmen, wenn nur 1% der erwerbsfähigen, britischen Menschen mit Behinderung bei ihnen eine Versicherung über £300 abschließen würden, eine Umsatzsteigerung von £27 mio erzielen. ^[8]

Doch nicht nur schwerbehinderte Menschen werden bei der Erstellung von Webseiten oft nicht berücksichtigt, sondern auch Menschen, die unter weniger schwerwiegenden Einschränkungen leiden. Beispielhaft seien hier die 8% der Männer und 0,5% der Frauen genannt, die unter Farbsehschwächen leiden. Dies wären in Deutschland alleine wiederum ca. 3,2 Millionen Männer und rund 200.000 Frauen.

Nicht zu vernachlässigen sind auch die Resultate des demagogischen Wandels. In einer älter werdenden Gesellschaft muss auch der Teil der Bevölkerung, der nicht mit der rasanten Entwicklung der Informationstechnologie aufgewachsen ist, bei der Planung einer Internetpräsenz berücksichtigt werden. Laut Statistischem Bundesamt nutzten bereits 2008 mehr als 15 Millionen Menschen zwischen 45 und 65 und 3,8 Millionen Menschen über 65 Internetangebote zu privaten Zwecken.. Das Nutzungsverhalten liegt dabei für Kommunikation bei ca 89 bzw 85%, E-Commerce bei 48 bzw 33% und E-Government bei 59 bzw 41%. ^[9]

Wie wird eine Webseite barrierefrei?

Damit eine Webseite barrierefrei ist, müssen laut W3C folgende Dinge erfüllt sein:

Die Inhalte müssen

• wahrnehmbar sein – Sie müssen den Benutzern so präsentiert werden, dass diese sie wahrnehmen können
• bedinbar sein – Benutzerschnittstellen und Navigation müssen bedienbar sein
• verständlich sein – Informationen und Benutzerschnittstellen müssen verständlich sein
• robust sein – Inhalte müssen von einer großen Auswahl an Benutzeragenten und assistierender Techniken interpretiert werden können.

Das heißt im Detail, dass alle Elemente einer Webseite so designed sein müssen, dass alternative Ausgabe- und Bedienmöglichkeiten zur Verfügung stehen und die Inhalte klar und verständlich formuliert und erkennbar sein müssen. Beispiele hierfür wären textbasierte Ausgaben von Audiomaterial oder andere geeignete Visualisierungsmöglichkeiten, alternative Eingabemöglichkeiten wie eine Bildschirmtastatur, Touchscreens, Skalierbare Webelemente und der gleichen. Desweiteren sollte bei der Farbauswahl darauf geachtet werden, Kombinationen zu wählen, die bei den bekannten Sehstörungen nicht zu einer Grau-in-Grau Darstellung führen. ^[10] Eine derartige Optimierung des Internetauftritts kommt allerdings nicht nur behinderten oder cognitiv eingeschränkten Menschen zu gute. Beispielsweise ermöglichen Skalierbarkeit und alternative Bedienelemente auch eine bessere Darstellung und Usability mit neuen Multimediageräten, wie Smartphones oder Tablet PCs und bieten damit auch einen Zusatznutzen für uneingeschränkte Besucher.

3.3 WCAG 2.0

Die Web Content Accessibility Guidlines (kurz WCAG, dt. Richtlinien für barrierefreie Webinhalte) sind eine Sammlung von Empfehlungen des W3C, deren Befolgung bei der Entwicklung einer Webseite dafür sorgt, die angebotenen Inhalte für Menschen im allgemeinen nutzbarer und für Menschen mit Behinderungen im speziellen barrierefrei zugänglich zu machen. Die dabei berücksichtigten Behinderungen beinhalten „Blindheit und Sehbehinderung, Gehörlosigkeit und nachlassendes Hörvermögen, Lernbehinderungen, kognitive Einschränkungen, eingeschränkte Bewegungsfähigkeit, Sprachbehinderungen, Photosensibilität und Kombinationen aus diesen Behinderungen“^[11]. Die WCAG berücksichtigen dabei vorhandene Techniken, sowie gängige Eingabehilfe und andere technische Assistenten aus den Bereichen der Darstellung und Steuerung, sowie gängiger Authentifizierungsmechanismen (bspw. CAPTCHA) und Hinweise für bessere Verständlichkeit der Inhalte.

Die WACG sind dabei als Sammlung von Erfolgskriterien verfasst, die zunächst als technik-unabhängige, prüfbare Aussage („Statement“^[12]) formuliert sind, jedoch jeweils Verweise zum Verständnis sowie Verweise zu technik-spezifischen Lösungen (z.B. HTML, Flash udgl.) sowie eine Einstufung des entsprechenden Statements in eine Konformitätsstufe beinhalten.

Die WCAG Konformitätsstufen, die eine Webseite erreichen kann sind A, AA und AAA, die jeweils vorraussetzen, dass alle Erfolgskriterien, die diesen und den vorhergehenden Stufen zugeordnet sind erfüllt sind, bzw eine alternative Version der Webseite zur Verfügung gestellt wird, die diese erfüllt.

Die erste Version der WCAG wurde am 05.05.1999 als Empfehlung des W3C veröffentlicht und beinhaltete Empfehlungen zu den Techniken HTML, CSS, SMIL und MathML. Die Weiterentwicklung zu WCAG 2.0 beinhaltet die Verwendung neuerer und modernerer Techniken, sowie präziser ausformulierte „Statements“ (s.o.), die dadurch besser, auch maschinell testbar sind. Darüber hinaus sollte ein einheitlicher Webstandart entwickelt werden. „WCAG 2.0 was developed in coordination with international efforts to harmonize on a single standard for Web content.“ ^[13]

Die Aktuelle Version der WCAG 2.0 wurde am 11.12.2008 veröffentlicht. Die aktuelle Version der deutschen Übersetzung ist vom 29.10.2009.

Auf Basis der Empfehlungen des WCAG 1.0 wurde 2002 von der Bundesrepublik Deutschland eine entsprechende Gesetzgebung verabschiedet.

4 Technologien / Umsetzung

4.1 WAI-ARIA

WAI-ARIA steht für Web Accessibility Initiative's Accessible Rich Internet Applications und ist eine Spezifikation, die Menschen mit Behinderungen den Zugriff auf Webinhalte vereinfachen soll. Dynamische Inhalte und selbsterstellte Programmelemente mit Einbindung von JavaScript, CSS und Ajax stellen dabei eine besondere Hürde dar, da diese von assistiven Technologien, wie bspw. Screenreadern, nicht ohne weiteres erkannt werden können und oft eine Bedienung ohne Maus nicht möglich ist. WAI-ARIA definiert hierfür eine Reihe semantischer Elemente, um diese Widgets zu beschreiben und den Aufbau für assistive Technologien zugänglich zu machen.^[14]
Die Elemente dieser Spezifikation gliedern sich in:

• Rollen
• Zustände
• Eigenschaften
• Live-Regionen

Eine Rolle legt den Typ eines Elementes fest und wird von assistiven Technologien genutzt, um den Zugriff auf Widgets und den strukturellen Aufbau der Seite zu ermöglichen^[15]. Die Zustände und Eigenschaften dienen zur Beschreibung des Elementes und ermöglichen eine dynamische Ein- und Ausgabe (z.B. Screenreader und Diktatsoftware), sowie die Erkennung und Manipulation von Attributen (z.B. diasbled, hidden, invalid, selected, etc.). Live-Regionen kennzeichnen Elemente, die sich während der Laufzeit ändern und ermöglichen einen entsprechenden Hinweis.
Der Zugriff auf die semantischen Elemente kann direkt über das Document Object Model (DOM) erfolgen. WAI-ARIA sieht für die Nutzung jedoch das accessibility Application Programming Interface als definierte Schnittstelle vor.^[16]

4.1.1 Rollen

Damit assistive Technologien den Zugriff auf komplexe Webinhalte ermöglichen können, muss die Semantic hinter dem strukturellen Aufbau und den verwendeten Komponenten zugänglich sein. Für eine anwendbare Navigation und Bedienung der verfügbaren Elemente, wird diesen eine Rolle zugewiesen, welche den Typ des Steuerelementes definiert und während der Laufzeit nicht geändert werden dürfen. Die HTML5-Elemente, die mehrere Rollen unterstützen, müssen in diesem Fall entfernt und neu erzeugt werden.^[17] Festgelegt sind eine Reihe abstrakten Rollen, von denen spezifische Rollen abgeleitet sind (siehe auch http://www.w3.org/TR/wai-aria/rdf_model.svg ). Die abstrakten Rollen dienen nur der Vererbung. Für die Verwendung im Quellcode sind die spezifischen Rollen vorgesehen.
Jede Rolle besitzt die folgenden Informationen^[18]:

• informative Beschreibung
• hierarchische Informationen zu verwandten Rollen
• Kontext der Rolle
• Referenzen und verwandte Konzepte in anderen Spezifikationen
• Anwendung der Web Ontology Language (OWL) zur Bereitstellung einer Typenhierarchie für die semantische Vererbung
• unterstützte Zustände und Eigenschaften der Rolle

Die Angabe der Rolle erfolgt mit role="NameDerRolle" und sorgt für eine Zuweisung der zur Rolle gehörenden Zustände und Eigenschaften.
Eine besondere Untergruppe der Rollen sind die document landmarks. Document Landmarks beziehen sich auf den Aufbau der Seite und sind Orientierungspunte, die eine schnelle und einfache Navigation möglich machen (z.B. banner, navigation, main, search). Diese Orientierungspunkte ermöglichen bspw. ein direktes Springen zur Navigation oder Suche ohne durch alle Elemente durchgehen zu müssen^[19].

4.1.2 Zustände und Eigenschaften

Die Zustände und Eigenschaften eines Elementes dienen den assitiven Technologien zur Ermittlung, wie das Element momentan aussieht (z.B. ein Ladebalken mit aktuell 65 Prozent Fortschritt; aria-valuenow="65") und welche Operationen auf das Element angewendet werden können. So ist eine Identifikation und Validierung von Pflichtfeldern möglich, aber auch das Ignorieren von Gestaltungselementen oder die Ermittlung von verfügbaren Operationen (z.B. sprachgesteuerte Eingabe) möglich. Ein Wechsel der Zustände und Eigenschaften wird an die assistiven Technologien weitergegeben und ermöglicht so eine Überwachung der Elemente und ggf. eine entsprechende Meldung an den Benutzer, dass z.B. deaktivierte Elemente jetzt nutzbar sind und evtl. eine Eingabe erfordern. Abhängig von der jeweiligen Rolle besitzen die Elemente spezifische Zustände und Eigenschaften, die mit aria-NameZustandEigenschaft="Wert" angegeben werden^[20].

4.1.3 Live-Regionen

Live-Regionen kennzeichnen Bereiche bzw. Elemente, bei denen sich die Inhalte während der Laufzeit mit hoher Wahrscheinlichkeit ändern, ohne dass diese den Fokus haben. Mit Hilfe der Angabe aria-live="off/polite/assertive" ist es assistiven Technologien möglich den Benutzer auf die Änderung aufmerksam zu machen, ohne den Fokus vom aktuellen Element zu nehmen bzw. den User bei der momentanen Tätigkeit zu unterbrechen oder zur Handlung zu zwingen, ihn jedoch zum Eingreifen auffordern können^[21].
So wäre es beispielsweise bei Web-basierten Mailclients möglich, den User über den Eingang einer neuen Nachricht zu informieren, ohne ihn bei beim Lesen oder Schreiben einer anderen Nachricht zu unterbrechen. Ein weitere Beispiele sind die Aktualisierung eines Newstikers und der Hinweis auf wichtige Meldungen oder aufgetretene Fehler bei z.B. direter Validierung von Formularfeldern gegen Datenbanken.

• 'Off' ist der Standardwert von aria-live und sorgt dafür, dass Änderungen nicht berücksichtigt werden, es sei denn das Element besitzt gerade den Fokus.
• 'Polite' steht für eine Aktualisierung im Hintergrund und bewirkt, dass der Benutzer zu einem günstigen Zeitpunkt über die Änderung informiert wird (bspw. nach Abschluss einer Eingabe).
• 'Assertive' ist die höchste Priorität und veranlasst assistive Technologien dazu, den Benutzer direkt zu informieren, da sonst die aktuelle Tätigkeit ggf. nicht korrekt abgeschlossen werden kann oder zu (Folge-)Fehlern führt.

4.1.4 Umsetzung

Die bei WAI-ARIA definierten Rollen, Zustände und Eigenschaften werden direkt im jeweiligen HMTL-Tag mit angegeben. Ein Element kann je nach Verwendungszweck eine oder mehrere Rollen unterstützen.

4.1.4.1 Navigation

Abbildung 2: Schema Landmarks

Personen, die keine Maus nutzen können und auf die Navigation per Tastatur angewiesen sind, konnten bisher nicht alle Elemente erreichen bzw. bedienen, da nicht alle Elemente per 'durchtabben' den Fokus bekommen konnten. WAI-ARIA erweitet die Nutzung des tabindex-Attributes auf alle sichtbaren Elemente und ermöglicht so eine anwenderfreundliche Navigation ohne auf eine Maus angewiesen zu sein. Das tabindex-Attribut kann auf einen Wert zwischen -1 und 32768 gesetzt werden, wobei -1 und 0 Sonderfälle sind.

• Hat ein Element einen Tabindex von 0, so steht es in relativer Position zu seiner Position im Dokument.
• Werte zwischen 1 und 32768 stellen die Position des Elementes innerhalb der Tabreihenfolge dar.

Die Reihenfolge muss nicht bei 1 beginnen, braucht nicht fortlaufend zu sein und kann eine variable Schrittweite besitzen.

• Ein Tabindex von -1 ermöglicht das Setzen des Fokus mit der JavaScript-Methode element.focus(), um beispielsweise eine Navigation per Cursortasten zu ermöglichen oder Tastenkürzel verfügbar zu machen.

Die Landmark-Rollen bieten darüber hinaus die Möglichkeit, den Inhalt in entsprechende Bereiche aufzuteilen. Diese Orientierungspunkte helfen dem Benutzer, um schnell zu bestimmten Inhalten zu gelangen und ermöglichen eine komfortable Navigation bzw. Bedienung der Seite (siehe Abbildung 2).

4.1.4.2 Tabs

Abbildung 3: Umsetzung Tabs

Um Tabs oder Registerkarten in einer Webapplikationen nutzen zu können, muss ein entsprechendes Widget erstellt werden. Dieses Widget besteht aus einer Kombination von div-Containern, die per JavaScript entsprechend sichtbar gemacht oder versteckt werden, sowie einer Liste der Kartenreiter. Für assistive Technologien ist der Zusammenhang der einzelnen Elemente nicht ohne Hilfe ersichtlich. Durch entsprechende Vergabe der Rollen, Zustände und Eigenschaften kann das Widget von der assistiven Technologie erkannt werden und ermöglicht so eine Nutzung des Features (siehe Abbildung 3).

4.1.4.3 Trees

Abbildung 4: Umsetzung Tree

Folgendes Beispiel zeigt, wie WAI-ARIA bei einem Widget für eine Baumstruktur angewendet werden kann, damit assistive Technologien bei der Bedienung genutzt werden können. Die einzelnen treeitem-Elemente sind unter der tree-Rolle zusammengefasst und entsprechend mit 'group' gebündelt. Das Attribut aria-expanded gibt an, ob der Zweig geöffnet ist oder nicht (siehe Abbildung 4).

4.1.4.4 Formulare

Abbildung 5: Umsetzung Formular

Ein Formular beinhaltet in der Regel ein oder mehrere Pflichtfelder, die dafür sorgen, dass das Formular auch verarbeitet werden kann. Um die Gültigkeit der Engaben zu prüfen, findet eine entsprechende Validierung statt. Diese wird häufig schon vor dem Versand des Formulars, also nach oder auch schon während der Eingabe durchgeführt. Muss die Eingabe einem Muster entsprechen, bieten sich reguläre Ausdrücke an und für eine Prüfung gegen einen großen Datenbestand kann AJAX genutzt werden. Das Ergebnis der Validierung wird dem Benutzer optisch kenntlich gemacht, indem z.B. die Felder farblich hervorgehoben werden oder eine entsprechende Grafik oder Text neben dem Element angezeigt wird. AJAX bietet sich ebenso für dynamische Formularbereiche an bzw. für Elemente, die erst während des Ausfüllens ihren Inhalt abhängig von vorherigen Eingaben beziehen. Sowohl die Validierung, als auch dynamische Formularelemente sind typische Live-Regionen. Folgende Abbildung zeigt die Umsetzung von WAI-ARIA bei einem Formular mit Pflichtfeldern und einer Meldung, wenn durch eine fehlgeschlagene Validierung ein Fehlerhinweis im DOM hinzugefügt wird (siehe Abbildung 5).

4.2 MicroData / MicroFormat

Microdata wurde entwickelt, um den Webcontent mit Zusatzinformationen versehen zu können und ihn damit für Maschinen verständlich zu machen. Browser, Suchmaschinen und assistive Technologien werden so in die Lage versetzt, die Bedeutung des Inhaltes zu erfassen und zu verarbeiten. So können explizit Informationen zu bspw. Personen, Organisationen, Produkten, Bewertungen, Events, Standorten, etc. hinterlegt werden, die von Programmen ausgelesen und genutzt werden kann. Beispiele hierfür sind die Übernahme von Kontaktinformationen zu einer Person/Organisation ins persönliche Adressbuch, ein direktes Hinzugügen von Events in den Terminplaner oder eine Hilfe für den Online-Einkauf durch Nutzung von Produktinformationen und Bewertungen der Produkte/Anbieter. Zur Bereitstellung von Microdata gibt es verschiedene Technologien, wie z.B. RDFa (Resource Description Framework in attributes), Microformats oder HTML5-Microdata^[22].
RDFa nutzt unter anderem XML-Namensräume und wurde für die XHTML-Welt konzipiert, wodurch es nicht in normalem HTML verwendet werden kann. Ein Entwurf zur Nutzung von RDFa in HTML wird momentan erstellt, jedoch sind hierfür größere Anpassungen in HTML5 notwendig, weshalb eine Realisierung fraglich ist.^[23] Microformats sind Datenstrukturen auf Basis von HTML-Syntax und sind daher bei HMTL, XHTML und HTML5 gleichermaßen anwendbar.\\ Das HTML5-eigene Microdata-Format erweitert die HTML-Elemente um bestimmte Attribute und Eigenschaften, durch die Elementgruppen zu Objekten zusammengefasst werden können. HTML5-Microdata war jedoch nur kurzzeitig Bestandteil der HTML5-Spezifikation, bevor es in eine eingene Spezifikation ausgelagert wurde. Zur Zeit befindet sich HTML5-Microdata noch in der Entwurfsphase.

Abbildung 6: Google-Suche: HTC

Abbildung 7: Google-Suche: Shopping Center Essen

Unterstützt wird auch HTML5-Microdata bereits jetzt von der Suchmaschinine Google für die Erstellung der sogenannten 'Rich Snippets'. 'Snippets' werden bei der Inexierung der Webseiten aus dem Inhalt erstellt und sind die Kurzinfos, die dem Benutzer der Suchmaschine zu den gefundenen Seiten in der Trefferliste angezeigt werden. Enthält die Seite Zusatzinformationen in den oben genannten Formaten, so werden aus den Daten zu Firmen, Produkten, Standorten, etc. die 'Rich Snippets' erzeugt ^[24]. Sucht der Benutzer z.B. nach einem Produkt, so können durch die gesammelten 'Rich Snippets' auch direkt Informationen zu Bewertung, Preis und Anbieter geliefert werden (siehe Abbildung 6).
Bei der Suche nach einer Lokation erhält der Benutzer neben der URL Informationen zu Standort, Bewertung, Adresse und Kontat (siehe Abbildung 7).
Für die Umsetzung werden hier HTML5-Microdata und Microformats betrachtet.

4.2.1 Umsetzung mit HTML5-Microdata

HTML5-Microdata ermöglicht die Erstellung von Objekten, indem HTML-Elemente durch das itemscope-Attribut zu einer Elementgruppe bzw. einem Item zusammengefasst werden. Der Typ des Items wird über das itemtype-Attribut festtgelegt, welches als Wert die URL der Spezifikation enthält, welche zur Validierung des Objetes dient. Die Eigenschaften des Items bilden die HTML-Elemente in der Gruppe, die mit dem itemprop-Attribut versehen sind. Diese haben als Wert den Inhalt des Elementes bzw. bei <a> den Wert von href oder bei <img> den Wert von src. Wenn in der Definition des itemtype enthalten, können die Objekte als Eigenschaft auch weitere Objekte enthalten^[25].

<div itemscope itemtype="http://data-vocabulary.org/Person">
        Mitarbeiterprofil:<br />
        <img itemprop="photo" src="Mustebild.jpg" /><br />
        Name: <span itemprop="name">Max Mustermann</span><br />
        Beruf: <span itemprop="title">Musterberuf</span><br />
        Abteilung: <span itemprop="role">Musterabteilung</span><br />
        Firma/Tochtergesellschaft: <span itemprop="affiliation">Muster GmbH</span><br />
        URL: <a href="http://www.beispiel.de" itemprop="url">www.beispiel.de</a><br />
        Adresse:<br />
        <span itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address">
                Strasse: <span itemprop="street-address">Musterstr. 123</span><br />
                PLZ: <span itemprop="postal-code">12345</span><br />
                Ort: <span itemprop="locality">Musterstadt</span><br />
                Bundesland: <span itemprop="region">NRW</span><br />
                Land: <span itemprop="country-name">Deutschland</span>
        </span>
</div>

4.2.2 Umsetzung mit Microformats

Microformats sind definierte Proflie mit festgelegten Eigenachaften für die zu beschreibenden Objekte, wie bspw. Personen, Events, Produkte oder Reviews. Die Entwicklung erfolgt durch die Community von microformats.org auf Basis bestehender HTML-Syntax. Für die Umsetzung werden class und rel -Attribute genutzt, über die die Datenstrukturen mit Hilfe festgelegter HTML-Elemente definiert sind. Microformats sind fest definiert und können nicht selbstständig erweitert werden, sind aber in HTML4, XHTML und HTML5 einstetzbar^[26]. Die Kompatibilität der einzelnen Microformats muss bei HTML5 jedoch vorher duch den Entwickler geprüft werden, denn das Microformat 'Vote Links' für eine Abstimmung nutzt bspw. das rev-Attribut, welches in HTML5 nicht mehr gültig ist^[27].
Bereits fertig definierte Spezifikationen sind z.B. Events mit hCaledar und Personen/Organisationen mit hCard. Noch in der Entwicklung, aber u.a. bereits von Google unterstützt, sind bspw. Reviews mit hReview, Produkte mit hProduct und Rezepte mit hRecipe.^[28]

4.2.2.1 hCalendar

hCalendar ist eine 1:1 Umsetzung des iCalendar (RFC 2445) VEVENT für sematisches HTML und kann von Anwendungen ausgelesen und weiterverarbeitet werden (z.B. Übernahme in den Terminplaner). Dieses Element repräsentiert einen Termin / ein Event und wird mindestens durch Angabe der Attribute für das Startdatum 'dtstart' (ISO Datum) und der Beschreibung 'summary' erstellt. Zusätzlich können beispielspweise noch das Enddatum 'dtend', der Ort 'location' und eine Internetadresse 'url' angegeben werden. Um eine für Menschen lesbare Darstellung des ISO Datums zu erreichen, kann das <abbr>-Element genutzt werden. Hier wird das title-Attribut als Wert verwendet und nicht der Inhalt des Tags^[29].

<div class="vevent">
        <a class="url" href="http://www.beispiel.de/workshops/html5/">
                http://www.beispiel.de/workshops/html5/
        </a>
        <span class="summary">HTML5 Workshop</span>: 
        <abbr class="dtstart" title="2011-01-10">10.</abbr> bis
        <abbr class="dtend" title="2011-01-14">14.01.2011</abbr> im 
        <span class="location">Musterhotel XYZ in Musterstadt</span>
</div>

4.2.2.2 hCard

hCard ist eine 1:1 Umsetzung der vCard (RFC 2426) für semantisches HTML und kann abhängig von den enthaltenen Angaben für diverse Zwecke genutzt werden, wie bspw. Übernahme ins Adressbuch, Kontaktaufnahme per E-Mail, Post,Telefon oder Instant Messenger. Dieses Element repräsentiert eine Person/Organisation unter Mindestangabe des vollständigen Namens 'fn' (Full Name) und der Namensbestandteile. Die Namensbestandteile werden unter 'n' (Name) als Unterattribute 'family-name', 'given-name', u.a. zusammengefasst. Die Namensbestandteile müssen nicht einzeln angegeben werden, wenn 'fn' nur aus 2 Zeichenketten besteht ('Max Mustermann' oder 'Mustermann, Max'). Sind die beiden Zeichenketten nur durch ein Leerzeichen getrennt, dann ist die 1. Zeichenkette der Vorname 'given-name' und die 2. der Nachname 'family-name'. Endet die 1. Zeichenkette mit einem Komma, findet die Zuweisung umgekehrt statt. In dem Fall, dass 'fn' und 'org' gleich sind, werden die Daten als Organisation und nicht als Person behandelt^[30].

<div class="vcard">
        <span class="fn">Max Mustermann</span>
        <div class="org">Muster GmbH</div>
        <a class="email" href="mailto:max.mustermann@muster.de">max.mustermann@muster.de</a>
        <div class="adr">
                <div class="street-address">Musterstr. 123</div>
                <span class="postal-code">12345</span>
                <span class="locality">Musterstadt</span>, 
                <span class="region">NRW</span>, 
                <span class="country-name">Deutschland</span>
        </div>
        <div class="tel">+49 (0)123 4567-890</div>
</div>

4.3 HTML5

Für die Implementierung einer reichhaltigeren und umfangreicheren Semantic stehen in HTML4 nicht genügend Elemente zur Verfügung. Um den Ansprüchen gerecht werden zu können, wurden daher immer neue Konstrukte geschaffen und Workarounds genutzt, um benötigte Strukturen abbilden zu können. Diese Vorgehensweise führte zu einem Wildwuchs, der weder einheitlich noch standardisiert ist. Zugleich steht HTML5 vor der Herausforderung, dass es es zu bestehendem Webcontent abwärtskompatibel und für zukünfitge Anforderungen erweiterbar sein muss. HTML5 bietet hierfür eine Reihe neuer semantischer Elemente, um den Webcontent strukturiert aufbauen zu können^[31]. Die neuen Elemente stellen allerdings ein Problem bezüglich der Abwärtskompatibilität dar, denn der Internet Explorer 8 und seine Vorgänger kennen die neuen Elemente nicht und machen Workarounds notwendig, um das gewünschte Ergebis zu erzielen. Für zukünftige Erweiterungen von HTML5 stellt sich die Frage, ob es sinnvoll ist, für jede neue Anforderung ein weiteres Element hinzuzufügen oder ggf. die vorhandenen Elemente über neue Attribute flexibler zu gestalten^[32].

4.3.1 Dokumentenstruktur

Betrachtet man den Quellcode von Internetseiten mit gleichem Layout, so findet man eine annähernd große Anzahl verschiedener Konstrukte und Namenskonventionen. Bereiche, wie z.B. Kopf- und Fußzeilen, Navigation, etc. sind auf fast allen Seiten zu finden. Der bisherige Mangel an HMTL-Elementen für eine Trennung dieser Bereiche führte zu einem Aufbau mit vielen ineinander verschachtelten <div>-Elementen, die über die class- und id-Attribute entsprechend kenntlich gemacht wurden. Dieser Aufbau wird mit zunehmendem Seitenumfang und Layout schnell unübersichtlich und erschwert Wartung und Anpassung. Da die Namen für die über 'class' und 'id' definierten Bereiche frei gewählt werden können, ist es für externe Software nicht möglich die Struktur des Inhalts zu erkennen. Ein <div>-Element ist nur ein Behälter, der zwar ein Design ermöglicht, aber keinen semantischen Mehrwert bietet^[33].

4.3.1.1 Elemente und Aufbau

Für eine einheitliche und klar definierte Struktur bietet HTML5 eine Reihe neuer Elemente, wie section, header & footer, nav, aside und article. Die Elemente dienen nur zur Strukturierung des Inhaltes und bieten keine neuen Funktionalitäten.^[34]

<body>
        <div id="navigationsleiste"></div>
        <div id="seite_header"></div>
        <div class="rechte_spalte"></div>
        <div id="inhalt">
                <div class="abschnitt">
                        <div class="abschnitt_header"></div>
                        <div class="artikel">
                                <p>... Text ...</p>
                        </div>
                        <div class="artikel">
                                <p>... Text ...</p>
                        </div>
                        <div class="abschnitt_footer"></div>
                </div>
                <div class="abschnitt">
                        <div class="abschnitt_header"></div>
                        <div class="artikel">
                                <p>... Text ...</p>
                        </div>
                        <div class="artikel">
                                <p>... Text ...</p>
                        </div>
                        <div class="abschnitt_footer"></div>
                </div>
        </div>
        <div id="seite_footer"></div>
</body>

<body>
        <nav></nav>
        <header></header>
        <aside></aside>
        <div id="inhalt">
                <section>
                        <header></header>
                        <article>
                                <p>... Text ...</p>
                        </article>
                        <article>
                                <p>... Text ...</p>
                        </article>
                        <footer></footer>
                </section>
                <section>
                        <header></header>
                        <article>
                                <p>... Text ...</p>
                        </article>
                        <article>
                                <p>... Text ...</p>
                        </article>
                        <footer></footer>
                </section>
        </div>
        <footer></footer>
</body>

4.3.1.2 Überschriften und Abschnitte

Zur inhaltlichen Strukturierung standen einem bisher nur die Überschriftsebenen <h1> bis <h6> zur Verfügung. Je komplexer eine Webseite wird, desto schneller ist man jedoch an dem Punkt angekommen, an dem die vorhandenen Überschriftsebenen nicht mehr ausreichen. Um dieses Problem zu lösen, wurde in HTML5 der Outline-Algrithmus implementiert. Dieser sorgt in Verbindung mit den neuen Struktur-Elementen (mit Ausnahme von <header> und <footer>) für eine Wiederverwendbarkeit der einzelnen Überschriftsebenen. In jedem dieser Elemente beginnt der Zähler wieder bei 1 und die Überschriftsebenen <h1> bis <h6> stehen eine Hierarchieebene tiefer erneut zur Verfügung^[35].

<h1>Überschrift 1</h1>
<h2>Überschrift 2</h2>
<h3>Überschrift 3</h3>

<h1>Überschrift 1</h1>
<section>
        <h1>Überschrift 2</h1>
        <article>
                <h1>Überschrift 3</h1>
        </article>
</section>

4.3.2 WAI-ARIA in HTML5

Die Web Hypertext Application Technology Working Group (WHATWG) Teile von WAI-ARIA in HTML5 integriert. Damit ist HTML5 die erste HTML-Version, die Barrierefreiheit von sich aus unterstützt. Für die gebräuchlichsten Widgets wurden mit HTML5 eigene Elemente eingeführt^[36]. So wurde z.B. für einen Fortschrittsbalken das <progress>-Tag eingeführt.
Die Umsetzung dieses Elementes musste in HTML4 noch mit einem <div>-Container erfolgen und machte die händische Zuweisung der ARIA-Rollen und -Attribute notwendig.

In HTML5 ist die Rolle des Elementes bereits festgelegt und die Attribute sind auf das entsprechende ARIA-Gegenstück gemappt und übrige Attribute werden mit einem Standardwert initialisiert. Das <progress>-Element ist bspw. der ARIA-Rolle 'progressbar' zugeordnet. Die Attribute value und max entsprechen aria-valuenow und aria-valuemax. Hier wird aria-valuemin mit Null initialisiert.

Die Anzeige beider Varianten führt zu einem identischen Resultat.

Die zugewiesenen Rollen der HTML5-Elemente sind fix und dürfen nicht explizit überschrieben werden. Eine Ausnahme bilden die unten aufgeführten Elemente, da diese verschiedene Einsatzmöglichkeiten bieten.

5 Praxisbeispiele

Die Einsatzmöglichkeiten von HTML5 sind die gleichen Bereiche, in der bisher auch schon HTML4 eingesetzt wird. HTML5 hat durch die Neuerungen auch die Chance auf mobilen Geräten verbreiteter Verwendung zu finden, als HTML4.

Der Einsatz von HTML5 an sich kann allerdings bereits eine Barriere bedeuten: Veraltete Browser, insbesondere der Internet Explorer, gehen nicht alle gleich mit den ihnen unbekannten Elementen um. Im Blog von Peter Kröner sowie in seinem Buch beschreibt der Autor, welche Probleme es bei der Verwendung von HTML5 geben kann und wie man sie lösen kann. Im IE bis einschließlich Version 8 entsteht z.B. das Problem, dass die Tags der neuen Elemente als leere Elemente im DOM angelegt werden. So würde im IE aus folgendem Code:

<nav>
    <ul>
        <li>...</li>
    </ul>
</nav>

folgende DOM-Abbildung:

<nav></nav>
<ul>
    <li>...</li>
</ul>
</nav><//nav>

Zusätzlich zu diesem Problem lassen sich die Elemente nicht per CSS formatieren.
Für diese Probleme gibt es verschiedene Workarounds. Die populärste Fehlerumgehung für den Internet Explorer ist momentan die "Anmeldung" der neuen Elemente per JavaScript, die durch Sjoerd Visscher bekannt wurde^[37]. Als Alternative hierzu können die neuen Elemente zusätzlich zu alten Techniken genutzt werden^[38] - es werden also die alten HTML4-Herangehenweisen genutzt und durch die neuen semantischen HTML5-Elemente ergänzt:

<div id="nav">
    <nav>
      <ul>
        <li>Navigationspunkt</li>
        <li>Navigationspunkt</li>
        <li>Navigationspunkt</li>
    </ul>
  </nav>
</div>

^[39] In diesem Beispiel von Peter Kröner wird eine gewöhnliche HTML4-Navigation durch das neue HTML5-Element <nav> angereichert. Diese Lösung hat den Nachteil, dass man einen Overhead in Kauf nimmt, der - je nach Seitenstruktur und -inhalt - sehr groß werden kann. Da dies den Wartungsaufwand, die Ladezeiten und damit letztendlich sowohl die Positionierung in Suchmaschinenergebnissen^[40] als auch die Usability beim Endnutzer stark negativ beeinflusst (insbesondere auf mobilen Endgeräten mit relativ langsamer UMTS-Anbindung), wird diese Lösung kaum genutzt.

Eine weitere Alternative ist die Nutzung der neuen Elemente und "Erfassung" dieser Elemente mittels universaler Selektoren^[41]. Abgesehen davon, dass diese Lösung nicht im (immer noch verbreiteten) IE6 funktioniert, bläht es das CSS einer Site auf und erschwert durch die hohe Komplexität dessen Wartung.

Die letzte Alternative nutzt die XML-Fähigkeiten der Browser aus. Konkret wird ein Namespace angelegt, der die neuen Elemente beinhaltet. Diese Lösung hat den Nachteil, dass die neuen Elemente auch nur mit diesem Namespace (also z.B. <html5:section>) genutzt werden können. Momentan nutzen zwar noch keine oder nicht viele Anwendungen (wie Screenreader oder Suchmaschinen) die neuen semantischen Elemente, aber ein Abweichen vom Standard könnte zur Folge haben, dass die semantische Bedeutung von den Algorithmen wahrscheinlich nicht erfasst werden würden bzw. im schlimmsten Fall der Inhalt in diesen Elementen vollständig ignoriert werden würde.
Aus diesem Grund ist die Nutzung der JavaScript-Lösung vorzuziehen, da das HTML dem Standard entspricht und von den verbreiteten Browsern nur der IE bei abgeschaltetem JavaScript Darstellungsprobleme verursachen könnte.
Auch der Screenreader NVDA^[42] erkennt - trotz des JS - die Inhalte in den neuen Elementen (siehe Abbildung 11).

Abbildung 11: Screenshot einer HTML5-Testseite mit eingeschaltetem Sprachbetrachter von JAWS

Lediglich die semantische Bedeutung wird (noch) nicht erkannt.
Die Nutzung dieses Workarounds bedingt allerdings, dass der Browser JavaScript unterstützt bzw. eingeschaltet hat. Der Entwickler kann zwar fehlende JavaScript-Unterstützung "abfangen" (es wird eine feste Meldung im HTML hinterlegt, welche per JavaScript entfernt wird)^[43], aber die CSS-Formatierungen werden je nach Seitenaufbau nicht oder nicht komplett durchgeführt (vgl. Abbildung 12).

Abbildung 12: Vergleich von HTML5-Inhalten im IE mit und ohne Javascript-Anmeldung der neuen Elemente

Laut Aussagen Microsofts wird der Internet Explorer in der nächsten Version (Version 9) die neuen HTML5-Elemente unterstützen^[44]. Im Folgenden werden Beispiele gezeigt oder erarbeitet, wie eine sinnvolle Verwendung der neuen Elemente aussehen könnte und welche zusätzlichen semantischen Bedeutungen für Maschinen erfassbar werden.

5.1 Allgemein

Das Grundgerüst erhält man mittlerweile von vielen im Internet verfügbaren Quellen. HTML5-Boilerplate^[45] stellt z.B. ein Grundgerüst zur Verfügung, dass sowohl das eigentliche HTML5-Grundgerüst, CSS-Resets, JavaScripte zur Unterstützung der HTML5-Elemente durch den Internet-Explorer (und Firefox in der Version 2) als auch Servereinstellungen zur passenden Auslieferung für verschiedene Browser beinhaltet. Außerdem werden verschiedene Best-Practices beachtet. Die Nutzung (und Erklärung) dieses Grundbausteins würde aber den Rahmen dieser Arbeit sprengen. Deshalb wird nur die JS-Bibliothek "HTML5 enabling script" von Remy Sharp^[46] verwendet. Dieses Script sorgt dafür, dass der IE die neuen Elemente erkennt und per CSS formatierbar macht. Es ist auf eine möglichst geringe Größe und Laufzeit optimiert. Dieses Script wird im Header einer Seite eingebaut, da diese JS-Befehle vor dem Parsen des Bodys durchgeführt werden müssen. Durch "Conditional Comments" können Teile einer Seite durch Bedingungen eingeschränkt werden. So wird hier die Script-Datei nur von IEs unter dem IE9 ausgeführt.
Als Vorlage wird eine durch den YAML-Builder^[47] generierte HTML4-Vorlage genutzt und mit weiteren bzw. neueren HTML5-Elementen und Attributen angereichert bzw. ersetzt (siehe Abbildung 13)^[48]. YAML, ausgeschrieben "Yet another Multicolumn Layout", ist ein (X)HTML- und CSS-Framework (u. A.) unter CC-Lizenz^[49] von Dirk Jesse. Die Vorteile dieses Frameworks sind im Eingangstext der Website benannt:

"Yet Another Multicolumn Layout" (kurz: YAML) ist ein (X)HTML/CSS Framework zur Erstellung moderner, flexibler Layouts auf Grundlage von float-Umgebungen. Dabei stehen ein Höchstmaß an Flexibilität für den Webdesigner und Zugänglichkeit für die Nutzer im Vordergrund.

• Ausgerichtet auf Webstandards und Barrierefreiheit
• Schlanker Framework-Kern mit zahlreichen Erweiterungsmöglichkeiten
• Robustes, flexibles Layoutkonzept (Spalten & Grid-Raster)
• Vorlagen für Typografie, Formulare, Microformate, RTL-Unterstützung usw.
• Umfassende, mehrsprachige Dokumentation

Durch die Nutzung dieser Vorlage erreichen wir durch die Verbreitung von YAML eine hohe Praxisrelevanz, gerade im Bereich der Barrierefreiheit, wie ein Auszug der Dokumentation von YAML zeigt^[50]:

Das YAML-Framework stellt ein flexibel einsetzbares Grundgerüst bereit, welches sich an den Anforderungen für barrierefreies Webdesign orientiert und die Vorteile von Webstandards konsequent nutzt. In diesem Zusammenhang möchte ich, nicht ohne ein klein wenig Stolz, auf das Redesign 2006 der Webseite Einfach für Alle verweisen. Die Webseite ist eine Initiative der Aktion Mensch und widmet sich seit vielen Jahren intensiv dem Thema Barrierefreies Webdesign. Das aktuelle flexible Mehrspaltenlayout des Jahres 2006 basiert nach Aussagen der Entwickler in großen Teilen auf YAML.

Abbildung 13: Beispiel einer HTML5-Grundstruktur mit semantischen Elementen

• Zeile 1:
  Im Gegensatz zu HTML4 hat sich der Doctype geändert. Es reicht für HTML5 nun lediglich diese kurze Form anzugeben. Diese Änderung soll auch das Ziel der WHAT-WG, die Entwicklung einfacher zu machen und überflüssige Angaben zu vermeiden, unterstreichen.
• Zeile 4:
  Während früher

  <meta http-equiv="Content-type" content="text/html; charset=utf-8" />

  angegeben werden musste, reicht nun diese kurze Variante um die Zeichenkodierung festzulegen.
• Zeile 6 - 8:
  Hier wird das bereits angesprochene JavaScript per Conditional Comments eingebunden, das dafür sorgt, dass die Internet Explorer unter Version 9 die neuen Elemente versteht.
• Zeile 17:
  Statt eines DIVs mit der ID "header", welches keinerlei durch Maschinen erfassbare semantische Bedeutung besitzt, kommt hier das neue Element <header> zum Einsatz. Hier durch wird es z.B. Screenreadern ermöglicht dem Nutzer das Vorlesen dieses - meist nur optisch oder beim ersten Besuch wichtigen - Bereiches zu überspringen. Gleichzeitig können Suchmaschinen erkennen, dass dieser Bereich etwas über die "Identität" des Auftrittes aussagt, allerdings nicht zum eigentlichen Inhalt der Seite gehört.
• Zeile 18:
  Mit diesem neuen Element, <hgroup>Markiert man die enthaltenen Überschriften als zueinander abhängig. Dieses Vorgehen sollte man bei Überschriften wählen, die zwingend zueinander gehören. In diesem Fall ist die Überschrift der ganzen Seite das Logo der Firma - mit dem Slogan als untergeordnete Überschrift. Dieses Vorgehen macht auch bei Artikeln Sinn; dort hätte der Titel eine H1, während der Untertitel die H2 darstellen würde. In der Seitenstruktur würden jeweils nur die H1 auftauchen, die Überschriften innerhalb der jweiligen hgroup wären nur bei Eintritt in diese hgroups relevant.
• Zeile 22:
  Im ursprünglichen HTML4-Entwurf war an dieser Stelle ein DIV-Container. Da der Inhalt dieses Containers ein Navigationselement ist, können wir diesen durch das neue Element <nav> ersetzen. Dies ermöglicht Screenreadern das Springen zu diesem Element.
• Zeile 31 (und 52):
  Hier gilt das gleiche wie im vorherigen Block, mit dem Unterschied dass diese Navigation Teil der Hauptnavigation der Seite darstellt. Dies wird durch das Document-Landmark-Attribut "role" kenntlich gemacht^[51].
• Zeile 32 (und 53):
  Diese Überschrift wird per CSS in den im Browser nichtsichtbaren Bereich verschoben. Sie dient dazu, dass Screenreader dem Benutzer darüber informieren, dass dies die Hauptnavigation bzw. Unternavigation darstellt.
• Zeilen 42, 43, 63, 65, 67 und 71:
  Statt semantisch unbedeutender DIV-Container werden hier <section>-Elemente aus HTML5 verwendet, die eine Zusammengehörigkeit der Inhalte kennzeichnen. In Zeile 44 (und an anderen Stellen) kommt ein
  -Container zum Einsatz, die nur für das Layout der Seite nötig sind (bzw. um fehlende CSS3-Unterstützung von älteren Browsern zu umgehen).
• Zeile 45:
  Per Document-Landmark-Attribut "role" wird dieses Formular als das Formular gekennzeichnet, welches die siteinterne Suche beinhaltet.
• Zeile 48:
  Hier wird der neue Eingabefeld-Typ "search" genutzt. Hierdurch ist für Screenreader erkennbar, dass dieses Feld ein Suchfeld darstellt. Außerdem kommt das neue Attribut "required" zum Einsatz und legt fest, dass dieses Feld ausgefüllt werden muss.
• Zeile 72 - 125:
  An dieser Stelle befindet sich der Footer der Seite. Dies wird durch das neue HTML5-Element <footer> gekennzeichnet. Da ein <footer>-Element allerdings auch mehrmals verwendet werden kann (z.B. um den Footer eines Artikels zu kennzeichnen), wird zusätzlich das Document-Landmark-Attribut "role" verwendet.
• Zeile 89 - 105:
  In diesem Beispiel befindet sich im Footer die Kontaktadresse des Seitenbetreibers. Auch diese wird semantisch mittels einer Kombination von Microdata und Microformat aufbereitet. Durch die Mischung wird erreicht, dass eine möglichst breite Palette an Programmen diese Daten nutzen kann. Das "Rich Snippets Testing Tool"^[52] von Google erkennt folgende Daten^[53]:

hcard
fn = Beispielfirma
org
organization-name = Beispielfirma
adr
street-address = Musterstraße 123
locality = Musterstadt
region = Nordrhein-Westfalen
postal-code = 12345
tel
value = +49 (0) 123 456789
tel
value = +49 (0) 123 567890
email
value = info@example.com
url = http://www.example.com/
Warning: This information will not appear as a rich snippet in search results results, because it seems to describe an organization. Google does not currently display organization information in rich snippets
Item 
Type: http://data-vocabulary.org/organization
url = http://www.example.com/ 
name = Beispielfirma 
address = Item( 1 ) 
geo = Item( 2 ) 
tel = +49 (0) 123 456789 
tel = +49 (0) 123 567890 
email = info@example.com 
Item 1 
Type: http://data-vocabulary.org/address
street-address = Musterstraße 123 
postal-code = 12345 
locality = Musterstadt 
region = NRW 
country-name = DE 
Item 2 
Type: http://www.data-vocabulary.org/geo/
latitude = 12.34 S 
longitude = 123.45 E 

Durch die Einbettung dieser Informationen in den Footer der Seite könnten in Zukunft per Screenreader oder von Google die entsprechenden Informationen sofort ausgelesen werden. Auf die Verwendung des neuen Elementes <address> wurde an dieser Stelle verzichtet, da dieses Element zur Auszeichnung der präferierten Kontaktadresse für den Inhalt gedacht ist - bei einem Blog-Posting wäre dies zum Beispiel die E-Mail-Adresse oder die URL zum Kontaktformular des Autors.

5.2 Audio / Video

Für die Einbettung von Audio- bzw. Videodaten werden in HTML5 neue Elemente zur Verfügung gestellt. Leider wurde von den Gremien kein Standard für die zu verwendenden Codecs festgelegt. Momentan positionieren sich die freien Browserhersteller (Mozilla und Opera) und Google mit WebM bzw. VP8 auf der einen Seite, während Microsoft und Apple auf das etablierte, aber patentbehaftete MPEG4 bzw. H.264 setzen. Mit der Einbettung von beiden Codecs kann aber eine hohe Abdeckung erzielt werden, zumal Microsoft für den IE9 eine WebM-Unterstützung zugesagt hat, sofern der Nutzer den entsprechenden Codec installiert hat und für einige andere Browser die kostenlose Entwicklung von H.264-Plugins angekündigt hat. Um auch ältere Browser zu unterstützen, kann ein Fallback eingebaut werden, der sich wiederum das weitverbreitete Flash-Plugin zu Nutze macht. Leider ist diese Vorgehensweise (durch die nötige Umrechnung des Inhaltes in verschiedene Formate) aufwendig. Dieser Aufwand kann aber durch die Verwendung automatisierter Systeme wie Content-Management-Systeme abgefedert werden.

Die neuen Elemente sollen Möglichkeiten zur Einbettung von Untertiteln bereitstellen, welche dann von Screenreadern vorgelesen werden können. Dieser Teil des Standards befindet sich aber noch in der Entwicklungsphase, verspricht aber einen großen Fortschritt zu bringen und hilft auch Benutzern, die nicht auf assistive Technologien angewiesen sind, da hier auch Untertitel für andere Sprachen untergebracht werden können.^[54]

Durch die fehlende Flash-Unterstützung von Apple-Geräten wie dem iPhone oder iPad werden die neuen Elemente allerdings schon heute eingesetzt. Auch Youtube experimentiert mit den neuen Elementen^[55]. Kroc Camen hat mit "Video for Everybody" einen Weg gezeigt, wie Entwickler einen abwärtskomatiblen Code schreiben können, der in einer Vielzahl von Browsern funktioniert^[56]:

<!-- first try HTML5 playback: if serving as XML, expand `controls` to `controls="controls"` and autoplay likewise -->
<!-- warning: playback does not work on iOS3 if you include the poster attribute! fixed in iOS4.0 -->
<video width="640" height="360" controls>
        <!-- MP4 must be first for iPad! -->
        <source src="__VIDEO__.MP4" type="video/mp4" /><!-- Safari / iOS video    -->
        <source src="__VIDEO__.OGV" type="video/ogg" /><!-- Firefox / Opera / Chrome10 -->
        <!-- fallback to Flash: -->
        <object width="640" height="360" type="application/x-shockwave-flash" data="__FLASH__.SWF">
                <!-- Firefox uses the `data` attribute above, IE/Safari uses the param below -->
                <param name="movie" value="__FLASH__.SWF" />
                <param name="flashvars" value="controlbar=over&image=__POSTER__.JPG&file=__VIDEO__.MP4" />
                <!-- fallback image. note the title field below, put the title of the video there -->
                <img src="__VIDEO__.JPG" width="640" height="360" alt="__TITLE__"
                     title="No video playback capabilities, please download the video below" />
        </object>
</video>
<!-- you *must* offer a download link as they may be able to play the file locally. customise this bit all you want -->
<p>        <strong>Download Video:</strong>
        Closed Format:        <a href="__VIDEO__.MP4">"MP4"</a>
        Open Format:        <a href="__VIDEO__.OGV">"Ogg"</a>
</p>

Wie in den HTML-Kommentaren beschrieben, wird zuerst versucht das neue <video>-Element zu nutzen. Der HTML5-Standard schreibt das Ignorieren sämtlicher Elemente innerhalb von <video> vor, die nicht explizit erlaubt sind (wie z.B. <source>), so dass bei neueren Browsern mit <video>-Unterstützung das <object>-Element ignoriert wird, während ältere Browser die ihnen unbekannte <video>- und <source>-Elemente ignorieren, dafür aber das <object>-Element beachten. Im <object>-Element befindet sich ein gewöhnlicher Flash-Player. Falls auch dieser nicht installiert oder unterstützt wird, kann der Browser mit Hilfe des im <object>-Element eingebetteten Bildes einen Hinweis anzeigen. Unter dem <video>-Element befinden sich Links, um das Video in verschiedenen Formaten zum Download anzubieten. Durch diese Reihe an Fallback-Mechanismen (HTML5 -> Flash -> Links) wird eine hohe Abdeckung an Browserversionen erreicht.

5.3 Blogs und Enzyklopädien

Dieses Beispiel besteht nur aus dem Content-Anteil eines Blogs oder einer Enzyklopädie. Die Seitenstruktur (wie z.B. der Vorschlag oben) werden hier nicht erneut berücksichtigt. Das folgende Beispiel könnte sich z.B. im DIV-Container mit der ID "col3_content" befinden:

<article role="article">
        <header>
                <hgroup>
                        <h1>Dies ist ein Blog-Post</h1>
                        <h2>... sogar mit Untertitel!</h2>
                </hgroup>
                Veröffentlicht am <time datetime="2011-02-08T18:00+01:00" pubdate>Dienstag, der 08.02.2011 um 18:00</time> von Martin Mustermann
        </header>
        <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. </p>
        <h2>Hat auch H2 wie der Untertitel, ist aber eine Zwischenüberschrift!</h2>
        <p>At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. </p>
        <h3>Hier ist eine Absatzüberschrift (h3)</h3>
        <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. 
        At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor</p>
        <h2>Hat auch H2 wie der Untertitel, ist aber eine Zwischenüberschrift!</h2>
        <p>At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. </p>
        <h3>Hier ist eine Absatzüberschrift (h3)</h3>
        <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. </p>
        <h2>Hat auch H2 wie der Untertitel, ist aber eine Zwischenüberschrift!</h2>
        <p>At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. </p>
        <h3>Hier ist eine Absatzüberschrift (h3)</h3>
        <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. </p>
        <h3>Hier ist eine Absatzüberschrift (h3)</h3>
        <p>Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.</p>
        <footer>
                <h2>Über den Autor</h2>
                <div class="vcard subcolumns" itemscope itemtype="http://data-vocabulary.org/Person"> 
                        <div class="c25l"> 
                                <div class="subcl"> 
                                        <img src="images/logo.jpg" alt="Foto: Martin Mustermann" class="photo" itemprop="photo">
                                </div>
                        </div>
                        <div class="c75r"> 
                                <div class="subc"> 
                                        <a href="mailto:mmustermann@example.com" class="email" itemprop="email"><span class="fn" itemprop="name">Martin Mustermann</span></a>, 
                                        auch <span class="nickname" itemprop="nickname">Musti</span> genannt, schreibt regelmäßig Artikel über irgendein Thema auf seinem Blog, 
                                        <a class="url" href="http://www.example.com" itemprop="url">www.example.com</a>. 
                                        Er lebt in <span class="adr" itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address">
                                        <span class="locality" itemprop="locality">Musterstadt</span> (in <span class="region" itemprop="region">NRW</span>)</span> 
                                        und arbeitet als <span class="title" itemprop="title">Webentwickler</span> bei <span class="org" itemprop="affiliation">Beispielfirma</span>.
                                </div>
                        </div>
                </div>
                <a href="#">Permalink</a> | <a href="#">15 Kommentare</a> | <a href="#">8 Pingbacks</a> | <a href="#">11 Tweets</a>
                <aside role="complementary">
                        <h2>Verwandte Artikel</h2>
                        <ul>
                                <li><a href="#">Verwandter Artikel 1</a></li>
                                <li><a href="#">Verwandter Artikel 2</a></li>
                                <li><a href="#">Verwandter Artikel 3</a></li>
                        </ul>
                </aside>
        </footer>
</article>

In diesem Blogbeispiel wird als Klammer um einen Beitrag das neue <article>-Element verwendet. Zusätzlich wird die gleichnamige ARIA-Rolle vergeben, da viele Browser dieses Merkmal noch nicht an Screenreader weitergeben^[57] Der Artikel bekommt einen <header>, in welchem innerhalb einer hgroup der Titel sowie Untertitel hinterlegt ist (ähnlich wie im allgemeinen Teil das Banner der Seite). Danach folgt das Veröffentlichungsdatum; hierfür wird das neue <time>-Element verwendet, dass als ein Attribut "datetime" ein standardisiertes Format (Die Zeit- und Zeitzonenangabe ist optional und bezieht sich auf UTC-Zeit) erhält, sofern der Inhalt des Elementes selbst nicht diesem Format entspricht. Das andere Attribut, pubdate, kennzeichnet diese Angabe als Veröffentlichungszeit für den nächsten höheren Artikel - in diesem Fall unser Artikel. Sofern XHTML5 verwendet wird, muss das Attribut pubdate den Wert "pubdate" enthalten.
Nach dem Header folgt der eigentliche Artikeltext. Hier können wie bisher auch schon weitere Überschriften bzw. Aufteilungen durchgeführt werden. Nach diesem Teil folgt der <footer>, in welchem zusätzliche Informationen zum Artikel (wie z.B. Metadaten) hinterlegt werden können. In diesem Beispiel wird mittels einer Mischung von Microdata und Microformats eine Kurzvorstellung des Autors durchgeführt. Danach folgen einige typische Blog-Angaben wie z.B. der Permalink und die Kommentaranzahl. Danach folgt ein neues <aside>-Element, welches verwandte Informationen kennzeichnen soll. Zusätzlich wird aus dem gleichen Grund wie auch beim <article>-Element auch hier eine ARIA-Rolle vergeben. Dies kennzeichnet die Auflistung der Links als verwandte Inhalte zu diesem Artikel.
Die Angabe des Autors dient nur zur Veranschaulichung der Möglichkeiten, bei Enzyklopädien wie Wikipedia würden diese Angaben vmtl. keinen Sinn machen.

5.4 Shops

Shops können potentiell am Besten von der gleichzeitigen Suchmaschinenoptimierung profitieren, wenn sie die (teilweise) neuen Möglichkeiten von HTML5, Microdata und Microformats nutzen. Mit Hilfe von Microformat und Microdata können Produktinformationen sowie Preise, Bewertungen, Lieferanten, Verfügbarkeit und viele andere Daten und Kombinationsmöglichkeiten. Microdata bietet hier allerdings weit mehr Möglichkeiten zur Auszeichnung, als Microformats ^[58]. Nachfolgend wird ein aus dem Shop der FOM die Mütze "Cashmere Mütze Martin S"^[59] genutzt um solch eine Auszeichnung beispielhaft darzustellen:

<article class="hproduct" itemscope itemtype="http://data-vocabulary.org/Product">
        <header>
                <h1><span itemprop="brand" class="brand">FOM</span> <span itemprop="name" class="fn">Cashmere Mütze</span></h1>
                <div class="subcolumns"> 
                        <div class="c50l"> 
                                <div class="subcl">
                                        Kategorie: 
                                        <span class="category">
                                                <span itemprop="category" class="value-title" title="Herren > Mützen">Mützen</span>
                                        </span> 
                                </div>
                        </div>
                        <div class="c50r">
                                <div class="subcl"> 
                                        <span itemprop="review" itemscope itemtype="http://data-vocabulary.org/Review-aggregate" class="review hreview-aggregate">
                                                Durchschnittliche Bewertung: <span itemprop="rating" class="rating">1.4</span>, basierend auf <span itemprop="count" class="count">64</span> Bewertungen
                                        </span>
                                </div>
                        </div>
                </div>
        </header>
        <div class="subcolumns"> 
                <div class="c25l"> 
                        <div class="subcl"> 
                                <img itemprop="photo" class="photo" src="http://www.focus-campus-store.de/images/product_images/info_images/107_0.jpg" alt="Foto: Cashmere Mütze">
                        </div>
                </div>
                <div class="c75r"> 
                        <div class="subc"> 
                                <p itemprop="description" class="description">Strickmütze mit klassischem Rippenmuster und umgeschlagenem Bund. Ein idealer Begleiter für die kalte Jahreszeit.<br>
                                        <br>
                                        Material: 100% Cashmere, zweifädig.<br>
                                        Lieferant: Gieffe/Italien.<br>
                                        <br>
                                        Jede Mütze hat ein Zertifikat mit der laufenden Nummer des Garnherstellers Cariaggi als Garantie des europäischen Ursprungs. 
                                        Unsere Strickmützen werden ausschließlich in kleinen Manufakturen in der Reggio Emilia in Italien gefertigt. Die Auflage ist auf 100 Stück limitiert.
                                </p>
                        </div>
                </div>
        </div>
        <footer>
                <div itemprop="offerdetails" itemscope itemtype="http://www.data-vocabulary.org/Offer/" class="subcolumns"> 
                        <div class="c50l"> 
                                <div class="subcl">
                                        Verkäufer:
                                        <span class="vcard" itemscope itemtype="http://data-vocabulary.org/Organization">  
                                                <img src="http://www.fom.de/fileadmin/fom/img/forschungsprojekte/fom_logo.jpg" alt="Logo: Hochschule für Ökonomie und Management" class="photo hideme" itemprop="photo">
                                                <a href="http://www.fom.de/" class="url" itemprop="url">
                                                        <span itemprop="name" class="fn org">Hochschule für Ökonomie und Management</span>
                                                </a>
                                                <span class="hideme">
                                                        <span itemprop="address" class="adr" itemscope itemtype="http://data-vocabulary.org/Address">
                                                                <span itemprop="street-address" class="street-address">Leimkugelstraße 6</span>,<br>  
                                                                <span itemprop="postal-code" class="postal-code">45141</span> 
                                                                <span itemprop="locality" class="locality">Essen</span>, 
                                                                <span itemprop="region"><abbr class="region" title="Nordrhein-Westfalen">NRW</abbr></span>, 
                                                                <span itemprop="country-name"><abbr class="country" title="Deutschland">DE</abbr></span>.<br>  
                                                        </span>  
                                                        <span itemprop="geo" itemscope itemtype="http://www.data-vocabulary.org/Geo/">
                                                                Latitude: <span itemprop="latitude">51.474001 S</span><br>
                                                                Longitude: <span itemprop="longitude">7.005037 E</span><br>
                                                        </span>  
                                                        <span class="type">Telefon: </span><span itemprop="tel" class="tel">+49 (0) 201 810040</span><br>
                                                        <span class="type">Telefax: </span><span itemprop="tel" class="tel">+49 (0) 201 81004180</span><br>
                                                        E-Mail: <a href="mailto:info@fom.de" class="email" itemprop="email">info@fom.de</a><br>
                                                </span>
                                        </span>
                                </div>
                        </div>
                        <div class="c50r">
                                <div class="subcl"> 
                                        Preis: <a itemprop="offerURL" href="http://www.focus-campus-store.de/Herren/Muetze/Cashmere-Muetze-Martin-S::107.html">
                                                <span class="price">
                                                        <span itemprop="price">49.00</span> <span itemprop="currency">€</span>
                                                </span>
                                        </a>
                                </div>
                        </div>
                </div>
        </footer>
</article>

Leider weigert sich das "Rich Snippets Testing Tool" von Google eine Voransicht zu erstellen, wenn sowohl Microformat als auch Microdata verwendet wird. Kurioserweise erkennt das Werkzeug aber alle Daten, die dazu nötig wären. Wenn man die Microformat-Auszeichnungen entfernt (bzw. die Klassennamen zum Eröffnen eines Microformatabschnittes unkenntlich macht - z.B. durch einen zusätzlichen Buchstaben), erhält man die in Abbildung 14 abgebildete Ausgabe.

Abbildung 14: Ausgabe des Rich Snippets Testing Tools von Google für das Shop-Beispiel

Folgende Daten werden vom Tool erkannt, wenn beide Formate verwendet werden:

hcard
fn = Hochschule für Ökonomie und Management
org
organization-name = Hochschule für Ökonomie und Management
adr
street-address = Leimkugelstraße 6
locality = Essen
region = Nordrhein-Westfalen
postal-code = 45141
tel
value = +49 (0) 201 810040
tel
value = +49 (0) 201 81004180
email
value = info@example.com
url = http://www.fom.de/
photo = http://www.fom.de/fileadmin/fom/img/forschungsprojekte/fom_logo.jpg
Warning: This information will not appear as a rich snippet in search results results, because it seems to describe an organization. Google does not currently display organization information in rich snippets
hproduct
brand name = FOM
category = Herren > Mützen
description = Strickmütze mit klassischem Rippenmuster und umgeschlagenem Bund. Ein idealer Begleiter für die kalte Jahreszeit. Material: 100% Cashmere, zweifädig. Lieferant: Gieffe/Italien. Jede Mütze...
fn = Cashmere Mütze
photo = http://www.focus-campus-store.de/images/product_images/info_images/107_0.jpg
price = 49.00
review hreview-aggregate
rating
average (normalized to 5.0 scale) = 1.5
average = 1.4
count = 64
Warning: In order to generate a preview, either price or review or availability needs to be present.
hcard
fn = Beispielfirma
org
organization-name = Beispielfirma
adr
street-address = Musterstraße 123
locality = Musterstadt
region = Nordrhein-Westfalen
postal-code = 12345
tel
value = +49 (0) 123 456789
tel
value = +49 (0) 123 567890
email
value = info@example.com
url = http://www.example.com/
photo = http://darkarrow.de/test/images/logo.jpg
Warning: This information will not appear as a rich snippet in search results results, because it seems to describe an organization. Google does not currently display organization information in rich snippets
Item 
Type: http://data-vocabulary.org/product
brand = FOM 
name = Cashmere Mütze 
category = Mützen 
review = Item( 1 ) 
photo = http://www.focus-campus-store.de/images/product_images/info_images/107_0.jpg 
description = Strickmütze mit klassischem Rippenmuster und umgeschlagenem Bund. Ein idealer Begleiter für die kalte Jahreszeit. Material: 100% Cashmere, zweifädig. Lieferant: Gieffe/Italien. Jede Mütze... 
offerdetails = Item( 2 ) 
Item 1 
Type: http://data-vocabulary.org/review-aggregate
rating = 1.4 
count = 64 
Item 2 
Type: http://www.data-vocabulary.org/offer/
offerurl = http://www.focus-campus-store.de/Herren/Muetze/Cashmere-Muetze-Martin-S::107.html 
price = 49.00 
currency = € 
Item 
Type: http://data-vocabulary.org/organization
photo = http://www.fom.de/fileadmin/fom/img/forschungsprojekte/fom_logo.jpg 
url = http://www.fom.de/ 
name = Hochschule für Ökonomie und Management 
address = Item( 3 ) 
geo = Item( 4 ) 
tel = +49 (0) 201 810040 
tel = +49 (0) 201 81004180 
email = mailto:info@example.com 
Item 3 
Type: http://data-vocabulary.org/address
street-address = Leimkugelstraße 6 
postal-code = 45141 
locality = Essen 
region = NRW 
country-name = DE 
Item 4 
Type: http://www.data-vocabulary.org/geo/
latitude = 51.474001 S 
longitude = 7.005037 E 
Item 
Type: http://data-vocabulary.org/organization
photo = http://darkarrow.de/test/images/logo.jpg 
url = http://www.example.com/ 
name = Beispielfirma 
address = Item( 5 ) 
geo = Item( 6 ) 
tel = +49 (0) 123 456789 
tel = +49 (0) 123 567890 
email = mailto:info@example.com 
Item 5 
Type: http://data-vocabulary.org/address
street-address = Musterstraße 123 
postal-code = 12345 
locality = Musterstadt 
region = NRW 
country-name = DE 
Item 6 
Type: http://www.data-vocabulary.org/geo/
latitude = 12.34 S 
longitude = 123.45 E

6 Weitere Anwendungsmöglichkeiten

Da weitere Praxisbeispiele den Rahmen sprengen würden, wird im Folgenden noch einmal auf weitere Anwendungsmöglichkeiten hingewiesen.

6.1 Kartenanwendungen

Kartenanwendungen wie Google Maps galten bisher durch ihre hohe Grafiklast als nicht barrierefrei realisierbar. Auch mit den neuen Möglichkeiten ist nicht unbedingt erkennbar, ob sich dies grundlegend ändern wird. Allerdings bieten die neuen Techniken zumindest ansatzweise Möglichkeiten, auch solche Anwendungen barriereärmer zu realisieren. So können z.B. gefundene Orte auf der Karte mit Microdata/Microformats ausgezeichnet werden, damit mobile, assistive Technologien diese auslesen und z.B. eine Navigation per Audio speziell für blinde Mitmenschen ermöglichen können. Die WAI-ARIA-Komponenten gibt es zwar nicht erst seit HTML5, aber auch diese könnten solch eine stark interaktive Anwendung, wie Kartenanwendungen, benutzbarer machen.

6.2 Social Networks

Auch für Social Networks können Auszeichnungen per Microdata/Microformats durchgeführt werden. Neben den bereits vorgestellten Personen-Standards (oder vielmehr in diesen Standards) können Links zu anderen Personen hinterlegt werden, welche das Attribut rel="friend" erhalten. Dieses Merkmal kann dann dazu genutzt werden, diese Verbindungen auszulesen.

7 Zusammenfassung und Fazit

Die neuen Möglichkeiten, die HTML5 (im erweiterten Sinne der WHAT-WG) bietet, lassen was Barrierefreiheit betrifft, einen großen Fortschritt erhoffen - zumindest, wenn sie denn genutzt werden. Denn genau hier liegt das Problem: Das Thema Barrierefreiheit wurde bisher immer sehr stiefmütterlich behandelt. Dabei ist barrierefreies Webdesign gar nicht teuer. Wer sich an die Standards hält (die zugegebenermaßen stetig im Fluss sind) hat schon einen großen Schritt in Richtung Barrierefreiheit getan. Leider tun dies nur sehr wenige Seiten, wahrscheinlich weil den Betreibern (neben dem Imagegewinn) nicht klar ist, wie viele Menschen von unterschiedlichsten Barrieren betroffen sind - zumal eine barrierefreie Website zwingend auch eine hohe Ergonomie (und damit für alle Benutzer Vorteile) aufweist.
Was den generellen Einsatz von HTML5 bzw. die Diskussionen, ob man HTML5 schon einsetzen soll, oder nicht, lässt sich wie fast immer nur sagen: Hier kommt es auf die Zielgruppe an. Bei normalen oder gar technikaffinen Nutzergruppen kann man diesen Schritt durchaus wagen. Insbesondere das Image des Betreibers kann auch hier eine Rolle spielen. Ein konservativer Betreiber wird sich ohne große Überzeugungsarbeit kaum auf einen noch in Entwicklung befindlichen neuen Standard einlassen.
Falls der Betreiber sich für HTML5 entscheidet, muss dieser sich dann auch noch für eine Lösung zur Behebung der Browserunterschiedlichkeiten oder -fehler wählen. So sollte man sich bei einer Nutzerstruktur, die häufig den IE verwendet, eher gegen die JavaScript-Lösung (und für die Namespace-Lösung) entscheiden, da hier die Chance höher ist, dass sich unter diesen Nutzern ein nicht zu vernachlässigender Anteil an Nutzern mit abgeschaltetem JavaScript befinden könnte. Leider gibt es hierzu kaum aussagekräftige Statistiken. Diese Lösung hat allerdings den Nachteil, dass man mehr Aufwand in die Verfolgung der Weiterentwicklungen bei SEO und assistiven Technologien investieren muss. Noch werden die neuen HTML5-Elemente semantisch nicht berücksichtigt - sobald dies aber der Fall ist, muss geprüft werden ob die XML-Namespace-Lösung von den Weiterentwicklungen der Suchmaschinenbetreiber und assistiven Technologien erfasst werden.
Anders sieht dies bei einem eher geringen Anteil von IE-Nutzern aus. Hier spricht dies eher für die Nutzung von JavaScript zur Lösung des IE-Problems. Diese hat den Vorteil, dass die Elemente von Anfang an dem Standard entsprechen und vmtl. auch von den Weiterentwicklungen erfasst werden.
Das Problem bei der Wahl für oder gegen den Einsatz von HTML5 berührt dabei noch nicht einmal so sehr die Besorgnis, dass die Seiten für Nutzer assistiver Technologien nicht benutzbar wären (JavaScript ist bei sachgemäßer Nutzung für z.B. Screenreader kein Problem und auch die XML-Namespace-Lösung wird von Screenreadern erkannt). Vielmehr sollte sich der Betreiber bei der Entscheidungsfindung fragen, ob er mit dem stetigen Wandel der Standards, der Technik und der Best-Practices - gerade im Bereich der Barrierefreiheit - mithalten kann. Die in dieser Arbeit vorgestellten Lösungsansätze könnten bereits morgen überholt sein und müssten dann zeitnah ausgetauscht werden.
Bei einer Entscheidung gegen die Nutzung von HTML5 sollten allerdings trotzdem der Einsatz der Techniken, die HTML5 nicht voraussetzen, bedacht werden. Eine Auszeichnung mit Microformats und WAI-ARIA-Komponenten kann und sollte bereits jetzt erfolgen. Unabhängig von der Nutzung von HTML5 kann der Einsatz dieser Techniken nicht nur den Barriereabbau einer Website bewirken, er hilft auch Suchmaschinenbetreibern beim Erfassen der relevanten Inhalte einer Seite (SEO). Der SEO-Bereich ist in den letzten Jahren immer weiter gewachsen (leider im Gegensatz zu den Bemühungen um die Barrierefreiheit). Da eine Auszeichnung für SEO (die Standards für Microformats und Microdata sind nicht zuletzt den Bemühungen aus diesem Bereich zu verdanken) nun auch assistiven Technologien weiterhilft besteht die Chance dass das gesamte Web barriereärmer wird. Hoffentlich erkennen dies auch die Hersteller von Screenreadern (bis auf Apple beteiligt sich wohl keiner^[60]).
Entwickler können sich aber auch für das schrittweise Einführen und Testen von HTML5 entscheiden. So sollte sich z.B. der neue Doctype und die neuen Eingabetypen jetzt schon nutzen lassen - ältere Browser machen aus unbekannten Eingabetypen normale Texteingabefelder. Barrierefreie Seiten lassen sich am Besten entwickeln, wenn man viele, verschiedene Tester hat - am Besten auch blinde Nutzer. Man kann zwar selber einen Screenreader ausprobieren, wird ihn aber als sehender niemals so bedienen, wie das blinde Nutzer tun. Wer schonmal einem beim Nutzen dieser Software zugesehen/zugehört hat, wird dies bestätigen. Die jahrelange Erfahrung und aufgebaute Geschwindigkeit und Gewohnheiten stehen denen von sehenden Besuchern einer Website genutzten Gewohnheiten, Erfahrungen und Tools in nichts nach, sind aber dennoch grundverschieden. Für einfache Tests kann man das tun, aber einen richtigen Test sollte man, die Möglichkeit natürlich vorausgesetzt, dennoch durchführen lassen.

8 Anhang

8.1 Fußnoten

1. ↑ http://ishtml5readyyet.com/, zuletzt abgerufen am 07.02.2011
2. ↑ Vgl. http://www.infoworld.com/d/developer-world/w3c-hold-html5-in-websites-041, zuletzt abgerufen am 07.02.2011
3. ↑ Vgl. http://http://www.w3.org, zuletzt abgerufen am 07.02.2011
4. ↑ Vgl. http://wiki.whatwg.org, zuletzt abgerufen am 07.02.2011
5. ↑ Hauser, T., et al (2009), S.238f
6. ↑ Vgl. http://wiki.whatwg.org/wiki/FAQ#HTML5, zuletzt abgerufen am 07.02.2011
7. ↑ Vgl. http://www.w3.org/html/wg/html5/diff, zuletzt abgerufen am 07.02.2011
8. ↑ Vgl. http://download.bluemars.de/webmontag/2007-07-02/, zuletzt abgerufen am 07.02.2011
9. ↑ Vgl. Czajka, S., Mohr, S. (2008), S. 557
10. ↑ http://www.w3.org/Translations/WCAG20-de/, zuletzt abgerufen am 07.02.2011
11. ↑ Vgl. http://www.w3.org/Translations/WCAG20-de/, zuletzt abgerufen am 07.02.2011
12. ↑ Vgl. http://www.w3.org/Translations/WCAG20-de/ , zuletzt abgerufen am 07.02.2011
13. ↑ Vgl. http://www.w3.org/WAI/intro/wcag.php, zuletzt abgerufen am 07.02.2011
14. ↑ Vgl. http://www.w3.org/WAI/intro/aria.php, zuletzt abgerufen am 07.02.2011
15. ↑ Vgl. Kröner, P. (2010), S. 100f
16. ↑ Vgl. http://www.w3.org/TR/wai-aria/introduction, zuletzt abgerufen am 07.02.2011
17. ↑ Vgl. http://www.w3.org/TR/wai-aria/roles, zuletzt abgerufen am 07.02.2011
18. ↑ Vgl. http://www.w3.org/TR/wai-aria/usage#usage_intro, zuletzt abgerufen am 07.02.2011
19. ↑ Vgl. http://dev.opera.com/articles/view/introduction-to-wai-aria/, zuletzt abgerufen am 07.02.2011
20. ↑ Vgl. http://hessendscher.de/wai-aria/, zuletzt abgerufen am 07.02.2011
21. ↑ Vgl. https://developer.mozilla.org/en/AJAX/WAI_ARIA_Live_Regions, zuletzt abgerufen am 07.02.2011
22. ↑ Vgl. Kröner, P. (2010), S. 102f
23. ↑ Vgl. http://www.w3.org/TR/rdfa-in-html/, zuletzt abgerufen am 07.02.2011
24. ↑ Vgl. http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets.html, zuletzt abgerufen am 07.02.2011
25. ↑ Vgl. http://www.w3.org/TR/microdata/, zuletzt abgerufen am 07.02.2011
26. ↑ Vgl. http://microformats.org/wiki/introduction, zuletzt abgerufen am 07.02.2011
27. ↑ Vgl. http://ablognotlimited.com/articles/microformats-html5-microdata, zuletzt abgerufen am 07.02.2011
28. ↑ Vgl. http://microformats.org/wiki/rich-snippets, zuletzt abgerufen am 07.02.2011
29. ↑ Vgl. http://microformats.org/wiki/hcalendar, zuletzt abgerufen am 07.02.2011
30. ↑ Vgl. http://microformats.org/wiki/hcard, zuletzt abgerufen am 07.02.2011
31. ↑ Vgl. http://dev.w3.org/html5/spec/Overview.html, zuletzt abgerufen am 07.02.2011
32. ↑ Vgl. http://www.alistapart.com/articles/semanticsinhtml5, zuletzt abgerufen am 07.02.2011
33. ↑ Vgl. http://designshack.co.uk/articles/html/html5-semantic-changes-3-of-4, zuletzt abgerufen am 07.02.2011
34. ↑ Vgl. Pilgrim, M. (2010), S. 41
35. ↑ Vgl. https://developer.mozilla.org/en/Sections_and_Outlines_of_an_HTML5_document, zuletzt abgerufen am 07.02.2011
36. ↑ Vgl. Kröner, P. (2010), S. 101
37. ↑ vgl. http://intertwingly.net/blog/2008/01/22/Best-Standards-Support#c1201006277, zuletzt abgerufen am 07.02.2011
38. ↑ vgl. http://www.peterkroener.de/html5-was-geht-heute-schon-was-geht-nicht-der-grosse-ueberblick/, zuletzt abgerufen am 07.02.2011
39. ↑ vgl. http://www.peterkroener.de/html5-was-geht-heute-schon-was-geht-nicht-der-grosse-ueberblick/, zuletzt abgerufen am 07.02.2011
40. ↑ vgl. http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html, zuletzt abgerufen am 07.02.2011
41. ↑ vgl. http://blog.whatwg.org/styling-ie-noscript, zuletzt abgerufen am 07.02.2011
42. ↑ Der Screenreader ist Open-Source und unter http://www.nvda-project.org/ erhältlich
43. ↑ vgl. https://github.com/paulirish/html5-boilerplate/issues/issue/115/#comment_439219, zuletzt abgerufen am 07.02.2011
44. ↑ vgl. http://blogs.msdn.com/b/ie/archive/2010/03/16/html5-hardware-accelerated-first-ie9-platform-preview-available-for-developers.aspx, zuletzt abgerufen am 07.02.2011
45. ↑ erhältlich unter html5boilerplate.com
46. ↑ vgl. http://remysharp.com/2009/01/07/html5-enabling-script/, zuletzt abgerufen am 07.02.2011
47. ↑ siehe http://builder.yaml.de
48. ↑ Die ursprünglich generierte Datei ist unter http://html5.darkarrow.de/test/YAML-Builder-generierte-Datei-HTML4.txt erreichbar
49. ↑ vgl. http://www.yaml.de/de/lizenz/lizenzbedingungen.html, zuletzt abgerufen am 07.02.2011
50. ↑ http://www.yaml.de/de/dokumentation/einfuehrung/barrierefreiheit-und-webstandards.html, zuletzt abgerufen am 07.02.2011
51. ↑ vgl. 4.1.1
52. ↑ http://www.google.com/webmasters/tools/richsnippets, zuletzt abgerufen am 07.02.2011
53. ↑ siehe http://www.google.com/webmasters/tools/richsnippets?url=http://html5.darkarrow.de/test/index.html&view=, zuletzt abgerufen am 07.02.2011
54. ↑ Beispiele: http://www.annodex.net/~silvia/itext/, zuletzt abgerufen am 07.02.2011
55. ↑ HTML5-Beta auf youtube.com/html5 einschalten, dann HTML5-Film aufrufen (z.B. http://www.youtube.com/watch?v=YE7VzlLtp-4 )
56. ↑ vgl. http://camendesign.com/code/video_for_everybody/test.html, zuletzt abgerufen am 07.02.2011
57. ↑ vgl. http://www.html5accessibility.com/index-aria.html, zuletzt abgerufen am 07.02.2011
58. ↑ vgl. http://www.google.com/support/webmasters/bin/answer.py?answer=186036, zuletzt abgerufen am 07.02.2011
59. ↑ vgl. http://www.focus-campus-store.de/Herren/Muetze/Cashmere-Muetze-Martin-S::107.html, zuletzt abgerufen am 07.02.2011
60. ↑ vgl. http://www.webstandards.org/2009/05/13/interview-with-ian-hickson-editor-of-the-html-5-specification/, zuletzt abgerufen am 07.02.2011

8.2 Literatur- und Quellenverzeichnis

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis