The application does one - rather complicated - task, with lots of business logic. There was no way we could rewrite it to include it directly into the website code. And because the application comes with its own Javascript and CSS, we decided to use an iframe to embed the application with clean isolation.

The company maintaining that application provided us with a version - running as a Docker container - where they had stripped all extra elements like the navigation, so that it would visually fit within the website. There was however no way for us to customise anything within the application.

iframe security

The promise of an iframe is to keep a clean security boundary between embedding page and embedded content. This means that it is by design not possible to call Javascript across the boundary.

Because injecting iframes could potentially trick a user into submitting data to an attacker (clickjacking), as the iframe may be from a different origin than the main page. Thus, to even render the iframe, the browser checks the Content-Security-Policy (CSP) HTTP header. That header has a field frame-src to control what may be included as an iframe. With this, I allowed the domain of the application to be included in iframes.

Content-Security-Policy: frame-src https://my-embed.com;

But not only does the including page need to allow an iframe. The page to be embedded also needs to allow being included with the frame-ancestors attribute of the CSP header. As we run the application Docker image under our control, I was able to add that header in the proxy that runs before the Docker image:

Content-Security-Policy: frame-ancestors https://my-website.com;

Several things to note:

• If you have other CSP rules, merge them with the rules, nginx will overwrite the header and not add to it
• Both options also support "self" to allow embedding resp. being embedded with the same webserver
• Prior to the CSP becoming a standard, there was an unofficial header X-Frame-Options, which is still supported by browsers
• Content-Security-Policy must be an actual HTTP header, <meta http-equiv=”...”> is ignored for Content-Security-Policy (and also ignored for X-Frame-Options).

Size of the iframe element

Now we get to the weird parts. To prevent multiple scrollbars, we need the iframe element to be exactly big enough for the embedded page. If it is too small, there is an additional scrollbar (or hidden content). If it is too large, there is odd whitespace.

The size of the element needs to be set on the iframe, owned by the parent. The dimensions of the content are however only known by the embedded application. HTML / CSS do not provide any means to let the parent page declare that it wants the iframe to have the “necessary size”.

We ended up with a really convoluted way, which seems the only way to achieve this: sending messages from the child page to the parent. This problem spawned dedicated javascript libraries like iframe-resizer. We ended up reimplementing the logic in the React application, as it was so small that a dedicated library felt like overkill. Following the tutorial at iframe-height (which also has some interesting background on the discussion about iframes in the Whatwg), we came up with this code for the containing website:

// register an event listener for messages
window.addEventListener('message', receiveMessage, false);

// handle a message
function receiveMessage(event) {
    const origin = event.origin || event.originalEvent.origin;
    // we configure the expected domain to allow for this additional sanity check
    if (expectedDomain !== origin) {
      return;
    }
    if (!event.data.request || 'iframeResize' !== event.data.request) {
      return;
    }
    // the id is known in the js class. we need to find the element that needs to be resized
    const iframe = document.getElementById(`iframe-${id}`);
    if (iframe) {
      // pad the height a bit to avoid unnecessary tiny scrolling
      iframe.style.height = (event.data.height + 20) + 'px';
      // width could be handled the same way if necessary - in our case the width is fix
    }
}

Now we need to make the embedded content send a message with its height. The Javascript for that is a bit verbose to allow for different browsers, but not complicated either:

(
    function(document, window) {
      if (undefined === parent || !document.addEventListener) {
        return;
      }
      function init() {
        let owner = null;
        const width = Math.max(document.body.scrollWidth, document.body.offsetWidth, document.documentElement.clientWidth, document.documentElement.scrollWidth, document.documentElement.offsetWidth);
        const height = Math.max(document.body.scrollHeight, document.body.offsetHeight, document.documentElement.clientHeight, document.documentElement.scrollHeight, document.documentElement.offsetHeight);
        if (parent.postMessage) {
          owner = parent;
        } else if (parent.contentWindow && parent.contentWindow.postMessage) {
          owner = parent.contentWindow;
        } else {
          return;
        }
        owner.postMessage({
          'request' : 'iframeResize',
          'width' : width,
          'height' : height
        }, '*');
      }

      if (document.readyState !== 'loading') {
        window.setTimeout(init);
      } else {
        document.addEventListener('DOMContentLoaded', init);
      }
      // this is needed to also adjust the iframe if something (e.g. the Javascript of the application) changes the size of the iframe without an actual page reload.
      const observer = new ResizeObserver(init);
      observer.observe(document.body);
    }
  )(document, window);"

iframes with same origin

If the iframe comes from the same origin (= domain) as the parent page, Javascript can cross the boundary. From parent to child, there is a contentWindow property on the iframe element. From child to parent, there is window.parent. With same origin, those elements expose all things the window usually has. For different origins, they only expose the function postMessage for the secure separation.

Injecting content with Nginx

Remember how I said we can’t modify the application? That still holds true. If we would have loaded both applications from the same domain, we could have had the parent page add a listener inside the iframe to directly update dimensions as needed. But the application contained absolute paths for its assets, so providing it from a subfolder of the same domain would have been tricky and we had to run it on a separate domain.

I ended up injecting the above snippet of Javascript in the Nginx proxy that sits in front of the Docker container:

proxy_set_header Accept-Encoding ""; # make sure we get plain response for substitution to work
...
sub_filter_last_modified on;
sub_filter "</body>" "<script language='javascript'>${script}</script></body>";
sub_filter_once on;
...
proxy_pass https://my-embed.com$request_uri;

Now the embedded iframe communicates its size to the containing page, which adjusts the iframe size accordingly.

(Note that Nginx does not execute these statements in order. The sub_filter instructions apply to the response, wihle proxy_set_header and proxy_pass apply to the request.)

Alternatives

Web Components are a more lightweight solution to combine separate sources into one website. If what you need to integrate is just an element and not a whole application, they might be a better fit. My collegue Falk wrote about Web Components last week.

Bonus: Access control for the iframe content

Because the application is not under our control, we need to manage access to it. We told the supplier of the application to remove access control and simply allow items to be created and edited by ID. Of course, this means that the application must never be directly exposed to the internet, but only reachable through the proxy.

On the embedding side, we track which user is allowed what ids, and have Nginx do a pre-flight check against the website to get the access decision:

# at the beginning of the location for the main request to the embeded application
auth_request /auth;

location /auth {
    # preflight authorization request with symfony
    fastcgi_pass phpfcgi;
    include /usr/local/openresty/nginx/conf/fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /app/public/index.php;
    # forward the original request URI to allow our main application to verify access to the specific resource
    fastcgi_param REQUEST_URI /embed-check$request_uri;
    # body is not forwarded. we have to remove content length separately, otherwise PHP-FPM will wait for the body until the auth request times out.
    fastcgi_pass_request_body off;
    fastcgi_param CONTENT_LENGTH "";
    fastcgi_param CONTENT_TYPE "";
    internal;
}

If the call at /embed-check/... returns a 2xx status, Nginx continues with the request, otherwise it returns the response with the status code to the client, allowing for example to redirect to the login page. In my case, i return an empty response with status 204 if the user is allowed to access the specific resource.

On Symfony side, I use Symfony security to make sure the user is logged in. And then parse the path to know which item in the application the request wants to access, and check if the user has access. This leaks knowledge about the URL design of the embedded application, which is not avoidable for granular access control.

Here are practical techniques to prevent it.

Session Hygiene

Start a fresh session for each task. This is the simplest technique and the easiest to get right. If earlier research is needed, write it into a temporary handoff file and let a new session pick up from there.

Streamline Tool Calling

Every tool call adds tokens to the context. Poorly built tools add a lot of them. To keep the context lean:

• Choose tools and MCPs that are well built and optimize token usage
• Make sure via prompting that the right tools are used from the start

A single bloated tool response can waste more context than an entire conversation turn.

Subagents

Agents can spawn other agents that run in their own context. This isolates work and keeps the parent context clean. It helps most when building large features where individual parts are independent.

The easiest way to use subagents is to prompt something like:

Split the current plan into tasks, use a subagent for each task.

Persistent Tasks

I built an MCP for Claude Code called deliverables-mcp that lets an agent create persistent tasks per codebase. Tasks are stored in .claude/deliverables.jsonl and persist across sessions.

This allows:

• Starting a new session before implementing each task
• Running subagents in parallel based on tasks dependencies
• Restarting a failed task in a clean session

The tool replaces Claude Code's internal tasks and is deliberately called "deliverables" for two reasons:

1. To avoid confusing the agent with two tools both called "tasks"
2. Deliverables are typically larger than just a task, which is a sweet spot for AI agents. Not so small that handoff cost dominates, but small enough that context problems are rare.

You can check out deliverables-mcp on GitHub.

Ein Artikel der Initiator*innen dieses Projekts, veröffentlicht in der neuesten Ausgabe der Revue Médicale Suisse, zieht nun eine erste Bilanz ein Jahr nach der öffentlichen Lancierung.

Ein offizielles Angebot statt fehlerhafter Antworten online

Die medizinische Grundversorgung, ein zentraler Pfeiler eines funktionierenden Gesundheitssystems, steht zunehmend unter Druck, selbst in Städten. Wenn Patient*innen ihre Hausärzt*innen nicht schnell erreichen können, suchen sie oft im Internet nach Antworten. Die Informationen, die sie dort finden, sind jedoch häufig ungenau oder sogar potenziell gefährlich.

In diesem Kontext kann eine gut konzipierte KI-Lösung helfen, die richtige Information zur richtigen Zeit bereitzustellen.

Deshalb haben wir die HUG bei der Entwicklung eines RAG-basierten Chatbots (Retrieval Augmented Generation) unterstützt. ConfIAnce ist nicht der erste Chatbot für Patient*innen. Er unterscheidet sich jedoch durch seine institutionelle Wurzeln, die Nutzung lokal validierter medizinischer Inhalte sowie durch Kontrollmechanismen, die die Zuverlässigkeit der Antworten sicherstellen.

Um Sicherheit zu gewährleisten, integriert das System mehrere Kontrollmechanismen, darunter Matching, Groundedness, Harmfulness, automatisierte Tests und semantisches Routing.

Qualitätssicherung durch Kontrolle des Systems

Eine zentrale Herausforderung besteht darin, die Kontrolle über das System zu behalten. Dafür braucht es geeignete Monitoring-Funktionen.

Automatisierte Tests prüfen sämtliche Antworten des Chatbots auf ihre faktische Übereinstimmung mit der Wissensbasis.

Zusätzlich sorgt ein von Administrator*innen anpassbares Routing dafür, dass Fragen gefiltert und bei Bedarf unter menschlicher Aufsicht weitergeleitet werden. Sie können den Chatbot zudem sofort offline nehmen, falls ein Fehlverhalten vermutet wird.

Themen, über die häufig gefragt wird, aber in den Ausgangsdokumenten noch wenig behandelt werden, werden identifiziert und weiter ausgebaut. So wird die Wissensbasis im Rahmen eines kontinuierlichen Verbesserungsprozesses erweitert.

Selbst das beste Tool bringt nur etwas, wenn es genutzt wird

Damit Patient*innen den Chatbot tatsächlich verwenden, haben die HUG eine öffentliche Informationskampagne gestartet. Ziel war es, das Tool bekannt zu machen und gleichzeitig realistische Erwartungen zu setzen.

ConfIAnce ist kein medizinisches Gerät und ersetzt keinen Arztbesuch. Vielmehr ist er ein Informationsangebot, das Fragen zu den häufigsten chronischen Erkrankungen bei Erwachsenen beantwortet.

Im Februar 2025 ging ConfIAnce in der Beta-Version online. Zwischen Anfang Februar und Ende Oktober 2025 haben 3’823 Nutzer*innen mit dem Chatbot interagiert. Daraus entstanden 5’969 Gespräche und 11’781 Fragen, im Durchschnitt etwa zwei Fragen pro Gespräch.

Die direkt im Chatbot abgegebenen Rückmeldungen sind zu 75 % positiv.

Hohe Akzeptanz für einen etwas anderen Chatbot

Chatbots im Gesundheitsbereich werden von Patient*innen meist gut angenommen, vor allem wegen ihrer ständigen Verfügbarkeit und der einfachen Nutzung. Studien zeigen jedoch auch wiederkehrende Probleme: eine uneinheitliche Qualität der Antworten sowie mangelnde Transparenz bei den verwendeten Quellen.

Genau hier unterscheidet sich ConfIAnce von vielen anderen medizinischen Chatbots.
Der Chatbot wurde entwickelt, um die Beziehung zwischen Patientinnen und Ärzt\innen zu unterstützen, nicht zu ersetzen. ConfIAnce entlastet Ärzt*innen in der Grundversorgung und schafft ihnen mehr Zeit für die menschliche Seite ihres Berufs.

Die Autorinnen des Artikels in der Revue Médicale Suisse betonen zudem, dass der Chatbot, der im spezifischen Kontext der HUG und ihrer Dokumente entwickelt wurde, auch in anderen institutionellen Umgebungen eingesetzt werden kann. Damit ein solches Projekt erfolgreich ist, braucht es zunächst hochwertige Daten, wie sie hier zur Verfügung standen. Darüber hinaus ermöglichen Kontrollmechanismen, automatisierte Tests und Nutzer\innen-Feedback eine kontinuierliche Verbesserung – und sorgen für Sicherheit und Relevanz, die Vertrauen schaffen.

Unsere Reise zur Barrierefreiheit folgte vier Hauptschritten: automatische Scans und Quick-Fixes, Tastaturnavigation, Optimierung für Mobile-Zoom und anschliessend für den Screen-Reader.

Automatische Scans und Quick-Fixes

Wir begannen mit automatisierten Accessibility-Tests mithilfe von Browser-Erweiterungen wie IBM Equal Access Accessibility Checker und axe DevTools. Diese Tools halfen uns, häufige Probleme zu identifizieren: fehlende Labels, unzureichender Farbkontrast, unsauberes semantisches HTML und fehlende ARIA-Attribute. Obwohl automatisierte Scans nur etwa 40% der Accessibility-Probleme erkennen, boten sie eine solide Grundlage für unsere Arbeit.

Tastaturnavigation

Eine korrekte Tastaturnavigation ist grundlegend für die Barrierefreiheit. Sicherzustellen, dass die grundlegende Tab-Navigation in der gesamten App funktioniert, ist relativ einfach. Komplexere Komponenten wie Tabs, Menüs und Modals erfordern jedoch erweiterte Tastaturinteraktionen: Pfeiltasten, Escape-Handling und Fokus-Management gemäss den offiziellen W3C-Richtlinien. Nutzer*innen, die auf Tastaturnavigation angewiesen sind, erwarten diese spezifischen Muster. Wenn davon abgewichen wird, führt das zu Verwirrung und Frustration. Anstatt diese Muster von Grund auf neu zu implementieren, nutzten wir Bits UI, eine Headless-UI-Bibliothek, die diese Accessibility-Richtlinien korrekt umsetzt.

Über einzelne Komponenten hinaus implementierten wir Fokus-Loops und Fokus-Wiederherstellung auf Anwendungsebene, damit Nutzer*innen beim Wechsel zwischen verschiedenen Bereichen der Chat-Oberfläche stets orientiert bleiben.

Optimierung für Mobile-Zoom

Während User-Tests für meinplatz.ch mit Nutzer*innen mit Behinderungen beobachteten wir etwas Auffälliges: Viele navigieren auf Websites auf mobilen Geräten mit 200% oder mehr Zoom und halten ihre Geräte nur etwa 10 cm vor die Augen. Diese Erkenntnis zeigte eine kritische Lücke in den meisten Chatbot-Implementierungen auf.

Die meisten Chatbots verwenden Elemente mit fixer Position: ein Chat-Input am unteren Rand und häufig eine Kopfzeile am oberen Rand. Wenn Nutzer*innen stark hineinzoomen, können fixierte Elemente den gesamten Viewport einnehmen und die Oberfläche unbenutzbar machen. Leider ist es in Browsern nicht möglich, das Zoom-Level zuverlässig zu erkennen. Unsere Lösung: Wir verwenden den Intersection Observer, um zu erkennen, wenn Header oder Footer mehr Platz einnehmen als erwartet. In diesem Fall entfernen wir ihre fixe Positionierung dynamisch, um die Nutzbarkeit wiederherzustellen.

Screen-Reader-Erfahrung

Barrierefreiheit für Screen-Reader entsteht nicht automatisch, sie erfordert sorgfältiges Design. Wir konzentrierten uns darauf, klaren Kontext durch eine saubere Seitenstruktur (Landmarks und Überschriften) bereitzustellen. So verstehen Nutzer*innen jederzeit, wo sie sich befinden und was gerade passiert, und erhalten Shortcuts zu den wichtigsten Bereichen der App.

Kontext bereitstellen

Wir implementierten eine umfassende Outline-Struktur mit Landmarks für die Hauptnavigation, die Einstellungen und die Eingabebereiche. Jede Nachricht enthält korrekte Überschriften und Labels. Zusätzlich haben wir nach dem Chat-Input (am unteren Seitenrand) einen Skip-Link eingefügt, der Nutzer*innen hilft, schnell zum Seitenanfang zurückzukehren.

Herausforderungen mit Web Components

Die Arbeit mit Web Components brachte eigene Herausforderungen mit sich. VoiceOver reagiert besonders empfindlich darauf, wie Bibliotheken implementiert sind. Wir arbeiteten eng mit dem Bits-UI-Team zusammen (das sehr schnell auf Bug-Reports reagierte) und implementierten beispielsweise lokale Portals für Dropdown-Menüs, um Navigationsprobleme mit VoiceOver zu vermeiden.

Umgang mit Ankündigungen

Eine der schwierigsten Herausforderungen war das Management von VoiceOver-Ankündigungen, wenn mehrere Ereignisse gleichzeitig auftraten. Da das Queueing von Ankündigungen nicht zuverlässig funktioniert, haben wir Ereignisse sorgfältig sequenziert und zusammengehörige Ankündigungen zusammengeführt. Wenn Nutzer*innen zum Beispiel „Alle Optionen auswählen“ in einer Liste anklicken, würden normalerweise einzelne Ankündigungen für jede Option ausgelöst und sich gegenseitig überschreiben. Stattdessen brechen wir diese einzelnen Ankündigungen ab und ersetzen sie durch eine einzige klare Meldung, die alles zusammenfasst (alle Elemente ausgewählt oder abgewählt, auf die vordefinierte Auswahl zurückgesetzt usw.).

Da der Chat eine SPA ohne Seiten-Reloads ist, war es zudem wichtig, alle Änderungen anzukündigen, die nur visuell sichtbar sind, zum Beispiel: Wechsel zwischen Light- und Dark-Mode, Sprachwechsel usw.

Chat-Flow für Screen Reader

Wir haben die Chat-Erfahrung speziell für Screen-Reader-Nutzer*innen gestaltet:

• Das Eingabefeld enthält sowohl einen Placeholder als auch ein aria-label mit dem Seitentitel. Dadurch wird beim Laden der Seite Kontext bereitgestellt, da das Eingabefeld automatisch fokussiert wird und Nutzer*innen den initialen Seiteninhalt überspringen.
• Wenn eine Antwort generiert wird, kündigen wir dies klar an und geben damit dasselbe Feedback wie bei einer visuellen Ladeanzeige.
• Sobald eine Antwort bereit ist, wird sie ohne Markdown-Formatierung vorgelesen (kein Kursiv, keine Links usw.), um einen natürlichen Lesefluss zu gewährleisten.
• Nach dem Vorlesen einer Antwort weisen wir darauf hin, dass Nutzer*innen direkt eine weitere Frage stellen oder zu den Optionen der letzten Nachricht navigieren können, um Feedback zu geben oder Referenzen anzusehen. Wir fügen diesen interaktiven Abschnitt der letzten Nachricht dynamisch zur Dokument-Outline hinzu und schaffen damit einen schnellen Navigations-Shortcut.
• Der Chat-Verlauf ist als Artikel mit Labels strukturiert, sodass frühere Konversationen leicht navigierbar sind.

Selbst ausprobieren

Du kannst diese Verbesserungen mit Alva erleben, dem Chatbot der Verwaltung Basel-Stadt. Versuche, mit VoiceOver (MacOS) oder NVA (Windows) zu navigieren, nur deine Tastatur zu verwenden oder auf einem mobilen Gerät stark hineinzuzoomen.

Eine fortlaufende Reise

Unser nächstes Ziel ist es, automatisierte Accessibility-Tests in unsere CI-Pipeline zu integrieren. Wie bereits erwähnt, erkennen automatisierte Scans jedoch nur rund 40 % der Accessibility-Probleme. Das bedeutet, dass wir weiterhin jede neue Funktion sorgfältig planen und manuell testen müssen. Nichts ersetzt menschliches Testen, wenn es um Barrierefreiheit geht. Automatisierte Tools können fehlende Labels oder Kontrastprobleme markieren, aber sie können nicht beurteilen, ob eine Oberfläche tatsächlich für jemanden nutzbar ist, der mit Screen-Reader oder Tastatur navigiert.

Barrierefreiheit ist eine fortlaufende Reise, kein Ziel. Wir setzen uns dafür ein, LiipGPT für alle nutzbar zu machen, und werden unseren Ansatz kontinuierlich auf Basis von Praxisfeedback weiterentwickeln.

Brauchst du Unterstützung bei deiner Accessibility?

Wir bieten Accessibility-Audits an, um Probleme in deinen Anwendungen zu identifizieren und zu beheben. Wenn du die Barrierefreiheit deines Produkts verbessern möchtest, kontaktiere uns, wir helfen gerne weiter.

GovNL: Von Monaten zu Minuten beim Aufbau von Websites

GovNL kombiniert Open-Source-Drupal-Komponenten mit einem offenen Designsystem, um zahlreiche Websites der niederländischen Regierung zugänglich und skalierbar zu betreiben. Die Zeit für den Aufbau neuer Websites reduziert sich dadurch von etwa drei Monaten auf rund zehn Minuten. Beeindruckend, um es gelinde zu sagen. Das ist ein starkes Beispiel dafür, wie Design für Wiederverwendung in grossem Massstab funktionieren kann.

Europäische Kommission: Koordination ist der Schlüssel zur Skalierung

Die Europäische Kommission betreibt bereits 770 Websites und investiert stark in das Drupal-Ökosystem. Besonders aufgefallen ist mir, wie stark der Fokus auf Koordination liegt. Man muss sicherstellen, dass die richtigen Inhalte über den richtigen Kanal innerhalb dieser grossen Website-Landschaft veröffentlicht werden. Open Source Program Offices (OSPOs) wurden eingerichtet, um Open-Source-Strategien sowohl auf Regierungsebene als auch innerhalb von Organisationen voranzutreiben.

Website des Kantons Basel-Stadt und Alva: ein Blueprint für lokale öffentliche Verwaltungen

Kurz vor der Mittagspause war ich an der Reihe, die verschiedenen KI-Use-Cases vorzustellen, die wir für den Kanton Basel-Stadt umgesetzt haben. Der Kanton setzte mit dem Relaunch von bs.ch neue Standards: mit einem nutzerorientierten Design, einem themenbasierten Zugang statt interner Organisationsstruktur und Alva als erstem KI-basierten Chatbot für einen Schweizer Kanton. Der Tech-Stack basiert auf Open-Source-Komponenten, und Liip hat im Rahmen des Relaunches stark zu Open Source beigetragen. Wir verwenden Drupal als CMS, Nuxt/Vue, den blökkli-Editor für das Headless-Frontend und Elasticsearch für die Suche. Die Inhalte werden von einem departementsübergreifenden Redaktionsteam erstellt, das einer klaren Content-Strategie folgt.

KI zur Unterstützung der Öffentlichkeit und der Editor*innen

Der Vortrag war auch eine Gelegenheit, mehr als 18 Monate nach dem Go-Live Zahlen zu teilen. Heute beantwortet Alva über 10 000 Fragen pro Monat, mit durchschnittlich 1,36 Fragen pro Konversation und einem Wachstum von +44 % seit Alva 2.0. Dank API-Integrationen kann der Chatbot Fragen auf Basis von Echtzeitinformationen beantworten. Alva wird stark von internen Mitarbeitenden des Kantons sowie von der Öffentlichkeit genutzt. Der Chatbot zeigt und überprüft stets seine Quellen, was entscheidend ist, um Vertrauen aufzubauen.

Auf der Redaktionsseite arbeitet blökkli intensiv daran, Texte zu vereinfachen. Mit dem blökkli-Editor und integrierter KI können Editor*innen nun Lesbarkeitsanalysen durchführen, vorgeschlagene Vereinfachungen nebeneinander sehen und diese übernehmen oder anpassen. Alva und die KI-Funktionen auf bs.ch werden kontinuierlich weiterentwickelt, um Editor*innen und Bürger*innen vertrauenswürdige KI-Technologien bereitzustellen.

KI-gestützte Technologien in der französischen Regierung

Ein weiterer inspirierender Vortrag zeigte Use-Cases von KI auf der Plattform Services Publics+ der französischen Regierung. Mit über 140 000 geteilten Erfahrungen und mehr als einer Million Reaktionen nutzt das System KI-gestützte Technologien, um staatlichen Stellen dabei zu helfen, Feedback an Bürger*innen zu geben. Dazu gehören Speech-to-Text und Echtzeit-Zusammenfassungen als zentrale Technologien. C’est magnifique!

Die EU vertraut Open Source mehr denn je

Die Europäische Union hat den Website Evidence Collector eingeführt – ein Open-Source-Tool, das Websites auf Sicherheitsprobleme überprüft. Bemerkenswert ist, dass das Projekt unter der EUPL (European Union Public Licence) veröffentlicht wurde. Diese betont die Interoperabilität zwischen Ländern und Lizenzen und unterstützt mehrsprachige Zusammenarbeit. Ich frage mich, ob es in der Schweiz etwas Ähnliches gibt.

Mit Interoperable Europe bietet die EU ausserdem ein neues Portal mit einem hilfreichen Licensing Assistant. Damit kannst du Softwarelizenzen finden und vergleichen sowie mit einem Kompatibilitäts-Checker prüfen, ob verschiedene Open-Source-Lizenzen kombiniert werden können und ob rechtliche Komplikationen entstehen könnten.

Open Source zu nutzen reicht nicht - wir brauchen Champions

Zum Abschluss betonte Tiffany Farris von der Strategieberatung Palantir.net (nicht zu verwechseln mit Palantir Technologies), dass die Nutzung von Open Source gut ist, aber nicht ausreicht. Organisationen brauchen Champions, die Beiträge zur Community und die Gesundheit des Ökosystems aktiv vorantreiben. Design für Wiederverwendung sollte ein zentrales Prinzip sein. Aus US-Perspektive ist Beschaffung (Procurement) ein grosses Problem: Die Nutzung von Open Source wächst, aber Unterstützungsmechanismen oft nicht. Wenn Open Source als „kostenlos“ betrachtet wird, kann das dazu führen, dass Aufträge an Anbieter gehen, die ihre Arbeit zwar als Open Source vermarkten, aber kein nachhaltiges Ökosystem unterstützen. Sie schlug konkrete Anpassungen der öffentlichen Beschaffung im Sinne von „Public Money, Public Code“ vor, um das Ökosystem besser zu unterstützen. Ein wirklich inspirierender Abschluss für einen intensiven Tag voller Lernen und Austausch.

Wenn du tiefer in die Inhalte eintauchen möchtest, kannst du dir die Playlist der Präsentationen von Drupal4Gov EU 2026 ansehen.

We created a fully themeable chat UI that can be embedded in any website and has no effect on the parent page. Kanton Basel-Stadts Alva and RAMMS' Rocky AI are instances of that UI.

This blog post will show you what we learned about creating web components that do not influence the parent page. Here are the good, the bad and the ugly when working with web components.

The Good

These are the good parts of web components. They will lay the foundation for why you might use them.

Portability

Every system that can handle HTML can handle web components. A simple tag and a script will integrate it into any web framework. It doesn't even need to be a JavaScript framework.

<body>
  <your-webcomponent></your-webcomponent>
  <script src="path/to/your-webcomponent.js"></script>
</body>

Native Feel

IFrames are another way to embed UI into a page, and they are arguably easier to use. But the main difference is that web components feel more native to the page, since they directly integrate into the parent page's layout. This means you can use transparency, intrinsic sizing (size based on the web component's contents), and seamless event communication with the parent page.

Slots

With slots you can provide content that will be added at a specified point inside your web component.

In our chat UI, we used a slot to let integrators provide a custom loading spinner. This spinner needs to be visible immediately, before the full theme loads asynchronously.

Shadow DOM - Isolating Styles

A robust way to ensure that your styles do not affect the parent page is to use the Shadow DOM. Shadow DOM is a web component feature to add a boundary for styles. Styles applied inside the Shadow DOM never apply to the parent page.

Caveat: Inheritable CSS Properties

There is one exception to the isolation where CSS properties of the parent page apply to the web component.

These are the properties that pierce through the boundary:

• Inheritable CSS properties like color, font-family, line-height
• CSS custom properties like --my-var

In practice, we have found it helps to fully specify the common properties like fonts and color on every element. That way you will never be surprised by different styles on integration.

Vite

For bundling web components, we can highly recommend Vite. There are a lot of neat tricks you can apply while bundling. Here are the Vite features we used for our web component.

Inlining Assets

Vite's explicit inline handling feature allowed us to inline our external CSS files into the JS bundle.

import cssContentString from "./index.css?inline";

This feature will not only inline the raw content of the imported index.css. It will also resolve all CSS imports, apply PostCSS transforms, and even work with CSS preprocessors like SASS. While inlined CSS is not the most efficient for browsers to render, the benefit is that we can ship a single JS file.

Library Mode

The Vite library mode provides you with fine-grained control of how the bundle should behave. To enable the library mode just add the build.lib option in your Vite config.

The Bad

Not everything about web components is great though. Here are the bad parts.

SSR - Hard to Get Working

Server-side rendering will almost certainly not work. The rest of the page can still be rendered server-side, but the web component will only show up as a <your-webcomponent></your-webcomponent> tag. Its contents will only be rendered in the browser.

There is one experimental package by Lit Labs that tries to solve this, but we never tried it.

Tailwind - Not a Great Fit

Tailwind feels like a natural choice for web components, but it does not play well with them.

The core issue is twofold. First, Tailwind ships its own CSS reset (called Preflight), which overrides default browser styles. When injected into a page that does not use Tailwind, it potentially breaks the page. Shadow DOM could isolate this reset, but Tailwind is fundamentally not designed to work inside a Shadow DOM. Here is the discussion if you are interested.

There are some hacky workarounds, but we tried them and had no success getting them to work reliably.

Our recommendation is to only use Tailwind if you are guaranteed that the parent page also uses it, and then use web components without Shadow DOM.

The Ugly

Verbose Web Components API

The native web component API is verbose and hard to read. A simple counter component, for example, requires manually defining a class, attaching a shadow root, setting up innerHTML, and wiring event listeners in connectedCallback. This boilerplate adds up quickly. You can see examples of the API here.

Fortunately, web components make for a great compile target. Svelte and Vue directly support compiling to web components. React is a bit trickier, but totally doable as well. We used this approach for our chat UI, where the first iteration was built with React and the current one with Svelte.

Weird Quirks

Advanced web component features come with edge cases that no documentation warns you about. Even Svelte, which has excellent web component support, ships with a notable list of caveats.

We even hit an undocumented edge case with slots in Svelte: the bundle script must load after the component markup, or slotted content will not render. An ugly wrapper for slots fixes the problem, but quirks like this add up and slow you down.

Font Loading - Not Working Inside Shadow DOM

When authoring web components, you get into the habit of defining all stylesheet links etc. in the web component body. As you should, so they do not affect the parent page. But there is another annoying detail here: @font-face will not work when defined in the Shadow DOM. If your web component needs a custom font, you need to inject the font CSS into the parent page to make it work.

Conclusion

I do not want to end on this ugly note though. I really think there are cases where web components are the right choice, and in our case we would choose Svelte & web components again.

To help you get started, here is a Svelte starter template.

The City of Zurich publishes over 900 datasets as open data, spread across six different APIs. There's CKAN for the main data catalog, a WFS Geoportal for geodata, the Paris API for parliamentary information from the Gemeinderat, a tourism API, SPARQL linked data, and ParkenDD for real-time parking data. All public, all freely available. But until now, making an AI assistant actually use these APIs meant writing custom integrations for each one.

The MCP server wraps all six APIs into 20 tools that any MCP-compatible AI assistant can call directly. Ask "How warm is it in Zurich right now?" and it queries the live weather stations. Ask about parking availability, and it pulls real-time data from 36 parking garages. It also covers parliamentary motions, tourism recommendations, SQL queries on the data store, and GeoJSON features for school locations, playgrounds, or climate data. All through a single, standardized Model Context Protocol interface.

Hayal Oezkan built it in Python using FastMCP. One file for the server with all 20 tool handlers. The repo is on GitHub.

Deploying it on our side took very little effort. The server supports both stdio transport for local use (like in Claude Desktop or Claude Code) and SSE and HTTP Streaming for remote deployment. I packaged it with Docker, deployed it to our cluster, and now it's available as a remote MCP server that anyone can add to their AI tools without installing anything locally.

The natural next step was integrating this with ZüriCityGPT. It happened, just not quite in the direction I originally had in mind.

ZüriCityGPT already had its own MCP server at zuericitygpt.ch/mcp, exposing tools for searching the city's website content, "Stadtratsbeschlüsse" and looking up waste collection schedules. Instead of wiring the open data tools into ZüriCityGPT, I went the other way: the open data MCP server now proxies tools from the ZüriCityGPT MCP server. A lightweight proxy client connects to the remote server via streamable-http and forwards calls. The whole thing is about 40 lines of Python.

So now, when you connect to the Zurich Open Data MCP server, you get 23 tools in one place. The 21 original open data tools across six APIs, plus zurich_search for querying the city's knowledge base and zurich_waste_collection for waste pickup schedules (based on the OpenERZ API). One MCP endpoint, many services behind it.

A city employee builds something useful in the open, publishes the code, and within a day it's deployed and available to a wider audience. Open data and open source working together, exactly as intended.

Im Zentrum des Relaunchs steht die Nutzerzentrierung. Statt der Innenperspektive soll eine themenzentrierte Struktur entstehen – wie sie beispielsweise der Kanton Basel-Stadt (mehr zum Projekt hier) bereits erfolgreich etabliert hat.

Das Vorhaben aus Content-Sicht? Ein Mammut-Projekt.

Was braucht es für ein Content-Projekt dieser Grösse?

Organisch gewachsene Inhalte können nicht einfach migriert werden. Ein Relaunch ist meist der Moment, in dem Content nicht nur übertragen, sondern qualitativ neu gedacht wird.

Da dabei ein grosses Volumen an Content überarbeitet werden muss, braucht es ein dezentrales Redaktionsmodell. Zahlreiche Mitarbeitende – oft ohne vertiefte Content-Erfahrung – sind involviert. Gute Prozesse, klare Rollen und gezielte Unterstützung sind daher essenziell:

• Eine entscheidungsfreudige Projektleitung
• Eine solide Bestandesaufnahme
• Konzept und Strategie
• Governance (Prozesse & Verantwortlichkeiten)
• Aufbau und Schulung der Webredaktion
• Operative Content-Produktion
• Qualitätssicherung

Liip darf den Kanton Graubünden auf dieser Reise begleiten. Auf Basis unserer Erfahrungen aus den Projekten in Basel-Stadt, Solothurn und verschiedenen Bundesämtern ist eine vertrauensvolle, effiziente Zusammenarbeit entstanden.

Wie wir zusammenarbeiten

Zwei Content-Strateginnen von Liip arbeiten eng mit der Projektleitung des Kantons zusammen. Die Projektleitung bringt internes Know-how und Entscheidungsstärke ein, Liip ergänzt operative Kapazität und viel Erfahrung aus ähnlichen Settings. Dieses Setup ermöglicht hohe Geschwindigkeit – und eine saubere Verzahnung von internem Wissen und externem Input.

Die Zusammenarbeit erstreckt sich über mehr als 1,5 Jahre.

Was sind die konkreten Lieferobjekte?

• Content Audit
• Content Strategie & Tonalität
• Content Governance & Redaktionsmodell (für die Projektphase und für den Betrieb danach)
• Content Lifecycle Modell
• Content Guidelines für die Redaktion
• Seitentypen & Beispieltexte (in Zusammenarbeit mit dem Design-Team)
• Wordvorlagen für die Erstellung der Texte
• Schulungen & Support der Redaktionsmitglieder
• KI-basiertes Schreibtool «GR-Editor» (basierend auf TextMate)
• Qualitätssicherung

Was bedeutet das im Detail? Vom Audit bis zur Qualitätssicherung

Ein Relaunch mit über 120 involvierten Redaktor*innen und Tausenden Seiten Content braucht vor allem eines: einen klaren Plan für die Umsetzung und gute Vorbereitung. Jeder Schritt baut auf dem vorherigen auf:

1. Content Audit – Klarheit schaffen

Gestartet sind wir in das Projekt mit der Analyse einer repräsentativen Auswahl bestehender Inhalte. Der Audit half bei der Identifizierung von Optimierungspotenzialen und bildete das Fundament für alle weiteren Entscheidungen.

2. Das Redaktionsmodell – Rollen, Verantwortlichkeiten und Prozesse

Die Content Governance und das entwickelte Redaktionsmodell haben einen grossen Teil der «Theorie» gelegt, auf der die operativen Arbeiten mit der Webredaktion dann aufgebaut wurden. Wir haben dabei ein Modell für das Projekt entworfen, ergänzt um einen Plan für nach dem Relaunch.

3. Content Strategie & Tonalität – die Leitlinie

Die Governance regelt Zusammenarbeit und Prozesse – die Content Strategie definiert die inhaltliche Ausrichtung. Sie richtet sich dabei weniger an die künftigen Redaktor*innen, sondern bildet die konzeptionelle und inhaltliche Grundlage für die operativen Elemente. Ergänzt wurden zwei Tonalitäten für den neuen Webauftritt.

Mit abgeschlossener Strategie begann die operative Phase.

4. Seitentypen & Beispieltexte – das Konzept wird konkret

Gemeinsam mit dem Designteam entwickelten wir die neuen Seitentypen. Unsere UX Writerin entwarf erste realistische Seiten, die als Referenz für die Finalisierung der Seitentypen dienten.

Arbeiten mit echten Texten ist entscheidend: Nur so lassen sich Struktur, Inhalt und Design sinnvoll aufeinander abstimmen.

Auch für die Schulung der Redaktor*innen sind die konkreten Text- und Seitenbeispiele wichtig.

5. Content Guidelines – das Handbuch für Redaktionsmitglieder

Abgeleitet von der Content Strategie bündeln die Content Guidelines Regeln, Empfehlungen, Beispiele und konkrete Anleitungen – für verständliche, barrierefreie und konsistente Inhalte.

6. Wordvorlagen – weil das CMS parallel erst entsteht

Da CMS-Entwicklung und Content-Entwicklung parallel laufen, müssen die Texte ausserhalb des CMS entstehen. Dafür erstellten wir Wordvorlagen, die:

• die neue Seitenstruktur abbilden,
• alle relevanten Meta-Informationen integrieren,
• Hinweise für Redaktor*innen enthalten.

Die Wordvorlagen wurden um Visualisierungen der einzelnen Seitentypen ergänzt. Dabei wurde ein reales Textbeispiel pro Seitentyp in Figma gesetzt und mit den Redaktor*innen als PDF geteilt.

7. KI-Schreibtool «GR-Editor» – Unterstützung in Echtzeit

Ein dezentrales Redaktionsmodell führt zwangsläufig zu variierender Textqualität. Der GR-Editor (basierend auf TextMate) wirkt dem entgegen. Er prüft Verständlichkeit, Konsistenz und Tonalität direkt beim Schreiben.

Der Kanton hatte ideale Voraussetzungen: bestehende kantonale Schreibvorgaben, die neuen Content Guidelines und die zwei definierten Tonalitäten.

8. Aufbau der Redaktionen & Schulungen

Zunächst wurden die Redaktionen zusammengestellt, passend zur neuen Website-Struktur: einem Themen- und einem Organisationsteil.

Für den Thementeil entstanden Themenredaktionen mit je einer Koordinator*in. Sie funktionieren als Schnittstelle zwischen den Redaktionen und der Projektleitung. Die Supportorganisation (Projektleitung + Liip) begleitet die Teams.

Die Schulungen waren der erste praktische Einstieg. Vorgestellt wurden die neuen Seitentypen, die Guidelines und der GR-Editor.

9. Redaktionssupport – Begleitung im Alltag

Die inhaltlichen Arbeiten laufen derzeit. Die Supportorganisation organisiert regelmässige Redaktionssitzungen, beantwortet Fragen und erarbeitet Lösungen. Jede Themenredaktion erhält individuelles Sparring zu ersten Texten.

10. Qualitätssicherung – bevor der Inhalt live geht

Bei dieser Menge an Inhalten ist Eigenverantwortung zentral. Die Redaktor*innen erhalten Checklisten, mit denen sie ihre Texte selbst prüfen können. Strategisch ausgewählte Inhalte erhalten spezifisches Feedback.

Auch der GR-Editor trägt wesentlich zur Qualitätssicherung bei.

Erste Learnings aus dem Projekt

Ein Relaunch dieser Grösse strapaziert alle Beteiligten. Ein dezentrales Redaktionsmodell ist unvermeidlich. Verständnis für die Situation der Redaktionsmitglieder, Flexibilität bei der Umsetzung der Planung und pragmatische Lösungen unterwegs sind zentrale Zutaten für ein konstruktives Miteinander.

Was bedeutet das konkret? Einige Beispiele:

• «Der Ton macht die Musik». Sich mit Respekt begegnen, offene Punkte benennen, Probleme ernst nehmen, Mitgestaltung zulassen.
• Den Redaktionen Gestaltungsspielraum für ihr Timing geben – innerhalb des übergeordneten Projektzeitplans.
• Tools flexibel einsetzen (z. B. Excel statt Miro, wenn es besser passt).

Die Arbeit mit realen Textbeispielen in der Entwicklung der Seitentypen hat sich klar als wichtige Entscheidung erwiesen. Bei so vielen Beteiligten braucht es reife Vorlagen und klare Referenzen – um Qualität, Konsistenz und Tempo sicherzustellen. Auch die Visualisierungen der Seitentypen haben einen zentralen Stellenwert. Gerade für Menschen, die stark über das Visuelle funktionieren, ist das Texten in den Wordvorlagen ohne Vorschau des Frontends eine Herausforderung. Die Visualisierungen dienen immerhin als allgemeiner Referenzwert.

Externe Expert*innen können Spitzen brechen und in Diskussionen einen externen Blick beisteuern. Darüber hinaus ist es schön zu sehen, wie ein gemeinsames Team über Organisationsgrenzen hinaus entstehen kann - gemeinsam im Sinn der Sache.

..und genau in diesem Sinne freuen wir uns auf die nächsten, abschliessenden Prozessschritte. Und auf ein spannendes Jahr für den Relaunch :)

The Bias Problem

The problem is bias. If you know that Response A comes from the expensive model and Response B from the cheaper one, you'll unconsciously read them differently. The idea behind our solution is borrowed from classic A/B testing: show two variants to evaluators without telling them which is which, and let the results speak. For RAG chatbots, the question isn't "which model is generally better?" It's "which configuration produces better answers for this specific knowledge base and these specific users?" That requires comparing pre-generated answers, not live model outputs.

Side by Side, Let's Evaluate

So we built Arena mode into the Admin UI. It works like this: you start by running your evaluation set against two different configurations. Maybe you're testing a new system prompt, or switching embedding models, or trying a different retrieval strategy. Each run produces answers for every question in the set. Then you create a comparison, selecting those two runs.

When an evaluator opens the comparison, they see one question at a time. Two answers, labeled A and B. No model names, no hints. The order is shuffled differently for each evaluator using a seeded randomization, so if Alice sees the Claude answer as "A" for question 3, Bob might see it as "B". This prevents evaluators from developing patterns like "A is always the better one."

For each answer, you rate it as Good, Neutral, or Bad. You can add a comment explaining why, which turns out to be incredibly valuable. The quantitative scores tell you which model wins, but the comments tell you why, and often reveal issues you wouldn't catch with automated evaluation.

More Feedback the Merrier

Multiple evaluators can rate the same comparison independently. Getting people involved is easy: share links generate a temporary API key, so you can send a URL to a colleague or a client and they can evaluate in a protected area without needing an admin account. They just enter their name and start rating.

Understand the Results

The results page shows a leaderboard: average score, win rate per model, and a breakdown per evaluator. That last part is where it gets interesting: it surfaces inter-annotator agreement, a standard measure of how much evaluators align in their ratings.

• High agreement: the quality difference is clear and you can act on the result with confidence.
• Low agreement: the two configurations are close enough that the choice may come down to other factors like cost or latency.

You can also drill into individual comments grouped by model, and export everything to Excel for reporting.

Calibrating AI with Human Truth

Building this was a good reminder that evaluation tooling is never "done." Christian recently wrote about using Claude Agent SDK to analyze chatbot answers automatically, which is the other side of the coin: scaling evaluation with AI. Arena mode complements that by providing the human ground truth that automated evaluation needs to calibrate against.

We're using Arena now whenever we make significant changes to a chatbot's configuration. The signal-to-noise ratio is much better than staring at spreadsheets of automated scores. The feature is available in the Admin UI for any organization that uses our evaluation sets.

The Next Steps of the Arena

We're considering adding support for more than two models in a single comparison, and possibly integrating the Arena ratings as ground truth labels for training better LLM-as-a-Judge prompts. For now, blind human evaluation with a simple Good/Neutral/Bad rating scheme gives us exactly what we need: honest answers about which configuration actually works better.

We already had an MCP server running on ZüriCityGPT and other LiipGPT deployments. Tools like knowledge base search, public transport timetables, and waste collection schedules were available to any MCP client, Claude Desktop, Cursor, or custom integrations. The tool definitions, schemas, and execution logic were all there. WebMCP just needed a bridge to bring them into the browser.

The implementation turned out to be surprisingly straightforward. When the page loads, a small script checks if navigator.modelContext exists. If it does, it fetches the available tools from our existing MCP endpoint using a standard JSON-RPC tools/list request and registers each one with navigator.modelContext.registerTool(). When an AI agent calls a tool, the execute handler sends a tools/call request back to the same endpoint. The entire client-side code is about 30 lines of vanilla JavaScript.

navigator.modelContext.registerTool({
  name: tool.name,
  description: tool.description,
  inputSchema: tool.inputSchema,
  execute: function(params) {
    return fetch(mcpUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        jsonrpc: '2.0',
        method: 'tools/call',
        params: { name: tool.name, arguments: params }
      })
    }).then(r => r.json()).then(d => d.result);
  }
});

The beauty is that the tool set is dynamic and per site setup. ZüriCityGPT exposes search with a special mode for city council resolutions (Stadtratsbeschlüsse, see also StrbGPT), waste collection lookups via the OpenERZ API, and Swiss public transport departures. A different LiipGPT deployment would expose its own set of tools. The backend decides what's available, the browser just registers whatever comes back.

One thing worth noting: navigator.modelContext is behind a flag in Chrome Canary (chrome://flags/#enable-webmcp-testing) and not available in any stable browser yet. The script uses feature detection, so nothing happens in unsupported browsers.

To actually test it, you need Chrome Canary and the Model Context Tool Inspector extension (which requires a Gemini API key to do anything useful with the tools). But the registration itself works, and seeing "search", "get_waste_collection", and "get_timetable_info" show up in the inspector when visiting a chatbot page is a nice confirmation that everything clicks together.

Now, ZüriCityGPT is a page with essentially one big input field. It's already a chatbot. An AI agent visiting the site could just type into that field. Exposing structured tools on a page that is itself a tool feels a little redundant. But it does open up genuinely new possibilities. A browser agent could search the knowledge base, check the next tram departure, and look up waste collection dates in parallel, without ever touching the chat UI, and combine the results with data from other sites. The chatbot answers questions one at a time. WebMCP lets agents compose capabilities.

Is this useful today? Not really. No stable browser supports it, and the user base of Chrome Canary with experimental flags enabled is, let's say, select. Google and Microsoft are pushing it through the W3C, and formal browser support is expected by mid-to-late 2026. When that happens, any AI agent visiting ZüriCityGPT will automatically discover what it can do, no documentation reading and UI guessing required.

The interesting part is the convergence. We now have the same tool definitions serving three purposes: LangChain tools for the chatbot's own RAG pipeline, an MCP server for "traditional" AI clients, and WebMCP for browser agents. One set of schemas, three integration points. Adding a new tool to any LiipGPT site automatically makes it available everywhere.

If you want to try it yourself, visit zuericitygpt.ch with Chrome Canary, enable the WebMCP flag, and install the Model Context Tool Inspector extension. You'll see the three registered tools and can ask Gemini when your next paper collection is. Or just type the question into the chatbot, that still works too.