hAccessibility (Deutsche Übersetzung)

Mikroformate wie hCalendar oder hReview verwenden das abbr-Element zur Auszeichnung von Datumsangaben. Viele Webentwickler stolpern über diese Art der Auszeichnung und fragen sich, ob es sich bei <abbr class="dtstart" title="19700101">01. Januar 1970</abbr> wirklich um semantisch korrekt angewandtes (X)HTML handelt. Der folgende Artikel zeigt, dass es tatsächlich problematisch sein kann, das Element abbr für diesen Zweck einzusetzen.

Dies ist die deutsche Übersetzung des Artikels hAccessiblity von Bruce Lawson und James Craig vom 27. April 2007. Dieses Dokument kann Übersetzungsfehler enthalten. Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an den Übersetzer. Kommentare des Übersetzers, die als solche gekennzeichnet sind, sind nicht Bestandteil des Ursprungsdokuments.

Vielen Dank an Tomas Caspers Hilfe bei der Übersetzung.

Mikroformate sind eine großartige Idee. Sie erlauben die Einbindung von maschinenlesbaren, semantischen Daten (beispielsweise Kontaktinformationen und Veranstaltungshinweisen) in Webseiten. Mit den richtigen Plugins können Sie diese Informationen direkt in Ihr Kalenderprogramm oder Adressbuch importieren. Wie bei Mikroformaten geht es in Teilbereichen der Barrierefreiheit darum, Webseiten maschinenlesbarer zu machen, um deren Gebrauchstauglichkeit für Menschen zu erhöhen.

In den meisten Fällen ergänzen sich Mikroformate und die Prinzipien der Barrierefreiheit von Webseiten hervorragend.

Abkürzungen in Mikroformaten

HTML kennt das abbr-Element zur Auszeichnung von Abkürzungen. Assistive Programme, darunter die beliebtesten Screenreader, verwenden dieses Element dazu, Abkürzungen zu erläutern, beispielsweise Abkürzungen wie BITV oder kg. Screenreader lesen die Erläuterung der Abkürzung vor, nicht die Abkürzung an sich, was für behinderte Nutzer sehr hilfreich ist. »20 kg« würde von sehenden Nutzern sofort als Abkürzung für »20 Kilogramm« wahrgenommen werden. Ein Screenreader versucht, die Abkürzung als Wort vorzulesen oder zu buchstabieren, in diesem Fall »kaa gee«. Über das abbr-Element machen Webautoren diese Information somit auch hörenden Nutzern zugänglich:

20 <abbr title="Kilogramm">kg</abbr>

Anmerkung des Übersetzers:

Screenreader verhalten sich nicht immer so wie beschrieben. Ein frisch installiertes JAWS liest die Abkürzung vor, nicht ihre Erläuterung.

Mikroformate empfehlen die Verwendung eines abbr-Entwurfsmusters, welches in vielen Fällen mit der korrekten Verwendung des <abbr>-Elements in (X)HTML übereinstimmt. Das Mikroformat hCard setzt das abbr-Entwurfsmuster ein, um Spachen- und Länderkürzel auszuformulieren.

<abbr class="country-name" title="Japan">JP</abbr>

In diesem Beispiel hat abbr gleich 2 Vorteile: Screenreader können das Wort »Japan« vorlesen, und Parser für Mikroformate können erkennen, dass es sich um eine japanische Adresse handelt. So sollte das abbr-Element verwendet werden; es erhöht die Zugänglichkeit und dient als Mikroformat-Entwurfsmuster.

Und die Entwickler sahen, dass es gut war.

hCalendars Erbsünde

Die Mikroformate-Entwickler verließen den Pfad der Zugänglichkeit und Semantik, als sie das abbr-Entwurfsmuster zum datetime-Entwurfsmuster erweiterten. Auch wenn sie es sicherlich gut gemeint haben, war diese Idee nicht viel mehr als ein Workaround für einen Browserbug und hatte, wie viele andere Workarounds auch, unbeabsichtigte, schädliche Nebeneffekte.

Das datetime-Entwurfsmuster ist ein Weg, Daten sowohl menschenlesbar (beispielsweise »12. März, 17:00 Uhr MEZ«) als auch maschinenlesbar (beispielsweise gemäß ISO 8601: »20070312T1700+01«) darzustellen. Wenn Webautoren das mit dem abbr-Entwurfsmuster kombinieren, kommt Folgendes dabei heraus:

<abbr class="dtstart" title="20070312T1700+01">
  12. März, 17:00 Uhr MEZ
</abbr>

Wie Sie dem voraus gegangenen Beispiel entnommen haben, versuchen Screenreader, die Erläuterung der Abkürzung vorzulesen. JAWS liest aus Ziffern bestehende Zeichenketten als eine Zahl vor; »1234« beispielsweise wird »ein Tausend zwei Hundert drei und vierzig« vorgelesen, nicht »eins zwei drei vier«. Eine Zeichenkette wie »20070312T1700+01« versuchen JAWS und Windows Eyes dem entsprechend auf eine Art und Weise vorzulesen, wie es niemals für menschliche Ohren vorgesehen war:

»Zwanzig Millionen siebzig Tausend drei Hundert zwölf tee ein Tausend sieben Hundert plus Null Eins« (JAWS 8 on IE7: MP3, Ogg)

Anmerkung des Übersetzers:

Bei den verlinkten Audio-Dateien handelt es sich um die Original-Dateien. Ich habe das Beispiel nicht neu aufgenommen. Dasselbe gilt weiter unten für die Beispiel-Screenshots. Auch diese sind dem Original-Artikel entnommen.

Auch wenn es merkwürdig klingen mag: Das Verhalten der Screenreader entspricht genau den Vorgaben der HTML-4-Empfehlung:

»Der Inhalt des abbr- bzw. acronym-Elements spezifiziert den Abkürzungsausdruck selbst, so, wie er normal im Fließtext erscheinen würde. Das title-Attribut dieser Elemente kann verwendet werden, um die Langform des Ausdrucks anzubieten.« (HTML 4, ABBR, deutsche Übersetzung)

Die Erläuterung des abbr-Elements sollte – anders als das ISO-Datumsformat – menschenlesbar sein. Natürlich auch maschinenlesbar, aber letztendlich sind es Menschen, denen die Information – in diesem Fall – vorgelesen wird, damit diese sie aufnehmen und verwerten. Im Sinne der Zugänglichkeitsrichtlinien für Webinhalte (WCAG) ist die Erläuterung eines Akronyms ein Gewinn an Zugänglichkeit, und die meisten Screenreader halten sich daran.

Wenn im Wald eine Abkürzung umfällt…

Anmerkung des Übersetzers:

Seit einiger Zeit ist folgende philosophische Frage sehr populär: Wenn im Wald ein Baum umfällt, und es ist niemand da, der das beobachtet, macht das Fallen des Baums trotzdem ein Geräusch? Die Überschrift soll vermutlich auf den fast schon philosophischen Charakter der sehr im Detail geführten Diskussion hinweisen.

Es gibt zahlreiche Diskussionen über die Semantik des abbr-Elements, und natürlich hat jeder das Recht auf seine eigene Meinung. Ist es legitim zu behaupten, »05. Januar, 17:00 Uhr« sei eine Abkürzung, weil das Jahr fehlt? Eventuell. Ist »05. Januar 2006, 17:00 Uhr« auch noch eine Abkürzung, weil die Angabe der Zeitzone fehlt? Vielleicht. Wir bestreiten nicht, dass diese menschenlesbaren Daten abgekürzte Formen einer vollständigen Datums- und Zeitangabe sind. Wir bestreiten allerdings, dass das ISO-Datumsformat eine vernünftige, der HTML-Empfehlung entsprechende, menschenlesbare Erläuterung einer solchen Abkürzung ist.

Es steht außer Frage, dass die Verwendung eines ISO-8601-Datumsformats im title-Attribut eines abbr-Elements die Zugänglichkeit der Abkürzung für Nutzer assistiver Technologien erheblich einschränkt.

Zugänglichkeit »in der freien Wildbahn«

Die Mikroformate-Entwickler stehen hypothetischen Situationen als Grund für die Änderung eines Mikroformats eher abweisend gegenüber. Sie fragen eher nach realen Beispielen, also – wie häufig zu lesen ist – Beispielen »in the wild«.

Wir möchten die Mikroformate-Entwickler daran erinnern, dass es »in der freien Wildbahn« reale Screenreader gibt, die sich bereits den Spezifikationen entsprechend verhielten, lange bevor es das Mikroformate-Entwurfsmuster gab, und wir fordern die Entwickler auf, diese realen Implementierungen zu respektieren, anstatt sich auf hypothetische Situationen wie die folgenden zu konzentrieren:

»Irgendwann könnte jemand eine CSS-Regel oder ein oder zwei CSS-Eigenschaften erfinden, die automatisch ISO-8601-Datumsangaben aus dem title-Attribut des abbr-Elements in das vom Nutzer bevorzugte Format transformieren.« (Quelle)

Was ist die Alternative?

Dieser Artikel soll keine Lösung aufzeigen, sondern auf ein Problem hinweisen, das die Zugänglichkeit von Webseiten reduziert und deshalb gelöst werden muss. Wir fordern die Mikroformate-Entwickler dazu auf, über das Problem nachzudenken, unabhängig davon, ob sie einen der folgenden Lösungsvorschläge annehmen oder nicht.

Das datetime-Attribut steht derzeit nur für die Element ins und del zur Verfügung, und wir würden uns wünschen, dass wir es anstelle des title-Attribut auch für span-Elemente einsetzen können, aber leider wäre das ungültiges HTML. Einige Webworker haben vorgeschlagen, für Mikroformate spezielle Attributnamensräume einzuführen, aber die Mikroformate-Entwickler sind streng gegen diesen Vorschlag und bevorzugen eher eine einfache, gültige Lösung. Mikroformate sind einfache Konventionen, um menschenlesbaren Dokumenten semantische Auszeichnung hinzuzufügen. Die Schleusen für spezielle DTDs und Namensräume zu öffnen, würde die Komplexität von Mikroformaten schnell auf das Niveau von RDF erhöhen und dazu führen, dass die Anwendbarkeit und Bedeutung von Mikroformaten abnimmt.

Also kehren wir zu den Grundlagen zurück: die bereits vorhandenen Elemente und Attribute des Plain Old Semantic HTML.

Das datetime-Entwurfsmuster wurde ursprünglich eingeführt als Workaround für einen Browserbug. Das object-Element im Zusammenspiel mit dessen data-Attribut wäre die passendere Lösung gewesen. Die Autoren wussten dies, aber sie konnten keinen Weg finden, dies umzusetzen, ohne auf Browserbugs zu stoßen.

Wir haben noch einmal hingeschaut und fanden einen Weg, damit sich Mikroformate und Barrierefreiheit wieder vertragen; inspiriert durch das include-Entwurfmuster, das leere object-Elemente verwendet.

Das object-Beispiel

<span class="dtstart">
  12. März 2007, 17:00 Uhr MEZ
  <object>
    <param name="value" value="20070312T1700+01" />
  </object>
</span>

Die Auszeichnung ist recht einfach und bleibt semantisch sauber, darüber hinaus ist es zugänglich. Nur leider…

Wo ist der Haken?

Nun, der Haken ist der folgende: Auch wenn Browser das object-Element nicht anzeigen sollten, gibt es einige kleinere Anzeigefehler im Internet Explorer (Screenshot) und im Safari. Zur Zeit beachtet der Internet Explorer 7 den Leerraum um das Objekt nicht, und Safari (Webkit nightly) fügt Zeilenumbrüche hinzu.

Viele Entwickler könnten über diese Probleme hinweg sehen. Die meisten Designer würden es nicht. Es gibt einen einfachen CSS-Bugfix, um das Problem zu lösen: Umfassen Sie das object-Element mit einem zusätzlichen span-Element und verbergen Sie dieses.

The »gehackte« (unschöne) Version des object-Beispiels

<span class="dtstart">
  12. März 2007, 17:00 Uhr MEZ
  <!-- das zusätzliche zu versteckende span-Element -->
  <span style="display:none">
    <object>
      <param name="value" value="20070312T1700+01" />
    </object>
  </span>
</span>

Leider ist dieses Quelltext-Beispiel ziemlich unschön und nicht so simpel, wie wir es gern hätten, aber vielleicht finden wir andere, einfache Varianten?

Einsatz des title-Attributs für das span-Element

<span class="dtstart" title="20070312T1700+01">
  12. März 2007, 17:00 Uhr MEZ
</span>

Die Variante mit leerem span-Element

<span class="dtstart">
  12. März 2007, 17:00 Uhr MEZ
  <span class="value" title="20070312T1700+01"></span>
</span>

Beide Beispiele nutzen, wie das abbr-Entwurfsmuster, das title-Attribut zur Integration der ISO-Daten. Die zweite Version verhindert das Erscheinen von Tooltipps. Bei speziellen Einstellungen kann es passieren, dass Screenreader den Text in dem einen oder anderen Fall vorlesen, aber dieses Problem sollte wesentlich seltener auftreten als das vollständige Vorlesen der abbr-Erläuterung.

Wir wollen nicht das abbr-Entwurfsmuster abschaffen, nur dessen fehlerhafte Verwendung. Wir betonen noch einmal: Wir fordern die Mikroformate-Entwickler dazu auf, über das Problem nachzudenken, unabhängig davon, ob sie einen der vorgeschlagenen Lösungsvorschläge annehmen oder nicht. Alle vorgestellten Beispiele sind zugänglicher als das abbr-Entwurfsmuster. Werfen Sie einen Blick auf die fertigen Beispiele, wenn Sie sich diese genauer anschauen möchten.

Wie wir bereits sagten, wir möchten Mikroformate. Aufgrund ihrer Einfachheit und ihres hohen Nutzens stehen sie kurz davor, allgemein akzeptiert zu werden. Wir bitten die Mikroformate-Entwickler, die Zugänglichkeit ihrer Spezifikationen noch einmal zu überprüfen, bevor diese Technologie sich etabliert und es dafür zu spät ist.

3 Reaktionen zu “hAccessibility (Deutsche Übersetzung)”

  1. soso

    Alles nicht sehr schön.
    Ich glaube, die Lösung findet man eher mit Zusammenarbeit mit der Screenreader-Fraktion, diese benötigen für die Aussprache ein tatsächliches Datum. Da “dooo einsneunpunkt juunnn” bei “Do, 19. Jun” nicht ganz so gut klingt wie “Heute” oder “Donnerstag den 19. Juni”.
    <abbr title=”Donnerstag 19 Juni”> wäre nett, vielleicht lässt sich das w3c dazu erweichen?

  2. Markus Baersch

    Stimmt, dieses Problem ist mir tatsächlich bisher gar nicht bewusst geworden und ich muss gestehen, dass meine Begeisterung für Mikroformate beim Lesen einen echten Dämpfer erhalten hat. Bei aller Liebe zum Web 2.0 und der Hoffnung, vielleicht schon ohne die »eine« große Ontologie ein wenig mehr Semantik in das Web 2.5 mit Hilfe von Mikroformaten zu bringen (ohne mich bisher aktiv daran beteiligt zu haben), ist diese grobe Unverträglichkeit mit den Anforderungen an _gebrauchstaugliche_ Webseiten für Nutzer von Screenreadern schlichtweg nicht mehr gegeben, denn dazu gehört auch, dass sich Zufriedenheit einstellen kann.

    Ich kann daher die mit strong-Tags hervorgehobenen Abschnitte nur teilen. Ich verstehe nur nicht, warum nicht von Anfang an ein viel gehaltsloseres Element wie span – oder meinetwegen ein div, wenngleich sich span für diesen Zweck ja fast von selbst aufdrängt – verwendet wurde. Wer keine zusätzliche Komplexität in´s Rennen schicken will, kann ja auf die zusätzliche Schachtelung zum Vermeiden der Tooltips (generell aber eine gute Idee, finde ich) verzichten.

    Ich finde zwar in der Spezifikation unter http://microformats.org/wiki/hcalendar kein explizites Verbot, andere Tags auch für dtstart & Co. zu verwenden, aber was machen denn die existierenden Konsumenten von Mikroformaten (Browserplugins etc.) mit hCalendar-divs, die sich _nicht_ der verbogenen abbr-Tags bedienen, sondern span-Lösungen einsetzen?

  3. Siegfried

    Ich habe mal ein Bisschen experimentiert. Dabei ist folgendes herausgekommen:

    <img src=”data:text/plain;charset=US-ASCII,20090328T1218″ alt=”heute” type=”text/plain”/>

    <img src=”data:message/rfc822;charset=US-ASCII,Sat, 28 Mar 2009 13:04:08 +0100″ alt=”heute” />

    Also: img ist ein inline-Element (im Gegensatz zu object). Der Witz ist hier die Verwendung von data URIs (http://en.wikipedia.org/wiki/Data_URI_scheme). Den mime-Typ message/rfc822 gibt es bereits (http://www.w3.org/Protocols/rfc1341/7_3_Message.html und http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3

    Normalerweise bezeichnet rfc822 das mail Format. Aber anscheinend wird das auch in Zusammenhang mit dem in diesem Zusammenhang spezifizierten Zeitformat gesehen. Ist leider nicht das iso Zeitformat.

    Einen mime-typ message/iso8601 gibt’s leider nicht. Wäre auch zu schön. Aber text/plain als Notbehelf geht auch.

    Was passiert, ist folgendes: Ein “Bild” vom typ text/plain kann nicht gerendert werden. Stattdessen wird der alt-Text gerendert. Desgleichen für Screenreader. Falls irgendwann mal ein Browser in der Lage sein sollte, solch ein “Bild” zu rendern, könnte das z.B. eine lokalisierte Version des Datums sein. Möglichkeiten gäbe es da.

    Und vielleicht erbarmt sich ja mal Jemand und registriert message/iso8601.

    Nur so eine Idee…

    Theoretisch könnte man etwas Ähnliches mit dem <q> Element machen, in Verbindung mit dem cite Attribut. Allerdings halte ich dieses Element für eher weniger geeignet (semantik).