Working Draft

Wir haben diese Revision mit Florian Sowade ü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.

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/

Wir waren dieses Jahr erneut auf der Head in the Cloud von mittwald in Espelkamp unterwegs und haben die Gelegenheit genutzt, mit André Richter ü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.

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 verfügbar sein.

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

Wir sprechen mit Patrick H. Lauke (LinkedIn, Mastodon, Bluesky) und Peter Krautzberger (LinkedIn, Mastodon) über die WCAG, 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 und der Backlog-Arbeit versucht, offene Fragen und Grauzonen besser zu klären.

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 Fragen, etwa was bei 319 oder 321 Pixeln gilt, wie man Apps auditiert und wie man WCAG auf Nicht-Web-Kontexte überträgt. Dazu verweisen wir auf die Mobile Accessibility Task Force und WCAG2ICT.

Auch die Terminologie kommt zur Sprache: WCAG 2.x denkt noch stark in „Pages“, was bei Single-Page-Apps, App-Screens und dynamischen Views immer weniger passt. In Richtung WCAG 3 und im Kontext von WCAG-EM wird deshalb stärker über Views und Screens gesprochen. Patrick schätzt WCAG 3 zwar als wichtig und konzeptionell interessant ein, hält es aber für realistischer, die heute verwendete WCAG 2.x weiter zu schärfen, weil sie die aktuelle Audit- und Gesetzesrealität prägt.

Zum Schluss sprechen wir darüber, wie man sich einbringen kann. Die Arbeit an WCAG läuft öffentlich über GitHub, Issues und Pull Requests können verfolgt und eingebracht werden. Patrick verweist auch auf das öffentliche WCAG 2 Backlog Project Board, über das offene Themen sortiert und abgearbeitet werden.

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

Wir sprechen mit 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.

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.

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

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.

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

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. 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, CSS-Architekturen und großen Codebasen stoßen Agents noch regelmäßig an ihre Grenzen. Gleichzeitig betrachten wir die organisatorischen Auswirkungen auf Teams, Reviews, Kostenstrukturen und die zukünftige Rolle von Entwicklerinnen und Entwicklern in einer zunehmend KI-gestützten Arbeitswelt.

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

Wir setzen unsere Hörendenfragen aus Revision 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, schauen auf die Rolle von Projekten wie Electron und Tauri und fragen uns, ob echte Browser-Innovation heute überhaupt noch stattfindet oder ob sich das Web längst in einer Konsolidierungsphase befindet.

Außerdem schauen wir auf neue Möglichkeiten wie das experimentelle -Element 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 und Tauri, 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 und die Frage, wie ernst Plattformbetreiber das offene Web als App-Plattform tatsächlich nehmen.

Wir sprechen über neue Ideen wie den OpenAI Atlas Browser 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, die wir erneut aufgreifen.

Danach geht es um alternative Browser und Suchmaschinen. Wir diskutieren die Wahrnehmung von Brave, den historischen Hintergrund von Vivaldi und die Rolle von Kagi, unter anderem anhand eines Mastodon-Posts von Nileane ü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. Zum Schluss sprechen wir noch über den Essay Never Forgive Them von Ed Citron und darüber, wie sich das Web und seine Plattformen in den letzten Jahren verändert haben.

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

Wir sprechen mit Bastian Allgeier (Web / Mastodon / Bluesky / LinkedIn) darüber, wie sich Kirby 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.

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

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 Workflows.

Bei KI-Features im Produkt selbst bleibt Bastian vorsichtig. Kirby soll weiterhin selbst gehostet auf einfachen Setups ebenso laufen wie auf größeren Servern. Feste Abhängigkeiten zu Anbietern wie OpenAI oder Anthropic passen aus seiner Sicht nicht gut zu diesem Anspruch. Wer KI integrieren möchte, kann das über eigene Erweiterungen oder bestehende Plugins aus dem Kirby Plugin-Verzeichnis tun, etwa über die Suche nach AI-Plugins.

Gleichzeitig beschreibt Bastian die ethische und strategische Ambivalenz im Umgang mit KI. Kirby hat viele Nutzerinnen und Nutzer aus Design, Kunst, NGOs und nachhaltig arbeitenden Projekten, die KI teils sehr kritisch sehen. Das Team will deshalb weder KI ignorieren noch unreflektiert alles darauf ausrichten. Wichtig bleibt, die eigene Unabhängigkeit zu bewahren und nicht in einen technischen oder gedanklichen Lock-in zu geraten.

Zum Schluss schauen wir auf die nächsten Schritte: Die Kirby Konf soll im September in Mainz die Community zusammenbringen, bewusst in kleinem Rahmen mit Talks und Session-Formaten. Außerdem arbeitet das Team an Kirby 6, inklusive größerem Refactoring, Vue-3-Umstieg, TypeScript-Arbeit und Änderungen an der Authentifizierung. Die aktuelle Alpha ist bereits als Kirby 6.0.0 Alpha 2 verfügbar.

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

Wir drehen wieder am ARIA-Glücksrad und sprechen mit Daniela, Paweł und Peter Krautzberger ü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 verzichten.

Paweł erzählt außerdem von QuentinC’s Playroom, 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.

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.

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 man mit Screenreader aber schnell den Zusammenhang zur ursprünglichen Radio-Group. Dazu passt die Diskussion im ARIA-Issue zu aria-expanded auf Radio- und Checkbox-Elementen, in der genau solche dynamischen Formular-Patterns besprochen werden.

Als möglicher, aber problematischer Bezug kommt aria-controls zur Sprache. Der alte Artikel “aria-controls is poop” von Heydon Pickering wird erwähnt, weil das Attribut zwar Beziehungen ausdrücken soll, in der Praxis aber oft zu generisch und schlecht nutzbar bleibt.

Ein Beispiel ist Reveal.js, das Paweł für einen Vortrag beim Accessibility Club Summit mit Pandoc aus Markdown erzeugt hat. Die Präsentation ist HTML im Browser, nutzt aber intern role="application". Dadurch funktionieren Pfeiltasten für Slides, gleichzeitig wird das Lesen der eigentlichen HTML-Struktur mit Screenreader und Braille-Display komplizierter, weil man zwischen Application Mode und virtuellem Lesemodus wechseln muss.

Wir kommen darauf, dass Description Lists mehrere

Im Gespräch geht es außerdem um aria-modal, Fokus-Trapping, inert und die Probleme früherer Implementierungen, die etwa mit aria-hidden auf großen DOM-Bereichen gearbeitet haben. Dabei wird auch erwähnt, dass Browser heute teils versuchen, fehlerhafte Kombinationen zu reparieren oder Warnungen auszugeben.

Zum Schluss verweisen wir noch auf Manuel Matuzovićs Artikel zu role="presentation". Der erklärt, warum diese Rolle nicht automatisch dasselbe leistet wie aria-hidden und wie ARIA-Konfliktauflösung dazu führen kann, dass Browser Rollen oder Attribute verwerfen, wenn sie falsch eingesetzt werden.

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

After a short recap of beyond tellerrand Düsseldorf and Niels’ earlier appearances in Revision 273 and Revision 358, we dig into clocks, oscilloscopes, DMX lights, lasers, Doom, and a lot of CSS.

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

Wir sprechen darüber, wie man aktuelle Sprach- und Bildmodelle zu Hause betreiben kann, welche Hardware dafür realistisch ist und warum das Thema gerade zwischen Datenschutz, Kostenkontrolle und digitaler Souveränität interessant wird. Schepp erzählt von seinem Setup mit einem gebrauchten Mac Studio, LM Studio, ComfyUI, lokalen Modellen und Open WebUI als Weboberfläche für die Familie.

Dabei geht es nicht nur um die Technik, sondern auch um die Frage, wie nachhaltig die aktuellen Abo- und Credit-Modelle großer AI-Anbieter sind, wie viel RAM Modelle und Kontextfenster wirklich brauchen und wo lokale LLMs im Alltag schon nützlich sind.

Im Webcafé, dem Podcast zu Webentwicklung, Webdesign und Unternehmenskultur, nehmen euch Felix und Kay mit auf eine spannende Reise durch die Welt moderner Softwareentwicklung. Gerade ihre unterschiedliche Perspektive macht dabei den Reiz aus: Felix schaut als Geschäftsführer der Geenen IT-Systeme GmbH auf Strategie, Führung und Unternehmensentwicklung, Kay bringt als Technical Lead den Blick auf Technik, Tools und Architektur ein. Genau daraus entstehen ehrliche, fundierte und persönliche Gespräche über Webtechnologien, Zusammenarbeit und die Herausforderungen digitaler Arbeit.

Jetzt reinhören: geenen-it-systeme.de

Technisch landet man schnell bei Speicherfragen: Modelle müssen in den RAM passen, und zusätzlich braucht das Kontextfenster eigenen Speicher. Schepp erklärt grob die Faustregel, dass große Modelle mit vielen Parametern entsprechend viel Speicher benötigen, und dass zusätzliche Kontextlänge schnell mehrere Gigabyte belegen kann. In LM Studio lassen sich Open-Weights-Modelle wie Qwen oder Gemma von Huggingface, dem NPM der KI-Modelle, laden und austauschen. Die ganz großen Frontier-Modelle von OpenAI, Anthropic oder Google bekommt man lokal allerdings nicht.

Ein wichtiger Hebel ist Quantisierung: Statt Modelle in voller 16-Bit-Auflösung zu betreiben, werden sie auf kleinere Bitbreiten komprimiert, zum Beispiel 4 Bit. Dadurch werden sie deutlich kleiner und laufen auf erschwinglicherer Hardware, verlieren aber je nach Modell und Grad der Quantisierung an Genauigkeit. Schepp erwähnt außerdem Mixture-of-Experts-Modelle, bei denen zwar das ganze Modell im Speicher liegt, aber pro Anfrage nur ein Teil aktiv arbeitet.

Für Bildgenerierung nutzt Schepp ComfyUI, bei dem Abläufe grafisch als Knoten zusammengesteckt werden. Wir erklären, dass ComfyUI-Modelle separat verwaltet werden müssen und dass es dafür fertige Workflows und Community-Ressourcen gibt, etwa über die ComfyUI-Dokumentation zu Modellen oder Plattformen wie Civitai.

Auch die Hardwarefrage nimmt viel Raum ein. Apple-Silicon-Macs sind wegen ihres gemeinsamen Speichers attraktiv, aber externe Nvidia-GPUs funktionieren am Mac praktisch nicht sinnvoll. Nvidia-Karten bleiben für viele KI-Workloads attraktiv, sind mit viel VRAM aber teuer. Für gehostete Varianten kommen Anbieter wie mittwald mStudio AI-Hosting ins Spiel, wo Modelle direkt bereitgestellt werden können, statt selbst llama.cpp oder andere Serverkomponenten zu betreiben.

Im zweiten Teil geht es stärker um die wirtschaftliche und praktische Seite: Wir diskutieren, ob heutige AI-Abos und Credit-Systeme langfristig tragfähig sind, warum agentische Tools besonders schnell Tokens verbrauchen und wie sich die Kosten für Coding-, Bild- und Video-Tools im Alltag summieren können. Lokale Modelle wirken in diesem Kontext wie eine Mischung aus Datenschutzstrategie, Kostenexperiment und digitalem Prepping.

Zum Schluss dreht sich die Diskussion um den Einsatz von KI beim Programmieren. Schepp nutzt KI eher als Sparringspartner und möchte den erzeugten Code weiterhin verstehen können. Die Runde spricht über Slop, technische Schuld, schwer wartbaren KI-Code und die Frage, wann AI-generierter Output die eigene Fähigkeit übersteigt, ihn noch sinnvoll zu prüfen.

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