Wie Screenreader eine Website tatsächlich navigieren – und warum das Ihren Blick auf Korrekturen verändert
Veröffentlicht am 25.8.2026 · Von Cluesia Team
Viele Befunde in einem Barrierefreiheits-Bericht („fehlender Alternativtext", „Überschriftenebenen springen von h2 auf h4", „Button hat keinen zugänglichen Namen") lesen sich wie willkürliche Regelbefolgung, bis man versteht, was ein Screenreader mit Ihrer Seite tatsächlich macht. Danach wirken die meisten Befunde nicht mehr willkürlich.
Die Seite wird nicht von oben nach unten wie ein Dokument gelesen
Ein sehender Besucher überfliegt eine Seite visuell – die Augen springen sofort zu einer großen Überschrift, einem auffälligen Button, einer vertrauten Navigationsleiste, geleitet von Layout und visueller Hierarchie. Ein Screenreader-Nutzer hat diese visuelle Abkürzung nicht. Stattdessen stellen Screenreader die Seite als strukturierten Baum dar, der aus dem zugrunde liegenden HTML entsteht: Überschriften, Landmarks (wie „Navigation", „Hauptinhalt", „Fußbereich"), Links, Formularfelder und Buttons, jeweils mit Namen und Rolle. Screenreader-Nutzer navigieren direkt in diesem Baum – von Überschrift zu Überschrift, von Landmark zu Landmark oder von Link zu Link – mit eigenen Tastenkürzeln, statt zu scrollen und zu überfliegen wie ein sehender Besucher.
Deshalb ist die Überschriftenstruktur viel wichtiger, als es scheint. Ein sehender Nutzer wirft einen Blick auf die Seite und versteht sofort: „das ist der wichtige Titel, das ist ein Unterabschnitt." Ein Screenreader-Nutzer, der zwischen Überschriften springt, um sich einen Überblick zu verschaffen, verlässt sich vollständig darauf, dass Ihre h1- bis h6-Tags in logischer Reihenfolge verwendet werden – springen Sie von einer h2 direkt auf eine h4, haben Sie visuell nichts kaputt gemacht, aber die Karte zerstört, auf die sich ein Screenreader-Nutzer zum Verständnis der Seitenstruktur stützt.
Der „zugängliche Name" leistet viel
Jedes interaktive Element – ein Button, ein Link, ein Formularfeld – braucht einen sogenannten zugänglichen Namen: den Text, den ein Screenreader für dieses Element tatsächlich ansagt. Manchmal ist er offensichtlich (ein Button mit der Aufschrift „Absenden" hat „Absenden" als zugänglichen Namen). Ein reiner Icon-Button (eine Lupe für die Suche, ein Papierkorb für Löschen) hat aber überhaupt keinen sichtbaren Text – fehlt ein aria-label oder ein ähnliches Attribut, sagt ein Screenreader nur „Button" an, ohne Hinweis darauf, was er bewirkt. Das ist einer der häufigsten Befunde bei echten Audits, und er ist völlig unsichtbar, wenn Sie sich nur die Seite ansehen, denn visuell bedeutet das Icon „offensichtlich" Suchen oder Löschen.
Warum Alternativtext mehr ist als „das Bild beschreiben"
Alternativtext gibt es genau deshalb, weil ein Screenreader ein Bild nicht so deuten kann wie ein sehender Mensch – er kann nur den Text ansagen, den Sie als Ersatz angegeben haben. Guter Alternativtext beschreibt Funktion oder Inhalt des Bildes im Kontext, keine allgemeine Bildunterschrift: Ein rein dekoratives Bild sollte einen leeren Alternativtext haben (alt=""), damit ein Screenreader es ganz überspringt, statt etwas Unhilfreiches wie „image1234.jpg" anzusagen; ein Produktfoto, das die einzige Informationsquelle für Farbe oder Design eines Produkts ist, braucht echten, konkreten Alternativtext; ein Bild, das als Button dient (etwa ein Social-Media-Icon mit Link zu Ihrer Twitter/X-Seite), braucht einen Alternativtext, der die Aktion beschreibt, nicht das Icon („Folgen Sie uns auf X", nicht „Vogel-Logo").
Die praktische Erkenntnis
Nichts davon erfordert, die technische Sprache von WCAG auswendig zu lernen. Es erfordert eine gedankliche Umstellung: Bevor Sie einen Befund beheben, fragen Sie sich: „Was würde ein Screenreader-Nutzer hier tatsächlich erleben – anhand der Strukturinformationen im Code, nicht anhand des visuellen Layouts?" Das meiste, was in einem Bericht auftaucht – Überschriftenreihenfolge, zugängliche Namen, Alternativtexte, Formularbeschriftungen –, lässt sich auf genau diese Frage zurückführen. Sehen Sie eine echte Aufschlüsselung der WCAG-Kriterien nach Prinzipien, oder prüfen Sie Ihre Website kostenlos, um zu sehen, was ein Scan auf Ihrer eigenen Website tatsächlich findet.
Sehen Sie, was Ihrer eigenen Website fehlt
Das hier ist Hintergrundlektüre — am schnellsten erfahren Sie Ihren tatsächlichen Stand mit einem kostenlosen Scan Ihrer eigenen Startseite.
Website kostenlos prüfen