How do you localize accessibility features like alt text and ARIA labels for a multilingual product?

Localizing accessibility features means translating alt text, ARIA labels, and other screen-reader-only strings into every language a product ships in, using the same style guide and quality checks applied to visible UI copy, so screen-reader users get a natural, WCAG-conformant experience in every locale.

Hoe lokaliseer je toegankelijkheidsfuncties zoals alt-tekst en ARIA-labels?

Het lokaliseren van toegankelijkheidsfuncties betekent het vertalen en aanpassen van de niet-zichtbare tekst die hulpmiddelen hardop voorleest — alt-tekst, ARIA-labels en alleen schermlezer-strings — naar elke taal waarin een product wordt geleverd. Omdat deze content nooit op het scherm wordt weergegeven, is het de content die het meest waarschijnlijk wordt overgeslagen door een vertaalworkflow die is gebouwd rond zichtbare UI-teksten. Smartling's Global Delivery Network (GDN) legt deze attributen standaard vast als vertaalbare strings en past vervolgens dezelfde woordenlijst, stijlgids en kwaliteitscontroles toe als voor zichtbare teksten, zodat gebruikers van schermlezers een natuurlijke, WCAG-conforme ervaring krijgen op elke locatie, niet alleen in de brontaal.

Waarom raakt toegankelijkheidsinhoud verloren in de vertaling?

Alt-tekst, ARIA-labels en schermlezer-strings worden om een specifieke, terugkerende reeks redenen niet vertaald — niet omdat teams niet geven om toegankelijkheid, maar omdat standaard lokalisatieworkflows zijn gebouwd rond wat een reviewer kan zien.

Visuele QA kan niet vastleggen wat niet zichtbaar is. Een reviewer die door een vertaalde site of app klikt, controleert wat er op het scherm wordt weergegeven, zodat alt-tekst en ARIA-labels in het Engels kunnen blijven tijdens een hele QA-pass zonder dat iemand het merkt.
Attributen bevinden zich in de markup, niet in de bodytekst. De attributen `alt`, `title`, `aria-label` en `aria-describedby` bevinden zich binnen HTML- of JSX-attributen in plaats van in alinea- of knoptekst. Een contentexport die is opgebouwd rond zichtbare strings kan deze attributen dus volledig overslaan.
Hulpmiddelen stellen haar eigen lengtebeperkingen. Toegankelijkheidslabels voor mobiele apparaten en ARIA-beschrijvingen hebben vaak een praktisch tekenlimiet, waardoor een letterlijke, woord-voor-woord vertaling kan worden afgekapt of onhandig kan klinken bij het hardop lezen.
De formulering van schermlezer moet gehoord worden, niet alleen gelezen. Een schermlezer spreekt de snaar precies zoals geschreven; een vertaling die wordt gemaakt alsof hij alleen op een pagina gelezen zou worden, kan hardop houterig of onnatuurlijk klinken.
De WCAG-conformiteit wordt doorgaans eenmaal gecontroleerd, in de brontaal. Veel toegankelijkheidsaudits voeren slechts één WCAG 2.2 AA-scan in het Engels uit en herhalen deze niet per taal. Hierdoor kan een taalspecifieke fout – een ontbrekend vertaald label of een defecte aria-describedby-referentie – onopgemerkt blijven.

Wat is er nodig om toegankelijkheidscontent correct te lokaliseren?

Het correct lokaliseren van toegankelijkheidscontent hangt af van vijf lagen die samenwerken, niet alleen het vertalen van de strings.

Volledige contentregistratie — elk vertaalbaar attribuut (alt, title, aria-label, aria-describedby) moet worden geïdentificeerd en in de workflow worden opgenomen samen met de zichtbare body- en knoptekst, en mag niet als een aparte, handmatige stap worden behandeld.
Context voor vertalers — omdat deze tekstfragmenten geen eigen visuele weergave hebben, moeten vertalers het UI-element zien dat een label beschrijft om te voorkomen dat een letterlijke, woord-voor-woord vertaling vreemd klinkt tijdens het spreken.
Stijl- en toonconsistentie — de woordenlijst en stijlgids die de zichtbare UI-tekst consistent houden, moeten ook gelden voor toegankelijkheidsteksten, zodat een schermlezer in het Frans of Japans klinkt als hetzelfde product als de zichtbare interface.
Kwaliteitscontrole per locatie — WCAG-conformiteitscontroles moeten worden uitgevoerd op elke verzonden locatie, niet alleen op de Engelse bron, aangezien een goedgekeurde Engelse audit niets zegt over de Duitse of Japanse versie.
Continue synchronisatie — wanneer ontwikkelaars UI-teksten toevoegen of bewerken, moeten alternatieve tekst en ARIA-labels automatisch opnieuw worden gedetecteerd en in de wachtrij worden geplaatst voor vertaling, net zoals bij zichtbare tekst, zodat de toegankelijkheidsinhoud na de lancering niet uit synchronisatie raakt.

Welke WCAG-succescriteria dekken lokale toegankelijkheidsinhoud?

Gelokaliseerde toegankelijkheidsinhoud sluit aan bij specifieke, genummerde WCAG 2.2 succescriteria, niet zomaar een algemene goede praktijk.

Toegankelijkheidselement	WCAG 2.2 Succescriterium	Wat gaat er mis als het niet gelokaliseerd is?
Afbeelding alt tekst	1.1.1 Niet-tekstuele inhoud (niveau A)	Een schermlezer in de doeltaal leest onvertaalde Engelse alt-tekst — of niets — in plaats van de afbeelding te beschrijven
ARIA-labels (aria-label, aria-labelledby)	4.1.2 Naam, rol, waarde (niveau A)	De toegankelijke naam die voor een knop of bedieningselement wordt aangekondigd, blijft in de brontaal, wat verwarrend kan zijn voor gebruikers van schermlezers die geen Engels spreken.
Statusberichten (aria-live regio's)	4.1.3 Statusberichten (Niveau AA)	Een dynamische update, zoals een cartridge-bevestiging, wordt alleen in het Engels aangekondigd, ongeacht de interfacetaal
Labels en instructies voor formuliervelden	3.3.2 Etiketten of instructies (niveau A)	Niet-vertaalde instructies zorgen ervoor dat gebruikers van schermlezer niet begrijpen wat een veld vereist

Hoe lokaliseer je in de praktijk toegankelijkheidsinhoud?

De bovenstaande workflowlagen vertalen zich in een concrete volgorde die de meeste teams naast hun bestaande lokalisatieproces kunnen uitvoeren.

Controleer niet-zichtbare tekenreeksen — crawl of exporteer het bronproduct voor elk alt-, title-, aria-label- en aria-describedby-attribuut naast de standaard UI-tekenreeksen; dit zijn de tekenreeksen die het meest waarschijnlijk ontbreken in een eerste inventarisatie van de inhoud.
Configureer automatische vastlegging — stel de bestandsrichtlijnen van de workflow in, zoals een include_translatable_attributes-regel, zodat alt-tekst en ARIA-attributen op dezelfde manier worden vastgelegd voor vertaling als de zichtbare tekst in de body, in plaats van dat iemand ze handmatig moet markeren.
Geef vertalers context, niet alleen strings — koppel visuele of structurele context aan elke toegankelijkheidsstring zodat een vertaler het UI-element kan zien dat het beschrijft en het kan vertalen naar hoe het gehoord zal worden, niet alleen hoe het gelezen zou worden.
Voer controles uit op de woordenlijst en stijlgids — pas hetzelfde profiel voor naleving van de woordenlijst en kwaliteitscontrole dat voor zichtbare tekst wordt gebruikt toe op toegankelijkheidsstrings, waarbij inconsistente terminologie of afkapping ten opzichte van platformspecifieke tekenlimieten wordt opgespoord.
Controleer de WCAG-conformiteit per landcode opnieuw : voer een schermlezercontrole en een geautomatiseerde WCAG-scan uit voor elke gepubliceerde landcodeversie, niet alleen voor de brontaal, voordat u een release als volledig toegankelijk verklaart.

Deze aanpak past bij teams die...

Lever een web- of mobiel product in meerdere talen en houd al bij of het voldoet aan WCAG 2.2 AA in de brontaal.
Sla alt-tekst, ARIA-labels en schermlezerstrings op in dezelfde codebase of CMS als zichtbare UI-kopie
Ze hebben een bestaande vertaalworkflow — woordenlijst, stijlgids, kwaliteitscontroles — die ze willen uitbreiden naar niet-zichtbare content in plaats van een tweede, apart proces te starten.
Toegankelijkheidscontent moet synchroon blijven met nieuwe UI-strings die ontwikkelaars uitbrengen, en niet slechts eenmalig bij de lancering worden verwerkt.

Evaluatiechecklist: Vragen om te stellen voordat u toegankelijkheidscontent lokaliseert

Haalt ons contentcaptatieproces HTML/JSX-attributen op, of alleen zichtbare tekst?
Als een export of connector alleen weergegeven tekenreeksen extraheert, worden alternatieve tekst en ARIA-labels waarschijnlijk overgeslagen zonder dat iemand het merkt.

Krijgen vertalers context bij teksten die nooit op het scherm worden weergegeven?
Een tekenreeks zoals aria-label="Sluiten" moet samen met het betreffende besturingselement worden gezien, anders moet een vertaler de toon en lengte ervan raden.

Worden woordenlijst- en stijlgidsregels toegepast op toegankelijkheidsstrings, niet alleen op zichtbare teksten?
Zonder dat kan een schermlezerervaring afwijken van de zichtbare terminologie en stem van een product over locaties heen.

Wordt de WCAG-conformiteit per landinstelling gecontroleerd, of slechts eenmaal in de brontaal?
Een conforme Engelse build garandeert geen conforme Duitse, Japanse of Arabische build.

Wat gebeurt er als een ontwikkelaar na de lancering een nieuw ARIA-label toevoegt?
Bevestig of het automatisch wordt gedetecteerd en in de wachtrij voor vertaling wordt geplaatst, of dat het ervan afhangt of iemand eraan denkt om het te markeren.

Hoe ondersteunt Smartling het lokaliseren van toegankelijkheidscontent?

Smartling's Global Delivery Network (GDN) behandelt standaardattributen alt, titel en placeholder-attributen als vertaalbare inhoud, en legt ze vast zoals het zichtbare teksten in de hoofd- en knoppen vastlegt, zodat toegankelijkheidsstrings geen aparte exportstap of een ontwikkelaar nodig hebben die ze niet markeert. Teams die capture moeten uitbreiden naar aangepaste of extra attributen kunnen dit doen met een include_translatable_attributes-richtlijn, die Smartling's parser precies vertelt welke extra HTML-attributen in de vertaalworkflow moeten worden gehaald. Connector-ondersteuning draagt dit door naar specifieke platforms — Smartling's Zendesk Connector bijvoorbeeld verwerkt standaard afbeeldingsnamen en alt-tekst voor vertaling, op dezelfde manier als het artikeltekst verwerkt.

Om te voorkomen dat niet-zichtbare tekstfragmenten als letterlijke vertalingen worden gelezen, bieden de Visual Context-tools van Smartling – waaronder de Context Capture Chrome-extensie en de Context Capture JavaScript-bibliotheek – vertalers een momentopname van de pagina of het scherm waartoe een tekstfragment behoort. XLIFF-notities kunnen automatisch worden vastgelegd als instructies voor de vertaler. Beide zijn nuttig voor een tekenreeks zoals een ARIA-label, dat geen eigen visuele weergave heeft om tegen te vertalen. Dezelfde woordenlijst, stijlgids en kwaliteitscontroleprofielen – inclusief controles op naleving van de woordenlijst en maximale lengte – die de zichtbare gebruikersinterface van een product consistent houden, gelden ook voor deze strings. Zo komt de schermlezerervaring overeen met de toon en terminologie van de zichtbare interface in elke uitgebrachte taal.