A site that is 100% compliant is not automatically 100% accessible.
Cigref highlights this by taking RGAA (General Reference Framework for the Improvement of Accessibility) as an example, noting that it does not account for dyslexia and mental health issues. It also reminds us that, in terms of compliance, the criteria are technical and “objective.” Meanwhile, user tests results are always subjective.
The trap of automated tools and “post-delivery” solutions
The tendency to center the approach to digital accessibility on documentary compliance rather than real-world usage is one of the blockers the association has identified.
The overreliance on automated tools is another. If they promise to facilitate the process of bringing a site up to standards, using them without a proper framework and guidance can prove counterproductive. And it can create a false sense of legal security.
These tools are often technical veneers that apply changes on the surface rather than at the source of the code. They can also interfere with assistive technologies by altering certain settings.
The Cigref also calls for vigilance regarding solutions that propose to add post-delivery accessible configurations. Their finding: they do not guarantee a standards-compliant accessibility approach. At most, some users may derive better comfort. But beware of superficial remodeling as well.
Involve, but also reassure… and put into “real-world” conditions
Another pitfall is the limited involvement of people with disabilities in projects.
There is also the risk that some roles fear a decline in the quality of their work. Cigref cites communications and marketing in particular. For them, it recommends highlighting the benefits of accessibility in terms of SEO improvements. A broader piece of advice: develop operation guides by job type. While presenting the approach as a safeguard against damage to the corporate image—“often more feared than the sanction.”
At iMSA (GIE for MSA IT), digital accessibility also has a dedicated budget line. Oversight is validated through pre-audit cycles starting at 80% of development, in addition to final audits and counter-audits by vendors.
Maturity and oversight of service providers
Providers, precisely, are another potential bottleneck. It is difficult, Cigref explains, to identify truly trained and qualified IT services firms.
More broadly, it is hard to contractually bind a provider to a results-based obligation regarding compliance. This depends heavily on client-specific parameters.
At the La Poste Group, the market for software publishers is deemed not sufficiently mature. Consequently, i-TEAM (the DSI unit delivering to internal clients) frames contractual requirements around improvement plans and roadmaps rather than binding thresholds in negotiations. Examples of clauses included in the contracts:
- Are there usability case studies from people with disabilities?
- Are usability controls performed during development phases?
- Is the solution usable in digital accessibility with the major browsers and the main assistive technologies?
- Are accessibility enhancement works planned in the roadmap?
To understand how to concretely organize the integration of requirements into the project phase, the Caisse des Dépôts has developed four scenarios:
- Internally developed digital service serving more than 100 people
Involves upskilling teams, an accessibility budget charged to the project with the cost of an RGAA audit (6300 € including tax, max) and up to 15 man-days of accompaniment. - SaaS contracted with a publisher serving more than 100 people
Same budget criterion, integration of requirements into market documents and allocation of up to 5 man-days. - Digital service serving fewer than 100 people (or an unknown number)
After discussion with accessibility referents, the project shifts to one of the two aforementioned scenarios. Or proceeds with a very limited scope scenario (functionally or in terms of target users or even budget). This implies a small uplift in skills and a short support period (max 3 man-days). - Digital service that does not implement a user interface
Accessibility considerations are not applicable.
To consult in addition :
How Leboncoin approaches digital accessibility at scale
Data.gouv.fr: from UI to search, an accessibility challenge for public data
What the European directive on the accessibility of products and services changes
