Webentwicklung

Screenreader-freundliches Markup schreiben

Verstehe ARIA-Labels, semantisches HTML und Best Practices für Formularfelder — damit Screenreader-Nutzer deine Inhalte ohne Probleme navigieren und verstehen können.

11 min Lesedauer Fortgeschrittene März 2026

Person mit Kopfhörern sitzt am Computer — Konzept für Screenreader und Audio-Navigation

Warum sauberes Markup zählt

Screenreader sind nicht einfach eine technische Anforderung — sie sind die einzige Brücke für Millionen von Menschen zwischen ihnen und dem Web. Wenn dein HTML nicht strukturiert ist, wenn deine Labels fehlen oder deine Buttons falsch deklariert sind, dann ist deine Website für diese Menschen schlicht nicht zugänglich.

Das Gute: Es ist nicht kompliziert. Mit den richtigen Grundlagen — semantisches HTML, korrekte ARIA-Attribute und durchdachte Formulardesign — schaffst du eine Erfahrung, die wirklich für alle funktioniert. Wir zeigen dir genau, wie das geht.

Code-Editor mit barrierefreiem HTML-Markup auf dem Bildschirm, professionelle Umgebung

Semantisches HTML ist die Grundlage

Das Erste, was du verstehen musst: HTML-Tags haben eine Bedeutung. Ein <h1> ist nicht einfach nur großer Text — es signalisiert einem Screenreader, dass hier eine Hauptüberschrift kommt. Ein <button> ist kein <div> mit Styling — es ist ein interaktives Element mit automatischer Tastaturunterstützung.

Wenn du <div class="button"> verwendest statt <button> , machst du das Leben für Nutzer unnötig schwer. Sie kriegen kein Feedback vom Screenreader, die Tastaturnavigation funktioniert nicht, und JavaScript muss alle diese Funktionen nachbauen.

Wichtigste semantische Tags

<header>, <nav>, <main>, <article>, <section>, <aside>, <footer> — Strukturelemente die die Seitenlayout beschreiben
<h1> bis <h6> — Überschriftenstruktur (keine Übersprünge! H1 H2 H3)
<button>, <input>, <textarea>, <select> — Interaktive Formularelemente
<label for=”…”> — Verbindung zwischen Label und Eingabefeld
<a href=”…”> — Links mit sichtbarem, aussagekräftigem Text

HTML-Code auf dunklem Bildschirm mit farblich hervorgehobenem semantischen Markup

Schematische Darstellung von ARIA-Attributen in einem Baum-Diagramm auf Whiteboard

ARIA-Attribute: Die Brücke zu mehr Kontext

ARIA steht für „Accessible Rich Internet Applications” — es ist eine Standardisierte Weg, um Screenreadern zusätzliche Informationen über Elemente zu geben, die HTML allein nicht liefern kann.

Die drei wichtigsten ARIA-Konzepte sind:

aria-label

Gibt einem Element einen unsichtbaren Namen für Screenreader. Nutze das für Icons, Buttons ohne Text oder andere Elemente, wo visueller Kontext klar ist, aber nicht im HTML steht.


                    <button aria-label="Menü öffnen"></button>

aria-describedby

Verbindet ein Element mit einer längeren Beschreibung anderswo auf der Seite. Perfekt für komplexe Komponenten, die zusätzlichen Kontext brauchen.


                    <input aria-describedby="hint"> <p id="hint">...</p>

aria-live

Sagt dem Screenreader, dass ein Bereich sich dynamisch ändert und angekündigt werden sollte. Nutze das für Echtzeit-Updates, Benachrichtigungen oder Formularfehler.


                    <div aria-live="polite">...</div>

Formularfelder richtig strukturieren

Formulare sind oft der Ort, wo Barrierefreiheit scheitert. Ein Screenreader-Nutzer sitzt vor deinem Formular und weiß nicht, welcher Input zu welchem Label gehört. Eingabefehler werden nicht angezeigt. Der Button am Ende ist kein Button, sondern ein div mit onclick-Handler.

Das Wichtigste zuerst: Jedes Eingabefeld braucht ein echtes <label> -Element mit for -Attribut, das auf die id des Feldes zeigt.

Das funktioniert nicht:


                  <div>Deine E-Mail</div>
                  

                  <input type="email" name="email">

Das funktioniert:


                  <label for="email">Deine E-Mail</label>
                  

                  <input id="email" type="email" name="email">

Wenn ein Feld erforderlich ist, nutze das required -Attribut. Wenn es Fehler gibt, setze aria-invalid="true" und nutze aria-describedby , um die Fehlermeldung zu verlinken. So weiß der Screenreader-Nutzer sofort, was falsch ist und wie er es beheben kann.

Formularfelder mit visuellen und nicht-visuellen Labels auf verschiedenen Bildschirmgrößen

Tester mit Kopfhörern bedient Tastatur — Testing von Screenreader-Kompatibilität

Testen mit echten Screenreadern

Du brauchst nicht auf Bauchgefühl zu verlassen. Es gibt kostenlose Screenreader, mit denen du deine Website selbst testen kannst. Unter Windows gibt’s NVDA (kostenlos, quelloffen), unter macOS ist VoiceOver bereits eingebaut. Es dauert ein paar Minuten, um die Basics zu lernen — und dann merkst du sofort, wo dein Markup versagt.

Beim Testen achte auf drei Dinge:

Kann ich navigieren? Mit Tab-Taste durch alle Buttons, Links und Formularfelder? Mit Pfeiltasten durch Listen?
Versteht der Reader meine Struktur? Werden Überschriften als Überschriften angesagt? Werden Labels mit Inputs verbunden?
Gibt es Fallstricke? Buttons die nicht funktionieren? Dynamische Updates die nicht angekündigt werden? Error-States die verborgen sind?

Das Wichtigste: Teste regelmäßig. Eine Minute Screenreader-Test beim Entwickeln spart dir Stunden später.

Zusammengefasst: Die Kern-Principles

Screenreader-freundliches Markup ist nicht kompliziert — es sind einige wenige Regeln, die wirklich zählen.

1. Semantisches HTML

Nutze echte HTML-Tags: <button> statt <div> , <nav> statt <div class="nav"> . Dein Markup wird selbsterklärend.

2. Labels und ARIA

Jedes Eingabefeld braucht ein echtes Label. Komplexere Komponenten brauchen ARIA-Attribute. Das sind keine Sonderaufgaben — das ist Teil von professionellem Markup.

3. Tastaturnavigation

Alles, das mit der Maus klickbar ist, muss auch mit der Tastatur erreichbar sein. Tab, Enter, Pfeiltasten — diese Shortcuts sollten funktionieren, ohne dass du extra JavaScript brauchst.

4. Regelmäßiges Testen

Lade dir NVDA oder VoiceOver, teste deine Website mit echten Screenreadern. Dann merkst du schnell, was nicht funktioniert. Das ist der beste Weg, um wirklich zu verstehen, wie Nutzer deine Website erleben.

Barrierefreiheit ist nicht eine Zusatzfeature — es ist Teil von gutem Webdesign. Wenn dein HTML sauber ist und deine Formularfelder korrekt gelabelt sind, dann funktioniert deine Website für alle. Das ist nicht verhandelbar.

Zurück zur Kategorie

Hinweis zur Barrierefreiheit

Dieser Artikel bietet informative Richtlinien und Best Practices für die Entwicklung barrierefreier Websites. Die hier vorgestellten Techniken und Standards basieren auf den WCAG 2.1-Richtlinien und branchenüblichen Praktiken. Jede Website hat unterschiedliche Anforderungen und Komplexitäten — es ist wichtig, die Barrierefreiheit in deinem spezifischen Kontext zu evaluieren und möglicherweise Fachleute zu konsultieren. Dieser Artikel ersetzt keine professionelle Beratung und ist nicht als verbindliche Anleitung zu verstehen.