BINOMES is often held up as a “textbook case” in accessibility. Would you agree?

Yes, but not for the reasons people think. The project is often described as exemplary because we reached 100% RGAA compliance. That is rare — fewer than 10% of French websites get to that level. But what makes BINOMES an interesting case is that we understood very early that compliance was not the point. A compliant platform is not necessarily an accessible one. And on this project, had we stopped at legal compliance, we would have shipped something unusable for a large share of users.

What is the difference between the two, in practice?

The RGAA lists 106 criteria. 60% can be tested automatically. The remaining 40% need context, a human eye, a real-life situation. No tool can decide for you whether a text alternative is relevant for a given piece of content. And above all, the standard tells you nothing about how people actually use their digital tools.

During the user tests, one of the visually impaired participants asked whether we wanted him to switch his screen on before we filmed him. He never used it. His screen was permanently off. No automated checker anticipates that. And if you do not test with real users, you have no way of knowing.

You talk about user testing as if it were exceptional. Is it not done as a matter of course?

Rarely. And that is exactly the problem. Most teams working on accessibility have never watched a visually impaired person use a phone. Even with 14 years of experience on these topics, I had never run mobile user tests with visually impaired people before this project. What I learned in a handful of sessions goes beyond what I had accumulated over years of compliance work.

Give me a concrete example of what that changed.

Signing in to the app uses an OTP, a six-digit code sent by email. The email also contained a direct sign-in link, simpler, but placed after the code. Not one user found that link. Neither the visually impaired participants nor the sighted ones taking part in the tests. Nobody reads an email all the way through when the app has told them to go and fetch a code. Moving the link above the code changed the experience. The email was compliant before that change. The app became accessible after it.

Were there other moments when a starting assumption was called into question?

The internal messaging system. We had planned a full module so that users could write to each other inside the app. It was complex to build, but we thought it was necessary. The visually impaired users told us they would rather be left in control: put them in touch, exchange contact details, and they use their own tools from there. They wanted fewer features, not more. Simplicity and autonomy. Those are the two things that came out strongest from all the tests.

People often say design and accessibility are incompatible. BINOMES has just won an international design award.

That prejudice is stubborn and wrong. It comes from the fact that most people working on accessibility have never seen an accessible app that is also well designed. The award is the result of a multidisciplinary team in which every discipline took accessibility into account, not just the developers at the end of the chain. You can make something beautiful, useful and accessible. A constraint, when it is built in from the design stage, becomes a design discipline.

On that note, what mistake should you absolutely avoid when starting an accessible project?

Thinking you can do accessibility later. It is the most common and the most expensive mistake. Going back over components that are already built to “force” accessibility in costs far more than doing it properly from the start. And it often delivers a worse result. On BINOMES, we ran the tests and the changes with visually impaired users before the RGAA compliance work. The opposite order to most projects. Accessibility is not a one-off either: an update can break what used to work. It is a continuous practice, not a box to tick.

So why do companies not do this work?

Because there is no structural reason to. No KPI proving that investing in real accessibility has a tangible impact on the business. No solid data on the return on investment. Accessibility remains first and foremost an ethical commitment in a world that makes its trade-offs on ROI. And the only real lever today is the legal framework. But we still lack real checks and real penalties. The European directive of June 2025 widens the scope and mandates new sector-by-sector supervisory bodies. That is progress. But it will be a few more years before penalties genuinely arrive.

A word for the engineers and developers reading this who have never done accessibility work?

Start by turning your screen off. Take your phone, open the app you are working on, and try to navigate with the screen reader on. Five minutes is enough to grasp what years of documentation do not convey. Accessibility is not a constraint you bolt on at the end. It is a way of building. And once you have seen how people really use what you build, you can no longer pretend not to know.