accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

Web-Standards, HTML und so…

Kommen wir zum technischen Gerüst dieser Seiten. Wie bereits erwähnt basieren das HTML&CSS auf dem YAML-Framework in der neuesten Version. Da auch die letzte Version auf diesem Gerüst basierte, war die Umstellung mit ein paar ausgefeilten Suchmustern im Editor relativ leicht zu bewältigen und so manche Zeile Code hat es aus der alten Fassung auch bis herüber geschafft – ein nicht zu unterschätzender Vorteil, den barrierefreie Seiten durch ihre eingebaute Logik haben.

Über die Style Sheets als solche hatten wir ja bereits in der ersten Folge dieser kleinen Serie geschrieben; dort finden Sie auch den Link zum Download einer ausführlich kommentierten Fassung.

Bedeutungslehre

Unsere Seiten sind nach wie vor mit sinnvoll strukturiertem und semantischem Markup aufgebaut. Dies betrifft insbesondere die Textauszeichnungen und die Struktur der Inhalte. Da HTML aber nie alle Eventualitäten abdecken wird, kommt es zwangsläufig zu Interpretationen der Bedeutung von Elementen, die von anderen Interpretationen abweichen kann. Insofern kann man über das eine oder andere Element sicher diskutieren (z.B. in unserer ›Tag-Cloud‹ – hierzu wird es noch einen eigenen Laborbericht geben), aber in der Regel werden beide Positionen Recht behalten.

Ein Element hat die Umstellung nicht überlebt: ACRONYM wurde global durch ABBR ersetzt. Da selbst Linguisten sich nicht einigen können, welche Abkürzung denn auch ein Akronym sei, und da das ACRONYM-Element in HTML5 aller Voraussicht nach nicht mehr spezifiziert sein wird, fiel uns dieser Abschied nicht sonderlich schwer.

Weiterlesen …

Valid, Valid über alles?

Fast alle Seiten validierten zum Zeitpunkt ihrer Erstellung nach HTML 4.01 strict (für Fachleute: unter Berücksichtigung der Regeln zur Wohlgeformtheit gemäß »XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition): A Reformulation of HTML 4 in XML 1.0.« mit Ausnahme der in Appendix C.1, C.2 und C.3 gelisteten XML-spezifischen Anforderungen). Wenn Sie dennoch Fehler im Markup dieser Seiten finden, wären wir natürlich für einen kurzen Hinweis dankbar.

Mit zwei Ausnahmen:

  1. Einige Seiten weisen »Fehler« in der Validierung auf, da wir z.B. im Gegensatz zum W3C der Auffassung sind, dass das start-Attribut von OL echter Inhalt ist und somit ins HTML gehört und nicht ins CSS.
  2. Seit dem aktuellen Relaunch setzen wir zur Kennzeichnung von Seitenbereichen und für erweiterte Funktionen Teile des kommenden WAI-ARIA-Standards ein. Aktuelle Hilfsmittel wie der Screenreader JAWS unterstützen diese Technik bereits in Verbindung mit modernen Browsern. Sie ermöglicht eine einfache Identifikation von Bestandteilen einer Seite wie z.B. der Navigation, der Suche, dem wesentlichen Inhalt einer Seite und ergänzenden Informationen zum jeweiligen Artikel.

Das hierfür benötigte role-Attribut ist jedoch noch nicht Bestandteil irgendeiner HTML- oder XHMTL-Spezifikation des W3C – verbreitete Validatoren geben hier also zurzeit noch einen Fehler aus. Da uns die Zugänglichkeit für den Nutzer wichtiger ist als ein grünes Fähnchen eines Prüfprogramms, haben wir nicht lange überlegt, ob wir diese Technik einsetzen sollen oder nicht.

Im Einzelnen setzen wir folgende Rollenzuweisungen ein, um Bereiche der Seiten zu kennzeichnen und abzugrenzen:

Größere Ansicht: Hervorhebung der ARIA-Document-Landmarks mit der Accessibility Toolbar

role="article"
Der wesentliche Inhalt einer Seite, also wie der Name schon sagt ein Artikel, ein Blogpost etc.
role="banner"
Die Kopfzeile der Seite mit dem Namen, Logo und Claim der Initiative
role="complementary"
Von Inhalt abhängige Bereiche, die diesen ergänzen, aber auch für sich allein stehen könnten (z.B. eine Vorlesefunktion)
role="contentinfo"
Ergänzende Informationen zum Inhalt wie z.B. Fußnoten, weiterführende Links etc.
role="main"
Der wesentliche Inhaltsbereich
role="navigation"
Der oder die Navigationsbereich(e)
role="note"
Ergänzende Bemerkungen zum Inhalt
role="search"
Die Suchfunktion

Eine tiefergehende Einführung in dieses Konzept finden Sie in einem Artikel von Gez Lemon bei der Opera Developer Community: »Introduction to WAI ARIA«

Fehlervermeidungsstrategien

Größere Ansicht: Hervorhebung der ARIA-Live-Regions mit der Accessibility Toolbar

Zusätzlich setzen wir Attribute aus WAI-ARIA ein um Screenreader-Nutzern die Handhabung von Formularen zu erleichtern. Besonders hilfreich sind hier:

aria-required="true"
Kennzeichnet ein Pflichtfeld in einem Formular, dass vom Nutzer ausgefüllt werden muss; mehr dazu bei Marco Zehe: »Easy ARIA Tip #1: Using aria-required«
role="alert"
Kennzeichnet eine Fehlermeldung; mehr dazu bei Marco Zehe: »Easy ARIA tip #3: aria-invalid and role ›alert‹«
aria-live="assertive"
Über diese sog. ›Live Regions‹ lässt sich steuern, mit welcher Dringlichkeit der Nutzer auf eine Fehlermeldung hingewiesen wird. Im konkreten Fall wird der Nutzer nicht unmittelbar bei der Arbeit unterbrochen (das wäre aria-live="rude"), sondern erst bei der nächsten Gelegenheit informiert.

Wie sich dies in der Praxis im Screenreader anhört hat Martin Kliehm auf dem Wiener A-Tag vorgeführt. Die Videos dazu finden sich in seinem flickr-Account, die dazugehörige Präsentation gibt's bei Slideshare.