Accessibility

Screenreader-Tests selbst durchführen: eine Anleitung für Teams

06. Juni 2026Zensations

Sie brauchen kein Speziallabor, um grobe Barrieren zu finden. Mit einer Stunde Zeit und Bordmitteln entdeckt jedes Team die wichtigsten Probleme.

Der Tastaturtest als Einstieg

Legen Sie die Maus beiseite und bedienen Sie Ihre wichtigste Strecke nur mit Tabulator, Pfeiltasten und Eingabetaste. Achten Sie darauf, ob der Fokus immer sichtbar ist, ob die Reihenfolge logisch bleibt und ob sich Menüs und Dialoge wieder schließen lassen.

Scheitert dieser Test, scheitert auch jede Screenreader-Nutzung. Deshalb beginnt jedes Audit an dieser Stelle.

Mit vorhandenen Werkzeugen prüfen

Diese Programme sind bereits installiert oder kostenlos verfügbar:

VoiceOver auf macOS und iOS
Narrator auf Windows und NVDA als kostenlose Alternative
TalkBack auf Android
Der Barrierefreiheitsprüfer in den Entwicklerwerkzeugen des Browsers

Was Sie konkret abhören

Lassen Sie sich die Seite vorlesen und notieren Sie jede Stelle, an der Sie als sehende Person raten müssten. Typische Fundstellen sind Schaltflächen ohne Namen, Bilder mit Dateinamen als Beschreibung und Fehlermeldungen, die nur farblich markiert sind.

Dokumentieren Sie jeden Fund mit Seite, Element und erwartetem Verhalten. Diese Liste ist die Grundlage für die Umsetzung.

Aus dem Test eine Routine machen

Nehmen Sie den Tastaturtest in Ihre Abnahmekriterien auf. Jede neue Seite wird vor der Veröffentlichung einmal ohne Maus bedient. Diese Gewohnheit verhindert, dass alte Fehler zurückkehren.

Wer seine Seite einmal ohne Maus bedient hat, versteht Barrierefreiheit sofort.

Warum Barrierefreiheit mehr als nur ein Compliance-Häkchen ist

Die landläufige Meinung reduziert Barrierefreiheit oft auf eine gesetzliche Pflicht, eine Box, die abgehakt werden muss. Doch diese Perspektive verkennt das immense Potenzial. Barrierefreiheit ist ein Qualitätsmerkmal, das die Nutzererfahrung für alle verbessert. Eine Website, die für Screenreader optimiert ist, ist gleichzeitig oft besser strukturiert, schneller und leichter verständlich für jeden Besucher. Es geht darum, digitale Produkte so zu gestalten, dass sie für die größtmögliche Anzahl von Menschen nutzbar sind. Dies schließt Menschen mit unterschiedlichen Fähigkeiten, technischen Gegebenheiten und situativen Einschränkungen ein.

In Österreich und der gesamten DACH-Region gibt es eine stetig wachsende Zahl von Menschen, die auf assistierende Technologien angewiesen sind. Rund 1,8 Millionen Österreicher leben mit einer Behinderung, viele davon haben Sehbeeinträchtigungen. Für Unternehmen bedeutet das, dass ein erheblicher Teil der potenziellen Kund:innen oder Nutzer ausgeschlossen wird, wenn digitale Angebote nicht barrierefrei sind. Ein Beispiel: Eine Online-Bank in Wien verzeichnete nach der barrierefreien Überarbeitung ihres Banking-Portals einen Rückgang der Supportanfragen um 15 % bei gleichzeitiger Steigerung der Online-Abschlüsse um 8 %. Dies zeigt, dass Investitionen in Barrierefreiheit direkte positive Auswirkungen auf das Geschäft haben können, indem sie die Effizienz steigern und neue Zielgruppen erschließen.

Welche Rolle spielen semantisches HTML und ARIA bei Screenreader-Tests?

Semantisches HTML und ARIA (Accessible Rich Internet Applications) sind die Grundpfeiler für eine funktionierende Screenreader-Nutzung. Semantisches HTML bedeutet, die richtigen HTML-Elemente für ihre beabsichtigte Bedeutung zu verwenden. Ein <h1> für die Hauptüberschrift, <p> für Absätze, <button> für Schaltflächen und <nav> für die Navigation. Dies gibt Screenreadern automatisch die notwendigen Informationen über die Struktur und Funktion der Inhalte. ARIA ergänzt diese Semantik, insbesondere bei komplexen UI-Komponenten, die mit reinem HTML nicht ausreichend beschrieben werden können. ARIA-Attribute wie role="alert", aria-label oder aria-expanded übermitteln zusätzliche Bedeutungen und Zustände an assistive Technologien.

Ein konkretes Beispiel veranschaulicht dies: Ein Entwicklerteam in Graz nutzte für ein Akkordeon-Menü zunächst Div-Elemente mit JavaScript. Screenreader konnten die Inhalte zwar vorlesen, aber nicht erkennen, dass es sich um ausklappbare Abschnitte handelte oder welcher Abschnitt gerade aktiv war. Durch die Umstellung auf <details> und <summary> für die Basisfunktion und das Hinzufügen von aria-expanded sowie aria-controls für die dynamischen Zustände wurde das Akkordeon plötzlich vollständig zugänglich. Die Benutzer konnten nun mit dem Screenreader erkennen, ob ein Abschnitt aufgeklappt war und diesen gezielt steuern. Dieser Ansatz verbessert die Usability erheblich, auch für nicht-Screenreader-Nutzer, die von einer klareren Struktur profitieren.

Checkliste für semantisches HTML und ARIA in Ihrem Screenreader-Test

Sind Überschriften hierarchisch und logisch aufgebaut (H1, H2, H3 usw.)?
Werden Listen (<ul>, <ol>) korrekt verwendet, nicht nur mit Zeilenumbrüchen simuliert?
Sind Formularfelder mit passenden <label>-Elementen verknüpft?
Verwenden interaktive Elemente wie Buttons oder Links die entsprechenden HTML-Tags?
Sind Icons oder reine Grafik-Links mit einem alt-Text oder aria-label versehen, der ihre Funktion beschreibt?
Werden ARIA-Rollen und Zustände korrekt eingesetzt, insbesondere bei dynamischen Inhalten wie Tabs, Modals oder Akkordeons?
Vermeiden Sie unnötiges oder überflüssiges ARIA, das die Semantik verwirren kann.

Wie teste ich Formulare und Interaktionen mit Screenreadern effektiv?

Formulare sind kritische Elemente jeder Website. Für Screenreader-Nutzer stellen sie jedoch oft Hürden dar, wenn sie nicht korrekt implementiert sind. Ein effektiver Test konzentriert sich darauf, den gesamten Ausfüllprozess zu simulieren: von der Navigation zum Formular bis zum Absenden. Jedes Formularfeld muss ein klares, programmatisch verknüpftes Label haben. Screenreader sollten den Feldtyp und eventuelle Anforderungen, wie "Pflichtfeld", deutlich ansagen. Fehlerprüfungen müssen sowohl visuell als auch auditiv erfolgen, idealerweise mit aria-live-Regionen, die Fehlermeldungen sofort ankündigen.

Nehmen wir das Anmeldeformular eines Online-Shops in Salzburg. Bei einer ersten Testrunde stellte ein Screenreader-Nutzer fest, dass Fehlermeldungen nach dem Absenden nur rot eingefärbt waren, aber nicht vorgelesen wurden. Auch der Fokus sprang nicht automatisch zum ersten fehlerhaften Feld zurück. Durch die Ergänzung von aria-describedby für die Fehlermeldung und das Setzen des Fokus mittels JavaScript konnte dieses Problem behoben werden. Zusätzlich wurden aria-required für Pflichtfelder und eine sichtbare Legende für Sternchen (*) implementiert. Dies ermöglichte es blinden Nutzern, das Formular selbstständig und ohne Frustration auszufüllen. Solche detaillierten Interaktionstests sind entscheidend, um reale Barrieren zu identifizieren und zu beheben.

Schritte für den Formulartest mit Screenreader

Navigieren Sie mit Tabulator und Pfeiltasten durch das gesamte Formular.
Prüfen Sie, ob jedes Feld ein sprechendes Label hat und der Screenreader es korrekt vorliest.
Überprüfen Sie, ob Pflichtfelder als solche gekennzeichnet und vorgelesen werden.
Testen Sie die Eingabe in verschiedene Feldtypen (Text, Radiobuttons, Checkboxen, Dropdowns).
Provozieren Sie Fehler und prüfen Sie, ob Fehlermeldungen klar und zeitnah vom Screenreader ausgegeben werden und der Fokus korrekt gesetzt wird.
Testen Sie die Übermittlung des Formulars und die Bestätigungsnachricht.
Stellen Sie sicher, dass der Fokus nach dem Absenden oder nach Fehlern an eine sinnvolle Stelle springt.

Welche typischen Probleme treten bei Bildern, Grafiken und Multimedia auf?

Bilder, Grafiken und Multimedia-Inhalte sind häufige Stolpersteine für Screenreader-Nutzer. Das häufigste Problem ist das Fehlen von Alternativtexten (alt-Attributen) oder deren unzureichende Qualität. Ein alt-Text sollte das Bild in seinem Kontext beschreiben, nicht nur "Bild" oder den Dateinamen. Dekorative Bilder sollten leere alt-Attribute (alt="") haben, damit sie von Screenreadern ignoriert werden. Bei komplexen Grafiken, wie Infografiken oder Diagrammen, ist oft eine ausführliche Beschreibung auf der Seite selbst oder über einen Link erforderlich, da der alt-Text allein nicht ausreicht. Für Videos und Audioinhalte sind Untertitel, Transkripte und Audiodeskriptionen unerlässlich. Ohne diese Hilfen bleiben wesentliche Informationen für gehörlose, hörbeeinträchtigte oder blinde Nutzer verborgen.

Ein Projekt für ein Tourismusportal in der Steiermark enthielt zahlreiche Bilder von Landschaften und Aktivitäten. Zunächst hatten die Bilder generische alt-Texte wie "Landschaftsbild_01.jpg". Ein Test mit VoiceOver zeigte, dass blinde Nutzer keine Ahnung hatten, was auf den Bildern zu sehen war. Nach einer Überarbeitung wurden die alt-Texte präzisiert: "Malerische Almwiesen mit Bergblick im Salzkammergut" oder "Familie beim Wandern an einem Bergsee". Für ein Imagevideo wurde ein Transkript und Untertitel hinzugefügt. Das Ergebnis: Die Zugänglichkeit stieg signifikant und die Nutzerbindung verbesserte sich messbar, da alle Besucher:innen die Inhalte vollständig erfassen konnten. Die Investition in qualitativ hochwertige Alternativtexte und Multimedia-Zugänglichkeit hat sich hier ausgezahlt und zeigt, dass auch für touristische Angebote Barrierefreiheit ein Gewinn ist.

Checkliste für Bilder, Grafiken und Multimedia

Haben alle informativen Bilder aussagekräftige alt-Texte?
Sind dekorative Bilder mit alt="" versehen, damit Screenreader sie ignorieren?
Gibt es für komplexe Grafiken oder Diagramme eine Textalternative oder detaillierte Beschreibung?
Sind für Videos und Audioinhalte Untertitel und Transkripte verfügbar?
Gibt es für Videos, die wichtige visuelle Informationen enthalten, eine Audiodeskription?
Können Mediaplayer ausschließlich über die Tastatur bedient werden (Play, Pause, Lautstärke)?

Können automatische Tools und KI-basierte Prüfungen den manuellen Test ersetzen?

Automatische Barrierefreiheitstools und KI-basierte Prüfungen sind wertvolle Helfer, aber sie können den manuellen Screenreader-Test nicht vollständig ersetzen. Sie sind hervorragend darin, technische Fehler wie fehlende alt-Attribute, unzureichenden Farbkontrast oder fehlende Formular-Labels zu identifizieren. Sie können große Mengen an Seiten schnell scannen und einen ersten Überblick über offensichtliche Mängel geben. Dies beschleunigt den Audit-Prozess und hilft, die häufigsten und leicht behebbaren Probleme zu finden. Auch für wiederkehrende Routinekontrollen oder als Teil eines CI/CD-Prozesses sind sie unverzichtbar.

Allerdings stoßen sie an ihre Grenzen, wenn es um die kontextuelle Bedeutung, die logische Lesereihenfolge oder die Usability geht. Ein Tool kann zwar erkennen, dass ein alt-Attribut existiert, aber nicht beurteilen, ob der Inhalt "Bild 123" sinnvoll ist. Es kann auch nicht fühlen, wie frustrierend es ist, wenn ein komplexes Menü mit dem Screenreader umständlich zu bedienen ist. Ein Team in Zürich setzte zunächst ausschließlich auf automatisierte Tests und verpasste dabei gravierende Navigationsprobleme, die erst durch manuelle Screenreader-Tests mit echten Nutzer:innen aufgedeckt wurden. Ein erfahrener Mensch, der mit einem Screenreader interagiert, kann die tatsächliche Nutzererfahrung bewerten und Probleme erkennen, die kein Algorithmus findet. Daher ist eine Kombination aus automatisierten Prüfungen und gründlichen manuellen Tests der effektivste Ansatz, um eine wirklich barrierefreie Website zu gewährleisten. Für einen detaillierteren Einblick in die Arbeit mit KI empfehle ich unseren Beitrag zu AI-Strategie ohne Hype.

Welche Rolle spielt die Farbgebung und der Kontrast für die Barrierefreiheit?

Die Farbgebung und der Kontrast spielen eine entscheidende Rolle für die Barrierefreiheit, insbesondere für Menschen mit Sehschwäche, Farbenblindheit oder für Nutzer:innen in hellen Umgebungen. Ein unzureichender Kontrast zwischen Text und Hintergrund macht Inhalte schwer lesbar oder sogar unlesbar. Dies betrifft nicht nur reinen Text, sondern auch Icons, Links und Schaltflächen, die wichtige Informationen oder interaktive Elemente darstellen. Die Web Content Accessibility Guidelines (WCAG) definieren klare Mindestkontrastverhältnisse (mindestens 4,5:1 für normalen Text und 3:1 für großen Text oder UI-Komponenten), die eingehalten werden müssen, um eine ausreichende Lesbarkeit zu gewährleisten. Darüber hinaus sollten Farben niemals das alleinige Mittel zur Informationsvermittlung sein. Wenn eine Fehlermeldung nur durch rote Farbe gekennzeichnet ist, ist sie für Farbenblinde nicht erkennbar.

Ein digitales Rathaus in Oberösterreich hatte ein neues Design eingeführt, das auf einem hellgrauen Text auf weißem Hintergrund basierte, was elegant wirken sollte. Erste Rückmeldungen von Bürgern zeigten jedoch, dass viele Schwierigkeiten beim Lesen der Inhalte hatten. Ein schneller Kontrast-Check offenbarte, dass der Kontrast weit unter dem WCAG-Standard lag. Durch eine Anpassung der Schriftfarbe auf ein dunkleres Grau konnte der Kontrast auf das erforderliche Niveau gebracht werden, ohne das Gesamtdesign zu zerstören. Zudem wurden wichtige Statusmeldungen, die zuvor nur farblich markiert waren, um ein Icon und einen erklärenden Text ergänzt. Solche Anpassungen sind oft einfach umzusetzen, haben aber eine immense Wirkung auf die Zugänglichkeit und die Akzeptanz des Angebots durch die Nutzer:innen.

Checkliste für Farbgebung und Kontrast

Entspricht der Kontrast von Text zu Hintergrund den WCAG-Richtlinien (mind. 4,5:1)?
Gilt dies auch für Text in Grafiken oder Logos, sofern sie informativ sind?
Werden wichtige Informationen oder Zustände nicht ausschließlich durch Farbe vermittelt (z.B. Links, Fehlermeldungen, aktive Menüpunkte)?
Ist der Kontrast von Icons und UI-Elementen (z.B. Checkboxen, Radiobuttons) ausreichend (mind. 3:1)?
Können Nutzer Farbschemata anpassen, falls dies für die Zielgruppe relevant ist?

Barrierefreiheit in den Entwicklungsprozess integrieren: So geht's

Barrierefreiheit sollte kein nachträglicher Gedanke sein, sondern von Anfang an in den Entwicklungsprozess integriert werden. Dies beginnt bereits in der Konzeptionsphase und im Design, wo Wireframes und Mockups auf ihre Zugänglichkeit hin überprüft werden. Wenn Barrierefreiheit "shift left" in den Prozess rückt, sind Fehler leichter und kostengünstiger zu beheben. Es erfordert ein Umdenken im gesamten Team: Designer berücksichtigen Kontrast und logische Reihenfolge, Entwickler verwenden semantisches HTML und ARIA, und Redakteure schreiben aussagekräftige Alternativtexte. Regelmäßige Schulungen und die Einbindung von Barrierefreiheitsexperten sind hierbei essenziell. Ein Discovery-Workshop zu Beginn eines Projekts kann helfen, diese Anforderungen frühzeitig zu definieren, siehe auch unseren Beitrag zum Discovery-Workshop.

Ein Softwareunternehmen aus Wien implementierte ein "Accessibility Champion"-Programm. In jedem Team wurde ein Entwickler oder Designer zum Barrierefreiheits-Beauftragten geschult. Diese Champions fungierten als Ansprechpartner und förderten das Bewusstsein im Team. Sie führten regelmäßige Mini-Audits durch und organisierten Wissenstransfer-Sessions. Innerhalb von sechs Monaten sank die Anzahl der Barrierefreiheits-Bugs um 40 %, und die Zeit für die Behebung der verbleibenden Fehler reduzierte sich um 25 %. Dieses Beispiel zeigt, dass die Integration von Barrierefreiheit als fester Bestandteil der Projektkultur und durch dedizierte Rollen die Effizienz steigert und die Qualität des Endprodukts erheblich verbessert. Die anfängliche Investition in Schulungen und interne Prozesse zahlt sich durch nachhaltigere und besser zugängliche Produkte aus.

Checkliste für die Integration von Barrierefreiheit in den Prozess

Sind Barrierefreiheitsrichtlinien Teil des Design-Systems und der Styleguides?
Werden Barrierefreiheits-Aspekte bereits in den User Stories oder Anforderungen berücksichtigt?
Führen Entwickler Code-Reviews mit Fokus auf Barrierefreiheit durch?
Sind automatisierte Barrierefreiheitstests in die CI/CD-Pipeline integriert?
Werden manuelle Screenreader-Tests regelmäßig von geschulten Personen durchgeführt?
Gibt es einen Prozess für das Management und die Behebung von Barrierefreiheits-Bugs?
Werden die Teams regelmäßig in Barrierefreiheit geschult?

Zusätzliche Tools und Ressourcen für vertiefte Screenreader-Tests

Über die genannten Bordmittel hinaus gibt es eine Reihe von erweiterten Tools und Ressourcen, die bei vertieften Screenreader-Tests helfen können. Für Windows ist der NVDA Screenreader eine kostenlose und sehr beliebte Alternative zu Narrator, die von vielen professionellen Testern genutzt wird. Für die Überprüfung von Kontrastverhältnissen gibt es Tools wie den WebAIM Contrast Checker oder Lighthouse im Chrome-Browser. Browser-Erweiterungen wie "axe DevTools" oder "WAVE Evaluation Tool" können ebenfalls erste automatisierte Analysen direkt im Browser durchführen. Für mobile Tests sind die jeweiligen Bordmittel (TalkBack auf Android, VoiceOver auf iOS) die erste Wahl. Darüber hinaus bieten zahlreiche Online-Ressourcen, wie die des W3C WAI, detaillierte Anleitungen und Best Practices.

Ein Entwicklerteam in Linz, das an einer komplexen Webanwendung arbeitete, setzte zusätzlich zum manuellen Test auf die "Accessibility Inspector"-Funktion in den Entwicklertools von Chrome und Firefox. Diese Funktion visualisiert den Accessibility Tree, den Screenreader verwenden, und macht so schnell ersichtlich, welche Informationen ein Screenreader über ein Element erhält. Dies half dem Team, versteckte semantische Fehler und ARIA-Fehlkonfigurationen zu finden, die im reinen manuellen Test leicht übersehen worden wären. Durch den Einsatz dieser spezialisierten Tools konnte die Genauigkeit der Tests erhöht und die Qualität der Anwendung signifikant verbessert werden. Dies zeigt, dass eine Kombination aus manuellem Test, grundlegenden Bordmitteln und spezialisierten Analyse-Tools den größten Erfolg bringt.

Wir bei Zensations beraten Sie gerne umfassend zu diesem Thema. Egal ob es um die technische Umsetzung geht (Website-Umsetzung mit AI) oder Sie eine strategische Beratung zur Integration von Barrierefreiheit in Ihr Unternehmen wünschen (Digitale Beratung). Sprechen Sie uns an und wir finden gemeinsam die passenden Schritte.

Weitere nützliche Tools und Ressourcen

WebAIM: Umfangreiche Ressourcen und ein Contrast Checker
Axe DevTools (Browser Extension): Automatische Barrierefreiheits-Prüfungen
WAVE Evaluation Tool (Browser Extension): Visuelle Darstellung von Barrierefreiheits-Problemen
Lighthouse (in Chrome DevTools): Audit-Funktion inklusive Barrierefreiheit
Accessibility Tree (in Browser DevTools): Visualisiert, wie der Screenreader die Seite versteht
W3C WAI Tutorials: Detaillierte Anleitungen und Beispiele

Häufige Fragen

Ersetzt das ein professionelles Audit?

Nein, aber es reduziert die Anzahl offensichtlicher Mängel deutlich.

Wie viel Zeit kostet der Test?

Für eine typische Strecke reichen 30 bis 60 Minuten.

Wer im Team sollte testen?

Redaktion, Design und Entwicklung gemeinsam, weil die Ursachen in allen drei Bereichen liegen.

Ihr nächster Schritt

Sie möchten dieses Thema für Ihr Unternehmen umsetzen? Wir prüfen Ihre Ausgangslage, benennen die drei wirksamsten Maßnahmen und nennen Ihnen Aufwand und Zeitrahmen. Schreiben Sie uns an office@zensations.at oder starten Sie mit dem kostenlosen GEO-Check.