Prieinamumas 24 kalbomis: kaip lokalizuoti siekiant įtraukios prieigos internete

Skaitmeninio prieinamumo pagrindai ES kontekste

Skaitmeninis prieinamumas reiškia interneto turinio ir programų kūrimą, kuriuo gali naudotis skirtingų gebėjimų žmonės – nepriklausomai nuo negalios, amžiaus ar techninių apribojimų. ES kontekste tai grindžiama Web Content Accessibility Guidelines (WCAG) 2.1 ir Europos standartu EN 301 549. Jie apibrėžia sėkmės kriterijus, tokius kaip alternatyviųjų tekstų pateikimas paveikslėliams, pakankami spalvų kontrastai arba valdymas klaviatūra. Įmonėms, kurios lokalizuoja svetaines į 24 ES kalbas, tai reiškia: prieinamumas turi būti integruotas į lokalizavimo procesą nuo pat pradžių, o ne vėliau.

Pagrindinis aspektas yra ARIA (Accessible Rich Internet Applications) etikečių ir alternatyviųjų tekstų vertimas. ARIA atributai, tokie kaip `aria-label` arba `aria-describedby`, suteikia ekrano skaitytuvams papildomos informacijos. Lokalizuojant svarbu, kad šie atributai būtų išversti ne tik kalbiškai teisingai, bet ir kontekstiškai prasmingai. Pavyzdys: mygtukas su `aria-label="Suche absenden"` prancūziškoje versijoje turėtų būti `aria-label="Envoyer la recherche"` – vertimas turi atlikti lygiai tokią pačią funkciją ekrano skaitytuvui. Taip pat grafikų alternatyvieji tekstai (alt atributai) turi būti tikslūs: vietoj „Produkto paveikslėlis“ geriau „Raudonas odinis krepšys su užtrauktuku, dydis 30x20 cm“.

Praktikoje pasitvirtino naudoti prieinamumo kontrolinį sąrašą vertimo proceso metu. Jame turėtų būti punktai, pvz.: ar visi `alt` tekstai yra ir aprašomieji? Ar ARIA etiketės yra prieinamos tiksline kalba? Ar klaviatūros spartieji klavišai (pvz., praleidimo nuorodoms) išversti teisingai? Be to, vertėjai turėtų dirbti turėdami pagrindinių WCAG kriterijų žinių. Jei klientas turi specifinių reikalavimų, pvz., WCAG AA lygio laikymąsi, lokalizavimas turi atitikti šiuos kriterijus visomis kalbomis.

Kitas punktas: prieinamumo perdangos (Accessibility Overlays) turi būti tikrinamos pagal kalbą. Perdanga, kuri dinamiškai pakeičia angliškus alternatyviuosius tekstus, neveiks automatiškai vokiškiems tekstams. Čia reikalingas glaudus kūrėjų ir lokalizavimo komandų bendradarbiavimas. Rekomenduojama atlikti prieinamumo testus kiekviena kalba – idealiu atveju su tikrais naudotojais arba automatinėmis priemonėmis, tokiomis kaip Axe ar WAVE, tačiau visada atsižvelgiant į kalbos specifiką. Teisiškai kiekviena ES šalis yra saistoma Web Accessibility direktyvos, tačiau praktinis įgyvendinimas skiriasi. Todėl visada turėtumėte pasikonsultuoti su teisininkais, kad tiksliai suprastumėte savo įsipareigojimus.

Teisiniai reikalavimai: EN 301 549 ir WCAG 2.1 vertime

Standartas EN 301 549 yra Europos nuoroda dėl prieinamų IKT produktų ir paslaugų. Jis nurodo WCAG 2.1 AA lygį kaip minimalų reikalavimą. Įmonėms, kurios valdo daugiakalbes svetaines, kyla klausimas: kaip perkelti šiuos reikalavimus į kiekvieną kalbą? Atsakymas yra sistemingas procesas, kuris sujungia WCAG aktualaus turinio vertimą su techniniu įgyvendinimu. Ypatingas dėmesys skiriamas klaidų pranešimų, pagalbos tekstų ir instrukcijų vertimui – jie turi būti ne tik kalbiškai teisingi, bet ir suprantami prieinamumo prasme.

Praktiškai aktualus pavyzdys yra įvesties pagalbų vertimas: jei formos laukas reikalauja tam tikros įvesties (pvz., datos formatu TT.MM.JJJJ), pagalbos tekstas tiksline kalba turi būti atitinkamai suformuluotas. WCAG 2.1 reikalauja, kad instrukcijos ir klaidų pranešimai būtų aiškūs ir atpažįstami. Verčiant iš „Please enter a valid email address“ gali tapti „Geben Sie eine gültige E-Mail-Adresse ein“ – abu atitinka reikalavimą. Tačiau sudėtingesnėms instrukcijoms, pavyzdžiui, CAPTCHA, reikia ypatingo atidumo. Čia rekomenduojame vienodai išversti alternatyvius prieinamus metodus (pvz., loginius klausimus) visomis kalbomis.

Svarbus teisinis aspektas yra dokumentų, kurie dažnai taip pat turi būti verčiami (pvz., PDF), prieinamumas. EN 301 549 nustato, kad visas turinys turi būti prieinamas, įskaitant skirtingomis kalbomis. Tai reiškia, kad išversti PDF taip pat turi būti pažymėti žymomis, su alternatyviaisiais tekstais ir skaitomi ekrano skaitytuvais. Praktiškai tam reikia darbo eigos: pirmiausia originalus PDF sukuriamas prieinamas, tada išverčiamas kiekvienai kalbai, o vėliau vėl patikrinamas prieinamumas. Automatizuotos priemonės čia padeda, tačiau būtinas rankinis patikrinimas, kurį atlieka apmokyti vertėjai arba prieinamumo ekspertai.

Atkreipkite dėmesį, kad EN 301 549 aiškinimas gali šiek tiek skirtis ES valstybėse narėse. Kai kurios šalys turi savo nacionalinius prieinamumo įstatymus, kurie viršija ES direktyvą. Todėl turėtumėte pasikonsultuoti su savo teisės patarėju, ar jūsų lokalizuotas turinys apima ir nacionalinius ypatumus. Pavyzdys: Vokietijoje galioja BITV 2.0 (Barrierefreie Informationstechnik-Verordnung), kuri nurodo WCAG 2.1. Taigi jūsų išversta svetainė turi atitikti tiek ES standartą, tiek nacionalinį reglamentą. Rekomenduojame atlikti atitikties patikrą kiekvienai tikslinei kalbai – viduje ar su išoriniais paslaugų teikėjais, kurie yra susipažinę su vietiniais reikalavimais atitinkamoje šalyje.

Prieinamumo deklaracijos ir jų kalbinė lokalizacija

Kiekviena vieša svetainė ES turi pateikti prieinamumo deklaraciją (Accessibility Statement), nurodančią atitikties lygį. Ši deklaracija turi būti parengta atitinkama (-omis) oficialia (-iomis) kalba (-omis). Daugiakalbėms svetainėms tai reiškia, kad deklaracijos negalima tiesiog išversti mašininiu vertimu – ji turi būti teisiškai tiksli ir kalbiškai teisinga. Deklaracijoje paprastai pateikiama: informacija apie WCAG atitikties lygį, paskutinio atnaujinimo data, kontaktinė informacija atsiliepimams ir, jei yra, išimtys arba neprieinamas turinys.

Lokalizuojant labai svarbu, kad teisinės nuorodos būtų tinkamai išverstos. EN 301 549 ir nacionaliniai įstatymai paprastai cituojami originalo kalba, tačiau pati deklaracija turi būti suformuluota taip, kad būtų suprantama tikslinei auditorijai. Sakinys, pvz., „This website is partially compliant with WCAG 2.1 Level AA“, tampa „Ši svetainė iš dalies atitinka WCAG 2.1 AA lygį“. Atkreipkite dėmesį, kad tokios sąvokos kaip „išimties taisyklė“ ar „neproporcinga našta“ tikslinės kalbos teisinėje kalboje turi būti tiksliai apibrėžtos. Praktikoje pasiteisino, kai šaltinio kalba parengiamas pavyzdinis tekstas, kurį vėliau kiekvienai tikslinei kalbai pritaiko gimtosios kalbos teisininkai arba specializuoti vertėjai.

Dažna problema yra nuorodų į „atsiliepimus“ ar „skundų procedūras“ lokalizavimas. Kai kuriose ES šalyse reikia nurodyti konkrečius kontaktinius centrus, pavyzdžiui, nacionalines vykdymo užtikrinimo institucijas. Ši informacija turi būti pateikta prieinamumo deklaracijoje – būtent atitinkama šalies kalba. Pavyzdžiui, ispaniškoje versijoje turėtų būti nurodytas „Oficina de Atención a la Ciudadanía“ kontaktinis adresas, o ne tik el. paštas anglų kalba. Be to, pati deklaracija turi būti prieinama, t. y. skaitoma ekrano skaitytuvais ir pateikiama prieinamu formatu (pvz., HTML su tinkamais antraščių lygiais).

Rekomenduojame nustatyti procesą, kai prieinamumo deklaracija tampa lokalizacijos darbo eigos dalimi. Nustatykite, kas tikrins vertimą – idealiu atveju teisės ekspertas, išmanantis tikslinės šalies prieinamumo teisę. Praktinis patarimas: neskelbkite prieinamumo deklaracijos šaltinio kalba ir tik tada pridėkite mašininius vertimus. Klaidingi vertimai gali sukelti teisinių pasekmių, nes deklaracija laikoma privalomu pareiškimu. Vietoj to skirkite pakankamai laiko jos parengimui ir patikrai. Atnaujinkite deklaraciją kiekvieną kartą, kai atliekamas didelis vertimo atnaujinimas, ir patikrinkite atitiktį teisės aktams. Ir, kaip visada, pasitarkite su savo teisės patarėju, ar jūsų prieinamumo deklaracijos lokalizacija atitinka visų atitinkamų jurisdikcijų reikalavimus.

Alternatyviųjų tekstų daugiakalbis kūrimas: metodai ir kultūriniai pritaikymai

Alternatyvieji tekstai yra pagrindinis prieinamumo elementas ir kiekvienoje tikslinėje kalboje turi būti ne tik teisingai išversti, bet ir kultūriškai pritaikyti. Patirtis rodo, kad tiesioginis vertimas nėra pakankamas, nes vaizdų turinys skirtingose kultūrose interpretuojamas skirtingai. Pavyzdžiui, Vokietijos rinkoje įprastas „Pašto“ simbolis (vokas) kitose ES šalyse gali turėti kitą reikšmę arba turėti būti pakeistas vietiniu atitikmeniu.

Siekiant tiksliai lokalizuoti, rekomenduojame trijų etapų procesą: Pirmiausia išanalizuokite paveikslėlį svetainės kontekste ir suformuluokite pagrindinę mintį. Tada išverskite šią mintį ne pažodžiui, o pritaikykite prie kalbinių reikalavimų – pavyzdžiui, vokiško žymimojo artikelio vartojimo arba datyvo slovėnų aprašymuose. Galiausiai patikrinkite kultūrinius aspektus: ar paveikslėlyje pavaizduotas gestas, kuris tikslinėje šalyje laikomas nemandagiu? Ar jame yra teksto elementų, pvz., ženklų ar ekrano kopijų, kuriuos reikia išversti? Pavyzdys: paveikslėlis su raudonu apskritimu ir įstriža linija Skandinavijoje reiškia „draudžiama“, o Pietų Europoje dažniau vartojamas išbrauktas objektas. Praktikoje verta pasitelkti atitinkamų šalių informacinius projektus arba patvirtinti su gimtakalbiais.

Techniškai alternatyviuosius tekstus daugiakalbiuose projektuose geriausia įgyvendinti naudojant centrinę vertimo valdymo sistemą (TMS). Kiekvienam vaizdo elementui suteikiamas unikalus ID, kuris susiejamas su atitinkamu alternatyviuoju tekstu visomis kalbomis. Atkreipkite dėmesį, kad alternatyviojo teksto ilgis gali skirtis priklausomai nuo kalbos: suomiški tekstai dažnai ilgesni, prancūziški – trumpesni. Todėl numatykite pakankamai vietos – praktika rodo, kad 200–250 simbolių pakanka tiksliam aprašymui daugumoje ES kalbų. Venkite užpildomųjų žodžių, tokių kaip „paveikslėlis“ ar „logotipas“, nes ekrano skaitytuvai juos jau paskelbia kaip vaizdą. Dekoratyvinėms grafikoms naudokite tuščią alt atributą (alt="") – tai turi būti vienoda visomis kalbomis.

Dažna klaida – angliškų raktinių žodžių, tokių kaip „button“ ar „link“, perėmimas į alternatyvųjį tekstą. Visada verskite juos į tikslinę kalbą, nes ekrano skaitytuvai, tokie kaip JAWS ar NVDA, nuskaito naršyklės kalbos nustatymus. Be to, sudėtingoms diagramoms alternatyvųjį tekstą galite papildyti nuoroda į išsamų aprašymą – šis išsamus aprašymas taip pat turi būti visiškai lokalizuotas. Laikydamiesi šio sisteminio požiūrio užtikrinsite, kad jūsų daugiakalbiai alternatyvieji tekstai atitiktų EN 301 549 reikalavimus ir būtų kultūriškai tinkami.

ARIA žymos ir vaidmenys vertime: sintaksė ir semantika

ARIA atributai, tokie kaip aria-label, aria-labelledby, aria-describedby ar role, kiekvienoje kalboje turi būti ne tik sintaksiškai teisingi, bet ir semantiškai perteikti elemento paskirtį. Skirtingai nuo matomo teksto, ARIA žymos dažnai yra nematomos ir naudojamos tik pagalbinėse technologijose. Todėl klaidingas vertimas yra ypač kritiškas, nes jis labai apsunkina navigaciją akliesiems ir regos negalią turintiems naudotojams.

ARIA žymų sintaksė HTML kalba atitinka fiksuotą šabloną: aria-label="Aprašymas". Lokalizavimo metu turite užtikrinti, kad išverstas aprašymas pateiktų tą patį kontekstą kaip ir originalas. Pavyzdžiui, aria-label „Meniu atidaryti“ vokiškai apibūdina veiksmą, kuris prancūziškai verčiamas kaip „Ouvrir le menu“ – tačiau reikia atsižvelgti ir į gramatiškai teisingą didžiųjų raidžių rašymą (Menu vietoj menu) prancūzų kalboje. Praktikoje pastebima, kad ekrano skaitymo priemonės, pvz., VoiceOver sistemoje macOS, kartais ignoruoja priešdėlinius artikulius („der“, „die“, „das“), todėl vokiškose ARIA žymose geriau vengti artikulių. Kitokia situacija yra romanų kalbose: ten artikuliai dažnai būtini suprantamumui.

Svarbus dalykas yra ARIA vaidmenų, tokių kaip role="button", role="navigation" ar role="alert", tvarkymas. Šie vaidmenys yra standartizuoti HTML specifikacijoje ir nėra verčiami – jie turi likti nepakeisti kode. Tačiau su jais susijusios žymos yra verčiamos. Venkite į žymą įtraukti vaidmens aprašymų, pvz., „mygtukas“, nes ekrano skaitymo priemonės vis tiek paskelbs vaidmenį. Vietoj to, žyma turėtų apibūdinti funkciją, pvz., „Siųsti“ vietoj „Siųsti mygtukas“. Kalbant apie dinamines sudedamąsias dalis, pvz., modalinius langus, ar reikia versti tokius atributus kaip aria-hidden ar aria-expanded? Ne, jų reikšmės (true/false) yra kalbos atžvilgiu neutralios. Tačiau modalinio lango žyma turėtų apibūdinti, ką tas langas daro („Pritaikyti paieškos filtrus“).

Savo CMS ar šablonų sistemoje naudokite vietos rezervavimo ženklus ARIA žymoms, kurios verčiamos pagal raktus. Kiekvienai naujai kalbai patikrinkite ARIA sintaksę atitinkamose naršyklėse ir pagalbinėse technologijose. Ypač svarbu: keičiant kryptį iš kairės į dešinę (pvz., arabų kalba), aria-label nereikia veidrodžiškai atspindėti – aprašymas išlieka tikslinės kalbos skaitymo kryptimi. Tačiau atkreipkite dėmesį, kad ARIA žymos ne visose ES kalbose veikia vienodai gerai: estų ir latvių ekrano skaitymo priemonėse specialiųjų simbolių tarimas gali skirtis – todėl išbandykite su gimtakalbiais. Siekdami teisiškai patikimo įgyvendinimo, rekomenduojame, kad ARIA žymų vertimą patikrintų profesionalus vertėjas, išmanantis ekrano skaitymo priemones. Tai nėra jūsų pačių teisinės konsultacijos pakaitalas, tačiau svarbus žingsnis siekiant atitikties.

Prieinamumo perdangos: dinamiškų komponentų lokalizavimo strategijos

Prieinamumo perdangos yra dinaminiai elementai, tokie kaip paieškos pasiūlymai, įrankių užuominos ar modaliniai langai, kurie rodomi virš pagrindinio turinio. Jų lokalizavimas kelia ypatingus reikalavimus, nes jie dažnai generuojami naudojant JavaScript ir turi vienu metu palaikyti kelias kalbas. Perdangoje paprastai yra tekstas, mygtukai, ARIA atributai ir būsenos pranešimai – visi šie komponentai kiekvienoje tikslinėje kalboje turi būti nuosekliai išversti.

Lokalizavimo strategija prasideda nuo turinio ir logikos atskyrimo. Visus tekstus, rodomus perdangoje, saugokite centriniame išteklių faile (JSON, XML ar PO). Kiekvienas teksto blokas gauna unikalų raktą, pvz., "search.placeholder" arba "modal.close". Dinaminėse perdangose, pvz., automatinio užbaigimo sąrašuose, reikia atsižvelgti ir į gyvas sritis (aria-live): pranešimas, pvz., „Rasti 3 rezultatai“, tikslinėje kalboje formuluojamas kitaip – lenkiškai, pvz., „Znaleziono 3 wyniki“ su tinkama skaičiaus forma. Todėl programuotojai turėtų nustatyti vietos rezervavimo ženklus daugiskaitos taisyklėms, kurios skiriasi priklausomai nuo kalbos.

Dažna problema yra persidengiančios perdangos: įrankių užuomina, rodoma virš modalinio lango, turi būti ta pačia kalba kaip ir modalinis langas. Įsitikinkite, kad perdangos kalbos nustatymas dinamiškai susietas su dabartinio puslapio kalba. Venkite perdangų rodymo per CSS ir vertimo per JavaScript – patirtis rodo, kad taip atsiranda vertimo spragų, pavyzdžiui, kai vertimas įkeliamas tik po inicijavimo. Vietoj to naudokite serverio pusės atvaizdavimą arba i18n sistemą, kuri vertimą įterpia jau kuriant DOM.

Išbandykite perdangas kiekvienoje tikslinėje rinkoje su ekrano skaitymo priemone. Ypač modaliniai langai turi išlaikyti fokusą perdangos viduje – tai galioja nepriklausomai nuo kalbos, tačiau mygtukai turėtų būti vietine kalba (pvz., „Uždaryti“ vietoj „Close“). Lokalizuodami atkreipkite dėmesį ir į tekstų ilgį: vokiškas tekstas „Bitte wählen Sie eine Option aus“ rumuniškai bus trumpesnis – kitoms kalboms, pvz., suomių, reikia daugiau vietos. Todėl planuokite lanksčius konteinerius, kurie prisitaiko prie teksto. Teisinis pastebėjimas: atitiktis EN 301 549 reikalauja, kad visas turinys būtų prieinamas – įskaitant dinamiškai įkeltas perdangas. Sudėtingų perdangų atveju pasikonsultuokite su prieinamumo ekspertu; tai nepakeičia teisinės konsultacijos, tačiau yra rekomenduojama.

Kelių kalbų ekrano skaitytuvų suderinamumo testavimas

Ekrano skaitytuvų suderinamumo patikrinimas 24 kalbomis reikalauja sistemingo požiūrio, kuris peržengia paprastų vertimų ribas. Patirtis rodo, kad daugiausia problemų kyla, kai ekrano skaitytuvas netinkamai atpažįsta kalbos pakeitimą arba kai dinaminis turinys, pvz., klaidų pranešimai, nėra ištariamas.

Pradėkite nuo testavimo matricos, apimančios visas tikslines kalbas ir populiariausius ekrano skaitytuvus – Windows: JAWS ir NVDA, macOS: VoiceOver, mobiliesiems: TalkBack (Android) ir VoiceOver (iOS). Išbandykite kiekvieną kalbos versiją su visais aktualiais ekrano skaitytuvais, nes specialiųjų simbolių (pvz., ß, é, ç) tarimas ir skaitymo tvarka gali skirtis.

Praktinis pavyzdys: vokiškoje versijoje ekrano skaitytuvas naršydamas su Tab klavišu turi pranešti apie fokusą ant spustelėjamų elementų teisinga tvarka. Kai dinaminis turinys, pvz., išskleidžiamasis meniu, atnaujinamas naudojant JavaScript, ekrano skaitytuvas turi būti informuotas – per ARIA Live regionus. Lokalizuokite Live region tekstus į kiekvieną tikslinę kalbą, kad vartotojai suprastų, koks pakeitimas įvyko.

Taip pat atlikite rankinius testus su tikrais regėjimo negalią turinčiais vartotojais, kalbančiais atitinkama gimtąja kalba. Automatiniai įrankiai, tokie kaip axe ar Lighthouse, aptinka tik pagrindines klaidas, bet ne kalbai būdingas tarimo problemas. Papildykite savo testus kalbos perjungimo patikra: kai puslapis perjungiamas iš vokiečių į prancūzų ar lenkų kalbą, HTML lang atributas turi būti teisingai nustatytas, kad ekrano skaitytuvas įkeltų tinkamą kalbos valdymą. Tam naudokite kalbai specifinius testavimo atvejus, užtikrinančius, kad garsiniai signalai ir kalbos sintezės pauzės atitiktų vietines tradicijas.

Kitas kritinis aspektas – kelių kalbų klaviatūros spartieji klavišai: kiekvienoje kalboje klavišų kombinacijos, pvz., Ctrl+C ar Alt+kažkas, gali būti skirtingai interpretuojamos ekrano skaitytuvuose. Išbandykite visus sparčiuosius klavišus kiekvienoje kalboje ir, esant konfliktams, juos pritaikykite. Dokumentuokite rezultatus centriniame testavimo protokole, kuris atnaujinamas kasmet, nes ekrano skaitytuvų versijos ir kalbos atpažinimas nuolat tobulėja.

Kalbai būdingi klaviatūros navigacijos ypatumai

Klaviatūros navigacija yra pagrindinis prieinamų svetainių elementas, kuris kiekvienoje kalboje reikalauja savo pritaikymų. Nors pagrindiniai principai, tokie kaip loginė fokuso tvarka ir matomas fokuso indikatorius, nepriklauso nuo kalbos, lokalizuojant į 24 ES kalbas išryškėja specifiniai iššūkiai.

Esminis skirtumas yra klaviatūros išdėstymai: vokiškai kalbantys vartotojai naudoja QWERTZ, o Prancūzijoje įprastas AZERTY, o Lenkijoje – QWERTY su papildomais diakritiniais ženklais. Todėl Tab klavišo seka turi būti sukurta taip, kad ji išliktų intuityviai valdoma visuose išdėstymuose. Venkite fiksuotų klaviatūros sparčiųjų klavišų, priklausomų nuo konkrečių klavišų pozicijų – pavyzdžiui, kombinacija Strg+UML vokiškose klaviatūrose neturėtų būti priskirta funkcijai, kuri prancūziškose klaviatūrose aktyvuojama kitu klavišu.

Dešinės į kairę kalbose, tokiose kaip arabų ar hebrajų, fokuso tvarka yra veidrodinė: pirmasis interaktyvus elementas yra viršuje dešinėje. Turite dinamiškai pritaikyti Tab indekso reikšmes pagal kalbos kryptį, kad navigacija vyktų pagal skaitymo srautą. Tam naudokite dir atributą konteinerio lygmenyje ir išbandykite navigaciją su ekrano skaitytuvu, palaikančiu RTL.

Kitas punktas – šaliai būdingos klavišų kombinacijos specialiesiems simboliams: Ispanijoje raidė Ñ įvedama naudojant AltGr+N, o Skandinavijoje Å, Ä ir Ö pasiekiami atskirais klavišais. Jei jūsų svetainėje yra vartotojiškai pritaikyti klaviatūros spartieji klavišai, pvz., paieškai ar spausdinimui, jie neturėtų naudoti simbolių, kurie tam tikruose išdėstymuose sunkiai pasiekiami. Alternatyviai suteikite galimybę pritaikyti sparčiuosius klavišus nustatymuose.

Praktinės rekomendacijos: naudokite pakankamo kontrasto fokuso indikatorius (bent 3:1 fono atžvilgiu) ir mažiausią 2 pikselių storį. Išbandykite navigaciją be pelės kiekvienoje kalboje, bent jau naudodami Firefox ir Chrome „Windows“ ir „macOS“ sistemose. Atkreipkite dėmesį, kad fokuso tvarka turi išlikti net ir dinamiškai rodomame turinyje, pvz., lightbox ar modaliniuose languose – čia padeda aria-haspopup naudojimas ir nuoseklus fokuso gaudymas.

Material dizainas ir prieinamumas: pritaikymas 24 kalboms

Prieinamų „Material Design“ komponentų diegimas 24 kalbomis reikalauja daugiau nei tik teksto vertimo. „Google“ „Material Design“ pateikia pagrindinius ARIA modelius, tačiau juos reikia kultūriškai ir kalbiškai pritaikyti kiekvienai kalbai, kad būtų laikomasi EN 301 549.

Pagrindiniai komponentai, tokie kaip naršymo stalčius, skirtukai, dialogai ir formos, turi skirtingą teksto ilgį priklausomai nuo kalbos. Vokiški žodžiai vidutiniškai yra 30 % ilgesni nei angliški, todėl horizontalūs meniu ar mygtukai be dinaminio pločio pritaikymo gali perpildyti. Naudokite nuo kalbos priklausančias CSS klases, valdomas per lang atributą, ir kiekvienai kalbai nustatykite fiksuotus, bet pakankamus minimalius pločius. Skirtukams ir lusteliams rekomenduojama vertikali išdėstymas arba horizontalus slinkimas ilgiems tekstams.

Kalboms, rašomoms iš dešinės į kairę, visi komponentai turi būti veidrodiniai. „Material Design“ tai palaiko per dir atributą, tačiau būtina užtikrinti, kad pasirinktinės piktogramos ar šešėlių kryptys taip pat būtų pritaikytos. Pavyzdžiui, rodyklė, rodanti į dešinę, RTL atveju turi rodyti į kairę. Išbandykite kiekvieną komponentą su RTL kalbos ekrano skaitytuvu, nes ARIA etiketės taip pat turi būti veidrodinės.

Formų elementai, pvz., įvesties laukai, reikalauja kalbai specifinių patvirtinimo pranešimų, kuriuos perskaito ekrano skaitytuvai. Naudokite aria-describedby, kad dinamiškai susietumėte klaidų pranešimus, ir lokalizuokite visus pranešimus, įskaitant rezervinį tekstą. Atkreipkite dėmesį, kad datos ir skaičių formatai atitiktų vietinius įpročius – Suomijoje data rašoma tt.MM.jjjj, Maltoje dd/mm/yyyy. Datos parinkiklis turi siūlyti šiuos formatus pagal kalbą ir atitinkamai pritaikyti klaviatūros naršymą.

Rekomendacijos: sukurkite stiliaus gairių dokumentą, kuriame kiekvienai kalbai nustatyti tikslūs matmenys, kontrasto santykiai (teksto fone mažiausiai 4,5:1) ir ARIA modeliai. Naudokite „Figma“ arba „Sketch“ „Material Design“ rinkinį peržiūroms, bet patikrinkite kiekvieną komponentą su prieinamumo įrankiu atitinkama kalba. Leiskite gimtosios kalbos naudotojams, dirbantiems su ekrano skaitytuvu ir klaviatūra, išbandyti vartotojo sąsają, kad nustatytumėte netikėtus išdėstymo poslinkius ar fokuso praradimus. Atminkite, kad teisiškai privalomą konsultaciją dėl EN 301 549 laikymosi turėtų atlikti teisės ekspertas.

Kontrasto reikalavimai: spalvos, šriftai ir tekstai skirtinguose rašmenyse

Kontrasto reikalavimų laikymasis yra pagrindinė prieinamo žiniatinklio dizaino dalis. Praktiškai turite ne tik atitikti WCAG 2.1 kriterijų 1.4.3 (mažiausias kontrasto santykis 4,5:1 įprastam tekstui ir 3:1 dideliam tekstui), bet ir atsižvelgti į rašto sistemų skirtumus. Taigi šriftas, kuris lotyniškoje abėcėlėje atrodo pakankamai kontrastingas, kirilicos ar graikų rašmenyse gali staiga prarasti įskaitomumą. Todėl rekomenduojame atlikti kontrasto testus su visais atitinkamais rašmenimis – geriausia su realiais teksto pavyzdžiais iš jūsų tikslinės kalbos.

Renkantis spalvas taip pat turėtumėte atsižvelgti į spalvų matymo sutrikimus. Maždaug 8 % vyrų turi raudonai žalią silpnaregystę; ši dalis skiriasi priklausomai nuo regiono. Praktiškai naudokite simuliatorius, tokius kaip „Colorblindly“ naršyklės įskiepis arba integruotus kūrėjų įrankius, kad patikrintumėte savo spalvų derinius. Taip pat pasirūpinkite, kad informacija nebūtų perteikiama tik spalva – papildykite, pavyzdžiui, simboliais ar tekstiniais užrašais. Tai ypač svarbu diakritiniais ženklais pažymėtiems šriftams, kurie esant mažam kontrastui greitai sulieja.

Nelotyniškiems raštams, tokiems kaip arabų, kinų ar devanagari, reikalingi atskiri testai, nes vidutinis brūkšnio storis ir rašmenų sudėtingumas skiriasi. Praktiškai pasiteisino, kiekvienam šriftui atlikti atskirą kontrasto patikrą su atitinkamu tekstu, o ne pasikliauti vien bendromis spalvų reikšmėmis. Įrankiai, tokie kaip „The Paciello Group“ „WCAG Contrast Checker“, leidžia įvesti priekinio ir fono spalvas; išbandykite jas su faktiniais jūsų svetainės šrifto dydžiais.

Konkreti veiksmų rekomendacija: kiekvienai kalbai sukurkite stiliaus gairių dokumentą, kuriame nustatomi minimalūs kontrasto santykiai įvairiems šrifto dydžiams ir storiui. Verčiant tekstus patikrinkite, ar naudojamas šriftas tiksline kalba užtikrina tokį patį įskaitomumą. Jei reikia, apsvarstykite alternatyvų šriftą, atitinkantį kontrasto reikalavimus. Atminkite, kad gairės taip pat taikomos dinaminiam turiniui, pvz., užvedimo efektams ar slinkties tekstams. Šis procesas turėtų būti jūsų reguliarios lokalizacijos darbo eigos dalis. Atkreipkite dėmesį, kad teisiniai reikalavimai gali skirtis priklausomai nuo ES šalies; abejonių atveju kreipkitės teisinės konsultacijos.

Kokybės užtikrinimas: tikrinimo sąrašai išverstiems prieinamumo komponentams

Kokybės užtikrinimas (KU) lokalizuotiems prieinamumo komponentams reikalauja sistemingo požiūrio, kuris peržengia paprastus vertimo patikrinimus. Praktiškai turėtumėte įdiegti daugiapakopį tikrinimo sąrašą, apimantį tiek kalbinius, tiek techninius aspektus. Pradėkite nuo automatizuojamo patikrinimo: ekrano skaitytuvų testai su įrankiais, tokiais kaip NVDA ar JAWS atitinkamomis kalbomis. Patikrinkite, ar visos ARIA etiketės teisingai perskaitomos ir ar klaviatūros naršymas veikia tiksline kalba. Ypač atkreipkite dėmesį į dinaminį turinį, pvz., perdangas ir iššokančius langus, kurie skirtingose kalbose gali būti skirtingai sudaryti.

Esminis dalykas yra alternatyviųjų tekstų ir etikečių nuoseklumas. Sukurkite centrinę terminologijos duomenų bazę, kurioje terminai, tokie kaip „Uždaryti“, „Meniu“ ar „Paieškos laukas“, būtų saugomi pagal kalbą. KU metu kiekvienas vertimas turėtų būti tikrinamas pagal šią duomenų bazę, siekiant išvengti nevienodų formuluočių. Be to, rekomenduojame patikrinti svetainės prieinamumo deklaracijos išsamumą visomis tikslinėmis kalbomis. Pagal ES direktyvą (EN 301 549) ji turi apimti tam tikrus privalomus duomenis ir būti parašyta suprantama kalba.

Atlikite rankinius testus su gimtosios kalbos tikrintojais, kurie moka kalbą ir turi patirties su pagalbinėmis technologijomis. Šie testuotojai turėtų atlikti tipinius naudojimo scenarijus: formos užpildymą, naršymą produkto puslapyje ar straipsnio skaitymą su ekrano skaitytuvu. Dokumentuokite rezultatus standartizuotoje klaidų ataskaitoje, kuri gali apimti ekrano kopijas ir garso įrašus. Kartokite šiuos testus po kiekvieno kalbinio ir techninio svetainės atnaujinimo.

Konkreti veiksmų rekomendacija: sukurkite kontrolinį sąrašą, kurį naudosite kiekvienam lokalizuotam komponentui. Jame turėtų būti tokie punktai kaip: Ar visi alt tekstai yra ir prasmingi? Ar ARIA etiketės teisingai atvaizduojamos? Ar klaviatūros naršymas veikia be vėlavimų? Ar kontrastas tinka visiems rašmenims? Paprašykite kolegų ar išorės vertintojų patvirtinti sąrašą. Jei negalite aiškiai įvertinti teisinių reikalavimų, pasitarkite su teisės konsultantu. KU yra nuolatinis procesas, kuris turi būti integruotas į jūsų lokalizavimo darbo eigą.

Įrankiai ir darbo eigos: KI vertimo integravimas su gimtosios kalbos patikra

KI vertimo ir gimtosios kalbos patikros derinys gali padidinti prieinamų komponentų lokalizavimo efektyvumą, jei procesai yra tinkamai nustatyti. Praktikoje pasiteisino dviejų etapų darbo eiga: pirma, visi tekstai – įskaitant alt tekstus, ARIA etiketes ir ekrano skaitytuvo tekstus – siunčiami per KI vertimo įrankį. Įsitikinkite, kad įrankis gauna specialius žymeklius ar kodus (pvz., HTML žymas, vietos rezervavimo ženklus), kad jie nebūtų išversti ar sugadinti. Tada atliekamas rankinis tikrinimas, kurį atlieka gimtosios kalbos vertintojas, vertinantis ne tik kalbos kokybę, bet ir techninį teisingumą.

Svarbi sąlyga yra gerai struktūrizuota vertimo atmintis (Translation Memory), kurioje yra pasikartojantys terminai ir frazės. Tai užtikrina, kad, pavyzdžiui, terminas „Uždaryti mygtukas“ būtų verčiamas vienodai visomis kalbomis. Prieinamumo komponentams rekomenduojame turėti atskirus glosarijus, kuriuose taip pat yra kontekstinės vertimo taisyklės – pavyzdžiui, kad ARIA etiketėje visada būtų aprašoma funkcija, o ne tik vaizdinis elementas. Integruokite šiuos glosarijus tiesiai į savo KI vertimo įrankį, kad pagerintumėte neapdorotų vertimų kokybę.

Darbo eiga taip pat turėtų apimti automatizuotus kokybės patikrinimus, pvz., neišverstų teksto segmentų ar klaidingos ARIA sintaksės aptikimą. Įrankiai, tokie kaip „GreatBlanc“ ar „Accessible Web“, siūlo sąsajas, leidžiančias įtraukti tokius patikrinimus į vertimo procesą. Po vertimo tekstai pereina antrą tikrinimo etapą: gimtosios kalbos redaktorius išbando komponentus su ekrano skaitytuvu tiksline kalba. Šis testas yra lemiamas, nes KI vertimai dažnai netinkamai perteikia toną ar idiominį skaitomumą. Pavyzdžiui, per daug pažodžiui išverstas sakinys ekrano skaitytuve gali tapti nesuprantamas.

Konkreti veiksmų rekomendacija: nustatykite standartizuotą procedūrą kiekvienai naujai kalbai: 1) Sukurkite glosariumą ir vertimo atmintį prieinamumo tekstams. 2) Atlikite KI vertimą su kontekstinėmis taisyklėmis. 3) Integruokite automatinę sintaksės patikrą. 4) Atlikite gimtosios kalbos patikrą su ekrano skaitytuvo testu. 5) Patvirtinkite po kokybės kriterijų įvykdymo. Dokumentuokite darbo eigas savo projektų valdymo įrankyje. Atkreipkite dėmesį, kad šis procesas turi būti reguliariai pritaikomas prie naujų kalbų ir technologijų tendencijų. Teisės konsultantas gali padėti užtikrinti, kad jūsų darbo eiga atitiktų EN 301 549 teisinius reikalavimus.

Tarptautinės prieinamumo patikros kontrolinis sąrašas

Išsami prieinamumo patikra 24 kalbomis reikalauja sistemingo požiūrio, apimančio tiek automatizuotus įrankius, tiek rankinius testus, kuriuos atlieka gimtosios kalbos ekspertai. Pradėkite nuo audito planavimo: kiekvienai kalbai apibrėžkite reprezentatyvų puslapių rinkinį – bent jau pagrindinį puslapį, produkto puslapį, formą ir kontaktų puslapį. Naudokite automatizuotus tikrinimo įrankius, tokius kaip Axe ar WAVE, kad nustatytumėte technines klaidas, tačiau nepasikliaukite vien jais. Praktikoje šie įrankiai atskleidžia tik apie 30 % problemų, ypač kalbant apie kalbai būdingus aspektus.

Verčiant prieinamumo perdangas (accessibility overlays) ir ARIA žymes, turite užtikrinti, kad ekrano skaitytuvai teisingai atkurtų tinkamą kalbos versiją. Patikrinkite, ar `lang` atributai nustatyti kiekviename puslapyje ir ar dinaminis turinys, pvz., modaliniai dialogai ar gyvosios sritys (live regions), gerbia dabartinį kalbos pasirinkimą. Dažna problema: ARIA žymė vokiečių kalba gali būti gramatiškai teisinga, bet lenkų kalba dėl trūkstamų galūnių tampa nesuprantama. Todėl visada leiskite gimtosios kalbos tikrintojui įvertinti žymių ir alternatyvių tekstų suprantamumą.

Atlikite rankinius testus su įprastais ekrano skaitytuvais, tokiais kaip NVDA (vokiečių, anglų) ar JAWS, taip pat su VoiceOver „iOS“ ir TalkBack „Android“ sistemose. Išbandykite klaviatūros naršymą: visi interaktyvūs elementai turi būti fokusuojami, o fokusas turi logiškai sekti atitinkamos kalbos skaitymo kryptį – dešinės krypties kalbose, tokiose kaip arabų, iš dešinės į kairę. Atkreipkite dėmesį į kontrastus: spalvos ir šriftų dydžiai gali skirtis kalbose su kitokiais rašmenimis (pvz., kinų ar kirilica). Naudokite kontrasto tikrintuvą, kuris imituoja spalvų suvokimą skirtingais šriftais.

Dokumentuokite visus tikrinimo rezultatus kontroliniame sąraše, kuriame kiekvienai kalbai būtų nurodyti kriterijai: WCAG 2.1 A ir AA lygių laikymasis, teisingas visų tekstų vertimas, veikiančios praleidimo nuorodos (skip links), nuosekli navigacija ir nepriekaištingas ARIA diegimas. Suplanuokite reguliarius auditus – geriausia po kiekvieno turinio atnaujinimo. Atkreipkite dėmesį: šis kontrolinis sąrašas nepakeičia teisiškai įpareigojančios patikros; teisiniais klausimais kreipkitės į savo teisės skyrių. Kruopšti tarptautinė patikra sumažina ieškinių riziką ir pagerina visų lankytojų naudotojo patirtį.

Perspektyva: Būsimi ES reikalavimai ir tvari lokalizacijos praktika

ES nuolat griežtina prieinamumo reikalavimus. Europos prieinamumo aktas (EAA) nuo 2025 m. birželio taps privalomas daugeliui produktų ir paslaugų. Ateityje galima tikėtis griežtesnių reikalavimų daugiakalbiui diegimui – ypač dinaminio turinio ir dirbtinio intelekto vertimų srityje. Įmonės turėtų anksti pasiruošti nacionalinių įstatymų suderinimui, kuris gali viršyti EN 301 549 standartą. Praktiškai tai reiškia: investuokite į sistemas, kurios prieinamumą integruoja nuo pat lokalizacijos proceso pradžios, o ne taiso vėliau.

Tvarus požiūris – tai daugiakalbių prieinamumo komandų, sudarytų iš kūrėjų, UX dizainerių ir gimtosios kalbos redaktorių, sukūrimas. Šios komandos turėtų būti tvirtai įtrauktos į CI/CD darbo eigą, kad kiekvienas vertimas būtų automatiškai tikrinamas dėl WCAG atitikties. Naudokite DI vertimus, tačiau visus su prieinamumu susijusius tekstus (pvz., alternatyvius tekstus ir ARIA žymes) palikite patikrinti gimtosios kalbos ekspertui. Patirtis rodo, kad toks automatizavimo ir žmogiškosios patikros derinys žymiai sumažina klaidų skaičių.

Technologijos pasirinkimas taip pat veikia tvarumą: rinkitės sistemas, kurios natūraliai palaiko prieinamumą, pvz., React su ARIA bibliotekomis arba Angular su prieinamumo moduliais. Venkite patentuotų perdangų (overlay) sprendimų, kuriuos dažnai sunku lokalizuoti ir kurie kelia teisinę riziką. Vietoj to naudokite gimtosios HTML kalbos elementus, kuriuos ekrano skaitytuvai gali geriau interpretuoti. Suplanuokite reguliarius mokymus savo lokalizacijos partneriams apie specifinius prieinamumo reikalavimus įvairiomis kalbomis.

Galiausiai verta atkreipti dėmesį į planuojamą ES direktyvą dėl viešojo sektoriaus svetainių ir mobiliųjų programėlių skaitmeninio prieinamumo, kuri taip pat paveiks privačias įmones. Tvari lokalizacijos sistema nėra vienkartinis projektas, o nuolatinis procesas. Dokumentuokite savo procesus ir dalinkitės gerąja praktika su kitais padaliniais. Atminkite: šis vertinimas nepakeičia teisinės konsultacijos; dėl konkrečių atitikties klausimų kreipkitės į savo teisininką. Taikydami aktyvų požiūrį ne tik išliksite atitinkantys reikalavimus, bet ir atversite savo paslaugas platesnei vartotojų grupei.

Spąstai ir dažnos klaidos lokalizuojant prieinamumą

Lokalizuojant prieinamą turinį į 24 kalbas nuolat pasitaiko panašių klaidų. Dažnas spąstas – tiesioginis alternatyviųjų tekstų ar ARIA etikečių vertimas neatsižvelgiant į tikslinę kalbą ir kultūrą. Pavyzdžiui, vaizdinis posakis „Spausk čia“ vokiškai veikia, lenkiškai gali skambėti nenatūraliai arba sukelti netinkamas asociacijas. Taip pat problematiški yra pažodiniai būsenos pranešimų vertimai, pavyzdžiui, klaidų pranešimai formose: „Field is required“ vokiškai tampa „Feld ist erforderlich“, o tai nors ir teisinga, bet ekrano skaitytuvų naudotojams gali būti mažiau suprantama. Geriau būtų „Dieses Feld muss ausgefüllt werden“ („Šis laukas turi būti užpildytas“).

Kita klaida – netinkamas kalbos atributų (lang atributų) valdymas. Daugiakalbiuose puslapiuose kūrėjai dažnai pamiršta dinamiškai keisti kalbos atributą keičiant kalbą. Ekrano skaitytuvai tada netinkamai atpažįsta kalbą, o tai lemia iškraipytą tarimą. Praktiškai kiekvienas teksto lygmuo – tiek HTML pagrinde, tiek ARIA etiketėse – turėtų būti aiškiai pažymėtas teisingu kalbos kodu.

Taip pat dažnai nepakankamai įvertinami kalbų ilgio skirtumai. Vokiški tekstai vidutiniškai ilgesni nei angliški ar prancūziški. Alternatyvus tekstas, kuris anglų kalba turi 100 simbolių, vokiškai gali reikalauti 130 simbolių. Jei vartotojo sąsaja turi fiksuotus išdėstymus, tai lemia nukirptus tekstus arba persidengiančius elementus. Todėl nuo pradžių planuokite lanksčius konteinerius arba palikite rezervą teksto plėtimuisi.

Specifinė ARIA etikečių problema – skirtingos ekrano skaitytuvų skaitymo taisyklės. Kol angliška etiketė skaitoma kaip „Button: Senden“, vokiška versija labiau tikisi „Schaltfläche: Senden“. Prisitaikymas prie šalies skaitymo standartų dažnai pamirštamas. Todėl kiekvieną kalbai specifinį įgyvendinimą išbandykite su gimtosios kalbos ekrano skaitytuvu (pvz., JAWS, NVDA, VoiceOver).

Galiausiai, prieinamumo deklaracijų vertimo klaidos dažnai sukelia teisinį neapibrėžtumą. EN 301 549 reikalauja tikslios informacijos apie atitiktį. Jei paslaugų teikėjas deklaraciją išverčia tik apytiksliai, svetainė gali būti laikoma neatitinkančia reikalavimų. Todėl visus teisiškai svarbius tekstus leiskite patikrinti teisės specialistui.

Venkite šių spąstų, kurdami aiškius prieinamumo vertimų stiliaus gaires ir reguliariai atlikdami ekrano skaitytuvų testus visomis tikslinėmis kalbomis. Rekomenduojamas glaudus lokalizavimo komandos ir prieinamumo ekspertų bendradarbiavimas.

Bendradarbiavimas su paslaugų teikėjais ir išlaidų valdymas

Prieinamumo turinio lokalizavimas į 24 kalbas reikalauja profesionalaus koordinavimo su specializuotais paslaugų teikėjais. Rinkitės tiekėjus, turinčius tiek techninio vertimo patirties, tiek išsamių ES prieinamumo standartų (EN 301 549, WCAG 2.1) žinių. Iš anksto paklauskite nuorodų iš prieinamumo lokalizavimo srities ir patikrinkite, ar vertėjai dirba gimtąja kalba ir gali testuoti su ekrano skaitytuvais.

Patikrintas modelis – DI vertimo ir gimtosios kalbos tikrinimo derinys. DI atlieka pirminį alternatyviųjų tekstų, ARIA etikečių ir klaidų pranešimų vertimą, o žmogaus tikrintojas užtikrina semantinį tikslumą, kultūrinį tinkamumą ir techninį teisingumą. Tai taupo išlaidas ir laiką nepakenkiant kokybei. Svarbu, kad tikrintojas taip pat išmanytų prieinamumo gaires – vien kalbos tikrintojo dažniausiai nepakanka.

Skaičiuodami išlaidas, atsižvelkite į šiuos punktus: prieinamumo deklaracijos ir teisinių tekstų vertimas (dažnai pagal žodžių ar simbolių skaičių), UI komponentų lokalizavimas, įskaitant alternatyvius tekstus ir etiketes (pagal eilučių ar komponentų skaičių), techninis konsultavimas dėl kalbos atributų ir ARIA struktūrų nustatymo, ir testavimo išlaidos ekrano skaitytuvais kiekvienoje kalboje. Patirtis rodo, kad testavimo dalis sudaro apie 30–40 procentų viso biudžeto.

Dažnas prieštaravimas – prieinamumo lokalizavimas per brangus. Praktiškai išlaidas galima sumažinti anksti planuojant: jei alternatyvūs tekstai ir etiketės jau projektavimo procese yra sukuriami daugiakalbiai, nereikia brangiai kainuojančių pataisymų. Taip pat pakartotinis naudojimas – pvz., identiški simboliai su tuo pačiu alternatyviu tekstu visomis kalbomis – sumažina darbo krūvį.

Bendradarbiavimas su paslaugų teikėjais reikalauja aiškios komunikacijos: apibrėžkite pagrindinių terminų glosarijų (pvz., „mygtukas“, „navigacijos meniu“) ir nustatykite teksto ilgio apribojimus. Naudokite vertimų valdymo sistemą (TMS), kuri seka kiekvieno komponento būseną ir registruoja pakeitimus. Reguliariai atlikite peržiūras, kuriose patikrinkite išverstą turinį bandomojoje sistemoje su ekrano skaitytuvu.

Galiausiai rekomenduojama paskirti fiksuotą kontaktinį asmenį paslaugų teikėjui, kuris apžvelgtų tiek techninius, tiek kalbinius reikalavimus. Taip užtikrinsite, kad jūsų daugiakalbis prieinamumo projektas būtų užbaigtas laiku ir neviršijant biudžeto.

Prieinamumo vertimo į 24 kalbas spąstai

Lokalizuojant prieinamą turinį kyla specifinių spąstų, kurie peržengia bendrąsias vertimo klaidas. Dažna klaida yra pažodinis ARIA žymų ar alternatyvaus teksto vertimas neatsižvelgiant į tikslinės kalbos semantiką. Pavyzdžiui, angliškas žodis "Submit" vokiškai gali tapti per ilgas, todėl ekrano skaitytuvai iškraipo pranešimą. Vietoj to reikalingi sutrumpinimai, pvz., "Siųsti" arba kontekstiniai variantai. Kitas spąstas – kultūriniai skirtumai simboliuose ir piktogramose: spalvų kodas „sėkmei“ (žalia) arba „klaidai“ (raudona) daugelyje kultūrų yra vienodas, tačiau kai kuriose Azijos šalyse raudona turi teigiamą reikšmę. Prieinamos instrukcijos, nurodančios spalvas, turi būti papildytos tekstu arba pritaikytos. Taip pat „Skip to main content“ nuorodų vertimas nėra trivialus: vokiškai tai tampa „Zum Hauptinhalt springen“, tačiau ilgio pokytis gali sutrikdyti išdėstymą arba klaviatūros naršymą. Be to, daugelis neįvertina kalbos deklaracijų HTML svarbos. Jei kalbos nuoroda nustatyta neteisingai (pvz., `lang="de"` vokiečių kalbos puslapiams), ekrano skaitytuvai gali neteisingai interpretuoti turinį ir taikyti netinkamą kalbos sintezę. Kitas punktas – sudurtiniai žodžiai vokiečių kalboje, pvz., „E-Mail-Bestätigung“, kuriuos ekrano skaitytuvai dažnai skaito neteisingai, nes neatpažįsta žodžių skirstymo. Čia padeda ARIA atributai, pvz., `aria-label`, kad būtų galima valdyti tarimą. Verčiant klaidų pranešimus formose, reikia pasirūpinti, kad klaidos ID liktų unikalus ir nesutrūktų dėl kalbai būdingų pritaikymų. Praktikoje paaiškėja, kad gimtosios kalbos tikrintojai turi tikrinti ne tik gramatiką, bet ir suderinamumą su ekrano skaitytuvais. Naudingas būdas – kiekvieną išverstą komponentą patikrinti su ekrano skaitytuvu ir palyginti išvestį su anglišku etalonu. Taip anksti galima aptikti klaidas, tokias kaip neteisingi kirčiavimai ar trūkstami alternatyvūs tekstai. Be tokio aktyvaus veikimo atsiranda kliūčių, galinčių turėti teisinių pasekmių – ypač nuo 2025 m. birželio mėn. su Europos prieinamumo aktu.

Praktiniai įrankiai ir technologijos daugiakalbiams prieinamumo testams

Kokybei užtikrinti, lokalizuojant prieinamumą 24 kalbomis, yra specializuotų įrankių, kurie peržengia paprastą vertimo programinę įrangą. Pagrindinis įrankis yra ekrano skaitytuvų integravimas į testavimo darbo eigą: vietiniai sprendimai, tokie kaip NVDA (Windows) arba VoiceOver (macOS), gali būti derinami su automatizuotais testais. Kiekvienai tikslinei kalbai gimtosios kalbos testuotojas turėtų patikrinti turinį su atitinkamu ekrano skaitytuvu, nes kalbos sintezės skiriasi kokybe. Automatiniai testavimo įrankiai, tokie kaip axe-core, Wave ar Lighthouse, nors atpažįsta daug WCAG pažeidimų, tačiau yra priklausomi nuo kalbos: jie tikrina, pvz., ar yra `aria-label`, bet ne tai, ar turinys tiksline kalba yra prasmingas. Todėl automatizuoto ir rankinio testavimo derinys yra būtinas. Praktinis požiūris – naudoti vertimo valdymo sistemas (TMS) su prieinamumo funkcijomis: šiuolaikinės TMS leidžia vertimo vienetus aprašyti metaduomenimis, kad vertėjai žinotų, ar tekstas yra paveikslėlio alternatyvusis tekstas, ar mygtuko etiketė. Be to, kai kurios sistemos siūlo konteksto peržiūras tiesioginiame makete, rodančias išverstą tekstą originalioje išdėstyme. Klaviatūros naršymui tikrinti tinka naršyklės plėtiniai, pvz., „Accessibility Insights“ iš „Microsoft“, leidžiantys išbandyti fokusavimo seką visomis kalbomis. Kitas naudingas įrankis – „netikros ekrano išvestys“: naudojant CSS galima parodyti paveikslėlių tekstines alternatyvas, kad būtų patikrinta, ar vertimas yra prasmingas. Taip pat kalbos atsarginės mechanizmai HTML (pvz., `lang=de` teksto lygiu) gali būti tikrinami tokiais įrankiais kaip W3C Validator. Galiausiai rekomenduojama naudoti „prieinamumo testavimo laboratorijas“ kaip paslaugą: kai kurios agentūros siūlo specialiai daugiakalbėms svetainėms automatinių nuskaitymų ir rankinių ekrano skaitytuvų testų derinį iki 24 kalbų. Įrankių pasirinkimas priklauso nuo biudžeto ir komandos dydžio, tačiau praktikoje pasiteisina atvirojo kodo įrankių, tokių kaip axe ir Poedit (vertimo failams), bei komercinių platformų, tokių kaip Transifex ar Lokalise su prieinamumo papildiniais, derinys. Svarbu, kad visi dalyviai – vertėjai, kūrėjai ir testuotojai – naudotų tą pačią įrankių grandinę, kad būtų išvengta klaidų dėl medijų trikdžių.