Wir spielen mal wieder ARIA-Glücksrad und haben uns dafür mit Paweł Masarczyk [https://www.linkedin.com/in/pawe%C5%82-masarczyk-3a68b2117/] (Mastodon [https://dragonscave.space/@Piciok]), Peter Krautzberger [https://www.peterkrautzberger.org/] (LinkedIn [https://www.linkedin.com/in/peter-krautzberger/] / Mastodon [https://bonn.social/@pkra]) und Marco Bretschneider [https://www.linkedin.com/in/marco-bretschneider-norderstedt/] (Mastodon [https://norden.social/@meise2000]) in bekannter Runde zusammengefunden. Daniela Kubesch [http://<a href=] musste diesmal krankheitsbedingt leider aussetzen 😥. Wir bedienen erneut unseren Zufallsgenerator [https://workingdraft.de/gluecksrad/], das „Glücksrad“, welches uns verschiedene ARIA-Properties ausspuckt, über die wir aus Sicht von Spezifikation, Implementierung und praktischer Nutzung mit assistiven Technologien sprechen.

Event-Tipp



Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.

Alle Infos gibt’s auf beyondtellerrand.com [https://beyondtellerrand.com?ref=workingdraft.de]

Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!

Dabei geht es weniger um trockene Attributkunde als um die Frage, was von den ARIA-Versprechen im Alltag tatsächlich bei Screenreadern und Browsern ankommt. Wir streifen typische Einsatzfälle, problematische Altlasten, offene Support-Lücken und die Unterschiede zwischen dem, was in Spezifikationen steht, was Browser daraus machen und was bei Nutzerinnen und Nutzern schließlich wirklich nutzbar ist.

Shownotes

[00:05:05] aria-selected [https://developer.mozilla.org/de/docs/Web/API/Element/ariaSelected] Zum Einstieg landen wir bei aria-selected und sprechen darüber, wo dieser Zustand überhaupt erlaubt ist, etwa bei Optionen, Tabs, Grid-Zellen oder Tree-Items. Dabei geht es unter anderem um Mehrfachauswahl in komplexeren Widgets, um den Unterschied zwischen Fokus und Auswahl sowie um die Frage, warum ARIA hier neben true und false auch noch den Zustand undefined [https://w3c.github.io/aria/#valuetype_true-false-undefined] kennt. [00:17:22] aria-level [https://developer.mozilla.org/de/docs/Web/API/Element/ariaLevel] Danach schauen wir uns aria-level an. Das Attribut kennen viele vor allem im Zusammenhang mit selbstgebauten Überschriften, also etwa bei Elementen mit role="heading", aber es spielt auch in Baumstrukturen, Kommentarhierarchien und ähnlichen Konstruktionen eine Rolle. Wir sprechen über Heading-Level jenseits von HTMLs sechs Überschriftsebenen, über Unterschiede zwischen Browsern und Screenreadern und über aktuelle Arbeiten rund um tiefere Überschriftenstrukturen, einschließlich der Diskussion um neue HTML-Mechanismen wie im WHATWG-Issue zu Heading Offsets [https://github.com/whatwg/html/issues/11655]. [00:28:14] aria-owns [https://w3c.github.io/aria/#aria-owns] und

Revision 707: ARIA-Glücksrad, die Dritte

In dieser Revision sprechen wir mit Leo Reuter von Vercel [https://vercel.com/] (LinkedIn [https://www.linkedin.com/in/leo-reuter] / E-Mail [mail%40leo-re%75ter%2E%64e]) über den Wandel von Deployment- und Hosting-Plattformen hin zu AI-gestützten Entwicklungswerkzeugen.

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]

Ausgangspunkt ist dabei unsere bisherige Beschäftigung mit Vibe Coding [https://workingdraft.de/690/] und der Frage, wie sich solche Werkzeuge in reale Entwicklungsprozesse einfügen, statt nur schnelle Demos und Prototypen zu erzeugen.

Gemeinsam schauen wir uns an, wo v0 [https://v0.app/] heute steht, wie sich das Tool von einem Generator für einzelne React-Komponenten zu einem System für komplette Anwendungen entwickelt hat und warum Themen wie bestehende Codebasen, Designsysteme, Branch-Workflows und Skills inzwischen wichtiger sind als das bloße Erzeugen von UI aus natürlicher Sprache.

[00:02:48] v0 [https://v0.app/] und Vercel [https://vercel.com/] Leo stellt zunächst seinen Weg vom Frontend-Engineering über langfristige Projektarbeit bis zu seiner Rolle als Solution Architect bei Vercel vor. Von dort aus steigen wir in die Geschichte von Next.js [https://nextjs.org/] und Vercel ein: Ausgangspunkt war der Wunsch nach mehr Guardrails im React-Ökosystem, etwa für Routing und Framework-Konventionen, und später die Frage, wie sich solche Anwendungen ohne den üblichen DevOps-Aufwand produktionsreif deployen lassen. Wir sprechen darüber, wie Vercel genau diese Lücke gegenüber klassischen Hyperscalern geschlossen hat und warum schnelle Rollbacks, Preview-Deployments und einfache Infrastruktur bis heute ein wichtiges Argument sind. [00:09:12] Von Komponenten zu kompletten Anwendungen Danach geht es um die AI-Produkte rund um Vercel und vor allem um v0 [https://v0.app/]. Leo beschreibt, wie intern zunächst mit frühen GPT-Modellen experimentiert wurde, um einzelne Komponenten zu erzeugen, und wie daraus Schritt für Schritt ein Tool entstand, das heute komplette Full-Stack-Anwendungen aus natürlicher Sprache erzeugen kann. Wir diskutieren, was inzwischen alles möglich ist, von Rapid Prototyping über Datenbank- und Payment-Anbindungen bis hin zu realistischen Produktideen, und wo die Grenze zwischen schneller Visualisierung und belastbarer Software verläuft. [00:12:50] Vom Prototyp zur produktiven Anwendung Ein Schwerpunkt der Folge ist die Frage, was „production-ready“ in diesem Kontext überhaupt bedeutet. Leo erklärt, dass v0 lange vor allem für schnelles Prototyping genutzt wurde, der Übergang in produktive Systeme aber oft daran scheiterte, dass Designsysteme, Komponenten oder der eigentliche Tech-Stack nicht übereinstimmten. Genau deshalb spielt der Git-Import inzwischen eine so große Rolle: Bestehende Projekte lassen sich in v0 laden, dort bearbeiten und über Branches und Pull Requests

Revision 706: v0 und Vercel, mit Leo Reuter

Nach rund 20 Wochen Pause haben wir uns mal wieder zusammengesetzt und durch die aktuellen Browser-Releases gewühlt. Diesmal haben uns vor allem Firefox und Safari angeschaut, während Chrome eher im Hintergrund mitlief.

Event-Tipp



Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.

Alle Infos gibt’s auf beyondtellerrand.com [https://beyondtellerrand.com?ref=workingdraft.de]

Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!

Dabei sind wir über eine ganze Reihe spannender Neuerungen gestolpert – von großen CSS-Features über neue APIs bis hin zu kleineren, aber wichtigen Verbesserungen im Detail. Wir gehen die Highlights durch und diskutieren, was davon wirklich relevant ist und wo noch Fragen offen bleiben.

Schaunotizen

[00:03:39] Anchor Positioning [https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Anchor_positioning] wird interoperabel Mit Anchor Positioning ist ein lange erwartetes CSS-Feature jetzt in allen Browsern angekommen. Es erlaubt, Elemente direkt relativ zu anderen Elementen zu positionieren – etwa für Popovers, Tooltips oder Dropdowns – ohne Wrapper-Hacks oder komplexes JavaScript. Der Browser übernimmt dabei auch das Umschalten von Positionen, wenn Inhalte am Viewport-Rand abgeschnitten würden. Besonders hilfreich ist der Artikel von Temani Afif [https://css-tip.com/anchor-issues/], der typische Edge Cases beschreibt. Ergänzend verweisen wir auf einen Talk von Bramus van Damme [https://www.youtube.com/@londonwebstandards8403], der sich ausführlich mit dem Feature beschäftigt. [00:30:27] CSS Module Scripts in Firefox [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#loading_non-javascript_resources] Firefox unterstützt nun ebenfalls CSS Module Scripts, sodass Styles direkt über ECMAScript-Module importiert werden können. Das ermöglicht neue Patterns für komponentenbasiertes Arbeiten, etwa in Kombination mit adoptedStyleSheets. Gleichzeitig diskutieren wir die Auswirkungen auf Performance und Architektur, insbesondere bei hybriden Ansätzen wie „Islands of Reactivity“, wo klassische Stylesheets und modulbasierte Styles zusammenkommen. [00:47:09] Navigation API [https://developer.mozilla.org/en-US/docs/Web/API/Navigation_API#browser_compatibility] und URL Pattern API [https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API] Die Navigation API ist jetzt auch in Firefox verfügbar und ersetzt die alte History API durch ein moderneres, eventbasiertes Modell. Navigationen können abgefangen, kontrolliert und mit eigenen Logiken versehen werden. Zusammen mit URL Pattern Matching entsteht so eine solide Grundlage für clientseitiges Routing ohne Frameworks. Die API ist Teil der Interop-Bemühungen, wie sie etwa im Interop 2026 [https://web.dev/blog/interop-2026?hl=en]-Programm definiert sind. [00:51:49] Customizable Select [https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Customizable_select] und neue Form Co [https://www.youtube.com/watch?v=WgSiqSqxTxw]

Revision 705: Browser-News-Roundup

Wir sprechen in dieser Folge mit Eleonora und Christoph vom NABU [https://www.nabu.de/] darüber, wie digitale Infrastruktur in einer großen, föderal organisierten NGO funktioniert. Ausgangspunkt ist das NABU-Netz: ein Intranet mit zentralem Login, das Mitglieder und vor allem Ehrenamtliche mit Werkzeugen für Kommunikation, Weiterbildung, Zusammenarbeit und Webarbeit versorgt.

Event-Tipp



Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.

Alle Infos gibt’s auf beyondtellerrand.com [https://beyondtellerrand.com?ref=workingdraft.de]

Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!

Im Mittelpunkt steht dabei der Webbaukasten für die vielen lokalen NABU-Gruppen. Wir schauen uns an, warum die bisherige Lösung auf Jimdo [https://www.jimdo.com/] zwar lange gut funktioniert hat, inzwischen aber an Grenzen stößt, und wie der NABU den Auswahlprozess für ein neues CMS angeht: mit Anforderungsmatrix, Rückkopplung aus dem Support, Einbindung von Ehrenamtlichen und einer Menge Fragen rund um Authentifizierung, Corporate Design, Migration und langfristige Wartbarkeit.

Schaunotizen

Der Tech-Stack des NABU Das NABU-Netz ist das zentrale Intranet des Verbands. Mitglieder können sich über einen gemeinsamen Login authentifizieren und erhalten darüber Zugriff auf verschiedene Werkzeuge, die die Verbandsarbeit unterstützen. Dazu gehören unter anderem ein Wiki auf Basis von BookStack [https://www.bookstackapp.com/], ein Chat mit Matrix [https://matrix.org/] und Element [https://element.io/], eine E-Learning-Plattform sowie eine Cloud auf Basis von OpenCloud [https://opencloud.eu/]. Für die zentrale Authentifizierung und Rechtevergabe nutzt der NABU Keycloak [https://www.keycloak.org/], damit die verschiedenen Systeme trotz unterschiedlicher technischer Grundlagen mit einem einheitlichen Login zusammenarbeiten.

Die lokalen Gruppen des NABU arbeiten sehr eigenständig, brauchen aber trotzdem Werkzeuge, mit denen sich Websites und Druckprodukte in einem gemeinsamen Erscheinungsbild erstellen lassen. Der bestehende Webbaukasten auf Basis von Jimdo [https://www.jimdo.com/] wurde ursprünglich gewählt, weil er mit seinem What-you-see-is-what-you-get-Ansatz für technische Laien gut nutzbar war. Über die Jahre sind jedoch immer mehr Sonderfälle, Designanpassungen und technische Nachrüstungen dazugekommen: JavaScript-Anpassungen für das Erscheinungsbild, manuelle HTML-Einbindungen, Cookie-Themen, fehlende Suchfunktion, problematische Statistiklösung und zusätzliche Kosten für Domains und E-Mail-Adressen. Dadurch ist aus einer einfachen Lösung ein System geworden, das für die gewachsene Komplexität des Verbands nur noch bedingt geeignet ist.

Für den Nachfolger des bisherigen Baukastens haben Eleonora und Christoph eine Anforderungsmatrix erstellt und verschiedene Systeme untersucht. In Betrachtung gezogen werden dabei unter anderem Drupal [https://www.drupal.org/], Directus [https://directus.io/], Kirby [https://getkirby.com/], Wagtail [https://wagtail.org/] und

Revision 704: Der Tech-Stack des NABU, mit Eleonora Heiden und Christoph Wolff

In dieser Revision beantworten wir Fragen aus der Hörerschaft. Wir, Peter und Schepp, haben uns einige Themen aus einer längeren Liste herausgepickt und diskutieren darüber, warum bestimmte Web-Techniken sich in der Praxis manchmal schwerer durchsetzen als man erwarten würde.

Event-Tipp



Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.

Alle Infos gibt’s auf beyondtellerrand.com [https://beyondtellerrand.com?ref=workingdraft.de]

Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!

Dabei sprechen wir unter anderem über Progressive Enhancement, den aktuellen Stand moderner Bildformate im Web sowie eine neue JavaScript-Funktion für explizites Ressourcen-Management. Wie üblich schweifen wir dabei gelegentlich ab, schauen uns Implementation-Details an und versuchen herauszufinden, was davon im Alltag von Webentwickler:innen wirklich relevant ist.

Schaunotizen

[00:10:26] Warum wird Progressive Enhancement so selten genutzt? Ausgangspunkt ist eine Frage von Tom: Wenn Progressive Enhancement theoretisch so sinnvoll ist, warum setzen viele Entwickler:innen neue Web-Features trotzdem erst ein, wenn sie in allen Browsern vollständig unterstützt werden? Wir diskutieren mögliche Gründe dafür. Ein Punkt ist sicherlich, dass viele Entwickler:innen neue Plattform-Features schlicht nicht wahrnehmen oder sie in ihrem Alltag keine große Rolle spielen. Wer hauptsächlich mit Frameworks arbeitet, wartet oft darauf, dass neue Features dort integriert werden, statt sie direkt zu nutzen.Ein anderer Faktor ist die Komplexität beim Testen: Progressive Enhancement bedeutet letztlich, mehrere mögliche Laufzeitumgebungen zu berücksichtigen. Man müsste also systematisch testen, wie sich eine Anwendung verhält, wenn einzelne Features fehlen – etwa in unterschiedlichen Browsern, auf verschiedenen Geräten oder unter speziellen Bedingungen wie deaktiviertem JavaScript. In der Praxis passiert das jedoch selten. Wir sprechen außerdem über mögliche Tools und Ideen, die solche Tests vereinfachen könnten. [00:26:35] Welche Bildformate sollte man heute im Web verwenden? Anschließend beschäftigen wir uns mit einer praktischen Performance-Frage: Welche Bildformate sind heute sinnvoll im Web? Klassische Formate wie JPEG oder PNG werden zunehmend von moderneren Alternativen abgelöst. Besonders relevant sind hier WebP und AVIF, die beide aus Videocodecs entstanden sind (VP- und AV1-Familie) und deutlich bessere Kompressionsraten bieten.Wir sprechen über Unterschiede bei Kompression, Decoding-Geschwindigkeit und praktischen Einsatzszenarien. Während AVIF häufig die bessere Kompression liefert, kann das Encoding deutlich rechenintensiver sein – insbesondere bei On-Demand-Bildgenerierung auf Servern. WebP ist in solchen Szenarien oft pragmatischer. Außerdem diskutieren wir progressive Bilddarstellung bei JPEG, Tricks für progressive Wahrnehmung sowie zukünftige Entwicklungen wie JPEG XL oder kommende Codecs wie AV2. [00:58:56] Explicit Resource Manage

Revision 703: Hörenden-Fragen – Progressive Enhancement, Bildformate und
JavaScript Disposables

In dieser Revision sprechen wir mit Thomas Steiner [https://blog.tomayac.com/] von Google über einen lange offenen Schmerzpunkt im Web: Permission-Dialoge. Ausgangspunkt ist das neue <geolocation>-Element, das Chrome eingeführt hat und das Permissions kontextueller, deklarativer und weniger fehleranfällig machen soll.

Event-Tipp



Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.

Alle Infos gibt’s auf beyondtellerrand.com [https://beyondtellerrand.com?ref=workingdraft.de]

Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!

Dabei schauen wir zurück auf die Geschichte der Geolocation API [https://developer.mozilla.org/docs/Web/API/Geolocation/getCurrentPosition], diskutieren Permission-Spam, Browser-Mitigations wie den „Blue Chip“ und werfen einen Blick auf PEPC (Page Embedded Permission Control) [https://github.com/WICG/PEPC] als ursprünglichen Ansatz. Außerdem geht es um UX, Security, Styling-Grenzen und die Frage, wie neue Webstandards sich in einer Welt voller Frameworks und KI-Generatoren durchsetzen können.

Schaunotizen

[00:01:42] Das <geolocation>-Element [https://developer.chrome.com/blog/geolocation-html-element] Permissions im Web waren lange implizit oder API-getrieben: Wer etwa navigator.geolocation.getCurrentPosition() [https://developer.mozilla.org/docs/Web/API/Geolocation/getCurrentPosition] aufruft, triggert einen Browser-Dialog. Alternativ gibt es explizite Anfragen wie Notification.requestPermission() [https://developer.mozilla.org/docs/Web/API/Notification/requestPermission_static]. Beide Varianten haben über die Jahre zu Permission-Spam, „Permission Fatigue“ und UX-Problemen geführt.

Ein früher Versuch zur Vereinheitlichung war navigator.permissions.request(), der jedoch nach Diskussionen im W3C Permissions Repository (Issue #83) [https://github.com/w3c/permissions/issues/83] wieder verworfen wurde. Stattdessen entstand bei der TPAC [https://www.w3.org/wiki/TPAC] 2023 die Idee der Page Embedded Permission Control (PEPC) [https://github.com/WICG/PEPC]: ein deklaratives <permission>-Element mit type-Attribut und optionalem type-ext für Details wie Präzision oder Constraints.

Daraus wurde schließlich ein spezialisierter Ansatz: Statt eines generischen Elements gibt es nun dedizierte Elemente wie <geolocation>. Chrome hat dieses Element mittlerweile geshipped (siehe Blogpost [https://developer.chrome.com/blog/geolocation-html-element], Feature-Status auf ChromeStatus [https://chromestatus.com/feature/5125006551416832]). Es kapselt nicht nur die Permission-Abfrage, sondern liefert direkt Positionsdaten – deklarativ und mit Events statt Callback-basierter Legacy-API.

UX-seitig bringt das neue Modell einige Änderungen: Der Dialog wird zentriert angezeigt, der Hintergrund kann abgedunkelt werden, und es gibt differenzierte Zustände („Allow on every visit“, „Allow this time“, „Continue not allo

Revision 702: Das <geolocation>-Element, mit Thomas Steiner

In dieser Folge sprechen wir mit Daniel Fau [https://www.linkedin.com/in/danielfau/] (CEO der TYPO3 GmbH [https://typo3.com/]) über den aktuellen Stand des Government Site Builder (GSB) [https://www.itzbund.de/DE/itloesungen/standardloesungen/gsb/gsb.html].

Event-Tipp



Noch nichts vor am 28. Februar? 👀

Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem 2D-Scroller-Spiel im Browser 🎮✨

👉 https://2026.stateofthebrowser.com [https://2026.stateofthebrowser.com?ref=workingdraft.de]

Remote-Ticket jetzt mit diesem Link zum halben Preis (£10): https://ti.to/lws/sotb2026/discount/Status_des_Browsers

Nachdem wir zuletzt vor allem über fehlende Ansprechpartner, 404-Links und Kommunikationshürden gestolpert sind, wollten wir genauer verstehen, wie GSB 11 technisch und organisatorisch aufgestellt ist.

[00:01:09] GSB 11: Standardisiertes TYPO3-CMS für die öffentliche Verwaltung [https://produkt.gsb.bund.de/gsb11] Der Government Site Builder (GSB) [https://www.itzbund.de/DE/itloesungen/standardloesungen/gsb/gsb.html] existiert seit 2003 und wurde ursprünglich vom Bundesverwaltungsamt (BVA) [https://www.bva.bund.de/] in Zusammenarbeit mit Materna entwickelt. Später übernahm die „Bundesstelle für Informationstechnik“ (BIT) Betrieb und Hosting, bevor diese Aufgaben 2016 im ITZBund [https://www.itzbund.de/] gebündelt wurden. Mit GSB 11 erfolgt nun der strategische Wechsel auf TYPO3 [https://typo3.org/] als technische Basis.

Frühere Versuche wie GSB 10 setzten zwar auf Open-Source-Komponenten, blieben aber ohne echte Community-Anbindung. GSB 11 wird dagegen explizit als standardisiertes CMS auf TYPO3-Basis entwickelt – mit Fokus auf Sicherheit, Barrierefreiheit, Wartbarkeit und Automatisierung. Daniel verweist in diesem Zusammenhang auch auf Marktdaten wie den CMS Census [https://cmscensus.de], der TYPO3 insbesondere im Public-Sector-Umfeld stark positioniert.

Technisch liegt die Distribution auf OpenCoDE [https://opencode.de/de/software/government-site-builder-11-gsb-11-2460], der Open-Source-Plattform der öffentlichen Verwaltung. Das Projekt ist über die zugehörige GitLab-Instanz [https://gitlab.opencode.de/bmi/government-site-builder-11/gsb11] einsehbar; dort finden sich Distribution, Extensions sowie – seit 2025 – auch ein öffentlich verfügbares Default-Frontend [https://gitlab.opencode.de/bmi/government-site-builder-11/extensions/gsb_public_frontend]. Releases erfolgen in regelmäßigen Zyklen, während die Roadmap transparent im Projekt hinterlegt ist.

Organisatorisch wurde GSB 11 in drei Losen ausgeschrieben: Produktentwicklung (Los 1), Betrieb (Los 2) und Migration/Relaunch (Los 3). Die Vergabe erfolgte im Rahmen des deutschen bzw. europäischen Ausschreibungsrechts (Kontext: TED – Tenders Electronic Daily [https://ted.europa.eu], eVergabe [https://www.evergabe-online.de]). Das Gesamtvolumen liegt im dreistelligen Millionenbereich über mehrere Jahre – ein erheblicher Open-Source-Invest.

Für Bundesbehörden stehen sogenannte Mandantenentwicklungsoptionen (MEO) zur Verfügung: MEO&nbs

Revision 701: Der Government Site Builder (GSB) – mit Daniel Fau

Zum Jubiläum werfen wir einen Blick zurück – ziemlich genau zehn Jahre. Inspiriert von einem Vorschlag aus unserem Community-Slack hören wir noch einmal in unsere Prognosen-Folge von Ende 2015 hinein [https://workingdraft.de/246/] und prüfen: Was ist aus unseren damaligen Thesen zu HTTP/2, Flexbox, Angular 2, React, Web Components und WebAssembly geworden?

Event-Tipp



Noch nichts vor am 28. Februar? 👀

Bei der State of the Browser 2026 erwarten euch Talks zu CSS Anchor Positioning, Accessibility jenseits von Checkbox-Compliance, der Temporal API, Performance, minimalistischen Web-Erlebnissen und sogar einem 2D-Scroller-Spiel im Browser 🎮✨

👉 https://2026.stateofthebrowser.com [https://2026.stateofthebrowser.com?ref=workingdraft.de]

Remote-Ticket jetzt mit diesem Link zum halben Preis (£10): https://ti.to/lws/sotb2026/discount/Status_des_Browsers

Zwischen Nostalgie, realistischen Einschätzungen und ein paar veritablen Fehleinschätzungen sprechen wir darüber, wie sich Frontend-Engineering tatsächlich verändert hat – und wo wir heute stehen: weniger Browser-Drama, mehr Tooling, mehr Framework-Vielfalt und ein völlig neues Spannungsfeld durch AI-gestützte Entwicklung.

Schaunotizen

[00:01:16] Das Web 10 Jahre später: Evolution statt Revolution Wir stellen fest: Viele Entwicklungen sind nicht spektakulär explodiert, sondern langsam gereift. HTTPS ist heute selbstverständlich – befeuert durch Let’s Encrypt und die Einführung von HTTP/2 (inklusive des mittlerweile gescheiterten Server Push) sowie später HTTP/3.

Im CSS-Bereich hat sich Grid etabliert, ohne Flexbox zu verdrängen. Beide koexistieren – oft pragmatisch statt dogmatisch eingesetzt.

Bei JavaScript hat ES2015 vieles verändert, aber weniger fundamental als gedacht. Wirklich einschneidend war async/await; vieles andere war „syntaktischer Zucker“. Parallel hat sich TypeScript stark verbreitet – ohne JavaScript zu ersetzen.

Im Framework-Bereich ist keine Monokultur entstanden: React, Angular, Vue und andere bedienen unterschiedliche Ökosysteme. Statt Konsolidierung sehen wir Fragmentierung. Und dann gibt es die AI-Tools, die bevorzugt mit React/TypeScript arbeiten.

Web Components und WebAssembly? Kein Mainstream-Overtake, aber solide Nischen-Erfolge. Sie tun genau das, wofür sie gedacht waren – nicht mehr, nicht weniger.

Und schließlich: Browser-Testing ist entspannter geworden. Der Internet Explorer ist Geschichte, Edge-Cases existieren weiterhin (hallo iOS Safari), aber das Drama-Level ist deutlich gesunken. Headless-Browser und CI-Tests haben neue Testrealitäten geschaffen.

Links

Let’s Encrypt [https://letsencrypt.org/] Kostenlose TLS-Zertifikate, die HTTPS massentauglich gemacht haben. Next.js [https://nextjs.org/] React-Framework, das als Default-Stack vieler AI-Tools gilt. Vercel [https://vercel.com/] Hosting-Plattform, eng mit Next.js verzahnt. Playwright [https://playwright.dev/] Browser-Automatisierung und Testing-Framework für Headless-Tests. BrowserStack [https://www.browserstack.com/] Cloud-Dienst zum Testen in echten Browser-/Device-Kombinationen.

Revision 700: 2016 vs. 2026 – Was ist aus unseren Prognosen geworden?

In dieser Folge setzen wir dort an, wo wir mit der vorherigen ARIA-Glücksrad-Folge [https://workingdraft.de/683/] aufgehört haben. Denn wir haben nach der Veröffentlichung tolles Feedback bekommen und holen uns deren Absender als Verstärkung rein: Mit Accessibility Engineer Daniela Kubesch [https://dnikub.dev/] (LinkedIn [https://www.linkedin.com/in/danikubesch/] / Bluesky [https://bsky.app/profile/dnikub.bsky.social] / Mastodon [https://front-end.social/@dnikub]), Frontend/Design-Systems Engineer Marco Bretschneider [https://www.linkedin.com/in/marco-bretschneider-norderstedt/], Web-Technologie-Consultant und W3C Invited Expert Peter Krautzberger [https://www.peterkrautzberger.org/] (LinkedIn [https://www.linkedin.com/in/peter-krautzberger/?lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BEhtEmt2zTLq0cd6DZ0e4sQ%3D%3D]) und Accessibility Experience Experten Paweł Masarczyk [https://www.linkedin.com/in/pawe%C5%82-masarczyk-3a68b2117/] sprechen wir darüber, was von ARIA-Attributen in der Praxis wirklich ankommt – bei Browsern, im Accessibility Tree und letztlich bei Screenreadern.

Wir gehen systematisch die Attribute aus der letzten Glücksrad-Runde durch, ordnen sie technisch ein und ergänzen sie um Perspektiven aus Spezifikation, Implementierung und tatsächlicher Nutzung. Dabei wird klar: Zwischen Spec-Idee, API-Mapping und realer Unterstützung liegen oft Welten.

Shownotes

[00:05:08] aria-placeholder [https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-placeholder] Wir klären, dass aria-placeholder tatsächlich das ARIA-Pendant zum HTML-placeholder ist – gedacht für selbstgebaute Input-ähnliche Controls. Alle sind sich einig: In freier Wildbahn sieht man es kaum, was vermutlich auch ein gutes Zeichen ist. Spannend ist vor allem, wie Placeholder von Screenreadern angesagt werden und wie sie sich von aria-describedby unterscheiden lassen. [00:11:25] aria-details [https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-details] & ariaDetailsElements (DOM) [https://developer.mozilla.org/docs/Web/API/Element/ariaDetailsElements] Peter nutzt die Gelegenheit für einen Deep Dive: aria-details ist kein „längeres Describe-By“, sondern ein eigenes Pattern, entstanden aus echten Use-Cases (z. B. Google Docs mit Kommentaren). Wir sprechen über die neuen Element-APIs, die ohne ID-Listen auskommen, über Popover-Verknüpfungen und darüber, wie vage Specs bewusst Spielraum für Assistive Technologien lassen. [00:21:13] (Core) Accessibility API Mappings (AAM) [https://www.w3.org/TR/core-aam-1.2/] Ein Abstecher unter die Haube: AAM-Spezifikationen beschreiben, wie DOM und ARIA auf die Accessibility-APIs der Betriebssysteme gemappt werden. Eigentlich für Browser-Hersteller gedacht – aber extrem hilfreich, um zu verstehen, wo Informationen verloren gehen oder ergänzt werden. [00:33:35] aria-posinset [https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-posinset] & aria-setsize [https://developer.mozilla.org/docs/Web/Accessibility/ARIA/Attributes/aria-setsize] Die Klassiker für große, virtuelle Datenmengen. Wir diskutieren, warum diese Attribute auf Einzelelementen sitzen müssen, wie gut sie tatsächlich unterstützt sind und ob User Agents nicht mehr selbst berechnen sollten. Fazit: theoretisch sinnvoll, praktisch noch eine Baustelle. [00:47:17] aria-errormessage [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-errormessage] Ein gutes Beispiel für das Dilemma „gute Idee, holprige Unterstützung“. Während NVDA und TalkBack Fortsc

Revision 699: ARIA-Glücksrad Nachklapp, neue APIs und reale Unterstützung

In dieser Folge sprechen wir zu zweit über unsere Eindrücke rund um den Government Site Builder (GSB) [https://www.bundesregierung.de/breg-de/service/gsb] – ausgelöst durch unseren Besuch auf der T3CON in Düsseldorf [https://t3con.typo3.com/].

Eigentlich wollten wir vor Ort ein Interview zum Projekt führen. Herausgekommen ist stattdessen eine kurze, leicht rantige Bestandsaufnahme darüber, wie schwer es ist, überhaupt belastbare Informationen oder Gesprächspartner:innen zum GSB zu finden.

Wir sprechen darüber, warum uns das Thema trotz (oder gerade wegen) politischer Rahmenbedingungen interessiert, welche Rolle das Informationstechnikzentrum Bund (ITZ-Bund) [https://www.itzbund.de/] spielt, wie Agenturen in sogenannten „Losen“ organisiert sind – und warum ein Projekt, das sich selbst als 100 % Open Source bezeichnet, von außen oft erstaunlich verschlossen wirkt.

[00:01:06] Government Site Builder (GSB 11) Der Government Site Builder ist ein von der Bundesverwaltung initiiertes Projekt, das eine standardisierte technische Basis für Webseiten von Bundesbehörden bereitstellt. Die aktuelle Version GSB 11 basiert auf TYPO3 [https://typo3.org/] und wird vom ITZ-Bund [https://www.itzbund.de/] verantwortet. Ziel ist es, Digitalisierung voranzubringen, Abhängigkeiten von proprietären Systemen zu reduzieren und eine einheitliche, barrierearme Plattform für Behördenwebsites zu schaffen.In der Umsetzung arbeitet das Projekt mit mehreren Vergabelosen: Während das ITZ-Bund den grundlegenden Tech-Stack verantwortet (Los 1), werden Migrationen und Implementierungen von Agenturen übernommen (Los 3). Als Generalunternehmer fungiert dabei eine große Agentur, unter deren Dach zahlreiche weitere Agenturen eingebunden sind.

Trotz des Open-Source-Anspruchs stößt man aktuell auf Hürden: Verlinkte Code-Repositorien auf OpenCode [https://opencode.de/] sind teilweise nicht öffentlich zugänglich, Aussagen zum Projekt müssen offenbar umfangreich abgestimmt werden, und selbst auf Konferenzen fällt es schwer, auskunftsfähige Ansprechpartner:innen zu finden.

Das steht in einem spürbaren Kontrast zu früheren Vorbildern wie gov.uk [https://www.gov.uk/], wo technische Erkenntnisse, Accessibility-Learnings und Architekturentscheidungen offen in die Community zurückgespielt wurden. Genau diese Offenheit vermissen wir aktuell beim GSB – obwohl das Projekt aus öffentlichen Mitteln finanziert wird und explizit Transparenz betont.

Links

bundespolizei.de [https://www.bundespolizei.de/] Beispiel einer Website, die bereits auf Basis von GSB 11 umgesetzt wurde. karriere.bund.de [https://www.karriere.bund.de/] Weitere öffentlich genannte Referenz für einen produktiven Einsatz des Government Site Builders. CoreMedia [https://www.coremedia.com/] Kommerzielles, Java-basiertes CMS, auf dem frühere GSB-Versionen (z. B. Version 7)
noch weit verbreitet laufen. KoliBri [https://public-ui.github.io/docs] Web-Components-basierte Frontend-Library, die im Kontext des GSB als mögliche
UI-Basis erwähnt wird. David Heinemeier Hansson [https://dhh.dk/] Erwähnt im Kontext der Diskussion, was „Open Source“ eigentlich bedeutet,
wenn Code zwar einsehbar, aber kaum offen für externe Beiträge ist.

Revision 698: Government Site Builder – Open Source, aber bitte nicht zu offen?

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

Working Draft