Přístupnost ve 24 jazycích: Jak lokalizovat pro inkluzivní přístup na web

Základy digitální přístupnosti v kontextu EU

Digitální přístupnost označuje navrhování webového obsahu a aplikací, které mohou používat lidé s různými schopnostmi – bez ohledu na postižení, věk nebo technická omezení. V kontextu EU to vychází z pokynů Web Content Accessibility Guidelines (WCAG) 2.1 a evropské normy EN 301 549. Ty definují kritéria úspěchu, jako je poskytování alternativních textů pro obrázky, dostatečné barevné kontrasty nebo ovládání pomocí klávesnice. Pro společnosti, které lokalizují webové stránky do 24 jazyků EU, to znamená: přístupnost musí být integrována do procesu lokalizace od začátku, nikoli až dodatečně.

Klíčovým aspektem je překlad štítků ARIA (Accessible Rich Internet Applications) a alternativních textů. Atributy ARIA jako `aria-label` nebo `aria-describedby` poskytují čtečkám obrazovky dodatečné informace. Při lokalizaci je důležité, aby tyto atributy byly přeloženy nejen jazykově správně, ale také kontextově smysluplně. Příklad: Tlačítko s `aria-label="Suche absenden"` by mělo ve francouzské verzi znít `aria-label="Envoyer la recherche"` – překlad musí pro čtečku obrazovky plnit přesně stejnou funkci. Rovněž alternativní texty pro grafiku (atributy alt) musí být přesné: místo „obrázek produktu“ raději „Červená kožená taška se zipem, velikost 30x20 cm“.

V praxi se osvědčilo používat při překladu kontrolní seznam pro přístupnost. Ten by měl obsahovat body jako: Jsou všechny `alt` texty přítomny a popisné? Jsou štítky ARIA k dispozici v cílovém jazyce? Jsou klávesové zkratky (např. pro přeskočení odkazů) správně přeloženy? Kromě toho by překladatelé měli pracovat se základní znalostí kritérií WCAG. Pokud má klient specifické požadavky, například dodržení úrovně AA podle WCAG, musí lokalizace tato kritéria splňovat ve všech jazycích.

Dalším bodem: Překryvy pro přístupnost (Accessibility Overlays) musí být jazykově specificky testovány. Překryv, který dynamicky nahrazuje anglické alternativní texty, nefunguje automaticky pro německé texty. Zde je nutná úzká spolupráce mezi vývojáři a lokalizačními týmy. Doporučuje se provádět testy přístupnosti v každém jazyce – ideálně se skutečnými uživateli nebo automatizovanými nástroji jako Axe nebo WAVE, ale vždy s ohledem na jazyková specifika. Z právního hlediska je každá země EU vázána směrnicí o přístupnosti webu (Web Accessibility Directive), ale praktická implementace se liší. Proto byste se měli vždy poradit s právním poradcem, abyste přesně porozuměli svým povinnostem.

Právní požadavky: EN 301 549 a WCAG 2.1 v překladu

Norma EN 301 549 je evropským referenčním standardem pro přístupné produkty a služby IKT. Odkazuje na WCAG 2.1 úrovně AA jako minimální požadavek. Pro společnosti provozující vícejazyčné webové stránky vyvstává otázka: Jak tyto požadavky přenést do každého jazyka? Odpověď spočívá v systematickém procesu, který propojuje překlad obsahu relevantního pro WCAG s technickou implementací. Zvláštní pozornost je třeba věnovat překladu chybových hlášení, nápověd a pokynů – ty musí být nejen jazykově správné, ale také srozumitelné z hlediska přístupnosti.

Praktickým příkladem je překlad nápovědy pro vstup: Pokud pole formuláře vyžaduje určitý formát (např. datum ve formátu DD.MM.RRRR), musí být nápověda v cílovém jazyce odpovídajícím způsobem formulována. WCAG 2.1 požaduje, aby pokyny a chybová hlášení byla jasná a identifikovatelná. V překladu se z „Please enter a valid email address“ může stát „Zadejte platnou e-mailovou adresu“ – obě splňují požadavek. U složitějších pokynů, například pro CAPTCHA, je však třeba zvýšené opatrnosti. Zde doporučujeme jednotně překládat alternativní přístupné metody (např. logické otázky) ve všech jazycích.

Důležitým právním aspektem je přístupnost dokumentů, které je často také třeba překládat (např. PDF). EN 301 549 stanoví, že veškerý obsah musí být přístupný, včetně obsahu v různých jazycích. To znamená, že přeložené PDF musí být rovněž otagované, opatřené alternativními texty a čitelné pro čtečky obrazovky. V praxi to vyžaduje pracovní postup: nejprve se vytvoří přístupné originální PDF, poté se přeloží pro každý jazyk a následně se znovu zkontroluje přístupnost. Automatizované nástroje jsou nápomocné, ale ruční kontrola školenými překladateli nebo odborníky na přístupnost je nezbytná.

Vezměte prosím na vědomí, že výklad EN 301 549 se může v členských státech EU mírně lišit. Některé země mají vlastní národní zákony o přístupnosti, které přesahují směrnici EU. Proto byste se měli poradit se svým právním poradcem, zda vaše lokalizovaný obsah pokrývá i národní specifika. Příklad: V Německu je rozhodující BITV 2.0 (Barrierefreie Informationstechnik-Verordnung), která odkazuje na WCAG 2.1. Vaše přeložená webová stránka tedy musí splňovat jak evropskou normu, tak národní nařízení. Doporučujeme provést kontrolu shody pro každý cílový jazyk – interně nebo s externími poskytovateli, kteří jsou obeznámeni s místními požadavky v dané zemi.

Prohlášení o přístupnosti a jejich jazyková lokalizace

Každá veřejná webová stránka v EU musí poskytovat prohlášení o přístupnosti (Accessibility Statement), které uvádí stupeň shody. Toto prohlášení musí být vypracováno v příslušném úředním jazyce (jazycích). Pro vícejazyčné webové stránky to znamená, že prohlášení nelze jednoduše přenášet pomocí strojového překladu – musí být právně přesné a jazykově správné. Prohlášení obvykle obsahuje: údaje o dodržování úrovně shody WCAG, datum poslední aktualizace, kontaktní možnost pro zpětnou vazbu a případně výjimky nebo nepřístupný obsah.

Při lokalizaci je klíčové, aby právní odkazy byly správně přeloženy. Norma EN 301 549 a národní zákony se obvykle citují v originále, ale samotné prohlášení musí být formulováno tak, aby bylo srozumitelné pro cílovou skupinu. Věta jako „This website is partially compliant with WCAG 2.1 Level AA“ se stává „Tato webová stránka je částečně v souladu s WCAG 2.1 Level AA“. Dbejte na to, aby výrazy jako „výjimka“ nebo „nepřiměřená zátěž“ byly v právním jazyce cílového jazyka přesně definovány. V praxi se osvědčuje vytvořit vzorový text ve výchozím jazyce, který poté upraví rodilí právníci nebo odborní překladatelé pro každý cílový jazyk.

Častým problémem je lokalizace odkazů na „zpětnou vazbu“ nebo „postupy pro stížnosti“. V některých zemích EU musí být uvedeny konkrétní kontaktní místa, například národní donucovací orgány. Tyto informace musí být součástí prohlášení o přístupnosti – a to v příslušném národním jazyce. Příklad: Pro španělskou verzi by se měla uvést kontaktní adresa „Oficina de Atención a la Ciudadanía“, nikoli pouze anglický e-mail. Kromě toho musí být samotné prohlášení přístupné, tedy čitelné pomocí screenreaderů a v přístupném formátu (např. HTML se správnými úrovněmi nadpisů).

Doporučujeme zavést proces, ve kterém je prohlášení o přístupnosti součástí pracovního postupu lokalizace. Určete, kdo překlad kontroluje – ideálně právní expert se znalostí práva přístupnosti v cílové zemi. Tip z praxe: Nezveřejňujte prohlášení o přístupnosti ve výchozím jazyce a poté nepřidávejte pouze strojové překlady. Chybné překlady mohou vést k právním důsledkům, protože prohlášení je považováno za závazné prohlášení. Místo toho si naplánujte dostatek času na vytvoření a kontrolu. Udržujte prohlášení aktuální tím, že při každé větší aktualizaci překladu zkontrolujete také právní soulad. A jako vždy: Zeptejte se svého právního poradce, zda vaše lokalizace prohlášení o přístupnosti splňuje požadavky všech relevantních jurisdikcí.

Vícejazyčné alternativní texty: Techniky a kulturní přizpůsobení

Alternativní texty jsou klíčovým prvkem přístupnosti a musí být v každém cílovém jazyce nejen správně přeloženy, ale také kulturně přizpůsobeny. Přímý překlad zpravidla nestačí, protože obrazový obsah je v různých kulturách interpretován odlišně. Například symbol běžný na německém trhu pro „poštu“ (obálka) může mít v jiných zemích EU jiný význam nebo může být nutné jej nahradit místním ekvivalentem.

Pro přesnou lokalizaci doporučujeme třífázový proces: Nejprve analyzujte obrázek v kontextu webové stránky a formulujte hlavní sdělení. Poté toto sdělení nepřekládejte doslovně, ale přizpůsobte jej jazykově specifickým požadavkům – například použití určitého členu v němčině nebo dativu ve slovinských popisech. Nakonec zkontrolujte kulturní aspekty: Zobrazuje obrázek gesto, které je v cílové oblasti považováno za neslušné? Obsahuje textové prvky jako cedule nebo snímky obrazovky, které je třeba přeložit? Příklad: Obrázek s červeným kruhem a diagonální čárou znamená ve Skandinávii „zakázáno“, zatímco v jižní Evropě se častěji používá přeškrtnutý předmět. V praxi se vyplatí konzultovat referenční projekty z příslušných zemí nebo validovat s rodilými mluvčími.

Technicky implementujte alternativní texty ve vícejazyčných projektech nejlépe pomocí centrálního systému pro správu překladů (TMS). Každý obrazový prvek obdrží jedinečné ID, které je propojeno s příslušným alternativním textem ve všech jazycích. Dbejte na to, že délka alternativního textu se může lišit podle jazyka: finské texty jsou často delší, francouzské kratší. Proto si naplánujte dostatek místa – zkušenosti ukazují, že 200–250 znaků stačí pro přesný popis ve většině jazyků EU. Vyhněte se vycpávkovým slovům jako „obrázek“ nebo „logo“, protože screenreadery již ohlašují obrázek. U dekorativních grafik použijte prázdný atribut alt (alt="") – to musí být stejné ve všech jazycích.

Častou chybou je přebírání anglických klíčových slov jako „button“ nebo „link“ do alternativního textu. Ty vždy překládejte do cílového jazyka, protože screenreadery jako JAWS nebo NVDA čtou nastavení jazyka prohlížeče. Využijte také možnost u komplexních diagramů doplnit alternativní text o propojený dlouhý popis – tento dlouhý popis musí být rovněž plně lokalizován. Tímto systematickým přístupem zajistíte, že vaše vícejazyčné alternativní texty budou jak v souladu s EN 301 549, tak kulturně vhodné.

ARIA popisky a role v překladu: Syntax a sémantika

ARIA atributy jako aria-label, aria-labelledby, aria-describedby nebo role musí v každém jazyce nejen syntakticky správně, ale také sémanticky vyjadřovat účel prvku. Na rozdíl od viditelného textu jsou ARIA popisky často neviditelné a používají je výhradně asistenční technologie. Proto je chybný překlad obzvláště kritický, protože výrazně zhoršuje navigaci pro nevidomé a slabozraké uživatele.

Syntaxe ARIA popisků v HTML se řídí pevným schématem: aria-label="Popis". Při lokalizaci musíte zajistit, aby přeložený popis poskytoval stejný kontext jako originál. Například aria-label „Menü öffnen“ v němčině popisuje akci, která se do francouzštiny překládá jako „Ouvrir le menu“ – ale také je třeba dbát na gramaticky správné velké písmeno (Menu místo menu) ve francouzštině. V praxi se ukazuje, že screenreadery jako VoiceOver v macOS občas ignorují úvodní členy („der“, „die“, „das“), proto byste se u německých ARIA popisků měli členům vyhnout. U románských jazyků je tomu naopak: tam jsou členy pro srozumitelnost často nutné.

Důležitým bodem je zacházení s ARIA rolemi, jako je role="button", role="navigation" nebo role="alert". Tyto role jsou normovány ve specifikaci HTML a nepřekládají se – v kódu musí zůstat nezměněné. Přidružené popisky se však překládají. Vyhněte se zahrnutí popisů rolí jako „Schaltfläche“ do popisku, protože screenreader roli stejně ohlásí. Místo toho by měl popisek popisovat funkci, např. „Senden“ místo „Senden-Schaltfläche“. U dynamických komponent, jako jsou modální okna, je třeba překládat také atributy jako aria-hidden nebo aria-expanded? Ne, jejich hodnoty (true/false) jsou jazykově neutrální. Nicméně popisek modálního okna by měl popisovat, co modální okno dělá („Suchfilter anpassen“).

Ve svém CMS nebo templating systému používejte zástupné symboly pro ARIA popisky, které se překládají pomocí klíčů. Při každém novém jazyce zkontrolujte syntaxi ARIA v příslušných prohlížečích a asistenčních technologiích. Zvláště důležité: Při změně směru zleva doprava (např. arabština) není třeba popisek aria-label zrcadlit, ale popis zůstává ve směru čtení cílového jazyka. Mějte však na paměti, že ARIA popisky nefungují ve všech jazycích EU stejně dobře: V estonských a lotyšských čtečkách obrazovky se může lišit výslovnost speciálních znaků – proto testujte s rodilými mluvčími. Pro právně bezpečnou implementaci doporučujeme nechat překlad ARIA popisků zkontrolovat odborným překladatelem se znalostmi screenreaderů. Toto nenahrazuje vlastní právní poradenství, ale je důležitým krokem k souladu s předpisy.

Accessibility-Overlays: Lokalizační strategie pro dynamické komponenty

Accessibility-Overlays jsou dynamické prvky, jako jsou návrhy vyhledávání, tooltipy nebo modální okna, které se zobrazují nad hlavním obsahem. Jejich lokalizace klade zvláštní nároky, protože jsou často generovány JavaScriptem a musí současně podporovat více jazyků. Overlay obvykle obsahuje text, tlačítka, ARIA atributy a stavové zprávy – všechny tyto komponenty musí být v každém cílovém jazyce konzistentně přeloženy.

Lokalizační strategie začíná oddělením obsahu a logiky. Všechny texty, které se v overlayi objevují, uložte do centrálního souboru zdrojů (JSON, XML nebo PO). Každý textový blok obdrží jedinečný klíč, např. "search.placeholder" nebo "modal.close". U dynamických overlayů, jako jsou seznamy automatického doplňování, je třeba zohlednit také živé regiony (aria-live): Zpráva jako „3 Ergebnisse gefunden“ bude v cílovém jazyce formulována jinak – v polštině například „Znaleziono 3 wyniki“ s odpovídajícím tvarem čísla. Programátoři by proto měli nastavit zástupné symboly pro pravidla množného čísla, která se liší podle jazyka.

Častým problémem jsou překrývající se overlaye: Tooltip, který se zobrazí nad modálním oknem, musí být ve stejném jazyce jako modální okno. Ujistěte se, že jazykové nastavení overlaye je dynamicky propojeno s aktuálním jazykem stránky. Vyhněte se zobrazování overlayů pomocí CSS a jejich překládání pomocí JavaScriptu – zkušenosti ukazují, že tím vznikají mezery v překladu, například když se překlad načte až po inicializaci. Místo toho použijte serverové renderování nebo i18n framework, který vloží překlad již při vytváření DOMu.

Testujte overlaye v každém cílovém trhu pomocí screenreaderu. Zejména modální okna musí udržet fokus uvnitř overlaye – to platí jazykově nezávisle, ale tlačítka by měla mít názvy v místním jazyce (např. „Schließen“ místo „Close“). Při lokalizaci také zohledněte délku textů: Německý text jako „Bitte wählen Sie eine Option aus“ bude v rumunštině kratší – jiné jazyky jako finština vyžadují více místa. Proto plánujte flexibilní kontejnery, které se textu přizpůsobí. Právní upozornění: Soulad s normou EN 301 549 vyžaduje, aby všechny obsahy byly přístupné – včetně dynamicky načítaných overlayů. U složitých overlayů se poraďte s odborníkem na přístupnost; toto nenahrazuje právní poradenství, ale je doporučeno.

Testování vícejazyčné kompatibility se screenreadery

Testování kompatibility se screenreadery ve 24 jazycích vyžaduje systematický přístup, který přesahuje jednoduché překlady. Zkušenosti ukazují, že většina problémů nastává, když screenreader správně nerozpozná přepnutí jazyka nebo když nejsou oznamovány dynamické prvky, jako jsou chybové zprávy.

Začněte vytvořením testovací matice, která pokrývá všechny cílové jazyky a nejběžnější screenreadery – pro Windows: JAWS a NVDA, pro macOS: VoiceOver, pro mobilní zařízení: TalkBack (Android) a VoiceOver (iOS). Otestujte každou jazykovou verzi se všemi relevantními screenreadery, protože výslovnost speciálních znaků (např. ß, é, ç) a pořadí čtení se mohou lišit.

Praktický příklad: V německé verzi musí screenreader při navigaci pomocí klávesy Tab oznamovat fokus na klikatelných prvcích ve správném pořadí. Pokud jsou dynamické prvky, jako je rozbalovací menu, aktualizovány pomocí JavaScriptu, musí být screenreader informován prostřednictvím ARIA live regionů. Lokalizujte texty v live regionech do každého cílového jazyka, aby uživatelé pochopili, jaká změna nastala.

Dále provádějte manuální testy s reálnými uživateli se zrakovým postižením, kteří mluví daným mateřským jazykem. Automatizované nástroje jako axe nebo Lighthouse odhalí pouze základní chyby, nikoli jazykově specifické problémy s výslovností. Doplňte své testy o kontrolu přepínání jazyků: Pokud stránka přepíná mezi němčinou, francouzštinou a polštinou, musí být atribut lang v HTML správně nastaven, aby screenreader načetl správné jazykové nastavení. Použijte k tomu jazykově specifické testovací případy, abyste zajistili, že tóny a pauzy hlasového výstupu odpovídají místním zvyklostem.

Dalším kritickým bodem jsou vícejazyčné klávesové zkratky: V každém jazyce mohou být kombinace kláves jako Ctrl+C nebo Alt+ něco v screenreaderech interpretovány odlišně. Otestujte všechny zkratky v každém jazyce a v případě konfliktů je upravte. Výsledky zaznamenejte do centrálního testovacího protokolu, který se každoročně aktualizuje, protože verze screenreaderů a rozpoznávání řeči se neustále zlepšují.

Jazykově specifické zvláštnosti při navigaci klávesnicí

Navigace klávesnicí je klíčovým prvkem přístupných webových stránek, který v každém jazyce vyžaduje vlastní úpravy. Zatímco základní principy jako logické pořadí fokusu a viditelný indikátor fokusu jsou jazykově nezávislé, při lokalizaci do 24 jazyků EU vznikají specifické výzvy.

Zásadní rozdíl spočívá v rozložení klávesnic: Německy mluvící uživatelé používají QWERTZ, zatímco ve Francii je běžné AZERTY a v Polsku QWERTY s dalšími diakritickými znaky. Pořadí tabulátorů proto musí být navrženo tak, aby zůstalo intuitivní ve všech rozloženích. Vyhněte se pevným klávesovým zkratkám závislým na konkrétních pozicích kláves – například kombinace Strg+UML na německých klávesnicích by neměla být přiřazena funkci, která je na francouzských klávesnicích spouštěna jinou klávesou.

U jazyků psaných zprava doleva, jako je arabština nebo hebrejština, je pořadí fokusu zrcadleno: První interaktivní prvek je vpravo nahoře. Je třeba dynamicky přizpůsobit hodnoty tabindex směru jazyka, aby navigace probíhala ve směru čtení. Použijte k tomu atribut dir na úrovni kontejneru a otestujte navigaci se screenreaderem podporujícím RTL.

Dalším bodem jsou národně specifické kombinace kláves pro speciální znaky: Ve Španělsku se písmeno Ñ zadává pomocí AltGr+N, zatímco ve Skandinávii jsou Å, Ä a Ö k dispozici jako samostatné klávesy. Pokud vaše webové stránky poskytují uživatelsky definované klávesové zkratky pro akce jako hledání nebo tisk, neměly by používat znaky, které jsou na určitých rozloženích obtížně dosažitelné. Namísto toho nabídněte možnost přizpůsobit zkratky v nastavení.

Praktická doporučení: Nastavte indikátory fokusu s dostatečným kontrastem (alespoň 3:1 vůči pozadí) a minimální tloušťkou 2 pixely. Otestujte navigaci bez myši v každém jazyce, minimálně ve Firefoxu a Chromu pod Windows a macOS. Mějte na paměti, že pořadí fokusu musí být zachováno i u dynamicky zobrazovaných prvků, jako jsou lightboxy nebo modální okna – zde pomáhá použití aria-haspopup a konzistentní focus trapping.

Materiální design a přístupnost: Úpravy pro 24 jazyků

Implementace přístupných komponent Materiálního designu ve 24 jazycích vyžaduje více než jen překlad textu. Materiální design od Googlu poskytuje základní ARIA vzory, ale ty musí být kulturně a jazykově přizpůsobeny každému jazyku, aby splňovaly EN 301 549.

Klíčové komponenty jako navigační zásuvka, záložky, dialogy a formuláře mají v závislosti na jazyku různé délky textů. Německá slova jsou v průměru o 30 % delší než anglická, takže horizontální menu nebo tlačítka bez dynamického přizpůsobení šířky mohou přetékat. Používejte jazykově závislé CSS třídy řízené atributem lang a pro každý jazyk nastavte pevné, ale dostatečné minimální šířky. U záložek a štítků doporučujeme vertikální uspořádání nebo horizontální posouvání pro dlouhé texty.

U jazyků zprava doleva musí být všechny komponenty zrcadleny. Materiální design to podporuje pomocí atributu dir, ale musíte zajistit, aby byla přizpůsobena i vlastní ikony nebo směry stínů. Například šipka směřující doprava by měla u RTL směřovat doleva. Otestujte každou komponentu s RTL screenreaderem, protože i ARIA štítky musí být zrcadleny.

Prvky formulářů, jako jsou vstupní pole, vyžadují jazykově specifické validační zprávy, které screenreader přečte. Použijte aria-describedby k dynamickému propojení chybových hlášení a lokalizujte všechny zprávy včetně zástupných textů. Dbejte na to, aby formáty data a čísel odpovídaly místním zvyklostem – ve Finsku se datum zapisuje jako tt.MM.jjjj, na Maltě jako dd/mm/yyyy. Výběr data musí tyto formáty nabízet podle jazyka a přizpůsobit tomu navigaci klávesnicí.

Doporučení: Vytvořte dokument stylového průvodce, který pro každý jazyk stanoví přesné rozměry, kontrastní poměry (text na pozadí nejméně 4,5:1) a ARIA vzory. Použijte Materiální design kit z Figmy nebo Sketche pro náhledy, ale každou komponentu ověřte nástrojem pro přístupnost v daném jazyce. Nechte rodilé mluvčí otestovat uživatelské rozhraní pomocí screenreaderu a klávesnice, aby identifikovali neočekávané posuny rozvržení nebo ztrátu fokusu. Mějte na paměti, že právně závazné poradenství ohledně souladu s EN 301 549 by měl poskytnout právní expert.

Požadavky na kontrast: Barvy, písma a texty v různých písmenech

Dodržování požadavků na kontrast je klíčovou součástí přístupného webového designu. V praxi musíte splnit nejen kritérium WCAG 2.1 1.4.3 (kontrastní poměr nejméně 4,5:1 pro běžný text a 3:1 pro velký text), ale také zohlednit rozdíly mezi systémy písma. Například písmo, které v latince působí dostatečně kontrastně, může u cyrilice nebo řeckých znaků náhle ztratit čitelnost. Proto doporučujeme provádět testy kontrastu se všemi relevantními znaky – ideálně s reálnými textovými ukázkami z vašeho cílového jazyka.

Při výběru barev dále dbejte na barvoslepost. Přibližně 8 % mužské populace trpí červeno-zelenou barvoslepostí; tento podíl se liší podle regionu. V praxi používejte simulátory jako plugin prohlížeče „Colorblindly“ nebo integrované vývojářské nástroje k ověření vašich barevných kombinací. Dále zajistěte, aby informace nebyly předávány pouze pomocí barev – doplňte je například symboly nebo textovými popisky. To je důležité zejména u písem s diakritikou, která při nízkém kontrastu rychle splývají.

Pro nelatinková písma jako arabština, čínština nebo dévanágarí jsou nutné vlastní testy, protože se liší průměrná tloušťka tahu a složitost znaků. V praxi se osvědčuje provést pro každé písmo samostatnou kontrolu kontrastu s daným textem, nikoli spoléhat pouze na obecné barevné hodnoty. Nástroje jako „WCAG Contrast Checker“ od The Paciello Group umožňují zadání barev popředí a pozadí; testujte je i se skutečnými velikostmi písma vašeho webu.

Konkrétní doporučení: Pro každý jazyk vytvořte dokument stylového průvodce, který stanoví minimální kontrastní poměry pro různé velikosti a řezy písma. Při překladu textů ověřte, zda použité písmo v cílovém jazyce nabízí stejnou čitelnost. V případě potřeby zvažte alternativní písmo, které splňuje požadavky na kontrast. Pamatujte, že pokyny platí i pro dynamický obsah, jako jsou efekty při najetí myší nebo posouvané texty. Tento proces by měl být součástí vašeho běžného lokalizačního workflow. Uvědomte si, že právní požadavky se mohou lišit podle země EU; v případě pochybností konzultujte právní poradenství.

Zajištění kvality: Kontrolní seznamy pro přeložené komponenty přístupnosti

Zajištění kvality (ZK) u lokalizovaných komponent přístupnosti vyžaduje systematický přístup, který přesahuje jednoduché kontroly překladu. V praxi byste měli zavést vícestupňový kontrolní seznam, který pokrývá jak jazykové, tak technické aspekty. Začněte s automatizovatelnou kontrolou: testy čteček obrazovky pomocí nástrojů jako NVDA nebo JAWS v příslušných jazykových verzích. Zkontrolujte, zda jsou všechny ARIA popisky správně předčítány a zda navigace pomocí klávesnice v cílovém jazyce funguje. Zvláštní pozornost věnujte dynamickému obsahu, jako jsou překryvy (overlays) a vyskakovací okna (pop-ups), která mohou být v různých jazycích strukturována odlišně.

Důležitým bodem je konzistence alternativních textů a popisků. Vytvořte centrální terminologickou databázi, ve které jsou termíny jako „Zavřít“, „Menu“ nebo „Vyhledávací pole“ uloženy specificky pro daný jazyk. Během ZK by měl být každý překlad kontrolován proti této databázi, aby se předešlo nejednotným formulacím. Dále doporučujeme zkontrolovat prohlášení o přístupnosti webu ve všech cílových jazycích na úplnost. To musí podle směrnice EU (EN 301 549) obsahovat určité povinné údaje a být sepsáno srozumitelným jazykem.

Provádějte manuální testy s rodilými mluvčími, kteří ovládají jazyk a mají zkušenosti s asistenčními technologiemi. Tito testeři by měli procházet typické scénáře použití: vyplnění formuláře, navigaci na produktové stránce nebo čtení článku pomocí čtečky obrazovky. Výsledky zdokumentujte ve standardizované zprávě o chybách, která může obsahovat snímky obrazovky a zvukové záznamy. Tyto testy opakujte po každé jazykové a technické aktualizaci webu.

Konkrétní doporučení: Vytvořte kontrolní seznam, který budete aplikovat na každou lokalizovanou komponentu. Ten by měl obsahovat body jako: Jsou všechny alt texty přítomny a smysluplné? Jsou ARIA popisky správně vydávány? Funguje navigace pomocí klávesnice bez zpoždění? Je kontrast u všech znaků správný? Nechte kontrolní seznam potvrdit kolegy nebo externími auditory. Pokud si nejste jisti právními požadavky, obraťte se na právní poradenství. ZK je kontinuální proces, který musí být integrován do vašeho lokalizačního workflow.

Nástroje a pracovní postupy: Integrace AI překladu s rodilým přezkoušením

Kombinace AI překladu a rodilého přezkoušení může zvýšit efektivitu lokalizace komponent přístupnosti, pokud jsou procesy správně nastaveny. V praxi se osvědčil dvoustupňový pracovní postup: Nejprve jsou všechny texty – včetně alt textů, ARIA popisků a textů pro čtečky obrazovky – odeslány do nástroje pro AI překlad. Ujistěte se, že nástroj obdrží speciální značky nebo kódy (např. HTML tagy, zástupné symboly), aby nebyly přeloženy nebo poškozeny. Poté následuje manuální kontrola rodilým mluvčím, který hodnotí nejen jazykovou kvalitu, ale i technickou správnost.

Důležitým předpokladem je dobře strukturovaná překladová paměť (Translation Memory), která obsahuje opakující se termíny a fráze. Tím zajistíte, že například termín „Tlačítko zavřít“ bude ve všech jazycích přeložen jednotně. Pro komponenty přístupnosti doporučujeme vést samostatné glosáře, které obsahují i kontextová pravidla překladu – například že u ARIA popisku se vždy popisuje funkce, nikoli pouze vizuální prvek. Integrujte tyto glosáře přímo do vašeho nástroje pro AI překlad, abyste zlepšili kvalitu hrubých překladů.

Pracovní postup by měl zahrnovat i automatizované kontroly kvality, například rozpoznávání nepřeložených textových segmentů nebo chybné syntaxe ARIA. Nástroje jako „GreatBlanc“ nebo „Accessible Web“ nabízejí rozhraní pro začlenění těchto kontrol do procesu překladu. Po překladu procházejí texty druhou úrovní kontroly: rodilý redaktor testuje komponenty pomocí čtečky obrazovky v cílovém jazyce. Tento test je zásadní, protože AI překlady často nesprávně zachycují tón nebo idiomatickou čitelnost. Například příliš doslovně přeložená věta se může stát ve čtečce obrazovky nesrozumitelnou.

Konkrétní doporučení: Zaveďte standardizovaný postup pro každý nový jazyk: 1) Vytvořte glosář a překladovou paměť pro texty přístupnosti. 2) Proveďte AI překlad s kontextovými pravidly. 3) Integrujte automatizovanou kontrolu syntaxe. 4) Proveďte rodilé přezkoušení s testem čtečky obrazovky. 5) Schválení po splnění kritérií kvality. Zdokumentujte pracovní postupy ve svém nástroji pro řízení projektů. Mějte na paměti, že tento proces je třeba pravidelně přizpůsobovat novým jazykovým a technologickým trendům. Právní poradenství může pomoci zajistit, že váš pracovní postup odpovídá zákonným požadavkům EN 301 549.

Kontrolní seznam pro mezinárodní audit přístupnosti

Důkladný audit přístupnosti ve 24 jazycích vyžaduje systematický přístup, který kombinuje automatizované nástroje s manuálním testováním rodilými mluvčími. Začněte plánováním auditu: pro každý jazyk definujte reprezentativní výběr stránek – alespoň úvodní stránku, stránku produktu, formulář a kontaktní stránku. Použijte automatizované nástroje jako Axe nebo WAVE k identifikaci technických chyb, ale nespoléhejte se pouze na ně. V praxi tyto nástroje odhalí jen asi 30 % problémů, zejména u jazykově specifických aspektů.

Při překladu překryvů přístupnosti a ARIA popisků musíte zajistit, aby čtečky obrazovky správně vydávaly správnou jazykovou verzi. Zkontrolujte, zda jsou na každé stránce nastaveny atributy `lang` a zda dynamický obsah jako modální dialogy nebo živé regiony respektují aktuální jazykový výběr. Častý problém: ARIA popisek může být v němčině gramaticky správný, ale v polštině kvůli chybějící deklinaci nesrozumitelný. Proto nechte popisky a alternativní texty vždy otestovat rodilým mluvčím na srozumitelnost.

Provádějte manuální testy s běžnými čtečkami obrazovky jako NVDA (němčina, angličtina) nebo JAWS, stejně jako s VoiceOver na iOS a TalkBack na Android. Otestujte navigaci klávesnicí: všechny interaktivní prvky musí být fokusovatelné a fokus musí logicky sledovat tok čtení daného jazyka – u jazyků s pravým směrem psaní jako arabština zprava doleva. Dbejte na kontrasty: barvy a velikosti písma mohou v jazycích s jinými znakovými sadami (např. čínština nebo cyrilice) působit odlišně. Použijte kontrolor kontrastu, který simuluje vnímání barev u různých fontů.

Zdokumentujte všechny výsledky auditu v kontrolním seznamu, který pro každý jazyk pokrývá kritéria: dodržení WCAG 2.1 úrovní A a AA, správný překlad všech textů, funkční skip-linky, konzistentní navigace a bezchybná implementace ARIA. Naplánujte pravidelné audity – ideálně po každé aktualizaci obsahu. Upozorňujeme: tento kontrolní seznam nenahrazuje právně závazný audit; v případě právních otázek konzultujte své právní oddělení. Pečlivý mezinárodní audit minimalizuje riziko žalob a zlepšuje uživatelský zážitek pro všechny návštěvníky.

Výhled: Budoucí požadavky EU a udržitelná lokalizační praxe

EU neustále zpřísňuje požadavky na přístupnost. Evropský akt o přístupnosti (EAA) bude od června 2025 povinný pro mnoho produktů a služeb. Do budoucna lze očekávat přísnější požadavky na vícejazyčnou implementaci – zejména u dynamického obsahu a překladů s podporou AI. Společnosti by se měly včas připravit na harmonizaci národních zákonů, která může přesahovat EN 301 549. V praxi to znamená: investujte do systémů, které integrují přístupnost od začátku do lokalizačního procesu, místo aby ji dodatečně opravovaly.

Udržitelným přístupem je vytvoření vícejazyčných týmů pro přístupnost složených z vývojářů, UX designérů a rodilých mluvčích editorů. Tyto týmy by měly být pevně začleněny do CI/CD workflow, aby každý překlad byl automaticky kontrolován na shodu s WCAG. Používejte AI překlady, ale nechte všechny texty relevantní pro přístupnost (jako alt texty a ARIA popisky) zkontrolovat rodilým mluvčím. Zkušenosti ukazují, že taková kombinace automatizace a lidské kontroly výrazně snižuje chybovost.

Volba technologie také ovlivňuje udržitelnost: vsaďte na frameworky, které nativně podporují přístupnost, jako React s ARIA knihovnami nebo Angular s moduly přístupnosti. Vyhněte se proprietárním overlay řešením, která jsou často obtížně lokalizovatelná a představují právní rizika. Místo toho používejte nativní HTML prvky, které čtečky obrazovky lépe interpretují. Naplánujte pravidelné školení pro své lokalizační partnery o specifických požadavcích přístupnosti v různých jazycích.

Konečně se vyplatí sledovat plánovanou směrnici EU o digitální přístupnosti webových stránek a mobilních aplikací veřejných institucí, která ovlivní i soukromé společnosti. Udržitelný lokalizační systém není jednorázový projekt, ale kontinuální proces. Dokumentujte své procesy a sdílejte osvědčené postupy s ostatními odděleními. Pamatujte: toto hodnocení nenahrazuje právní poradenství; pro konkrétní otázky compliance konzultujte svého právního zástupce. Proaktivním přístupem zůstanete nejen v souladu s předpisy, ale otevřete své služby širší uživatelské základně.

Úskalí a časté chyby při lokalizaci přístupnosti

Při lokalizaci přístupného obsahu do 24 jazyků se opakovaně vyskytují podobné chyby. Častým úskalím je doslovný překlad alternativních textů nebo ARIA popisků bez ohledu na cílový jazyk a kulturu. Například obrazné vyjádření jako „Klick hier“ může v němčině fungovat, ale v polštině působit nepřirozeně nebo vyvolávat nesprávné asociace. Stejně problematické jsou doslovné překlady stavových hlášení, například u chybových zpráv ve formulářích: „Field is required“ se v němčině stane „Feld ist erforderlich“, což je sice správně, ale pro uživatele screenreaderů může být méně srozumitelné. Lepší by bylo „Dieses Feld muss ausgefüllt werden“.

Další chyba se týká nesprávného zacházení s jazykovými atributy (lang atributy). U vícejazyčných stránek vývojáři často zapomínají dynamicky přizpůsobit jazykový atribut při přepínání jazyků. Screenreader pak nerozpozná jazyk správně, což vede k zdeformované výslovnosti. V praxi by měla být každá textová úroveň – ať už v základním HTML nebo v ARIA popiscích – explicitně označena správným jazykovým kódem.

Často se také podceňují rozdíly v délce mezi jazyky. Německé texty jsou v průměru delší než anglické nebo francouzské. Alternativní text, který má v angličtině 100 znaků, může v němčině potřebovat 130 znaků. Pokud uživatelské rozhraní používá pevné rozvržení, vede to k oříznutým textům nebo překrývajícím se prvkům. Proto již od začátku plánujte flexibilní kontejnery nebo ponechte rezervy pro roztažení textu.

Specifickým problémem u ARIA popisků jsou odlišná pravidla čtení screenreaderů. Zatímco v angličtině se popisek čte jako „Button: Odeslat“, německá verze očekává spíše „Schaltfläche: Senden“. Přizpůsobení místním standardům předčítání se často opomíjí. Každou jazykově specifickou implementaci proto testujte s rodilým screenreaderem (např. JAWS, NVDA, VoiceOver).

Konečně chyby při překladu prohlášení o přístupnosti často vedou k právní nejistotě. Norma EN 301 549 vyžaduje přesné údaje o shodě. Pokud poskytovatel služeb přeloží prohlášení pouze zběžně, může být web považován za nevyhovující. Proto nechte všechny právně relevantní texty zkontrolovat odborníkem na právo.

Těmto úskalím se vyhněte vytvořením jasných stylů pro překlady přístupnosti a pravidelným testováním se screenreadery ve všech cílových jazycích. Doporučuje se úzká spolupráce mezi lokalizačním týmem a odborníky na přístupnost.

Spolupráce s dodavateli a řízení nákladů

Lokalizace obsahu přístupnosti do 24 jazyků vyžaduje profesionální koordinaci se specializovanými dodavateli. Vyberte poskytovatele, kteří mají zkušenosti jak s technickým překladem, tak i s důkladnou znalostí standardů EU pro přístupnost (EN 301 549, WCAG 2.1). Předem se ptejte na reference z oblasti lokalizace přístupnosti a ověřte, zda překladatelé pracují v rodném jazyce a umí testovat se screenreadery.

Osvědčeným modelem je kombinace strojového překladu a korektury rodilým mluvčím. Strojový překlad provede prvotní překlad alternativních textů, ARIA popisků a chybových hlášení, zatímco lidský korektor zajistí sémantickou přesnost, kulturní vhodnost a technickou správnost. Tím se šetří náklady i čas, aniž by byla ohrožena kvalita. Dbejte na to, aby korektor znal také směrnice o přístupnosti – samotný jazykový korektor obvykle nestačí.

Při kalkulaci nákladů zohledněte následující položky: překlad prohlášení o přístupnosti a právních textů (často podle počtu slov nebo znaků), lokalizace komponent uživatelského rozhraní včetně alternativních textů a popisků (podle počtu řetězců nebo komponent), technické poradenství pro nastavení jazykových atributů a ARIA struktur a náklady na testování se screenreadery v každém jazyce. Zkušenosti ukazují, že podíl testování činí zhruba 30–40 % celkového rozpočtu.

Častou námitkou je, že lokalizace přístupnosti je příliš drahá. V praxi lze náklady snížit včasným plánováním: pokud jsou alternativní texty a popisky koncipovány vícejazyčně již ve fázi návrhu, odpadá náročné dodatečné úpravy. Také znovupoužitelnost – například identické ikony se stejným alternativním textem ve všech jazycích – snižuje úsilí.

Spolupráce s dodavateli vyžaduje jasnou komunikaci: definujte glosář klíčových pojmů (např. „tlačítko“, „navigační menu“) a stanovte limity délky textů. Používejte systém pro řízení překladů (TMS), který sleduje stav každé komponenty a zaznamenává změny. Provádějte pravidelné recenze, při nichž necháte přeložený obsah otestovat na testovacím systému se screenreaderem.

Závěrem doporučujeme určit u dodavatele stálou kontaktní osobu, která bude dohlížet jak na technické, tak jazykové požadavky. Tím zajistíte, že váš vícejazyčný projekt přístupnosti bude dokončen včas a v rámci rozpočtu.

Úskalí při překladu přístupnosti do 24 jazyků

Lokalizace přístupného obsahu přináší specifická úskalí, která přesahují běžné překladatelské chyby. Častou chybou je doslovný překlad ARIA popisků nebo alternativních textů bez ohledu na sémantiku cílového jazyka. Například anglický popisek „Submit“ může být v němčině příliš dlouhý, což způsobí, že čtečka obrazovky zkrátí sdělení. Místo toho jsou nutné zkratky jako „Senden“ nebo kontextové alternativy. Dalším úskalím jsou kulturní rozdíly u symbolů a ikon: Barevný kód pro „úspěch“ (zelená) nebo „chybu“ (červená) je v mnoha kulturách stejný, ale v některých asijských zemích má červená pozitivní konotaci. Přístupné instrukce odkazující na barvy musí být proto buď doplněny textem, nebo upraveny. Také překlad odkazů „Skip to main content“ není triviální: v němčině vzniká „Zum Hauptinhalt springen“, ale změna délky může narušit rozvržení nebo navigaci klávesnicí. Mnozí také podceňují význam jazykových deklarací v HTML. Není-li jazykové označení správně nastaveno (např. `lang="de"` pro německé stránky), mohou čtečky obrazovky interpretovat obsah chybně a použít nesprávnou jazykovou syntézu. Dalším bodem jsou složená slova v němčině – například „E-Mail-Bestätigung“ – která čtečky obrazovky často správně nepřečtou, protože nerozpoznají dělení slov. Zde pomáhají ARIA atributy jako `aria-label` pro řízení výslovnosti. Při překladu chybových zpráv ve formulářích je třeba dbát na to, aby ID chyb zůstala jednoznačná a nebyla narušena jazykově specifickými úpravami. V praxi se ukazuje, že rodilí mluvčí musí testovat nejen gramatiku, ale také kompatibilitu s čtečkami obrazovky. Užitečným přístupem je otestovat každý přeložený komponent pomocí čtečky obrazovky a porovnat výstup s anglickým referenčním. Tím lze včas odhalit problémy, jako jsou nesprávné přízvuky nebo chybějící alternativní texty. Bez tohoto proaktivního postupu vznikají bariéry, které mohou mít právní důsledky – zejména od června 2025 s Evropským aktem o přístupnosti.

Praktické nástroje a technologie pro vícejazyčné testování přístupnosti

Pro zajištění kvality přístupné lokalizace do 24 jazyků existují specializované nástroje, které přesahují jednoduchý překladatelský software. Klíčovým nástrojem je integrace čteček obrazovky do testovacího workflow: nativní řešení jako NVDA (Windows) nebo VoiceOver (macOS) lze kombinovat s automatizovanými testy. Pro každý cílový jazyk by měl rodilý mluvčí otestovat obsah s příslušnou čtečkou obrazovky, protože jazykové syntézy mají různou kvalitu. Automatizované testovací nástroje jako axe-core, Wave nebo Lighthouse sice odhalí mnoho porušení WCAG, ale jsou závislé na jazyku: kontrolují například, zda je `aria-label` přítomen, nikoli zda je obsah v cílovém jazyce smysluplný. Proto je nezbytná kombinace automatického a manuálního testování. Praktickým přístupem je použití systémů pro správu překladů (TMS) s funkcemi pro přístupnost: moderní TMS umožňují opatřit překladové jednotky metadaty, takže překladatelé vědí, zda jde o alternativní text k obrázku nebo popisek tlačítka. Některé systémy navíc nabízejí náhledy v kontextu, které zobrazí přeložený text přímo v původním rozvržení. Pro testování navigace klávesnicí jsou vhodná rozšíření prohlížeče jako „Accessibility Insights“ od Microsoftu, s nimiž lze testovat pořadí fokusu ve všech jazycích. Dalším užitečným nástrojem jsou „fiktivní obrazovkové výstupy“: pomocí CSS lze zobrazit textové alternativy obrázků a zkontrolovat, zda je překlad smysluplný. Použití jazykových záložních mechanismů v HTML (např. `lang=de` na úrovni textu) lze ověřit pomocí nástrojů jako W3C Validator. V neposlední řadě se doporučuje využití „testovacích laboratoří přístupnosti“ jako služby: některé agentury nabízejí speciálně pro vícejazyčné weby kombinaci automatických skenů a manuálních testů s čtečkami obrazovky až ve 24 jazycích. Volba nástrojů závisí na rozpočtu a velikosti týmu, ale v praxi se osvědčuje kombinace open-source nástrojů jako axe a Poedit (pro překladové soubory) a komerčních platforem jako Transifex nebo Lokalise s pluginy pro přístupnost. Důležité je, aby všichni zúčastnění – překladatelé, vývojáři a testeři – používali stejnou sadu nástrojů, aby se předešlo chybám způsobeným předáváním médií.