Umlaute, Sonderzeichen und Textauszeichnung

Umlaute, ß und die meisten Sonderzeichen schreibst du in HTML direkt in den Quelltext – vorausgesetzt, <meta charset="utf-8"> steht in den ersten 1024 Bytes des Dokuments. Zwingend als Entity brauchst du nur &, < und >. Wer den Zeilenumbruch zwischen zwei Wörtern verhindern will, nimmt  .

Damit ist der Nachschlage-Teil erledigt. Der Rest dieser Seite beantwortet die Fragen dahinter: warum das Encoding über kaputte Umlaute entscheidet, warum HTML mehrfache Leerzeichen verschluckt – und welche Elemente im Fließtext eine Bedeutung tragen statt nur eine Optik: <strong>, <em>, <time>, <abbr> und ihre Nachbarn.

Das Wichtigste in Kürze

• Umlaute brauchen keine Entities. Mit <meta charset="utf-8"> in den ersten 1024 Bytes des Dokuments schreibst du ä, ö, ü und ß direkt in den Quelltext. ä ist Altlast aus der Zeit vor UTF-8.
• Genau drei Zeichen musst du maskieren: & als &, < als < und – per Konvention – > als >. In Attributwerten kommt das jeweilige Anführungszeichen dazu.
• Kaputte Umlaute (ä statt ä) sind fast nie ein HTML-Problem, sondern ein Widerspruch zwischen Datei-Kodierung und HTTP-Header. Der Header gewinnt.
• HTML fasst mehrere Leerzeichen zu einem zusammen. Wer zwei Wörter zusammenhalten will, nimmt   (U+00A0); wer Abstand will, nimmt CSS – nicht <br><br>.
• Erst die Bedeutung, dann die Optik: <strong>/<em> wenn eine Aussage dahintersteht, <b>/<i> wenn nicht.
• <time datetime> und <data value> machen Angaben maschinenlesbar – unabhängig davon, wie sie im Text formuliert sind.
• Realistische Einordnung: Gängige Screenreader sagen <strong> und <em> standardmäßig nicht an. Der Nutzen liegt trotzdem woanders – siehe unten.
• <abbr title> ist ein Zusatz, kein Ersatz: Die Langform beim ersten Auftreten auszuschreiben, hilft mehr.
• Fremdsprachige Passagen bekommen ein lang – sonst spricht der Screenreader sie falsch aus.

Bedeutung vs. reine Optik

Mehrere Elementpaare sehen im Browser fast gleich aus, meinen aber Unterschiedliches:

• <strong> kennzeichnet inhaltliche Wichtigkeit („Achtung, das ist zentral“). <b> macht nur fett, ohne Bedeutung – gedacht für Stichwörter, um die es keine besondere Dringlichkeit gibt.
• <em> markiert eine Betonung, die den Sinn verschieben kann („Ich habe heute keine Zeit“). <i> ist nur Schräglage: Fachbegriffe, Werktitel, fremdsprachige Wendungen, Gedanken.
• <mark> hebt etwas hervor, das im aktuellen Zusammenhang relevant ist – klassisch der Suchbegriff in einer Trefferliste. Wichtig: Wer damit arbeitet, darf sich nicht allein auf die Farbe verlassen (1.4.1 Benutzung von Farbe).
• <del> und <ins> dokumentieren eine Änderung (mit datetime und cite belegbar), <s> sagt nur: gilt nicht mehr – etwa ein alter Preis.

Faustregel, die ich mir angewöhnt habe: Erst die Bedeutung benennen, dann zur optischen Variante greifen, wenn wirklich keine dahintersteht. Und: <strong> wirkt nur, solange es selten ist. Ein ganzer Absatz in <strong> sagt nichts mehr aus.

Was Screenreader wirklich ansagen

Hier steht in vielen Artikeln etwas Beschönigendes, deshalb die klare Antwort: Die gängigen Screenreader sprechen <strong> und <em> standardmäßig nicht an. Weder NVDA noch JAWS noch VoiceOver machen aus einer Hervorhebung hörbar etwas Besonderes; die Auszeichnungen tauchen auch nicht als eigene Rolle im Barrierefreiheits-Baum auf. Wer will, kann die Ansage von Schriftattributen in den Einstellungen einschalten – die meisten Menschen tun das nicht, weil es beim Lesen stört.

Warum lohnt sich der Aufwand dann? Wegen vier anderer Gründe:

1. Ohne CSS bleibt die Bedeutung erhalten. In der Lese-Ansicht, im E-Mail-Export, im Textbrowser, in der Übersetzungsansicht – überall dort, wo dein Stylesheet nicht mitkommt, trägt das Element die Aussage weiter.
2. Braillezeilen und Einstellungen. Wer Formatierungsansagen aktiviert oder eine Braillezeile nutzt, bekommt die Auszeichnung sehr wohl mit.
3. Maschinen lesen mit. Suchmaschinen und KI-Systeme werten Struktur aus. Ein <strong> ist ein schwaches, aber echtes Signal – ein <span class="fett"> ist gar keins.
4. Es kostet nichts. Das richtige Element zu tippen ist keine Mehrarbeit, sondern eine Gewohnheit.

Anders ist es bei <abbr>: Hier gibt es tatsächlich Ansage-Verhalten – JAWS liest die Langform vor, wenn die entsprechende Einstellung aktiv ist, NVDA und VoiceOver sprechen sie je nach Konfiguration beim ersten Auftreten mit. Verlassen kann man sich darauf aber nicht, und per Tastatur oder auf dem Touchscreen ist ein title-Tooltip ohnehin kaum erreichbar. Deshalb gilt: Erklärungsbedürftige Abkürzungen beim ersten Vorkommen im Text ausschreiben – das <abbr> ist die Zugabe, nicht die Lösung.

Maschinenlesbare Angaben: <time>, <abbr>, <data>

Manche Elemente machen Inhalte gezielt für Software verständlich:

<p>Veröffentlicht am <time datetime="2026-07-26">26. Juli 2026</time>.</p>
<p>Die <abbr title="Web Content Accessibility Guidelines">WCAG</abbr> sind der zentrale Standard.</p>
<p>Der Kurs dauert <time datetime="PT2H30M">zweieinhalb Stunden</time>.</p>
<p>Wir liefern <data value="4.99">für unter fünf Euro</data>.</p>

<time datetime="…"> trennt die Schreibweise im Text von der normierten Angabe. Das datetime-Attribut kennt mehrere Formate:

Damit steht im Text „letzten Freitag“ oder „zweieinhalb Stunden“, während Software den exakten Wert bekommt. Ohne datetime ist <time> nur dann gültig, wenn der Textinhalt selbst schon ein normiertes Datum ist.

<data value="…"> ist das Gegenstück für alles, was kein Zeitpunkt ist: Preise, Mengen, Artikelnummern, Bewertungen. Es wird selten genutzt und ist genau dann nützlich, wenn Text und Wert auseinanderfallen.

Randnotiz – wofür der ganze Aufwand? Solche Auszeichnungen richten sich nicht nur an Screenreader. Auch Web-Crawler (Googlebot & Co.) und KI-Crawler (z. B. GPTBot oder ClaudeBot) profitieren: Ein datetime-Attribut macht ein Veröffentlichungsdatum eindeutig auswertbar, ein <abbr> verbindet Kürzel und Langform. Gerade bei KI-Antworten entscheidet die Eindeutigkeit darüber, ob eine Angabe korrekt übernommen oder stillschweigend falsch geraten wird. Den nächsten Schritt in diese Richtung gehen strukturierte Daten / Schema.org – dort wird aus der Auszeichnung im Satz ein maschinenlesbarer Datensatz.

Weitere nützliche Inline-Elemente

Technisches:

• <code> für Code im Fließtext, <kbd> für Tastatureingaben, <samp> für Programmausgaben, <var> für Variablen.

Zitate und Begriffe:

• <q> für ein kurzes Zitat im Satz – der Browser setzt die Anführungszeichen selbst, passend zur Sprache aus lang. Wer sichergehen will, legt sie per CSS-Eigenschaft quotes fest. Für längere Zitate ist <blockquote> richtig, für den Werktitel <cite>; ausführlich unter Zitate richtig auszeichnen.
• <dfn> kennzeichnet die Definition eines Begriffs an seiner Erstnennung.

Auf- und Abwertungen:

• <small> ist kein „kleiner Text“, sondern eine Nebenbemerkung: Fußnote, Rechtliches, Urheberrechtszeile.
• <sub> und <sup> für Tief- und Hochstellung, wenn sie bedeutungstragend sind (H₂O, m²) – nicht für Fußnotenzahlen als Design.
• <u> hat in HTML5 eine enge Bedeutung („nicht ausgesprochene Anmerkung“, etwa eine markierte Rechtschreibfehler-Stelle). Für Unterstreichungen im Layout ist es falsch – Unterstrichenes liest sich im Web als Link.

Sprache und Richtung:

• Fremdsprachige Passagen bekommen ein eigenes lang: <span lang="en">Progressive Enhancement</span>. Das ist WCAG 3.1.2 Sprache von Teilen und sorgt dafür, dass der Screenreader die Aussprache umschaltet.
• <bdi>/<bdo> regeln die Leserichtung, wenn Inhalte aus Sprachen mit Rechts-nach-links-Schreibung eingebettet werden – etwa Nutzernamen in einer Liste.

Umlaute, ß und Sonderzeichen: das Encoding entscheidet

Die häufigste Frage zu deutschem Text in HTML lautet: Muss ich ä schreiben oder darf ich einfach „ä“ tippen? Die Antwort ist seit über zehn Jahren dieselbe: Tippe das Zeichen. Voraussetzung ist eine einzige Zeile im <head>:

<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="utf-8" />
  <title>Übersicht über Größen und Maße</title>
</head>

Zwei Bedingungen müssen dafür erfüllt sein, und beide werden regelmäßig übersehen:

1. Die Deklaration steht in den ersten 1024 Bytes des Dokuments. Der HTML-Standard schreibt das so vor, weil der Browser das Parsen sonst mit einer falschen Annahme beginnt und neu starten muss. Praktisch heißt das: <meta charset> gehört als erste oder zweite Zeile in den <head>, vor jedes <title> mit Umlauten.
2. Die Datei ist tatsächlich als UTF-8 gespeichert. Die Deklaration ist eine Behauptung, keine Umwandlung. Editoren zeigen die Kodierung meist in der Statusleiste; im Zweifel hilft file -I datei.html auf der Kommandozeile.

Kommt der Server zusätzlich mit einem eigenen Content-Type: text/html; charset=utf-8-Header, gewinnt dieser Header gegenüber dem <meta>-Element. Wenn Umlaute also trotz korrekter Meta-Angabe kaputt aussehen, lohnt der Blick in die Antwort-Header, bevor man im HTML weitersucht.

Wenn statt „ä“ ein „ä“ erscheint

Dieses Muster ist kein Zufall, sondern eine Signatur. UTF-8 kodiert „ä“ als zwei Bytes (C3 A4). Interpretiert ein Browser diese Bytes als Windows-1252, macht er daraus brav zwei Zeichen: Ã und ¤. Sichtbares „ä“, „ö“ oder „ß“ heißt deshalb immer: Datei ist UTF-8, Deklaration sagt etwas anderes.

Der umgekehrte Fall sieht anders aus: Ist die Datei in Latin-1 gespeichert und als UTF-8 deklariert, ergeben die Bytes keine gültige UTF-8-Sequenz – der Browser zeigt das Ersatzzeichen �. Aus der Art des Fehlers lässt sich also ablesen, an welcher der beiden Schrauben zu drehen ist.

Die drei Zeichen, die du wirklich maskieren musst

Entities sind nicht abgeschafft, sie haben nur einen viel kleineren Zuständigkeitsbereich als früher. Maskiert werden muss, was der Parser sonst als Markup liest:

Alles andere – Umlaute, ß, €, Akzente, Emoji, kyrillische oder arabische Schrift – schreibst du direkt. Das hat drei praktische Vorteile: Der Quelltext bleibt lesbar, die Suche im Editor findet die Wörter, und die Dateigröße sinkt, weil ä sechs Bytes braucht, wo „ä“ zwei genügen.

Zeichen, für die sich eine Entity trotzdem lohnt

Bei einer Handvoll Zeichen ist die benannte Form die bessere Wahl – nicht aus technischen Gründen, sondern weil sie im Quelltext eindeutig ist. Ein geschütztes Leerzeichen, ein bedingter Trennstrich und ein Gedankenstrich sehen im Editor sonst aus wie ein normales Leerzeichen, gar nichts und ein Bindestrich:

Die vollständige Liste aller benannten Zeichenreferenzen führt der HTML-Standard; sie umfasst über 2.000 Einträge, von denen im Alltag die obigen reichen.

Der Teil, der in Zeichentabellen fehlt: Barrierefreiheit

Sonderzeichen sind für Screenreader keine neutrale Angelegenheit, und hier liegt der Punkt, den reine HTML-Referenzen auslassen.

Symbole tragen Bedeutung, werden aber nicht zuverlässig vorgelesen. Wie ein Zeichen ausgesprochen wird, hängt von Screenreader, Stimme, Sprache und der eingestellten Ausführlichkeit ab. „→“ wird je nach Konfiguration als „Pfeil nach rechts“ angesagt, als „Rechtspfeil“ oder gar nicht. Wenn ein Zeichen also Information transportiert – ein Pfeil als „führt zu“, ein Häkchen als „erfüllt“, ein Kreuz als „nicht erfüllt“ –, braucht es eine Textalternative. Das ist WCAG 1.1.1 Nicht-Text-Inhalte und gilt für ein „✓“ genauso wie für ein Bild:

<!-- Falsch: Die Bedeutung steckt allein im Zeichen -->
<td>✓</td>

<!-- Richtig: Das Zeichen ist Dekoration, die Aussage steht als Text daneben -->
<td><span aria-hidden="true">✓</span><span class="visually-hidden">erfüllt</span></td>

Getippte Pseudo-Formatierung zerstört die Ausgabe. Wer Text mit Unicode-Kunstschriften fett setzt (𝗕𝗲𝗶𝘀𝗽𝗶𝗲𝗹 statt <strong>Beispiel</strong>), verwendet in Wahrheit mathematische Sonderzeichen. Screenreader lesen daraus Zeichenketten wie „mathematisches fettes B“ – oder überspringen sie ganz. Dasselbe gilt für g e s p e r r t e n Text: Aus „Willkommen“ wird eine Buchstabenfolge, die einzeln vorgelesen wird. Für Sperrung ist letter-spacing in CSS zuständig, für Fettung <strong>.

Emoji werden vollständig vorgelesen und stehen am besten am Satzende. Ein Emoji mitten im Satz unterbricht den Lesefluss mit einer oft überraschend langen Beschreibung („lächelndes Gesicht mit lachenden Augen“). Drei Emoji hintereinander ergeben drei solcher Beschreibungen. Sparsam und ans Ende – das ist die ganze Regel.

Leerzeichen: warum aus dreien eines wird

Das zweite Alltagsthema hat dieselbe Ursache wie das erste: HTML ist kein Textverarbeitungsprogramm. Aufeinanderfolgende Leerzeichen, Tabulatoren und Zeilenumbrüche fasst der Browser zu einem einzigen Leerzeichen zusammen. Das ist kein Fehler, sondern das Standardverhalten von white-space: normal – und der Grund, warum sich Quelltext beliebig einrücken lässt, ohne die Ausgabe zu ändern.

<!-- Alle drei Zeilen erzeugen exakt dieselbe Ausgabe -->
<p>Ein     Satz     mit     Abstand.</p>
<p>Ein Satz mit Abstand.</p>
<p>Ein
   Satz
   mit Abstand.</p>

Daraus folgen drei verschiedene Aufgaben, die oft verwechselt werden.

Zwei Wörter zusammenhalten:  

Das geschützte Leerzeichen (U+00A0) sieht aus wie ein Leerzeichen, verhindert aber den Zeilenumbruch an dieser Stelle – und wird nicht zusammengefasst. Es gehört überall dorthin, wo ein Umbruch den Text schwerer lesbar macht:

<p>Der Weg ist 5&nbsp;km lang.</p>
<p>Zuständig ist Dr.&nbsp;Sommer.</p>
<p>Siehe §&nbsp;12d BGG, S.&nbsp;4.</p>
<p>Das sind 10&nbsp;000 Zeichen.</p>

Für die typografisch saubere Variante bei Abkürzungen wie „z. B.“ gibt es das schmale geschützte Leerzeichen U+202F ( ): z. B. Es ist enger als ein normales Leerzeichen und bricht ebenfalls nicht um. Einen benannten Kurznamen hat es in HTML nicht – die numerische Referenz ist der einzige Weg.

Ein verbreiteter Irrtum dazu:   ist kein Werkzeug für Abstände.     als Einrückung ist ein Layout-Hack, den Screenreader je nach Einstellung als „Leerzeichen Leerzeichen Leerzeichen“ ansagen. Abstand ist eine Aufgabe von margin, padding oder gap.

Abstand zwischen Absätzen: CSS, nicht <br>

<br> erzeugt einen Zeilenumbruch innerhalb eines Blocks. Es ist richtig, wo der Umbruch zum Inhalt gehört: in einer Anschrift, in einem Gedicht, in einer Zeile aus einem Songtext. Es ist falsch als Abstandshalter.

<!-- Falsch: leere Zeilen als Gestaltungsmittel -->
<p>Erster Absatz.</p><br><br>
<p>Zweiter Absatz.</p>

<!-- Richtig: zwei Absätze, Abstand kommt aus dem Stylesheet -->
<p>Erster Absatz.</p>
<p>Zweiter Absatz.</p>

<!-- Richtig: Umbruch gehört zum Inhalt -->
<p>
  Jakob Sommer<br />
  Musterstraße 1<br />
  12345 Musterstadt
</p>

Der Unterschied ist nicht kosmetisch. Ein Screenreader kündigt Absätze als Struktureinheiten an und erlaubt, absatzweise zu navigieren; eine mit <br> zusammengeklebte Textwand bietet diese Sprungmarken nicht. Wer den Abstand tatsächlich braucht, setzt ihn in CSS – und bleibt damit auch kompatibel zu WCAG 1.4.12 Textabstände, das verlangt, dass Nutzerinnen und Nutzer Abstände selbst vergrößern dürfen.

Leerzeichen wirklich erhalten: <pre> oder CSS

Wenn die Formatierung Teil des Inhalts ist – Code, ASCII-Tabellen, eingerückte Konfigurationen –, ist <pre> das richtige Element. Es hält Leerzeichen und Zeilenumbrüche exakt so, wie sie im Quelltext stehen:

<pre><code>root
  ├── index.html
  └── css/
      └── style.css</code></pre>

Für Fälle, in denen <pre> zu viel ist, gibt es die CSS-Eigenschaft white-space: pre-wrap erhält Leerzeichen und Umbrüche, bricht aber am Rand trotzdem um; pre-line erhält nur die Zeilenumbrüche.

Leerzeichen in URLs und Dateinamen

Ein Sonderfall mit eigener Regel: In einer URL ist das Leerzeichen kein gültiges Zeichen. Es wird nach RFC 3986 prozentkodiert – als %20:

<a href="/dateien/barrierefreie%20checkliste.pdf">Checkliste herunterladen</a>

Browser zeigen im Adressfeld oft die dekodierte Fassung an, senden aber %20. In Query-Strings kommt zusätzlich das + als Leerzeichen vor, weil Formulare nach application/x-www-form-urlencoded kodieren – im Pfad einer URL gilt das nicht, dort bedeutet + ein echtes Pluszeichen.

Mein praktischer Rat dazu: Leerzeichen in Dateinamen gar nicht erst entstehen lassen. Bindestriche statt Leerzeichen, keine Umlaute, alles klein – das erspart prozentkodierte Links, die niemand mehr lesen kann, und vermeidet Probleme beim Kopieren zwischen Betriebssystemen.

Ein Beispiel im Zusammenhang

<p>
  Mit <kbd>Tab</kbd> springst du zum nächsten Element. Der alte Preis von
  <s>49 €</s> beträgt jetzt <strong><data value="29.00">29 €</data></strong> –
  gültig bis <time datetime="2026-12-31">Jahresende</time>, wie es die
  <abbr title="Allgemeine Geschäftsbedingungen">AGB</abbr> vorsehen.
</p>

Jedes Element hier trägt eine Aussage: eine Taste, ein überholter Wert, eine wichtige Information, ein maschinenlesbarer Betrag, ein konkretes Datum, eine aufgelöste Abkürzung. Nichts davon ist Dekoration – und nichts davon würde ein <span> mit CSS-Klasse leisten.

Wo <span> die richtige Wahl ist

Damit das nicht als Dogma missverstanden wird: <span> ist nicht verboten, sondern das richtige Element, wenn es keine Bedeutung zu transportieren gibt – ein farbiges Wort im Logo-Schriftzug, ein Zeilenumbruch-Helfer, ein Anker für eine Animation. Die Frage lautet immer: Ginge beim Weglassen des CSS eine Information verloren? Wenn ja, gehört ein bedeutungstragendes Element hin; wenn nein, ist <span> genau richtig. Dieselbe Logik gilt eine Ebene höher für div und span.

Häufige Fehler

• <b>/<i> statt <strong>/<em>, obwohl eine Bedeutung dahintersteht.
• Ganze Sätze in <strong>, wodurch die Wichtigkeit verwässert.
• <abbr> ohne title – dann fehlt gerade die nützliche Zusatzinfo.
• Nur <abbr> statt Ausschreiben bei erklärungsbedürftigen Kürzeln.
• Datum nur als Text, ohne <time datetime>.
• <u> als Gestaltungsmittel – es sieht aus wie ein Link.
• <small> als Schriftgrößen-Regler statt als Nebenbemerkung.
• Visuelles Durchstreichen mit CSS, wo <del> oder <s> die Bedeutung transportieren sollte.
• Fremdsprachige Zitate ohne lang – der Screenreader liest sie deutsch vor.
• ä statt „ä“ im Quelltext, obwohl UTF-8 deklariert ist – unnötiger Ballast.
• <meta charset> zu weit unten, hinter einem <title> mit Umlauten.
•   als Abstandshalter statt margin oder padding.
• <br><br> zwischen Absätzen, wo zwei <p> hingehören.
• Symbole wie ✓ oder → ohne Textalternative, obwohl sie die Aussage tragen.

Häufige Fragen

Wie stelle ich Umlaute in HTML richtig dar?

Speichere die Datei als UTF-8 und setze <meta charset="utf-8" /> in die ersten 1024 Bytes des Dokuments, also ganz an den Anfang des <head> – vor den <title>. Danach schreibst du ä, ö, ü und ß direkt in den Quelltext; ä ist nicht nötig und kostet sechs Bytes statt zwei. Maskieren musst du nur &, < und > sowie in Attributwerten das jeweilige Anführungszeichen. Erscheint statt „ä“ ein „ä“, ist die Datei UTF-8 und die Deklaration eine andere; erscheint „�“, ist es umgekehrt.

Wie erzeuge ich ein geschütztes Leerzeichen in HTML?

Mit   (U+00A0). Es verhindert einen Zeilenumbruch an dieser Stelle und wird nicht mit benachbarten Leerzeichen zusammengefasst – richtig also bei 5 km, Dr. Sommer oder § 12d. Für die schmale Variante bei Abkürzungen wie z. B. gibt es U+202F, das nur als numerische Referenz   existiert. Als Abstandshalter taugt   nicht; dafür ist CSS zuständig.

Wie mache ich eine Leerzeile in HTML?

Für Abstand zwischen Absätzen gar nicht mit HTML, sondern mit CSS: Zwei <p> bekommen ihren Abstand über margin. <br> ist ein Zeilenumbruch innerhalb eines Blocks und gehört dorthin, wo der Umbruch zum Inhalt zählt – Anschrift, Gedicht, Songzeile. <br><br> als Gestaltungsmittel nimmt Screenreadern die Absatz-Struktur, über die sich sonst springen ließe.

Wie schreibe ich ein Leerzeichen in einer URL?

Als %20. Das Leerzeichen ist in URLs kein gültiges Zeichen und wird nach RFC 3986 prozentkodiert: /dateien/meine%20datei.pdf. In Query-Strings steht zusätzlich + für ein Leerzeichen, weil Formulardaten anders kodiert werden – im Pfad bedeutet + dagegen ein echtes Pluszeichen. Am besten vermeidest du Leerzeichen in Dateinamen von vornherein und nimmst Bindestriche.

Sind <b> und <i> verboten?

Nein. Sie sind richtig, wenn es keine besondere Bedeutung gibt – etwa ein kursiver Fachbegriff oder ein fett gesetztes Stichwort ohne besonderes Gewicht. Steht eine Bedeutung dahinter, sind <strong> und <em> korrekt.

Bringt <strong> etwas fürs Ranking?

Ein sehr schwaches Signal, mehr nicht. Wer damit Keywords markiert, verschwendet Aufmerksamkeit; wer damit echte Kernaussagen markiert, hilft Lesenden – und das ist der Zweck.

Muss ich jede Abkürzung mit <abbr> auszeichnen?

Nicht zwingend, und schon gar nicht mehrfach im selben Text. Bei der ersten Nennung einer erklärungsbedürftigen Abkürzung finde ich es sinnvoll – zusätzlich zur ausgeschriebenen Form im Fließtext.

Was ist der Unterschied zwischen <s> und <del>?

<del> heißt „wurde entfernt“ und gehört in Änderungsdokumentation (mit datetime und cite). <s> heißt „trifft nicht mehr zu“ – der klassische alte Preis. Wer unsicher ist: Gab es eine Bearbeitung? Dann <del>.

Kann ich <mark> frei verwenden?

Für Hervorhebungen, die sich auf den aktuellen Kontext beziehen – Suchtreffer, markierte Stellen in einem Zitat – ja. Als dauerhafte Textauszeichnung nein; dafür ist <strong> oder <em> gedacht.

Wie prüfe ich, ob ich richtig ausgezeichnet habe?

Zwei einfache Tests: das Stylesheet abschalten (bleibt die Aussage erkennbar?) und den HTML-Validator laufen lassen. Für den Rest hilft die Frage, ob das Element etwas behauptet – und ob diese Behauptung stimmt.

Fazit

Inline-Semantik ist Feinarbeit, aber sie lohnt sich: <strong> und <em> transportieren Wichtigkeit und Betonung, <time>, <data> und <abbr> machen Angaben maschinenlesbar, <mark>, <del> und <s> unterscheiden Hervorhebung von Überholtem. Dass Screenreader die Hervorhebungen selten ansagen, ändert daran wenig – der Gewinn liegt in allem, was ohne dein CSS auskommen muss.

Bei den Zeichen ist die Lage einfacher, als ihr Ruf vermuten lässt: UTF-8 deklarieren, Umlaute direkt tippen, drei Zeichen maskieren. Und beim Leerraum lohnt sich die Trennung der drei Aufgaben –   hält zusammen, CSS schafft Abstand, <pre> erhält Formatierung. Wer nach Bedeutung statt nach Optik auszeichnet, bleibt der Linie von Was ist semantisches HTML? treu – bis in den einzelnen Satz und bis ins einzelne Zeichen.

Quellen

• Text-level semantics (HTML-Standard, WHATWG – verbindliche Definition aller Inline-Elemente)
• Named character references (HTML-Standard, WHATWG – vollständige Liste aller benannten Entities)
• The charset declaration (HTML-Standard, WHATWG – Regel zu den ersten 1024 Bytes)
• Encoding Standard (WHATWG – wie Browser Kodierungen bestimmen und behandeln)
• RFC 3986, Abschnitt 2.1: Percent-Encoding (IETF – verbindliche Regel für Leerzeichen in URLs)
• Screen Readers support for text level HTML semantics (TPGi/Vispero – Testübersicht, welche Auszeichnungen tatsächlich angesagt werden)