Formulaires multilingues accessibles : RTL, lang, pluriels

Trois dimensions à internationaliser dans un formulaire

Un formulaire accessible et internationalisé doit piloter trois dimensions : (1) le contenu textuel (libellés, placeholders, options, messages d'erreur) à traduire via votre i18n. (2) la mise en page (RTL/LTR, espacements, alignement) selon la langue active. (3) la validation logique (formats de date, téléphone, code postal) qui varie selon les conventions locales. WCAG 3.3.1 exige que les messages d'erreur soient précisément localisés.

Attribut lang sur libellé et message d'erreur

WCAG 3.1.2 (niveau AA) impose d'identifier les passages en langue différente via l'attribut lang sur le conteneur. Pour un libellé multilingue (placeholder en anglais dans un formulaire français), entourez le passage de span lang=en. Pour les messages d'erreur localisés (arabe dans une interface française), enveloppez dans span lang=ar. Cela permet au lecteur d'écran de basculer automatiquement vers la langue du texte pour la synthèse vocale.

RTL : mirroring de l'interface, pas seulement du texte

Pour les langues à script RTL (ar, he, fa, ur), il ne suffit pas de renverser le texte : il faut aussi inverser la mise en page (sidebar à droite devient sidebar à gauche, icônes flèches inversées, alignements mirrorés). WCAG 1.4.12 couvre les espacements, mais le mirroring complet relève d'une convention culturelle. Utilisez les attributs dir=rtl ou dir=auto sur html ou sur les conteneurs. Pour les icônes directionnelles, proposez des variantes.

Format de date, séparateurs numériques et postaux

Chaque langue a ses conventions : JJ/MM/AAAA en français, MM/DD/YYYY en anglais américain, YYYY-MM-DD en ISO. Séparateur décimal : virgule en français, point en anglais. Séparateur de milliers : espace en français, virgule en anglais. Code postal : 5 chiffres en France, 4+2 en UK. Pour la validation, ne hardcodez jamais les patterns : exposez-les en configuration selon la locale. Utilisez le type input html=date qui s'adapte automatiquement.

Messages d'erreur localisés et pluriels

Les messages d'erreur sont un point critique : un message en français pour un utilisateur arabe échoue à l'accessibilité. Utilisez un système d'i18n qui sépare la logique de validation du rendu du message. Pour les pluriels, le français et l'arabe ont des règles différentes : votre bibliothèque i18n doit supporter les distinctions via les fichiers CLDR. Pour les bibliothèques connues : i18next gère les pluriels complexes (arabe, russe).

Tests lecteurs d'écran en plusieurs langues

Tester un formulaire multilingue suppose de valider chaque langue avec le lecteur d'écran adapté : NVDA + Firefox pour toute langue, VoiceOver + Safari pour vérifier les langues RTL (VoiceOver supporte l'arabe natif). JAWS pour configurations institutionnelles. Pour chaque langue, vérifiez : attribut lang annoncé en début de page, prononciation correcte des libellés, directions RTL respectées dans la navigation Tab, messages d'erreur restitués dans leur langue d'origine.

Questions fréquentes

Formulaire bilingue : faut-il dupliquer les champs ?

Non, un champ reste un champ : ce sont les libellés, placeholders et options qui sont dupliqués ou sélectionnés via i18n. Pour un formulaire bilingue, exposez deux langues en parallèle : chaque champ a deux libellés (un fr, un en) clairement séparés par lang, ou via une bascule explicite. Ne dupliquez jamais les champs (exemple : nom_en et nom_fr), c'est de la redondance.

RTL : quels pièges pour l'accessibilité ?

Trois pièges courants : (1) les icônes directionnelles non mirrorées (flèche droite qui reste à droite). (2) les alignements text-align=left ou right hardcodés qui ne s'adaptent pas au RTL. (3) les marges CSS directionnelles (margin-left, padding-right) qui doivent être mirrorées via les propriétés logiques margin-inline-start, padding-inline-end. Ces propriétés logiques CSS sont le pattern propre au RTL.

Format de date international : quel standard ?

Utilisez ISO 8601 (YYYY-MM-DD) en backend pour la portabilité, et le format local pour l'affichage utilisateur. Le input type=date en HTML5 respecte la locale du navigateur. Pour les masques visibles, proposez un placeholder adapté (JJ/MM/AAAA pour le français, MM/DD/YYYY pour l'anglais américain). Pour les utilisateurs en contexte global, le format ISO reste sans ambiguïté.

Comment localiser les messages d'erreur sans se perdre ?

Adoptez une clé d'erreur stable + une fonction de traduction. Par exemple : errors.required se traduit en Champ obligatoire en français, This field is required en anglais. Ne dupliquez JAMAIS vos messages en plusieurs endroits du code : centralisez-les dans un fichier errors.json chargé par votre système i18n. Pour les pluriels complexes, utilisez les bibliothèques i18n qui gèrent CLDR.

WCAG 3.1.2 : combien de langues dans une même page ?

WCAG 3.1.2 ne fixe pas de limite : vous pouvez avoir autant de langues dans une page que nécessaire, à condition de toutes les identifier via l'attribut lang. Cela dit, limitez-vous aux langues réellement nécessaires au contexte. Multiplier les fragments multilingues devient confus et peut nuire à la lecture.

EAA et multilinguisme : quels contrôles DGCCRF ?

Depuis le 28 juin 2025, l'EAA impose le niveau WCAG 2.1 AA aux services numériques privés. Pour un formulaire multilingue, les critères 3.1.1, 3.1.2 et 3.3.1 s'appliquent pleinement. Un passage en langue étrangère sans attribut lang est une non-conformité. La DGCCRF peut sanctionner de 7 500 € à 15 000 € les manquements constatés, et un formulaire B2C est un point de contrôle classique.