Wir waren dieses Jahr erneut auf der Head in the Cloud [https://www.mittwald.de/lp/head-in-the-cloud] von mittwald [https://www.mittwald.de/] in Espelkamp unterwegs und haben dort mit Torben Mallwitz [https://linkedin.com/in/torben-mallwitz] über einen Vortrag gesprochen, den man so vermutlich nur selten auf einer Konferenz hört. Torben, CTO von guenstiger.de [https://www.guenstiger.de/], hat sehr offen darüber berichtet, wie das Unternehmen im April 2025 Opfer eines Ransomware-Angriffs wurde und welche technischen, organisatorischen und menschlichen Herausforderungen die folgenden Tage und Wochen geprägt haben.

Shownotes

[00:00:27] Ransomware, Realität und Wiederherstellung Am Morgen des 23. April 2025 begann für das Team von guenstiger.de ein Ausnahmezustand. Nahezu sämtliche internen Systeme waren verschlüsselt worden, Daten waren offenbar abgeflossen und in jedem Verzeichnis fanden sich die typischen Lösegeldforderungen samt Verweis auf eine Seite im Darknet. Glück im Unglück: Die eigentliche Preisvergleichsplattform blieb weiterhin online und konnte zumindest in einem eingeschränkten Modus weiterbetrieben werden.

Torben beschreibt sehr eindrücklich, wie professionell die hinter der Qilin-Ransomware stehende Organisation arbeitet. Ransomware wird mittlerweile als „Ransomware as a Service“ betrieben. Die Angreifer agieren wie ein Unternehmen mit klaren Strukturen, Support, Hierarchien und sogar Partnerprogrammen. Die Kommunikation läuft über ein Chatfenster im Darknet und fühlt sich, von der kriminellen Komponente abgesehen, erstaunlich ähnlich zu einer gewöhnlichen Geschäftsbeziehung an.

Für guenstiger.de war schnell klar, dass externe Hilfe benötigt wird. Noch am ersten Tag wurden Spezialisten für Incident Response und Forensik hinzugezogen, die bei der Analyse, der Verhandlung mit den Angreifern und der Wiederherstellung der Systeme unterstützten. Ein wichtiges Learning aus dem Vorfall: In einer solchen Situation sollte man nicht versuchen, alles selbst zu lösen. Die emotionale Belastung und die Vielzahl der gleichzeitig auftretenden Probleme machen einen kühlen Blick auf die Lage nahezu unmöglich.

Besonders spannend ist die wirtschaftliche Perspektive, die Torben auf das Thema einnimmt. Die Entscheidung, Lösegeld zu zahlen, wurde nicht aus Panik getroffen, sondern als nüchterne Business-Entscheidung. Der Zeitgewinn bei der Wiederherstellung der Systeme und die Bedeutung eines möglichst geringen Vertrauensverlusts gegenüber Kunden und Partnern überwogen letztlich die Alternative, alles ausschließlich aus Backups und manuellen Prozessen wieder aufzubauen.

Überraschend ist auch die Professionalität der Angreifer nach der Zahlung. Als die bereitgestellten Entschlüsselungswerkzeuge nicht überall funktionierten, gab es tatsächlich Support und Nachbesserungen. Das mag zunächst absurd wirken, folgt aber einer internen Logik: Das Geschäftsmodell der Erpresser basiert darauf, dass sich herumspricht, dass nach einer Zahlung auch tatsächlich geliefert wird.

Natürlich blieb es nicht bei der Wiederherstellung. Der Vorfall wurde genutzt, um die eigene Infrastruktur grundlegend zu modernisieren. Neue Sicherheitsmaßnahmen, Multi-Faktor-Authentifizierung, stärker zentral verwaltete Geräte und eine überarbeitete Systemarchitektur sollen zukünftige Angriffe erschweren. Daneben setzt das Team inzwischen verstärkt auf Notfallübungen und Planspiele, um im Ernstfall schneller und koordinierter reagieren zu können.

Ein zentrales Fazit des Gesprächs lautet dabei: Absolute Sicherheit gibt es nicht. Moderne IT-Systeme sind zu komplex und die Angriffsvektoren zu vielfältig. Ziel kann daher nur sein, die eigenen Systeme möglichst widerstandsfähig und als Angriffsziel möglichst unattraktiv zu machen.

Das Video zum Talk wird zeitnah auf dem YouTube Kanal von Mittwald [https://www.youtube.com/@mittwald] v

On Tour @ #headinthecloud – Der Randomware-Angriff auf guenstiger.de mit Torben
Mallwitz

Wir haben diese Revision mit Florian Sowade [https://de.linkedin.com/in/floriansowade] über den EU AI Act gesprochen. Florian hat sich in die Regulierung eingelesen und erklärt uns, was die EU damit eigentlich regulieren will, welche Risikokategorien es gibt und warum der Act nicht primär ein Verbot von KI ist.

Gemeinsam sortieren wir ein, welche Pflichten schon gelten, welche noch kommen, warum Hochrisiko-Anwendungen anders behandelt werden als alltägliche KI-Tools und weshalb gerade Transparenz, Schulungspflichten, Trainingsdaten, Deepfakes und Auditierbarkeit in der Praxis noch viele offene Fragen aufwerfen.

Shownotes

[00:01:03] EU AI Act [https://de.wikipedia.org/wiki/Verordnung_%C3%BCber_k%C3%BCnstliche_Intelligenz] Florian erklärt den EU AI Act als Versuch der EU, den Einsatz von KI zu regulieren, nicht zu verbieten. Im Zentrum steht eine Einteilung nach Risiko: inakzeptables Risiko, hohes Risiko, begrenztes Risiko und niedriges beziehungsweise nicht explizit reguliertes Risiko. Verboten sind etwa Social Scoring, bestimmte biometrische Identifikation im öffentlichen Raum und manipulative Systeme. Hochrisiko-Anwendungen betreffen Bereiche wie Kreditwürdigkeit, Recruiting, Medizin, Migration, Grenzkontrolle oder Rückfallprognosen. Dort braucht es unter anderem menschliche Kontrolle, Risikomanagement und teilweise Folgenabschätzungen.

Beim begrenzten Risiko geht es vor allem um Transparenz: Menschen sollen wissen, wenn sie mit einer KI interagieren oder wenn Bilder, Videos oder Texte KI-generiert sind. Peter und Florian diskutieren, wie gut solche Pflichten überhaupt durchsetzbar sind, ob sich daraus ähnliche Effekte wie bei Cookie-Bannern ergeben könnten und wo Missbrauch oder „malicious compliance“ naheliegen. Die niedrigste Kategorie umfasst Anwendungen wie Spamfilter, KI in Spielen, Übersetzungen, Zusammenfassungen oder alltägliche Textarbeit, die nicht weiter reguliert sind.

Ein größerer Teil des Gesprächs dreht sich um die Frage, was im Gesetz überhaupt als KI gilt. Da die Arbeit am Act bereits vor dem Durchbruch von Large Language Models begonnen hat, ist der Begriff nicht nur auf neuronale Netze oder Chatbots beschränkt. Entscheidend ist eher, ob ein System aus Daten lernt und daraus automatisiert Entscheidungen oder Empfehlungen ableitet. Das führt zu Grenzfällen, etwa bei Workflow-Tools, Coding-Assistenten oder automatisierten Entscheidungen in regulierten Branchen.

Florian ordnet außerdem ein, was der Act für Unternehmen bedeutet. Für seinen eigenen Arbeitskontext sieht er vor allem Schulungspflichten, interne Richtlinien und bewussten Umgang mit Daten als relevant an. Coding-Assistenten fallen nach seinem Verständnis nicht automatisch in Hochrisiko-Regeln, solange am Ende nachvollziehbarer Code entsteht. Kritisch wird es, wenn KI-Systeme selbst Entscheidungen treffen oder wenn generierter Code in Bereichen eingesetzt wird, in denen Grundrechte oder Lebensentscheidungen betroffen sind.

Zum Schluss sprechen wir über Bußgelder, offene Fristen, Kritik von Industrie und Netzpolitik, Transparenzpflichten für Modellanbieter, Trainingsdaten, Urheberrecht, Deepfakes, Watermarking und die Frage, wie sich KI langfristig in bestehende Software und Regulierung einfügt. Florian vermutet, dass der EU AI Act im Alltag vieler Entwicklerinnen und Entwickler eher im Hintergrund bleiben wird, aber bei Hochrisiko-Anwendungen sinnvolle zusätzliche Anforderungen schafft.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Revision 719: Der EU AI Act, mit Florian Sowade

Wir waren dieses Jahr erneut auf der Head in the Cloud [https://www.mittwald.de/lp/head-in-the-cloud] von mittwald [https://www.mittwald.de/] in Espelkamp unterwegs und haben die Gelegenheit genutzt, mit André Richter [https://www.linkedin.com/in/schnittsteller/] über die Zukunft der Website zu sprechen. André ist seit den frühen Tagen des Webs im Agenturumfeld unterwegs und beschäftigt sich heute als Director Digital Experience mit der Frage, wie Unternehmen auch in einer von KI geprägten Welt digital relevant bleiben können.

Shownotes

[00:00:26] Die Website der Zukunft Sterben Websites aus? Für André Richter lautet die Antwort: nein, aber sie verändern sich grundlegend. Die klassische Vorstellung einer Website als Sammlung von Seiten, die Menschen direkt im Browser aufrufen, verliert an Bedeutung. Stattdessen werden Inhalte und Funktionen zunehmend über Chatbots, Large Language Models und andere Interfaces vermittelt. Die Website bleibt dabei die digitale Repräsentanz eines Unternehmens, muss ihre Rolle aber neu definieren.

Im Mittelpunkt steht für André die Idee, dass eine Website immer ein Versprechen ist: Sie soll Menschen bei einem konkreten Problem helfen. Diese Funktion bleibt bestehen, auch wenn die Kommunikation künftig häufiger über Maschinen stattfindet. Webseiten werden daher nicht nur für menschliche Besucher, sondern zunehmend auch für KI-Systeme gestaltet werden müssen.

Als Denkmodell führt André seine „fünf I“ ein: Interaktion, Individualisierung, Interfaces, Inhalte und Infrastruktur. Nutzer interagieren anders mit Webseiten als noch vor wenigen Jahren und erwarten Antworten statt Linklisten. Gleichzeitig ermöglicht KI eine bislang ungeahnte Personalisierung, bei der Inhalte situativ und individuell zusammengestellt werden können. Hinzu kommen neue Interfaces jenseits des klassischen Bildschirms sowie die Frage, wie Inhalte strukturiert und technische Infrastruktur möglichst souverän und unabhängig betrieben werden können.

Besonders ausführlich sprechen wir über Inhalte. Unternehmen müssten sich viel stärker damit auseinandersetzen, was sie tatsächlich einzigartig macht. Generische Ratgebertexte und austauschbare Marketingfloskeln verlieren an Wert. Stattdessen sollten Webseiten konkrete Fragen beantworten, Probleme lösen und den eigenen Mehrwert klar herausstellen.

Technisch sieht André viele Parallelen zu den bekannten Disziplinen aus SEO und Barrierefreiheit. Semantische Strukturierung, sauber aufbereitete Inhalte und maschinenlesbare Informationen bleiben entscheidend. Wer bereits gelernt hat, Inhalte so aufzubereiten, dass Suchmaschinen und assistive Technologien sie verstehen können, bringt gute Voraussetzungen für die Welt der KI-getriebenen Suche mit.

Schließlich diskutieren wir die Frage, wie Erfolg künftig gemessen werden kann. Wenn immer weniger Nutzer direkt auf Webseiten landen, verlieren klassische Metriken wie Besucherzahlen oder Rankings an Aussagekraft. Stattdessen werden qualitative Faktoren wichtiger: Werden Nutzerbedürfnisse erfüllt? Entsteht Vertrauen? Werden die richtigen Inhalte von KI-Systemen aufgegriffen? Und wie gut gelingt es Unternehmen, bestehende Kundenbeziehungen zu pflegen und auszubauen?

Das Video zum Talk wird zeitnah auf dem YouTube Kanal von Mittwald [https://www.youtube.com/@mittwald] verfügbar sein.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

On Tour @ #headinthecloud – Die Website der Zukunft mit André Richter

Wir sprechen mit Patrick Lauke [https://www.splintered.co.uk/] (LinkedIn [https://www.linkedin.com/in/redux/], Mastodon [https://mastodon.social/@patrick_h_lauke], Bluesky [https://bsky.app/profile/did:plc:bk7qw66tikjbjux7cywqrsij]) und Peter Krautzberger [https://www.peterkrautzberger.org/] (LinkedIn [https://www.linkedin.com/in/peter-krautzberger/], Mastodon [https://mastodon.social/@pkra@bonn.social]) über die WCAG [https://www.w3.org/WAI/WCAG22/Understanding/], ihre Success Criteria und die Frage, warum ein Standard, der auf den ersten Blick sehr eindeutig wirkt, in der Praxis oft viel Interpretationsspielraum lässt.

Wir sprechen darüber, warum WCAG 2.x trotz ihrer Schwächen weiterhin die Grundlage vieler Audits und gesetzlicher Anforderungen ist, wie sich neue Erfolgskriterien additiv an ältere anhängen, warum das nicht immer elegant ist und wie Patrick im WCAG-GitHub-Repository [https://github.com/w3c/wcag/] und der Backlog-Arbeit versucht, offene Fragen und Grauzonen besser zu klären.

Shownotes

[00:00:56] WCAG, Success Criteria und Interpretationsspielräume [https://patrickhlauke.github.io/wcag-interpretation/] Wir steigen mit Patricks und Peters Hintergrund ein: Patrick arbeitet bei Tetralogical im Accessibility Consulting, war früher bei Opera und ist unter anderem im W3C-Kontext aktiv. Peter arbeitet im akademischen Verlagswesen, ist in der ARIA Working Group und Co-Editor der ARIA-Spezifikation. Von dort aus landen wir bei der WCAG 2.2 [https://www.w3.org/WAI/WCAG22/Understanding/] und der Frage, wie belastbar ihre Erfolgskriterien eigentlich sind.

Patrick beschreibt die WCAG als Standard, der objektiv und binär wirkt, in der Praxis aber oft Interpretationsarbeit verlangt. Ein Kriterium kann formal nach Pass oder Fail aussehen, aber sobald man echte Interfaces, echte Nutzer:innen und echte Audit-Situationen betrachtet, entstehen Grauzonen. Besonders schwierig wird das, weil WCAG in Gesetze und Standards hineinreferenziert wird, etwa über den EAA, EN 301 549, BITV oder andere nationale Regelungen. Damit hängen an der Auslegung nicht nur Best Practices, sondern auch Compliance, Haftungsfragen und wirtschaftlicher Druck.

Ein erstes Beispiel ist 1.1.1 Non-text Content: Alle wissen, dass Bilder, Audiohinweise oder andere Nicht-Text-Inhalte Alternativen brauchen, aber was eine „gute“ Alternative ist, hängt stark vom Kontext ab. Ist ein Speaker-Foto dekorativ, wenn der Name danebensteht? Oder gehört eine Beschreibung des Aussehens dazu? Schon hier zeigt sich, dass selbst das erste Erfolgskriterium nicht rein mechanisch prüfbar ist.

Weiter geht es mit Target Size aus WCAG 2.1 und 2.2. Patrick erklärt, dass die Formulierung theoretisch sogar einen ein Pixel großen Link bestehen lassen kann, wenn rundherum genug Abstand vorhanden ist. Das wäre formal eventuell ein Pass, praktisch aber ein schlechtes Interface. Genau solche Fälle zeigen, dass man WCAG nicht als vollständige Usability-Spezifikation missverstehen sollte.

Ein weiterer großer Block dreht sich um das additive Modell von WCAG 2.x. Ältere Success Criteria werden in Minor-Versionen nicht grundlegend umgeschrieben, damit neuere Fassungen rückwärtskompatibel zu bestehenden gesetzlichen Referenzen bleiben. Stattdessen kommen neue Kriterien hinzu. Das erklärt Überschneidungen wie zwischen Pointer Gestures und Dragging Movement. Patrick beschreibt, wie er in den nicht-normativen Understanding-Dokumenten Beispiele und Erklärungen verschoben und präzisiert hat, ohne den normativen Kern der Spezifikation umzudeuten.

Wir sprechen außerdem über Reflow und die Frage, wie sinnvoll sehr konkrete Grenzwerte wie 320 CSS Pixel sind. Die Idee dahinter ist klar: Inhalte sollen bei starkem Zoom nicht in zwei Richtungen gescrollt werden müssen. In der Praxis entstehen aber neue Frage

Revision 718: WCAG: Pass, Fail oder kommt drauf an?

Wir sprechen mit Nina Gerling [https://www.linkedin.com/in/nina-gerling/] über das erste Jahr nach dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG). Nina bringt mehr als 20 Jahre Erfahrung im Bereich digitale Barrierefreiheit mit und berichtet aus ihrer Arbeit als Beraterin, Auditorin und Mitglied verschiedener Accessibility-Communities.

Gemeinsam schauen wir darauf, welche Auswirkungen das BFSG in der Praxis hat, welche Produkte und Dienstleistungen tatsächlich betroffen sind und wo sich bereits erste Herausforderungen, Missverständnisse und Schlupflöcher zeigen. Außerdem sprechen wir darüber, warum Barrierefreiheit weit über Webseiten hinausgeht und welche Rolle Banken, Telekommunikation, E-Books, Selbstbedienungsterminals und digitale Dienstleistungen im Alltag vieler Menschen spielen.

Shownotes

[00:01:02] Ein Jahr BFSG: Was hat sich verändert? Nina erzählt von ihrem Weg von der Frontend-Entwicklung in die Beratung für digitale Barrierefreiheit und berichtet, wie sich die Accessibility-Szene durch das Inkrafttreten des BFSG verändert hat. Wir sprechen darüber, warum plötzlich viele neue Expert:innen aufgetaucht sind, weshalb Barrierefreiheit ein enorm breites Fachgebiet ist und warum man auch nach Jahrzehnten noch ständig dazulernt.Anschließend ordnen wir das Barrierefreiheitsstärkungsgesetz (BFSG) [https://www.gesetze-im-internet.de/bfsg/] ein. Dabei geht es um die Übergangsfristen, die Unterschiede zwischen Bestands- und Neusystemen sowie um die Frage, welche Produkte und Dienstleistungen überhaupt betroffen sind. Nina erläutert, dass das Gesetz vor allem verbraucherorientierte Angebote adressiert und nicht pauschal jede Website erfasst.

Wir betrachten verschiedene Anwendungsfälle wie Websites und Apps mit Vertragsabschluss, E-Books und E-Book-Reader, Selbstbedienungsterminals, Streaming- und Medienangebote sowie Telekommunikationsdienste. Besonders interessant ist die Diskussion über Echtzeit-Textkommunikation für gehörlose Menschen und die technischen Voraussetzungen in den Mobilfunknetzen, die durch europäische Vorgaben vorangetrieben werden.

Ein weiterer Schwerpunkt ist die praktische Bedeutung von Barrierefreiheit im Alltag. Am Beispiel von Banken, Geldautomaten und digitalen Bankdienstleistungen diskutieren wir, warum Barrierefreiheit nicht nur Komfort bedeutet, sondern häufig Voraussetzung für gesellschaftliche Teilhabe ist. Dabei wird deutlich, wie eng physische und digitale Zugänge inzwischen miteinander verknüpft sind.

Gegen Ende sprechen wir über die Durchsetzung von Barrierefreiheit, über Meldewege für Verstöße und über die Rolle von Community-Angeboten, Verbänden und Netzwerken. Dabei geht es auch um den Austausch innerhalb der Accessibility-Community sowie um Möglichkeiten für Menschen, die sich dem Thema erstmals nähern möchten.

Links

Nina Gerling auf LinkedIn [https://www.linkedin.com/in/nina-gerling/] Ninas LinkedIn-Profil mit Hinweisen auf Vorträge, Webinare und Beiträge rund um digitale Barrierefreiheit. MLBF [https://mlbf.link/] Projekt und Informationsangebot rund um Meldungen und Beschwerden zu mangelnder Barrierefreiheit von Marcus Herrmann [https://marcus-herrmann.com/]. Barrieren-Gutachten [https://barrieren-gutachten.de/] Portal zur Meldung und Dokumentation von Barrieren, insbesondere im öffentlichen Bereich von Casey Kreer [https://conesible.de/] & Mitstreiter:innen. IAAP D-A-CH [https://iaap-dach.org/] Fachverband für digitale Barrierefreiheit im deutschsprachigen Raum mit Webinaren und Veranstaltungen. Accessibility Club [https://accessibility.club/] Niedrigschwellige Community-Treffen für Menschen, die sich mit digitaler Barrierefreiheit beschäftigen oder einsteigen möchten.

Diskutier

Revision 717: Ein Jahr BFSG, mit Nina Gerling

Wir sprechen über Agentic Engineering und die Frage, wie sich KI-gestützte Softwareentwicklung gerade verändert. Dabei geht es weniger um klassisches Vibe Coding und mehr um die Orchestrierung von Agents, Tools und Workflows, die uns bei Planung, Umsetzung und Betrieb von Software unterstützen können.

Anhand unserer eigenen Erfahrungen diskutieren wir aktuelle Werkzeuge, den Umgang mit Skills, MCPs und Agenten sowie die Herausforderungen, die beim Einsatz von KI im Entwicklungsalltag entstehen.

Unser Sponsor



Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft [https://mittwald.de/workingdraft?ref=workingdraft.de]

Shownotes

[00:01:00] Agentic Engineering statt Vibe Coding Ausgehend von Hans‘ Artikel sprechen wir darüber, wie sich KI-Unterstützung in der Softwareentwicklung in kurzer Zeit verändert hat. Während zunächst Code-Vervollständigung, Copiloten und später Vibe Coding im Vordergrund standen, geht es heute zunehmend darum, Agents, Tools und Workflows miteinander zu verbinden. Wir diskutieren, was einen Agenten ausmacht, welche Rolle Tool-Use spielt und warum Agentic Engineering mehr umfasst als das reine Generieren von Code.

Anschließend vergleichen wir unsere persönlichen Setups. Vanessa setzt unter anderem auf OpenCode, GitLab Duo und getrennte Arbeitsumgebungen für klassische Entwicklung und Agenten-gestützte Aufgaben. Hans beschreibt seine Arbeitsweise mit Cursor und die zunehmende Verlagerung von klassischen Entwicklungsabläufen hin zu Chat- und Agent-zentrierten Workflows. Dabei geht es auch um automatisierte Refactorings, Commit-Erstellung und den sogenannten YOLO-Modus.

Ein weiterer Schwerpunkt ist die Zusammenarbeit verschiedener Systeme über das Model Context Protocol (MCP). Wir erläutern, wie Agents Informationen aus Werkzeugen wie Notion, GitLab, Slack oder Datenbanken zusammenführen können und weshalb Agentic Engineering häufig über einzelne Repositories hinausgeht. Dabei betrachten wir auch konkrete Beispiele aus dem Projektalltag, bei denen Planung, Dokumentation und Implementierung über mehrere Systeme hinweg koordiniert werden.

Ausführlich beschäftigen wir uns mit Skills [https://skills.sh]. Dabei handelt es sich um wiederverwendbare Anweisungen und Kontextinformationen, die Agents bei ihrer Arbeit unterstützen. Wir sprechen darüber, wie sich Entwicklungsrichtlinien, Brand-Vorgaben, Ticket-Strukturen oder projektspezifische Regeln in Skills abbilden lassen und welche Vor- und Nachteile ein umfangreicher Skill-Katalog mit sich bringt.

Danach betrachten wir den eigentlichen Entwicklungsprozess. Wir sprechen über Brainstorming mit AI, die Ausarbeitung von User Stories und Anforderungen, die Erstellung von Implementierungsplänen sowie den Übergang zur eigentlichen Umsetzung. Dabei wird deutlich, dass Agentic Engineering nicht nur Coding umfasst, sondern den gesamten Software-Development-Lifecycle begleiten kann.

Zum Schluss diskutieren wir die Grenzen aktueller Systeme. Insbesondere bei komplexen Frontend-Projekten, bestehenden Design-Systemen,

Revision 716: Agentic Engineering statt Vibe Coding

Wir setzen unsere Hörendenfragen aus Revision 703 [https://workingdraft.de/703/] fort und sprechen diesmal ausführlich über den Zustand von PWAs im Jahr 2026 sowie über die Frage, warum sich Browser gefühlt kaum noch weiterentwickeln. Dabei landen wir bei Install-Prompts, App-Stores, Browser-Engines, alternativen Suchmaschinen und der immer gleichen Chromium-Basis unter vielen modernen Browsern.

Außerdem diskutieren wir über neue Browser-Ideen wie den OpenAI Atlas Browser [https://chatgpt.com/de-DE/atlas/], schauen auf die Rolle von Projekten wie Electron [https://www.electronjs.org/] und Tauri [https://v2.tauri.app/] und fragen uns, ob echte Browser-Innovation heute überhaupt noch stattfindet oder ob sich das Web längst in einer Konsolidierungsphase befindet.

Shownotes

[00:05:36] The State of PWAs in 2026 [https://developer.chrome.com/blog/install-element-ot] Angestoßen durch die entsprechende Hörerfrage von Jan Gregor Emge-Triebel [https://jangregor.me/] und Søren Birkemeyer [https://annualbeta.com/] diskutieren wir, wie es Progressive Web Apps aktuell geht und warum sie trotz vieler technischer Fortschritte nie ganz den Durchbruch geschafft haben. Wir sprechen über Installierbarkeit, Browser-Chrome, fehlende Sichtbarkeit im Alltag und warum sich native App-Stores weiterhin als dominante Plattform behaupten.

Außerdem schauen wir auf neue Möglichkeiten wie das experimentelle <install>-Element [https://developer.chrome.com/blog/install-element-ot] von Chrome und Edge und diskutieren, ob bessere Install-Prompts oder integrierte App-Verzeichnisse PWAs langfristig helfen könnten. Dabei vergleichen wir PWAs auch mit Ansätzen wie Electron [https://www.electronjs.org/] und Tauri [https://v2.tauri.app/], die Webtechnologien in klassische Desktop-Anwendungen verpacken.

Auch Apples Verhältnis zu Web-Apps bleibt Thema. Wir sprechen über die jüngsten Entwicklungen rund um deklarative Push-Notifications in WebKit [https://webkit.org/blog/16535/meet-declarative-web-push/] und die Frage, wie ernst Plattformbetreiber das offene Web als App-Plattform tatsächlich nehmen.

[00:23:01] Browser-Innovation und die Chromium-Monokultur Im zweiten großen Themenblock sprechen wir über eine weitere Frage von Jan Gregor Emge-Triebel [https://jangregor.me/]: What happened to Browser-Innovation? Ausgangspunkt ist die Beobachtung, dass Browser heute zwar technisch leistungsfähig sind, sich ihre Interfaces und Konzepte aber nur noch langsam verändern.

Wir sprechen über neue Ideen wie den OpenAI Atlas Browser [https://chatgpt.com/de-DE/atlas/] und fragen uns, ob AI-gestützte Interfaces tatsächlich eine neue Browser-Generation einläuten könnten oder ob sich dahinter am Ende doch wieder nur Chromium verbirgt. Dazu passt auch unsere ältere Folge Revision 688: Browser-Engine-Diversity [https://workingdraft.de/688/], die wir erneut aufgreifen.

Danach geht es um alternative Browser und Suchmaschinen. Wir diskutieren die Wahrnehmung von Brave [https://brave.com/de/], den historischen Hintergrund von Vivaldi [https://vivaldi.com/de/] und die Rolle von Kagi [https://kagi.com/], unter anderem anhand eines Mastodon-Posts von Nileane [https://mastodon.social/@nileane@nileane.fr/116609418951205339] über die Plattform.

Außerdem schweifen wir kurz zu älteren Browser- und Präsentationsideen ab und erinnern uns an Peters HTML-basiertes Präsentationsframework Pik [https://www.peterkroener.de/pik7-ein-html5-praesentationsframework-fuer-nerds/]. Zum Schluss sprechen wir noch über den Essay Never Forgive Them [https://www.wheresyoured.at/never-forgive-them/] von Ed Citron und darüber, wie sich das Web und seine Plattformen in den letz

Revision 715: Hörendenfragen zu PWAs, Tailwind und Browsern

Wir sprechen mit Bastian Allgeier (Web [https://bastianallgeier.com/] / Mastodon [https://mastodon.social/@bastianallgeier] / Bluesky [https://bsky.app/profile/bastianallgeier.com] / LinkedIn [https://www.linkedin.com/in/bastianallgeier/]) darüber, wie sich Kirby [https://getkirby.com/] nach mehr als 14 Jahren weiterentwickelt und was es bedeutet, ein kommerzielles CMS langfristig zu pflegen. Dabei geht es um Verantwortung gegenüber Kundinnen, Kunden und Community, um Wartbarkeit, Refactoring und die Frage, warum Beständigkeit gerade in schnelllebigen Zeiten ein eigenes Feature ist.

Außerdem diskutieren wir, wie sich KI auf CMS-Entwicklung, Content-Workflows, Plugins, Support und Produktentscheidungen auswirkt. Bastian beschreibt, warum Kirby KI nicht als fest eingebautes Kernfeature behandelt, sondern weiterhin auf Offenheit, Erweiterbarkeit und Unabhängigkeit setzt.

Unser Sponsor



Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft [https://mittwald.de/workingdraft?ref=workingdraft.de]

Shownotes

[00:00:59] Kirby, KI und die Verantwortung langlebiger Software Bastian erzählt, wie aus einem Nebenprojekt für eigene Kundenprojekte nach und nach Kirby [https://getkirby.com/] wurde. Seit 2017 arbeitet er Vollzeit daran. Wir erinnern uns an frühere Besuche bei Working Draft, unter anderem Revision 592 [https://workingdraft.de/592/] zu zehn Jahren Kirby und Revision 167 [https://workingdraft.de/167/], sowie an Bastians Auftritt bei der Nightly Build [https://www.nightlybuild.de/].Ausgehend von einem Talk von Oliver Reichenstein [https://beyondtellerrand.com/events/dusseldorf-2026/speakers/oliver-reichenstein] über iA Writer [https://ia.net/de/writer] sprechen wir darüber, warum schnell erzeugte Software nicht dasselbe ist wie über Jahre gepflegte Software. Bastian betont, dass der eigentliche Aufwand oft erst nach dem ersten funktionierenden Prototyp beginnt: Wartung, Support, Weiterentwicklung, Migrationspfade, alte Abhängigkeiten und das Vertrauen der Nutzerinnen und Nutzer.

Ein großer Teil der Diskussion dreht sich um KI und sogenannte Vibe-Coding-Workflows. Bastian beobachtet, dass KI den Wechsel von anderen Systemen zu Kirby erleichtern kann, weil Migrationen schneller umsetzbar werden. Auch Plugins lassen sich heute leichter für spezifische Projekte bauen. Gleichzeitig entstehen neue Support-Probleme, wenn KI falschen Code erzeugt und Nutzerinnen und Nutzer die Fehler zunächst dem CMS zuschreiben.

Wir sprechen darüber, warum Kirbys dateibasierter Ansatz in dieser neuen Werkzeuglandschaft unerwartet gut funktioniert. Inhalte und Code liegen als Text vor, wodurch KI-Werkzeuge leichter Kontext erfassen können, ohne erst komplexe Datenbankzugriffe oder Schnittstellen zu benötigen. Kirby wird dabei weniger als klassisches Plug-and-Play-CMS beschrieben, sondern eher als flexibler Werkzeugkasten oder Klebersystem zwischen Website, Apps, Enterprise-Systemen und individuellen Workf

Revision 714: Kirby, KI und die Verantwortung langlebiger Software, mit Bastian
Allgeier

Wir drehen wieder am ARIA-Glücksrad [https://workingdraft.de/gluecksrad/] und sprechen mit Daniela [https://dnikub.dev/], Paweł [https://www.linkedin.com/in/pawe%C5%82-masarczyk-3a68b2117/] und Peter Krautzberger [https://www.peterkrautzberger.org/] über Rollen und Attribute, die man im Alltag teils nie sieht, teils besser nicht selbst nachbauen sollte. Dabei geht es um abstrakte Rollen, Menü-Patterns, deaktivierte Zustände, Dialoge, Präsentationswerkzeuge und einige ARIA-Fallen, die erst in Kombination mit Screenreadern richtig sichtbar werden. Diesmal müssen wir leider auf unser Runden-Mitglied Marco [https://www.linkedin.com/in/marco-bretschneider-norderstedt/] verzichten.

Shownotes

[00:02:33] ARIA Sectionhead Role [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/sectionhead_role] Die erste gezogene Rolle ist eine abstrakte ARIA-Rolle. sectionhead ist nicht für Autorinnen und Autoren gedacht, sondern dient innerhalb der ARIA-Ontologie als übergeordnete Rolle für Dinge, die den Kopf eines Bereichs bilden, etwa Headings, Column Header, Row Header oder Tabs. Laut Spezifikation sollen User Agents solche abstrakten Rollen nicht auf Accessibility APIs mappen, was sie für die praktische Arbeit eher zu einem Stolperstein beim Lernen macht. [00:08:04] ARIA Menuitemcheckbox Role [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/menuitemcheckbox_role] menuitemcheckbox passt in Menüs von Web-Apps, die sich an native Anwendungen annähern. Beispiele sind Menüleisten, Quick Settings und das Pattern aus den ARIA Authoring Practices für Menubars [https://www.w3.org/WAI/ARIA/apg/patterns/menubar/], etwa bei einem Texteditor, in dem Einträge wie Bold oder Italic direkt einen aktivierten Zustand haben können.

Paweł erzählt außerdem von QuentinC’s Playroom [https://www.qcsalon.net/de/], einer Plattform für Brett- und Kartenspiele für blinde Menschen, die Web-App-Patterns und ARIA-Rollen kreativ nutzt, um komplexe Spieloberflächen per Tastatur und Screenreader bedienbar zu machen.

[00:13:33] ARIA Disabled [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-disabled] aria-disabled kam schon in Revision 707 [https://workingdraft.de/707/] vor, wir beleuchten es aber noch einmal im Kontext bestimmter UI-Komponenten. Daniela bringt nämlich zwei Beispiele mit: einen Button mit Loading-, Success- und Fail-State sowie einen selbstgebauten Date Picker, in dem einzelne Tage nicht verfügbar sind.

Beim Date Picker stellt sich die Frage, ob nicht verfügbare Tage weiterhin per Pfeiltasten erreichbar sein sollten. Paweł plädiert dafür, sie im Grid sichtbar und erreichbar zu lassen, damit Screenreader-Nutzende die Struktur des Kalenders verstehen und nicht durch übersprungene Tage irritiert werden. Idealerweise sollte zusätzlich der Grund kommuniziert werden, etwa dass ein Datum nicht verfügbar oder bereits gebucht ist. Als Bezug dient das Date Picker Dialog Beispiel der ARIA Authoring Practices [https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/datepicker-dialog/].

[00:18:58] ARIA Radio Role [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/radio_role] Die radio-Rolle macht im Grunde das, was man erwartet, sollte aber möglichst nicht selbst nachgebaut werden, solange native Radio-Inputs funktionieren. Das Gespräch dreht sich schnell um Radio-Groups, die abhängig von der Auswahl weitere Formularfelder einblenden.

Paweł beschreibt ein Pattern, bei dem neue Felder im DOM direkt zwischen Radio-Optionen eingefügt werden. Bei kurzen Formularen kann das noch verständlich sein, bei längeren Abschnitten verliert ma

Revision 713: ARIA-Glücksrad – von Dialogen, Definitionen und Datepickern

We speak with Niels Leenheer [https://nielsleenheer.com/] about playful browser experiments, strange hardware, and why the web is still a great runtime for doing things it was never really designed for.

After a short recap of beyond tellerrand [https://beyondtellerrand.com/] Düsseldorf and Niels’ earlier appearances in Revision 273 [https://workingdraft.de/273/] and Revision 358 [https://workingdraft.de/358/], we dig into clocks, oscilloscopes, DMX lights, lasers, Doom, and a lot of CSS.

Shownotes

[00:03:08] HTML5 Test and old browser API experiments [https://html5test.com/] Niels introduces himself as a Dutch web developer who has been playing with the web since 1993. We talk about HTML5 Test [https://html5test.com/], a project that once gamified browser support for new HTML5 features and even influenced browser vendors to implement APIs they had not originally prioritized. Today the test is mostly obsolete, but that is also because HTML5 succeeded. [00:07:42] beyond tellerrand and creative web work We recap beyond tellerrand [https://beyondtellerrand.com/] Düsseldorf, where Niels gave a talk about his browser-based tinkering projects. The conversation also touches on the current AI-heavy mood in the industry, Oliver Reichenstein’s perspective on AI copycats, and why conferences like beyond tellerrand are valuable because they show creative, non-mainstream work that does not feel easily replaceable by AI-generated output. [00:14:56] Stubborn clocks, Raspberry Pi and physics Niels explains how he got interested in clocks through Vasilis and projects like the Diagon Clock [https://vasilis.nl/clocks/diagon-clock/23d/]. His own clock runs Chrome fullscreen on a round touchscreen attached to a Raspberry Pi. Instead of simply showing the correct time, it deliberately behaves badly: it misunderstands daylight saving time, forgets midnight, and keeps adding hours. Later, he added gravity using Box2D [https://box2d.org/] via box2d.js [https://github.com/kripken/box2d.js/], turning the clock hands into physical objects that can be flicked, dropped and bounced around. [00:20:56] Oscilloscope drawings with SVG, CSS and Web Audio Niels then describes how his obsession with clocks led him to an oscilloscope. Instead of drawing to a normal screen, he uses Web Audio to generate left and right channel signals that steer the oscilloscope beam on the X and Y axes. The shapes come from SVG: browser APIs such as path length and point sampling are used to turn SVG geometry into audio waves. CSS transforms add an extra challenge because the raw path coordinates need to be combined with transformation matrices. [00:37:26 ] DMX lights, smoke machines and WebUSB We talk about controlling stage hardware from the browser. Niels uses DMX [https://de.wikipedia.org/wiki/DMX_(Lichttechnik)], a protocol based on 512 values sent repeatedly to connected devices. With a USB-to-DMX dongle and WebUSB, a JavaScript array can be translated into packets that control lights, smoke machines and, in theory, a stage flamethrower. The browser is not replacing a classic driver here, but JavaScript acts as the converter between the web app and the device protocol. [00:38:18] Lasers, ILDA and Asteroids The laser project builds on the oscilloscope work. Niels wanted to draw with lasers, inspired by Seb Lee-Delisle’s Asteroids laser projector work [https://www.youtube.com/watch?v=FkHjG759ABY]. A USB dongle converts browser-generated coordinates into ILDA [https://de.wikipedia.org/wiki/International_Laser_Display_Association], the protocol understood by laser projectors. Because the oscilloscope project already generated X/Y coordinates, Niels

Revision 712: The Web Beyond the Edges of the Browser Window, with Niels
Leenheer

Der wöchentliche Podcast für Webdesigner:innen und -entwickler:innen. Supported
uns bei Patreon: https://patreon.com/workingdraft

Host

Shows