Poslepu.cz na novém URL

Od ledna 2014 najdete blog na adrese poslepu.cz.

Zobrazují se příspěvky se štítkemstrukturování obsahu. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemstrukturování obsahu. Zobrazit všechny příspěvky

středa 9. ledna 2013

Otestujte si přístupnost svých PDF pomocí nástroje PDF Accessibility Checker

Pokud vytváříte PDF a chcete si rychle ověřit, zda splňuje technické požadavky na přístupnost, můžete k tomu použít několik nástrojů. Jedním z nich je i PAC - the PDF Accessibility Checker.

Jedná se o freewarový nástroj, vyvíjený a distribuovaný nadací Access for all, který slouží k testování přístupnosti PDF dokumentů a formulářů. Jeho zajímavou funkcí je možnost zobrazení náhledu strukturovaného dokumentu ve webovém prohlížeči. PDF Accessibility Checker v takovém případě ukáže, které tagy (nadpisy, odstavce, atp.) jsou v PDF použity a současně je zobrazí tak, jak by byly interpretovány asistivními technologiemi.

PDF Accessibility Checker nabízí možnost zobrazení zprávy s výsledky testování, obsahující odkazy na nalezené chyby. Po potvrzení odkazu je zobrazeno místo pravděpodobné příčiny chyby přímo ve zdrojovém dokumentu, takže uživatel ví, kde a co by měl opravit.

Co lze pomocí PDF Accessibility Checkeru otestovat?

  • Použití značek pro strukturování obsahu,
  • přítomnost titulku dokumentu,
  • definování jazyka, v němž je dokument napsán,
  • nastavení zabezpečení dokumentu tak, že umožnuje přístup k obsahu i asistivním technologiím,
  • zda je při pohybu tabulátorem zachováno logické pořadí,
  • konzistentní strukturu nadpisů,
  • přítomnost záložek,
  • použití přístupných fontů,
  • zda je obsah uspořádán v logickém pořadí,
  • přítomnost textových alternativ u obrázků,
  • zda jsou tagy a role definovány korektně,
  • dostatečný kontrast mezi barvou textu a pozadí,
  • zda je prázdné místo definováno jen vizuálně, nebo i v kódu.

Další informace o testovaných oblastech včetně jejich detailnějšího popisu včetně odkazů na WCAG 2.0 jsou k dispozici například v souboru PAC Quick Manual (PDF, 1.2 MB).

I přesto, že nástroj testuje pouze technické aspekty přístupnosti, je určitě dobré si s ním PDF, které chceme někomu poslat nebo dát na web, zkontrolovat.

Související odkazy

pátek 21. prosince 2012

Proč bych nerad, aby strukturální HTML5 elementy skončily v propadlišti dějin

K sepsání tohoto příspěvku mě inspiroval skvělý článek Martina Michálka HTML5 strukturální elementy stojí za starou bačkoru. S Martinovým názorem souhlasím, dnes opravdu nemá smysl strukturální HTML5 elementy používat, protože jejich podpora je momentálně nijaká a uživatelům nic nepřináší.

Pokud chceme obsah stránek strukturovat kvůli uživatelům (a přístupnosti), můžeme kromě již snad dostatečně dobře známé techniky viditelných i skrytých nadpisů použít i atribut role z WAI-ARIA. Ten má dostatečnou podporu v prohlížečích i asistivních technologiích a uživatelé tak mohou při jeho použití využívat všech výhod, které jim správně strukturovaná stránka přináší. Tomuto přístupu hraje do karet i to, že WAI-ARIA je dnes součástí HTML5 a lze na ni v případě potřeby odkázat.

Takže to máme vyřešeno a můžeme skončit. Nebo ne? Ne, nemůžeme, protože si myslím, že by strukturování pomocí HTML5 elementů bylo lepší.

V čem vidím výhodu strukturálních HTML5 elementů oproti rolím z WAI-ARIA?

Rozdíl nevidím v technické stránce věci (z hlediska složitosti/jednoduchosti zápisu to vychází +/- stejně), ale spíš v koncepci a v lepším začlenění přístupnosti do tvorby webu.

Při stávajícím řešení přes WAI-ARIA (proti které mimochodem nic nemám a naopak ji propaguji, kudy chodím) je přístupnost vyčleněna nad rámec standardního vývojového cyklu webu. Obvyklá praxe je stále taková, že kodér běžnými postupy vytvoří šablony a teprve pak se stará o přístupnost. Pokud se tedy o ni vůbec stará. A když ano, tak je přístupnost v tomto případě často brána jako "vícepráce", kvůli které si kodér navíc ještě musí doplnit vzdělání a nastudovat další specifikaci. Což jsou věci, které dle mého názoru chuť dělat něco pro přístupnost dost výrazně snižují.

Pokud by se ale místo rolí z WAI-ARIA ujaly HTML5 elementy a měly by dostatečnou podporu na straně prohlížečů i asistivních technologií, myslím, že by to pro uživatele, přístupnost i kodéry bylo lepší. Kodéři by totiž tyto elementy při psaní kódu používali naprosto samozřejmě a nezávisle na tom, jestli pro přístupnost něco chtějí nebo nechtějí dělat. Podobně, jako dnes zcela běžně používají jiné HTML elementy. Přístupnost by se tak stala součástí jejich běžných pracovních postupů bez jakékoliv vícepráce či vícenákladů na vzdělávání a nebyla by vyčleněna mimo běžné pracovní postupy. A přesně to je důvod, proč bych byl osobně raději, kdyby se spíše než role z WAI-ARIA ujaly HTML5 elementy.

Jsem si samozřejmě vědom toho, že ani dnes všichni nepoužívají například pro nadpisy elementy h1h6, ale tvoří si místo nich vlastní konstrukce typu <div class="nadpis1">. I tak mi ale přijde snazší v takovém případě dotyčnému vysvětlit, že pro nadpisy máme přímo určené elementy, než ho odkazovat na nastudování si další specifikace.

Nebo se mýlím a je jedno, jestli se kodér učí WAI-ARIA nebo HTML5 elementy? A ty jsou tedy zbytečné, když už je tady WAI-ARIA?

Ale ať už to ve finále dopadne tak nebo onak, nejdůležitější je, že budeme mít nástroj přímo určený pro definování sémantiky jednotlivých oblastí stránky a nebudeme pro to muset používat nějaké workaroundy jako nyní.

Související odkazy