# Réfugiés.info: How We Improved a Public Service Accessibility Without Ever Stopping It > A hands-on case study on migrating Réfugiés.info to the French State Design System (DSFR) and continuously improving RGAA accessibility compliance, led by a small Beta.gouv team. **Published:** 2024-12-20 **Author:** Jérémie Gisserot **Language:** en **Canonical URL:** https://jeremie-gisserot.net/en/accessibility-design-systems/refugies-info-dsfr-accessibility-case-study --- > **Quick summary:** > This case study tells how the **Réfugiés.info** team, a public product incubated by **Beta.gouv** (France's government startup incubator), improved its digital accessibility while migrating to the **DSFR** (France's State Design System). > The goal: reconcile technical debt, human constraints, and **RGAA** requirements (France's accessibility framework, equivalent to WCAG) to evolve an essential service without interrupting its mission. --- ## Table of Contents 1. [The Day I Opened the Hood](#1-the-day-i-opened-the-hood) 2. [What Technical and Accessibility Problems Did We Need to Solve?](#2-what-technical-and-accessibility-problems-did-we-need-to-solve) 3. [How Did We Structure the Accessibility + DSFR Approach?](#3-how-did-we-structure-the-accessibility--dsfr-approach) 4. [What Technical Challenges Did We Encounter?](#4-what-technical-challenges-did-we-encounter) 5. [What Concrete Progress and Lessons Can We Draw?](#5-what-concrete-progress-and-lessons-can-we-draw) 6. [What Are the Next Steps?](#6-what-are-the-next-steps) 7. [FAQ — Accessibility and DSFR](#faq--accessibility-and-dsfr) --- ## 1. The Day I Opened the Hood When I joined Réfugiés.info, I had the strange sensation of taking the helm of a ship already at sea. A solid ship, used every day by refugees and asylum seekers, but where each piece told a different story. The site worked, yes. But its code vibrated like an old floorboard: it holds, but you can't jump too hard on it. Under the hood, technical generations mixed together: custom components, disparate conventions, successive attempts to structure the interface. The service wasn't inaccessible… but it wasn't yet inclusive. I thought to myself: _we can help it breathe better._ ### What Is Réfugiés.info? **Réfugiés.info** is a French public service that helps refugees, asylum seekers, and support workers find reliable information about their rights and administrative procedures. A useful, human product, well-established within the **Beta.gouv** ecosystem — France's government startup incubator that supports public products through an agile, iterative approach. ### Where Were We Starting From? The product had an **in-house design system**, visually coherent but lacking robust tooling and a clear accessibility strategy. That's when the team decided to level up: 👉 strengthen **digital accessibility**, 👉 migrate to the **DSFR** (France's State Design System), 👉 and maintain the product's evolution pace. ### My Role and Starting Level I joined the team as a **senior front-end developer**, specialized in design systems and web standards, but **not yet an RGAA expert**. I knew accessibility best practices without mastering every criterion of the framework. So I started by observing: keyboard navigation, screen reader behavior, heading structure, visible focus states. Result: significant room for improvement. > 🧩 **DSFR:** the _Design System de l'État français_ (French State Design System), a component library and graphic rules for harmonizing public digital services. > ♿ **RGAA:** the _Référentiel Général d'Amélioration de l'Accessibilité_ (France's General Accessibility Improvement Framework), equivalent to WCAG. It defines the criteria to meet for ensuring access to all users. > 🏛️ **Beta.gouv:** France's _startup d'État_ incubator, which supports public products through an agile, iterative approach. --- ### How Did the Process Start? The **Beta.gouv accessibility team** stepped in from the beginning: an individual onboarding session to get up to speed, understand testing tools, and frame priorities. Not a formal audit, but a real **educational boost** that transformed the "accessibility" topic into a **concrete roadmap**. In parallel, the migration to **DSFR** emerged as a logical lever: the DSFR already integrates many accessibility best practices. 👉 Working on both topics simultaneously made sense: each migrated component gained both coherence and inclusion. Time-consuming, certainly, but **much more virtuous**: redo less, do better, and build more durably. --- ## 2. What Technical and Accessibility Problems Did We Need to Solve? ### A Solid Public Product… But One That Needed Realignment Réfugiés.info worked well: users found what they needed. But under the hood, **the product wasn't yet aligned with RGAA standards** or DSFR logic. #### Front-End Debt and Code Heterogeneity The site carried the legacy of **several generations of developers**. Some parts used older technologies, others more modern React, with a lot of **SCSS** instead of a utility-first system like Tailwind CSS. Components were properly organized but **not designed with RGAA in mind**; their internal logic varied from one block to another. --- ### Where Was Web Accessibility? There was **no formal RGAA audit yet**. The team "paid attention," but without a structured approach. In practice: - **hierarchically inconsistent headings**, - **invisible focus states** in some modals, - **unannounced dynamic components**, - and sometimes **icons without text alternatives**. The product was **not exclusionary**, but it was **not yet inclusive by design**. --- ### What About the Design System? The **in-house design system** ensured visual coherence, but remained **outside public standards**. With the **DSFR**, we needed to unify styles and components, adopt **DSFR tokens**, and rework the CSS logic. We chose to gradually switch to **React-DSFR** and introduce **Tailwind** to simplify development and reduce front-end debt. --- ### What Team Constraints Were There? The team was small. In one year, **three project managers** succeeded each other. The **CTO** was only half-time, and I was **the only developer at four days per week**. **Budget uncertainties** caused several pauses; work progressed in fits and starts. > 🎯 **Main challenge:** realign the technical and accessibility foundation without interrupting the public service. --- ## 3. How Did We Structure the Accessibility + DSFR Approach? ### A Method Designed to Progress Despite Constraints The goal: **advance on accessibility and DSFR migration simultaneously**, without blocking production. Rather than a complete redesign, we opted for an iterative approach: improve with each pass, never regress. --- ### What Role Did the Beta.gouv Accessibility Team Play? They supported me through an **individual onboarding workshop**: targeted coaching on RGAA logic, audit tools, and manual testing foundations. Their support continued: answers to edge cases, advice on keyboard focus and ARIA, and a **surprise mid-project audit** that helped reprioritize critical fixes. --- ### How Did We Track Accessibility Work? We created a **dedicated accessibility backlog**, organized **by page**, each ticket referencing RGAA criteria with clear priority levels (Critical / Important / Comfort). Even after a several-week pause, we could **resume work without losing context**. --- ### How Did We Combine Accessibility and DSFR Migration? **Integrate DSFR while fixing accessibility**, component by component. Each migration was tested for keyboard navigation, screen reader behavior, heading coherence, and visual compatibility. The philosophy: **leave each page more accessible than before**. --- ## 4. What Technical Challenges Did We Encounter? ### Making DSFR and the Old System Coexist We migrated **component by component**, testing compatibility at each step. The main navigation required a **partial rewrite** for keyboard focus, screen reader behavior, and active state management. ### Adding Tailwind CSS We developed **a custom tool** that maps DSFR tokens into the Tailwind config, generating classes consistent with the official naming convention. Result: DSFR interfaces coded with Tailwind logic, without breaking the State's design charter. ### Accessibility Sensitive Points The most complex challenges: **real-time search** (signaling results without drowning screen readers), **modals** (keyboard focus management), and **nested lists** from the rich text editor. --- ## 5. What Concrete Progress and Lessons Can We Draw? ### ✅ Measurable Progress - **DSFR foundation** stabilized: main components redesigned or migrated - **Tailwind CSS** integrated, lightening code and improving coherence - **Critical journeys** keyboard navigable and correctly announced - **Blocking behaviors** eliminated on forms, modals, and dynamic search - **Front-end debt** significantly reduced ### Key Lessons 1. Never underestimate the complexity of a DSFR migration 2. A dedicated budget changes everything — but use it wisely over time 3. Tailwind + DSFR is possible with rigorous token management 4. People remain central — flexibility and humor are essential > Moving from forced compliance to mastered improvement. That's the philosophy we arrived at. --- ## 6. What Are the Next Steps? - **Finalize screen reader support** on dynamic content and user feedback - **Complete footer sub-pages**, still partially compliant - **Await the next RGAA audit** results to prioritize final fixes - **Reduce technical debt on back-office screens** - **Document design decisions** for handoff to other Beta.gouv teams ### Key Takeaways - Accessibility isn't a sprint, it's a **continuous practice** - The **DSFR** can serve as a technical lever, not a constraint - **Tailwind + DSFR** is viable with good token management - A small team can improve a public product, step by step - **Every refactor counts** — leaving the code more accessible than before is already a victory --- ## FAQ — Accessibility and DSFR **How do you integrate the DSFR into an existing product?** Progressively, component by component, testing accessibility and design compatibility at each step. **Can you combine DSFR and Tailwind CSS?** Yes: map DSFR tokens into the Tailwind configuration to maintain graphic coherence. **How do you make a public service more accessible without a complete redesign?** By working iteratively: each update should make the product a little more inclusive than before. --- > ✍️ _Case study by Jérémie Gisserot — designer & front-end developer (Beta.gouv), specialized in accessibility, design systems, and product strategy._ --- **Read more:** - [Why and How to Disable CSS for Accessibility Testing](/en/accessibility-design-systems/accessibility-disable-css-guide): the practical guide we use daily - [Why I built myself a personal AI agent](/en/personal-ai-agent/why-personal-ai-agent): how I use agents with persistent memory in my daily workflow