Auszeichnung von Abkürzungen

[Auge]

Hallo

Da im Thread Barrierefreiheit des Forums vor kurzem das Title-Attribut zur Sprache kam und andererseits ich in den nächsten Tagen Texte zu übertragen habe, die Abkürzungen enthalten, will ich fragen, wie man die heutzutage auszeichnet.

Früher™️ hat man ja den abgezürzten Begriff im Title-Attribut notiert (<abbr title="Abkürzung">Abk.</abbr>). Heute wird propagiert, dass das Title-Attribut für wichtige Infos ungeeignet ist, weil es für Nicht-Maus-Nutzer nicht erreichbar, die darin Info also unzugänglich ist. Das Argument ist für mich nachvollziehbar, aber wohinein kommt der ausgeschriebene Begriff stattdessen, wenn ich eine Abkürzung benutze und sie als solche auszeichne?

Tschö, Auge

[MrMurphy1]

Hallo

die Abkürzungen enthalten, will ich fragen, wie man die heutzutage auszeichnet

Ganz einfach: Gar nicht. Barrierefreie (besser: zugängliche) Text enthalten keine Abkürzungen, da Abkürzungen selbst bereits Barrieren sind.

Du suchst also eine Lösung für ein Problem, welches du selbst schaffst.

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

Ganz einfach: Gar nicht. Barrierefreie (besser: zugängliche) Text enthalten keine Abkürzungen, da Abkürzungen selbst bereits Barrieren sind.

It depends.

Gängige Abkürzungen wie z.B. diese hier düften schneller aufgenommen werden als zum Beispiel die ausgeschriebene Phrase; der Lesbarkeit also zugute kommen.

Das setzt natürlich beim Leser die Kenntnis von gängigen Abkürzungen wie bspw. obige u.a. voraus. Kann man machen, denke ich. Für Texte in leichter Sprache mag das nicht gelten.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

Das setzt natürlich beim Leser die Kenntnis von gängigen Abkürzungen wie bspw. obige u.a. voraus.

Die Verwendung der Abkürzungen hier sind ein gutes Beispiel, wie man es nicht machen sollte 😉 ich bin beim lesen drüber gestolpert und musste ein zweites mal langsam lesen um zu verstehen, was du sagen wolltest.

LG,
CK

[MrMurphy1]

Hallo

Du berücksichtigst mit deiner Antwort leider nur einen Teil der betroffenen User. Nämlich diejenigen, welche die Abkürzungen selbst nicht kennen. Von denen es viel mehr gibt als gemeinhin vermutet wird, die aber häufig auf Grund von negativen Erfahrungen in der Vergangenheit auch nicht nachfragen mögen.

Du ignorierst aber diejenigen, die Texte nur Zeichen für Zeichen aufnehmen können, aus welchen Gründen auch immer. Zum Beispiel wenn die Zeichen extrem vergrößert werden müssen oder sie Brailleschrift verwenden oder einen Screenreader benötigen.

Die alle können Abkürzungen überhaupt nicht, wie die meisten User hier, im Vorfeld erkennen. Die müssen die Abkürzung zunächst vollkommen aufnehmen, dürfen dabei das Ende nicht verpassen (was teilweise sehr schwierig ist, da Abkürzungen korrekt geschrieben Leerzeichen enthalten können und nicht immer mit einem Punkt enden), sind deshalb zunächst schon ein Wort weiter, müssen dann im Kopf das ganze Zeichenkonstrukt komplett zusammensetzen und können danach überhaupt erst beginnen, die Abkürzung zu übersetzen.

Deshalb sind Abkürzungen selbst immer massive Barrieren. Wer barrierefreie Seiten erstellen will und dabei Abkürzungen verwendet hat Barrierefreiheit / Zugänglichkeit noch nicht mal ansatzweise begriffen.

Ich kann mir als Lösung nur vorstellen, das beide Formen (die ausgeschriebene und die abgekürzte) verwendet werden und dann dem jeweiligen Zielpublikum zugänglich gemacht werden.

Zum Beispiel wird der Text grundsätzlich ausgeschrieben dargestellt. Besucher, welche mit Abkürzungen vertraut sind und die den Text visuell aufnehmen können, können dann auf Buttonklick auf die Abkürzungen umschalten. Wenn der Besucher dann merkt, das der Autor viele Abkürzungen verwendet, die ihm nicht bekannt sind, kann er einfach wieder zurückschalten.

Ergebnis: Der Text ist barrierefrei und die User können selbst entscheiden.

Vorteil: so ein Lösung ist sehr simpel umzusetzen.

Gruss

MrMurphy

[Benedikt L.]

Hi!

Du ignorierst aber diejenigen, die Texte nur Zeichen für Zeichen aufnehmen können, aus welchen Gründen auch immer. Zum Beispiel wenn die Zeichen extrem vergrößert werden müssen oder sie Brailleschrift verwenden oder einen Screenreader benötigen.

Screenreader können gut mit Abkürzungen umgehen. Und Nutzer von Bildschirmlupen freuen sich eher wenn häufige Begriffe abgekürzt sind, sonst müssen sie sich ja noch mehr über den Bildschirm bewegen.

Die alle können Abkürzungen überhaupt nicht, wie die meisten User hier, im Vorfeld erkennen. Die müssen die Abkürzung zunächst vollkommen aufnehmen, dürfen dabei das Ende nicht verpassen (was teilweise sehr schwierig ist, da Abkürzungen korrekt geschrieben Leerzeichen enthalten können und nicht immer mit einem Punkt enden), sind deshalb zunächst schon ein Wort weiter, müssen dann im Kopf das ganze Zeichenkonstrukt komplett zusammensetzen und können danach überhaupt erst beginnen, die Abkürzung zu übersetzen.

Ich verstehe den Fall nicht den du hier beschreibst. Das Ausschreiben von Abkürzungen passiert bestenfalls im Fließtext bei der ersten Benutzung. Oder in einem verlinkten Glossar, wenn das "Ausschreiben" zur Erklärung nicht reicht. Ähnliches gilt für das Definieren eines Begriffs. Schau dir einmal die zugehörigen WCAG 2.0 Techniques an:

• https://www.w3.org/TR/WCAG-TECHS/G97.html
• https://www.w3.org/TR/WCAG-TECHS/G101.html
• https://www.w3.org/TR/WCAG-TECHS/G102.html

Und Understanding WCAG 2.0:

• https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-located.html

Deshalb sind Abkürzungen selbst immer massive Barrieren. Wer barrierefreie Seiten erstellen will und dabei Abkürzungen verwendet hat Barrierefreiheit / Zugänglichkeit noch nicht mal ansatzweise begriffen.

So radikal würde ich das keinesfalls formulieren!

Ja, Abkürzungen sind möglichst zu vermeiden. Aber sie kommen in der Sprache und damit auf Webseiten vor. Es gilt sie bewusst und zugänglich zu verwenden.

Ich kann mir als Lösung nur vorstellen, das beide Formen (die ausgeschriebene und die abgekürzte) verwendet werden und dann dem jeweiligen Zielpublikum zugänglich gemacht werden.

Doppel-Lösungen versucht man eigentlich zu vermeiden in der Barrierefreiheit!

Zum Beispiel wird der Text grundsätzlich ausgeschrieben dargestellt. Besucher, welche mit Abkürzungen vertraut sind und die den Text visuell aufnehmen können, können dann auf Buttonklick auf die Abkürzungen umschalten. Wenn der Besucher dann merkt, das der Autor viele Abkürzungen verwendet, die ihm nicht bekannt sind, kann er einfach wieder zurückschalten.

Davon würde ich abraten. Es ist verwirrend wenn alle Abkürzungen ausgeschrieben werden. Texte werden dadurch schlecht lesbar. Ein Text über "EU", "NATO" und "UN" wird nicht verständlicher wenn überall "Europäische Union", "Nordatlantisches Verteidigungs-Bündnis" und "Vereinte Nationen" steht. Außerdem gehört NATO zu den "aussprechbaren" Abkürzungen, ist also selbst ein Wort.

Die WCAG geben dies bezüglich Techniken vor an denen man sich orientieren sollte, genauer gesagt MUSS um WCAG konform zu sein.

Vorteil: so ein Lösung ist sehr simpel umzusetzen.

Ich finde es ganz und gar nicht simpel eine Doppel-Lösung umzusetzen. Wenn einen Screenreader Benutzer die ausgeschriebenen Abkürzungen nerven, muss er erst den Button finden. (Woher weiß er, dass es ihn gibt?) Und dann wieder an die Text-Stelle zurückgehen, wo er herkam. Nicht gut.

Grüße

Benedikt

[marctrix]

Hej Benedikt,

Screenreader können gut mit Abkürzungen umgehen. Und Nutzer von Bildschirmlupen freuen sich eher wenn häufige Begriffe abgekürzt sind, sonst müssen sie sich ja noch mehr über den Bildschirm bewegen.

Was des einen Freud, ist des anderen Leid - @mrmurphy hat ja wohl eher Menschen mit Konzentrationsschwäche, Lese-Rechtschreicb-Schwäche und/oder anderen kognitiven Einschränkungen gemeint.

Insofern habt ihr beide recht - ein typisches Dilemma der Barrierefreiheit. Einer der Gründe, warum barrierefreie Seiten (vom Nutzer) anpassbar sein müssen:

Guideline 1.3: Present content in different ways

Die alle können Abkürzungen überhaupt nicht, wie die meisten User hier, im Vorfeld erkennen. Die müssen die Abkürzung zunächst vollkommen aufnehmen, dürfen dabei das Ende nicht verpassen (was teilweise sehr schwierig ist, da Abkürzungen korrekt geschrieben Leerzeichen enthalten können und nicht immer mit einem Punkt enden), sind deshalb zunächst schon ein Wort weiter, müssen dann im Kopf das ganze Zeichenkonstrukt komplett zusammensetzen und können danach überhaupt erst beginnen, die Abkürzung zu übersetzen.

Ich verstehe den Fall nicht den du hier beschreibst. Das Ausschreiben von Abkürzungen passiert bestenfalls im Fließtext bei der ersten Benutzung. Oder in einem verlinkten Glossar, wenn das "Ausschreiben" zur Erklärung nicht reicht. Ähnliches gilt für das Definieren eines Begriffs. Schau dir einmal die zugehörigen WCAG 2.0 Techniques an:

Und Understanding WCAG 2.0:

• https://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-located.html

Da steht beispielsweise

Expanded forms of Abbreviations The expanded form of each abbreviation is available in a programmatically determinable manner. User agents that speak the text can use the expanded form to announce the abbreviation. Other user agents might make the expanded form available as a tooltip or as contextual help for the abbreviation.

Wie Auge aber bereits in seinem Ausgangsposting einleitend anmerkte sind title−Texte keinesfalls allen zugänglich. Nur Screenreader-Nutzer könnten sie sehen (wenn sie das nicht aus nachvollziehbaren Gründen abgeschaltet haben, was meist der Fall sein dürfte) und Nutzer mit einer Maus, die die Maus auch noch lang genug unbeweglich über der Abkürzung stehen lassen. Konventionen zur Auszeichnung von Abkürzung (gepunktete Unterstreichung) haben sich nie durchgesetzt und dürften mindestens die von mrmurphy angesprochene Zielgruppe vor weitere Probleme stellen.

Es dürfte sicher auch Menschen ohne kognitive Beeinträchtigungen verwirren, wenn Texte markiert sind, bei denen sich aber nichts tut (auf einem Tablet beispielsweise).

Insofern sehe ich hier Probleme in der WCAG, die inzwischen allgemein bekannt sein dürften. Die WCAG sollte nicht als Glaubensmanifest gesehen werden. Solche Fehler sind selten, aber sie kommen vor.

Letztendlich kommt es nur auf den Nutzer an.

In den meisten Fällen werden die vom Verzicht von Abkürzungen profitieren, auch wenn du schöne Beispiele für Ausnahmen gebracht hast.

Don't make me think gilt eben nicht für Entwickler und Redakteure. Wann Abkürzungen bekannt genug sind um nur einmal aufgelöst zu werden (beim ersten Auftreten), muss bedacht werden: bei jedem Begriff unter Berücksichtigung der Zielgruppe.

Einem Legastheniker, der bei der UN beschäftigt ist, muss man UN nicht als Vereinte Nationen "übersetzen".

Ich kann mir als Lösung nur vorstellen, das beide Formen (die ausgeschriebene und die abgekürzte) verwendet werden und dann dem jeweiligen Zielpublikum zugänglich gemacht werden.

Doppel-Lösungen versucht man eigentlich zu vermeiden in der Barrierefreiheit!

Ja, aber Anpassbarkeit ist eine Forderung (siehe oben).

Zum Beispiel wird der Text grundsätzlich ausgeschrieben dargestellt. Besucher, welche mit Abkürzungen vertraut sind und die den Text visuell aufnehmen können, können dann auf Buttonklick auf die Abkürzungen umschalten. Wenn der Besucher dann merkt, das der Autor viele Abkürzungen verwendet, die ihm nicht bekannt sind, kann er einfach wieder zurückschalten.

Davon würde ich abraten. Es ist verwirrend wenn alle Abkürzungen ausgeschrieben werden. Texte werden dadurch schlecht lesbar. Ein Text über "EU", "NATO" und "UN" wird nicht verständlicher wenn überall "Europäische Union", "Nordatlantisches Verteidigungs-Bündnis" und "Vereinte Nationen" steht.

Sagt wer? - Wohl nur diejenigen, die so "funktionieren" wie du. Andere würden vielleicht eine andere Darstellung vorziehen. Warum bist du dagegen, dem Nutzer eine Wahlmöglichkeit anzubieten?

Die WCAG geben dies bezüglich Techniken vor an denen man sich orientieren sollte, genauer gesagt MUSS um WCAG konform zu sein.

Vorteil: so ein Lösung ist sehr simpel umzusetzen.

Ich finde es ganz und gar nicht simpel eine Doppel-Lösung umzusetzen. Wenn einen Screenreader Benutzer die ausgeschriebenen Abkürzungen nerven, muss er erst den Button finden. (Woher weiß er, dass es ihn gibt?) Und dann wieder an die Text-Stelle zurückgehen, wo er herkam. Nicht gut.

Touché.

Wer ist wichtiger Menschen ohne Augenlicht oder Menschen mit kognitiven Einschränkungen? Wer entscheidet? Freiwillige vor.

Mitunter widersprechen sich die Bedürfnisse von mehreren Nutzern. Darum ist Anpassbarkeit wichtig. mrmurphy hat hier eine Idee eingebracht, kein komplett durchdachtes Konzept. Deine Hinweise sollten bei einer eventuellen Umsetzung berücksichtigt werden.

Um zur Ausgangsfrage von @Auge zurück zu kommen:

Ich bevorzuge es, gängige Abkürzungen bei der ersten Verwendung aufzulösen, so wie man es im Deutschunterricht in der Schule gelernt hat:

Die UN (Vereinte Nationen) empfehlen…

Weiter würde ich nur noch UN benutzen, aber mit der Möglichkeit die Abkürzung einzublenden (für Screenreader-Nutzer als WAI-ARIA-Attribut, für Mausnutzer und Tablet-Nutzer als Tooltipp - ich würde per CSS den Inhalt des ARIA-Attributes ausgeben, dann muss die Maus nicht über dem Text verweilen).

Menschen mit Konzentrationsschwäche kann das allerdings auch ablenken. Das ist nun von mir ein Schnellschuss und nicht der Weisheit letzter Schluss. Müsste ich noch mal die entsprechenden Stellen der WCAG im Detail durchlesen und eigene Überlegungen hinzufügen.

Mal sehen, was andere dazu geschrieben habe, melde mich dann nach entsprechender Lektüre noch mal zu Wort…

Marc

[Gunnar Bittersmann]

@@marctrix

mit der Möglichkeit die Abkürzung einzublenden (für Screenreader-Nutzer als WAI-ARIA-Attribut …)

Wie genau soll das gehen?

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

mit der Möglichkeit die Abkürzung einzublenden (für Screenreader-Nutzer als WAI-ARIA-Attribut …)

Wie genau soll das gehen?

Hatte noch keinen konkreten Bedarf das Problem zu lösen, komplett durchzudenken und zu testen. Eine erste Idee für eine Überlegung wäre:

HTML

<abbr aria-describedby="un" tabindex="0">UN<span class="visuallyhidden" id="un"> Vereinte Nationen</span></abbr>

CSS

/* Original from H5BP.com */
.visuallyhidden { border: 0; clip: rect(0 0 0 0); height: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute; width: 1px; }

abbr:hover span.visuallyhidden,
abbr:focus span.visuallyhidden,
abbr:active span.visuallyhidden { clip: auto; height: auto; margin: 0; overflow: visible; position: static; width: auto; }

Marc

[Gunnar Bittersmann]

@@marctrix

mit der Möglichkeit die Abkürzung einzublenden (für Screenreader-Nutzer als WAI-ARIA-Attribut …)

Wie genau soll das gehen?

Hatte noch keinen konkreten Bedarf das Problem zu lösen, komplett durchzudenken und zu testen. Eine erste Idee für eine Überlegung wäre:

HTML

<abbr aria-describedby="un" tabindex="0">UN<span class="visuallyhidden" id="un"> Vereinte Nationen</span></abbr>

Wie schon gesagt: “No, because like -label, -labelledby & -describedby are not recognised on <abbr>.” —Léonie Watson

LLAP 🖖

[marctrix]

Hej Gunnar,

Wie schon gesagt: “No, because like -label, -labelledby & -describedby are not recognised on <abbr>.” —Léonie Watson

Hättest du nicht gefragt, hätte ich den Thread schon durchgelesen…

Marc

[Matthias Apsel]

Hallo marctrix,

Was des einen Freud, ist des anderen Leid - @mrmurphy hat ja wohl eher Menschen mit Konzentrationsschwäche, Lese-Rechtschreicb-Schwäche und/oder anderen kognitiven Einschränkungen gemeint.

Nicht mrmurhy, MrMurphy1 😜

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Was des einen Freud, ist des anderen Leid - @mrmurphy hat ja wohl eher Menschen mit Konzentrationsschwäche, Lese-Rechtschreicb-Schwäche und/oder anderen kognitiven Einschränkungen gemeint.

Nicht mrmurhy, MrMurphy1 😜

ups…

Marc

[Gunnar Bittersmann]

@@Auge

Früher™️ hat man ja den abgezürzten Begriff im Title-Attribut notiert (<abbr title="Abkürzung">Abk.</abbr>). Heute wird propagiert, dass das Title-Attribut für wichtige Infos ungeeignet ist

Die Frage hier ist: Ist die Info denn wichtig? Bei gängigen Abkürzungen sollte sie es nicht sein. Nicht gängige Abkürzungen sollten nicht verwendet werden.

aber wohinein kommt der ausgeschriebene Begriff stattdessen, wenn ich eine Abkürzung benutze und sie als solche auszeichne?

Ich hab die Frage mal durchgereicht.

LLAP 🖖

[Auge]

Hallo

Die Frage hier ist: Ist die Info denn wichtig? Bei gängigen Abkürzungen sollte sie es nicht sein. Nicht gängige Abkürzungen sollten nicht verwendet werden.

Die Abkürzung der Wochentage halte ich durchaus für gängig und auch du hast sie in einem Thread, in dem es unter Anderem um Öffnungszeiten ging (wenn auch in einem anderen Zusammenhang), verwendet. Dem Argument der Gängigkeit der Abkürzung folgend, könnte man die Ausschreibung theoretisch weglassen und nur die Abkürzung als Abkürzung auszeichnen (<abbr>Mo</abbr>).

Die semantische Auszeichnung der einzelnen Angaben kommt dann noch oben drauf. Ehedem habe ich das mit Microformats erledigt, aber das scheint heutzutage nicht mehr verwendet zu werden. Schade eigentlich, mir hat die Systematik recht gut gefallen. Du propagierst hier ja immer schema.org. Laut den Angaben des Microformats-Wikis zur Browserunterstützung unterstützen die meisten Browser deren System nativ oder durch Plugins. Allerdings ist diese Wiki-Seite letztmalig 2014 aktualisiert worden.

Die Wikipedia nennt Daten aus 2012 und aus 2013 zur Verbreitung von Microformats, Microdata und RDFa, die eine Verschiebung von Microformats hin zu RDFa und Microdata aufzeigen. Andererseits heißt es auf der Wikipedia-Seite zu Schema.org „Ein Großteil der Klassen und Attribute von schema.org wurde aus früheren Formaten wie etwa Mikroformats, FOAF, GoodRelations und OpenCyc übernommen.“ Welches System ist heute zu bevorzugen? Gibt es da einen klaren Sieger?

Tschö, Auge

[Martl]

Hallo Gunnar,

definiere "gängig"; das dürfte wohl von Fall zu Fall, Zielgruppe zu Zielgruppe usw.[!] unterschiedlich gesehen werden.

Praktikabel sollte sein: Den Begriff bei seinem ersten Auftreten im Text ausschreiben und mit der Abkürzung "verknüpfen", z.B.[!]: "Bürgerliches Gesetzbuch" (<abbr>BGB</abbr>). Ein zusätzliches title-Attribut kann, muß aber nicht sein.

Schön wäre natürlich, wenn es eine ähnliche Logik wie bei label/input gäbe, vielleicht in HTML6?

Grüße, Martl

[Auge]

Hallo

definiere "gängig"; das dürfte wohl von Fall zu Fall, Zielgruppe zu Zielgruppe usw.[!] unterschiedlich gesehen werden.

Die Abkürzungen der Wochentage, um die es hier geht, halte ich, wie schon gesagt, durchaus für gängig. Ich kann aber auch das von MrMurphy vorgebrachte Argument, dass es Einschränkungen gibt, die es einem nicht möglich machen, ein Wort oder eine zusammengehörige Wortgruppe in seiner Gesamtheit zu erfassen, nachvollziehen. Damit ist selbst eine gängige Abkürzung eine Barriere. Gerade die Abkürzungen der Wochentage, die meist ohne den eine Abkürzung markierenden Punkt geschrieben werden, erschließen sich ja normalerweise aus dem Kontext des Textes, der unter Umständen nicht einfach erfassbar ist.

Praktikabel sollte sein: Den Begriff bei seinem ersten Auftreten im Text ausschreiben und mit der Abkürzung "verknüpfen", z.B.[!]: "Bürgerliches Gesetzbuch" (<abbr>BGB</abbr>). Ein zusätzliches title-Attribut kann, muß aber nicht sein.

In Wikipedia-Artikeln ist dieses Schema ja gängig und damit bekannt, aber in meinem Fall dürfte das so nicht machbar sein. Ich werde die Wochentagsnamen wohl ausschreiben. Interessieren täte mich die aktuell gängige Art der Auszeichnung von Abkürzungen allerdings dennoch.

Tschö, Auge

[Gunnar Bittersmann]

@@Martl

definiere "gängig"; das dürfte wohl von Fall zu Fall, Zielgruppe zu Zielgruppe usw.[!] unterschiedlich gesehen werden.

Natürlich.

Und wenn die Zielgruppe (so gut wie) alle sind, muss man einen kleinsten gemeinsamen Nenner finden. „z.B.“, „u.a.“ „usw.“ und die Abkürzung von Wochentagen dürften dazugehören.

(Mal abgesehen davon, dass man dann vielleicht bei seiner Zielgruppenanalyse was falsch gemacht hat. ;-))

Praktikabel sollte sein: Den Begriff bei seinem ersten Auftreten im Text ausschreiben und mit der Abkürzung "verknüpfen", z.B.[!]: "Bürgerliches Gesetzbuch" (<abbr>BGB</abbr>). Ein zusätzliches title-Attribut kann, muß aber nicht sein.

Zumal es Screenreadernutzern so gut wie gar nicht hilft, wie Marco sagte.

Schön wäre natürlich, wenn es eine ähnliche Logik wie bei label/input gäbe, vielleicht in HTML6?

Oder doch schon heute?

… <b id="abbr-bgb">Bürgerliches Gesetzbuch</b> (<abbr>BGB</abbr>) …
  ⋮
… im <abbr aria-describedby="abbr-bgb">BGB</abbr> …

Oder gar aria-labelledby? Nutzer dürften sich allerdings über den Grammatikfehler wundern, wenn denn „im Bürgerliches Gesetzbuch“ vorgelesen würde.

LLAP 🖖

EDIT: Code als nicht brauchbar markiert, siehe Antwort

[Martl]

Hallo Gunnar,

Oder doch schon heute?

iGuck™: guter Hinweis.

...über den Grammatikfehler wundern...

Nominativ Singular als Definition verwenden und mögliche Grammatikfehler als Schönheitsfehler abhaken. Alternativ: Rechtschreib- und Grammatikautmatik einbauen;)

Grüße, Martl

[Gunnar Bittersmann]

@@Martl

iGuck™: guter Hinweis.

Nö. Guck lieber zweimal.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Oder doch schon heute?

… <b id="abbr-bgb">Bürgerliches Gesetzbuch</b> (<abbr>BGB</abbr>) …
  ⋮
… im <abbr aria-describedby="abbr-bgb">BGB</abbr> …

Nö.

Oder gar aria-labelledby?

“No, because like -label, -labelledby & -describedby are not recognised on <abbr>.” —Léonie Watson

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Léonie verwies mich noch auf Using the HTML title attribute von Steve Faulkner. Darin:

“The title on the abbr element is well supported by screen reader software, but its use is still problematic, as other user groups cannot access the expansion. It is recommended that the expanded form of an abbreviation is provided in plain text when it is first used in a document, and/or a glossary of terms that provides the expanded form is provided. This is not to suggest that that the expansion should not be provided using the title attribute, only that due to its limitations, an expansion in plain text should also be provided.”

LLAP 🖖

[Matthias Apsel]

Hallo Auge,

aber wohinein kommt der ausgeschriebene Begriff stattdessen, wenn ich eine Abkürzung benutze und sie als solche auszeichne?

In Markdown kann man das z.B. so machen:

*[z.B.]: zum Beispiel

*[z.B.]: zum Beispiel

Ich weiß, das war nicht deine Frage.

Bis demnächst
Matthias

[Auge]

Hallo

W.H.O.W. (Whow!)! Mit einer derart kontrovers geführten Diskussion habe ich bei diesem Thema nicht gerechnet.

Um den bisherigen Verlauf zusammenzufassen.

1. Es gibt in der jeweils verwendeten Sprache gängige Abkürzungen und solche, die einer Erläuterung bedürfen.
2. Es geht um geschriebene Texte. In geschriebenen Texten sind Abkürzungen in den meisten Fällen vermeidbar.
3. In manchen Fällen, wie zum Beispiel Eigennamen, deren Abkürzung gängiger ist, als der ausgeschriebene Name, sollte die Abkürzung verwendet, aber bei ihrer ersten Verwendung auch ausgeschrieben werden ^[1].
4. In manchen anderen Fällen, wie zum Beispiel Abkürzungen aus Fremdsprachen oder solchen, die in bestimmten Gruppen eine andere Bedeutung haben als für Menschen außerhalb dieser Kreise, bedarf eine Abkürzung auch einer Erklärung ^[2].

Der Anwendungsfall, dessentwegen ich hier fragte, ist eine Auflistung von Öffnungszeiten. Die Abkürzungen der Wochentage (Mo, Di, Mi, Do, Fr, Sa, So) sind zumindest für deutschsprachige Muttersprachler zweifellos als gängig zu bezeichnen. Ich möchte zudem davon ausgehen, dass auch einigermaßen in der deutschen Sprache geübte Fremdsprachler, die deswegen die deutschsprachige Version der Website mit einiger Wahrscheinlichkeit aufrufen dürften, diese Abkürzungen kennen. Es sollte also kein Problem sein, die Abkürzungen zu verwenden. Dennoch komme ich nicht ohne diverse „aber“ aus.

Die hier mehrfach vorgeschlagene Ausschreibung ^[3] bei der erstmaligen Verwendung der Abkürzung ist in einer solchen Liste allerdings irgendwie sinnlos. In der Liste wird jede der verwendeten Abkürzungen (jeder der aufgelisteten Wochentage) ^[4] nur jeweils einmal genannt.

Werden die Abkürzungen benutzt und stehen sie einfach so wie Wörter da und sind nicht als Abkürzungen gekennzeichnet, werden sie von Screenreadern auch als Worte vorgelesen. Nur „So“ für den Sonntag ergibt ein tatsächlich in der deutschen Sprache existierendes Wort, dessen Verwendung in der Liste aber so überhaupt keinen Sinn ergibt („So Schließtag“?). Mir erscheint somit eine Markierung der Abkürzungen als Abkürzung als sinnvoll.

Mit der Markierung allein ergibt sich allerdings immer noch nicht die richtige Aussprache. Es gibt schließlich verschiedene Arten von Abkürzungen. Da wären kurzgeschriebene einzelne Worte, wie zum Beispiel „Mo“ für „Montag“ oder „bzw.“ für „beziehungsweise“, weiterhin gibt es Abkürzungen für Begriffe aus mehreren Worten, zum Beispiel „u.s.w.“ für „und so weiter“. Daneben die Unterscheidung zwischen einer als Wort gesprochenen Abkürzung, gerne auch bei zusammengesetzten Eigennamen verwendet, beispielsweise DESY, und als Buchstaben gesprochene Abkürzungen (wenn sie denn als Buchstaben gesprochen werden), beispielsweise „LKW“ oder eben „bzw.“ oder „u.s.w.“. Vorgelesen werden sollten sie, bis auf als Abkürzung gängige Eigennamen (DESY, NATO), aber als vollständige Worte.

[edit]Nicht vergessen werden sollten die von MrMurphy vorgebrachten Fälle von Menschen mit Konzentrations- und/oder Verständnisschwierigkeiten. Die brauchen unter Umständen immer wieder das volle Wort statt der Abkürzung. Sei es, weil sie sich die Bedeutung von Abkürzungen über einen Fließtext hinweg nicht merken können, sei es, weil sie das Umswitchen zwischen Wortfolgen und Abkürzungen aus dem Lesefluss bringt. Spätestens da sind wir nämlich je nach Laune, Stimmung und Tageszeit bei „Jedermann“ und nicht nur bei offensichtlich gesundheitlich eingeschränkten Menschen.[/edit]

Eine bei der Abkürzung stehende Ausschreibung/Erklärung, wie sie für einen Fließtext zweifelsohne die bessere Wahl ist, passt in einer Liste, wie der skizzierten, einfach nicht. Also sollte man der Abkürzung per Attribut die Ausschreibung beifügen können. Wie Gunnar bei Marco Zehe in Erfahrung brachte, wird das Title-Attribut nur von JAWS und nur nach Anpassungen der Konfiguration benutzt ^[5]. Allerdings verweist Gunnar auch auf Steve Faulkner ^[6], der schreibt, dass das Title-Attribut von Screenreadern breit unterstützt wird, aber eben für andere Benutzergruppen (beispielsweise am Touchscreen) unzugänglich bleibt.

Womit wir quasi wieder am Anfang wären. In meiner Liste werde ich die Wochentagsnamen ausschreiben. Ich hoffe aber, dass die in diesem Thread ausgebreiteten Gedanken spätere Leser nicht nur verwirren, sondern ihnen auch helfen, Entscheidungen für den jeweils konktreten Fall zu treffen.

Die Links in den Fußnoten ^[1:1] und ^[2:1] wurden in diesem Thread ursprünglich von Benedict L. eingeführt ^[7].

Tschö, Auge

---

1. G97: Providing the first use of an abbreviation immediately before or after the expanded form ↩︎ ↩︎

2. G102: Providing the expansion or explanation of an abbreviation ↩︎ ↩︎

3. Martl, 06.06.2017 12:57, Benedict L., 06.06.2017 21:53 ↩︎

4. Da die Öffnungszeiten von Montag bis Freitag identisch sind, möchte ich sie für diese Tage zusammenfassen („Mo bis Fr: …“). Die einzelne Auflistung für jeden der Tage blähte die Liste mMn nur unnötig auf. ↩︎

5. Marco Zehe auf Twitter ↩︎

6. Gunnar Bittersmann, 06.06.2017 16:08 ↩︎

7. Benedict L., 06.06.2017 21:53 ↩︎

[Gunnar Bittersmann]

@@Auge

Werden die Abkürzungen benutzt und stehen sie einfach so wie Wörter da und sind nicht als Abkürzungen gekennzeichnet, werden sie von Screenreadern auch als Worte vorgelesen. Nur „So“ für den Sonntag ergibt ein tatsächlich in der deutschen Sprache existierendes Wort, dessen Verwendung in der Liste aber so überhaupt keinen Sinn ergibt („So Schließtag“?).

Ich wäre mir da nicht so sicher, dass das für Screenreader-Nutzer keinen Sinn ergibt. Ich denke, unzählige Webseiten verwenden „So“ für „Sonntag“ – und das auch noch ohne dass das als Abkürzung gekennzeichnet wäre. Screenreader-Nutzer könnten gelernt haben und daran gewöhnt sein, das „So“ in bestimmten Kontexten „Sonntag“ bedeutet und recht problemlos den Sinn erfassen.

Daneben die Unterscheidung zwischen einer als Wort gesprochenen Abkürzung, gerne auch bei zusammengesetzten Eigennamen verwendet, beispielsweise DESY, und als Buchstaben gesprochene Abkürzungen

Und es gibt Mischformen: WCAG, KFOR, …

(wenn sie denn als Buchstaben gesprochen werden) beispielsweise „LKW“ oder eben „bzw.“ oder „u.s.w.“.

?? Wer sagt denn ernsthaft „bezettwe“ oder „ueswe“?

Vorgelesen werden sollten sie, bis auf als Abkürzung gängige Eigennamen (DESY, NATO), aber als vollständige Worte.

Nö, es sollte auch „Elkawe“ vorgelesen werden, nicht „Lastkraftwagen“.

LLAP 🖖

[Auge]

Hallo

Werden die Abkürzungen benutzt und stehen sie einfach so wie Wörter da und sind nicht als Abkürzungen gekennzeichnet, werden sie von Screenreadern auch als Worte vorgelesen. Nur „So“ für den Sonntag ergibt ein tatsächlich in der deutschen Sprache existierendes Wort, dessen Verwendung in der Liste aber so überhaupt keinen Sinn ergibt („So Schließtag“?).

Ich wäre mir da nicht so sicher, dass das für Screenreader-Nutzer keinen Sinn ergibt. Ich denke, unzählige Webseiten verwenden „So“ für „Sonntag“ – und das auch noch ohne dass das als Abkürzung gekennzeichnet wäre. Screenreader-Nutzer könnten gelernt haben und daran gewöhnt sein, das „So“ in bestimmten Kontexten „Sonntag“ bedeutet und recht problemlos den Sinn erfassen.

„So“ war nur das Beispiel für eine Abkürzung, die auch ein Wort ergibt. Das Vorlesen der Abkürzungen für die anderen Tage halte ich aber für irgendwie komisch. Jene mit Vokalen lassen sich ja noch einfach sprechen, aber „Fr“? Nicht, dass sich „Fr“ nicht sprechen ließe, aber gesprochen kommt das eben unnatürlich herüber (mMn).

Daneben die Unterscheidung zwischen einer als Wort gesprochenen Abkürzung, gerne auch bei zusammengesetzten Eigennamen verwendet, beispielsweise DESY, und als Buchstaben gesprochene Abkürzungen

Und es gibt Mischformen: WCAG, KFOR, …

K-For ist klar, aber wie wird WCAG „gemischt“?

(wenn sie denn als Buchstaben gesprochen werden) beispielsweise „LKW“ oder eben „bzw.“ oder „u.s.w.“.

?? Wer sagt denn ernsthaft „bezettwe“ oder „ueswe“?

Ich, wenn ich weiß, wem ich damit mit einem Augenzwinkern kommen kann. In einem ernsthaften Kontext macht das — inklusive mir — natürlich niemand. Beim leise lesen aber wandle ich nicht unbedingt jede Abkürzung um. Ich dachte, diese Unterscheidung mit „Vorgelesen werden sollten sie“ klargemacht zu haben. Das ist wohl nicht so rübergekommen, wie ich mir das gedacht habe.

Vorgelesen werden sollten sie, bis auf als Abkürzung gängige Eigennamen (DESY, NATO), aber als vollständige Worte.

Nö, es sollte auch „Elkawe“ vorgelesen werden, nicht „Lastkraftwagen“.

Sag' ich doch: „und als Buchstaben gesprochene Abkürzungen …, beispielsweise „LKW““.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

„So“ war nur das Beispiel für eine Abkürzung, die auch ein Wort ergibt. Das Vorlesen der Abkürzungen für die anderen Tage halte ich aber für irgendwie komisch. Jene mit Vokalen lassen sich ja noch einfach sprechen, aber „Fr“? Nicht, dass sich „Fr“ nicht sprechen ließe, aber gesprochen kommt das eben unnatürlich herüber (mMn).

Ob uns das unnatürlich erscheint, ist irrelevant. Die Frage ist: Wie kommt das bei Screenreader-Nutzern rüber, die das vielleicht ständig so hören?

K-For ist klar, aber wie wird WCAG „gemischt“?

Ich hab das immer (englisch) als [ˈwikæg] gehört.

LLAP 🖖

[marctrix]

Hej Gunnar,

@@Auge

„So“ war nur das Beispiel für eine Abkürzung, die auch ein Wort ergibt. Das Vorlesen der Abkürzungen für die anderen Tage halte ich aber für irgendwie komisch. Jene mit Vokalen lassen sich ja noch einfach sprechen, aber „Fr“? Nicht, dass sich „Fr“ nicht sprechen ließe, aber gesprochen kommt das eben unnatürlich herüber (mMn).

Ob uns das unnatürlich erscheint, ist irrelevant. Die Frage ist: Wie kommt das bei Screenreader-Nutzern rüber, die das vielleicht ständig so hören?

Abkürzungen sind nicht allein ein Problem von SR-Nutzern!

Insbesondere kognitive Einschränkungen betreffen uns alle mehr oder weniger regelmäßig, wie Auge bereits anmerkte…

Die Zusammenfassung von Auge find eich ziemlich gut. Das Problem muss in erster Linie redaktionell mit Menschenverstand gelöst werden unter (nochmal) Berücksichtigung der Zielgruppe.

Marc

[Auge]

Hallo

„So“ war nur das Beispiel für eine Abkürzung, die auch ein Wort ergibt. Das Vorlesen der Abkürzungen für die anderen Tage halte ich aber für irgendwie komisch. Jene mit Vokalen lassen sich ja noch einfach sprechen, aber „Fr“? Nicht, dass sich „Fr“ nicht sprechen ließe, aber gesprochen kommt das eben unnatürlich herüber (mMn).

Ob uns das unnatürlich erscheint, ist irrelevant. Die Frage ist: Wie kommt das bei Screenreader-Nutzern rüber, die das vielleicht ständig so hören?

Abkürzungen sind nicht allein ein Problem von SR-Nutzern!

Im fraglichen Abschnitt meines Postings ging es tatsächlich konkret um Screenreader-Nutzer, die eine Abkürzung ohne entsprechende Auszeichnung als ein nicht existierendes Wort vorgelesen bekommen (wie ich vermute). Aber ja, die Frage, wie in verschiedenen Szenarien mit Abkürzungen umzugehen ist, betrifft bei weitem nicht nur Screenreader-Nutzer. Das haben wir, bei allen Unterschieden in der Betrachtung, hier ja alle herausgeschält.

Insbesondere kognitive Einschränkungen betreffen uns alle mehr oder weniger regelmäßig, wie Auge bereits anmerkte…

Der erste, der das ins Spiel brachte, war MrMurphy. Selbst wenn seine Betrachtung einseitig (mMn zu) auf solche Einschränkungen abstellt, ist das von ihm beschriebene Problem nicht zu unterschätzen. Für einen Menschen, der beispielsweise aufgrund einer Einschränkung der Sehfähigkeit eine sehr starke Vergrößerung benötigt, so dass er auf einen Blick auf dem Monitor bestenfalls ein paar Buchstaben sehen kann, zerreißt jede ungewohnte Buchstabenstellung und damit wohl auch viele Abkürzungen den Lesefluss. Ich durfte das selbst miterleben. 😟

Die Zusammenfassung von Auge find ich ziemlich gut.

Danke.

Tschö, Auge

[Tabellenkalk]

Hallo,

Nö, es sollte auch „Elkawe“ vorgelesen werden, nicht „Lastkraftwagen“.

Nö, nicht Elkawe, sondern Ellkaweh…

Gruß
Kalk

[Matthias Apsel]

Hallo Auge,

Und zur gängigen Auszeichnung mit title-Attribut sagt Heydon Pickering: „That is the standard way. There is no good way.“

Bis demnächst
Matthias

[marctrix]

Hej Matthias,

Hallo Auge,

Und zur gängigen Auszeichnung mit title-Attribut sagt Heydon Pickering: „That is the standard way. There is no good way.“

Habe ich auch befürchtet — einige Probleme von title habe ich hier ja erwähnt (für Sehende wie Blinde).

Ich experimentiere derzeit auf CodePen noch ein wenig herum, so wird die Auflösung der Abkürzung zumindest für Blinde und für Tablet-Nutzer zugänglich (Mausnutzern sowieso).

Die Frage ist immer ncoh: wie Sehende darauf hinweisen?

Marc