Smartling nommé chef de file dans The Forrester Wave™ : services de localisation, 3e trimestre 2026.
Smartling nommé Leader dans The Forrester Wave™
Lire le rapport

Comment localiser les fonctionnalités d'accessibilité telles que le texte alternatif et les étiquettes 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 de caractères réservées aux lecteurs d'écran) dans toutes les langues dans lesquelles un produit est distribué. Comme ce contenu n'apparaît jamais à l'écran, c'est celui qui risque le plus d'être ignoré par un flux de travail de traduction basé sur le texte visible de l'interface utilisateur. Le réseau de distribution mondial (GDN) de Smartling capture par défaut ces attributs sous forme de chaînes traduisibles, puis applique le même glossaire, le même guide de style et les mêmes contrôles de qualité que ceux utilisés 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 toutes les langues, et pas seulement dans la langue source.

Dernière révision : 31 août 2026

Pourquoi le contenu d’accessibilité se perd-il dans la traduction?

Le texte alternatif, les étiquettes ARIA et les chaînes de lecture d’écran ne sont pas 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.

  • L’assurance qualité visuelle ne peut pas capter ce qui n’est pas visible. Un évaluateur, en cliquant 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 tout un passage QA sans que personne ne s’en rende compte.
  • Les attributs résident dans la marger, pas dans le corps du texte. alt, title, aria-label et aria-describedby se trouvent dans des attributs HTML ou JSX plutôt que dans un paragraphe ou un bouton, donc une exportation de contenu construite autour de chaînes visibles peut les ignorer complètement.
  • Les technologies d'assistance imposent leurs propres contraintes de longueur. Les étiquettes d'accessibilité mobile et les descriptions ARIA ont souvent des limites de caractères pratiques, de sorte qu'une traduction littérale, mot à mot, peut être tronquée ou lue maladroitement à voix haute.
  • La formulation d’un lecteur d’écran doit être entendue, pas seulement lue. Un lecteur d’écran récite 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.

Qu'est-ce qu'il faut 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 de caractères.

  • 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 — étant donné que ces chaînes de caractères ne comportent aucune représentation visuelle propre, les traducteurs doivent voir l'élément d'interface utilisateur décrit par une étiquette afin d'éviter une traduction littérale, mot à mot, qui sonne étrangement à l'oral.
  • Cohérence du style et du ton — le glossaire et le guide de style qui maintiennent la copie de l’interface visible cohérente devraient aussi s’étendre aux chaînes d’accessibilité, donc un lecteur d’écran en français ou japonais sonne comme le même produit que l’interface visible.
  • Vérification de qualité par localisation — Des vérifications de conformité WCAG doivent être effectuées sur chaque lieu expédié, pas seulement sur la source anglaise, puisqu’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é?

Le contenu d’accessibilité localisé correspond à des critères spécifiques et numérotés de réussite WCAG 2.2, pas seulement une bonne pratique générale.

Élément d’accessibilitéCritère de réussite WCAG 2.2Qu'est-ce qui ne fonctionne pas si ce n'est pas localisé ?
Texte alt de l'image1.1.1 Contenu non textuel (niveau A)Un lecteur d’écran dans la langue cible lit du texte alternatif anglais non traduit — ou rien — 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 une commande reste dans la langue source, ce qui peut induire en erreur les utilisateurs de lecteurs d'écran non anglophones.
Messages de statut (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 formulaire3.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 localiser concrètement le contenu accessible ?

Les couches de flux de travail 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.

  1. 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.
  2. Configurez la capture automatique — définissez les directives de fichier du flux de travail, comme une règle de include_translatable_attributes, afin que le texte alternatif et les attributs ARIA soient capturés pour traduction de la même manière que la copie visible du corps, au lieu de dépendre manuellement de quelqu’un qui les signale.
  3. Donnez du contexte aux traducteurs, pas seulement des strings — attachez un contexte visuel ou structurel à chaque chaîne d’accessibilité afin qu’un traducteur puisse voir l’élément d’interface qu’il décrit et le traduire selon la façon dont il sera entendu, pas seulement comment il sera lu.
  4. Appliquez des vérifications de glossaire et de guide de style — exécutez le même profil de conformité et de contrôle de la 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 propres à la plateforme.
  5. Revérifiez la conformité aux WCAG pour chaque langue — effectuez une analyse par lecteur d'écran et une analyse WCAG automatisée sur chaque version publiée pour chaque langue, et pas seulement sur la langue source, avant de déclarer une version comme étant entièrement accessible.

Cette approche convient aux équipes qui...

  • Livrez un produit web ou mobile en plusieurs langues et suivez déjà la conformité AA WCAG 2.2 dans le langage 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 comme copie visible de l’interface utilisateur
  • Ils ont déjà un flux de travail de traduction (glossaire, guide de style, contrôles de qualité) qu'ils souhaitent étendre au contenu non visible, sans avoir à exécuter un deuxième processus distinct.
  • Il est nécessaire que le contenu d'accessibilité reste synchronisé à mesure que les développeurs déploient de nouvelles chaînes d'interface utilisateur, et ne soit pas seulement géré une seule fois au lancement.

Quand ce 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 composantes interactives, des messages d’état dynamiques ou des champs de formulaire, où les attributs ARIA sont rarement utilisés à la base

Liste de vérification pour l'évaluation : Questions à se poser avant de localiser le contenu d'accessibilité

Notre processus de saisie de contenu extrait-il les attributs HTML/JSX ou seulement le texte visible ?
Si un export ou un connecteur n’extrait que des chaînes de caractères rendues, le texte alternatif et les étiquettes ARIA sont probablement sauté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 à côté du contrôle qu’elle étiquette, 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 selon la région, ou seulement une fois dans la langue source?
Une version anglaise conforme ne garantit pas une version allemande, japonaise ou arabe conforme.

Que se passe-t-il lorsqu’un développeur ajoute une nouvelle étiquette ARIA après le lancement?
Confirme si c’est automatiquement détecté et mis en file d’attente pour traduction, ou si ça dépend que quelqu’un se souvienne de le 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 textes visibles du corps et des boutons, donc les chaînes d’accessibilité ne nécessitent pas une étape d’exportation séparée ni qu’un développeur pense à les signaler. Les équipes qui doivent étendre la capture à des attributs personnalisés ou additionnels 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, intègre 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 éviter que les chaînes de caractères non visibles ne soient interprétées comme des traductions littérales, les outils de contexte visuel de Smartling — notamment l'extension Chrome Context Capture et la bibliothèque JavaScript Context Capture — offrent aux traducteurs un aperçu 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 pour le traducteur. Les deux sont utiles pour une chaîne de caractères comme une étiquette ARIA, qui n'a pas de rendu visuel propre sur lequel se baser pour la traduction. Le même glossaire, le même guide de style et le même profil de contrôle qualité — y compris les contrôles de conformité du glossaire et de limite de longueur cible — qui assurent la cohérence de l'interface utilisateur visible d'un produit s'appliquent également à ces chaînes de caractères, de sorte que l'expérience du lecteur d'écran corresponde au ton et à la terminologie de l'interface visible dans chaque langue déployée.

Questions connexes

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 fournissant des traductions de la plus haute qualité, plus rapidement et à des coûts nettement inférieurs.

Prendre un rendez-vous