Warum menschliches Urteil im Frontend trotz Automatisierung und KI unverzichtbar bleibt

Zusammenfassung

Künstliche Intelligenz und automatisierte Tools können Frontend-Entwickler:innen besonders im Bereich Barrierefreiheit sinnvoll unterstützen. Sie erkennen häufig technische Probleme wie fehlende Labels, schlechte Farbkontraste oder fehlerhafte HTML-Strukturen schnell und zuverlässig.

Trotzdem reicht das allein nicht aus. Gute Accessibility bedeutet nicht nur, Regeln zu erfüllen, sondern digitale Produkte tatsächlich verständlich, nutzbar und nachvollziehbar zu gestalten. Viele Probleme entstehen erst im Nutzungskontext – zum Beispiel bei unklarer Navigation, fehlender Orientierung oder verwirrenden Abläufen. Solche Aspekte lassen sich nur schwer automatisiert bewerten.

Auch KI stößt hier an Grenzen. Sie kann Muster erkennen und Vorschläge machen, versteht jedoch keine reale Nutzungssituation und hinterfragt Annahmen nicht von selbst. Dadurch wirken Antworten oft plausibel, ohne immer die beste Lösung zu sein.

Der Artikel zeigt deshalb: KI ist ein hilfreiches Werkzeug, ersetzt aber nicht menschliche Urteilskraft. Gute Frontend-Entwicklung entsteht dort, wo Technik, Design, Nutzerbedürfnisse und kritisches Denken zusammenkommen.

Während immer mehr Stimmen behaupten, dass KI mit Leichtigkeit die Arbeit von Frontend-Entwickler:innen übernehmen könne, wird ein entscheidender Teil oft übersehen: die Komplexität realer Probleme und die Vielzahl an Entscheidungen, die im Entwicklungsprozess getroffen werden müssen. Besonders deutlich wird das im Bereich der Barrierefreiheit.

Accessibility ist mehr als das Erfüllen technischer Kriterien. Sie entsteht im Zusammenspiel von Verständnis, Kontext und Abwägung. Genau hier zeigt sich: Auch wenn KI viele Prozesse unterstützt und zusätzliche Zusammenhänge sichtbar machen kann, stößt sie regelmäßig an Grenzen.

In diesem Beitrag werfe ich einen Blick auf ein Barrierefreiheits-Audit einer Website, die zuvor bereits automatisiert getestet wurde – und zeige, welche Probleme erkannt wurden, welche nicht, und warum die vorgeschlagenen Lösungen oft nicht ausreichen.

Automatisierte Tests sind ein guter Anfang

Automatisierte Tools wie Lighthouse oder axe sind aus der modernen Entwicklung nicht mehr wegzudenken. Sie liefern schnell Ergebnisse, decken offensichtliche Probleme im Code auf und helfen dabei, grundlegende Standards einzuhalten.

Dabei lohnt sich jedoch eine Unterscheidung zwischen Prüf-Engines und Tools. Accessibility-Engines wie axe-core, QualWeb oder der IBM Equal Access Accessibility Checker übernehmen die eigentliche Analyse anhand definierter Regeln. Bekannte Tools wie Lighthouse, Browser-Erweiterungen, CI-Scanner oder Test-Integrationen wie axe-playwright bauen häufig auf solchen Engines auf und ergänzen sie um eigene Oberflächen, Reports oder zusätzliche Prüfungen.

Typischerweise erkennen sie:

• unzureichende Farbkontraste
• fehlende Alternativtexte
• fehlerhafte semantische Strukturen
• nicht korrekt verknüpfte Labels

Dabei wird jedoch schnell deutlich: Diese Tools arbeiten auf Basis klar definierter Regeln, die entweder erfüllt werden oder nicht – eine systemische Grenze. Sie können nur das prüfen, was sich eindeutig in Regeln und Algorithmen übersetzen lässt.

Qualität und Kontext bleiben dabei weitgehend unberücksichtigt. Ob ein Alternativtext tatsächlich sinnvoll ist oder nur formal existiert, lässt sich so beispielsweise nicht zuverlässig bewerten.

Automatisierte Tests sind damit ein wichtiger Einstieg – aber keine verlässliche Aussage über die tatsächliche Nutzbarkeit.

KI als Unterstützung – aber kein Ersatz

Um Kontext stärker einzubeziehen, kann künstliche Intelligenz unterstützen. Sie ist in der Lage, Muster zu erkennen und Inhalte in Relation zu setzen – etwa wenn Bildinhalte mit vorhandenen Alternativtexten abgeglichen werden.

Das kann zusätzliche Hinweise liefern und offensichtliche Diskrepanzen sichtbar machen.

Gleichzeitig bleibt diese Bewertung zwangsläufig begrenzt. KI kann Plausibilität einschätzen, aber keine reale Nutzungssituation nachvollziehen. Ob ein Alternativtext im konkreten Kontext die richtige Information vermittelt, lässt sich nicht zuverlässig ableiten.

Der Kontext, den KI einbeziehen kann, ist auf das beschränkt, was direkt verfügbar ist: Code, Struktur und visuelle Darstellung. Reale Nutzungssituationen, individuelle Bedürfnisse oder Erwartungen von Nutzer:innen bleiben außen vor.

Auch in meinem Fall wurde die Website vorab geprüft – mit einem insgesamt soliden Ergebnis. Auf den ersten Blick wirkte sie zugänglich.

Doch genau hier zeigt sich die Grenze dieser Bewertung: Der Eindruck von Zugänglichkeit hielt dem manuellen Audit nicht stand.

Die Lücke: Was KI nicht versteht

Kontext ist nicht gleich Code

Ein zentrales Problem lag in der Nutzung von vermeintlich dekorativen Bildern und Icons. Technisch gesehen waren Icons in Listen korrekt ausgezeichnet – sie waren mit aria-hidden versehen und somit für Screenreader ausgeblendet.

Formal ist das korrekt.

In der konkreten Umsetzung erfüllten diese Icons jedoch eine visuelle Funktion: Sie strukturierten Inhalte und wirkten für sehende Nutzer:innen wie eine Art Überschrift oder Orientierungspunkt. Diese Information wurde an keiner anderen Stelle vermittelt – und ging für Screenreader-Nutzer:innen damit vollständig verloren.

Hier zeigt sich ein grundlegendes Problem: Visuelle Struktur ist nicht automatisch semantische Struktur. Entscheidend ist nicht, ob ein Element technisch korrekt verborgen ist, sondern ob seine Bedeutung an anderer Stelle zugänglich gemacht wird.

Isoliert betrachtet ist ein aria-hidden-Icon unproblematisch. Im Nutzungskontext kann es jedoch dazu führen, dass Inhalte unterschiedlich wahrgenommen werden – je nachdem, wie sie konsumiert werden.

Automatisierte Tests und KI erkennen hier keinen Fehler – nicht, weil sie ungenau arbeiten, sondern weil die eigentliche Problematik außerhalb dessen liegt, was sich rein technisch prüfen lässt.

Accessibility ist damit weniger eine Frage der reinen Struktur sondern eher der vermittelten Information.

Nutzerführung lässt sich nicht messen

Ein weiterer Bereich, in dem automatisierte Tests an ihre Grenzen stoßen, ist die Nutzerführung.

In der untersuchten Anwendung war die Fokus-Reihenfolge technisch korrekt umgesetzt. Alle interaktiven Elemente waren erreichbar, es gab keine „Dead ends“.

Und dennoch war die Navigation nicht intuitiv. Scrollverhalten wurde durch das Springen des Fokus negativ beeinflusst, visuelle und interaktive Führung griffen nicht ineinander. Inhalte ließen sich zwar erreichen, aber nicht sinnvoll erschließen.

Für Nutzer:innen, die auf Tastaturnavigation angewiesen sind, entstand kein klarer, nachvollziehbarer Ablauf.

Accessibility misst nicht nur, ob etwas erreichbar ist – sondern auch, ob es sinnvoll bedienbar ist.

Solche Probleme lassen sich kaum automatisiert bewerten. Vor allem fehlt die Einordnung: Wann ist etwas formal korrekt – und wann tatsächlich nutzbar?

Diese Unterscheidung basiert nicht auf festen Regeln, sondern auf Erwartungen, Gewohnheiten und mentalen Modellen.

Ein oft übersehener Faktor: KI widerspricht nicht

Neben den technischen Grenzen gibt es noch einen subtileren, aber entscheidenden Aspekt: KI ist darauf ausgelegt, plausible und hilfreiche Antworten zu liefern – nicht darauf, Annahmen aktiv zu hinterfragen.

Wenn wir KI-Tools in der Entwicklung verwenden, formulieren wir unsere Fragen oft bereits mit einer bestimmten Erwartung oder Hypothese. Diese fließt direkt in die Antwort mit ein.

Das führt zu einem Effekt, der dem Confirmation Bias ähnelt: Bestehende Annahmen werden eher gestützt als systematisch überprüft.

Wer KI mit einer Vermutung füttert, erhält oft keine Gegenposition – sondern eine  Bestätigung.

Auch mit ausführlichen Prompts lässt sich dieses Verhalten nur begrenzt ausgleichen. Im Gegenteil: Je mehr Kontext wir vorgeben, desto stärker beeinflussen wir, welche Aspekte berücksichtigt werden – und welche nicht.

Das kann dazu führen, dass:

• bestehende Fehlannahmen stabilisiert werden
• suboptimale Lösungen überzeugend wirken
• alternative Perspektiven gar nicht erst berücksichtigt werden

Gerade im Accessibility-Kontext ist das kritisch. Viele Probleme sind nicht offensichtlich – und oft liegt die eigentliche Herausforderung genau dort, wo die erste Einschätzung zu kurz greift.

Ein menschliches Audit bringt hier etwas Entscheidendes mit: die Bereitschaft zum Widerspruch.

Es stellt Fragen wie:

• Ist das wirklich verständlich – oder nur formal korrekt?
• Wird das Problem tatsächlich gelöst – oder nur verschoben?
• Würde ich diese Lösung selbst als Nutzer:in nachvollziehen können?

Diese Form von kritischer Einordnung ist kein Zusatz, sondern zentraler Bestandteil guter Accessibility-Arbeit.

 

KI vs. Realität: Wenn Lösungen nicht ausreichen

Neben der Problemerkennung ist auch die Qualität der vorgeschlagenen Lösungen entscheidend.

In mehreren Fällen wurden durch KI-gestützte Ansätze oder automatisierte Tools Lösungsvorschläge generiert, die auf den ersten Blick sinnvoll wirkten – bei genauerem Hinsehen jedoch zu kurz griffen oder neue Probleme mit sich brachten.

Ein wiederkehrendes Muster: Es werden lokale Probleme optimiert, während die eigentliche Herausforderung auf Systemebene liegt.

Einige typische Beispiele:

• Vorschlag: Korrektur von Farbkontrasten
  Tatsächliche Lösung: Überarbeitung des Designsystems
  Problem: Einzelne Anpassungen hätten zu Inkonsistenzen geführt
• Vorschlag: Semantische Korrekturen im HTML
  Tatsächliche Lösung: Umstrukturierung der Inhalte
  Problem: Die eigentliche Herausforderung lag in der Informationsarchitektur, nicht im Markup

Diese Beispiele zeigen: Die „richtige“ Lösung entsteht selten isoliert im Code. Sie bewegt sich im Spannungsfeld von Design, Technik und Nutzungskontext.

Wichtig ist dabei auch die Gegenperspektive: Das gilt nicht nur für KI.

Auch manuelle Audits, externe Reviews oder erfahrene Entwickler:innen können Empfehlungen aussprechen, die im konkreten Produktkontext nicht tragfähig sind, unnötige Komplexität erzeugen oder an Prioritäten vorbeigehen.

Ein Audit ist deshalb kein Maßnahmenkatalog, der blind umgesetzt werden sollte – sondern eine fundierte Grundlage für Entscheidungen.

Gerade im Accessibility-Bereich braucht es Einordnung:

• Welche Empfehlung verbessert reale Nutzbarkeit?
• Welche erzeugt nur formale Compliance?
• Welche verschiebt Probleme an anderer Stelle?
• Welche Lösung ist langfristig wartbar?

Gute Accessibility-Arbeit entsteht nicht durch das blinde Umsetzen von Empfehlungen – egal ob von KI, Tooling oder Menschen – sondern durch reflektierte Entscheidungen im jeweiligen Kontext.

 

Die unsichtbare Arbeit: Entscheidungen treffen

Was in der Diskussion um KI oft untergeht, ist die Vielzahl an Entscheidungen, die gute Accessibility-Arbeit ausmachen.

Welche Lösung ist langfristig wartbar?
Wie beeinflusst eine Änderung das Designsystem?
Welche Nutzergruppen sind besonders betroffen?
Welche Kompromisse sind tragbar – und für wen?

Diese Fragen lassen sich nicht rein regelbasiert beantworten. Sie erfordern Erfahrung, Kontextwissen und Abstimmung im Team.

Hinzu kommt: Das Web entwickelt sich ständig weiter. Neue Technologien, Patterns und Tools bringen neue Möglichkeiten – aber auch neue Herausforderungen. Viele davon lassen sich erst durch reale Nutzung bewerten.

Accessibility ist kein Zustand, den man erreicht, sondern ein kontinuierlicher Prozess.

Die Rolle der KI: Ein starkes Werkzeug

All das bedeutet nicht, dass KI keinen Platz in der Frontend-Entwicklung hat – im Gegenteil.

Richtig eingesetzt kann sie:

• schnelle Erstanalysen liefern
• bekannte Problemklassen zuverlässig erkennen
• bei der Umsetzung unterstützen
• repetitive Aufgaben vereinfachen

Doch sie bleibt ein Werkzeug.

Sie trifft keine Entscheidungen, übernimmt keine Verantwortung und widerspricht uns nicht von sich aus.

 

Fazit: Warum Frontend menschlich bleibt

Die Vorstellung, dass KI Frontend-Entwickler:innen ersetzt, greift zu kurz – insbesondere im Bereich der Barrierefreiheit.

Denn viele der entscheidenden Probleme entstehen nicht dort, wo Regeln verletzt werden, sondern dort, wo sie eingehalten werden – und trotzdem keine gute Nutzungserfahrung entsteht.

Accessibility ist mehr als das Einhalten von Kriterien. Sie ist das Ergebnis von Kontextverständnis, Abwägung und bewussten Entscheidungen – und oft auch davon, die eigenen Annahmen zu hinterfragen.

Genau hier zeigen sich auch die aktuellen Grenzen vieler Systeme. Benchmarks wie A11y LLM Eval testen inzwischen, wie gut Sprachmodelle standardmäßig zugänglichen HTML-Code erzeugen. Die Ergebnisse zeigen: Bekannte, automatisiert prüfbare Muster lassen sich oft erkennen oder verbessern. Schwieriger wird es jedoch bei Strukturqualität, konsistenter Semantik, Bedienlogik und Fragen realer Nutzbarkeit.

KI kann unterstützen. Aber gerade an den entscheidenden Stellen zeigt sich: Sie ersetzt nicht die Bewertung – sie macht sie sichtbar. Sie übernimmt keine Verantwortung. Sie erlebt keine Frustration in der Nutzung. Und sie hinterfragt Entscheidungen nicht von sich aus.

Darum bleibt Frontend-Arbeit im Kern menschlich: Gute digitale Produkte entstehen nicht allein durch korrekten Code, sondern durch Urteilskraft.

Solange digitale Produkte für Menschen gemacht werden, braucht es Menschen, die sie gestalten, hinterfragen und verbessern.