accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

28 Nov 2008

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.

Kommentare zu dieser Meldung: 8

Permalink Ansgar Hein meinte am 30.11.2008:

Schöne Zusammenfassung der technischen Finessen der neuen Website. Interessant ist die Zusammenführung mehrerer CSS-Dateien aus YAML sowie die Kompression selbiger in eine Datei. Ich fände einen generellen Hinweis auf diesen Eintrag hilfreich für Einsteiger in das Thema. Denn leider weiß noch nicht jeder, dass bessere Zugänglichkeit und damit Innovation manchmal nur durch Missachtung aktueller W3C-Werkzeuge erzielt werden kann und man Richtlinien zur Not auch mal brechen und nicht nur beugen muss.

Permalink Henning meinte am 02.12.2008:

Frage eines Laien, der für einen Verein einen Relaunch stemmen soll und sich mit Barrrierefreiheit erst seit kurzem beschäftigt: Warum haben die abbr-Elemente keine title-Attribute? Gibt's da einen Trick, oder muss man da nichts mehr eintragen?

Permalink Der Caspers meinte am 03.12.2008:

> Warum haben die abbr-Elemente keine title-Attribute?

Doch, haben sie teilweise schon. Nicht alle, aber manche (z.B. hier im Formular das »URL«). Sinnvoll ist das dann, wenn es ohne sinnentstellend wäre oder es sich um eine eher ungebräuchliche Abkürzung handelt. Bei gängigen Abkürzungen wie z.B. z.B. ist die zusätzliche Auszeichnung mit einem title eher unnötig, zumal Screenreader eigene Ausspracheregeln für verbreitete Abkürzungen haben.

Permalink Gerrit van Aaken meinte am 20.12.2008:

Wie sollte man denn eine OL, die bei einer anderen Ziffer als 1 beginnten soll, per CSS dazu bringen, das auch zu tun? Gibt es da etwas eine Möglichkeit? Mir fiele für dieses Problem ebenfalls nur das "verbotene" start-Attribut ein ...

Permalink Der Caspers meinte am 20.12.2008:

Mit counter-reset und counter-increment, s. w3.org/TR/CSS21/generate.html#counters

Das Problem ist halt, dass wir für Codelistings Ordererd Lists OL benutzen und teilweise die Zeilennummern referenzieren. Ohne CSS stimmt dann die Zuordnung nicht mehr, daher gehört sowas ins HTML (weil es echter Inhalt ist und nicht nur Deko).

Permalink Thomas Scholz meinte am 20.12.2008:

Gerrit, mit Countern und Generated Content. Kann aber der IE nicht, und ohne Stylesheet fallen sie weg, und der Zusammenhang ist hinüber.

Auch deshalb schreibe ich nur noch HTML 5. Da geht das nämlich wieder.

Permalink Heribert Wettels meinte am 12.01.2009:

> 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.

Unabhängig von der linguistischen Diskussion gibt es aber doch einen gravierenden Unterschied, wie Akronyme bzw. Abkürzungen auszusprechen sind, die sich irgendwie im Markup wiederfinden sollten.

Abkürzungen wie ZDF (Zweites Deutsches Fernsehen) sollten "Zett De Eff" gelesen werden, während der TÜV (Technischer Überwachungsverein) als "Tüff" gelesen wird.

Wie gesagt, auch wenn die Linguisten da noch diskutieren, halte ich eine Konvention, dass ZDF mit ABBR und TÜV mit ACRONYM ausgezeichnet wird, durchaus für angemessen.

Wie gehen denn die gängigen Screenreader mit dem Thema um? Was hört ein Nutzer, wenn er die oben genannten Beispiele in den beiden verschiedenen Markups liest?

Permalink Der Caspers meinte am 12.01.2009:

> Wie gesagt, auch wenn die Linguisten da noch diskutieren,
> halte ich eine Konvention, dass ZDF mit ABBR und TÜV mit
> ACRONYM ausgezeichnet wird, durchaus für angemessen.

Genau da liegt das Problem: es gibt keine allgemeingültigen Regeln, was wie ausgesprochen wird. Ok, bei Z D F gibt es genau eine, aber bei vielen anderen Abkürzungen gibt es gleich mehrere, die verbreitet sind. MySQL z.B. - wird sowohl Mai Ess Kiuh Ell als auch Mai Sequel ausgesprochen.

Dazu kommt, dass Screenreader CSS weitestgehend ignorieren und somit Regeln wie abbr.buchstabieren {speak : spell-out;} nirgendwo funktionieren können.

> Wie gehen denn die gängigen Screenreader mit dem Thema
> um? Was hört ein Nutzer, wenn er die oben genannten Beispiele
> in den beiden verschiedenen Markups liest?

Auch das lässt sich nicht allgemeinverbindlich beantworten. Das hängt vom verwendeten Screenreader, der verwendeten Sprachsynthese und der verwendeten Stimme ab. Ausserdem haben die meisten Screenreader eingebaute Aussprache-Wörterbücher, in denen der Nutzer festlegen kann wie etwas ausgesprochen wird. Und dann kommen noch die Ausführlichkeits-Einstellungen hinzu, in denen festgelegt wird, ob z.B. title-Attribute etc. anstatt des Taginhalts vorgelsen werden usw. usf.

Das sind ein paar Unbekannte zu viel in der Gleichung, zumal, wie oben erwähnt, das acronym-Element über kurz oder lang eh aus HTML rausfällt.