beta.gouv.fr est un incubateur de services numériques publics dont l’ambition est de produire des services numériques répondant à des standards de qualité. Parmi ces standards, l’accessibilité numérique est primordiale : elle consiste à rendre les contenus et services numériques compréhensibles et utilisables par les personnes en situation de handicap.

Pour accompagner cet effort, le Pôle Numérique Inclusif (PNI) de beta.gouv.fr a pour mission de :

• Accompagner les équipes et leurs incubateurs
• Faire monter en compétence les membres de la communauté
• Inclure l’accessibilité dans les pratiques

Dans cette optique, nous (le Pôle Numérique Inclusif) avons étudié l’accessibilité numérique d’un échantillon de services numériques du portefeuille, et souhaitons communiquer sur les apprentissages observés. Cette étude vise à encourager l’amélioration de l’accessibilité au sein des produits beta.gouv.fr. Elle n’a pas pour but d’évaluer la conformité RGAA des services étudiés.

Cette analyse a été effectuée fin 2025. Elle ne tient pas compte des changements qui ont pu être effectués depuis.

Résultats de l’étude

Niveau d’accessibilité

Sur un panel de 38 produits (sur les 213 produits de notre portefeuille, soit sur un échantillon de 18 % de nos produits), le niveau d’accessibilité se répartit ainsi :

Note : l’échantillon étudié est différent chaque année, mais se veut représentatif (voir notre Méthodologie d’évaluation manuelle rapide)

Problèmes les plus fréquents

Pour mieux appréhender l’impact utilisateur du manque d’accessibilité (c’est-à-dire les difficultés d’accès auxquelles les usagères et usagers sont confrontés), nous avons estimé leur densité en « nombre de problèmes par page » (pb/p).

Les usagères et usagers de ces services rencontrent plus de 5,5 problèmes d’accessibilité par page. Il s’agit d’une moyenne : sur l’ensemble du panel, certains services en concentrent davantage, d’autres beaucoup moins. Même si ce chiffre peut sembler faible, il traduit une forte pénibilité d’usage : dit autrement, une personne consultant consécutivement 5 pages peine sur des défauts d’accessibilité 27 fois au fil de son parcours.

On constate aussi que plus de la moitié de ces problèmes sont bloquants : c’est-à-dire que certaines personnes seront empêchées de naviguer, d’accéder ou de comprendre l’information plus de 3 fois par page.

Les problèmes les plus fréquemment rencontrés sont :

1. Plus de 2.5 problèmes de navigation (dont 1.7 bloquants) par page :
   • La navigation au clavier est souvent laborieuse, avec plus de 2 problèmes par page : focus parfois invisible, manque de cohérence de l'ordre de tabulation et absence de lien d'évitement (1 fois sur 2), ce qui est pénible pour les personnes naviguant sans souris ;
   • Un seul moyen de navigation, imposé au lieu de deux requis : 1 fois sur 2, l'unique moyen de navigation est un menu principal (sans recherche ou plan de site) ;
   • Diverses difficultés de navigation par titres (0.4 pb/p).
2. Environ 1.8 problèmes de compréhension (dont 1 bloquant) par page :
   • Impossibilité d'accéder à une information faute d'alternative correcte aux images, médias & vidéos, quasiment 1 fois par page (0.8 pb/p) ;
   • Difficultés de compréhension dû à des titres de page non pertinent (0.5 pb/p, soit 1 page sur 2) ou des intitulés de liens et boutons non explicites (0.3 pb/p) ;
   • Parfois langue du document inexacte, ce qui occasionne par exemple une vocalisation de la page en français dans une autre langue, la rendant incompréhensible des personnes utilisant un lecteur d'écran.
3. Près de 1 problème de perception par page (bloquant 1 fois sur 2) : textes illisibles lorsqu'ils sont consultés en gros caractères (0.4 pb/p), contrastes insuffisants (0.3 pb/p) et, très gênant bien que rare dans notre panel : mouvement ou clignotement intrusif (qui ne peut être stoppé).

Erreurs courantes

Nous avons par ailleurs répertorié les erreurs majoritaires dans notre panel, c’est-à-dire les plus couramment commises par les équipes.

Voici les erreurs commises sur plus de la moitié de notre panel :

1. 68 % des services présentent des incohérences de titraille : la hiérarchie des titres ne reflète pas le contenu de la page, des balises sont utilisées non pour leur valeur sémantique de titre mais pour écrire en gros, etc.
2. De nombreux services présentent des déficiences de navigation :
   • 61 % n’ont pas de lien d’évitement fonctionnel (absent ou défectueux). Bien que ce composant soit disponible dans le DSFR, il n'est souvent pas implémenté.
   • 61 % des services imposent un seul système de navigation (alors que deux sont requis).
   • 53 % dégradent la visibilité du focus.
3. 61 % des services perdent en lisibilité en gros caractères : textes tronqués, éléments fixes (sticky bar) qui recouvrent des contenus, etc. Cela montre que l'affichage en texte agrandi ne fait pas partie des tests usuels.
4. La moitié des services ne traitent pas correctement les images non informatives (qui doivent être non seulement dépourvues d'alternative, mais aussi rendues silencieuses). Cela révèle un manque de maîtrise du codage accessible des images dans leurs différents formats : les balises img sont le plus souvent pourvues de leur attribut alt, mais les autres formats (svg, etc.) ne sont généralement pas correctement structurés.
5. Enfin, de nombreux services peinent à proposer des intitulés suffisamment informatifs :
   • Nous observons une certaine difficulté à rédiger l'alternative textuelle adéquate (sur 58 % des services) tant pour les images que pour les contenus riches.
   • La moitié des services présente des intitulés de liens et boutons peu explicites : c'est le cas lorsqu'une série de liens s'intitulent de façon identique, par exemple « voir le dossier », sans préciser le nom de chaque dossier.
   • Souvent identiques, les titres des pages de la moitié des services manquent de précision.

Apprentissages

Au-delà des défauts d’accessibilité qui ressortent le plus (en général ou par équipe), nous avons aussi approfondi l’analyse sur certaines thématiques.

Des nouveaux points de contrôle pour mieux connaître les difficultés

Cette année, nous avons décidé d’ajouter quelques nouveaux points de contrôle au protocole d’évaluation défini l’année dernière. Cela nous a permis d’identifier un problème récurrent qui échappait jusqu’alors à notre évaluation : le responsive est trop souvent oublié. En effet, seulement un produit sur 2 est correctement utilisable sur mobile. Un tiers présente quelques défauts d’affichage sur mobile et 1 produit sur 6 n’est pas du tout utilisable sur mobile.

Concernant les 3 autres nouveaux points de contrôles (vidéos et sons, captchas ou mode sombre), les résultats nous permettent de confirmer que ces défauts sont rares dans notre échantillon. Plus de détail en annexe.

Les formulaires, source de difficulté, pour les usagers… et pour les équipes.

Les formulaires sont un point de contact avec les usagères et usagers, permettant l’interaction avec le service. Leur accessibilité est donc primordiale. De plus, dans notre échantillon, plus d’une page sur deux propose un formulaire.

Pourtant, nous avons observé que lorsqu’un formulaire est présent, on y détecte des erreurs dans la moitié des cas (48 %) : consignes de saisie absentes, mal associées ou peu explicites, champs obligatoires non signalés, etc. — sans compter les défauts que notre protocole ne permet pas de détecter.

Une qualité parfois hétérogène au sein d’un même service

Nous avons remarqué que le niveau d’accessibilité peut être très inégal au sein d’un même site. Par exemple :

• Des pages intérieures qualitatives, mais une page d'accueil peu accessible.
• Un site au niveau correct, mais dont l'accessibilité est fortement dégradée par l'intégration d'un service tiers sur l'une des pages.
• Un service développé de façon correctement accessible, sauf sur ses fonctionnalités récentes.

Ce constat rappelle que l’accessibilité ne réussit que si elle est travaillée par chaque membre de l’équipe, tout au long du projet.

De nombreuses erreurs évitables

Il est toujours très frustrant de constater que les problèmes les plus bloquants ne sont pas les plus compliqués à corriger. Par exemple :

• langue du document mal déclarée, alors qu'il suffit d'un attribut HTML lang="fr" ;
• absence de lien d'évitement, alors qu'il existe un composant prêt à l'emploi dans le DSFR ;
• visibilité du focus dégradée, alors que la valeur native de la propriété CSS outline suffit ;
• etc.

Cela montre encore une fois que l’un des enjeux de l’accessibilité n’est pas la complexité de la discipline mais plutôt un manque de réflexes des équipes (qui pourraient être consolidés par de la formation, des process…).

Un Design System aidant… mais pas suffisant

Une partie de l’accessibilité est prise en compte par le Système de Design de l’État (DSFR) au sein des composants mais aussi via la documentation associée. La majorité de notre panel (75 %) s’appuyant sur le DSFR, on a pu constater ses effets bénéfiques :

• Couleurs : les services qui utilisent exclusivement les palettes accessibles du DSFR ne présentent pas d'erreurs de contraste ; alors que c'est un problème courant en règle générale (dans le monde, plus de 79 % des sites font ces erreurs d'après la dernière étude WebAIM)
• Formulaires : dans notre échantillon, l'absence d'étiquette de champ est une erreur rare. En comparaison, cette même erreur est courante dans le monde (65 % d'après la dernière étude WebAlmanach).

Cela confirme que l’usage d’un Design System accessible, tel que le DSFR, est un véritable bénéfice pour l’accessibilité.

Pourtant, malgré sa bonne adoption dans notre échantillon, nous constatons que cela ne suffit pas. Par exemple, l’absence de lien d’évitement est un problème récurent dans notre panel, alors que le composant existe, prêt à l’emploi, dans le DSFR. Son absence d’implémentation montre donc un manque de connaissance (de son fonctionnement, de sa nécessité…).

Cela nous rappelle que les ressources favorisant l’accessibilité, comme le DSFR, sont certes nécessaires mais pas suffisantes.

Épilogue

Nous menons cette étude pour la deuxième année consécutive. Cet exercice nous est très utile pour :

• Faire un état des lieux de la qualité d'accessibilité des produits de l'incubateur, plus précis que ce que ce que nous permettrait une analyse avec des tests automatiques.
• Identifier les problématiques récurrentes, où le Pôle Numérique Inclusif peut mettre de l'énergie pour accompagner les équipes produits de beta.gouv.fr.
• Encourager les équipes à entamer une démarche d'amélioration de l'accessibilité quand ce n'est pas déjà fait ; en proposant des prochaines actions claires.

Annexes

Ressources

• Méthodologie de l'évaluation manuelle rapide
• Résultat de l'évaluation 2024

Nouveaux points de contrôle

Mode sombre

Le Système de Design de l’État propose un composant Paramètres d’affichages permettant aux usagers de choisir d’afficher le site en thème clair ou en thème sombre. Nous nous sommes interrogés sur la qualité de cette personnalisation, notamment quand le site présente des composants personnalisés. En effet, cela nécessite que l’équipe s’assure que le composant soit accessible dans les deux versions (thème clair et thème sombre).

En 2025, sur les 31 services utilisant le DSFR, 8 ont implémenté ce thème sombre (25 %) ; et seulement un service a mal implémenté ce thème sombre, en ne s’assurant pas que les contrastes minimums soient respectés ; le rendant ainsi contre-productif.

Captcha, vidéos et sons

Les vidéos ou sons qui se lancent automatiquement et les captchas peuvent être de véritables barrières en terme d’accessibilité.

Nous n’avions pas inclus ces points de contrôle dans notre protocole initial, car nous n’avions jamais rencontrés ces problèmes lors de nos accompagnements. Cette année, nous avons décidé d’ajouter ces points de contrôle à notre évaluation, par souci d’exhaustivité.

Ainsi, en 2025, nous avons pu constater que :

• Aucun des services évalué ne propose de captcha. Les services ont choisi d'autres mécanismes de protection.
• 18 services affichent des vidéos ou du son (soit 47 % de notre échantillon), mais seulement un le fait de manière problématique (vidéo en autoplay).

Responsive

Nous évaluions déjà l’utilisation de la page pour les personnes utilisant un zoom d’écran. Cette année, nous avons décidé de rajouter aussi un point de contrôle spécifique au responsive.

Nous avons trouvé que seulement un produit sur 2 est utilisable correctement sur mobile. Un tiers présente quelques défauts d’affichage sur mobile et 1 produit sur 6 n’est pas du tout utilisable sur mobile.

Méthodologie d’évaluation manuelle rapide

Nous avons réutilisé une méthodologie sensiblement similaire à celle de l’année dernière :

1. Sélection de l'échantillon de services
2. Constitution d’un échantillon réduit pour chaque service
3. Inspection manuelle sur chaque page
4. Évaluation du niveau d’accessibilité
5. Communication à l’équipe concernée des principaux défauts identifiés

Sélection d’un panel de services

Nous avons choisi d’inspecter les services numériques de notre portefeuille parmi les plus avancés et/ou ayant un fort impact. Ce panel contenait :

• 4 services à impact national. Ce sont les services « vitrine » de beta. Ils ont eu un impact significatif sur la vie de centaines de milliers voire de millions de Françaises et de Français.
• 17 services candidats au FAST. Ces services ont atteint suffisamment de maturité pour souhaiter « passer à l’échelle ». L’enjeu d’accessibilité est donc très important.
• 🆕 17 services phares désignés par les différents incubateurs du réseau. Cela nous a permis de nous assurer que chaque incubateur était bien représenté au moins à hauteur de 10 % dans notre panel.

Ainsi, nous avons construit un échantillon de 38 produits (contre 26 l’année dernière).

Constitution d’un échantillon réduit

Pour chacun des services du panel, nous avons identifié les 3 pages les plus pertinentes à inspecter. Nous avons systématiquement inspecté la page d’accueil, puis nous avons choisi deux autres pages de type :

• Formulaires (connexion, démarche, simulateur, recherche)
• Contenus, représentatifs du service

Nous avons ainsi inspecté un total de 114 pages.

Inspection manuelle

Comme l’année dernière, pour que notre inspection reste rapide, reproductible et pertinente, nous avons choisi des points de contrôle :

• ayant un impact utilisateur fort
• dont le geste technique de vérification est rapide
• suffisamment variés (pour être représentatifs de la diversité des problèmes)
• pérenne (qui reste pertinent dans la durée, quelque soit le référentiel en vigueur)

Nous avons ainsi retenu une liste 27 points de contrôle, répartis en 9 catégories :

Comparativement à un audit RGAA, cette liste de contrôle n’est pas exhaustive : elle ne permet aucunement d’apprécier la conformité. Mais la frugalité de cette méthode d’évaluation a l’avantage d’être opérable en un temps très court : environ 30 minutes par service suffisent à obtenir une grille d’évaluation ainsi qu’un aperçu de son niveau d’accessibilité (voir section suivante).

Notation des problèmes

Nous avons conservé l’approche centrée utilisateur de notre évaluation : comme l’année dernière, nous avons nuancé la sévérité des erreurs d’accessibilité identifiées relativement au parcours utilisateur. Notre but était d’identifier les points bloquants sur le parcours dans ces pages.

En effet, un même défaut d’accessibilité n’a pas le même impact selon qu’il est en début de parcours ou niché dans une fonctionnalité secondaire. Par exemple, un champ de saisie non accessible dans le formulaire de login permettant d’accéder au service est un problème majeur, bloquant l’usager ou l’usagère, tandis que ce même défaut est mineur dans un formulaire de recueil d’avis (à plus forte raison s’il existe d’autre moyen de contacter le service).

Comme dans les audits d’ergonomie, notre notation reflète le degré de sévérité des défauts d’accessibilité relativement au parcours utilisateur. Pour chacun des points de contrôle, nous avons ainsi évalué si la page présentait :

Évaluation du niveau d’accessibilité

Cette inspection est menée en regard croisé, par deux expertes du Pôle Numérique Inclusif, coutumières de l’évaluation experte de l’accessibilité. Mais contrairement à l’audit RGAA, cette méthodologie ne permet pas d’établir un taux ni même un score d’accessibilité.

En revanche, l’issue de l’évaluation permet d’apprécier si l’accessibilité est correctement, moyennement, peu ou pas prise en compte sur le service. Ainsi, nous exprimons une appréciation globale du niveau d’accessibilité de chaque service, en des termes simples :

Note : Le niveau maximum est correct. Nous considérons que notre méthode d’évaluation n’est pas suffisamment exhaustive pour permettre d’identifier un « bon » niveau d’accessibilité.

Communication aux équipes

À l’issue de l’analyse, nous envoyons un rapport, succinct mais personnalisé, à chaque équipe évaluée, en listant notamment :

• Les problèmes les plus marquants rencontrés sur le site
• Nos recommandations à l’équipe, en précisant des ressources de références en français.

Protocole d’évaluation

Nous mettons la grille d’évaluation manuelle à disposition :

• Le premier onglet "Évaluation" contient une grille vierge ;
• Le second onglet "Mode d'emploi" fournit des indications génériques (sélection des pages, outils nécessaires, mode de fonctionnement de la grille) et précise le geste, la notation et exemplifie chaque point de contrôle.

N’hésitez pas à l’utiliser dans votre organisation si cela s’y prête :