106 critères de contrôle : c’est le nombre exact que couvre le référentiel général d’amélioration de l’accessibilité (RGAA) dans sa version 4.1, applicable aux services publics numériques. Un bloc de formulaire de saisine citoyenne, livré pour un site intercommunal, devait s’y conformer sans exception, tout en respectant en parallèle le principe de minimisation des données du RGPD. Les deux exigences, loin de s’opposer, se sont révélées largement complémentaires une fois le travail engagé.
Le formulaire permet à un habitant de signaler un problème sur la voie publique (éclairage, voirie, propreté) avec localisation, description et coordonnées de contact. Une demande initiale prévoyait bien plus de champs — numéro de téléphone fixe et mobile, date de naissance, numéro de dossier fiscal — qui n’avaient aucune utilité pour traiter un signalement de nid-de-poule.
Minimiser avant d’accessibiliser
La première étape n’a pas été de coder, mais de réduire la liste des champs à ce qui sert réellement le traitement du signalement : catégorie de problème, description, localisation (via une carte ou une adresse saisie), et un seul moyen de contact au choix (e-mail ou téléphone, pas les deux imposés). Chaque champ retiré de la maquette initiale l’a été après une question simple posée au service instructeur : « qui consulte ce champ, et pour en faire quoi ? ». Sans réponse claire, le champ disparaissait.
Cette réduction a un effet direct sur l’accessibilité : un formulaire plus court comporte mécaniquement moins de points de friction pour un utilisateur de lecteur d’écran ou de navigation au clavier. Minimisation des données et accessibilité tirent ici dans le même sens plutôt que de s’opposer.
Ce que le bloc a dû garantir techniquement
Le bloc est un bloc dynamique avec rendu serveur, choisi précisément pour garder la main sur chaque attribut HTML généré — un impératif pour respecter le RGAA, qui descend jusqu’au niveau de l’attribut. Quelques exemples concrets retenus dans l’implémentation :
- Chaque champ est associé à son étiquette via un
<label for>explicite, jamais un simple positionnement visuel du texte à côté du champ. - Les champs obligatoires portent l’attribut
requiredet une indication textuelle visible (« champ obligatoire »), pas uniquement une couleur ou un astérisque isolé. - Les messages d’erreur de validation sont associés au champ concerné via
aria-describedby, et annoncés dynamiquement grâce à une zonearia-live="polite"plutôt que déplacés silencieusement en haut de page. - L’ordre de tabulation suit strictement l’ordre visuel du formulaire, vérifié manuellement au clavier, sans
tabindexpositif qui casserait cet ordre naturel. - Le contraste des textes d’erreur (rouge sur fond blanc) a été vérifié pour atteindre un ratio minimal de 4,5:1, conforme au critère de contraste du RGAA.
La carte de localisation, un point de friction RGAA classique
Le champ de localisation reposait initialement sur une carte interactive cliquable, sans alternative. Ce choix isolé aurait rendu le formulaire inutilisable au clavier et pour un utilisateur de lecteur d’écran. La solution retenue combine les deux approches : la carte reste disponible comme raccourci visuel, mais un champ de saisie d’adresse en texte libre, avec autocomplétion basée sur l’API Adresse du gouvernement, reste toujours la voie principale et pleinement accessible.
Validation côté serveur, pas seulement côté client
Le RGAA impose que la validation d’un formulaire fonctionne même en l’absence de JavaScript, ou lorsque celui-ci échoue à charger. Le bloc effectue donc une double validation : une validation JavaScript immédiate pour le confort visuel, et une validation PHP complète côté serveur au moment de la soumission, qui seule fait foi. Sans cette seconde couche, un utilisateur naviguant avec un script bloqué (extension de sécurité, mauvaise connexion) pourrait soumettre un formulaire invalide sans aucun retour.
if ( empty( $_POST['categorie'] ) || ! in_array( $_POST['categorie'], acme_categories_autorisees(), true ) ) {
$errors[] = 'categorie';
}
Sur un projet de service public, je considère l’accessibilité et la minimisation des données comme un seul et même chantier de conception, pas comme deux cases à cocher séparément en fin de projet : les décisions qui servent l’une servent presque toujours l’autre.
Bilan du projet
Ce formulaire n’a pas nécessité de prouesse technique particulière : la difficulté résidait dans la discipline de conception, pas dans le code. Réduire la collecte au strict nécessaire a simplifié l’accessibilité, et inversement, penser l’accessibilité dès la maquette a évité d’ajouter des champs superflus « au cas où ». La collectivité dispose aujourd’hui d’un bloc réutilisable sur d’autres démarches de saisine du même type, avec cette même base de validation à deux niveaux.
