WCAG-Erfolgskriterien · Level AAA

WCAG 3.1.4: Abkürzungen

WCAG 3.1.4 verlangt, dass ein Mechanismus verfügbar ist, um die ausgeschriebene Form oder Bedeutung von im Inhalt verwendeten Abkürzungen zu identifizieren. Dieses Kriterium stellt sicher, dass Nutzer, die mit Abkürzungen, Akronymen oder Initialismen nicht vertraut sind, auf deren vollständige Bedeutung zugreifen können, was das Verständnis für Menschen mit kognitiven Beeinträchtigungen, Nicht-Muttersprachler und Screenreader-Nutzer unterstützt.

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 3.1.4 — Abkürzungen (Level AAA) verlangt, dass immer dann, wenn eine Abkürzung, ein Akronym oder ein Initialismus in Webinhalten erscheint, ein Mechanismus vorhanden sein muss, mit dem Nutzerinnen und Nutzer die ausgeschriebene Form oder Bedeutung herausfinden können. Eine Abkürzung ist im Sinne der WCAG eine verkürzte Form eines Wortes, einer Wortgruppe oder eines Namens — dazu gehören klassische Abkürzungen (z. B. „approx.“ für „approximately“), Akronyme (z. B. „NASA“ für „National Aeronautics and Space Administration“) und Initialismen (z. B. „HTML“ für „HyperText Markup Language“).

Das Kriterium schreibt keine einzelne verpflichtende Technik vor. Stattdessen fordert es, dass irgendein Mechanismus existiert, damit Nutzerinnen und Nutzer, die auf eine unbekannte Kurzform stoßen, feststellen können, wofür sie steht. Zulässige Mechanismen sind unter anderem: die Abkürzung beim ersten Vorkommen im Text auszuschreiben (z. B. „HyperText Markup Language (HTML)“), das HTML-Element <abbr> mit einem title-Attribut zu verwenden, das die ausgeschriebene Form bereitstellt, ein von der Seite verlinktes Glossar bereitzustellen oder die vollständige Form im umgebenden Kontext zu nennen, sodass die Bedeutung eindeutig ist.

Ein Pass liegt vor, wenn jede Abkürzung im Inhalt mindestens einen dieser Mechanismen hat: Die ausgeschriebene Form erscheint im Text neben der Abkürzung oder unmittelbar vor ihrem ersten Vorkommen; das <abbr>-Element mit einem informativen title-Attribut umschließt die Abkürzung; ein von der Seite aus zugängliches Glossar oder eine Definitionsliste definiert den Begriff; oder der umgebende Kontext macht die Bedeutung vollständig klar und eindeutig. Ein Fail liegt vor, wenn eine Abkürzung ohne eine dieser Unterstützungen erscheint — die Nutzerin oder der Nutzer sieht eine Kurzform wie „MoNE“ oder „SCR“ ohne jeden Hinweis auf ihre Bedeutung, ohne Tooltip, ohne vorherige Ausschreibung und ohne verlinktes Glossar.

Die WCAG enthält eine enge Ausnahme: Wenn die Abkürzung als Teil der Sprache selbst gilt — das heißt, sie ist so weit verbreitet, dass sie als eigenständiges Wort fungiert (z. B. „laser“ oder „radar“, die ursprünglich Akronyme waren) —, ist eine Ausschreibung nicht erforderlich. Ebenso gelten Abkürzungen als konform, die in den eigenen definierten Begriffen des Inhalts erläutert und in diesem Kontext konsistent mit einem klar zugänglichen Glossar verwendet werden. Der entscheidende Test ist immer, ob eine Person, die die Abkürzung nicht kennt, ihre Bedeutung über im Inhalt verfügbare Mechanismen herausfinden kann.

Warum das wichtig ist

Abkürzungen sind in Webinhalten allgegenwärtig — Regierungsportale, Gesundheitssysteme, E‑Commerce-Plattformen und Bildungswebsites stützen sich stark auf Kurzformen. Während sie Fachleuten vertraut sind, stellen diese verkürzten Formen für mehrere Nutzergruppen erhebliche Barrieren dar.

Menschen mit kognitiven Beeinträchtigungen und Lernbehinderungen wie Legasthenie, intellektuellen Beeinträchtigungen oder Aufmerksamkeitsstörungen können Schwierigkeiten haben, unbekannte Abkürzungen zu entschlüsseln, was sie dazu zwingt, die Seite zu verlassen, um nach Bedeutungen zu suchen, oder ganz aufzugeben. Für Nutzerinnen und Nutzer mit Gedächtnisbeeinträchtigungen können selbst Abkürzungen, denen sie bereits begegnet sind, von Sitzung zu Sitzung nicht zuverlässig erinnert werden, sodass Mechanismen innerhalb der Seite eine entscheidende, fortlaufende Unterstützung bieten.

Screenreader-Nutzende — darunter blinde Menschen oder Menschen mit starker Sehbehinderung — sind direkt betroffen, weil Screenreader Abkürzungen phonetisch auf eine Weise aussprechen können, die verwirrend oder bedeutungslos ist. Ein Screenreader könnte „SCR“ beispielsweise als unsinnige Buchstabenfolge aussprechen, statt „Sustainable Corporate Responsibility“. Wenn das <abbr>-Element korrekt mit einem title-Attribut verwendet wird, können bestimmte Screenreader-Konfigurationen die ausgeschriebene Form statt des Initialismus vorlesen, was das Verständnis erheblich verbessert. Laut der Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung, von denen ein großer Teil auf unterstützende Technologien angewiesen ist, um auf digitale Inhalte zuzugreifen.

Nicht-muttersprachliche Personen sind eine weitere betroffene Gruppe. Eine türkische Nutzerin, die ein englischsprachiges technisches Dokument liest — oder ein englischsprachiger Nutzer, der ein türkisches Regierungsportal nutzt —, kann in der Sprache versiert sein, aber mit fach- oder kulturspezifischen Abkürzungen völlig unvertraut. Ausschreibungen respektieren die Vielfalt der Hintergründe und Wissensstände der Nutzenden.

Betrachten wir ein konkretes Szenario: Eine Patientin besucht das Online-Portal eines Krankenhauses, liest ihren Diagnosebericht und stößt auf „KOAH“ ohne jede Ausschreibung. Eine türkische Ärztin erkennt dies sofort als „Kronik Obstrüktif Akciğer Hastalığı“ (Chronic Obstructive Pulmonary Disease), aber eine Patientin oder eine Pflegeperson ohne medizinische Fachkenntnisse versteht ihre eigene Diagnose nicht. Die Ausschreibung — entweder beim ersten Vorkommen im Fließtext oder über ein <abbr title='Kronik Obstrüktif Akciğer Hastalığı'>KOAH</abbr>-Element — verwandelt einen verwirrenden Begriff in verständliche Information und unterstützt informierte Entscheidungen.

Über die Barrierefreiheit hinaus gibt es messbare Vorteile für Usability und SEO. Suchmaschinen indexieren die ausgeschriebenen Formen von Abkürzungen und verbessern so die Auffindbarkeit von Inhalten für Nutzerinnen und Nutzer, die mit ausgeschriebenen Begriffen suchen. Klare, eindeutige Sprache reduziert außerdem Supportanfragen, erhöht Erfolgsquoten bei Aufgaben und stärkt das Vertrauen von Nutzenden mit unterschiedlichen Lese- und Bildungsniveaus.

Verwandte Axe-core-Regeln

WCAG 3.1.4 erfordert manuelle Tests, da kein automatisiertes Tool zuverlässig feststellen kann, ob eine bestimmte Abkürzung im Kontext einer Seite ausreichend erklärt wird. Automatisierte Scanner können das Vorhandensein von <abbr>-Elementen erkennen, aber nicht beurteilen, ob jede Abkürzung auf einer Seite eine zugängliche Ausschreibung erhalten hat. Nachfolgend eine Zusammenfassung des relevanten axe-core-Kontexts:

  • Manuelle Tests erforderlich (keine dedizierte axe-core-Regel): Axe-core enthält keine automatisierte Regel speziell für WCAG 3.1.4. Der Grund ist, dass die Beurteilung, welche Textfolgen Abkürzungen sind, ob sie irgendwo auf der Seite ausreichend ausgeschrieben werden und ob ein verlinktes Glossar zugänglich ist, menschliches Urteilsvermögen und kontextbezogenes Lesen erfordert. Ein automatisiertes Tool kann ohne tiefes Sprachverständnis nicht zwischen „IT“ (Information Technology), „it“ (Pronomen) und „It“ (Eigenname) unterscheiden. Testende müssen den Seiteninhalt manuell lesen, alle Abkürzungen, Akronyme und Initialismen identifizieren und anschließend prüfen, ob jede einzelne einen zugänglichen Ausschreibungsmechanismus hat.
  • Verwandter Check — <abbr> ohne title: Obwohl es keine eigenständige axe-core-Regel gibt, die 3.1.4 zugeordnet ist, markieren einige Accessibility-Linting-Tools und Browser-Erweiterungen <abbr>-Elemente ohne title-Attribut als Best-Practice-Warnung. Wenn Sie <abbr> als Ausschreibungsmechanismus verwenden, muss das title-Attribut vorhanden sein und die vollständige ausgeschriebene Form enthalten; ein leeres oder fehlendes title verfehlt den Zweck des Elements und würde einen Verstoß gegen dieses Kriterium darstellen.

Wie man testet

  1. Automatisierter Scan als Basis: Führen Sie axe DevTools oder Lighthouse auf der Seite aus. Obwohl keines der Tools eine dedizierte Regel für 3.1.4 hat, kann axe DevTools Best-Practice-Hinweise zu <abbr>-Elementen ohne title-Attribute anzeigen. Notieren Sie diese als Ausgangspunkte, aber beachten Sie, dass damit keine Abkürzungen erfasst werden, die überhaupt kein <abbr>-Markup haben.
  2. Manuelle Inhaltsprüfung: Lesen Sie den gesamten Seiteninhalt — einschließlich Überschriften, Fließtext, Tabellen, Formularbeschriftungen, Button-Beschriftungen, Navigationselementen und Fußzeilentext. Markieren Sie jedes Wort oder jede Zeichenfolge, die eine Abkürzung, ein Akronym oder ein Initialismus sein könnte. Prüfen Sie für jede einzelne, ob: (a) sie zuvor auf derselben Seite ausgeschrieben wurde; (b) sie in ein <abbr>-Element mit einem nicht leeren title eingebettet ist; (c) die Seite auf ein Glossar verlinkt, das sie definiert; oder (d) der umgebende Kontext ihre Bedeutung eindeutig macht.
  3. Screenreader-Prüfung mit NVDA + Firefox: Öffnen Sie die Seite in Firefox mit aktiviertem NVDA. Navigieren Sie mit den Pfeiltasten durch den Inhalt. Wenn NVDA auf ein <abbr>-Element mit title stößt, sollte der Titeltext angesagt werden. Prüfen Sie, ob die Ausschreibungen ausgegeben werden. Beachten Sie, dass sich das Verhalten von NVDA bei title-Attributen auf <abbr>-Elementen je nach Version und Einstellungen unterscheiden kann — testen Sie zunächst mit der Standardkonfiguration von NVDA.
  4. Screenreader-Prüfung mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver und navigieren Sie durch die Seite. VoiceOver unter macOS liest title-Attribute auf <abbr>-Elementen vor. Verwenden Sie VO+A, um die Seite linear zu lesen, und achten Sie darauf, ob Abkürzungen ihre Ausschreibungen erhalten. Prüfen Sie unter iOS durch Wischen durch den Inhalt dasselbe Verhalten.
  5. Screenreader-Prüfung mit JAWS + Chrome: Navigieren Sie mit aktiviertem JAWS und den Pfeiltasten durch die Seite. JAWS behandelt <abbr title='...'>, indem der Titel angesagt wird. Testen Sie, ob die Ausschreibung für jede ausgezeichnete Abkürzung korrekt vorgelesen wird.
  6. Tastatur- und visuelle Prüfung für Tooltip-Ausschreibungen: Wenn die Implementierung auf CSS-Tooltip-Mustern oder JavaScript-gesteuerten Tooltips basiert, die an <abbr>-Hover-Zustände gebunden sind, springen Sie mit der Tastatur (oder fokussieren Sie das Element programmatisch) zu dem Element und prüfen Sie, ob der Tooltip erscheint. Die WCAG verlangt, dass der Mechanismus zugänglich ist und nicht nur mit der Maus funktioniert — ein Tooltip, der nur bei Hover erscheint, schließt Tastaturnutzende aus.
  7. Prüfung von Glossar-Links: Wenn die Seite auf ein verlinktes Glossar setzt, folgen Sie dem Link und vergewissern Sie sich, dass jede im Ausgangsinhalt verwendete Abkürzung einen entsprechenden Eintrag mit einer klaren Definition hat. Prüfen Sie, ob der Glossar-Link gut sichtbar platziert und mit der Tastatur erreichbar ist.

Wie man es behebt

Unmarkierte Abkürzung beim ersten Vorkommen — Falsch

<p>The WHO reported that NCDs account for 74% of all deaths globally each year.</p>

Unmarkierte Abkürzung beim ersten Vorkommen — Richtig

<!-- Expand on first use inline, then use abbr for subsequent references -->
<p>The World Health Organization (WHO) reported that non-communicable diseases
(<abbr title='non-communicable diseases'>NCDs</abbr>) account for 74% of all
deaths globally each year.</p>

abbr-Element ohne title-Attribut — Falsch

<!-- abbr element present but title is missing — provides no expansion -->
<p>Submit your <abbr>VAT</abbr> registration number to proceed.</p>

abbr-Element ohne title-Attribut — Richtig

<!-- title attribute supplies the full expansion for assistive technologies -->
<p>Submit your <abbr title='Value Added Tax'>VAT</abbr> registration number to proceed.</p>

Nur-Hover-Tooltip für Abkürzung — Falsch

<!-- CSS tooltip only appears on mouse hover; keyboard users and touch users cannot access it -->
<span class='tooltip-trigger'>KVKK
  <span class='tooltip-text'>Kişisel Verilerin Korunması Kanunu</span>
</span>

Nur-Hover-Tooltip für Abkürzung — Richtig

<!-- Using abbr with title ensures the expansion is available to all users,
     including keyboard and screen reader users, without relying on hover -->
<abbr title='Kişisel Verilerin Korunması Kanunu'>KVKK</abbr>

Abkürzung in einem Tabellenkopf ohne Ausschreibung — Falsch

<table>
  <thead>
    <tr>
      <th>SKU</th>
      <th>MoQ</th>
      <th>ETA</th>
    </tr>
  </thead>
</table>

Abkürzung in einem Tabellenkopf ohne Ausschreibung — Richtig

<!-- abbr with title inside th provides context for all users, including screen reader users -->
<table>
  <thead>
    <tr>
      <th><abbr title='Stock Keeping Unit'>SKU</abbr></th>
      <th><abbr title='Minimum Order Quantity'>MoQ</abbr></th>
      <th><abbr title='Estimated Time of Arrival'>ETA</abbr></th>
    </tr>
  </thead>
</table>

Häufige Fehler

  • Verwendung von <abbr> ohne title-Attribut: Text nur in <abbr>-Tags zu kapseln, bietet keinen semantischen Mehrwert und keine Ausschreibung — das title-Attribut ist zwingend erforderlich, damit das Element seinen Barrierefreiheitszweck unter diesem Kriterium erfüllt.
  • Eine Abkürzung erst nach ihrem ersten Vorkommen ausschreiben: Wenn eine Abkürzung im Lesefluss vor ihrer Ausschreibung erscheint (z. B. in einer Überschrift vor dem Fließtext, der sie ausschreibt), haben Nutzende, die zuerst auf die Überschrift stoßen, an dieser Stelle keinen Mechanismus, um sie zu verstehen. Schreiben Sie immer beim ersten oder vor dem ersten Vorkommen aus.
  • Sich ausschließlich auf Mouse-Hover-Tooltips verlassen: CSS- oder JavaScript-Tooltips, die nur bei :hover erscheinen, sind für reine Tastaturnutzende, Touchscreen-Nutzende und die meisten Screenreader-Konfigurationen unzugänglich. Das Muster <abbr title> ist vorzuziehen, oder Tooltips müssen zusätzlich bei :focus ausgelöst werden.
  • Ein verlinktes Glossar bereitstellen, den Link aber schwer auffindbar machen: Wenn Ihr Ausschreibungsmechanismus ein Glossar ist, muss der Link klar beschriftet, gut sichtbar platziert und mit der Tastatur erreichbar sein. Ein Glossar-Link, der in einer Fußzeile in kleiner Schrift oder hinter einem eingeklappten Bereich versteckt ist, erfüllt die Anforderung an einen nutzbaren Mechanismus möglicherweise nicht.
  • Abkürzungen inkonsistent ausschreiben — nur einige Vorkommen markieren: Wenn Sie <abbr title> für ein Akronym in einem Abschnitt verwenden, andere Vorkommen auf derselben Seite aber unmarkiert lassen, stoßen Nutzende, die direkt über die Suche oder Landmarken zu diesen Abschnitten springen, auf unerklärte Kurzformen.
  • Anzunehmen, dass alle Abkürzungen allgemein verständlich sind: Fachspezifische Abkürzungen, die Praktikerinnen und Praktikern offensichtlich erscheinen („EBITDA“ im Finanzwesen, „API“ in der Softwareentwicklung, „BKT“ in türkischen Verwaltungskontexten), können für Personen außerhalb dieser Bereiche völlig unverständlich sein, einschließlich Menschen, die unterstützende Technologien nutzen oder die Seite zum ersten Mal besuchen.
  • Die Ausschreibung nur im Alt-Text von Bildern statt im Text bereitzustellen: Wenn eine Abkürzung im Alt-Text eines Bildes ausgeschrieben wird, der sichtbare Text aber nur die Abkürzung zeigt, ist der Mechanismus möglicherweise nicht für alle Nutzenden zugänglich (z. B. für Personen, die Browser-Lesemodi verwenden). Ausschreibungen sollten im programmatischen Text des Dokuments selbst verfügbar sein.
  • Falsche oder verkürzte title-Werte verwenden: Das title-Attribut eines <abbr>-Elements muss die vollständige ausgeschriebene Form enthalten, nicht eine weitere Abkürzung oder eine teilweise Erklärung. title='HTML lang' statt title='HyperText Markup Language' erfüllt das Kriterium nicht.
  • Abkürzungen in dynamischen Inhalten nicht berücksichtigen: Inhalte, die über AJAX, Infinite Scroll oder Single-Page-Application-Routing geladen werden, können nach dem initialen Laden der Seite neue Abkürzungen einführen. Jeder dynamisch in den DOM eingefügte Inhalt muss ebenfalls konform sein — Abkürzungen in dynamisch gerenderten Bereichen benötigen dieselben Ausschreibungsmechanismen wie statische Inhalte.
  • Akronyme, die zu gebräuchlichen Wörtern geworden sind, immer als ausgenommen zu betrachten: Die Ausnahme für Abkürzungen, die als Wörter fungieren („laser“, „radar“), ist eng gefasst. Begriffe wie „URL“ oder „PDF“ sind in technikaffinen Kontexten sehr bekannt, können aber für ältere Menschen, Menschen mit kognitiven Beeinträchtigungen oder Personen aus anderen kulturellen Hintergründen weiterhin unverständlich sein. Im Zweifel sollten Sie die Ausschreibung bereitstellen — sie schadet Nutzenden, die den Begriff bereits kennen, nie.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die digitale Barrierefreiheit fest, die sich an WCAG 2.2 orientieren. Die Verfügung umfasst eine breite Palette von Organisationstypen: öffentliche Einrichtungen und Regierungsbehörden auf allen Ebenen, E‑Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministry of National Education (MoNE) zugelassen sind.

Die Verfügung schreibt in erster Linie die Einhaltung von WCAG 2.2 Level AA vor. WCAG 3.1.4 — Abkürzungen ist ein Level-AAA-Kriterium und daher nach dem aktuellen Wortlaut der Präsidialverfügung 2025/10 keine direkte gesetzliche Verpflichtung. Allerdings ist die Konformität mit Level AAA nicht nur ein bloßes Ziel — sie hat im türkischen digitalen Umfeld erhebliches praktisches und reputationsbezogenes Gewicht.

Für Einrichtungen des öffentlichen Sektors, Krankenhäuser und Bildungseinrichtungen, die vielfältige Bevölkerungsgruppen bedienen — von denen viele mit bürokratischen oder medizinischen Abkürzungen nur begrenzt vertraut sind — ist die Umsetzung von 3.1.4 eine Frage echter Dienstleistungsqualität. Die türkische Verwaltungs- und Rechtssprache ist reich an Initialismen („SGK“ für Sosyal Güvenlik Kurumu, „KDV“ für Katma Değer Vergisi, „ÖTV“ für Özel Tüketim Vergisi), die für Beamtinnen und Beamte selbstverständlich sind, für die Allgemeinbevölkerung jedoch verwirrend sein können, insbesondere für ältere Menschen, Nutzerinnen und Nutzer in ländlichen Regionen oder Erstbesuchende eines Portals.

Banken, Telekommunikationsanbieter und E‑Commerce-Plattformen, die der Verfügung unterliegen, würden ihre Barrierefreiheitsposition — und ihr Markenvertrauen — stärken, indem sie Abkürzungen in Beschreibungen von Finanzprodukten, Vertragszusammenfassungen, Tariftabellen und Servicebedingungen ausschreiben. Gerade Finanzdokumente sind dicht mit Abkürzungen, die wichtige Informationen vor Verbraucherinnen und Verbrauchern verschleiern können, die fundierte Entscheidungen treffen müssen.

Organisationen, die eine formale WCAG-2.2-AAA-Konformität anstreben — sei es, um Marktführerschaft zu demonstrieren, Beschaffungsanforderungen internationaler Partner zu erfüllen oder die Erwartungen spezialisierter Verträge im öffentlichen Gesundheitswesen oder im Bildungsbereich zu erfüllen — sollten 3.1.4 als Standardpraxis umsetzen. Das Overlay-SDK von Accsible unterstützt Teams bei der Implementierung und Prüfung von Mustern zur Ausschreibung von Abkürzungen und kann so konfiguriert werden, dass es während der Content-Erstellung Hinweise einblendet, wodurch Organisationen die Konformität auch bei dynamisch aktualisierten Inhalten in großem Maßstab aufrechterhalten können.