Puis-je faire ma démarche seul, quel que soit mon handicap ?

Belrive est une commune fictive. Son portail sert aux démarches administratives en ligne. La démarche de référence est la demande d’un acte de naissance : courte, fréquente, précise.

Les utilisateurs visés sont tous les habitants. Parmi eux, des personnes aveugles ou malvoyantes, des lecteurs lents, des personnes sans souris, des habitants peu à l’aise avec le numérique. L’Insee comptait 7 % de personnes en situation d’illectronisme parmi les 16 à 74 ans en 2025.

Ces profils sont des hypothèses. Aucun entretien n’a été mené. Camille Martin, nom affiché dans les écrans, est un exemple.

Le système de design de l’État, le DSFR, est réservé aux services de l’État. Belrive a donc son propre système, construit avec les mêmes exigences.

• Métier. Couvrir la demande, le suivi et les préférences d’affichage. Ne perdre personne entre la première question et la confirmation.
• Technique. Le texte doit pouvoir être agrandi à 200 % sans casser la mise en page. Les deux modes de contraste doivent partager les mêmes composants.
• Accessibilité. Le RGAA 4.1.2 sert de référentiel, avec ses 106 critères et 13 thématiques. L’information ne doit jamais reposer sur la couleur seule. Le focus doit rester visible sur tous les fonds.
• Délai. Un mois, en parallèle de mon activité. Périmètre : une démarche complète et ses écrans annexes.

Recherche documentaire, sur des sources publiques consultées le 4 octobre 2026. Trois enseignements.

Le cadre légal se durcit. L’article 47 de la loi de 2005 impose une déclaration d’accessibilité, un schéma pluriannuel et une mention en page d’accueil. L’Arcom contrôle, avec des sanctions jusqu’à 50 000 euros. L’European Accessibility Act s’applique depuis le 28 juin 2025.

L’écart avec la réalité est documenté : en janvier 2026, 16 des 244 démarches essentielles étaient pleinement conformes, selon la Cour des comptes.

Des patterns éprouvés existent : GOV.UK et le DSFR documentent la question unique par page, le résumé d’erreurs et la page de vérification. Pris comme références, non copiés. La méthode du langage clair de la DITP a guidé les libellés.

• RGAA 4.1.2, DINUM, référentiel en vigueur. RGAA 5 annoncé pour fin 2026, DINUM, 4 mars 2026.
• Loi 2005-102, article 47, et décret 2019-768 du 24 juillet 2019.
• Article 47-1, ordonnance 2023-859 du 6 septembre 2023 : contrôle par l’Arcom.
• European Accessibility Act, applicable depuis le 28 juin 2025.
• Cour des comptes, 18 juin 2026 : 16 démarches essentielles sur 244 pleinement conformes en janvier 2026.
• Insee Focus 376, 19 février 2026 : illectronisme, 7 % des 16 à 74 ans en 2025.
• DITP, méthode du langage clair, ISO 24495-1:2023.
• GOV.UK Design System et DSFR : patterns de formulaire, cités comme références.

1. Piste 1 : un long formulaire sur une seule page. Toutes les questions visibles d’un coup. Écartée : charge cognitive forte pour un lecteur lent, erreurs regroupées trop loin des champs.
2. Piste 2 : des erreurs signalées par la couleur et une icône. Bordure rouge et pictogramme d’alerte, sans texte. Écartée : contraire à la règle « jamais la couleur seule ». L’utilisateur ne sait pas quoi corriger.
3. Piste 3 : un mode sombre à la place du contraste renforcé. Le mode sombre est attendu. Écartée : le besoin documenté est le contraste, pas la couleur du fond.

1. Une question par page, puis une page de vérification

L’écran. La demande d’acte de naissance se déroule en écrans successifs. Chaque écran pose une question : type d’acte, date. Une page de vérification récapitule les réponses, avec un lien « Modifier » par ligne. La confirmation clôt le parcours.

La règle. Une page, une question, un bouton. Toute correction passe par la page de vérification.

Le compromis. Plus de pages, plus de clics qu’un formulaire unique. J’ai accepté ce coût pour la clarté.

2. Les erreurs en deux endroits, en texte

L’écran. La question sur la date, en état d’erreur. Un résumé en tête de page liste les problèmes et pointe vers les champs. Sous le champ, un message dit quoi corriger, en langage clair.

La règle. Une erreur se lit toujours en texte, jamais par la couleur ou l’icône seules. Le résumé reçoit le focus pour que la technologie d’assistance l’annonce.

Le compromis. Le message apparaît deux fois. Redondance voulue, qui coûte de l’espace vertical.

3. Contraste renforcé et texte à 200 % comme modes de variables

L’écran. Les préférences d’affichage proposent le mode « Contraste renforcé » et la taille de texte. Deux écrans de question montrent le résultat dans chaque mode.

La règle. Les couleurs et les tailles de texte sont des variables Figma. La collection Color a deux modes, Standard et Contraste renforcé. La collection Text size a deux modes, 100 % et 200 %. Chaque écran se vérifie dans les quatre combinaisons. La paire de contraste texte la plus faible est à 5,3:1 en standard et 9,7:1 en renforcé.

Le compromis. Système plus lourd à maintenir : chaque nouveau composant se teste dans chaque mode avant d’entrer dans la bibliothèque.

Le reste du système suit la même logique. Typographie Atkinson Hyperlegible Next, liens soulignés, 12 pictogrammes vectoriels en deux tons. Pas de 3D, pas de verre sous le texte. L’anneau de focus est double, jaune à l’intérieur et sombre à l’extérieur, pour rester lisible sur tous les fonds. Conçu dans Figma avec un workflow augmenté par l’IA : Claude relié à Figma par MCP, dirigé et relu par le designer.

Non mesuré. Métrique : taux de démarches terminées sans aide, par type de technologie d’assistance. Relevé : test modéré avec lecteur d’écran et navigation clavier, puis audit RGAA du site une fois développé.

Chiffres comptés par script dans le fichier Figma, le 4 octobre 2026. Le pied de page des écrans indique « Accessibilité : statut à déclarer après audit ».

Partir de l’accessibilité change l’ordre des décisions. Contraste, focus et texte des erreurs se décident avant la couleur de marque. Les modes de variables ont rendu ce test systématique : un écran qui casse à 200 % se voit tout de suite.

J’ai aussi appris la limite d’une maquette. Elle montre des contrastes calculés et des critères cités. Elle ne peut pas être conforme. La conformité se déclare après l’audit d’un site réel.

Transparence

• ClientAucun. Commune fictive, projet personnel, données d’exemple.
• RechercheDocumentaire, sur des sources publiques datées du 4 octobre 2026. Aucun entretien.
• Test utilisateurNon réalisé. Aucun test avec technologies d’assistance, aucun audit sur un site réel.
• AccessibilitéContrastes calculés paire par paire. Ni audit ni déclaration de conformité : une maquette ne peut pas être « conforme RGAA ».

Voir sur DribbbleL’offre que ce projet illustre