Tilgængelighed på 24 sprog: Sådan lokaliserer du til inklusiv webadgang

Grundlæggende om digital tilgængelighed i EU-sammenhæng

Digital tilgængelighed betegner udformningen af webindhold og -applikationer, der kan bruges af mennesker med forskellige evner – uanset handicap, alder eller tekniske begrænsninger. I EU-sammenhæng er dette baseret på Web Content Accessibility Guidelines (WCAG) 2.1 og den europæiske standard EN 301 549. Disse definerer succes-kriterier som tilvejebringelse af alternativ tekst til billeder, tilstrækkelige farvekontraster eller betjening via tastatur. For virksomheder, der lokaliserer websteder til 24 EU-sprog, betyder dette: Tilgængelighed skal integreres i lokaliseringsprocessen fra starten, ikke først efterfølgende.

Et centralt aspekt er oversættelsen af Accessible Rich Internet Applications (ARIA)-labels og alternativ tekst. ARIA-attributter som `aria-label` eller `aria-describedby` giver skærmlæsere yderligere information. Ved lokalisering er det vigtigt, at disse attributter ikke kun oversættes sprogligt korrekt, men også kontekstuelt meningsfuldt. Et eksempel: En knap med `aria-label="Suche absenden"` bør på fransk hedde `aria-label="Envoyer la recherche"` – oversættelsen skal udføre den helt samme funktion for skærmlæseren. Også alternativ tekst til grafik (alt-attributter) skal være præcis: I stedet for "Billede af et produkt" bedre "Rød lædertaske med lynlås, størrelse 30x20 cm".

I praksis har det vist sig nyttigt at bruge en tjekliste for tilgængelighed i oversættelsesprocessen. Denne bør indeholde punkter som: Er alle `alt`-tekster til stede og beskrivende? Er ARIA-labels tilgængelige på målsproget? Oversættes tastaturgenveje (f.eks. til sprængningslinks) korrekt? Derudover bør oversættere arbejde med grundlæggende kendskab til WCAG-kriterierne. Hvis en kunde har specifikke krav, for eksempel overholdelse af niveau AA i henhold til WCAG, skal lokaliseringen opfylde disse kriterier på alle sprog.

Et andet punkt: Accessibility overlays (udvidelser til tilgængelighed) skal kontrolleres sprogspecifikt. Et overlay, der dynamisk erstatter engelsk alternativ tekst, fungerer ikke automatisk for tyske tekster. Her kræves et tæt samarbejde mellem udviklere og lokaliseringsteams. Det anbefales at udføre tilgængelighedstest på hvert sprog – ideelt set med rigtige brugere eller automatiserede værktøjer som Axe eller WAVE, dog altid under hensyntagen til sprogspecifikationer. Juridisk set er hvert EU-land bundet af web-tilgængelighedsdirektivet, men den praktiske implementering varierer. Derfor bør du altid søge juridisk rådgivning for nøjagtigt at forstå dine forpligtelser.

Juridiske krav: EN 301 549 og WCAG 2.1 i oversættelse

Standarden EN 301 549 er den europæiske reference for tilgængelige IKT-produkter og -tjenester. Den henviser til WCAG 2.1 på niveau AA som minimumskrav. For virksomheder, der driver flersprogede websteder, opstår spørgsmålet: Hvordan overfører jeg disse krav til hvert sprog? Svaret ligger i en systematisk proces, der sammenkæder oversættelsen af WCAG-relevante indhold med den tekniske implementering. Særlig opmærksomhed gives til oversættelse af fejlmeddelelser, hjælpetekster og instruktioner – disse skal ikke kun være sprogligt korrekte, men også forståelige i forhold til tilgængelighed.

Et praksisrelevant eksempel er oversættelse af inputhjælp: Hvis et formularfelt kræver en bestemt indtastning (f.eks. dato i format DD.MM.ÅÅÅÅ), skal hjælpeteksten på målsproget formuleres tilsvarende. WCAG 2.1 kræver, at instruktioner og fejlmeddelelser er klare og identificerbare. I oversættelse kan "Please enter a valid email address" blive til "Angiv en gyldig e-mailadresse" – begge opfylder kravet. Men ved mere komplekse instruktioner, f.eks. for CAPTCHA'er, kræves særlig omhu. Her anbefaler vi at oversætte alternative tilgængelige metoder (f.eks. logikspørgsmål) ensartet på alle sprog.

Et vigtigt juridisk aspekt er tilgængeligheden af dokumenter, der ofte også skal oversættes (f.eks. PDF'er). EN 301 549 foreskriver, at alt indhold skal være tilgængeligt, herunder indhold på forskellige sprog. Det betyder, at oversatte PDF'er også skal være tagget, forsynet med alternativ tekst og læsbare for skærmlæsere. I praksis kræver det en arbejdsgang: Først oprettes den originale PDF tilgængelig, derefter oversættes den til hvert sprog, og til sidst kontrolleres tilgængeligheden igen. Automatiserede værktøjer er en hjælp her, men en manuel gennemgang af uddannede oversættere eller tilgængelighedseksperter er uundværlig.

Bemærk, at fortolkningen af EN 301 549 kan variere en smule i EU-medlemsstaterne. Nogle lande har egne nationale tilgængelighedslove, der går ud over EU-direktivet. Derfor bør du konsultere din juridiske rådgiver for at afgøre, om dine lokaliserede indhold også dækker nationale særheder. Et eksempel: I Tyskland er BITV 2.0 (Barrierefrei Informationstechnik-Verordnung) gældende, som henviser til WCAG 2.1. Dit oversatte websted skal derfor opfylde både EU-standarden og den nationale forordning. Vi anbefaler at udføre en compliance-kontrol for hvert målsprog – internt eller med eksterne leverandører, der er fortrolige med de lokale krav i det pågældende land.

Tilgængelighedserklæringer og deres sprogspecifikke lokalisering

Enhver offentlig hjemmeside i EU skal indeholde en tilgængelighedserklæring (Accessibility Statement), der angiver overensstemmelsesgraden. Denne erklæring skal være affattet på det/de pågældende officielle sprog. For flersprogede hjemmesider betyder det, at du ikke bare kan oversætte erklæringen via maskinoversættelse – den skal være juridisk præcis og sprogligt korrekt. Erklæringen indeholder typisk: oplysninger om overholdelse af WCAG-overensstemmelsesniveau, dato for seneste opdatering, kontaktmulighed for feedback og i givet fald undtagelser eller ikke-tilgængeligt indhold.

Ved lokalisering er det afgørende, at de juridiske referencer oversættes korrekt. EN 301 549 og national lovgivning citeres normalt i originalen, men selve erklæringen skal formuleres, så den er forståelig for målgruppen. En sætning som 'This website is partially compliant with WCAG 2.1 Level AA' bliver til 'Denne hjemmeside er delvist i overensstemmelse med WCAG 2.1 Level AA'. Sørg for, at begreber som 'undtagelsesbestemmelse' eller 'uforholdsmæssig byrde' er præcist defineret i målsprogets juridiske sprogbrug. I praksis har det vist sig effektivt at udvikle en skabelon på kildesproget, som derefter tilpasses af modersmålstalende jurister eller fagoversættere for hvert målsprog.

Et almindeligt problem er lokalisering af henvisninger til 'feedback' eller 'klageprocedure'. I nogle EU-lande skal der nævnes specifikke kontaktsteder, f.eks. nationale håndhævelsesorganer. Disse oplysninger skal indgå i tilgængelighedserklæringen – og på det pågældende lands sprog. Et eksempel: For den spanske version bør kontaktadressen for 'Oficina de Atención a la Ciudadanía' nævnes, ikke kun en engelsk e-mail. Desuden skal selve erklæringen være tilgængelig, dvs. læsbar med skærmlæsere og i et tilgængeligt format (f.eks. HTML med korrekt overskriftsniveau).

Vi anbefaler at etablere en proces, hvor tilgængelighedserklæringen indgår i lokaliseringsarbejdsgangen. Fastlæg, hvem der gennemgår oversættelsen – ideelt set en juridisk ekspert med kendskab til tilgængelighedsret i mållandet. Et praktisk tip: Offentliggør ikke tilgængelighedserklæringen på kildesproget og tilføj derefter kun maskinoversættelser. Fejlagtige oversættelser kan føre til juridiske konsekvenser, da erklæringen betragtes som en bindende erklæring. Planlæg i stedet tilstrækkelig tid til udarbejdelse og gennemgang. Hold erklæringen opdateret ved at kontrollere juridisk overensstemmelse ved hver større oversættelsesopdatering. Og som altid: Spørg din juridiske rådgiver, om din lokalisering af tilgængelighedserklæringen opfylder kravene i alle relevante jurisdiktioner.

Flersprogede ALT-tekster: Teknikker og kulturelle tilpasninger

ALT-tekster er et centralt element i tilgængelighed og skal på hvert målsprog ikke kun oversættes korrekt, men også tilpasses kulturelt. Erfaringen viser, at direkte oversættelse ikke er tilstrækkelig, da billedindhold tolkes forskelligt i forskellige kulturer. For eksempel kan et symbol for 'post' (kuvert), der er almindeligt på det tyske marked, have en anden betydning i andre EU-lande eller skal erstattes med en lokal ækvivalent.

Til præcis lokalisering anbefaler vi en tre-trins proces: Først analyserer du billedet i hjemmesidens kontekst og formulerer kernebudskabet. Derefter oversætter du ikke budskabet ordret, men tilpasser det til de sprogspecifikke krav – f.eks. brug af bestemt artikel på tysk eller dativ i slovenske beskrivelser. Endelig undersøger du kulturelle aspekter: Viser billedet en gestus, der anses for uforskammet i en målregion? Indeholder det tekststykker som skilte eller skærmbilleder, der skal oversættes? Et eksempel: Et billede med en rød cirkel og en diagonal streg betyder 'forbudt' i Skandinavien, mens man i Sydeuropa oftere bruger en overstreget genstand. I praksis kan det betale sig at konsultere referenceprojekter fra de pågældende lande eller validere med modersmålstalere.

Teknisk set implementeres ALT-tekster i flersprogede projekter bedst via et centralt oversættelsesstyringssystem (TMS). Hvert billedelement får et unikt ID, der knyttes til den pågældende ALT-tekst på alle sprog. Vær opmærksom på, at længden af ALT-teksten kan variere afhængigt af sproget: Finske tekster er ofte længere, franske kortere. Planlæg derfor tilstrækkelig plads – erfaringen viser, at 200–250 tegn er tilstrækkeligt til en præcis beskrivelse på de fleste EU-sprog. Undgå fyldord som 'billede af' eller 'logo af', da skærmlæsere allerede annoncerer det som et billede. For dekorative grafikker bruges et tomt alt-attribut (alt="") – dette skal være ens på alle sprog.

En almindelig fejl er at overføre engelske stikord som 'button' eller 'link' til ALT-teksten. Oversæt disse altid til målsproget, da skærmlæsere som JAWS eller NVDA læser browserens sprogindstilling. Brug også muligheden for at supplere ALT-teksten med en linket lang beskrivelse ved komplekse diagrammer – denne lange beskrivelse skal også lokaliseres fuldstændigt. Med denne systematiske tilgang sikrer du, at dine flersprogede ALT-tekster både overholder EN 301 549 og er kulturelt passende.

ARIA-labels og -roller i oversættelse: syntaks og semantik

ARIA-attributter som aria-label, aria-labelledby, aria-describedby eller role skal på hvert sprog ikke kun være syntaktisk korrekte, men også semantisk formidle elementets formål. I modsætning til synlig tekst er ARIA-labels ofte usynlige og bruges udelukkende af assisterende teknologier. Derfor er en fejlagtig oversættelse særlig kritisk, da den i høj grad forringer navigationen for blinde og svagsynede brugere.

Syntaksen for ARIA-labels i HTML følger et fast skema: aria-label="Beskrivelse". Ved lokalisering skal du sikre, at den oversatte beskrivelse giver samme kontekst som originalteksten. For eksempel beskriver et aria-label "Menü öffnen" på tysk en handling, der på fransk oversættes til "Ouvrir le menu" – men også den grammatisk korrekte store bogstav (Menu i stedet for menu) på fransk skal overholdes. I praksis viser det sig, at skærmlæsere som VoiceOver på macOS til tider ignorerer den indledende artikel ("der", "die", "das"), hvorfor du på tyske ARIA-labels bør undgå artikler. Det forholder sig anderledes med romanske sprog: Der er artikler ofte nødvendige for forståelsen.

Et vigtigt punkt er behandlingen af ARIA-roller som role="button", role="navigation" eller role="alert". Disse roller er standardiseret i HTML-specifikationen og oversættes ikke – de skal forblive uændrede i koden. De tilhørende labels derimod skal oversættes. Undgå at inkludere rollebeskrivelser som "Knap" i label'et, da skærmlæseren alligevel annoncerer rollen. I stedet bør label'et beskrive funktionen, f.eks. "Send" i stedet for "Send-knap". Ved dynamiske komponenter som modale vinduer skal attributter som aria-hidden eller aria-expanded også oversættes? Nej, deres værdier (true/false) er sprogneutrale. Dog bør label'et på et modal beskrive, hvad modalet gør (f.eks. "Tilpas søgefiltre").

Indsæt pladsholdere for ARIA-labels i dit CMS eller skabelonsystem, som oversættes via nøgler. Kontroller ved hvert nyt sprog ARIA-syntaksen i de relevante browsere og assisterende teknologier. Særligt vigtigt: Ved retningsskift fra venstre mod højre (f.eks. arabisk) skal aria-label ikke spejles, men beskrivelsen forbliver i målsprogets læseretning. Vær dog opmærksom på, at ARIA-labels ikke fungerer lige godt i alle EU-sprog: I estiske og lettiske skærmlæsere kan udtalen af specialtegn afvige – test derfor med modersmålstalende. For en juridisk sikker implementering anbefaler vi, at oversættelsen af ARIA-labels kontrolleres af en fagoversætter med kendskab til skærmlæsere. Dette er ikke en erstatning for din egen juridiske rådgivning, men et vigtigt skridt mod compliance.

Accessibility-overlays: lokaliseringsstrategier for dynamiske komponenter

Accessibility-overlays er dynamiske elementer som søgeforslag, tooltips eller modale vinduer, der vises oven på hovedindholdet. Deres lokalisering stiller særlige krav, da de ofte genereres med JavaScript og skal understøtte flere sprog samtidigt. Et overlay indeholder typisk tekst, knapper, ARIA-attributter og statusmeddelelser – alle disse komponenter skal være oversat konsekvent på hvert målsprog.

Lokaliseringsstrategien begynder med adskillelse af indhold og logik. Gem al tekst, der vises i et overlay, i en central ressourcefil (JSON, XML eller PO). Hver tekstblok får en unik nøgle, f.eks. "search.placeholder" eller "modal.close". Ved dynamiske overlays som autocomplete-lister skal live-regioner (aria-live) også tages i betragtning: En meddelelse som "3 resultater fundet" formuleres anderledes på målsproget – på polsk f.eks. "Znaleziono 3 wyniki" med passende numerusform. Programmerere bør derfor opsætte pladsholdere for flertalsregler, der varierer afhængigt af sproget.

Et almindeligt problem er overlappende overlays: Et tooltip, der vises oven på et modal, skal være på samme sprog som modalet. Sørg for, at overlayets sprogindstilling dynamisk kobles til det aktuelle sidesprog. Undgå at vise overlays via CSS og oversætte med JavaScript – erfaringen viser, at det skaber huller i oversættelsen, f.eks. hvis oversættelsen først indlæses efter initialisering. Brug i stedet server-side rendering eller et i18n-framework, der indsætter oversættelsen allerede ved oprettelse af DOM'en.

Test overlays på hvert målmarked med en skærmlæser. Især modale vinduer skal holde fokus inden for overlayet – det gælder sprogligt uafhængigt, men knapperne skal være på det lokale sprog (f.eks. "Luk" i stedet for "Close"). Vær opmærksom på teksternes længde ved lokalisering: En tysk tekst som "Bitte wählen Sie eine Option aus" bliver kortere på rumænsk – andre sprog som finsk kræver mere plads. Planlæg derfor fleksible containere, der tilpasser sig teksten. En juridisk bemærkning: Overensstemmelse med EN 301 549 kræver, at alt indhold er tilgængeligt – også dynamisk indlæste overlays. Søg rådgivning fra en tilgængelighedsekspert ved komplekse overlays; dette erstatter ikke juridisk rådgivning, men anbefales.

Test af flersproget skærmlæserkompatibilitet

Test af skærmlæserkompatibilitet på 24 sprog kræver en systematisk tilgang, der går ud over simple oversættelser. Erfaringsmæssigt opstår de fleste problemer, når sprogskift ikke registreres korrekt af skærmlæseren, eller når dynamisk indhold som fejlmeddelelser ikke annonceres.

Start med at oprette en testmatrix, der dækker alle målsprog og de mest almindelige skærmlæsere – til Windows: JAWS og NVDA, til macOS: VoiceOver, til mobile enheder: TalkBack (Android) og VoiceOver (iOS). Test hver sprogversion med alle relevante skærmlæsere, da udtalen af specialtegn (f.eks. ß, é, ç) og læserækkefølgen kan variere.

Et praktisk eksempel: I den tyske version skal en skærmlæser ved navigation med tabulatortasten annoncere fokus på klikbare elementer i den korrekte rækkefølge. Hvis dynamisk indhold som en udfoldelig menu opdateres via JavaScript, skal skærmlæseren informeres herom – via ARIA-live-regioner. Oversæt live-region-teksterne til hvert målsprog, så brugerne forstår, hvilken ændring der er sket.

Udfør også manuelle tests med rigtige brugere med synshandicap, der taler det pågældende modersmål. Automatiserede værktøjer som axe eller Lighthouse opdager kun grundlæggende fejl, men ikke sprogspecifikke udtaleproblemer. Supplementér dine tests med en kontrol af sprogskift: Når siden skifter mellem tysk, fransk og polsk, skal lang-attributten i HTML være korrekt indstillet, så skærmlæseren indlæser den rigtige sprogstyring. Brug sprogspecifikke testcases til at sikre, at symboltoner og pauser i taleoutputtet svarer til de lokale vaner.

Et andet kritisk punkt er flersprogede tastaturgenveje: På hvert sprog kan tastekombinationer som Ctrl+C eller Alt+ noget fortolkes forskelligt i skærmlæsere. Test alle genveje på hvert sprog og tilpas dem ved konflikter. Dokumentér resultaterne i en central testlog, der opdateres årligt, da skærmlæserversioner og talegenkendelse konstant forbedres.

Sprogspecifikke særlige forhold ved tastaturnavigation

Tastaturnavigation er et centralt element i tilgængelige websteder, der kræver egne tilpasninger på hvert sprog. Mens grundprincipper som logisk fokusrækkefølge og synlig fokusindikator er sproguafhængige, opstår der specifikke udfordringer ved lokalisering til 24 EU-sprog.

En væsentlig forskel ligger i tastaturlayoutene: Tysksprogede brugere bruger QWERTZ, mens AZERTY er almindeligt i Frankrig, og i Polen bruges QWERTY med ekstra diakritiske tegn. Fanerækkefølgen skal derfor designes, så den forbliver intuitiv at betjene på alle layouts. Undgå faste tastaturgenveje, der afhænger af bestemte tastpositioner – for eksempel bør kombinationen Ctrl+UML på tyske tastaturer ikke tildeles en funktion, der på franske tastaturer udløses af en anden tast.

Ved højre-til-venstre-sprog som arabisk eller hebraisk spejles fokusrækkefølgen: Det første interaktive element er øverst til højre. Du skal dynamisk justere tab-indeksværdierne efter sprogretningen, så navigationen følger læseretningen. Brug dir-attributten på containerniveau og test navigationen med en skærmlæser, der understøtter RTL.

Et andet punkt er landespecifikke tastekombinationer for specialtegn: I Spanien indtastes bogstavet Ñ via AltGr+N, mens Å, Ä og Ö i Skandinavien er tilgængelige via separate taster. Hvis dit websted tilbyder brugerdefinerede tastaturgenveje til handlinger som søgning eller udskrivning, bør disse ikke bruge tegn, der er svære at nå på bestemte layouts. Tilbyd alternativt muligheden for at tilpasse genvejene i indstillingerne.

Praktiske anbefalinger: Brug fokusindikatorer med tilstrækkelig kontrast (mindst 3:1 i forhold til baggrunden) og en minimumstykkelse på 2 pixels. Test navigationen uden mus på hvert sprog, mindst med Firefox og Chrome under Windows og macOS. Bemærk, at fokusrækkefølgen også skal opretholdes ved dynamisk indhold som lightboxes eller modalvinduer – her hjælper brugen af aria-haspopup og konsekvent fokustrapping.

Materialdesign og tilgængelighed: Tilpasninger til 24 sprog

Implementeringen af tilgængelige Material Design-komponenter på 24 sprog kræver mere end blot tekstoversættelse. Googles Material Design leverer grundlæggende ARIA-mønstre, men disse skal kulturelt og sprogligt tilpasses for hvert sprog for at opfylde EN 301 549.

Centrale komponenter som navigationsmenuen, faner, dialogbokse og formularer har forskellige tekstlængder afhængigt af sproget. Tyske ord er i gennemsnit 30 % længere end engelske, så horisontale menuer eller knapper kan overløbe uden dynamisk breddetilpasning. Brug sprogafhængige CSS-klasser styret via et lang-attribut, og fastsæt faste, men tilstrækkelige minimumsbredder for hvert sprog. Ved faner og chips anbefales vertikal placering eller horisontal scroll til lange tekster.

Ved højre-til-venstre-sprog skal alle komponenter spejles. Material Design understøtter dette via dir-attributten, men du skal sikre, at brugerdefinerede ikoner eller skyggeretninger også tilpasses. For eksempel bør en pil, der peger til højre, pege til venstre ved RTL. Test hver komponent med en RTL-skærmlæser, da ARIA-labels også skal spejles.

Formularelementer som inputfelter kræver sprogspecifikke valideringsmeddelelser, som oplæses af skærmlæsere. Brug aria-describedby til dynamisk at knytte fejlmeddelelser, og lokaliser alle meddelelser inklusive pladsholdertekster. Sørg for, at dato- og talformater følger lokale konventioner – i Finland skrives dato som dd.mm.åååå, på Malta som dd/mm/åååå. En datovælger skal tilbyde disse formater afhængigt af sproget og tilpasse tastaturnavigationen derefter.

Anbefalinger: Opret et styleguide-dokument, der for hvert sprog fastsætter nøjagtige mål, kontrastforhold (tekst på baggrund mindst 4,5:1) og ARIA-mønstre. Brug Figma eller Sketchs Material Design Kit til forhåndsvisninger, men kontrollér hver komponent med et tilgængelighedsværktøj på det pågældende sprog. Lad brugergrænsefladen testes af modersmålstalende, der arbejder med skærmlæser og tastatur, for at identificere uventede layoutforskydninger eller fokustab. Bemærk, at en juridisk bindende rådgivning om overholdelse af EN 301 549 bør foretages af en juridisk ekspert.

Kontrastkrav: Farver, skrifttyper og tekster i forskellige skriftsystemer

Overholdelse af kontrastkrav er en central del af tilgængelig webdesign. I praksis skal du ikke kun opfylde WCAG 2.1-kriterium 1.4.3 (kontrastforhold på mindst 4,5:1 for normal tekst og 3:1 for stor tekst), men også tage højde for forskelle mellem skriftsystemer. En skrifttype, der fremstår tilstrækkelig kontrastrig i det latinske alfabet, kan pludselig miste læsbarhed ved kyrilliske eller græske tegn. Derfor anbefaler vi at udføre kontrasttest med alle relevante skrifttegn – ideelt set med reelle teksteksempler fra dit målsprog.

Ved farvevalg bør du også være opmærksom på farveblindhed. Omkring 8 % af den mandlige befolkning har en rød-grøn farvesvækkelse; andelen varierer efter region. Brug i praksis simulatorer som "Colorblindly"-browserpluginnet eller de integrerede udviklingsværktøjer til at kontrollere dine farvekombinationer. Sørg desuden for, at information ikke udelukkende formidles via farver – suppler f.eks. med symboler eller tekstetiketter. Dette er særligt relevant for skrifttyper med diakritiske tegn, der hurtigt kan udviskes ved lav kontrast.

For ikke-latinske skrifter som arabisk, kinesisk eller devanagari er separate tests nødvendige, da den gennemsnitlige stregtykkelse og tegnernes kompleksitet varierer. I praksis har det vist sig nyttigt at udføre en separat kontrastkontrol for hver skrifttype med den pågældende tekst og ikke kun stole på generelle farveværdier. Værktøjer som "WCAG Contrast Checker" fra The Paciello Group giver mulighed for at indtaste for- og baggrundsfarver; test også disse med de faktiske skriftstørrelser på dit website.

Konkret handlingsanbefaling: Opret et styleguide-dokument for hvert sprog, der fastsætter minimumskontrastforhold for forskellige skriftstørrelser og -vægte. Kontrollér ved oversættelse af tekster, om den anvendte skrifttype giver samme læsbarhed på målsproget. Overvej om nødvendigt en alternativ skrifttype, der opfylder kontrastkravene. Husk, at retningslinjerne også gælder for dynamisk indhold som hover-effekter eller scroll-tekster. Denne proces bør være en del af din almindelige lokaliseringsworkflow. Vær opmærksom på, at lovkravene kan variere mellem EU-lande; konsulter om nødvendigt en juridisk rådgiver.

Kvalitetssikring: Tjeklister for oversatte tilgængelighedskomponenter

Kvalitetssikring (QA) af lokaliserede tilgængelighedskomponenter kræver en systematisk tilgang, der går ud over simple oversættelseskontroller. I praksis bør du indføre en flertrins tjekliste, der dækker både sproglige og tekniske aspekter. Start med en automatiserbar kontrol: skærmlæsertest med værktøjer som NVDA eller JAWS i de respektive sprogversioner. Kontroller, om alle ARIA-etiketter læses korrekt op, og om tastaturnavigationen fungerer på målsproget. Vær særlig opmærksom på dynamisk indhold som overlays og pop-ups, der kan være struktureret forskelligt på forskellige sprog.

Et væsentligt punkt er konsistensen af alternativtekster og etiketter. Opret en central terminologidatabase, hvor begreber som "Luk", "Menu" eller "Søgefelt" er sprogspecifikt gemt. Ved kvalitetssikring bør hver oversættelse kontrolleres mod denne database for at undgå uensartede formuleringer. Desuden anbefaler vi at kontrollere webstedets tilgængelighedserklæring på alle målsprog for fuldstændighed. Ifølge EU-direktivet (EN 301 549) skal denne indeholde specifikke obligatoriske oplysninger og være affattet i et forståeligt sprog.

Udfør manuelle tests med modersmålsprøvere, der både behersker sproget og har erfaring med hjælpeteknologier. Disse testpersoner bør gennemspille typiske brugsscenarier: udfyldning af en formular, navigation gennem en produktside eller læsning af en artikel med skærmlæser. Dokumentér resultaterne i en standardiseret fejlrapport, der også kan indeholde skærmbilleder og lydoptagelser. Gentag disse tests efter hver sproglig og teknisk opdatering af webstedet.

Konkret handlingsanbefaling: Udvikl en tjekliste, som du gennemgår for hver lokaliseret komponent. Denne bør indeholde punkter som: Er alle alt-tekster til stede og meningsfulde? Bliver ARIA-etiketter korrekt udlæst? Fungerer tastaturnavigationen uden forsinkelser? Er kontrasten korrekt i alle skrifttegn? Lad tjeklisten godkendes af kolleger eller eksterne kontrollører. Hvis du ikke entydigt kan vurdere juridiske krav, bør du inddrage en juridisk rådgiver. QA er en løbende proces, der skal integreres i din lokaliseringsworkflow.

Værktøjer og arbejdsgange: Integrer AI-oversættelse med modersmålsgennemgang

Kombinationen af AI-oversættelse og modersmålsgennemgang kan øge effektiviteten ved lokalisering af tilgængelighedskomponenter, forudsat at processerne er korrekt opsat. I praksis har en totrins arbejdsgang vist sig effektiv: Først sendes alle tekster – inklusive alt-tekster, ARIA-etiketter og skærmlæsertekster – gennem et AI-oversættelsesværktøj. Sørg for, at værktøjet modtager særlige markeringer eller koder (f.eks. HTML-tags, pladsholdere), så disse ikke oversættes eller ødelægges. Derefter følger manuel gennemgang af en modersmålsbruger, der ikke kun evaluerer sprogkvaliteten, men også den tekniske korrekthed.

En vigtig forudsætning er en velstruktureret oversættelseshukommelse (Translation Memory), der indeholder tilbagevendende begreber og sætninger. Dette sikrer, at f.eks. begrebet "Luk-knap" oversættes ensartet på alle sprog. For tilgængelighedskomponenter anbefaler vi at føre separate glossarer, der også indeholder kontekstafhængige oversættelsesregler – for eksempel, at et ARIA-label altid beskriver funktionen og ikke kun det visuelle element. Integrér disse glossarer direkte i dit AI-oversættelsesværktøj for at forbedre kvaliteten af råoversættelserne.

Arbejdsgangen bør også omfatte automatiserede kvalitetskontroller, f.eks. identifikation af uoversatte tekstsegmenter eller fejlagtig ARIA-syntaks. Værktøjer som "GreatBlanc" eller "Accessible Web" tilbyder grænseflader til at integrere sådanne kontroller i oversættelsesprocessen. Efter oversættelse gennemgår teksterne en anden kontrolfase: En modersmålsredaktør tester komponenterne med en skærmlæser på målsproget. Denne test er afgørende, da AI-oversættelser ofte ikke korrekt gengiver tonefald eller idiomatisk læsbarhed. For eksempel kan en for bogstaveligt oversat sætning blive uforståelig i skærmlæseren.

Konkret handlingsanbefaling: Opret en standardiseret procedure for hvert nyt sprog: 1) Opret glossar og oversættelseshukommelse for tilgængelighedstekster. 2) Udfør AI-oversættelse med kontekstafhængige regler. 3) Integrér automatiseret syntakskontrol. 4) Modersmålsgennemgang med skærmlæser-test. 5) Godkendelse efter opfyldelse af kvalitetskriterier. Dokumentér arbejdsgangene i dit projektstyringsværktøj. Bemærk, at denne proces løbende skal tilpasses nye sprog- og teknologitrends. Juridisk rådgivning kan hjælpe med at sikre, at din arbejdsgang opfylder de lovmæssige krav i EN 301 549.

Tjekliste til international tilgængelighedstestning

En grundig gennemgang af tilgængelighed på 24 sprog kræver en systematisk tilgang, der omfatter både automatiserede værktøjer og manuelle test af modersmålseksperter. Start med en auditplanlægning: Definer for hvert sprog et repræsentativt udvalg af sider – mindst forsiden, en produktside, en formular og en kontaktside. Brug automatiserede testværktøjer som Axe eller WAVE til at identificere tekniske fejl, men stol ikke udelukkende på dem. I praksis dækker disse værktøjer kun omkring 30 % af problemerne, især ved sprogspecifikke aspekter.

Ved oversættelse af accessibility overlays og ARIA-labels skal du sikre, at skærmlæsere korrekt afgiver den rigtige sprogversion. Kontrollér, om `lang`-attributter er angivet på hver side, og om dynamisk indhold som modale dialoger eller live-regioner respekterer det aktuelle sprogvalg. Et almindeligt problem: Et ARIA-label kan være grammatisk korrekt på tysk, men uforståeligt på polsk på grund af manglende bøjning. Lad derfor altid labels og alternativtekster blive testet for forståelighed af en modersmålsekspert.

Udfør manuelle test med almindelige skærmlæsere som NVDA (tysk, engelsk) eller JAWS, samt VoiceOver på iOS og TalkBack på Android. Test tastaturnavigationen: Alle interaktive elementer skal kunne fokuseres, og fokus skal logisk følge læseretningen for det pågældende sprog – for højre-til-venstre-sprog som arabisk fra højre mod venstre. Vær opmærksom på kontraster: Farver og skriftstørrelser kan opleves anderledes i sprog med andre skrifttegn (f.eks. kinesisk eller kyrillisk). Brug en kontrasttester, der også simulerer farveopfattelse i forskellige skrifttyper.

Dokumentér alle testresultater i en tjekliste, der for hvert sprog dækker kriterierne: Overholdelse af WCAG 2.1 niveau A og AA, korrekt oversættelse af alle tekster, fungerende skip-links, konsistent navigation og fejlfri ARIA-implementering. Planlæg regelmæssige audits – ideelt set efter hvert indholdsopdatering. Bemærk: Denne tjekliste erstatter ikke en juridisk bindende gennemgang; konsulter din juridiske afdeling ved juridiske spørgsmål. En omhyggelig international gennemgang minimerer risikoen for retssager og forbedrer brugeroplevelsen for alle besøgende.

Fremtidsperspektiv: Fremtidige EU-krav og bæredygtig lokaliseringspraksis

EU arbejder løbende på at skærpe tilgængelighedskravene. European Accessibility Act (EAA) bliver obligatorisk fra juni 2025 for mange produkter og tjenester. Fremover må der forventes strengere krav til flersproget implementering – især ved dynamisk indhold og AI-baserede oversættelser. Virksomheder bør tidligt forberede sig på en harmonisering af nationale love, der kan gå ud over EN 301 549. I praksis betyder det: Invester i systemer, der integrerer tilgængelighed fra starten i lokaliseringsprocessen i stedet for at rette op efterfølgende.

En bæredygtig tilgang er at oprette flersprogede tilgængelighedsteams bestående af udviklere, UX-designere og modersmålsredaktører. Disse teams bør være fast integreret i CI/CD-workflowet, så hver oversættelse automatisk testes for WCAG-overholdelse. Brug AI-oversættelser, men lad alle tilgængelighedsrelevante tekster (som alt-tekster og ARIA-labels) blive gennemgået af en modersmålsekspert. Erfaringsmæssigt reducerer en sådan kombination af automatisering og menneskelig gennemgang fejlraten betydeligt.

Også teknologi valget påvirker bæredygtigheden: Brug frameworks, der nativt understøtter tilgængelighed, som React med ARIA-biblioteker eller Angular med accessibility-moduler. Undgå proprietære overlay-løsninger, der ofte er svære at lokalisere og indebærer juridiske risici. I stedet bør du bruge native HTML-elementer, som bedre kan fortolkes af skærmlæsere. Planlæg regelmæssig træning af dine lokaliseringspartnere om de specifikke krav til tilgængelighed på forskellige sprog.

Endelig er det værd at kigge på det planlagte EU-direktiv om digital tilgængelighed for offentlige myndigheders websteder og mobilapplikationer, som også vil påvirke private virksomheder. Et bæredygtigt lokaliseringssystem er ikke et engangsprojekt, men en løbende proces. Dokumentér dine processer og del bedste praksis med andre afdelinger. Husk: Denne vurdering erstatter ikke juridisk rådgivning; konsulter din juridiske rådgiver ved konkrete compliance-spørgsmål. Med en proaktiv tilgang forbliver du ikke kun compliant, men åbner din tjeneste for en bredere brugergruppe.

Faldgruber og hyppige fejl ved lokalisering af tilgængelighed

Ved lokalisering af tilgængeligt indhold på 24 sprog opstår der igen og igen lignende fejl. En hyppig faldgrube er den direkte oversættelse af alt-tekster eller ARIA-labels uden hensyntagen til målsproget og -kulturen. For eksempel kan et billedligt udtryk som „Klick hier“ fungere på tysk, men på polsk virke unaturligt eller vække forkerte associationer. Lige så problematisk er bogstavelige oversættelser af statusmeddelelser, f.eks. ved fejlmeddelelser i formularer: „Field is required“ bliver på tysk til „Feld ist erforderlich“, hvilket er korrekt, men kan være mindre forståeligt for skærmlæserbrugere. Bedre ville være „Dieses Feld muss ausgefüllt werden“.

En anden fejl vedrører forkert håndtering af sprogattributter (lang-attributter). På flersprogede sider glemmer udviklere ofte at justere sprogattributten dynamisk ved sprogskift. Skærmlæsere genkender da ikke sproget korrekt, hvilket fører til forvrænget udtale. I praksis bør hvert tekstniveau – hvad enten det er i HTML-grundstrukturen eller i ARIA-labels – være eksplicit forsynet med den korrekte sprogkode.

Også længdeforskellene mellem sprogene bliver ofte undervurderet. Tyske tekster er i gennemsnit længere end engelske eller franske. En alt-tekst, der på engelsk har 100 tegn, kan på tysk kræve 130 tegn. Hvis brugergrænsefladen har faste layouts, fører dette til afskårne tekster eller overlappende elementer. Planlæg derfor fra starten fleksible containere eller lad pladsreserver til tekstudvidelser.

Et specifikt problem ved ARIA-labels er de forskellige læseregler for skærmlæsere. Mens et label på engelsk læses op som „Button: Senden“, forventer den tyske version snarere „Schaltfläche: Senden“. Tilpasningen til landetypiske oplæsningsstandarder bliver ofte glemt. Test derfor hver sprogspecifik implementering med en modersmålsbaseret skærmlæser (f.eks. JAWS, NVDA, VoiceOver).

Endelig fører fejl i oversættelsen af tilgængelighedserklæringer ofte til juridiske usikkerheder. EN 301 549 kræver præcise oplysninger om overensstemmelse. Hvis en tjenesteudbyder kun oversætter erklæringen groft, kan websiden betragtes som ikke-konform. Få derfor alle juridisk relevante tekster gennemgået af en fagjurist.

Undgå disse faldgruber ved at oprette klare styleguides for tilgængelighedsoversættelser og udføre regelmæssige skærmlæsertests på alle målsprog. Et tæt samarbejde mellem lokaliseringsteamet og tilgængelighedseksperter anbefales.

Samarbejde med tjenesteudbydere og omkostningsstyring

Lokalisering af tilgængelighedsindhold på 24 sprog kræver professionel koordinering med specialiserede tjenesteudbydere. Vælg udbydere, der både har erfaring med teknisk oversættelse og solid viden om EU's tilgængelighedsstandarder (EN 301 549, WCAG 2.1). Spørg på forhånd efter referencer inden for tilgængelighedslokalisering og kontrollér, om oversætterne arbejder på modersmål og kan teste med skærmlæsere.

En velafprøvet model er kombinationen af AI-oversættelse og modersmålsbaseret gennemgang. AI'en står for den indledende oversættelse af alt-tekster, ARIA-labels og fejlmeddelelser, mens den menneskelige korrekturlæser sikrer semantisk nøjagtighed, kulturel passendehed og teknisk korrekthed. Dette sparer omkostninger og tid uden at gå på kompromis med kvaliteten. Sørg for, at korrekturlæseren også kender tilgængelighedsretningslinjerne – en ren sprogkorrekturlæser er som regel ikke nok.

Ved omkostningsberegning bør du medtage følgende poster: oversættelse af tilgængelighedserklæringen og de juridiske tekster (ofte efter antal ord eller tegn), lokalisering af UI-komponenter inklusive alt-tekster og labels (efter antal strenge eller komponenter), teknisk rådgivning om opsætning af sprogattributter og ARIA-strukturer samt testomkostninger for skærmlæsertests på hvert sprog. Erfaringsmæssigt udgør testandelen omkring 30-40 procent af det samlede budget.

En hyppig indvending er, at tilgængelighedslokalisering er for dyr. I praksis kan omkostningerne dog reduceres ved at planlægge tidligt: Hvis alt-tekster og labels allerede i designprocessen udformes flersproget, undgås tidskrævende efterjustering. Også genanvendelighed – f.eks. identiske symboler med samme alt-tekst på alle sprog – reducerer indsatsen.

Samarbejdet med tjenesteudbydere kræver klar kommunikation: Definér en ordliste med centrale begreber (f.eks. „Schaltfläche“, „Navigationsmenü“) og fastsæt længdegrænser for tekster. Brug et oversættelsesstyringssystem (TMS), der sporer status for hver komponent og logger ændringer. Udfør regelmæssige reviews, hvor du får kontrolleret de oversatte indhold på et testsystem med skærmlæser.

Afslutningsvis anbefales det at udpege en fast kontaktperson hos tjenesteudbyderen, der har overblik over både de tekniske og sproglige krav. På den måde sikrer du, at dit flersprogede tilgængelighedsprojekt afsluttes rettidigt og inden for budgettet.

Faldgruber ved oversættelse af tilgængelighed til 24 sprog

Lokalisering af tilgængeligt indhold indebærer specifikke faldgruber, der rækker ud over almindelige oversættelsesfejl. En almindelig fejl er ordret oversættelse af ARIA-labels eller alt-tekster uden at tage hensyn til målsprogets semantik. For eksempel kan en engelsk label som "Submit" blive for lang på tysk, hvilket får skærmlæsere til at forvanske udsagnet. I stedet er forkortelser som "Send" eller kontekstafhængige alternativer nødvendige. En anden faldgrube er kulturelle forskelle i symboler og ikoner: En farvekode for "succes" (grøn) eller "fejl" (rød) er den samme i mange kulturer, men i nogle asiatiske lande har rød en positiv konnotation. Tilgængelige instruktioner, der henviser til farver, skal derfor enten suppleres med tekst eller tilpasses. Også oversættelsen af "Skip to main content"-links er ikke triviel: På tysk bliver det "Zum Hauptinhalt springen", men længdeændringen kan forstyrre layoutet eller tastaturnavigationen. Desuden undervurderer mange betydningen af sprogdeklarationer i HTML. Hvis sprogangivelsen ikke er korrekt indstillet (f.eks. `lang="de"` for tyske sider), kan skærmlæsere fortolke indholdet forkert og anvende den forkerte sprogsyntese. Et andet punkt er sammensatte ord på tysk – f.eks. "E-Mail-Bestätigung" – som skærmlæsere ofte ikke læser korrekt, da de ikke genkender orddelingen. Her hjælper ARIA-attributter som `aria-label` til at styre udtalen. Ved oversættelse af fejlmeddelelser i formularer skal man være opmærksom på, at fejl-ID forbliver unikt og ikke brydes af sprogspecifikke tilpasninger. I praksis viser det sig, at modersmålsprøvere ikke kun skal teste grammatik, men også skærmlæserkompatibilitet. En nyttig tilgang er at teste hver oversat komponent med en skærmlæser og sammenligne output med den engelske reference. På denne måde kan uheld som forkerte betoninger eller manglende alternativtekster opdages tidligt. Uden denne proaktive tilgang opstår barrierer, der kan have juridiske konsekvenser – især fra juni 2025 med European Accessibility Act.

Praktiske værktøjer og teknologier til flersprogede tilgængelighedstest

Til kvalitetssikring af tilgængelig lokalisering på 24 sprog findes der specialiserede værktøjer, der rækker ud over simpel oversættelsessoftware. Et centralt værktøj er integration af skærmlæsere i testworkflowet: native løsninger som NVDA (Windows) eller VoiceOver (macOS) kan kombineres med automatiserede tests. For hvert målsprog bør en modersmålsprøver teste indholdet med den pågældende skærmlæser, da sprogsyntese har varierende kvalitet. Automatiserede testværktøjer som axe-core, Wave eller Lighthouse opdager ganske vist mange WCAG-overtrædelser, men er sprogafhængige: De kontrollerer f.eks. om `aria-label` er til stede, men ikke om indholdet er meningsfuldt på målsproget. Derfor er en kombination af automatiseret og manuel test uundværlig. En praktisk tilgang er brugen af oversættelsesstyringssystemer (TMS) med tilgængelighedsfunktioner: Moderne TMS gør det muligt at forsyne oversættelsesenheder med metadata, så oversættere ved, om en tekst er en alt-tekst til et billede eller en etiket på en knap. Derudover tilbyder nogle systemer inline-kontekstforhåndsvisninger, der viser den oversatte tekst direkte i det originale layout. Til test af tastaturnavigation er browsertilføjelser som Microsofts "Accessibility Insights" velegnede, hvormed fokusrækkefølgen kan testes på alle sprog. Et andet nyttigt værktøj er "dummy-skærmoutput": via CSS kan man vise billeders tekstalternativer for at kontrollere, om oversættelsen er meningsfuld. Også brugen af sprog-fallback-mekanismer i HTML (f.eks. `lang=de` på tekstniveau) kan kontrolleres med værktøjer som W3C Validator. Endelig anbefales brugen af "tilgængelighedstestlaboratorier" som en tjeneste: Nogle agenturer tilbyder specifikt til flersprogede websteder en kombination af automatiske scanninger og manuelle skærmlæsertest på op til 24 sprog. Valget af værktøjer afhænger af budget og teamstørrelse, men i praksis har en blanding af open source-værktøjer som axe og Poedit (til oversættelsesfiler) samt kommercielle platforme som Transifex eller Lokalise med tilgængeligheds-plugins vist sig at være effektiv. Det er vigtigt, at alle involverede – oversættere, udviklere og testpersoner – bruger den samme værktøjskæde for at undgå fejl på grund af mediebrud.