Mit zwölfjähriger Geschichte und über 5.000 Downloads pro Folge ist Working Draft
der etablierteste Podcast für Webentwickler im deutschsprachigen Raum.
Wenn ihr neue Entwicklerkollegen sucht oder ein Produkt für Webentwickler
anbietet, schreibt uns unter sponsoring@workingdraft.de.
In dieser Revision sprechen wir mit Thomas Steiner 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.
Dabei schauen wir zurück auf die Geschichte der Geolocation API, diskutieren Permission-Spam, Browser-Mitigations wie den „Blue Chip“ und werfen einen Blick auf PEPC (Page Embedded Permission Control) 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.
Permissions im Web waren lange implizit oder API-getrieben: Wer etwa navigator.geolocation.getCurrentPosition() aufruft, triggert einen Browser-Dialog. Alternativ gibt es explizite Anfragen wie Notification.requestPermission(). 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) wieder verworfen wurde. Stattdessen entstand bei der TPAC 2023 die Idee der Page Embedded Permission Control (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, Feature-Status auf ChromeStatus). 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 allowing“). Damit soll „Permission Regret“ reduziert werden – also das nachträgliche Bereuen einer Entscheidung.
Es gibt außerdem Styling-Regeln: Bestimmte CSS-Eigenschaften sind eingeschränkt, um Clickjacking oder visuelle Täuschung zu verhindern. Pseudo-Klassen wie :granted oder :invalid sowie Events wie onvalidationstatuschange, onpromptaction und onpromptdismiss ermöglichen dennoch eine Integration ins UI.
In der Standardisierungsdiskussion gab es unterschiedliche Positionen: WebKit und Mozilla äußerten zunächst Vorbehalte gegenüber dem generischen Permissions-Element. Mit dem fokussierten <geolocation>-Ansatz scheint sich die Lage zu entspannen; Mozilla signalisiert vorsichtige Zustimmung, während WebKit noch prüft.
Weitere Stichworte unseres Gesprächs sind die „Line of Death“ (Abgrenzung zwischen Web-Content und Browser-UI), User Activation (siehe User Activation in Chrome) sowie Browser-Mitigations gegen Spam, etwa ML-gestützte Heuristiken und der nicht-modale „Blue Chip“ bei Notification-Prompts (siehe Origin Trial zum Permission-Element und Best Practices).
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.
Der Government Site Builder (GSB) existiert seit 2003 und wurde ursprünglich vom Bundesverwaltungsamt (BVA) in Zusammenarbeit mit Materna entwickelt. Später übernahm die „Bundesstelle für Informationstechnik“ (BIT) Betrieb und Hosting, bevor diese Aufgaben 2016 im ITZBund gebündelt wurden. Mit GSB 11 erfolgt nun der strategische Wechsel auf TYPO3 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, der TYPO3 insbesondere im Public-Sector-Umfeld stark positioniert.
Technisch liegt die Distribution auf OpenCoDE, der Open-Source-Plattform der öffentlichen Verwaltung. Das Projekt ist über die zugehörige GitLab-Instanz einsehbar; dort finden sich Distribution, Extensions sowie – seit 2025 – auch ein öffentlich verfügbares Default-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, eVergabe). 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 1 bedeutet weitgehend standardisierte Nutzung inklusive Hosting, Wartung und Sicherheitsprüfung (u. a. mit Bezug auf Prüfmechanismen im Umfeld des BSI), MEO 2 erlaubt weitergehende Anpassungen, bringt aber mehr Eigenverantwortung mit sich. Darüber hinaus bleibt das DIY-Modell möglich: Distribution herunterladen, selbst betreiben – Open Source eben.
Zielsetzung ist ein „One-for-All“-Ansatz im Sinne übergreifender Standardisierung (Kontext: IT-Planungsrat) statt individueller Neuentwicklung. Gleichzeitig diskutieren wir die Kommunikationsrealität rund um GSB 11: lange Vergabeprozesse, NDA-Sensibilität, vorsichtige öffentliche Aussagen – und die Frage, wie offen sich Open Source im öffentlichen Sektor anfühlen kann und sollte.
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 und prüfen: Was ist aus unseren damaligen Thesen zu HTTP/2, Flexbox, Angular 2, React, Web Components und WebAssembly geworden?
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.
In dieser Folge setzen wir dort an, wo wir mit der vorherigen ARIA-Glücksrad-Folge 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 (LinkedIn / Bluesky / Mastodon), Frontend/Design-Systems Engineer Marco Bretschneider (Mastodon), Web-Technologie-Consultant und W3C Invited Expert Peter Krautzberger (LinkedIn / Mastodon) und Accessibility Experience Experten Paweł Masarczyk (Mastodon) 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.
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.
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.
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.
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.
Ein gutes Beispiel für das Dilemma „gute Idee, holprige Unterstützung“. Während NVDA und TalkBack Fortschritte machen, bleibt die Abdeckung lückenhaft. Trotzdem sehen wir den Mehrwert gegenüber reinem aria-describedby – gerade, wenn Fehlermeldungen klar als solche kommuniziert werden sollen.
Wir diskutieren die Idee, Audio-Ausgabe per CSS zu beeinflussen: von Tonhöhe über Geschwindigkeit bis hin zu Sound-Design. Zwischen Branding-Potenzial und Kontrollverlust für Nutzer:innen entsteht eine Grundsatzfrage, die stark an Debatten rund um Alternativtexte erinnert.
Sehr spezielle Werkzeuge für sehr spezielle Fälle. Peter erklärt, warum Braille-Attribute existieren, wofür sie gedacht sind (z. B. Bildung, Musik- oder Chemienotation) – und warum man sie in 99,9 % der Fälle besser nicht anfasst.
Wir landen wieder bei großen Tabellen, Grids und Tree-Grids: Wann machen zusätzliche ARIA-Infos Sinn, wann sind sie redundant? Besonders spannend sind menschenlesbare Index-Texte (z. B. Schachfelder wie „A4“) jenseits reiner Zahlen.
Ein eher leises Signal mit großer Wirkung: Es teilt Assistive Technologien mit, dass eine interaktive Liste Mehrfachauswahl erlaubt. Wir ordnen es ein zwischen nativen Desktop-Patterns, Web-Mail-UIs und den WAI-ARIA Authoring Practices.
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) 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.
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 und wird vom ITZ-Bund 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 sind schienen 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, 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.
Update: Nach Hinweisen von Hörenden liegt das Projekt auf Open Code hier und der Sourcecode selbst hier Vielen Dank dafür!.
In dieser Folge sprechen wir mit Frederik Braun (Mastodon) aus dem Firefox-Security-Team bei Mozilla über den langen Weg der Sanitizer API: Von ersten Prototypen vor über fünf Jahren bis zum geplanten Shipping in Firefox und Chrome im Februar 2026.
Einleitend klären wir, warum Cross-Site-Scripting (XSS) auch 2026 noch eines der größten Web-Security-Probleme ist, weshalb bestehende Lösungen wie DOMPurify, Content Security Policy oder Trusted Types zwar helfen, aber kaum breit eingesetzt werden – und dass die Sanitizer API einen neuen, deutlich praxisnäheren Ansatz verfolgt.Die Sanitizer API ist ein neuer Web-Standard, mit dem sich unsicheres HTML direkt beim Einfügen in den DOM bereinigen lässt – ohne String-Roundtrips und ohne zusätzliche Bibliotheken. Statt Element.innerHTML = html wird künftig Element.setHTML(html) verwendet. Der Browser übernimmt Parsing, Bereinigung und Einfügen in einem Schritt und verhindert zuverlässig Cross-Site-Scripting, DOM-Clobbering und viele Varianten von Mutated-XSS.
Die eingangs erwähnte, mittlerweile fünfeinhalb Jahre alte Folge mit Frederik, in der XSS und die ursprüngliche Idee der Sanitizer API bereits ausführlich besprochen wurden.
Dieses Interview ist Teil der Serie On Tour @ #t3con. T3CON ist die jährliche Konferenz, bei der es um alle Themen rund um TYPO3 geht. Wir waren am 25. November 2025 in Düsseldorf beim Community Day vor Ort und haben die Stimmung und einige Interviews mitgenommen.
Incluthon: Inklusion testen statt abhaken
Auf dem Community Day der T3CON in Düsseldorf sprechen wir mit Stefan Barac (LinkedIn) über Incluthon: eine Initiative, die Menschen mit Behinderungen mit Unternehmen zusammenbringt, um digitale Produkte wirklich inklusiver zu machen. Statt reiner Checklisten geht’s um echte Usability-Tests mit Accessibility-Fokus, bei denen Barrieren aus realer Nutzungsperspektive sichtbar werden.
Außerdem geht’s um Mentoring und Sensibilisierung für ganze Produktteams: von verständlicher Sprache über passende Ikonografie und Informationsarchitektur bis hin zu der Erkenntnis, dass Accessibility ein fortlaufendes Programm ist (kein einmaliges Projekt). Wir streifen dabei auch regulatorischen Druck (BFSG, European Accessibility Act) und die WebAIM-Million-Studie als Reality-Check – und empfehlen ausdrücklich, sich die Demos/Webinare von Claudio Zeni anzuschauen, um ein besseres Gefühl für assistive Technologien in der Praxis zu bekommen.
So lang ist es her (5 Jahre), dass Anselm Hannemann hier im Working Draft Teil des Podcast-Teams war. Jetzt habe ich (Hans) ihn mal gefragt, ob er mal wieder bei uns zu Gast sein möchte — und er hat ja gesagt.
Heute geht’s mal um Anselm, was ihn zu dem gemacht hat, der er heute ist, und was er in den letzten Jahren so getrieben hat.
Schaunotizen
[00:03:30] Zum Programmieren gekommen
Wir sprechen darüber, wie wir uns kennengelernt haben. Da war der Weg nicht weit, um über Anselms Werdegang zu sprechen: Ausbildung, Studium und erste Projekte. Spannend auch, wie damals Print-Design ins Web gebracht wurde.
[00:20:30] Engineering Management als Freelancer
Wir sprechen darüber, wie sich Engineering Management außerhalb klassischer Festanstellungen anfühlt und welche besonderen Herausforderungen das Freelancing in dieser Rolle mit sich bringt. Anselm erzählt, zwischen Technik, Menschenführung und Erwartungen von Auftraggebern zu navigieren, wie Verantwortung ohne formale Macht funktioniert und warum Kommunikation, Vertrauen und klare Rollen dabei entscheidend sind.
[00:31:00] Burn-out, Prävention und Gartenprojekt
Ein tolles Projekt, das Anselm vor einigen Jahren ins Leben gerufen hat, ist eine eigene Gärtnerei. Nach Burn-out und Überlegungen, wie man im Software-Engineering eigentlich gesund bleibt, kam es zu dieser kostspieligen Idee. Unser Gespräch geht über die Finanzierung und Personal-Coaching, das aus dem Burn-out hilft.
Eine ziemlich cool gemachte Doku über Anselm, seinen Weg als Entwickler und Freelancer sowie darüber, wie er nach einem Burn-out neue Perspektiven zwischen Software-Engineering, Selbstorganisation und Gartenarbeit gefunden hat.
Dieses Interview ist Teil der Serie On Tour @ #t3con. T3CON ist die jährliche Konferenz, bei der es um alle Themen rund um TYPO3 geht. Wir waren am 25. November 2025 in Düsseldorf beim Community Day vor Ort und haben die Stimmung und einige Interviews mitgenommen.
Frontend State of TYPO3
Mit Thomas Maroschik konnten wir ein TYPO3 Board Member für uns gewinnen. Er gibt uns Einblicke, wie Frontend Technologien in TYPO3 gerade ein neues Hoch erfahren, wie man TYPO3 als Headless CMS nutzen kann und wie KI TYPO3 beeinflusst.
Zum Jahresende gibt’s noch ein kleines Extra für Euch: Unsere großartige Post-Producerin Sabine hat sich hingesetzt und aus dem Jahr wieder herrliche Outtakes zusammengeschnitten – Versprecher, Neustarts, Ratlosigkeit, Lachen und all die Momente, die es sonst nie in die Folge schaffen. Ein liebevoller Blick hinter die Kulissen von Working Draft und ein Geschenk, über das wir uns sehr gefreut haben. Viel Spaß beim Hören (und Mitlachen)!
Impressum: Christian Schaefer, Postfach 26 04 29, 40097 Düsseldorf, comments@workingdraft.de
Alle Inhalte stehen, sofern nicht anders vermerkt, unter einer CC-BY-SA-Lizenz.
