Kommentare zu: hAccessibility (Deutsche Übersetzung)

Von: Siegfried

Siegfried — Sat, 28 Mar 2009 12:24:47 +0000

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

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 Element machen, in Verbindung mit dem cite Attribut. Allerdings halte ich dieses Element für eher weniger geeignet (semantik).

Von: Markus Baersch

Markus Baersch — Wed, 07 Jan 2009 22:18:29 +0000

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?

Von: soso

soso — Thu, 19 Jun 2008 02:20:23 +0000

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”.
wäre nett, vielleicht lässt sich das w3c dazu erweichen?