Des dizaines de cases sans nom pour l’IBAN, des cases à cocher sans intitulé, une police de coche manquante : comment les formulaires remplissables d’une administration sont devenus automatiquement conformes à PDF/UA-1 – et ce qui reste malgré tout du travail manuel.
Exemple anonymisé tiré d’un traitement réel ; le nom de l’organisation et le titre du document ont été modifiés.
Les formulaires PDF remplissables d’une administration communale – dont un mandat de prélèvement SEPA – étaient pratiquement impossibles à remplir pour les utilisateurs de lecteurs d’écran : pour l’IBAN, une longue série de champs sans nom était annoncée, et les cases à cocher n’avaient pas d’intitulé. Après la correction automatique, les formulaires ont atteint 100 points sur 100, et le rapport PAC n’a lui non plus montré aucune erreur. Restaient des questions auxquelles aucun contrôle de conformité ne répond : l’ordre de tabulation correspond-il à l’ordre visible, et les champs obligatoires et les intitulés sont-ils compréhensibles ?
Situation de départ
Avec un mandat de prélèvement SEPA, les citoyennes et citoyens autorisent l’administration à prélever des montants récurrents sur leur compte. Le formulaire est court mais dense : nom et adresse, IBAN et BIC dans des cases, cases à cocher, signature. D’autres formulaires électroniques de la même administration étaient construits de manière similaire. Tous étaient déjà remplissables – visuellement propres, avec une case par caractère de l’IBAN. Comme ces formulaires sont nécessaires à des procédures administratives en cours, l’exception prévue pour les fichiers anciens ne s’applique en général pas (voir Formulaires PDF accessibles).
Ce que le contrôle a révélé
- Champs en cases sans intitulé : chaque caractère de l’IBAN était un champ distinct sans info-bulle. Un lecteur d’écran annonçait des dizaines de champs de saisie sans nom les uns après les autres – sans indiquer à quoi ils servaient. PDF/UA-1 exige pour chaque champ de formulaire une info-bulle ou une description alternative dans la structure (règle veraPDF 7.18.1-3).
- Cases à cocher sans nom accessible : seul « case à cocher, non cochée » était annoncé – mais pas à quoi elle servait.
- Plusieurs champs dans un élément Form : selon PDF/UA-1, un élément Form sans attribut Role ne peut contenir qu’un seul champ (règle veraPDF 7.18.4-2).
- Police de coche non incorporée : la coche des cases provient de la police ZapfDingbats, qui n’était pas incorporée au document. PDF/UA-1 exige des polices incorporées (règle veraPDF 7.21.4.1-1).
- Polices des champs lacunaires : les polices du contenu des champs présentaient des largeurs de caractères manquantes ou incohérentes et un encodage incomplet (règles veraPDF 7.21.5-1 et 7.21.7-1).
Pour les utilisateurs voyants, rien de tout cela n’était perceptible : les cases étaient au bon endroit, la coche apparaissait au clic, et les intitulés étaient bien lisibles. Ils n’étaient cependant que du texte sur la page, sans lien avec les champs. Quiconque parcourt le formulaire avec la touche Tab et un lecteur d’écran ne sait donc pas quel champ a le focus – et, pour un IBAN de 22 caractères, peut difficilement savoir si un caractère a été sauté.
Ce que DokAudit a fait automatiquement
- Info-bulles pour les champs en cases : chaque position a reçu un nom unique selon le modèle « IBAN, caractère 5 sur 22 » – déduit de l’intitulé du groupe de champs et de la position.
- Noms pour les cases à cocher : tirés du texte d’intitulé situé juste à côté de la case.
- Un élément Form par champ : chaque champ de formulaire se trouve désormais dans son propre élément Form de la structure.
- Police de coche incorporée : ZapfDingbats a été remplacée par la police libre et métriquement identique URW D050000L – incorporée, avec largeurs de caractères et correspondance Unicode.
- Polices des champs corrigées : largeurs de caractères reprises du programme de police, encodage et correspondance Unicode complétés.
- Recontrôle : à nouveau avec veraPDF et ses propres contrôles de la structure logique.
Résultat
Chiffres clés de l’étude de cas sur les formulaires SEPA| Caractéristique | Avant | Après |
|---|
| Cases IBAN | champs sans nom | info-bulle par caractère, p. ex. « IBAN, caractère 5 sur 22 » |
|---|
| Cases à cocher | sans nom accessible | nom tiré de l’intitulé voisin |
|---|
| Éléments Form | plusieurs champs dans un élément | un élément Form par champ |
|---|
| Police de coche | ZapfDingbats, non incorporée | URW D050000L, incorporée |
|---|
| Polices des champs | largeurs et encodage incomplets | corrigés |
|---|
| Résultat global | PDF/UA-1 échoué | 100 points sur 100 ; rapport PAC sans erreur |
|---|
Ce qu’un humain devrait encore faire
- Vérifier l’ordre de tabulation : parcourir une fois le formulaire uniquement avec la touche Tab. L’ordre suit désormais la structure ; qu’il corresponde à l’ordre visible, par exemple dans des zones à deux colonnes, doit être jugé par un humain.
- Champs obligatoires et messages d’erreur : ils sortent du périmètre de PDF/UA, mais relèvent des critères WCAG (3.3.2 Étiquettes ou instructions). Signaler les champs obligatoires techniquement et visiblement, pas seulement par la couleur. Les messages d’erreur par script ne fonctionnent pas de manière fiable dans de nombreuses visionneuses.
- Intitulés compréhensibles : expliquer en une courte phrase des termes comme « identifiant créancier » (Gläubiger-Identifikationsnummer) ou « référence unique du mandat » (Mandatsreferenz) ; les info-bulles peuvent reprendre l’explication.
- Reconstruire lors de la prochaine révision : pour l’IBAN, un seul champ à cases de caractères vaut mieux que 22 champs individuels – un champ, une info-bulle, une saisie plus rapide.
- Envisager une alternative en ligne : là où une démarche en ligne existe, elle est plus accessible pour beaucoup de personnes que n’importe quel PDF.
Les enseignements à en tirer
- Les formulaires sont particulièrement critiques. Remplir un formulaire, ce n’est pas seulement lire, c’est agir. Un champ sans nom n’est pas ici une imperfection, mais une impasse.
- Les info-bulles sont obligatoires. PDF/UA-1 les exige pour chaque champ ; le critère WCAG 4.1.2 (Nom, rôle et valeur) exige que les technologies d’assistance puissent nommer chaque champ.
- La technique invisible compte. Personne ne voit une police de coche non incorporée – elle empêche pourtant la conformité.
- Conforme automatiquement ne veut pas dire facile à utiliser automatiquement. Le test à la touche Tab et un bref essai avec un lecteur d’écran font partie de chaque formulaire (Tester soi-même).
Sources:
État : 10/2026. Cet article donne une vue d’ensemble générale et ne constitue pas un conseil juridique. Font foi les textes de loi et de normes en vigueur ; dans certains cas, le droit d’un Land allemand peut différer.