Hvordan lokaliserer man tilgængelighedsfunktioner som alt-tekst og ARIA-etiketter?

Sidst gennemgået: 31. august 2026

Hvad skal der til for at lokalisere tilgængelighedsindhold korrekt?

Korrekt lokalisering af tilgængelighedsindhold afhænger af fem lag, der arbejder sammen, ikke blot af oversættelse af strengene.

• Komplet indholdsregistrering — alle oversættelige attributter (alt, titel, aria-label, aria-describedby) skal identificeres og trækkes ind i arbejdsgangen sammen med synlig brødtekst og knaptekst og behandles ikke som et separat, manuelt trin.
• Kontekst for oversættere — fordi disse strenge ikke har nogen visuel gengivelse, skal oversættere se det brugergrænsefladeelement, som en etiket beskriver, for at undgå en bogstavelig, ord-for-ord-gengivelse, der læses mærkeligt højt.
• Stil og tonekonsistens — ordlisten og stilguiden, der holder den synlige brugergrænsefladetekst konsistent, bør også omfatte tilgængelighedsstrenge, så en skærmlæser på fransk eller japansk lyder som det samme produkt som den synlige brugerflade.
• Kvalitetsverifikation pr. lokalitet — WCAG-overensstemmelsestjek skal køres mod alle leverede lokaliteter, ikke kun den engelske kilde, da en bestået engelsk revision ikke siger noget om den tyske eller japanske version.
• Løbende synkronisering – når udviklere tilføjer eller redigerer brugergrænsefladestrenge, skal alt-tekst og ARIA-etiketter automatisk genregistreres og sættes i kø til oversættelse, på samme måde som synlige strenge, så tilgængelighedsindhold ikke mister synkronisering efter lanceringen.

Hvilke WCAG-succeskriterier dækker lokaliseret tilgængelighedsindhold?

Lokaliseret tilgængelighedsindhold er tilpasset specifikke, nummererede WCAG 2.2-succeskriterier og ikke blot generel god praksis.

Hvordan lokaliserer man tilgængelighedsindhold i praksis?

Ovenstående arbejdsgangslag omsættes til en konkret sekvens, som de fleste teams kan køre sideløbende med deres eksisterende lokaliseringsproces.

1. Revider ikke-synlige strenge – gennemgå eller eksporter kildeproduktet for hver alt-, title-, aria-label- og aria-describedby-attribut sammen med standard UI-strenge; disse er de strenge, der højst sandsynligt mangler i en first-pass indholdsopgørelse.
2. Konfigurer automatisk registrering – angiv arbejdsgangens fildirektiver, f.eks. en include_translatable_attributes-regel, så alternativ tekst og ARIA-attributter registreres til oversættelse på samme måde som synlig brødtekst, i stedet for at være afhængig af, at nogen markerer dem manuelt.
3. Giv oversætterne kontekst, ikke kun strenge – tilføj visuel eller strukturel kontekst til hver tilgængelighedsstreng, så en oversætter kan se det brugergrænsefladeelement, den beskriver, og oversætte det til, hvordan det vil blive hørt, ikke kun hvordan det ville blive læst.
4. Anvend ordliste- og stilguidetjek – kør den samme ordlisteoverholdelses- og kvalitetskontrolprofil, der bruges til synlig tekst, mod tilgængelighedsstrenge, og fang inkonsekvent terminologi eller afkortning i forhold til platformspecifikke tegnbegrænsninger.
5. Genbekræft WCAG-overholdelse pr. lokalitet — kør en skærmlæsergennemgang og en automatisk WCAG-scanning mod hver publiceret lokalitetsbuild, ikke kun kildesproget, før en udgivelse kaldes "accessibility-complete".

Denne tilgang passer til teams, der...

• Send et web- eller mobilprodukt på flere sprog og spor allerede WCAG 2.2 AA-overholdelse på kildesproget
• Gem alt-tekst, ARIA-etiketter og skærmlæserstrenge i samme kodebase eller CMS som synlig brugergrænsefladetekst
• Har en eksisterende oversættelsesworkflow — ordliste, stilguide, kvalitetstjek — de ønsker at udvide til ikke-synligt indhold i stedet for at køre en anden, separat proces
• Har brug for, at tilgængelighedsindhold forbliver synkroniseret, når udviklere udgiver nye brugergrænsefladestrenge, og ikke kun håndteres én gang ved lancering

Når dette måske ikke er topprioriteten

• Et produkt med en brugerbase på kun ét sprog og ingen kortsigtet plan for en flersproget udgivelse
• Statisk marketingindhold med få interaktive komponenter, dynamiske statusmeddelelser eller formularfelter, hvor ARIA-attributter sjældent bruges i første omgang.

Evalueringstjekliste: Spørgsmål du bør stille, før du lokaliserer tilgængelighedsindhold

Henter vores indholdsregistreringsproces HTML/JSX-attributter eller kun synlig tekst?
Hvis en eksport eller forbindelse kun udtrækker gengivne strenge, springes alt-tekst og ARIA-etiketter sandsynligvis over, uden at nogen bemærker det.

Får oversættere kontekst for strenge, der aldrig gengives på skærmen?
En streng som aria-label="Luk" skal ses ved siden af det kontrolelement, den navngiver, ellers gætter en oversætter på tone og længde.

Anvendes regler for ordlister og stilguider på tilgængelighedsstrenge, ikke kun synlig tekst?
Uden det kan en skærmlæseroplevelse afvige fra et produkts synlige terminologi og stemme på tværs af landestandarder.

Verificeres WCAG-overholdelse pr. sprog, eller kun én gang i kildesproget?
En kompatibel engelsk version garanterer ikke en kompatibel tysk, japansk eller arabisk version.

Hvad sker der, når en udvikler tilføjer en ny ARIA-etiket efter lanceringen?
Bekræft, om den automatisk registreres og sættes i kø til oversættelse, eller om den afhænger af, at nogen husker at markere den.

Hvordan understøtter Smartling lokalisering af tilgængelighedsindhold?

Smartlings Global Delivery Network (GDN) behandler alt-, title- og placeholder-attributter som standard som oversætteligt indhold og registrerer dem på samme måde, som det registrerer synlig brødtekst og knaptekst, så tilgængelighedsstrenge ikke kræver et separat eksporttrin eller en udvikler, der husker at markere dem. Teams, der har brug for at udvide registrering til brugerdefinerede eller yderligere attributter, kan gøre det med en include_translatable_attributes-direktiv, som fortæller Smartlings parser præcis, hvilke ekstra HTML-attributter der skal trækkes ind i oversættelsesarbejdsgangen. Understøttelse på connectorniveau fører dette videre til specifikke platforme — Smartlings Zendesk Connector indtager for eksempel som standard billednavne og alt-tekst til oversættelse, på samme måde som den håndterer artikeltekst.

For at forhindre, at ikke-synlige strenge læses som ordrede oversættelser, giver Smartlings visuelle kontekstværktøjer – herunder Context Capture Chrome Extension og Context Capture JavaScript Library – oversættere et øjebliksbillede af den side eller skærm, en streng tilhører, og XLIFF-noter kan automatisk registreres som oversætterinstruktioner. Begge er nyttige til en streng som en ARIA-etiket, som ikke har sin egen visuel gengivelse at oversætte imod. Den samme ordliste, stilguide og kvalitetskontrolprofil – inklusive overholdelse af ordlister og kontrol af længdegrænser – der sikrer ensartethed i et produkts synlige brugergrænseflade, gælder også for disse strenge, så en skærmlæseroplevelse matcher den synlige brugerflades tone og terminologi i alle leverede landestandarder.

Relaterede spørgsmål

• Hvordan automatiserer virksomheder sproglig kvalitetssikring?
• Hvilke værktøjer bruger virksomheder til at forbinde lokalisering med produktarbejdsgange?