Working Draft

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. 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) 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 Ninas LinkedIn-Profil mit Hinweisen auf Vorträge, Webinare und Beiträge rund um digitale Barrierefreiheit. MLBF Projekt und Informationsangebot rund um Meldungen und Beschwerden zu mangelnder Barrierefreiheit von Marcus Herrmann. BARRIEREN-GUTACHTEN Portal zur Meldung und Dokumentation von Barrieren, insbesondere im öffentlichen Bereich von Casey Kreer & Mitstreiter:innen. IAAP D-A-CH Fachverband für digitale Barrierefreiheit im deutschsprachigen Raum mit Webinaren und Veranstaltungen. ACCESSIBILITY CLUB Niedrigschwellige Community-Treffen für Menschen, die sich mit digitaler Barrierefreiheit beschäftigen oder einsteigen möchten.

In dieser Folge sprechen wir mit Daniel Fau (CEO der TYPO3 GmbH) über den aktuellen Stand des Government Site Builder (GSB). 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 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 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.

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. 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 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 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 & ARIADETAILSELEMENTS (DOM) 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) 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 & 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 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. [00:50:31] CSS SPEECH & AUDIO-DESIGN 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. [01:05:11] BRAILLE-PROPERTIES 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. [01:15:15] ARIA-COLCOUNT, ARIA-COLINDEX & TABELLEN 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. [01:23:01] ARIA-MULTISELECTABLE 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. LINKS A-TAG WIEN 2026 Accessibility-Konferenz in Wien, Anmeldung ab 1. Februar. ARIA ACTIONS Vorschlag für ein neues Pattern, um sekundäre Aktionen besser zugänglich zu machen. CORE ACCESSIBILITY API MAPPING Spezifikation zum Mapping von ARIA auf Betriebssystem-APIs. ARIA-ISSUES ZU PLACEHOLDER, DETAILS & CO. Diskussionen rund um mehrere der besprochenen Attribute. HTML-SUPPORT IN SCREENREADERN Überblick zu tatsächlicher Unterstützung von HTML-Features. DEPRECATION-DISKUSSION ZU ARIA-ERRORMESSAGE Einblick in die Debatte innerhalb der ARIA Working Group. LÉONIE WATSON: CSS SPEECH Vortrag zur Motivation und Einordnung von CSS Speech. JAWS SOUND SCHEMES Beispiel für nutzerseitig konfigurierbares Audio-Feedback. PRONUNCIATION TASK FORCE „Gegenseite“ im Diskurs um Aussprache und Audio-Kontrolle. LEONIE WATSON: ADDRESSING CONCERNS ABOUT CSS SPEECH Einordnung der Kritikpunkte und Gegenargumente. VASILIS VAN GEMERT: EXCLUSIVE DESIGN Talk mit spannenden Audio- und Nicht-visuellen Design-Experimenten. WAI-ARIA AUTHORING PRACTICES: LISTBOX Referenzmuster für interaktive (auch multiselect-fähige) Listen.

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. SCHAUNOTIZEN [00:01:08] DIE SANITIZER API 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. LINKS REVISION 447: XSS UND DIE HTML SANITIZER API 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. REVISION 452: CORS, CORP, (C)ORB, COOP UND COEP Eine weitere Folge mit Security-Fokus, nämlich zu diversen sicherheitsrelevanten HTTP-Headern, ebenfalls mit Frederik. REVISION 514: ASTS, LINTER UND SECURITY MIT FREDERIK BRAUN In dieser Revision reden sprechen wir mit Frederik über Abstract Syntax Trees, Lexer und Parser. Und natürlich Security! DOM CLOBBERING Angriffstechnik, bei der HTML-IDs oder Names bestehende JavaScript-Objekte überschreiben und so Logikfehler oder Sicherheitslücken auslösen. Höre dazu auch Revision 202: Sicherheitslücken – DOM Clobbering, XSS via CSS, ES6 Fallen. INTEROP-PROJEKT Browser-übergreifende Initiative zur Angleichung von Web-Plattform-Features, potenziell relevant für Trusted Types in zukünftigen Iterationen.

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. [00:53:22] ANSELMS AKTUELLES TECHNISCHES INTERESSE Schnelle AI-Modelle, LLMs lokal laufen lassen, Accessibility AI und wann funktioniert AI für Coding. LINKS HOW FARMING SAVED ME FROM DEVELOPER BURNOUT 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.

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)!