At the end of 2022, I first saw ChatGPT in a video on TikTok and tried it immediately. It was able to explain Contents to me faster than my teachers, solve tasks better than if I did them myself, and even develop ideas I would never have come up with. That really fascinated me.

But it wasn't until I started my apprenticeship that I realized just how powerful and important AI really is. Today, I use it daily. Not to do my work for me, but to teach myself new things, research more effectively, and work more efficiently on certain tasks.

My apprenticeship is diverse. That's exactly what makes it exciting

I'm completing an apprenticeship as a Digital Business Developer EFZ. I'm currently in my second year. After the first year at Bbc Basislehrjahr, I've been working at Liip since summer 2025.

What I find particularly exciting about this apprenticeship is that I have many different tasks. I work in various Circles, self-organized teams based on holacracy. This way, I get to know many different perspectives, tasks, and people.

I started in the Finance Circle, which focused more on data management. Since then, I've had the opportunity to look into various other teams and get to know different tasks, perspectives, and ways of working. Today, I work in the Content and Design Circle with a focus on process optimization, automation, and AI. I'll also get to know several other Circles, tasks, and roles throughout my apprenticeship.

This variety suits me well. I like working in a structured way, communicate actively, and find it exciting to analyze and improve workflows. At Liip, I have the privileged opportunity to take on responsibility early in my apprenticeship. I work on impactful internal and external projects, make decisions, and contribute my own ideas. For me, this strongly distinguishes Liip from many other employers offering apprenticeships.

Dealing with clients is part of it

One part of my apprenticeship that might be less visible from the outside is dealing with clients. I learn to communicate professionally, represent my own company well, and understand important factors for good collaboration. This means, for example, clearly communicating information within the team, gathering requirements, and communicating in a structured way in projects. Because I participate in real projects early on as an apprentice, I develop a good sense of what really matters to clients.

How I use AI specifically

AI becomes particularly helpful when I provide a lot of context. Then, a general tool becomes a valuable sparring partner. AI supports me especially when I have a clear goal and need a good first draft quickly. I use it for brainstorming, to understand new terms, for research, or to structure texts.

• Fun fact on the side: This blog post was also partially structured with AI. I gathered my thoughts, explained the context, and then got help creating a meaningful structure. This is how I use AI in everyday life.

A good example is the manual for the LiipGPT backend that I wrote. At the beginning, I had practically no experience writing manuals. So I first taught myself the basics with the help of AI. Then I gave the AI as much context as possible and developed a draft step by step with it. In the end, a handbook was created that is often used internally and individually expanded for clients. For me, this was a moment when I realized how much added value AI can bring, because I could not only work faster and without experience, but also create a result that really helps others in their everyday work.

I don't use these tools thoughtlessly. I test them, compare them, and carefully consider which use cases they really make sense for.

AI is my best learning buddy

AI has great potential for learning. It simplifies content, provides examples, and adapts to my level. No textbook can do that. Getting started with a topic becomes faster this way. As an apprentice, I ask the AI questions and follow-up questions that I wouldn't dare to ask in class.

At the same time, however: AI must never replace your own thinking. Those who don't understand how AI works and how it can be used will end up learning very little.

For me, openness and critical questioning are part of dealing with new tools. AI can empower learners, but only if it's consciously used as a tool. That's why it's important for apprentices to engage with AI during their apprenticeship. Not later, when everyone else has long been a routine user.

How do you use AI?

Perhaps it's worth pausing briefly after this Blogpost and thinking about your own use of AI. How do you really use AI in your everyday life today? What concrete added value does it bring you? Is it just a tool you try out occasionally? Or do you use it consciously to work better, faster, or more structured?

At Liip, I directly experience how an organization doesn't just use AI, but actively shapes it:

• Regular knowledge exchanges and Liip Talks about AI, from new models to ethical questions.
• AI training for all employees. Internally, we offer workshops and special modules so everyone stays confident in using AI.
• Development and further development of our own AI tools like LiipGPT, which is already in use with clients from healthcare, legal, and public sectors.
• AI Sustainability Guidelines, an internal framework that ensures AI projects are implemented ethically and sustainably.

This shows me what an organization can look like that doesn't blindly deploy AI, but takes responsibility for it.

How do employees in your company use AI? Are there clear rules or offerings to use AI meaningfully? Where could AI specifically support you in your role if you used it more deliberately?

AI is not a fixed concept that works the same for everyone. But those who use it early quickly realize: The question is not whether you still need an apprenticeship, but how much more you get out of it when you have AI.

Museum für Gestaltung: a masterpiece in Public Value and User Experience

The new website of the Museum für Gestaltung Zürich serves as the central hub for the museum's digital communication and offers visitors the opportunity to connect with the museum. In co-creation, we crafted a solution that allows the design to speak for itself and delivers real public value. The BOSW jury agreed, awarding the new site the Silver prize in both the User Experience and Public Value categories.

More on the winning project

As Clelia Kanai, head of Marketing & Communication, points out “For us, design means clarity and responsibility – even in the digital realm. In Liip, we had a partner who shared and upheld this ethos, from the initial concept right through to the final accessibility check. The fact that this resulted in a project which the BOSW jury has awarded silver in the User Experience and Public Value categories is both a validation and a wonderful recognition for us.”

so.ch: transparency, accessibility and user-friendliness to strengthen the trust of the public

We developed a new website for the canton of Solothurn, so.ch. It creates genuine public value by making cantonal services transparent, accessible and easy to understand, thereby strengthening the trust of the public, local authorities and the business community in public services. As bs.ch showed us last year, a user-centred website is crucial for improving the lives of citizens who increasingly need to find their public info and documents online. The jury recognised the quality of its user experience by awarding us Bronze in this key category.

More on the winning project

Even though we haven’t won as many awards as we’d have liked (and we, of course, think we deserve), it was interesting to feel the pulse of the web industry. We sincerely congratulate "Swissgrid 24/7" on being named the Master of Swiss Web 26. See you next year!

In light of recent political developments, a “do-talk gap” has been pointed out in sustainability efforts. Zurich Climate Week proves differently: taking action on the climate crisis and talking about it.

And that’s exactly what we need right now. Because sustainable transformation doesn’t happen in silence. It happens where different perspectives and commitments come together: business, policy, academia, and civil society. Where knowledge is shared. Where solutions are developed and scaled together.

Why we’re getting involved

At Liip, we decided to contribute to the Zurich Climate Week programme for several reasons:

• To support the initiative by actively contributing to the programme
• To strengthen our commitment to sustainability beyond the Climate Week
• And not least: to share our experiences, learn from others, and grow our network of like-minded people

Our contribution to Climate Week—just like the 2 focus areas we’ve chosen for our events—is guided by one principle: taking responsibility.

Our contribution

Liip is part of the programme with 2 formats—both focused on exchange, practical insights, and real-world applicability.

Hacking for Sustainable AI

More info & registration

Artificial intelligence has long become part of our everyday lives. It seems to offer solutions to many problems—and is often the first place we turn when we reach a dead end. At the same time, its environmental and societal impacts remain largely unresolved.

When does using AI actually create real value? And how can we use it in ways that contribute to a more sustainable future?

Together with opendata.ch, we’re bringing these questions to the table in a mini hackathon. Developers, designers, sustainability experts, companies, and other interested participants are invited to collaboratively develop new ideas, prototypes, and perspectives.

👉 Goal: to develop concrete approaches for using AI in a meaningful, responsible, and impactful way.

Sustainability Reporting for SMEs: Real Cases, Practical Steps

More info & registration

SMEs play a key role in the sustainable transformation. And yet many find themselves at the same starting point: where do we begin? What really matters? And how much effort does it take?

In this session, four SMEs share their experiences with voluntary sustainability reporting.

The format is interactive: as a roundtable, participants can ask questions, share their own approaches, and discuss together how to overcome common challenges.

👉 Goal: to lower the barrier to entry, show that getting started is feasible, and grow a community of committed SMEs.

From talking to doing—together

Zurich Climate Week stands for a mindset we strongly believe in: combining urgency with optimism. Not just talking about problems, but driving concrete solutions forward. Taking responsibility together—and creating impact in the process.

Especially in a context where uncertainty is increasing and priorities are shifting, it is more important than ever to stay the course. Sustainability is not a short-term trend—it is a long-term commitment. And at the same time, an opportunity: for innovation, for new business models, for real differentiation—and for a different quality of life.

What we need are more spaces for exchange. More transparency. And more courage to share work that is still in progress.

Zurich Climate Week creates exactly these spaces. We’re excited to be part of it.

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.

An article published by the team behind the project in the latest issue of the Revue Médicale Suisse provides a first assessment one year after its public launch.

An official chatbot instead of unreliable answers online

Primary care, which is essential for a well-functioning healthcare system, is facing a growing shortage, even in urban areas. Without easy access to their primary care physician, many patients turn to the internet to search for answers. Unfortunately, the information they find is often inaccurate or even potentially harmful.

In this context, a well-designed AI solution can help deliver the right information at the right time.

This is why we supported HUG in developing a RAG-based chatbot (Retrieval Augmented Generation). ConfIAnce is not the first chatbot designed for patients. However, it stands out thanks to its institutional roots, its use of locally validated medical content, and the control layers implemented to ensure reliable responses.

To guarantee safety, the system integrates monitoring mechanisms, including matching, groundedness checks, harmfulness detection, automated testing, and semantic routing.

Keeping control of the tool to ensure quality

One key challenge is maintaining control over the system, which requires monitoring capabilities. To achieve this, automated tests are run on all answers generated in response to user questions.

These tests measure the factual consistency of the chatbot’s responses compared with the knowledge base.

In addition, adjustable routing rules allow administrators to maintain human oversight by filtering and directing questions appropriately. Administrators can also immediately take the chatbot offline if a malfunction is suspected.

Topics that are frequently asked about but are insufficiently covered in the source documents are identified. These are then developed further to enrich the knowledge base as part of a continuous improvement process.

Even the best tool is only useful if people use it

For the chatbot to be useful, patients need to use it. To support adoption, HUG ran a public information campaign that promoted the tool while setting realistic expectations about what it can do.

ConfIAnce is not a medical device meant to replace a consultation. Instead, it provides informational support for questions related to the most common chronic diseases affecting adults.

In February 2025, ConfIAnce was released in beta. Between early February and the end of October 2025: 3,823 users interacted with the chatbot, generating 5,969 conversations with 11,781 questions (about two questions per conversation)

Feedback provided directly through the chatbot is 75% positive.

Strong acceptance for a different kind of chatbot

Chatbots in healthcare journeys are generally well accepted by patients thanks to their constant availability and ease of use. However, studies highlight recurring issues: inconsistent response quality and a lack of transparency regarding sources.

These are precisely the aspects that differentiate ConfIAnce from many other medical chatbots.

Designed to support, not replace, the relationship between patients and physicians, ConfIAnce helps primary care doctors by freeing up time so they can focus on practising medicine with the human-centred approach that motivated them to choose this profession.

The chatbot, developed in the specific context of HUG and its information resources, could be adapted to other institutional settings.
For such a project to succeed, access to high-quality data is essential, as was the case here. Beyond that, control layers, automated testing, and user feedback enable continuous improvement and ensure the safety and relevance needed to build trust.

Our accessibility journey followed four main steps: automatic scans and quick-fixes, keyboard navigation, mobile zoom optimization, and screen reader experience.

Automatic Scans and Quick-Fixes

We started with automated accessibility testing using browser extensions like IBM Equal Access Accessibility Checker and axe DevTools. These tools helped us identify common issues: missing labels, insufficient color contrast, improper semantic HTML, and missing ARIA attributes. While automated scans only catch about 40% of accessibility issues, they provided a solid foundation for our work.

Keyboard Navigation

Proper keyboard navigation is fundamental to accessibility. Ensuring basic Tab navigation works across the app is straightforward, but more complex components like tabs, menus, and modals require advanced keyboard interactions: arrow keys, Escape key handling, and focus management that follow official W3C guidelines. Users who rely on keyboard navigation have learned to expect these specific patterns, and deviating from them creates confusion and frustration. Rather than building these patterns from scratch, we leveraged Bits UI, a headless UI library that implements these accessibility guidelines correctly.

Beyond individual components, we implemented focus loops and focus restoration at the application level to keep users oriented as they move through different stages of the chat interface.

Mobile Zoom Optimization

During user testing for meinplatz.ch with users who have disabilities, we observed something striking: many users navigate websites on mobile devices with 200% or more zoom, holding their devices just 10cm from their eyes. This insight highlighted a critical gap in most chatbot implementations.

Most chatbots use fixed-position elements: a chat input at the bottom and often a header at the top. When users zoom in significantly, these fixed elements can consume the entire viewport, making the interface unusable. Unfortunately, reliably detecting user zoom levels is impossible in browsers. Our solution: use Intersection Observer to detect when the header or footer take up more space than expected, then dynamically remove their fixed positioning to restore usability.

Screen Reader Experience

Screen reader accessibility isn't automatic: it requires careful design. We focused on providing clear context through proper page structure (landmarks and headings), ensuring users always understand where they are and what's happening, and provide them shortcut to the key parts of the app.

Providing Context

We implemented a comprehensive outline structure with landmarks for main navigation, settings, and input areas. Each message includes proper headings and labels, and we added a skip link after the chat input (at the bottom of the page) to help users quickly return to the top.

Web Component Challenges

Working with web components introduced unique challenges. VoiceOver is particularly sensitive to how libraries are implemented. We worked closely with the bits-ui team (who were very responsive to bug reports) and implemented local portals for dropdown menus to avoid VoiceOver navigation issues, for example.

Managing Announcements

One of the trickiest challenges was managing VoiceOver announcements when multiple events occur simultaneously. Since queuing announcements doesn't work reliably, we carefully sequenced events and merged related announcements. For example, when a user clicks "select all options" for a list, individual announcements for each option would normally fire and override each other. Instead, we cancel those separate announcements and replace them with a single clear announcement summarizing everything that happened (all items selected or deselected, reset to the predefined set of items, etc.).

Since the chat is a SPA without page reloads, it was also important to announce all changes that are only visually visible, for example: light/dark mode switch, language switch, etc.

Chat Flow for Screen Readers

We designed the chat experience specifically for screen reader users:

• The input field includes both a placeholder and an aria-label with the page title, providing context on page load since the input auto-focuses and users skip over the initial page content.
• When a response is being generated, we announce this clearly, providing the same feedback that a visual loading indicator would.
• Once a response is ready, it's read without markdown formatting (no bold, no links, etc.) to maintain a natural reading flow.
• After reading a response, we make users aware that they can ask another question directly or navigate to the last message's options to provide feedback or view references. We dynamically add this interactive section of the last message (where users are most likely to interact) to the document outline, creating a quick navigation shortcut.
• Chat history is structured as articles with labels, making it easy to navigate past conversations.

Try It Yourself

You can experience these improvements with Alva, the chatbot of the Basel-Stadt administration. Try navigating with VoiceOver (MacOS) or NVA (Windows), use only your keyboard, or zoom in significantly on a mobile device.

An ongoing journey

Our next goal is to integrate automated accessibility testing into our CI pipeline. However, as mentioned earlier, automated scans only catch around 40% of accessibility issues. This means we'll still need to carefully plan and test each new feature manually. Nothing replaces human testing when it comes to accessibility—automated tools can flag missing labels or contrast issues, but they can't evaluate whether an interface is actually usable for someone navigating with a screen reader or keyboard.

Accessibility is an ongoing journey, not a destination. We're committed to making LiipGPT usable for everyone, and we'll continue refining our approach based on real-world feedback.

Need Help with your Accessibility?

We offer accessibility audits to help you identify and fix issues in your own applications. If you're looking to improve the accessibility of your product, get in touch with us, we would be happy to help.

GovNL: From months to minutes to build sites

GovNL combines open source Drupal components and an open design system to run many Dutch government sites in a way that is accessible and scalable. It reduces time to build new sites from 3 months to about 10 minutes, pretty impressive to say the least. This is a strong use case of designing for reuse at large scale.

European Commission: Coordination is key to scaling

The European Commission already runs no less than 770 sites and invests heavily in the Drupal ecosystem! What stood out for me was how much they focus on coordination—making sure the right content is published through the right channel across that landscape. Open source program offices (OSPOs) were established as a way to drive open source agendas both at government level and inside organisations.

Kanton Basel-Stadt website and Alva: a blueprint for local public administration

Just before lunch break, it was time for me to present the different AI use cases we implemented for Kanton Basel-Stadt. The canton set new standards with the bs.ch relaunch with user-centred design, topic-based access instead of internal org structure, and Alva as the first AI-based chatbot for a Swiss canton. The stack is based on open source components and Liip heavily contributed to open source as part of this relaunch. We use Drupal as CMS, Nuxt/Vue, the blökkli editor for the headless frontend and Elasticsearch for search. Content is produced by a cross-department editorial team following a clear content strategy.

AI to support the public and editors of the website

The talk was an opportunity to share figures more than 18 months after the go-live. Today, Alva handles over 10,000 questions per month, with about 1.36 questions per conversation and +44% growth since Alva 2.0. API integrations let the chatbot answer questions based on real-time information. Alva is also used heavily by internal users from the canton as well as the public. The chatbot always shows and validates its sources, which is central to creating trust.

On the editing side, blökkli is working hard to simplify texts. By using the blökkli editor with integrated AI, editors can now run a readability audit, see proposed simplifications side-by-side and accept or adapt them. Alva and the AI features on bs.ch are continuously developed further to provide editors and citizens trustworthy AI technology.

AI assisted technologies at the French Government

Another inspiring talk to watch was Use-cases of AI in the Services Publics+ platform at the French government. With more than 140.000 experiences shared and over a million of reactions, the system uses AI assisted technology to help State service provide feedback to citizens. They leverage speech to text and real-time summaries as an enabling technology. C’est magnifique!

The EU trusts open source more than ever

The European Union introduced Website Evidence Collector that scans sites for security issues and is open source. It was notable that they publish it under the EUPL (European Union Public Licence), which emphasises interoperability between countries and licences and supports multilingual collaboration. I wonder if Switzerland has something similar?

Not only does the EU trust open source for security they also provide through Interoperable Europe a new portal there’s a useful Licensing Assistant. You can find and compare software licences and run a compatibility checker to see if different open source licences can be combined and whether there are legal complications.

Using open source is not enough, we need champions

Finally, Tiffany Farris from strategy consultancy Palantir.net (not to be confused with the infamous Palantir Technologies) stressed that using open source is good, but not enough. You need champions in the organisation who put contribution and ecosystem health on the agenda. Designing for reuse should be a core principle. From a US perspective, procurement is a problem: open source usage has grown, but support mechanisms often haven’t. Treating open source as “free” can lead to contracts going to vendors who brand their work as open source without actually supporting a thriving ecosystem. She proposed concrete public money, public code-style amendments to public procurement to better support the ecosystem. This was really an inspiring conclusion to an intense day of learning and exchanges.

You can watch the playlist if you would like to dive deeper into the presentations from Drupal4Gov EU 2026.

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.