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.

Hur lokaliserar du tillgänglighetsfunktioner som alternativtext och ARIA-etiketter?

Lokalisering av tillgänglighetsfunktioner innebär att översätta och anpassa den icke-synliga texten som hjälpmedelstekniken läser högt - alt-text, ARIA-etiketter och skärmläsbara strängar - till alla språk en produkt levereras på. Eftersom det här innehållet aldrig återges på skärmen är det det innehåll som mest sannolikt kommer att hoppas över av ett översättningsarbetsflöde byggt kring synlig användargränssnittskopia. Smartlings Global Delivery Network (GDN) fångar dessa attribut som standard som översättningsbara strängar och tillämpar sedan samma ordlista, stilguide och kvalitetskontroller som används för synlig kopia så att skärmläsaranvändare får en naturlig, WCAG-överensstämmande upplevelse på alla språk, inte bara källspråket.

Varför försvinner tillgänglighetsinnehåll i översättning?

Alternativ text, ARIA-etiketter och skärmläsarsträngar översätts av en specifik, återkommande uppsättning skäl - inte för att team inte bryr sig om tillgänglighet, utan för att standardlokaliseringsarbetsflöden bygger på vad en granskare kan se.

Visual QA kan inte fånga det som inte är synligt. En granskare som klickar på en översatt webbplats eller app kontrollerar vad som återges på skärmen, så att alternativ text och ARIA-etiketter kan förbli på engelska genom ett helt QA-pass utan att någon märker det.
Attribut finns i markering, inte brödtext. alt, title, aria-label och aria-describedby sitter i HTML- eller JSX-attribut snarare än stycke- eller knapptext, så en innehållsexport byggd kring synliga strängar kan hoppa över dem helt.
Hjälpteknik ställer sina egna längdbegränsningar. Mobila tillgänglighetsetiketter och ARIA-beskrivningar har ofta praktiska teckengränser, så en bokstavlig, ord-för-ord-översättning kan avkortas eller läsas besvärligt högt.
Skärmläsarens frasering måste höras, inte bara läsas. En skärmläsare talar strängen exakt som skriven; en översättning som produceras som om den bara någonsin skulle läsas på en sida kan låta stillad eller onaturlig högt.
WCAG-överensstämmelse verifieras vanligtvis en gång, på källspråket. Många tillgänglighetsgranskningar kör en enda WCAG 2.2 AA-skanning på engelska och kör inte om den per språk, så en lokal specifik regression — en saknad översatt etikett, en trasig aria-beskriven referens — kan skickas oupptäckt.

Vad krävs för att lokalisera tillgänglighetsinnehåll korrekt?

Korrekt lokalisering av tillgänglighetsinnehåll beror på att fem lager arbetar tillsammans, inte bara översätter strängarna.

Fullständig innehåll sinspelning — varje översättbart attribut (alt, title, aria-label, aria-descripbedby) måste identifieras och dras in i arbetsflödet tillsammans med synlig brödtext och knapptext, inte behandlas som ett separat, manuellt steg.
Kontext för översättare — eftersom dessa strängar inte har någon egen visuell återgivning måste översättarna se gränssnittselementet som en etikett beskriver för att undvika en bokstavlig, ord-för-ord-ord-rendering som läses konstigt högt.
Stil- och tonkonsistens - ordlistan och stilguiden som håller synlig användargränssnittskopia konsekvent bör också omfatta tillgänglighetssträngar, så en skärmläsare på franska eller japanska låter som samma produkt som det synliga gränssnittet.
Kvalitetsverifiering per lokal — WCAG-överensstämmelsekontroller måste köras mot varje levererad lokal, inte bara den engelska källan, eftersom en godkänd engelsk granskning inte säger något om den tyska eller japanska versionen.
Pågående synkronisering — eftersom utvecklare lägger till eller redigerar gränssnittssträngar måste alt-text och ARIA-etiketter upptäckas igen och ställas i kö för översättning automatiskt, på samma sätt som synliga strängar är, så tillgänglighetsinnehållet försvinner inte ur synk efter lanseringen.

Vilka WCAG-framgångskriterier täcker lokaliserat tillgänglighetsinnehåll?

Lokaliserat tillgänglighetsinnehåll mappar till specifika, numrerade WCAG 2.2-framgångskriterier, inte bara en allmän god praxis.

Tillgänglighetselement	WCAG 2.2 Framgångskriterium	Vad går sönder om det inte är lokaliserat
Bild alt text	1.1.1 Icke-textinnehåll (nivå A)	En skärmläsare på målspråket läser oöversatt engelsk alt-text — eller ingenting — istället för att beskriva bilden
ARIA-etiketter (aria-etikett, aria-labelledby)	4.1.2 Namn, roll, värde (nivå A)	Det tillgängliga namnet som tillkännages för en knapp eller kontroll förblir på källspråket, vilket förvirrar användare som inte är engelska skärmläsare
Statusmeddelanden (aria-live-regioner)	4.1.3 Statusmeddelanden (Nivå AA)	En dynamisk uppdatering, som en kundvagnsbekräftelse, meddelas endast på engelska oavsett gränssnittsspråk
Formulärfältetiketter och instruktioner	3.3.2 Etiketter eller instruktioner (nivå A)	Oöversatta instruktioner gör att skärmläsaranvändare inte kan förstå vad ett fält kräver

Hur lokaliserar du tillgänglighetsinnehåll i praktiken?

Arbetsflödeslagren ovan översätts till en konkret sekvens som de flesta team kan köra tillsammans med sin befintliga lokaliseringsprocess.

Granska icke-synliga strängar — genomsök eller exportera källprodukten för varje alt-, title-, aria-label- och aria-describedby-attribut tillsammans med vanliga UI-strängar; det här är de strängar som troligen saknas i en förstapass-innehållsinventering.
Konfigurera automatisk hämtning — ange arbetsflödets fildirektiv, till exempel en include_translatable_attributes-regel, så att alternativ text och ARIA-attribut fångas för översättning på samma sätt som synlig brödtext är, istället för att förlita sig på att någon flaggar dem manuellt.
Ge översättare sammanhang, inte bara strängar - bifoga visuellt eller strukturellt sammanhang till varje tillgänglighetssträng så att en översättare kan se gränssnittselementet som den beskriver och översätta det för hur det kommer att höras, inte bara hur det skulle läsas.
Använd ordlista- och stilguidekontroller — kör samma ordlistans efterlevnads- och kvalitetskontrollprofil som används för synlig kopia mot tillgänglighetssträngar, fånga inkonsekvent terminologi eller trunkering mot plattformsspecifika teckenbegränsningar.
Bekräfta om WCAG-överensstämmelse per språk — kör ett skärm läsarpass och en automatisk WCAG-skanning mot varje publicerad språkversion, inte bara källspråket, innan du anropar en version tillgänglighetskomplete.

Detta tillvägagångssätt passar team som...

Skicka en webb- eller mobilprodukt på flera språk och spåra redan WCAG 2.2 AA-överensstämmelse på källspråket
Lagra alternativ text, ARIA-etiketter och skärmläsarsträngar i samma kodbas eller CMS som synlig användargränssnittskopia
Har ett befintligt översättningsarbetsflöde - ordlista, stilguide, kvalitetskontroller - de vill utvidga till icke-synligt innehåll istället för att köra en andra, separat process
Behöver tillgänglighetsinnehåll för att förbli synkroniserat när utvecklare skickar nya gränssnittssträngar, inte bara hanteras en gång vid lanseringen

Utvärderingschecklista: Frågor att ställa innan du lokaliserar tillgänglighetsinnehåll

Tar vår innehållsinspelningsprocess HTML/JSX-attribut, eller bara synlig text?
Om en export eller anslutning bara extraherar renderade strängar, kommer alternativtext och ARIA-etiketter sannolikt att hoppas över utan att någon märker det.

Får översättare sammanhang för strängar som aldrig återges på skärmen?
En sträng som aria-label= " Stäng " måste ses bredvid kontrollen den märker, annars gissar en översättare på ton och längd.

Tillämpas ordlista- och stilguideregler för tillgänglighetssträngar, inte bara synlig kopia?
Utan det kan en skärmläsarupplevelse glida från en produkts synliga terminologi och röst över olika språk.

Verifieras WCAG-överensstämmelse per språk, eller bara en gång på källspråket?
En överensstämmande engelsk version garanterar inte en överensstämmande tysk, japansk eller arabisk byggnad.

Vad händer när en utvecklare lägger till en ny ARIA-etikett efter lanseringen?
Bekräfta om det automatiskt upptäcks och köas för översättning, eller beror på att någon kommer ihåg att flagga det.

Hur stöder Smartling lokalisering av tillgänglighetsinnehåll?

Smartlings Global Delivery Network (GDN) behandlar alt-, title- och platshållarattribut som översättningsbart innehåll som standard och fångar dem på samma sätt som det fångar synliga brödtext- och knappkopior, så tillgänglighetssträngar kräver inte ett separat exportsteg eller att en utvecklare kommer ihåg att flagga dem. Team som behöver utöka inspelningen till anpassade eller ytterligare attribut kan göra det med ett include_translatable_attributes-direktiv, som berättar för Smartlings tolkare exakt vilka extra HTML-attribut som ska dras in i översättningsarbetsflödet. Stöd på anslutningsnivå bär detta vidare till specifika plattformar - Smartlings Zendesk Connector, till exempel, tar in bildnamn och alt-text för översättning som standard, på samma sätt som den hanterar artikelns brödtext.

För att förhindra att icke-synliga strängar läses som bokstavliga översättningar ger Smartlings Visual Contextverktyg - inklusive Context Capture Chrome Extension och Context Capture JavaScript Library - översättare en ögonblicksbild av sidan eller skärmen som en sträng tillhör, och XLIFF-anteckningar kan fångas automatiskt som översättarinstruktioner. Båda är användbara för en sträng som en ARIA-etikett, som inte har någon egen visuell rendering att översätta mot. Samma ordlista, stilguide och kvalitetskontrollprofil — inklusive efterlevnad av ordlistor och gränskontroller av mållängder — som håller produktens synliga användargränssnitt konsekvent gäller också för dessa strängar, så en skärmläsarupplevelse matchar det synliga gränssnittets ton och terminologi i varje land som levereras.