Die 10 häufigsten Fehler, die KI bei der Webentwicklung macht

Philip Walton

Veröffentlicht: 11. November 2026

Diese Woche haben wir Version 1.0 von Modern Web Guidance veröffentlicht. Dabei handelt es sich um eine Reihe von Skills, mit denen Webplattform-Fachwissen, Best Practices und Daten zur Browserkompatibilität direkt in Ihre Coding-Agents eingebunden werden. Unser Ziel mit Modern Web Guidance ist es, Entwicklern, die KI-Codierungs-Agents verwenden, dabei zu helfen, die Leistungsfähigkeit und Funktionen der modernen Webplattform voll auszuschöpfen und letztendlich die Webnutzung für Nutzer zu verbessern.

Seit wir im Mai die frühe Vorabversion von Modern Web Guidance vorgestellt haben, sind die KI-Agenten für die Programmierung immer besser geworden und es wurden viele beeindruckende neue Frontier-Modelle veröffentlicht. Eine der am häufigsten gestellten Fragen lautet: Folgen diese neuen Frontier-Modelle nicht bereits den Best Practices für die Webentwicklung?

Leider lautet die Antwort „Nein“. Das wissen wir, weil wir es getestet haben.

In jedem Leitfaden von Modern Web Guidance wird eine Reihe von Erwartungen definiert, die erfüllt sein müssen, wenn die Best Practices im Leitfaden ordnungsgemäß befolgt wurden. Unsere Evaluierungssuite testet diese Leitfäden dann, indem sie denselben Prompt an einen Agenten mit installierter Modern Web Guidance (der geführte Agent) und einen anderen Agenten ohne installierte Modern Web Guidance (der ungeführte Agent) sendet. Die Ausgabe beider Ausführungen wird mit den im Leitfaden definierten Erwartungen abgeglichen.

Wenn Sie die Erfolgsquoten mit und ohne Anleitung vergleichen, sehen Sie, dass KI-Modelle – selbst die neuesten Frontier-Modelle – die Best Practices für die moderne Webentwicklung nicht zuverlässig von selbst befolgen.

Im Durchschnitt bestehen KI-Agenten für die Programmierung ohne Anleitung nur etwa 50 % der Prüfungen in unserer Bewertungssuite, während es mit Modern Web Guidance etwa 90 % sind.

In unserem Bewertungs-Dashboard finden Sie eine vollständige Liste der spezifischen Prüfungen, die wir für jeden Leitfaden durchführen, und die Ergebnisse der einzelnen Modelle.

In diesem Beitrag werden zehn der problematischsten Bereiche behandelt, in denen KI-Modelle immer wieder Fehler machen. Dabei geht es um wichtige Disziplinen, mit denen Webentwickler in ihrer täglichen Arbeit am wahrscheinlichsten zu tun haben, z. B. Barrierefreiheit, Nutzerfreundlichkeit, Leistung und Sicherheit.

1. Bedienungshilfen: Tastaturfokus und inert-Verwaltung

Für Nutzer, die mit einer Tastatur oder einem Screenreader navigieren, ist eine vorhersehbare Fokusreihenfolge entscheidend, um interaktive Benutzeroberflächen nutzbar zu machen. Ohne diese Funktion kann der Fokus auf ausgeblendete Hintergrundinhalte wandern oder in Dutzenden von zusätzlichen Tabstopps hängen bleiben.

Fokus- und inert-Management ist eine der größten Lücken bei der Barrierefreiheit in unseren Bewertungen und einer der Bereiche, die sich mit Modern Web Guidance am meisten verbessern. Zu den häufigsten Fehlern gehören:

• Der Fokus wird nicht auf neu geöffnete Ansichten verschoben und beim Zurückgehen wird vergessen, den Fokus wieder auf das auslösende Element zu legen.
• Verwendung von manuellen JavaScript-Tab-Traps und aria-modal="true" für benutzerdefinierte Modale, anstatt ein modales <dialog> zu verwenden oder Hintergrundinhalte mit inert zu markieren.
• Jedes Element in einer Symbolleiste oder einem Richtungsgitter als separaten Tabstopp verfügbar machen, anstatt einen einzelnen Tabstopp mit roving tabindex zu verwenden.
• Erstellen von benutzerdefinierten :focus-visible-Umrissen, die kein Kontrastverhältnis von 3:1 zu angrenzenden Hintergründen haben.

2. Bedienungshilfen: Unterstützung für reduzierte Bewegung

Unerwartete Seitenbewegungen und großflächige Animationen sind nicht nur ablenkend, sondern können bei Nutzern mit vestibulären Störungen oder Bewegungsempfindlichkeit auch Schwindel, Übelkeit oder Kopfschmerzen auslösen.

KI-Modelle prüfen in der Regel, ob prefers-reduced-motion vorhanden ist, wenn sie Standard-CSS-Übergänge oder Keyframe-Animationen hinzufügen. Bei der Verwendung neuerer Funktionen wie optimiertem Scrollen, Ansichtsübergängen oder scrollgesteuerten Animationen wird die reduzierte Bewegung jedoch oft vergessen oder bei der Implementierung werden Fehler gemacht:

• scroll-behavior:smooth wird global und bedingungslos für das Stammelement festgelegt.
• Scrollgesteuerte CSS-Animationen werden ohne Prüfung auf reduzierte Bewegung verwendet.
• Entfernen der transition-Dauer für Karussellelemente, um die Bewegung beim Scrollen zu reduzieren, aber dann vergessen, auch die Transformationsattribute zu entfernen, was dazu führt, dass die Elemente beim Scrollen in der Größe springen.
• Anwendung einer pauschalen Dauer von 0.01ms für *, *::before und *::after, wenn die Einstellung „Weniger Bewegung“ aktiv ist. Dadurch werden auch alle wichtigen Übergänge ohne Bewegung gelöscht, die für die Kommunikation von Änderungen des UI-Status erforderlich sind.
• Dokumentübergreifende Ansichtsübergänge werden bedingungslos aktiviert und ::view-transition-*-Animationen werden überschrieben, wenn die reduzierte Bewegung aktiv ist, anstatt die @view-transition-Regel nur hinter einer Prüfung auf reduzierte Bewegung zu verbergen.

3. Barrierefreiheit: Formularvalidierung, Formathinweise und Status für automatisches Ausfüllen

Formulare sind ein Eckpfeiler der meisten Critical User Journeys im Web. Ein kleiner Fehler in einem Bezahlformular kann erhebliche Auswirkungen auf das Geschäftsergebnis eines Unternehmens haben.

Beim Erstellen von Formularen machen KI-Modelle viele der Grundlagen richtig. Sie scheitern jedoch oft an kleinen, aber wichtigen Details wie Validierungsfehlern, der richtigen Platzierung von Platzhaltern und Formathinweisen sowie der korrekten Integration in Passwortmanager und Autofill-Funktionen:

• Erneute Implementierung von CSS-:user-invalid mit benutzerdefinierter JavaScript-blur-Validierung, bei der oft unberührte required-Felder gekennzeichnet werden, sobald Nutzer sie mit der Tabulatortaste überspringen.
• aria-invalid wird nicht mehr mit sichtbaren Fehlern synchronisiert, entweder weil aria-invalid="true" vorzeitig auf blur gesetzt wird oder weil :user-invalid in CSS formatiert wird, ohne aria-invalid in JavaScript zu synchronisieren.
• Sich auf verschwindenden placeholder-Text verlassen, um erforderliche Formate anzuzeigen (z. B. MM/YY bei der Eingabe des Ablaufdatums einer Karte), anstatt einen dauerhaften Hinweis zu rendern, der mit aria-describedby verknüpft ist.
• Formatierungshinweise und Passwortregeln unter dem <input> (statt darüber) platzieren, wo sie durch mobile Tastaturen und Autofill-Popovers verdeckt werden können, wenn der Nutzer sie lesen muss.
• :autofill-Eingaben werden nur durch Ändern der Rahmenfarbe hervorgehoben, anstatt die Farbe mit einem nicht farblichen Hinweis zu kombinieren, der das Layout nicht verändert (z. B. ein eingefügtes box-shadow).

4. Nutzererfahrung: Wisch- und Touch-Gesten

KI-Agenten sind gut darin, Touch-Gesten mit imperativem JavaScript zu implementieren und ihre eigene benutzerdefinierte Physiklogik zu schreiben. Diese Implementierungen funktionieren, aber die JavaScript-basierten Touch-Interaktionen fühlen sich selten so flüssig an, wie es Nutzer von systemeigenen Apps gewohnt sind.

Viele dieser Interaktionen können mit CSS und nativen Scroll-APIs implementiert werden, sodass der Browser die Gestenphysik außerhalb des Hauptthreads ausführen kann. In unseren Bewertungen übersehen KI-Modelle diese Funktionen jedoch oft:

• Implementierung von Wischgesten zum Schließen oder Einblenden mit pointermove- oder touchmove-Listenern anstelle von CSS Scroll Snap.
• Weglassen von overscroll-behavior-x:none auf Oberflächen, auf denen durch Wischen zwischen Tabs gewechselt werden kann. Dadurch kann beim Wischen versehentlich eine Vor- oder Zurück-Navigation im Browser ausgelöst werden.
• Effekte für den Wischfortschritt im Hauptthread in JavaScript-Callbacks anstelle von scrollgesteuerten Animationen ausführen.
• Der Tastaturfokus auf scrollbasierten Wischaktionsbereichen wird nicht richtig unterstützt.

5. Nutzererfahrung: Dialogfelder, Pop-over und Übergänge auf der obersten Ebene

In unseren Bewertungen greifen Modelle beim Animieren, Schließen oder Einschränken des Scrollens um modale Dialogfelder und Pop-over häufig auf imperative JavaScript-Workarounds zurück.

Anstatt sich auf moderne HTML- und CSS-Funktionen zu verlassen, die für Overlays auf der obersten Ebene entwickelt wurden, erstellen Agenten häufig eigene Zustandsmaschinen für den Ein- und Ausstieg, History-Hooks und Scroll-Sperren für den Body, die schwieriger zu warten und anfällig für subtile UI-Fehler sind.

Wenn Sie diese Interaktionen richtig gestalten, kann sich eine instabil wirkende Oberfläche in eine ausgereifte Oberfläche verwandeln, der die Nutzer vertrauen. Dies sind die häufigsten Fehler, die wir sehen:

• Benutzerdefinierte position:fixed-Overlays mit manuellen Click-Outside-Handlern für das Schließen durch Klicken außerhalb des Overlays erstellen, anstatt einfach popover zu verwenden.
• Erstellen von Ein- und Ausstiegsanimationen durch Umschalten von CSS-Übergangsklassen und Koordinieren mit requestAnimationFrame()- und transitionend-Listenern (mit setTimeout()-Fallbacks), anstatt dies in reinem CSS mit @starting-style und transition-behavior zu tun.
• Das Scrollen auf der Seite hinter einem geöffneten modalen Fenster wird gesperrt, indem overflow:hidden für <html> festgelegt wird, anstatt ein <dialog>-Element zu verwenden, um Overscroll zu verhindern.
• popstate-Listener werden hinzugefügt, um Android-Zurück-Gesten zu erkennen und geöffnete Modale zu schließen, anstatt die native Schließen-Funktion des Zurück-Buttons eines modalen <dialog>-Elements zu verwenden.

6. Nutzerfreundlichkeit: Dunkler Modus und an das Design angepasste Steuerelemente

Nutzer aktivieren den dunklen Modus, um die Augen zu schonen und Blendeffekte zu reduzieren. Ein helles weißes Aufblitzen beim Seitenaufbau, Formularsteuerelemente ohne Design oder ein Schalter, der nicht mit den Betriebssystemeinstellungen synchronisiert ist, beeinträchtigen die Nutzerfreundlichkeit sofort.

Ein Schalter für den dunklen Modus mag einfach erscheinen, aber Modelle ohne Anleitung übersehen in unseren Bewertungen immer wieder wichtige Plattformdetails, die für das richtige Umschalten des Designs und die nativen Formularsteuerelemente erforderlich sind:

• In der <head> fehlt <meta name="color-scheme" content="light dark">. Dadurch sehen Nutzer im dunklen Modus einen weißen Canvas-Blitz, während externe Stylesheets geladen werden.
• Dunkle Designs oder Komponenten mit dunkler Oberfläche mit benutzerdefinierten Farben gestalten, ohne color-scheme festzulegen, sodass native Scrollleisten und Formularsteuerelemente im hellen Modus bleiben.
• Die CSS-Funktion light-dark() wird beim Definieren von Farbtokens, die sich automatisch an das aktive color-scheme anpassen, nicht berücksichtigt.
• Nur ein binärer Schalter für hell oder dunkel, der eine explizite Überschreibung in localStorage festlegt, ohne die Möglichkeit, zur Standardeinstellung des Betriebssystems zurückzukehren.
• Vergessen, einen storage-Ereignis-Listener hinzuzufügen, sodass andere geöffnete Tabs nicht synchronisiert werden, wenn der Nutzer das Design ändert.

7. Leistung: Reaktionsschnelligkeit und flüssige Wiedergabe während der Laufzeit

Nutzer verbringen die meiste Zeit auf einer Webseite, nachdem sie vollständig geladen wurde. Träge Interaktionen und ruckelige Übergänge können die Nutzerfreundlichkeit also genauso beeinträchtigen wie ein langsames anfängliches Laden.

In unseren Bewertungen folgen die Modelle im Allgemeinen den klassischen Best Practices für die Ladezeit, die seit Jahren in Tools wie Lighthouse empfohlen werden. Außerdem wissen sie in der Regel, dass offensichtlich rechenintensive Schleifen an einen Web Worker ausgelagert werden sollten. Wo sie jedoch immer wieder Probleme haben, ist die Reaktionsfähigkeit des Hauptthreads, die für die Optimierung des INP unerlässlich ist: Isolieren von Layoutarbeiten, Planen von Aufgaben nach Priorität und Nutzen neuer HTML- und CSS-Funktionen, die Renderingarbeiten außerhalb des Hauptthreads ausführen.

Wir sehen zum Beispiel häufig, dass Agenten:

• Benutzerdefinierte setTimeout()-Warteschlangen für Hintergrund- oder Aufgaben mit niedriger Priorität werden verwendet, anstatt Aufgaben, die für den Nutzer sichtbar sind, mit scheduler.postTask() zu priorisieren oder die Fortsetzung von Aufgaben mit scheduler.yield() zu nutzen, wenn der Browser dies unterstützt.
• Komplexe Layouts (z. B. dichte Datenraster) werden ohne content-visibility:auto und contain-intrinsic-size erstellt. Das bedeutet, dass Aktualisierungen nach Nutzerinteraktionen einen Reflow der gesamten Seite auslösen.
• Inaktive SPA-Ansichten mit display:none ausblenden (oder entfernen), anstatt content-visibility:hidden (in Kombination mit inert) zu verwenden. Ersteres zerstört den im Cache gespeicherten Rendering-Status, sodass beim Zurückwechseln das gesamte Layout und die Darstellung neu geladen werden.
• Pausieren von <canvas>-Animationen und Hintergrundschleifen außerhalb des Bildschirms mit Intersection Observer-Callbacks, anstatt content-visibility:auto mit dem contentvisibilityautostatechange-Ereignis (falls verfügbar) zu koppeln, wodurch der Pre-Rendering-Bereich des Browsers verpasst wird, bevor Elemente in die Ansicht gescrollt werden.
• Erstellen von UI-Hinweisen zur Scroll-Affordanz mithilfe von scroll-Ereignis-Listenern, die kontinuierliche Layoutberechnungen erzwingen, anstatt CSS-Scroll-Statusabfragen zu verwenden, sofern verfügbar (mit Intersection Observer-Fallbacks).

8. Leistung: Layoutverschiebungen und visuelles Flackern

Unerwartete Layoutverschiebungen unterbrechen die Konzentration des Lesers und können dazu führen, dass Nutzer auf unerwartete Schaltflächen klicken – manchmal mit unumkehrbaren Folgen.

Die Modelle fügen Standard-<img>-Elementen zuverlässig die Attribute width und height hinzu, um Layoutverschiebungen zu vermeiden. Sie übersehen jedoch regelmäßig andere häufige Ursachen für Layoutverschiebungen und Pre-Paint-Flashes, die durch <video>-Elemente, Webfont-Wechsel, Symbolleisten in mobilen Browsern und clientseitige Tests verursacht werden. All diese Faktoren können sich auf den CLS auswirken.

• Explizite width- und height-Attribute für <video>-Elemente werden weggelassen, sodass nicht geladene Player standardmäßig 300×150 verwenden und das Layout verschieben, sobald Metadaten geladen werden. Alternativ werden Media-Wrapper-Elemente formatiert, anstatt aspect-ratio und object-fit direkt für Media-Elemente festzulegen.
• Webschriftarten werden mit System-Fallback-Schriftarten ohne font-size-adjust gekoppelt, was dazu führt, dass Absätze und Überschriften sichtbar neu formatiert werden, wenn Webschriftarten ausgetauscht werden.
• Hero-Bereiche und Vollbildlayouts werden mit statischen vh-Einheiten anstelle von dynamischen oder kleinen Darstellungsbereichseinheiten (dvh, svh) dimensioniert, was dazu führt, dass Inhalte springen, wenn die Symbolleisten des mobilen Browsers maximiert und minimiert werden.
• Inhalte werden mit alten opacity:0- oder visibility:hidden-Snippets gegen Seitenflackern und mehrsekündigen Zeitlimits für clientseitige A/B-Tests ausgeblendet. Dadurch wird der LCP verzögert und unsichtbare Elemente bleiben anklickbar. Stattdessen sollten Skripts mit blocking="render" verwendet werden, sofern verfügbar.
• Dokumentübergreifende Ansichtsübergänge werden ausgelöst, bevor das kritische Markup für den sichtbaren Bereich geparst wurde, anstatt das erste Rendering mit rel="expect" und blocking="render" zu verzögern. Dadurch werden halb geparste Elemente mitten im Übergang eingeblendet.

9. Sicherheit: DOM-XSS-Abwehr und HTML-Bereinigung

Eine einzige Cross-Site-Scripting-Schwachstelle (XSS) reicht aus, damit ein Angreifer beliebigen Code in den Browsern Ihrer Nutzer ausführen, Sitzungsdaten stehlen oder Aktionen im Namen der Nutzer ausführen kann. Deshalb sind vom Browser erzwungene Schutzmaßnahmen wie sichere HTML-Bereinigung, Trusted Types und strenge CSPs so wichtig.

Modelle gehen diese Sicherheitsbedenken selten proaktiv an. Beispielsweise haben die Modelle bei allen Aufgaben in unserer vollständigen Bewertungssuite ohne explizite Aufforderung keine Content Security Policy (CSP) oder Cross-Origin-Isolation-Header hinzugefügt.

Selbst wenn Prompts direkt nach Sicherheit fragen, scheitern ungeleitete Modelle weiterhin bei mehr als der Hälfte unserer Sicherheitsprüfungen und greifen auf anfällige benutzerdefinierte Fallbacks oder unvollständige Richtlinien zurück. Das wird bei der Abwehr von DOM-XSS deutlich:

• Selbst erstellte DOMParser-Zulassungslisten-Sanitizer schreiben – entweder als setHTML()-Fallback oder innerhalb einer Trusted Types-Richtlinie –, anstatt eine geprüfte Bibliothek wie DOMPurify zu verwenden, wenn keine native Bereinigung verfügbar ist.
• DOMPurify wird bei jedem Seitenaufbau sofort gebündelt, anstatt das native setHTML() zu verwenden, wenn es unterstützt wird, und DOMPurify nur als Fallback per Lazy Loading zu laden.
• Registrierung von permissiven (input) => input-Passthrough-Richtlinien für vertrauenswürdige Typen, die die Erzwingung von Senken untergraben.
• Kopplung von Trusted Types auf statischen Seiten mit Host-Zulassungslisten-script-src 'self'-CSPs, anstatt Inline-Skripts mit SHA-256-Hashes zu sperren.
• 'strict-dynamic' und 'report-sample' werden beim Konfigurieren von Nonce-basierten script-src-Content Security Policies weggelassen.

10. Sicherheit: Anmeldung mit Passkey, erneute Authentifizierung und Lebenszyklus von Anmeldedaten

Passkeys verbessern die Sicherheit für Nutzer und die Anmelde-Conversions für Unternehmen, aber die Implementierung (auch mit Hilfe von KI-Agenten) ist eine Herausforderung.

WebAuthn hat spezifische APIs für Serialisierung, Funktionserkennung und Signalisierung, die von ungeleiteten Modellen in unseren Bewertungen fast vollständig ignoriert werden. Wenn Sie ein KI-Modell bitten, die Anmeldung mit Passkeys, die Verwaltung oder die erneute Authentifizierung hinzuzufügen, schreibt es oft manuelle Byte-Codierungs-Hilfsprogramme, überspringt Funktionsprüfungen in der Verwaltungsoberfläche oder lässt Anmeldedaten nicht mit Passwortmanagern synchronisieren:

• Manuelles Erstellen von Base64URL-Konvertierungs-Hilfsprogrammen für atob() und btoa() – entweder als primärer Pfad oder als redundanter Fallback-Boilerplate – anstatt sich auf integrierte Serialisierungsmethoden wie parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() und credential.toJSON() zu verlassen.
• PublicKeyCredential.signalUnknownCredential() wird bei der Anmeldung weggelassen, wenn der Server eine unbekannte Anmeldedaten-ID meldet. Gelöschte oder widerrufene Passkeys bleiben in den Passwortmanagern der Nutzer erhalten.
• PublicKeyCredential.getClientCapabilities() wird übersprungen, bevor die Benutzeroberfläche zum Erstellen und Verwalten von Passkeys gerendert wird.
• Weglassen von AbortController und AbortSignal beim Starten von Anfragen zur erneuten Passkey-Authentifizierung mit Step-up.
• Übergabe der Ursprungstest-Option mediation:"immediate" anstelle von uiMode:"immediate" für optimierte Aufforderungen zur Anmeldung.

Diese Lücken schließen

Diese zehn Bereiche sind bei Weitem nicht vollständig und wir gehen davon aus, dass sich die spezifischen Wissenslücken im Laufe der Zeit ändern werden. Die Modelle werden aufholen und die Webplattform wird sich weiterentwickeln.

Die gute Nachricht ist, dass Modern Web Guidance all diese Lücken schließt und sich zusammen mit der Plattform weiterentwickelt.

Führen Sie den folgenden Befehl aus, um mit Modern Web Guidance zu beginnen, oder suchen Sie im Plug-in-Marktplatz Ihres KI-Agenten danach:

npx modern-web-guidance@latest install

Haben Sie gesehen, dass Modelle andere Webentwicklungsaufgaben falsch ausgeführt haben? Darüber möchten wir unbedingt informiert werden. Erstellen Sie ein Issue im GitHub-Repository für Modern Web Guidance oder helfen Sie uns, diese Lücken für andere Entwickler zu schließen, indem Sie einen Beitrag zum Projekt leisten.