2026-02-11 · Redakce Baduno · 6 blog.readMin · Blog a znalosti
Zákon o posílení přístupnosti: Co musí weby nyní splňovat
Od června 2025 platí BFSG – a spadá pod něj mnoho firemních webů. Povinnosti, srozumitelně seřazené, bez paniky.
Kdo je dotčen
Zákon zahrnuje elektronické služby orientované na spotřebitele – včetně online obchodů a mnoha rezervačních a kontaktních tras. Čisté B2B nabídky a mikropodniky jsou částečně vyjmuty; zařazení by mělo být v případě pochybností právně prověřeno.
Co se požaduje
Prakticky se požadavky řídí WCAG: vnímatelnost (kontrasty, alternativní texty), ovladatelnost (klávesnice, fokus), srozumitelnost (jasný jazyk, chybová hlášení) a robustnost (čisté HTML pro pomocné technologie).

Dobrá zpráva
Přístupné weby jsou téměř vždy také rychlejší, lépe strukturované a přátelštější k vyhledávačům. Povinnost přispívá ke kvalitě, která se stejně vyplatí – a otevírá velkou, často ignorovanou skupinu uživatelů.
Pragmaticky začít
Nejprve otestovat (automatizovaně plus ručně), poté prioritizovat podle dopadu: kontrasty, alternativní texty, formuláře a ovládání klávesnicí odstraní většinu každodenních bariér. Prohlášení o přístupnosti dokumentuje stav poctivě.
Hreflang a přístupnost: Často přehlížená souhra
Vícejazyčné weby čelí další výzvě: Požadavky na přístupnost platí pro každou jazykovou verzi samostatně. Atribut hreflang, který vyhledávačům označuje jazykové a regionální přiřazení, musí být implementován tak, aby čtečky obrazovky a další asistenční technologie správně rozpoznaly přepínání jazyků. Pokud je hreflang nastaven špatně nebo chybí, může to značně ztížit navigaci pro zrakově postižené uživatele – například když se stránka náhle načte v jiném jazyce, aniž by to uživatel očekával. Prakticky to znamená: Každá jazyková varianta musí nabízet nejen překlady, ale také plně přístupné struktury. To zahrnuje správné deklarace jazyka v HTML (atribut lang) a konzistentní alternativní texty ve všech jazycích. Konfiguraci hreflang byste proto měli od začátku zahrnout do testování přístupnosti.
Automatizované testovací nástroje: silné stránky a omezení
Nástroje jako axe, Wave nebo Lighthouse dokážou automaticky odhalit mnoho technických bariér, např. chybějící alternativní texty, nedostatečný kontrast nebo chybné atributy ARIA. Nenahrazují však manuální kontrolu, protože srozumitelnost textů, logické pořadí obsahu nebo použitelnost formulářů s asistenčními technologiemi lze zachytit pouze pomocí skutečných uživatelských testů. Automatizované kontroly poskytují první rychlou analýzu chyb a jsou vhodné pro průběžné testování v rámci CI/CD pipeline. Výsledky však musí vždy vyhodnotit člověk, protože nástroje produkují jak falešně pozitivní, tak falešně negativní hlášení. Pragmatický pracovní postup: nejprve automatizované testy, poté manuální vzorek s odečítačem obrazovky a klávesnicí a nakonec závěrečný test použitelnosti s postiženými uživateli.
Právní důsledky a přechodná období
Zákon BFSG stanovuje pokuty a varování, pokud webové stránky nesplňují požadavky. Pro produkty, které byly uvedeny do provozu před 28. červnem 2025, existuje přechodné období do 28. června 2030 – ale pouze pro ty, které byly před tímto datem již bezbariérové nebo u kterých bylo prokazatelně na bezbariérovosti pracováno. Kdo spustí nový web nebo redesign po 28. červnu 2025, musí okamžitě splňovat všechny požadavky. Pozor: Zákon se vztahuje na veškerý nově vzniklý obsah; starší obsah (např. archivní stránky) může být za určitých okolností náročnější na úpravu. V praxi se doporučuje písemná dokumentace pokroku, aby bylo možné v případě námitek prokázat, že bezbariérovost zavádíte postupně. Prohlášení o přístupnosti na webu je stejně povinné.
Od června 2025 platí BFSG – a spadá pod něj mnoho firemních webů. Povinnosti, srozumitelně seřazené, bez paniky.
Bezbariérovost jako součást mezinárodní SEO strategie
Bezbariérové webové stránky splňují nejen zákonné požadavky, ale také mnoho kritérií, která vyhledávače hodnotí pozitivně: sémantická struktura HTML, jasné hierarchie nadpisů, výstižné alternativní texty a rychlé načítání. Tyto faktory jsou pro SEO relevantní ve všech jazycích. Kromě toho mohou vyhledávače explicitně penalizovat bariéry, jako jsou neoznačená tlačítka nebo chybějící nadpisy, protože ztěžují indexaci. Kdo zpřístupní svůj web všem uživatelům, automaticky zlepšuje uživatelský komfort a tím nepřímo i signály pro hodnocení. Zejména u vícejazyčných webů se vyplatí integrovat bezbariérovost od začátku do lokalizačních workflowů – například pomocí kontrolních seznamů pro překladatele k vytváření bezbariérových alternativních textů.
Testování s reálnými uživateli: Proč je nezbytné
Automatizované nástroje odhalí jen část bariér. Teprve test s lidmi, kteří jsou skutečně odkázáni na asistenční technologie, ukáže, zda vaše webová stránka funguje v běžném provozu. Nevidomí uživatelé používají čtečky obrazovky jinak, než simulují automatizované kontroly; neslyšící uživatelé mají jiné požadavky na videa ve znakovém jazyce; osoby s motorickým postižením navigují bez myši. Strukturovaný test se třemi až pěti účastníky z různých skupin postižení odhalí problémy, které žádný nástroj nenajde – například nelogické pořadí fokusu, chybějící kontextové informace v ARIA popiscích nebo nesrozumitelné chybové zprávy. Tyto testy ideálně naplánujte do fáze vývoje, ne až těsně před spuštěním. Výsledky zdokumentujte v prohlášení o přístupnosti jako součást zajištění kvality. Pamatujte: Testy musí být provedeny pro každou jazykovou verzi zvlášť, protože překlady mohou vytvořit nové bariéry – například pokud alternativní texty neodpovídají cílovému jazyku nebo jsou formulářové pokyny gramaticky nesprávné.
Systémy pro správu obsahu a přístupnost: Úskalí pluginů
Mnoho webových stránek je postaveno na CMS jako WordPress, TYPO3 nebo Drupal. Tyto systémy nabízejí pluginy nebo rozšíření, která slibují přístupnost – například nástroje pro překryv, které dodatečně upravují kontrasty nebo vkládají atributy ARIA. Taková řešení jsou většinou nedostatečná a mohou dokonce vytvářet nové bariéry tím, že přepisují stávající sémantické struktury. Místo toho byste měli přístupnost implementovat přímo do šablony nebo motivu: čistá struktura HTML, správné hierarchie nadpisů, nativní prvky formulářů. Při výběru pluginů dbejte na to, aby byly v souladu s WCAG a pravidelně aktualizované. Dalším problémem je, že mnoho redaktorů vkládá obsah pomocí vizuálního editoru a ignoruje alternativní texty nebo formáty nadpisů. Školte své redaktory nebo používejte pracovní postupy, které vynucují přístupné vstupy – například povinná pole pro alternativní texty u obrázků. Také volba šablony CMS ovlivňuje přístupnost: testujte každou šablonu před použitím automatizovaným nástrojem a manuálním vzorkem.
Testování s lidmi s postižením: Nezbytný krok
Automatizované nástroje a manuální kontrolní seznamy odhalí mnoho technických bariér, ale nenahrazují testování s reálnými uživateli. Lidé s postižením používají různé asistenční technologie – screenreadery jako JAWS, NVDA nebo VoiceOver, zvětšovací software, hlasové ovládání nebo speciální klávesnice. Každá z těchto kombinací se chová jinak, takže i formálně vyhovující stránka může být pro nevidomého uživatele nepoužitelná. Proto plánujte pravidelné uživatelské testy s heterogenní skupinou: zrakově postižené, osoby s motorickým omezením a kognitivním postižením. Nechte je provádět definované úkoly na vašem webu, například nákup produktu nebo vyplnění kontaktního formuláře. Pečlivě dokumentujte vzniklé problémy: kde navigace vázne, která hlášení jsou nesrozumitelná, které prvky nejsou dosažitelné? Poznatky z těchto testů mají zlatou hodnotu, protože odhalují nejen bariéry, ale také potenciál optimalizace pro všechny uživatele. Dbejte na to, abyste testy prováděli pro každou jazykovou verzi zvlášť, protože překlady a souvětí ovlivňují srozumitelnost odlišně. Začleňte výsledky do svého kontinuálního procesu zlepšování – přístupnost není jednorázový projekt, ale trvalý úkol.
Zakotvení přístupnosti v systému pro správu obsahu
Mnoho nedostatků v přístupnosti vzniká již při tvorbě obsahu: redaktoři zapomínají na alternativní texty, nepoužívají hierarchické nadpisy nebo odkazují na nic neříkající slova jako „klikněte zde“. Abyste tomu předešli, měli byste přístupnost zakotvit přímo ve vašem systému pro správu obsahu (CMS). Školte své redakční týmy v základech WCAG – a to pro každý jazykový tým zvlášť, aby požadavky nebyly podkopány kulturními rozdíly v tvorbě textu. Využívejte pluginy CMS nebo rozšíření, která při vkládání obrázků vynucují povinná pole pro alternativní text nebo vizuálně zobrazují hierarchii nadpisů. Začleňte automatizované kontroly do schvalovacího workflow, které před publikováním upozorní na časté chyby, jako jsou chybějící popisky nebo příliš nízký kontrast. Dále dbejte na to, aby vámi používané šablony a motivy CMS byly již přístupné – například s korektními ARIA landmarks, správou fokusu klávesnice a sémantickým HTML. Pro vícejazyčné weby je zásadní, aby CMS podporoval lokalizaci přístupných struktur, například automatickým správným nastavením atributů hreflang a deklarací jazyka. Dobře integrovaný proces přístupnosti do CMS snižuje náklady na úpravy a zajišťuje konzistentní kvalitu napříč všemi jazykovými verzemi.
blog.faqT
Co se stane, pokud moje webová stránka poruší BFSG?
Při porušení BFSG mohou být uloženy pokuty. Dále je třeba počítat s varováními ze strany konkurentů nebo spotřebitelských organizací. Výše pokut se odvíjí od závažnosti porušení a může dosahovat až 100 000 eur. Prohlášení o přístupnosti s rozsahem a stavem opatření je povinné a slouží jako doklad.
Musí být překlady mé webové stránky rovněž přístupné?
Ano, každá jazyková verze musí samostatně splňovat požadavky na přístupnost. To zahrnuje správné atributy jazyka (lang), přeložené alternativní texty a navigaci s nízkou bariérovostí. Atribut hreflang musí být nastaven tak, aby vyhledávače a asistenční technologie správně rozpoznávaly přepínání jazyků. I překladatelské agentury by proto měly dbát na přístupnost svých dodávek.