Screenreader-Kompatibilität

Screenreader-Kompatibilität bezeichnet die Fähigkeit einer Webseite, von einem Screenreader korrekt interpretiert und in Sprache oder Brailleschrift umgewandelt zu werden.

Was bedeutet Screenreader-Kompatibilität?

Screenreader-Kompatibilität bedeutet, dass eine Website von Screenreadern zuverlässig interpretiert und in Sprache oder Brailleschrift ausgegeben werden kann. Screenreader nutzen nicht das „Aussehen“ der Seite, sondern die semantische Struktur und die zugänglichen Informationen im Code.

Damit das funktioniert, müssen Inhalte, Navigation und Interaktionen so umgesetzt sein, dass sie:

  • logisch strukturiert sind
  • per Tastatur bedienbar sind
  • sinnvolle Namen und Zustände haben
  • dynamische Änderungen verständlich ankündigen

Warum ist das wichtig?

Für blinde und sehbehinderte Menschen ist ein Screenreader oft der zentrale Zugang zum Web. Wenn Screenreader-Kompatibilität fehlt, entstehen echte Barrieren:

  • Menüs sind nicht nutzbar
  • Formulare sind unverständlich
  • Inhalte werden in falscher Reihenfolge vorgelesen
  • Buttons und Links haben keine sinnvollen Namen
  • modale Dialoge „fangen“ den Fokus nicht ab

Neben dem ethischen Aspekt ist das auch relevant für WCAG und je nach Kontext für BITV.

Wie Screenreader Websites „lesen“

Screenreader arbeiten entlang eines Accessibility Trees, der aus dem DOM und zusätzlichen Informationen besteht:

  • HTML Semantik (h1 bis h6, nav, main, button, form)
  • sichtbare Textinhalte
  • Alternativtexte
  • Labels und Beschriftungen
  • ARIA Rollen, Namen, Zustände
  • Fokus und Tastaturreihenfolge

Wenn eine Seite visuell gut aussieht, aber strukturell falsch gebaut ist (z. B. nur divs), kann sie für Screenreader trotzdem unbenutzbar sein.

Zentrale Bausteine für Screenreader-Kompatibilität

1) Semantisches HTML

Semantische Elemente helfen Screenreadern, die Seite zu verstehen.

Wichtig sind unter anderem:

  • genau eine h1 pro Seite
  • korrekte Überschriftenhierarchie
  • main Bereich für den Hauptinhalt
  • nav Bereiche für Navigationen
  • button für Aktionen, a für Links

Beispiel: sinnvolle Struktur (Code Snippet)

<header>
  <nav aria-label="Hauptnavigation">
    <a href="/leistungen/">Leistungen</a>
    <a href="/kontakt/">Kontakt</a>
  </nav>
</header>

<main id="content">
  <h1>Screenreader-Kompatibilität</h1>
  <h2>Warum das wichtig ist</h2>
  <p>...</p>
</main>

2) Aussagekräftige Link- und Button-Texte

„Hier klicken“ ist für Screenreader in einer Linkliste nicht hilfreich. Der Text muss auch ohne Kontext verständlich sein.

Beispiele:

  • gut: „Preise“, „Kontakt“, „Referenzen“
  • schlecht: „Mehr“, „Weiter“, „Hier klicken“

3) Bilder und Alternativtexte

  • Informative Bilder brauchen einen sinnvollen Alt-Text.
  • Dekorative Bilder sollten einen leeren Alt-Text haben, damit sie nicht stören.

Beispiele (Code Snippet)

<img src="/team.jpg" alt="Teamfoto im Büro" />

<img src="/divider.svg" alt="" />

4) Formulare: Labels und Fehlermeldungen

Formulare sind eine der häufigsten Barrieren.

Minimum:

  • jedes Feld hat ein label
  • Fehlermeldungen sind eindeutig
  • Pflichtfelder sind erkennbar
  • Fokus springt sinnvoll zur Fehlermeldung

Beispiel (Code Snippet)

<label for="email">E-Mail</label>
<input id="email" name="email" type="email" autocomplete="email" required />

<p id="email-error">Bitte geben Sie eine gültige E-Mail ein.</p>

5) Tastatur und Fokus-Management

Screenreader-Nutzer arbeiten häufig per Tastatur. Darum:

  • sichtbarer Fokus ist Pflicht
  • Tab-Reihenfolge muss logisch sein
  • keine Fokus-Fallen
  • Skip-Link ist sehr hilfreich

Beispiel: Skip-Link (Code Snippet)

<a href="#content">Zum Inhalt springen</a>

ARIA: wann es hilft und wann es schadet

ARIA kann komplexe Komponenten zugänglich machen, wird aber oft falsch eingesetzt.

Grundregeln:

  • nutzen Sie zuerst natives HTML, wenn möglich
  • ARIA nur ergänzen, wenn Semantik fehlt
  • keine ARIA Rollen auf Elemente setzen, die bereits korrekt sind

Häufig sinnvolle ARIA Patterns

  • aria-label für Buttons ohne Text
  • aria-expanded bei aufklappbaren Menüs
  • aria-controls zur Zuordnung von Trigger und Inhalt
  • aria-live für dynamische Statusmeldungen

Beispiel: Toggle Button (Code Snippet)

<button aria-expanded="false" aria-controls="menu" aria-label="Menü öffnen">
  ☰
</button>

<nav id="menu" hidden>
  <a href="/leistungen/">Leistungen</a>
</nav>

Typische Fehler, die Screenreader-Kompatibilität brechen

  • Überschriften werden nur „optisch“ formatiert, ohne echte h-Tags
  • Click-Elemente sind divs statt buttons
  • Icons ohne Text und ohne aria-label
  • modale Dialoge ohne Fokus-Führung
  • Fehlermeldungen werden nur farblich angezeigt
  • dynamische Inhalte ändern sich ohne Ankündigung
  • Links haben identische Texte, aber unterschiedliche Ziele
  • Tabellen ohne Kopfzeilen oder ohne klare Zuordnung

Screenreader-Kompatibilität testen

Automatische Tools finden nur einen Teil der Probleme. Sinnvoll ist die Kombination aus:

  • automatischer Prüfung (z. B. Lighthouse)
  • manuelle Tastaturtests
  • Screenreader-Tests mit realen Geräten

Wichtiger als die Tool-Auswahl ist ein reproduzierbarer Testablauf und klare Fix-Prioritäten.

Checkliste

  • Überschriftenhierarchie ist korrekt und logisch
  • Navigation und Interaktionen sind per Tastatur nutzbar
  • Fokus ist sichtbar und Reihenfolge ist sinnvoll
  • Formulare haben Labels, klare Fehlermeldungen und Pflichtfeld-Logik
  • Links und Buttons sind eindeutig benannt
  • Alt-Texte sind korrekt gesetzt (informativ oder leer dekorativ)
  • ARIA wird sparsam und korrekt eingesetzt
  • dynamische Inhalte werden verständlich angekündigt

Fazit

Screenreader-Kompatibilität entsteht durch sauberes HTML, klare Inhalte, gutes Fokus-Management und einen vorsichtigen Umgang mit ARIA. Wenn diese Grundlagen stimmen, wird Ihre Website nicht nur zugänglicher, sondern oft auch stabiler, besser wartbar und nutzerfreundlicher für alle.

jetzt online