Barrierefreiheit: Warum manuelles Testen unverzichtbar bleibt
In der Diskussion um digitale Barrierefreiheit hört man oft, dass automatisierte Tests ausreichen oder dass künstliche Intelligenz früher oder später alle Barrieren beseitigen wird. So verlockend diese Vorstellung auch sein mag – die Realität sieht anders aus.
Automatisierte Tests erfassen längst nicht alle Barrieren, viele bleiben unentdeckt. Darunter befinden sich leider auch Barrieren, die für manche Nutzer:innen eine erhebliche Hürde darstellen.
Deshalb bleibt manuelles Testen ein unverzichtbarer Bestandteil barrierefreier Entwicklung.
Grenzen automatisierter Barrierefreiheits-Tests
Wer sich ausschließlich auf automatisierte Tests verlässt, übersieht viele Hindernisse, welche die Nutzung einer Website erheblich erschweren können. Hier sind einige Beispiele für Barrieren, die nur durch menschliche Überprüfung erkannt werden können:
Alternativtexte – Wenn Maschinen die Bedeutung nicht verstehen
Automatische Tests prüfen lediglich, ob ein Bild einen Alternativtext besitzt – nicht jedoch, ob dieser sinnvoll ist. Ein Alt-Text wie „Bild“ oder „Foto“ bringt sehbeeinträchtigten Nutzer:innen keinerlei Mehrwert. Dasselbe gilt für vage Beschriftungen von Schaltflächen oder Links wie „Weiter“. Die inhaltliche Qualität dieser Beschreibungen bleibt eine Aufgabe menschlicher Einschätzung.
KI-gestützte Werkzeuge können hier zwar unterstützen, doch ihre Vorschläge sollten kritisch geprüft werden. Sie erkennen oft nicht den Kontext oder die eigentliche Aussage eines Bildes. Ein gutes Beispiel dafür sind humorvolle oder metaphorische Darstellungen, deren Bedeutung eine KI kaum erfassen kann.
Lesbarkeit – Mehr als nur eine Frage der Schriftart
Jeder kennt das Problem mit schwer lesbaren Handschriften – und genauso verhält es sich mit schlecht gewählten Schriftarten auf Websites. Verschnörkelte oder zu kleine Schriften erschweren das Lesen nicht nur für Menschen mit Sehbeeinträchtigungen oder Dyslexie, sondern auch für viele andere Nutzer:innen. Hier kann kein automatischer Test eine echte Nutzererfahrung simulieren.
„Kreative“ Programmierung – Wenn HTML gegen Barrierefreiheit arbeitet
Ein <span>-Element mit Klick-Event ist kein Button – daran gibt es keinen Zweifel. Dennoch begegnet man dieser Praxis immer wieder. Während Mausnutzer:innen problemlos interagieren können, sind Tastaturnutzende ausgeschlossen, da <span>-Elemente nicht von Natur aus fokussierbar sind.
Ein häufiger Fehler ist der Versuch, mangelnde Barrierefreiheit mit ARIA-Attributen zu kaschieren. Doch falsche ARIA-Implementierungen können zusätzliche Barrieren schaffen. Der nachhaltige Weg besteht darin, von Anfang an semantisch korrektes HTML zu nutzen und es gezielt mit ARIA-Attributen zu ergänzen, wo nötig.
Unzureichendes CSS – Wenn der Fokus verloren geht
Auch wenn eine Website technisch mit der Tastatur navigierbar ist – was nützt das, wenn Nutzer:innen nicht sehen, wo sie sich gerade befinden? Fehlendes oder unzureichendes Fokus-Handling führt dazu, dass Tastaturnutzende orientierungslos bleiben.
Weitere Styling-Probleme, die automatisierte Tests nicht erkennen:
- Links, die nicht eindeutig als solche erkennbar sind
- Falsch verwendete Cursor-Stile, die irreführend sind
Überschriftenstruktur – Automatisch korrekt, aber nicht unbedingt sinnvoll
Automatische Tests können erkennen, ob eine Überschriften-Hierarchie eingehalten wird – doch ob diese Struktur den Inhalt tatsächlich sinnvoll gliedert, bleibt unerkannt. Eine h1-h2-h3-Hierarchie allein bedeutet nicht automatisch, dass die Seite logisch aufgebaut ist. Hier braucht es den kritischen Blick eines Menschen.
Missverständliche Formulierungen – Wenn kleine Details große Auswirkungen haben
Textverständlichkeit ist mehr als nur Rechtschreibung. Beispielsweise kann die Uhrzeit „8.15 Uhr“ von Screenreadern falsch interpretiert werden, während „8:15 Uhr“ eindeutiger ist. Ähnlich verhält es sich mit Datumsangaben: „21.12.2011“ kann für einige Mitmenschen schwer erfassbar sein, während „21. Dezember 2011“ eindeutiger ist.
Wie können Entwickler:innen vorgehen?
Bewährt hat sich, Barrierefreiheit nicht erst am Ende zu prüfen, sondern bereits während der Entwicklung mitzudenken und zu testen. Sobald ein testbarer Entwicklungsstand vorliegt, können automatische Test-Tools eingesetzt werden, um erste Barrieren aufzudecken und gezielt zu beheben.
Erst wenn diese Tools keine offensichtlichen Probleme mehr melden, sollte das manuelle Nachtesten folgen. Dazu gehört unter anderem, die Anwendung ausschließlich mit der Tastatur zu bedienen: Sind alle Inhalte erreichbar? Lassen sich alle Funktionen genauso nutzen wie mit der Maus?
Fällt dieser Test positiv aus, kann im nächsten Schritt ein Screenreader eingesetzt werden. Ideal ist es, die Augen zu schließen und die Anwendung erneut zu testen: Sind alle Inhalte verständlich aufgebaut? Werden wichtige Informationen korrekt ausgegeben oder fehlen Hinweise?
Sind an diesem Punkt alle relevanten WCAG-Kriterien erfüllt und liefern die Tests zufriedenstellende Ergebnisse, ist eine solide Grundlage für ein inklusives Nutzungserlebnis geschaffen – für möglichst alle Anwender:innen.
Um die beschriebenen Schritte umzusetzen, können verschiedene Tools unterstützen.
Für erste Prüfungen eignen sich automatische Test-Tools wie
- WAVE | Browser-Erweiterung: Firefox / Chrome/Brave
- axe DevTools | Browser-Erweiterung: Firefox / Chrome/Brave
- Google Lighthouse
Für das manuelle Testen können folgende Tools unterstützen:
- Web Disability Simulator | Browser-Erweiterung: Chrome/Brave
- This is WCAG | Website zur Filterung der WCAG-Kriterien nach Themen
- Who can use | Website zur Prüfung von Farbkombinationen hinsichtlich Kontrast inkl. Simulation der Wahrnehmung von Nutzenden mit optischen Einschränkungen (z.B. Rot-Grün- oder Blau-Gelb-Schwäche) und situationsbezogener Ereignisse (z.B. direktes Sonnenlicht)
Fazit: Barrierefreiheit braucht den menschlichen Blick
Barrierefreiheit bedeutet weit mehr als das Bestehen automatisierter Tests. Sie betrifft uns alle – sei es durch eine Sehschwäche, eine temporäre Verletzung oder altersbedingte Einschränkungen.
Manuelles Testen bleibt unverzichtbar, um digitale Angebote wirklich für alle zugänglich zu machen. Denn Barrierefreiheit ist keine rein technische Herausforderung, sondern ein Zeichen gelebter Inklusion.
Falls du noch andere Barriere-Beispiele oder coole Tools kennst, schreib diese gern in die Kommentare!
