The City of Toulon and the Toulon Metropolitan Area have undertaken a complete overhaul of their respective institutional websites with a clear goal: to offer a digital service that is easier to read, more efficient... and above all more accessible.
As part of a public contract, they called on various providers who worked closely together:
- Perméable for UX/UI design,
- bluedrop.fr for development, integration and technical management,
- Ideance for support in digital accessibility and the RGAA audit.
Here is the new City website and that of the Toulon Metropolitan Area.
Accessibility has been addressed as a central part of the project, and this is no coincidence. Digital public services have a legal obligation in this area: since the law of February 11, 2005 on equal rights and opportunities, strengthened by the 2016 European directive, public organizations are required to make their websites and applications accessible to everyone, including people with disabilities. This obligation is concretely reflected by compliance with the RGAA, the General Accessibility Improvement Framework, and by the publication of a accessibility statement.
It was in this context that a... was born close collaboration between the teams of bluedrop.fr and ofIdeance.
A collaboration in the service of accessibility
We incorporated accessibility at the heart of the UX/UI design and development process, right from the earliest stages of the project.
This approach paid off, as confirmed by the audit results : the Toulon Metropolitan Area website shows an overall compliance rate of 95.9% and an average rate of 99.6%. Results that reflect the seriousness and commitment of the whole team throughout the project.
Cross Interview Ideance / bluedrop.fr
To look back on this collaboration and the lessons we've learned, we spoke with Steven Mouret, a digital accessibility expert at Ideance, and Rouaïda Roumieh, Head of the front-end development department and accessibility lead at bluedrop.fr.
Could you introduce yourself, your organization, and explain your connection with digital accessibility?
Steven: Ideance is a consulting firm specialized in digital accessibility. Our mission is to support organizations (businesses, local governments, public bodies) in making their digital services accessible to everyone: RGAA audits, consulting, training, technical support. That's the context in which I work daily.
My own background started in front-end development. I first became interested in accessibility as a self-learner, and in 2012, I obtained a web accessibility expert certification from the Braillenet association, a W3C member that has trained a large part of French experts in this field. In fact, the French RGAA standard originates from their work, and it’s the current reference.
What has had a profound impact on me in this journey is the meaning that accessibility has given my work. Realizing that what you develop can literally change the daily life of people with disabilities transforms the way you approach every project. Since 2022, I have joined Ideance as an accessibility expert. My technical experience remains a real asset for supporting development teams and offering concrete solutions tailored to each technology.
Rouaïda : bluedrop.fr is a web agency specializing in UX/UI design, development, and maintenance of Drupal web projects. We are closely interested in web-related issues such as accessibility, performance, security, eco-design, and so on.
Nineteen years ago, I joined bluedrop.fr as a back-end developer. As the company grew and the front-end department took shape, my position naturally moved in that direction, until I eventually became Head of the front-end development department. In the same way, over time, the issue of accessibility became an integral part of our clients' expectations and projects. In my work, it has become a real area of expertise. In 2024, I attended dedicated training and earned a digital accessibility certification, and I gradually took on the role of accessibility lead within the development team. That means I no longer just develop: I also train my colleagues and structure our internal processes.
In practical terms, what is digital accessibility and how do you approach accessibility in your work?
Steven : You have to distinguish between two concepts that are often confused. On one hand, accessibility in the broad sense is the ability for content or a functionality to be used by someone with a disability—whether visual, motor, cognitive, or auditory. On the other hand, compliance refers to adhering to a standard: in France, that's the RGAA. You can have a compliant site that's still hard to use in practice, and vice versa. When I talk about compliance, I mean strictly following the standard. When I talk about accessibility, I’m talking about actual usability.
What's often misunderstood is that accessibility does not concern only blind people. It involves users with very different needs: people who navigate by keyboard, those who use voice recognition, those who need strong visual contrast, or those who use a braille display—a physical device placed under the keyboard with small pins that raise and lower to display braille content in real time.
Rouaïda : For us as developers, in practical terms, this means applying specific rules to HTML structure, color contrasts, image alternatives, keyboard navigation. It’s a meticulous task, but it results in sites that are truly robust, understandable, and usable by everyone.
How do you integrate accessibility into your projects?
Rouaïda : Before I was trained, for the development teams, accessibility felt like a real burden. We were asked to apply rules we didn't really understand, not knowing what they were for or what impact they had on users. It felt like we were doing two developments at the same time, without seeing the point.
After my training, I trained the team in turn. And that's when something changed. Once developers understood why we apply these rules, what people who depend on them actually experience, resistance dropped. We were then able to create structured processes: accessibility is built in from the very start of development, tests are carried out along the way, and we work alongside partners like Ideance on complex technical points. It has become a way of working, not an extra constraint.
Steven : What Rouaïda says is fundamental, and unfortunately it's a barrier we encounter very often. That's why raising awareness is a crucial first step. A developer asked to apply rules without them being explained or their real-world impact being made clear will struggle to keep up with them over time. When you realize that an unlabelled button literally prevents a user navigating by voice from clicking it, you never forget.
How was your collaboration on the Toulon project organized?
Steven : We structured the process into several complementary phases. Upfront, I provided reference materials and technical recommendations targeting complex issues, taking into account the technical constraints specific to the project and to Drupal.
Then we worked in agile mode, by sprints. With each delivery, I participated in acceptance testing to check the accessibility of the components developed. This isn't a superficial check: we test every feature with real assistive technologies, check keyboard behavior, state changes, and focus management. Next came a formal audit phase, followed by a correction phase, and finally a follow-up audit to validate the fixes.
This approach of continuous support, rather than a simple audit at the end of the project, makes it possible to anticipate problems instead of discovering them too late.
Rouaïda : On our side, the collaboration was very smooth. The recommendations were clear, directly actionable, and always came with explanations.
We didn't just receive instructions, but a line of reasoning. That allowed us to gain skills and become more independent on the subject.
What were the main technical challenges you encountered?
Rouaïda : One of the challenges concerned the content filters. At first, we wondered which component to use: tabs, an accordion, something else? This initial choice has consequences for accessibility. The technical difficulty was that the Drupal module managing these filters had a basic mechanism that was not very accessible. We had to add the expected behaviors to it—keyboard navigation, state changes, focus management—while keeping the module. The fact that the page works via Ajax, meaning results update without a full page reload, was not a problem in itself, but required extra work we usually don't have to do on a standard page.
Steven : To make this concrete: imagine using a site with your eyes closed, guided only by the screen reader's audio feedback. You apply a filter. The list of results changes on the screen, but your screen reader says nothing. You don't know whether the action worked or what happened. Did the page respond? Are there results? Which ones?
What we set up is an automatic message, not visible on the screen, that is read by the screen reader as soon as the list updates. This message indicates, for example, the number of results displayed. The user then knows their filter has been applied and can browse the list to view the new content. This is just one element among others, but it illustrates the nature of the work: making purely visual information perceptible, so that everyone can understand what's happening on the page and continue to use it.
Are there any elements you are particularly satisfied with?
Rouaïda : Yes, especially the work on media (images). We implemented fields for alternative text, captions, enriched transcripts.
Steven : This is an excellent example. The exercise proves to be particularly demanding for contributors, as a lack of knowledge about the subject of images makes it difficult to distinguish between their different elements.
Without a deep understanding of the meaning of the image and its contexts, it becomes difficult to design:
- The alternative text: which must describe the image.
- The caption: which provides context for the image.
- The detailed description: which allows you to describe images with rich content.
The risk of confusion is real when the background is not understood. This is precisely where training proves its worth: it must enable contributors to analyze the intention behind the image before even writing a single line.
What does the RGAA accessibility audit involve?
Steven : The audit is the formal verification of compliance. We start by selecting a sample of pages that are representative of the service: the homepage and the contact page are mandatory, and we also add the pages that reflect the main content and key features. For Toulon, this included calendar views, news items, and so-called "hot" and "cold" content. For this sample, we review all the RGAA criteria and tests.
It's mostly a manual task, and it's important to understand this. Many criteria cannot be checked by an automated tool. Is an image's alternative text relevant in its context? Does the heading hierarchy make sense to a user? No robot can answer that as of today. That's why the audit takes time and why you have to pick the right moment to start: if you do it too early, you'll spot basic errors that could have been fixed much earlier.
At the end of the audit, we produce a compliance report that is presented to all teams (clients and contractors). This is followed by a correction phase, then a follow-up audit to validate the implemented corrections.
Rouaïda : The follow-up audit was completed very quickly on our side. The recommendations were clear from the start, so when there were oversights, we immediately understood what needed fixing. Most of the time, they were small mistakes from inattention, not structural issues.
Steven : That’s quite rare and worth highlighting! And it’s directly linked to the fact that we worked together throughout the project. I knew the teams, their technical constraints, and they were knowledgeable enough about the topic to integrate corrections without back-and-forth. We achieved results very close to 100% compliance on the development side, showing it’s entirely achievable when everyone plays their part.
What benefits have you gained from this collaboration?
Steven : Working with a team that’s already aware of accessibility really changes the way we can support them. When the teams aren't familiar with the topic, we often stick to what's strictly necessary for compliance. With bluedrop.fr, we could go further: think about usability for real users, not just tick off criteria. It's an approach we don’t always get to use with less mature teams in terms of accessibility.
Rouaïda : For us, it was our first collaboration of this kind and we had some concerns. But communication was always smooth. What stood out to me most was Steven’s teaching approach: he didn’t just answer our questions, he explained the reasoning behind them. Now, when I come across a complex issue, I ask myself how he would analyze it. Sometimes I find the answer by myself. It’s a way of passing on knowledge that really leaves a mark.
Any advice for organizations that want to get started?
Steven : Raise awareness early, and raise awareness for everyone, not just developers. From decision-makers to contributors, everyone has a role to play. Include accessibility in your public contracts: ask for evidence, audit reports, and make sure your contractors have a real policy in the field. Train your teams before launching an audit, because an audit done too soon only reveals errors that could have been avoided.
And don’t wait to have a perfect result before publishing an accessibility statement. The law allows you to declare you’re in the process of achieving compliance. The important thing is to make progress. The law is from 2005, but it’s never too late to start, and accessibility is, in any case, ongoing work. An audit gives you the status at a given point in time. The very next day, if content is published without following the rules, compliance changes. That’s why you need to anchor it in the practices of all your teams, just like quality or performance.
Rouaïda : Absolutely agree. We would never consider delivering a site without design, so why deliver one without accessibility? It’s a quality standard, not an extra constraint. It should be part of the project’s DNA, right alongside functionality.
Do you want to improve your Drupal site's accessibility? Let's talk about it!
Accessibility doesn’t happen by chance: it’s built in from the design stage and evaluated throughout the project. At bluedrop.fr, we help public and private organizations design and develop accessible Drupal sites that comply with the RGAA.
Tell us about your project using our contact form to get support from our Drupal experts. And to carry out an RGAA accessibility audit or receive specialized support, contact the Ideance experts.