.svg)
.svg)
.svg)
%201Q26_%20GRC%202029.png?width=600&name=(CTA)%201Q26_%20GRC%202029.png)
.svg)
.svg)
Comment localisez-vous les fonctionnalités d’accessibilité comme le texte alternatif et les labels ARIA ?
Localiser les fonctionnalités d’accessibilité signifie traduire et adapter le texte non visible que la technologie d’assistance lit à voix haute — texte alternatif, étiquettes ARIA et chaînes uniquement en lecteur d’écran — dans chaque langue dans laquelle un produit est livré. Comme ce contenu ne se rend jamais à l’écran, c’est le contenu le plus susceptible d’être sauté par un flux de traduction construit autour d’un texte visible de l’interface. Le Global Delivery Network (GDN) de Smartling capture ces attributs sous forme de chaînes traduisibles par défaut, puis applique le même glossaire, le même guide de style et les mêmes contrôles de qualité que pour le texte visible afin que les utilisateurs de lecteurs d’écran bénéficient d’une expérience naturelle et conforme aux WCAG dans chaque région, pas seulement dans la langue source.
Dernière évaluation : 31 août 2026
Pourquoi les contenus d'accessibilité se perdent-ils dans la traduction ?
Le texte alternatif, les labels ARIA et les chaînes de lecteur d’écran restent non traduits pour un ensemble précis et récurrent de raisons — non pas parce que les équipes ne se soucient pas de l’accessibilité, mais parce que les flux de travail de localisation standards sont construits autour de ce qu’un évaluateur peut voir.
- Le contrôle qualité visuel ne peut pas capter ce qui n’est pas visible. Un critique qui clique sur un site ou une application traduite vérifie ce qui est affiché à l’écran, donc le texte alternatif et les labels ARIA peuvent rester en anglais pendant toute une passe QA sans que personne ne s’en rende compte.
- Les attributs résident dans la margée, pas dans le corps des textes. alt, title, aria-label et aria-describedby se trouvent dans des attributs HTML ou JSX plutôt que dans des paragraphes ou des boutons, donc une exportation de contenu construite autour de chaînes visibles peut les ignorer complètement.
- La technologie d’assistance impose ses propres contraintes de longueur. Les labels d’accessibilité mobile et les descriptions ARIA ont souvent des limites de caractères pratiques, donc une traduction littérale, mot à mot, peut être tronquée ou lue à voix haute de façon maladroite.
- La formulation d’un lecteur d’écran doit être entendue, pas seulement lue. Un lecteur d’écran prononce la corde exactement telle qu’elle est écrite ; une traduction produite comme si elle ne pouvait être lue que sur une page peut sembler maladroite ou artificielle à voix haute.
- La conformité aux WCAG est généralement vérifiée une seule fois, dans la langue source. De nombreux audits d'accessibilité effectuent une seule analyse WCAG 2.2 AA en anglais et ne la réexécutent pas pour chaque langue, de sorte qu'une régression spécifique à une langue (une étiquette traduite manquante, une référence aria-describedby cassée) peut passer inaperçue.
Que faut-il pour localiser correctement le contenu d'accessibilité ?
La localisation correcte du contenu d’accessibilité dépend de cinq couches qui travaillent ensemble, pas seulement de la traduction des chaînes.
- Capture complète du contenu — chaque attribut traduisible (alt, title, aria-label, aria-describedby) doit être identifié et intégré au flux de travail avec le texte visible du corps et des boutons, et non traité comme une étape manuelle distincte.
- Contexte pour les traducteurs — comme ces chaînes n’ont pas de rendu visuel propre, les traducteurs doivent voir l’élément UI décrit par une étiquette pour éviter un rendu littéral, mot à mot, qui se lit étrangement à voix haute.
- Style et tonalité — le glossaire et le guide de style qui maintiennent la cohérence de la copie visible de l’interface utilisateur devraient aussi s’étendre aux chaînes d’accessibilité, afin qu’un lecteur d’écran en français ou japonais ressemble au même produit que l’interface visible.
- Vérification qualité par localisation — Des vérifications de conformité WCAG doivent être effectuées sur chaque lieu expédié, pas seulement sur la source anglaise, car un audit anglais réussi ne dit rien sur la version allemande ou japonaise.
- Synchronisation continue — à mesure que les développeurs ajoutent ou modifient des chaînes d’interface utilisateur, le texte alternatif et les étiquettes ARIA doivent être redétectés et remis en file d’attente pour la traduction automatiquement, de la même manière que les chaînes visibles, afin que le contenu d’accessibilité ne se désynchronise pas après le lancement.
Quels critères de réussite WCAG couvrent le contenu d’accessibilité localisée ?
Le contenu d’accessibilité localisé correspond à des critères spécifiques et numérotés de réussite WCAG 2.2, et non seulement une bonne pratique générale.
| Élément d’accessibilité | Critère de réussite WCAG 2.2 | Qu’est-ce qui casse si ce n’est pas localisé |
|---|---|---|
| Texte alt de l'image | 1.1.1 Contenu non textuel (niveau A) | Un lecteur d'écran dans la langue cible lit le texte alternatif anglais non traduit — ou rien du tout — au lieu de décrire l'image. |
| Étiquettes ARIA (aria-label, aria-labelledby) | 4.1.2 Nom, rôle, valeur (niveau A) | Le nom accessible annoncé pour un bouton ou un contrôle reste dans la langue source, ce qui embrouille les utilisateurs de lecteurs d’écran non anglophones |
| Messages d'état (régions aria-live) | 4.1.3 Messages d'état (niveau AA) | Une mise à jour dynamique, comme une confirmation de panier, est annoncée uniquement en anglais, quelle que soit la langue de l'interface. |
| Étiquettes et instructions des champs de formulaire | 3.3.2 Étiquettes ou instructions (niveau A) | Les instructions non traduites laissent les utilisateurs de lecteurs d’écran incapables de comprendre ce qu’un champ exige |
Comment localisez-vous en pratique le contenu accessible ?
Les différentes couches du flux de travail décrites ci-dessus se traduisent par une séquence concrète que la plupart des équipes peuvent exécuter en parallèle de leur processus de localisation existant.
- Audit des chaînes non visibles — explorez ou exportez le produit source pour chaque attribut alt, title, aria-label et aria-describedby ainsi que les chaînes d'interface utilisateur standard ; ce sont les chaînes les plus susceptibles d'être absentes d'un inventaire de contenu initial.
- Configurez la capture automatique — définissez les directives de fichier du flux de travail, telles qu'une règle include_translatable_attributes, afin que le texte alternatif et les attributs ARIA soient capturés pour la traduction de la même manière que le texte corporel visible, au lieu de compter sur le signalement manuel par une personne.
- Donnez du contexte aux traducteurs, pas seulement des conditions — attachez un contexte visuel ou structurel à chaque chaîne d’accessibilité afin qu’un traducteur puisse voir l’élément de l’interface utilisateur décrit et le traduire selon la manière dont il sera entendu, pas seulement la manière dont il serait lu.
- Appliquez des vérifications de glossaire et de guide de style — exécutez le même profil de conformité et de contrôle qualité du glossaire utilisé pour le texte visible sur les chaînes d'accessibilité, en détectant les incohérences terminologiques ou les troncatures par rapport aux limites de caractères spécifiques à la plateforme.
- Revérifiez la conformité WCAG par localisation — effectuez un passage de lecteur d’écran et un scan WCAG automatisé sur chaque compilation de localisation publiée, pas seulement sur le langage source, avant de déclarer une version accessible complète.
Cette approche convient aux équipes qui...
- Déployez un produit web ou mobile en plusieurs langues et assurez-vous déjà la conformité aux normes WCAG 2.2 AA dans la langue source.
- Stockez du texte alternatif, des étiquettes ARIA et des chaînes de lecteur d’écran dans la même base de code ou CMS en tant que copies visibles de l’interface utilisateur
- Avoir un flux de travail de traduction existant — glossaire, guide de style, contrôles qualité — ils souhaitent étendre au contenu non visible au lieu d’exécuter un second processus séparé
- Il faut que le contenu d’accessibilité reste synchronisé pendant que les développeurs envoient de nouvelles chaînes d’interface, pas seulement une fois au lancement
Quand cela n’est peut-être pas la priorité absolue
- Un produit destiné à une seule langue et sans projet de version multilingue à court terme.
- Contenu marketing statique avec peu de composants interactifs, de messages d’état dynamiques ou de champs de formulaire, où les attributs ARIA sont rarement utilisés à l’origine
Liste de vérification pour l'évaluation : Questions à se poser avant de localiser le contenu d'accessibilité
Notre processus de capture de contenu extrait-il des attributs HTML/JSX, ou seulement du texte visible ?
Si un export ou un connecteur ne fait que retirer des chaînes rendues de caractère, le texte alternatif et les étiquettes ARIA sont probablement ignorés sans que personne ne s’en rende compte.
Les traducteurs reçoivent-ils le contexte des chaînes de caractères qui ne s'affichent jamais à l'écran ?
Une chaîne comme aria-label="Close » doit être vue aux côtés du contrôle qu’elle indique, sinon un traducteur devine le ton et la longueur.
Les règles du glossaire et du guide de style s'appliquent-elles aux chaînes d'accessibilité, et pas seulement au texte visible ?
Sans cela, l'expérience de lecture d'écran peut s'éloigner de la terminologie et de la voix visibles du produit selon les régions.
La conformité WCAG est-elle vérifiée par localité, ou seulement une fois dans la langue source ?
Une version anglaise conforme ne garantit pas une version conforme allemande, japonaise ou arabe.
Que se passe-t-il lorsqu'un développeur ajoute une nouvelle étiquette ARIA après le lancement ?
Confirmez si elle est automatiquement détectée et mise en file d’attente pour traduction, ou si cela dépend du fait que quelqu’un se souvienne de la signaler.
Comment Smartling prend-il en charge la localisation du contenu accessible ?
Le Global Delivery Network (GDN) de Smartling traite par défaut les attributs alt, titre et placeholder comme du contenu traduisible, les capturant de la même manière qu’il capture les copies visibles du corps et des boutons, afin que les chaînes d’accessibilité ne nécessitent pas une étape d’exportation séparée ni qu’un développeur se souvienne de les signaler. Les équipes qui doivent étendre la capture à des attributs personnalisés ou supplémentaires peuvent le faire avec une directive include_translatable_attributes, qui indique à l’analyseur de Smartling exactement quels attributs HTML supplémentaires intégrer dans le flux de traduction. Le support au niveau du connecteur transmet cela à des plateformes spécifiques — le Zendesk Connector de Smartling, par exemple, ingère par défaut les noms des images et le texte alternatif pour la traduction, de la même manière qu’il gère le corps des articles.
Pour empêcher les chaînes non visibles de se lire comme des traductions littérales, les outils de Visual Context de Smartling — y compris l’extension Chrome Context Capture et la bibliothèque JavaScript Context Capture — offrent aux traducteurs un instantané de la page ou de l’écran auquel appartient une chaîne, et les notes XLIFF peuvent être capturées automatiquement sous forme d’instructions traductrices. Les deux sont utiles pour une chaîne comme une étiquette ARIA, qui n’a pas de rendu visuel propre pour traduire. Le même glossaire, guide de style et profil de contrôle qualité — incluant la conformité au glossaire et les limites de longueur cible — qui maintiennent l’interface visible d’un produit cohérente s’appliquent également à ces chaînes, afin qu’une expérience lecteur d’écran corresponde au ton et à la terminologie de l’interface visible dans chaque lieu expédié.
Prêt à voir Smartling en action ?
Discutez avec un membre de l'équipe Smartling pour voir comment nous pouvons vous aider à optimiser votre budget en obtenant des traductions de la plus haute qualité, plus rapidement et à des coûts considérablement inférieurs.