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
- The Day I Opened the Hood
- What Technical and Accessibility Problems Did We Need to Solve?
- How Did We Structure the Accessibility + DSFR Approach?
- What Technical Challenges Did We Encounter?
- What Concrete Progress and Lessons Can We Draw?
- What Are the Next Steps?
- 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
- Never underestimate the complexity of a DSFR migration
- A dedicated budget changes everything — but use it wisely over time
- Tailwind + DSFR is possible with rigorous token management
- 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.