Euro-Symbol

[molily]

Hallo,

Die Idee, "EUR" als Abkürzung in HTML auszuzeichnen und mit der "Langform" zu betiteln, mag zwar rein logisch korrekt sein, dürfte aber bei allen Beteiligten mehr Verwirrung stiften, als erklärend wirken.

Wieso, inwiefern? In grafischen Browsern wird höchstwahrscheinlich eine Unterstreichnung und ein Tooltip angeboten, was meiner Meinung nach zwar weniger notwendig ist, da die Bedeutung für Sehende einfacher aus dem Kontext erkennbar ist und die Großbuchstabenfolge »EUR« geläufig ist, aber daran sehe ich nichts Verwirrendes.

Ich sehe darin aber etwas störendes, wenn man ständig diese Tooltipps kriegt.

Meiner Auffassung ist höchstens die Kennzeichnung durch Unterstreichung (border-bottom) störend, welche jedoch sich abschalten lässt.

Aber dankenswerter Weise hat sich das W3C ja mit den WCAG ausführlich beschäftigt und fordert lediglich für das _erste_ Auftreten einer Abkürzung deren Auszeichnung mit <abbr>.

Ehrlich gesagt weiß ich nicht, in wiefern das konkret helfen soll. Ein Screenreader-Benutzer »scannt« eine Seite genauso wie ein primär sehender Benutzer. Klassische Online-Dokumente mit mehreren Abschnitten werden nicht immer streng von oben nach unten ohne Auslassungen gelesen, so kommt es andauernd vor, dass das erste Auftauchen einer Abkürzung vollkommen übersehen wird und das Verständnis der folgenden Verwendung nicht verbessern. Da wäre der Verzicht auf abbr/acronym zugunsten eines Glossars sogar noch angemessener, was den nötigen Aufwand für den Benutzer aber nicht verringern würde, von Intuitivität ganz zu schweigen..

Und das erscheint mir sehr sinnvoll zu sein. Die Idee ist, dem Browser einmal einen Hinweis zu geben, wie die Abkürzung in der Langform heißt - gewünscht wäre, sie bei entsprechend konfigurierter Ausgabe dann automatisch auch überall sonst entsprechend verständlich zu machen.

Ich sehe diese Idee dahinter nicht und habe diese Begründung auch noch nirgendwo gelesen. Selbst wenn, mehr als Theorie ist nicht. Meines Wissens gibt es bisher kein Browser bzw. keine Zusatzsoftware, die das so handhabt. Ich nehme an, dass die Richtlinie von linearem Lesen von zusammenhängenden Texten ausgeht, wie etwa längere Artikel und Abhandlungen.
Ein Folgeproblem wäre sowieso, dass manche Screenreader lediglich das title-Attribut ausgeben, anstatt etwa die Abkürzung einzuführen, wie es in Offline-Texten üblich ist, nämlich beim ersten Auftreten die Langversion *und* die Abkürzung in Klammern zu nennen und im Folgenden nur noch die Abkürzung. Somit würde es nichts helfen, nur das erste Auftreten auszuzeichnen, weil die Verbindung zu den folgenden gleichen Abkürzung nicht erkennbar würde.

Was gewünscht wäre, finde ich reichlich irrelevant für die Entscheidung, ob abbr genutzt wird oder nicht, solange die von geschilderte Vorgehensweise rein utopisch ist und sich keine entsprechenden Ansätze zeigen. Mir ist die theoretische Konformität zu den WCAG gleichgültig, solange ich keine praktischen Vorteile im Hier und Jetzt sehe und niemand von dem profitiert, was die WCAG als ausreichend ansieht.

Wem soll damit geholfen werden?

Beispielsweise Screenreader-Benutzer mit Sprach- oder Brailleausgabe.

Die mir bekannte Vorlesesoftware enthält Bibliotheken, in welchen unter anderem Abkürzungen gelistet sind, damit diese in der Langform ausgesprochen werden.

JAWS 4.51 musste ich es manuell beibringen, EUR als Euro vorzulesen (hätte ich auch nicht erwartet). Vom IBM HPR habe ich Ähnliches in Erinnerung. Letztlich ist es wohl die Aufgabe des Benutzers, solche Wörterbücher anzulegen.

Reale Seiten bilden immer einen Kompromiss zwischen den Anforderungen der Benutzer, denen der Entwickler und den Unzulänglichkeiten der wiedergebenden Software.

Denn dass es sich bei "EUR-Angaben" um Preise handelt, dürfte relativ schnell jedem gebildeten Menschen klar sein.

Es ist ein Anspruch von Barrierefreiheit (oder nenne es ein Teil von Benutzbarkeit, wie auch immer), solche augenscheinlich selbstverständlichen Voraussetzungen zu hinterfragen. Ich sehe hier keinen Grund, eine potenzielle Barriere einzubauen, welche weniger gebildete Menschen benachteiligt, während »Euro« beziehungsweise EUR mit abbr auch für diese Menschen verständlich ist.

Dann frage ich mich wirklich, welche Menschen das sein sollen, die "EUR" nicht verstehen, aber "Euro".

Das sagte ich bereits.

Diese Menschen können ja in keinem Geschäft etwas kaufen, weil sie gar nicht wissen, was sie bezahlen müssen. Überall merkwürdige Schildchen mit dieser ominösen Abkürzung drauf, und niemand erzählt einem, was das heißt.

...

Zum Glück hat die Kassiererin bislang immer die Scheinchen mit dem Euro-Aufdruck akzeptiert...

Ja, und, um im Bild zu bleiben, es ist noch kein Analphabet verhungert.

Es geht ferner nicht nur um kennen oder nicht kennen, sondern um erkennen. Und dieses Erkennen ist einfacher möglich, wenn die Langform der Abkürzung beispielsweise beim Vorlesen ausgegeben wird. Abbr ist dazu das passende Element. Noch sicherer und kompatibler ist es, direkt »Euro« zu schreiben.

Was mir beim <abbr> wirklich fehlt, ist ein vernünftiges "das ist jetzt die Langform der ausgezeichneten Abkürzung"-Attribut. Mit "title" werde ich nicht wirklich glücklich. Das ist ein Universalattribut, welches mit beliebiger Bedeutung (welche, hängt sehr vom Autor ab) eingesetzt werden kann. Das W3C setzt hier "may" in der Erklärung ein, nicht "must" - also keine harte Verpflichtung.

Jaja, aber was ist daran problematisch? Das title-Attribut wird meines Wissens von allen Browsern/Zusatztools, die abbr/acronym verstehen, auch mit exakt dieser Bedeutung umgesetzt. Bei der Tooltip-Umsetzung musst der Zusammenhang natürlich im Kopf des Lesers entstehen, weil nicht ausdrücklich angemerkt wird, dass es sich bei der Zusatzinformation um die Auflösung der Abkürzung handelt.

Das »may« bezieht sich ausschließlich darauf, dass es dem Autor frei steht, eine Langversion anzubieten, das heißt, das title-Attribut ist technisch gesehen optional. Wenn der Autor ein title-Attribut in einem abbr- oder acronym-Element einsetzt, dann muss natürlich damit gerechnet werden, dass es im Zusammenhang mit diesen Elementen eine Sonderbedeutung erhält beziehungsweise so interpretiert wird. Darin sehe ich kein Problem, weil es extrem selten vorkommt, dass ein title-Attribut für abbr/acronym vergeben wird, ohne dass im title der Elementinhalt als Abkürzung gemeint ist.

Falls du darauf anspielst, dass die Specs den Browsern nicht vorschreiben, dass und wie die ausgeschriebene Variante angeboten werden muss - das liegt generell außerhalb dem Zuständigkeitsbereich der Specs, und was die Browser letztlich wie implementieren, ist deren Sache. Ein Beispiel ist das q-Element: Das »must« in »Visual user agents must ensure that the content of the Q element is rendered with delimiting quotation marks« wurde seit Jahren ignoriert. Mit anderen »Vorschriften« ist es ähnlich.

Genau deshalb wird der Sinn, den eine Auszeichnung machen könnte, auch noch sehr lange auf sich warten lassen, weil die Software es nicht auf die Reihe kriegt.

Hm? Siehe oben. Die Spec trägt dafür nicht die entscheidende Verantwortung. Dass die Browser bis vor einiger Zeit keine Notiz davon genommen haben, liegt sicherlich nicht daran, dass kein gesondertes Attribut beispielsweise namens expanded oder ähnliches alleinig für die Langversion zur Verfügung steht.

Von daher sehe ich in diesem speziellen Beispiel wirklich nur, dass drei Zeichen gegen 29 Zeichen eingetauscht werden,

Wie gesagt, ein Zeichen mehr reicht und die Sache ist gegessen.

die für die Mehrheit keinen wirklichen Mehrwert an Information bringt, stattdessen mit eher lachhaften Effekten ("aha, EUR heißt Euro - hätte ich ja nie gedacht") dank des Tooltipps amüsieren,

Das sehe ich ja prinzipiell ein - ganz Eifrige bestehen auch darauf, jede noch so geläufige Abkürzung wie bzw., usw., z.B., bspw., d.h., o.ä. und vergleichbare mit abbr auszuzeichnen, am besten sogar bei jedem Vorkommen. Das ist natürlich unvertretbarer Aufwand und bei durchgängiger grafischer Hervorhebung ein einziges Wirrwarr. So extrem ist es eher kontraproduktiv, andererseits ist es ratsam, nicht in einen Abkürzungsfimmel zurückzufallen, der alles abkürzt, was irgendwie abkürzbar ist.

und mangels Softwareausnutzung bei denen, die es vielleicht brauchen könnten, nicht ankommt.

Wie kommst du plötzlich darauf? Es ist, wie bereits gesagt, für existierende Screenreader-Benutzer real von Vorteil, Accessibility-Proxies und Benutzerstylesheets können auch davon Verwendung machen.

Mit anderen Worten: Eine Mehrheit muß leiden, damit eine Minderheit nicht glücklicher wird.

Ähm, »leiden«? Das ist selbst als Hyperbel ein schlechter Scherz.

Ok, 90% dieser Kritik fällt dank der Anweisung des W3C flach, dass die Abkürzung nur einmal (beim ersten Mal) mit <abbr> auszuzeichnen ist. Das klingt vernünftig.

Ich hatte nicht vor, über die WCAG 1.0 und deren abstrakten Empfehlungen zu diskutieren, sondern darüber, was real hilfreich ist.

Grüße,
Mathias