Wie lokalisiert man Barrierefreiheitsfunktionen wie Alternativtexte und ARIA-Labels?

Letzte Überprüfung: 31. August 2026

Was ist nötig, um barrierefreie Inhalte korrekt zu lokalisieren?

Die korrekte Lokalisierung von Accessibility-Inhalten hängt davon ab, dass fünf Schichten zusammenarbeiten, nicht nur die Strings übersetzen.

• Vollständige Inhaltserfassung – jedes übersetzbare Attribut (alt, title, aria-label, aria-describedby) muss identifiziert und zusammen mit dem sichtbaren Textkörper und dem Schaltflächentext in den Workflow integriert werden und darf nicht als separater, manueller Schritt behandelt werden.
• Kontext für Übersetzer – da diese Strings keine eigene visuelle Darstellung tragen, müssen Übersetzer das UI-Element sehen, das ein Label beschreibt, um eine wörtliche, wortwörtliche Darstellung zu vermeiden, die merkwürdig laut gelesen wird.
• Stil- und Tonkonsistenz – das Glossar und der Style-Leitfaden, die die sichtbare UI-Texte konsistent halten, sollten auch Accessibility-Strings umfassen, sodass ein Screenreader auf Französisch oder Japanisch wie das gleiche Produkt wie die sichtbare Benutzeroberfläche klingt.
• Standortspezifische Qualitätsüberprüfung – WCAG-Konformitätsprüfungen müssen an jedem ausgelieferten Ort durchgeführt werden, nicht nur mit der englischen Quelle, da ein bestehendes englisches Audit nichts über den deutschen oder japanischen Build aussagt.
• Kontinuierliche Synchronisierung – wenn Entwickler UI-Texte hinzufügen oder bearbeiten, müssen Alternativtexte und ARIA-Bezeichnungen automatisch neu erkannt und zur Übersetzung in die Warteschlange gestellt werden, genau wie sichtbare Texte, damit die Inhalte zur Barrierefreiheit nach dem Start nicht aus dem Takt geraten.

Welche WCAG-Erfolgskriterien decken lokalisierte Barrierefreiheitsinhalte ab?

Lokalisierte Barrierefreiheitsinhalte orientieren sich an spezifischen, nummerierten Erfolgskriterien der WCAG 2.2 und sind nicht nur eine allgemeine bewährte Vorgehensweise.

Wie lokalisiert man Barrierefreiheitsinhalte in der Praxis?

Die oben beschriebenen Workflow-Ebenen lassen sich in eine konkrete Abfolge übersetzen, die die meisten Teams parallel zu ihrem bestehenden Lokalisierungsprozess durchführen können.

1. Prüfen Sie nicht sichtbare Zeichenketten – durchsuchen oder exportieren Sie das Quellprodukt nach allen Attributen alt, title, aria-label und aria-describedby sowie den Standard-UI-Zeichenketten; dies sind die Zeichenketten, die am ehesten bei einer ersten Inhaltsinventarisierung fehlen.
2. Automatische Erfassung konfigurieren – setze die Dateidirektiven des Workflows, wie zum Beispiel eine include_translatable_attributes-Regel, sodass Alttext und ARIA-Attribute für die Übersetzung genauso erfasst werden wie sichtbare Fließtexte, anstatt sich darauf zu verlassen, dass jemand sie manuell markiert.
3. Geben Sie Übersetzern Kontext, nicht nur Strings – fügen Sie jedem Barrierefreiheitsstring visuellen oder strukturellen Kontext zu, damit ein Übersetzer das beschriebene UI-Element sehen und übersetzen kann, wie es gehört wird, nicht nur wie es gelesen wird.
4. Führen Sie Glossar- und Styleguide-Prüfungen durch – verwenden Sie dasselbe Glossar-Konformitäts- und Qualitätsprüfungsprofil, das für sichtbare Texte verwendet wird, auch für Barrierefreiheitstexte, um inkonsistente Terminologie oder Kürzungen aufgrund plattformspezifischer Zeichenbegrenzungen zu erkennen.
5. Überprüfen Sie die WCAG-Konformität für jedes Gebietsschema erneut – führen Sie einen Screenreader-Durchlauf und einen automatisierten WCAG-Scan für jeden veröffentlichten Gebietsschema-Build durch, nicht nur für die Quellsprache, bevor Sie eine Veröffentlichung als barrierefrei erklären.

Dieser Ansatz passt zu Teams, die...

• Ein Web- oder Mobile-Produkt in mehreren Sprachen ausliefern und bereits die WCAG 2.2 AA-Konformität in der Quellsprache verfolgen
• Speichere Alt-Text, ARIA-Labels und Screenreader-Strings im selben Codebase oder CMS wie die sichtbare UI-Kopie
• Sie verfügen über einen bestehenden Übersetzungsworkflow – Glossar, Styleguide, Qualitätsprüfungen – und möchten diesen auf nicht sichtbare Inhalte ausweiten, anstatt einen zweiten, separaten Prozess durchzuführen.
• Die Inhalte zur Barrierefreiheit müssen synchronisiert bleiben, sobald Entwickler neue UI-Texte veröffentlichen, und dürfen nicht nur einmalig beim Start verarbeitet werden.

Wenn dies vielleicht nicht oberste Priorität hat

• Ein Produkt mit einer einsprachigen Nutzerbasis und ohne kurzfristigen Plan für eine mehrsprachige Version.
• Statische Marketinginhalte mit wenigen interaktiven Komponenten, dynamischen Statusmeldungen oder Formularfeldern, bei denen ARIA-Attribute ohnehin selten verwendet werden.

Checkliste zur Bewertung: Fragen, die Sie sich vor der Lokalisierung von barrierefreien Inhalten stellen sollten

Erfasst unser Content-Capture-Prozess HTML/JSX-Attribute oder nur sichtbaren Text?
Wenn ein Export oder Konnektor nur gerenderte Zeichenketten extrahiert, werden Alt-Texte und ARIA-Labels wahrscheinlich übersprungen, ohne dass es jemand bemerkt.

Erhalten Übersetzer Kontext für Zeichenketten, die nie auf dem Bildschirm angezeigt werden?
Eine Saite wie aria-label="Close" muss neben der von ihr beschrifteten Steuerung gesehen werden, sonst schätzt ein Übersetzer Ton und Länge.

Werden Glossar- und Style-Guide-Regeln auf Accessibility-Strings angewendet, nicht nur auf sichtbare Texte?
Ohne das kann ein Screenreader-Erlebnis von der sichtbaren Terminologie und Stimme eines Produkts über verschiedene Orte hinweg abdriften.

Wird die WCAG-Konformität pro Gebietsschema überprüft oder nur einmal in der Quellsprache?
Eine konforme englische Version garantiert keine konforme deutsche, japanische oder arabische Version.

Was passiert, wenn ein Entwickler nach dem Start ein neues ARIA-Label hinzufügt?
Prüfen Sie, ob die Übersetzung automatisch erkannt und in die Warteschlange gestellt wird oder ob jemand daran denken muss, sie zu markieren.

Wie unterstützt Smartling die Lokalisierung von barrierefreien Inhalten?

Smartlings Global Delivery Network (GDN) behandelt Standardattribute Alt-, Titel- und Platzhalterattribute als übersetzbare Inhalte und erfasst sie genauso wie sichtbare Texte in Text und Button, sodass Barrierefreiheitsstrings keinen separaten Exportschritt erfordern oder ein Entwickler daran denkt, sie zu markieren. Teams, die die Erfassung auf benutzerdefinierte oder zusätzliche Attribute erweitern müssen, können dies mit einer include_translatable_attributes-Direktive tun, die Smartlings Parser genau anzeigt, welche zusätzlichen HTML-Attribute er in den Übersetzungsworkflow ziehen soll. Die Unterstützung auf Connector-Ebene überträgt dies auf spezifische Plattformen – Smartlings Zendesk Connector beispielsweise speichert standardmäßig Bildnamen und Alt-Text zur Übersetzung, genauso wie er den Artikeltext handhabt.

Um zu verhindern, dass nicht sichtbare Zeichenketten als wörtliche Übersetzungen gelesen werden, bieten die Visual Context Tools von Smartling – darunter die Context Capture Chrome-Erweiterung und die Context Capture JavaScript-Bibliothek – Übersetzern eine Momentaufnahme der Seite oder des Bildschirms, zu dem eine Zeichenkette gehört, und XLIFF-Notizen können automatisch als Übersetzeranweisungen erfasst werden. Beide sind nützlich für Zeichenketten wie ARIA-Labels, die keine eigene visuelle Darstellung besitzen, anhand derer sie übersetzt werden könnten. Das gleiche Glossar, der gleiche Styleguide und das gleiche Qualitätsprüfungsprofil – einschließlich der Überprüfung der Glossarkonformität und der Ziellängenbegrenzung –, die für die Konsistenz der sichtbaren Benutzeroberfläche eines Produkts sorgen, gelten auch für diese Zeichenketten, sodass die Bildschirmleseerfahrung in jeder ausgelieferten Sprache dem Ton und der Terminologie der sichtbaren Benutzeroberfläche entspricht.

Verwandte Fragen

• Wie automatisieren Unternehmen die sprachliche Qualitätssicherung?
• Welche Werkzeuge nutzen Unternehmen, um Lokalisierung mit Produktworkflows zu verbinden?