Das agentenfähige Web und Abschlussprojekt

Das agentenfähige Web

0:00 Das letzte Modul, und es hat zwei Teile. Zuerst ein Ausblick auf eine Entwicklung, die dieses Seminar in einem neuen Licht zeigt: Browser-Agenten lesen dieselbe Struktur wie assistive Technik. Daraus folgt der Leitsatz — wer für Screenreader gut baut, baut zugleich für Maschinen gut lesbar. Das ist ein bemerkenswerter Nebeneffekt, und er gibt der Barrierefreiheit ein zweites, wirtschaftliches Argument.

0:24 Und dann kommt der zweite Teil: das Abschlussprojekt, in dem Sie alles aus drei Tagen zusammenführen. Am Ende steht die Frage, wie es zu Hause weitergeht.

Das agentenfähige Web und Abschlussprojekt

0:34 Sieben Kapitel. Die ersten vier sind Ausblick: die gemeinsame Grundlage von Menschen und Maschinen, was Namen und Stabilität dabei leisten, der aktuelle Stand von Agentic Browsing und WebMCP — und eine Warnung, die Reihenfolge nicht umzudrehen. Dann zwei Kapitel zum Abschlussprojekt: Aufgabe und Ablauf, dann Umsetzung und Ergebnisse.

0:53 Und zum Schluss die praktischste Frage überhaupt: Was ist der erste Schritt, wenn Sie am Montag wieder im eigenen Projekt sitzen? Die Antwort wird einige überraschen — es ist kein Werkzeug.

Zugängliche Semantik als Grundlage für Menschen und Maschinen

1:05 Beginnen wir mit der Beobachtung, die diesem Modul seinen Titel gibt. Browserbasierte Agenten lesen denselben Baum wie assistive Technik — und daraus folgt mehr, als man auf den ersten Blick denkt. Erinnern Sie sich an Modul acht: Der Browser erzeugt aus dem DOM einen zweiten Baum mit Rollen, Namen, Zuständen und Werten.

1:25 Genau diesen Baum lesen jetzt auch browserbasierte Agenten — nicht das Bild, nicht das Markup, sondern die semantische Struktur. Und daraus folgt ein bemerkenswerter Nebeneffekt: Wer für Screenreader gut baut, baut zugleich für Maschinen gut lesbar. Ohne Zusatzaufwand, ohne zweite Umsetzung, ohne neue Technik. Barrierefreiheit bekommt damit ein zweites Argument — eines, das in Häusern zieht, in denen das erste nicht gezogen hat. Sie müssen dafür nichts anders machen.

1:54 Vier Punkte, und der letzte ist mir der wichtigste. Dieselbe Maßnahme bedient zwei Zwecke ohne doppelten Aufwand — das ist selten und sollte man nutzen. Wer Automatisierung will, braucht ohnehin saubere Semantik; das ist ein Argument, das in Gesprächen über Effizienz landet und nicht in der Compliance-Ecke. Die Investition rechnet sich damit auch ohne rechtliche Pflicht. Und dann der vierte Punkt, der eine Haltung festhält: Was zuerst kommt, bleibt trotzdem der Mensch.

2:22 Das Argument ist ein zusätzlicher Hebel, keine neue Begründung — und diesen Unterschied sollte man nicht verwischen. Der erste Stolperstein ist eine Verschiebung, die schleichend passiert: aus dem Nebeneffekt eine Begründung machen und die Menschen verdrängen. Wenn Barrierefreiheit nur noch mit Automatisierbarkeit begründet wird, fällt sie, sobald ein Agent den Fall auch anders löst.

2:44 Der zweite ist die praktische Folge davon: Semantik für Agenten optimieren, ohne sie je mit Screenreader zu prüfen. Und der dritte ist eine Frage des Adressaten: das Argument gegenüber Betroffenen verwenden statt gegenüber der Leitung. Für die Leitung ist es ein hilfreiches Zusatzargument. Für betroffene Menschen ist es zynisch.

Namen, Zustände und Stabilität

3:04 Was braucht ein Agent, um eine Oberfläche zu bedienen? Die Antwort ist die eigentliche Pointe dieses Moduls: nichts, was wir nicht schon in den Modulen neun bis zwölf besprochen haben. Schaltflächen ohne Namen, Zustände ohne Meldung, Bedienelemente ohne Rolle — für einen Agenten sind sie genauso unzugänglich wie für einen Screenreader.

3:24 Er kann nur bedienen, was er benennen kann. Das ist wörtlich dieselbe Anforderung, keine verwandte. Ein Punkt kommt hinzu, und der ist für Sie als Entwicklungsteam ohnehin relevant: Stabilität. Zufällig erzeugte Identifikatoren, springende Layouts und Zustände ohne Rückmeldung erschweren jede Automatisierung — die durch Agenten genauso wie Ihre eigenen End-to-End-Tests.

3:47 Wer stabile Bezeichner vergibt, hilft beiden. Das ist ein Argument, das jedes Team sofort versteht. Diese Tabelle fasst das ganze Kapitel zusammen. Ein zugänglicher Name hilft Screenreader und Sprachsteuerung — und der Agent findet damit das Element. Ein gemeldeter Zustand sagt Menschen die Änderung an — und der Agent erkennt den Erfolg seiner Aktion.

4:09 Interessant ist die dritte Zeile: Stabile Bezeichner helfen Menschen nichts unmittelbar, aber sie halten Tests und Agenten heil. Und ein vorhersehbares Layout bedeutet für Menschen weniger Suchen, für Maschinen weniger Fehlgriffe. Vier Maßnahmen, die Sie ohnehin kennen. Es kommt nichts Neues hinzu — das ist die eigentliche Botschaft.

4:30 Der erste Stolperstein ist eine technische Nebenwirkung moderner Werkzeuge: Bezeichner bei jedem Build neu erzeugen. Ihre eigenen Tests werden dadurch brüchig, und Sie kompensieren mit immer komplizierteren Selektoren. Vergeben Sie stabile Bezeichner, das löst mehrere Probleme gleichzeitig. Der zweite kennen Sie aus Modul neun: Zustände nur visuell ändern und nirgends melden.

4:52 Und der dritte ist eine Verortung, die dem Thema schadet: Stabilität als reines Testthema führen statt als Qualitätsmerkmal. Als Testthema landet es beim Testteam, als Qualitätsmerkmal in der Definition of Done — und dort wirkt es.

Agentic Browsing und WebMCP

5:07 Jetzt der Blick auf den aktuellen Stand — und mit einer ausdrücklichen Kennzeichnung, was etabliert ist und was Ausblick. Diese Unterscheidung ist hier besonders wichtig. Zwei Entwicklungen mit unterschiedlichem Reifegrad. Agenten, die Websites im Browser bedienen, sind 2026 aus dem Experimentierstadium heraus — das findet statt, und Sie können davon ausgehen, dass Ihre Anwendung auch von Agenten bedient wird.

5:32 Der weitergehende Ansatz wäre, dass Anwendungen ihre Fähigkeiten direkt anbieten, statt sie über die Oberfläche nachbedienen zu lassen. WebMCP verfolgt genau das. Und jetzt die Einordnung, die dazugehört: WebMCP ist im August 2026 experimentell, ebenso die zugehörige Prüfkategorie in Lighthouse. Das gehört ausdrücklich gesagt, weil solche Themen in Präsentationen gern reifer wirken, als sie sind.

5:58 Diese Tabelle ist im Grunde eine Handlungsanweisung. Der Accessibility Tree ist etabliert — heute umsetzen, wie in den letzten drei Tagen besprochen. Agentic Browsing ist in Nutzung, das erfordert eine Produktentscheidung: Wollen Sie das unterstützen, einschränken, beobachten? Diese Frage sollte bewusst beantwortet werden.

6:19 WebMCP ist experimentell — beobachten, nicht einplanen. Und die Lighthouse-Kategorie ist vorgeschlagen, also ausdrücklich kein Prüfmaßstab. Wenn Sie eine Sache aus diesem Kapitel mitnehmen, dann diese vier Zeilen. Sie schützen Sie davor, Ausblick und Anforderung zu verwechseln. Der erste Stolperstein ist im Vertrieb verführerisch und im Projekt teuer: experimentelle Ansätze als Planungsgrundlage verkaufen.

6:45 Experimentelles kann sich ändern oder verschwinden. Der zweite ist eine Auslassung mit ähnlicher Wirkung: den Reifegrad in Unterlagen weglassen und damit Erwartungen wecken. Schreiben Sie „experimentell, Stand August 2026" dazu — das ist derselbe Grundsatz wie bei den Normfassungen in Modul sieben. Und der dritte ist ein Zeitproblem: aus dem Ausblick eine Anforderung an das laufende Projekt machen. Ihr laufendes Projekt hat genug mit den etablierten Kriterien zu tun.

Agent Experience als Ergänzung, nicht als Ersatz

7:14 Und jetzt die Warnung, die zu diesem Ausblick gehört. Die Reihenfolge bleibt: Menschen zuerst. Wer sie umdreht, baut Oberflächen, die technisch gut lesbar und für Menschen unbrauchbar sind. Es gibt inzwischen den Begriff Agent Experience, und er ist nicht falsch — Agenten sind Nutzer, und ihre Erfahrung ist gestaltbar. Aber sie ist kein Ersatz für die Erfahrung eines Menschen.

7:37 Wer beginnt, für Maschinen zu optimieren, riskiert etwas Konkretes: Oberflächen, die technisch hervorragend lesbar und für Menschen unbrauchbar sind. Präzise Beschriftungen ohne Erklärung, knappe Fehlermeldungen ohne Hilfe, Abläufe ohne die Zwischenschritte, die Menschen zur Orientierung brauchen. Die Reihenfolge bleibt deshalb: Menschen zuerst, Maschinenlesbarkeit als Folge guter Semantik. Nicht umgekehrt — auch wenn der Nebeneffekt echt ist.

8:04 Vier Warnzeichen, und sie schleichen sich einzeln ein. Beschriftungen werden technischer, weil der Agent sie besser trifft. Erklärende Zwischenschritte fallen weg, weil der Agent sie nicht braucht — Menschen aber schon. Fehlermeldungen werden knapper und damit für Menschen unverständlich; das ist die Umkehrung von Modul elf.

8:22 Und das vierte Zeichen ist das aussagekräftigste, weil es in Diskussionen hörbar wird: Entscheidungen werden mit Automatisierbarkeit begründet statt mit Nutzen. Wenn Sie das im Meeting hören, ist es Zeit für den Kontext-Steckbrief aus Modul zwei — und für die Frage, wer diese Oberfläche eigentlich benutzt. Der erste Stolperstein ist der eben beschriebene: Oberflächen für Agenten vereinfachen und Menschen den Kontext nehmen.

8:47 Der zweite kennen Sie aus Modul eins, in neuem Gewand: zwei Fassungen bauen, eine für Menschen und eine für Maschinen. Sonderwege veralten, Hauptwege werden gepflegt — das war damals schon die Antwort und gilt hier unverändert. Und der dritte ist ein Messfehler mit Folgen: Agentennutzung messen und daraus auf Qualität schließen.

9:06 Eine hohe Agentennutzung kann auch bedeuten, dass Menschen die Oberfläche meiden. Zahlen brauchen eine Interpretation, wie wir in Modul vierzehn gesehen haben.

Abschlussprojekt: Aufgabe und Ablauf

9:16 Damit zum Abschlussprojekt. Sie führen alles aus drei Tagen an einem vollständigen Webprozess zusammen — von der Nutzerfrage bis zur überprüfbaren Definition of Done. Jede Gruppe bearbeitet einen vollständigen Webprozess von Fahrtwind. Zur Wahl stehen Registrierung, Terminbuchung, Suche mit Filtern, Bezahlvorgang, Verwaltungsformular oder ein Dashboard mit Datentabelle — Sie entscheiden selbst.

9:40 Wichtig bei der Wahl ist nur eines: Der Prozess muss Formulare, Zustände und eine Entscheidung enthalten. Sonst trägt er die Aufgabe nicht, weil Ihnen die Hälfte der Prüfpunkte fehlt. Der Ablauf folgt dem Seminar von der Nutzerfrage bis zu den Akzeptanzkriterien. Das ist bewusst so gebaut: Sie gehen den Weg noch einmal, diesmal an einem Stück und in Ihrem Tempo.

10:02 Fünf Schritte, und sie folgen der Norm aus Modul zwei. Nutzer und Nutzungskontext als Steckbrief. Risiken und Barrieren mit betroffener Gruppe — das ist die Verknüpfung, die später die Priorisierung trägt. Task Flow zeichnen und zugängliche Akzeptanzkriterien formulieren, in der Form aus Modul sechzehn. Oberfläche entwerfen, ausdrücklich mit Fokuszuständen und Fehlertexten — den beiden, die im Entwurf immer fehlen.

10:28 Und Schritt fünf ist ein Kniff, den ich sehr empfehle: die Kriterien von einer anderen Gruppe gegenlesen lassen, vor dem Bauen. Eine Lücke im Kriterium wird sonst zur Lücke im Ergebnis. Der erste Stolperstein ist der Reflex, gegen den Modul zwei gebaut ist: mit dem Entwurf beginnen und den Kontext nachträglich begründen.

10:48 Das fühlt sich produktiv an und erzeugt eine Begründung statt einer Grundlage. Der zweite ist eine Weichenstellung am Anfang: einen Prozess wählen, der keine Formulare und keine Zustände hat. Sie können dann die Hälfte des Gelernten nicht anwenden. Und der dritte ist der Kernfehler aus Modul sechzehn: Akzeptanzkriterien erst nach der Umsetzung formulieren. Dann beschreiben sie, was gebaut wurde — und prüfen gar nichts mehr.

Abschlussprojekt: Umsetzung, Prüfung und Ergebnisse

11:13 Die zweite Hälfte: bauen, prüfen, belegen. Und ein Hinweis zur Präsentation am Ende, der die Erwartung geraderückt — vorgestellt werden die Belege, nicht die Bildschirme. Jetzt wird gebaut und geprüft: semantische Webkomponenten implementieren, KI oder einen Coding Agent kontrolliert einsetzen, automatische und manuelle Tests durchführen, Ergebnisse priorisieren und dokumentieren, eine überprüfbare Definition of Done formulieren.

11:40 Ein Hinweis zur Reihenfolge, der die wichtigste Aussage aus Modul zwei wiederholt: Die Prüfung gehört in den Ablauf hinein, nicht ans Ende. Prüfen Sie, sobald die erste Komponente steht — nicht, wenn alles fertig ist. Sonst finden Sie am letzten Tag Grundsatzprobleme, für die keine Zeit mehr ist. Das ist die Iterationsschleife, jetzt in Ihrem eigenen Projekt.

12:01 Diese Tabelle ist zugleich Ihre Abgabeliste und eine Landkarte des Seminars. Acht Artefakte, und die rechte Spalte sagt Ihnen jeweils, aus welchen Modulen sie stammen. Der analysierte User Flow aus Modul zwei und vier. Der Entwurf aus fünf und sechs. Die zugängliche Komponente aus neun bis zwölf. Die Akzeptanzkriterien aus sieben und sechzehn.

12:23 Die Prüfergebnisse aus fünfzehn und sechzehn, die manuelle Prüfliste aus dreizehn und fünfzehn. Der dokumentierte KI-Ablauf aus siebzehn und achtzehn. Und der priorisierte Verbesserungsplan aus vierzehn und sechzehn. Wenn Sie später etwas nachschlagen wollen — hier steht, wo. Der erste Stolperstein ist die Versuchung jeder Abschlusspräsentation: die schönsten Bildschirme vorstellen statt der Belege. Ihre Bildschirme sehen sicher gut aus.

12:51 Interessant für alle anderen ist, was Sie geprüft haben und was Sie gefunden haben. Der zweite ist eine Auslassung: den KI-Ablauf mündlich beschreiben, statt ihn zu dokumentieren. Der Auftrag, der Plan, die Abweichungen — das ist der wertvollste Teil für die anderen Gruppen. Und der dritte ist der Klassiker aus Modul vierzehn: den Verbesserungsplan ohne Priorisierung abgeben. Eine unpriorisierte Liste wird nicht abgearbeitet, sondern abgelegt.

Wie es nach dem Seminar weitergeht

13:18 Das letzte Kapitel ist das praktischste. Am Montag sitzen Sie wieder im eigenen Projekt. Was ist der erste Schritt? Die Antwort überrascht viele: Es ist kein Werkzeug. Der Reflex nach so einem Seminar ist, ein Werkzeug einzuführen. Das ist verständlich — es ist sichtbar, es ist abgeschlossen, man kann es vorzeigen. Und es ist selten der wirksamste erste Schritt.

13:42 Der ist meist eine Vereinbarung: ein Punkt in der Definition of Done, ein Tastaturtest im Review, eine Komponentenspezifikation mit Semantik. Solche Vereinbarungen kosten kein Geld und keine Einführung, sie verändern aber die tägliche Arbeit. Die automatisierten Prüfungen folgen danach — in dieser Reihenfolge. Umgekehrt bekommen Sie ein Tor, das an Regeln misst, auf die sich niemand verständigt hat.

14:07 Fünf Schritte für vier Wochen, und die Fußzeile fasst die Logik zusammen: vier Schritte ohne Werkzeug, einer mit. Erst ein Punkt in die Definition of Done — der Tastaturdurchlauf, der wirksamste manuelle Test aus Modul fünfzehn. Dann die drei meistgenutzten Komponenten nach der Vier-Zeilen-Regel beschreiben; drei, nicht alle. Dann ein Prüfwerkzeug auswählen und überall dasselbe verwenden.

14:31 Dann ein Register für offene Punkte anlegen, mit Auswirkung und Termin. Und erst danach ein Quality Gate — mit Konsequenz. Das ist ein Monat, es kostet praktisch nichts, und es verändert die Ausgangslage grundlegend. Der erste Stolperstein ist der eben besprochene: mit dem Werkzeug beginnen und die Vereinbarung nachholen wollen.

14:51 Die Vereinbarung wird dann nie nachgeholt, weil das Werkzeug ja läuft. Der zweite ist Ehrgeiz mit vorhersehbarem Ausgang: alle Komponenten auf einmal beschreiben wollen. Nach der siebten hört man auf, und die Datei bleibt halbfertig liegen. Drei reichen — die drei, die überall verwendet werden. Und der dritte kennen Sie aus Modul sechzehn: das Tor einführen, bevor der Bestand die Schwelle halten kann. Dann bricht der Bau, und das Tor wird abgeschaltet.

15:18 Vier Punkte. Agenten lesen denselben Baum wie assistive Technik — dieselbe Maßnahme wirkt zweifach, und das ist ein Argument, das Sie im Haus verwenden können. Agentic Browsing ist in Nutzung, WebMCP ist Ausblick; halten Sie das in Unterlagen auseinander. Menschen zuerst, Maschinenlesbarkeit als Folge guter Semantik — nicht umgekehrt.

15:39 Und der praktischste Satz für Montag: Der erste Schritt zu Hause ist eine Vereinbarung, kein Werkzeug. Für das Abschlussprojekt noch einmal der Hinweis aus der Fußzeile: Vorgestellt werden am Ende die Belege, nicht die schönsten Bildschirme.

Drei Tage, ein Prinzip

15:54 Drei Tage, und wenn ich sie auf ein Prinzip eindampfen müsste, dann auf dieses: Barrierefreiheit ist Produktqualität und entsteht beim Bauen, nicht bei der Abnahme. Das war der erste Satz in Modul eins und er trägt alles dazwischen. Dazu drei Sätze für den Alltag. Was per Tastatur geht, geht meist auch per Schalter, Sprache und Screenreader — deshalb ist der Tastaturtest Ihr bester Einstieg.

16:17 KI beschleunigt die Arbeit, verantwortet wird sie von Menschen. Und ganz praktisch: Materialien, Prüflisten und Quellen liegen in der Seminarfreigabe. Vielen Dank für Ihre Aufmerksamkeit — und viel Erfolg damit.