Názory k článku
Jak budou vypadat pravidla přístupného webu pro veřejnou správu?

Bravo! Je vidět, že pravidla jsou "z pera" lidí, kteří věci rozumí. A možná až moc. Nevím, jestli to byl záměr nebo výsledek "bouřlivé diskuze", ale některé věci jsou dost jinotajně ukryty. Myslím třeba bod, kde se v podstatě mluví o povinnosti podtrhávat odkazy (Odkazy jsou odlišeny od ostatního textu, a to nikoli pouze barvou).
Jednoznačně souhlasím s tím, co je v návrhu uvedeno. Mnoho autorů webů z toho radost mít nebude. A mnoho milionů, které byly vyhozeny na různé gov-portály, bude moci být podrobeno ještě přísnější kritice, než byla ta z úst pár poblouzněných odborníků na webdesign.
Doufám, že odborně dobře zpracovaná vyhláška nebude přemleta (zprzněna) průchodem skrze mašinerii naší státní správy.

No a teď jen zajistit vymahatelnost tohoto návrhu. Aby to nedopadlo jako v jiných podobných případech, sice je zákon (vyhláška, nařízení apod.) porušen, ale žádné sankce z toho neplynou, takže se každý vykašle na to to dodržovat.

Z návrhu novely zákona o ISVS vyplývá, že za nepřístupný web je možné udělit pokutu až 1 milión korun.

No jo Davide, ale to je problém. Stát ukládá pokutu státu. To je jako by si řidiči sami udělovali pokuty. Ty peníze by bylo lepší investovat do školení tvůrců, přesvědčování výše postavených úředníků atd.

Nevím, jestli to byl záměr nebo výsledek "bouřlivé diskuze", ale některé věci jsou dost jinotajně ukryty. Myslím třeba bod, kde se v podstatě mluví o povinnosti podtrhávat odkazy (Odkazy jsou odlišeny od ostatního textu, a to nikoli pouze barvou).

Ne, u tohoto pravidla panovala naprostá shoda. A když už mluvíte o těch jinotajích, budu mít pro vás jednu malou hádanku. I kdybych odstranil toto citované pravidlo, stále by byly pouze jinak barevné odkazy proti pravidlům. Najdete to pravidlo, které to ještě řeší? :-)

To, že jsem zvolil příklad s odkazy byla náhoda. Nechtěl jsem tohle (ani jiná) pravidla. Mě se ten návrh opravdu líbí. Hodně bude záviset na jejich doplnění právě o zmíněné techniky, podrobné výklady atd.

Zamezení odlišení odkazů pouze barvou je sice podchyceno i jiným pravidlem, ale pokud odkazy odliším třeba boldem a okolní neodkazový text budu libovolně podtrhávat, tak jsem se proti pravidlům neprovinil :-).
Ale je to jediná věc, která mne zarazila - vím, že se někdo někde zmiňoval, že v pravidlech bude požadavek na nepodtrhávání textů, které nejsou odkazem - uvažovalo-li se o tom, proč takové pravidlo nakonec není?
Jinak pěkné, dobře vybrané.
Nevíte, jestli se náhodou neuvažuje o tom, že by se rozšířilo spektrum organizací, na jejichž weby by se vyhláška vztahovala? Co další organizace, financované státem, u nichž je přístupnost také důležitá (nemocnice, vysoké školy...)?

Protože mě ostatní přehlasovali. :o)

Ne vážně. Souhlasil jsem nakonec s kolegy i s požadavkem ministerstva, abychom se omezili opravdu jen na mminimum pravidel zajišťujících PŘÍSTUPNOST k informacím. Během závěrečného tříkolového rubání bylo několik pravdidel zmírněno a několik vypadlo zcela. Pravidlo "Každý podtržený text je odkazem" bylo mezi nimi - nakonec jsem (sám rád) musel uznat, že v jeho případě jde spíš o použitelnost: stránka, kde je náhodná polovina slov podtržena a odkazy jsou odlišeny ztučněním, je jistě hodně špatně použitelná (usability), ale přístupná přece jen je (accessibility).

Spoustu věcí můžeme doporučit (a snad to i uděláme) - ale tato pravidla musejí být závazná a vymahatelná. Byla-li by přepříliš přísná, jejich zavedení do praxe by bylo složitější.

Takze kvuli "pristupnosti" budou weby typograficky paskvil?

Mnoho tvurcu webu? Opravil bych to na mnoho tvurcu webu statni spravy ;-).

"V metaznačkách je uvedena použitá znaková sada dokumentu."

Znaková sada od HTML 4.0 a výše (včetně XHTML) je vždy Unicode/ISO 10646. Lepší by podle mne bylo psát:

"V metaznačkách je uvedeno použité kódování dokumentu."

Jinak držím palce při spolupráci s MI.

Jelikož se tomu kódování říká "znaková sada", tedy v angličtině "charset", použili jsme právě tenhle termín. A stejně jednak každý ví, oč jde, jednal u každého bodu bude ještě podrobnější "prováděcí" popis.

Nechci vypadat jako hnidopich, ale ohledně znakových sad a kódování se mezi lidmi šíří tolik bludů, že nejsem zrovna nadšený z toho, když závazný dokument bude obsahovat špatný a zavádějící termín.

Kódování není v angličtině "charset". "charset" se jmenuje parametr HTTP hlavičky, který označuje kódování. Název parametru je zavádějící, protože pochazí z MIME, které při svém vzniku počítalo s více znakovými sadami, ne s jednou znakovou sadou Unicode a jejími několika kódování. Viz. citace z HTML 4.01:

The most straightforward way for a server to inform the user agent about the character encoding of the document is to use the "charset" parameter of the "Content-Type" header field of the HTTP protocol ([RFC2616], sections 3.4 and 14.17)

Myslím, že by byla škoda, aby jinak velmi užitečný dokument, za jehož přípravou je mnoho práce, zrovna toto kazilo.

Že by měl web obsahovat korektní specifikaci kódování, pod to se klidně podepíšu. Ale vynucovat, že to musí být provedeno meta elementem, s tím souhlasit nemohu. Meta element http-equiv slouží jen jako berlička pro případ, že příslušnou hodnotu nelze specifikovat přímo v HTTP hlavičce. Je-li možné nastavit HTTP hlavičky, měla by tomu řešení být dána přednost. Specifikace v meta elementu přináší spíš problémy, protože dokument může být v různých situacích překódován (např. v závislosti na Accept-Charset a meta element takové překódování značně komplikuje (je ho nutné najít, přeparsovat a opravit).

Charset v meta má ale i jednu velkou výhodu - umožňuje určit kódování i u stránky, která je uložena na disk.

Který ze současných browserů nepodporuje utf-8?

V jakých praktických situacích by bylo třeba řešit accept-charset?

V tom případě by ho tam měl doplnit ten, kdo stránku na disk ukládá. Jen on totiž ví, v jakém kódování ji tam ukládá. Navíc si představte modelový příklad: mějme dvě stránky řekněme ve windows-1250. Stránka A má toto kódování uvedeno v HTTP hlavičce a nemá http-equiv. Stránka B má v HTTP hlavičce uvedeno iso-8859-2 a v http-equiv má windows-1250. Asi se shodneme, že stránka A je v pořádku a stránka B ne; jenže podle pravidel z článku je to přesně naopak. Ten příklad se stránkou B není tak umělý, jak by se zdálo, s takovými stránkami se setkávám poměrně často; právě proto, že je autorům neustále vtloukáno do hlavy používání http-equiv, aniž by se dozvěděli, co to vlastně je a jak to funguje (nebo nefunguje).

Ze současných prohlížečů podporují UTF-8 asi všechny. Ale u těch starších by stránka v UTF-8 byla natolik nepoužitelná, že bych si ani dnes nedovolil poslat stránku v UTF-8 nikomu, kdo podporu tohoto kódování nedeklaruje v hlavičce dotazu.

Myslím, že k tomuto problému je potřeba přistoupit pragmaticky. Kódování v meta tagu je užitečné pro ukládání na disk, proto je vhodné ho ve stránce mít. Kódování určené v HTTP hlavičce má přednost před kódováním z meta tagu (viz specifikace HTML 4.01). Aby nedocházelo k špatné interpretaci kódování stránky je proto vhodné, aby kódování zasílané v HTTP hlavičce bylo stejné jako v meta tagu. Pokud kódování nesouhlasí, je to způsobeno špatnou konfigurací WWW serveru nebo jeho modulu pro překódování, a to je to místo, které by se mělo opravit.

Souhlasím s tebou Michale, že by aplikace při ukládání stránky měla doplnit informaci o kódování. Ale kolik prohlížečů to dělá? Překonfigurovat WWW server mi přijde nepoměrně jednodušší, než si doprogramovávat chybějící funkci prohlížeče :-D

Historicky skutečně nebylo moc moudré vkládat informaci o kódování do , protože první moduly pro překódování češtiny měnily pouze HTTP hlavičky, ne obsah HTML stránky. Podle mé zkušenosti se tyto moduly teď už moc nepoužívají, a novější alternativy přepisují i kódování v , aby identifikace kódování souhlasila.

Kvůli ukládání stránek na disk, CD-ROM apod. je skutečně potřeba mít kódování identifikované přímo uvnitř dokumentu. Ostatně tímto směrem se vydalo i XML, které si také nese informaci o použitém kódování.

Kromě pragmatických důvodů se můžeme nechat inspirovat W3C, které se rovněž přiklání k názoru, že by kódování mělo být součástí dokumentu:

http://www.w3.org/TR/2004/WD-i18n-html-tech-char-20040509/#IDAK1FO

Taky uvedu jeden odkaz. Na WaSP v článku Webby Awards Validation Woes je doporučení přesně opačné:

If you have the appropriate encoding on the server, please do not add it to your document via the meta element.

Ta citace je trochu vytržená z kontextu:

Encoding mismatches. This problem is popping up more and more now that the W3C's validator has been upgraded. What this means is that the encoding on the server is conflicting with the encoding in the document. If you have the appropriate encoding on the server, please do not add it to your document via the meta element.

Doporučení podle mne vychází z předpokladu, že HTTP hlavičky a dokument identifikují rozdílná kódování (jedno z nich je pak logicky chybné). Pokud se však oba údaje shodují, nevidím v čem by měl být problém. Jen se zkrátka uplatnila mezi sexuology oblíbená metoda "pásek a kšandy".

Neřekl bych, že je to vytržené z kontextu. I v tom kontextu vyznívá IMHO takto: než riskovat, že v HTTP hlavičce bude něco jiného než v meta elementu, je lepší používat jen jedno. Svým způsobem tu hraje roli i argument o uložení do souboru: pokud v HTTP hlavičce bude kódování správné a v meta elementu chybné, v prohlížeči to nepoznám. A je určitě lepší, pokud v dokumentu nebude nic, než pokud tam bude kódování, které neodpovídá skutečnosti. Proto autor doporučuje používat jen jednu variantu: buď HTTP hlavičku (přednostně) nebo meta element (pokud to nejde).

Na druhou stranu je nutno vzít v úvahu, že jak toto doporučení, tak to od W3C, psali lidé, kteří se nemuseli vyrovnávat se schizmatem ISO 8859-2 vs. Windows 1250.

Myslím, že weby státní správy se také nemusejí zabývat problémem osmibitového kódování, protože stále platí ČSN ISO/IEC 8859-2. :-)

Uvedena norma se jmenuje "Informační technologie - Jedním 8-bitovým bytem kódované soubory grafických znaků - Část 2: Latinská abeceda č. 2".

Já myslel, že u nás je ještě pořád za oficiální považována KOI8CS... :-)

Ukladat informaci o kodovani do dokumentu samotneho je IMHO naprosto nekonsistentni, jelikoz na to, abyste META tag objevili, uz musite vedet (alespon priblizne), v jakem kodovani dokument je.

"Slepice, nebo vejce?", rekl by na to klasik.

Kodovani tedy musi uvedeno externe. Pravda, do META tagu ho take muzeme pripsat, ale pokud spravne rozumim specifikaci HTTP, pak ma proxy pravo text prekodovavat a onu externi informaci aktualizovat, aniz by ovsem mela povinnost rozumet vnitrku dokumentu.

Tento požadavek má hlavní důvod v tom, aby byla stránka čitelná po uložení na jiné médium, než je web. Tedy např. po uložení lokální disk, kdy se všechny informace z http hlavičky ztratí.

Přece v Lynxu se tam přidá kromě kodu i BASE. Mám pocit, že i správci WWW-stránek znají jenom MSIE.
Ale co opravdu chybí v doporučeních a je potřebné říci, jsou západoevropské znaky na české stránce - zvláště když jsme už v Evropské Unii. (Třeba přeškrtnuté o )
Může se připsat třeba do kodování Windows-1250 znak ø resp. ø anebo k tomu musí být vše v UTF-8 ?
Je vůbec znám způsob transkripce přeškrtnutého o do češtiny? Kdysi o tom něco psali v oběžníku UVISu, ale to brali všichni tak vážně, jako když USIS psal, že stránky mají být v ISO-8859-2. Hlavně aby tak také neskončila současná doporučení. To, že zcela ignorují předchozí výstupy - produkované dokonce pořád ve stejném baráku - to samo už je k tomu asi opět předurčuje.
P.S.
Jinak jsem se chtěl ještě zeptat ohledně terminologického problému se znakovou sadou, zda někdo umí na WWW-server umístit znak, který by nebyl někde definován v Unicodu?

Problém je v tom, co označuje pojem znak. :-) Samozřejmě, že lze v datech uložit znak, který není v žádné standardní znakové sadě.

No, tak to sesumirujme.

1. "Do dokumentu" je dobre kvuli ukladani na disk, zo by mohl delat i ten, kdo stranku uklada, ale aktualne to nikdo moc nedela
2. "Do hlavicky" je dobre protoze v tele to komplikuje prekodovavani, kdy se musi sahat "do dokumentu" coz samo o sobe pusobi komplikace a navic muze az vyustit ve zmenu jeho delky coz vyrazne komplikuje situaci (zejmena zadost o ne celou stranku, ale jen cast); krome toho, parsing dokumentu a tedy i teto informace uz podleha informaci o pouzitem kodovani

A ted rozbor. Mozna reseni -

1. ukladace zacnou informaci z hlavicky ukladat (nepravdepodobne)
2. stranky budou jen v UTF, ISO-8859-* nebo ASCII, ktere uz vetsina modernich prohlizecu zvlada cimz zmizi potreba prekodovavani cimz prestane vadit TAG v hlavicce
3. stranky budou jen v UTF cimz zmizi jak potreba prekodovavat tak charset oznacovat, cimz problem jestli tam nebo onam zcela mizi

Osobne bych byl nejradeji pro [3], ale zda se, ze [2] je prijatelna kompromisni volba - pokud budou stranky jen ve vyjmenovanych kodovanich lze jakekoliv prekodovavani "on-demand" hodit pres palubu ...

Takze, pokud uzname realitu sveta (ze kodovani se pri ukladani na disk typicky ztraci) pak za dodrzeni podminky, ze stranky budou v kodovani, ktere je "rozumne" zvolene reseni patrne dobrym kompromisem ...

Opravdu jsem překvapen, že v oné ministerské komisi sedí lidé, kteří tomu rozumějí a nikoliv nějací úřední šimlové...

Jen tak dál.

Jediná věc, se kterou bych si dovolil nesouhlasit je de facto schválení rámů, ale jinak bych to vše podepsal bez sebemenších námitek.

Jsem zvědav, jak se to bude dodržovat v praxi ;)

Rámové struktury, které jsou vytvořeny podle pravidel zmíněných ve článku, vůbec přístupnosti nebrání. Někdy ji dokonce výrazně usnadňují například zrakově postiženým. Sám jsem si před několika lety zkusil navigaci v rámech na hlasovém výstupu a byl jsem skutečně zaskočen, jak je to příjemné.

Kazda stranka (krome uvodni strany) obsahuje odkaz na vyssí uroven v hierarchii webu a odkaz na uvodni stranu

Jak je to v pripade ramcu (framu), kdy je menu v jednom a text v druhem ramci, musi byt odkaz na uvodni stranu i v textu, nebo staci ten v menu? Mysli se strankou 1 soubor nebo zobrazeny obsah obrazovky?

Ano, právě v těch framech je to velmi podstatné. Kdo vám zaručí, že uživatel kteroukoli stránku webu vidí uvnitř rámové struktury? Navíc tady jde o pravidla přístupnosti, tedy často o používání stránek zrakově postiženými uživateli - hlasové výstupy a braillské řádky často s žádnými framy nepracují.

A není právě toto důvod pro úplný zákaz rámců ve státní správě?

Hlasové výstupy a braillské řádky nejsou prohlížeče, jsou to jen výstupy, jako třeba tiskárna nebo monitor. Webovou stránku načte prohlížeč (například MSIE) a do těchto výstupních zařízení ji předává nějaký modul pro zpřístupnění textových elementů (třeba Microsoft Agent) většinou za použití dalšího mezistupně, kterému se říká screen-reader (čtečka obrazovky). Čtečka obrazovky obvykle zajišťuje další funkce (osa dokumentu podle nadpisů, čtení pouze odkazů, čtení atributů title...). Štečka nebývá jednoúčelová -- stejným programem ovládáte Word, Outlook i Explorer (a že zrakově postižení opravdu používají obyčejné programy).

Takže braillský řádek ani hlasový výstup nemusí podporovat rámy, musí je jakýmkoli způsobem podporovat prohlížeč. Rámy prostě přístupnosti nevadí. A je milé, že tenhle předpis nezasahuje jinam než právě do přístupnosti (například, že se jím neupravuje minimální mzda nebo spotřební daň na benzín, jak je u nás zvykem).

Eto vsjo.

Ale samozřejmě, že přístupnosti rámy vadí. Beru Váš argument, že "čtečky" stránek jako takové nejsou prohlížeči v pravém smyslu, ale jak sám mimoděk přiznáváte, jsou i takové prohlížeče, které rámy nepodporují.

A dovolím si tvrdit, že při debatě o přístupnosti by neměli být bráni v potaz jen lidé zrakově hendikepovaní, ale třeba i uživatelé zastaralých (linux)/moderních (mobil) technologií, obzvláště pokud tomu nic nebrání.

Asi nemá smysl dělat speciální "grafiku" pro mobilní telefon, ale proč by neměl být přístupný obsah, jen proto, že webdesigner používá zastaralou technologii (rámy).

Navíc si nedokážu představit web státní správy, který by nebyl generován pomocí php/asp nebo podobným jazykem na straně serveru a tudíž odpadá jakýkoliv problém s vkládáním "opakující se" navigace.

Nemám k dispozici žádný výzkum, ale troufl bych si odhadnout, že pokud tomu tak není teď, velmi brzy přijde doba, kdy počet uživatelů prohlížečů bez rámů vysoce převýší počet slabozrakých/nevidomých uživatelů. Tak jako by neměl web státní správy ignorovat skupinu druhou, proč by měl ignorovat skupinu první, když pro to není žádný důvod.

Nebo nějaký důvod, proč používat rámy existuje?

Co treba web obecniho uradu Dolnich Kotehulek? To je take statni sprava a pochybuji, ze ten web pobezi na ASP/PHP ;-)

Presne proto jsem se ptal, jeden takovy web spravuji, a je uplne zbytecne ho delat v php/asp, jelikoz ma minimum opakujicich se informaci, ktere by se daly smysluplne nacitat z databaze (bylo by to mnohem slozitejsi nez je napsat primo v html) a ramce jsou idealnim prostredkem pro zobrazeni navigace. K tem obcim: opravdu dle zakona o informacich je povinna kazda statni instituce (skola, obec) $poskytovat informace verejne pristupnym mediem (napr. internet)$ - tot formulace ze zakona, tim mediem by teoreticky mohl byt i telefon. A jak jiste vite, vytvoreni webu se dnes pohybuje od 30 tis nahoru a ne kazda obec na to ty prachy muze dat (mnohde ani moc netusi co to internet je a k cemu se da pouzit a nemusi to byt ani smysluplne, jelikoz kdo by se s tim delal pro 2 pristupy mesicne)

I na takovémhle webu by se mi asi líbilo, kdyby každá jeho stránka obsahovala na konci textové odkazy alespoň na základní úrovně navigace (pravidla požadují jen titulní stranu) a na začátku strany by se hodila navigační nit.

K tem obcim: opravdu dle zakona o informacich je povinna kazda statni instituce (skola, obec) $poskytovat informace verejne pristupnym mediem (napr. internet)$ - tot formulace ze zakona, tim mediem by teoreticky mohl byt i telefon.

Podívejte se na celý článek o té novele. Jsou zde zmíněné všechny ty klíčové parametry. Např. škol se tento zákon vůbec netýká, ale obcí už ano.

Do PHP nebbo ASP to musíte přece předělat proto, aby stránky Dolních Kotěhůlek běžely pěkně pomalu a vytěžovaly dostatečně přenosovou linku.
Jinak se k pravým profesionálům nepřiblížíte. Schválně, který profesionál vkládá přes PHP třeba jen stejné záhlaví (cokoliv změní jednou za několi měsíců), a připsal do http-hlavičky informace pro cachování?
(Ono mezi námi stačí, když někteří zde zasvěceně diskutující odborníci už měsíce přesměrovávají stále stejně server na jiný přes 302 - protože 301 nevědí jak v PHP-čku napsat. - Jen tak na okraj, o informacích pro cacheování asi určitě na komisi nikdo nehovořil, protože o tom se v HTML-příručkách pro začátečníky obvykle nepíše, Nebo se snad pletu?)

Jen tak na okraj, o informacích pro cacheování asi určitě na komisi nikdo nehovořil, protože o tom se v HTML-příručkách pro začátečníky obvykle nepíše, Nebo se snad pletu?

A můžu se zeptat na důvod, který vás vede k tomu, že si myslíte, že bychom o cacheování v souvislosti s přístupností mluvit měli? Já zde totiž žádnou souvislost nevidím.

Přece aby si pokaždé WWW-klient nestahoval stránky Dolních Kotěhůlek, protože je má již týden v cachi a stránky správce serveru aktualizuje vždy 10. v sudém měsíci.
To přece souvisí s přístupností při zbytečně zatěžované (jedné) lince pro celé Pošumaví, po níž se pak přenos skutečně aktuálních věcí nezvládne.
Ale já přece znám naše dobře "profesionály". Takovéto přízemní problémy přece náleží amatérům (s pomalou linkou) z Pošumaví (jak dokazuje i vaše otázka).

To přece souvisí s přístupností při zbytečně zatěžované (jedné) lince pro celé Pošumaví, po níž se pak přenos skutečně aktuálních věcí nezvládne.

Obávám se, že se mýlíte. Vámi zmiňovaná vysoká datová náročnost stejně jako desítky dalších pravidel použitelnosti s ryzí přístupností pro hendikepované uživatele nemají nic společného. Ale asi Vás nepřesvědčím, ale co naplat.

Já ten handicap mám, protože nemám dostatečně rychlou linku.
Problém je někde úplně jinde! WWW-stránky nelze oddělit od serveru a jeho komunikačních schopností.
Sejde-li se tedy několik odborníků, kteří se nezabývají http-protokolem, tak nemohou z hlediska přístupnosti vypracovat nic jiného než model pro HTML-stránky získávané pomocí file:/// Tedy pokračování opět analogických koncepčních chyb, jaké byly v SIS, kde se opisovaly standardy RFC v domnění, že se tak "samy" propojí informační systémy například finančích úřadů s úřady katastrálními.
Co je ale zásadně špatně, že takováto doporučení budou jen "otravovat" mnohé správce WWW-serverů, ale jejich problémy jim to vyřešit nepomůže. K tomu mají také být standardy, doporučení, návody, aby "méně znalí z Pošumaví" v nich mohli najít i návod. - Ale ono je to vždy naopak. Složité věci si musí každý vyřešit sám, ale na méně podstatné problémy máme různá doporučení. Proto to u nás ...atd.

Záleží na úhlu pohledu. Váš čtyřlístek se totiž ujal předpisu z pohledu přístupnosti pro postižené. digital divide je problém obecnější. Zahrnuje i bariéry způsobené odlišným vybavením uživatele (třeba problém s rámy an mobilních telefonech), se vzděláním, jazykem a také s možnostmi připojení (tedy to ukládání do vyrovnávací paměti).

Když ale podtrhnete, že důraz je kladen na postižení, tak ta pravidla sedí.

Váš čtyřlístek se totiž ujal předpisu z pohledu přístupnosti pro postižené. digital divide je problém obecnější.

Martine, ale nezapomeň, že jsme se museli vejít do znění toho návrhu novely zákona, pro který připravujeme prováděcí předpis. Nemůžeme jít dál, než nám ta novela umožňuje. A ta novela přístupnost definuje pomerně jasně ...

Však neříkám, že to je špatně. :-)

no, tak to si trosku protirecite, protoze pokud se jedna o stranky maleho rozsahu, ktere vsak dodrzuji zminene optimum do 100k, tak ty rozhodne nezatizi ani linku z "Pošumaví".

Ono totiz vetsinou zalezi na navrhu a rozvrzeni designu, tak nejak s ohledem na datovou zatez, pak se Vam totiz laborovat s ramci na ukor pristupnosti nevyplati (nevim, jak velkou sluzbu udelate ramci "amaterum" s pda apod.)

Pristupnosti stranek se nemysli to, ze budou dostupne 99,9 procent casu, ze budou umisteny na rychlem serveru a rychle pripojeny do internetu, ale mysli se to, ze budou dostupne velke skupine obyvatel, vcetne tech postizenych, ve smyslu pristupnosti obsahu (slepy uzivatel tezko zjisti, co je na obrazku nakresleno, kdyz chybi jeho textovy popis) atd.

Vytvoreni webu se pohybuje od 30 tisic nahoru? No, to neni pravda. Spousta lidi vam udela spickovy, pristupny web i do deseti tisic.

Pro statni spravu ? Proc ? Vyhazuji se preci penize nas vsech, tak proc jich nevyhodit o neco vic, kdyz ti nahore vyhazuji miliardy, proc by si ty Kotehulky nemohli vyhodit desetitisice.

Kdyby to totiz fungovalo jak ma, tak stat zaridi nejake univerzalni web rozhrani prave pro male obce, kam si mohou davat sve informace. A teprve kdyz se chteji nejak odlisit, mohou si zaridit vlastni prezentaci.

Rámová struktura sama o sobě není překážkou v přístupnosti, vždy záleží na tom, jak ji tvůrce využije (totéž platí o skriptech a podobně).

Každý nový předpis přináší s sebou nové náklady na přizpůsobení nynějšího stavu. To bude platit i u spousty webů, až vstoupí v platnost vyhláška o přístupnosti. Tahle pravidla umožňují jednoduchým způsobem upravit současné weby tak, aby byly na základní úrovni přístupné.

Web má životní cyklus. Ve včerejším profilu Daniel Kafka píše, že je to kolem dvou let. To je také doba, během které se nejspíš dočkáme nařízení o přístupnosti z EU. Nikdo ještě netuší, jak přísná či měkká budou pravidla EU, ale je jasné, že si nejspíš vyžádají další úpravy webů. S ohledem na daňové poplatníky si tedy myslím, že tenhle první nástřel by opravdu měl požadovat jen základní přístupnost.

U nových webů státní správy už bych očekával kompatibilitu s WCAG v úrovni alespoň AA, lépe AAA. Ale u webů již existujících je trvání na odstranění rámů (které navíc nemusí bránit v přístupnosti) zbytečně drahé.

U nových webů státní správy už bych očekával kompatibilitu s WCAG v úrovni alespoň AA, lépe AAA.

Martine, domnívám se, že se pleteš. Chtít po českém webu dodržet celou úroveň "AA" nebo dokonce "AAA" je úplný nesmysl. Ještě jsem nepotkal žádný český web, který by splňoval ani jedno "A". To, že to některé weby o sobě tvrdí, ještě neznamená, že to opravdu dodržují.

Když se podíváš do té naší metodiky, zjistíš, že v ní ani nejsou všechny body z priority "A". Ale na druhou stranu jsou zde některé body z priority "AA" a dokonce i dva body odpovídající prioritě "AAA". Zkrátka, spolehnout se jen na WCAG v české praxi roku 2004 prostě nejde.

A jen doplním, že ty body WCAGu, které odpovídají prioritě "AAA", jsme do naší metodiky dali jen proto, že vyšly jako klíčové v onom zmiňovaném uživatelském testování organizace DRC.

Já se zeptám jinak. Existuje nějaký důvod, proč bychom měli rámy zakazovat? Dokud to někdo považuje za dobrý nápad a dokud je to "košer" konstrukce, tak na to právo nemáme. A je spousta situací, kdy je použití rámů dokonce nejvhodnější a nejefetivnější technologií (třeba rozsáhlé manuály s dlouhým obsahem, nebo některá aplikační rozhraní).

Naší povinností je jen zajistit, aby i ty rámy byly přístupné. Tedy hlavně aby se stránky daly používat i bez rámů, aby žádná dílčí stránka umístění v nějaké struktuře rámu nevyžadavala (ani nepředpokládala), aby fungovala navigace i bez rámů a aby se obsahem rámů dalo posouvat. To je skutečné minimum přístupnosti a přesně toto v těch pravidlech najdete - nic víc a nic míň.

Ano. Kdo si přečte pravidla pozorně, musí mu být jasné, že pokud na webu budou dodržena všechna zmiňovaná pravidla, budou rámce přístupné a není s nimi žádný problém.

Rád bych všem (a především těm, jimž se zdají příliš přísná) připomněl smysl těchto pravidel. Jde o pravidla *přístupnosti* (neboli accessibility), mající zajistit co možná bezbariérový přístup k informacím na webech veřejné správy pro občany s nějak sníženými/změněnými schopnostmi. Ze stejných důvodů se na úřadech staví bezbariérové přístupy pro vozíčkáře - jistě taky leckomu, kdo běhá jak kamzík, mohou lézt krkem, to ale nijak nesnižuje jejich význam.

Pekne, pekne prijde mi to strizlive a efektivne nastavena latka. Mozna budu vypadat jako nedovzdelanec, mozna je to tim, ze to nepouzivam, ale nevim jak vypada serverova obrazkova mapa. Vim, jak vypada oblibena mapa se na klientovi, ale na serveru?

Mapa na serveru pracuje podobně jako mapa na klientu. Plocha je rozdělena na aktivní oblasti vymezené souřadnicemi. Po klepnutí na plochu odesílá prohlížeč serveru souřadnice (podobně, jako po klnutí na formulářový input typu image). Server získané souřadnice vyhodnotí a podle toho, které aktivní oblasti náleží, vrátí na klient odezvu.

Kdo teď nadává, že ta pravidla jsou příliš přísná, bude asi zaskočen, když se dozví, že jsou jen velmi obecná a měkká, protože budou platit po krátký čas. V Evropské komisi je připravován předpis, který by požadavky na bezbariérový přístup k webu měl sjednotit.

Další zajímavá věc je, že zatímco tento návrh se dotkne nejspíš jen státní správy, v jiných zemích je pravidlem, že se předpis pro bezbariérový web týká všech organizací, institucí a firem, které nakládají s penězi ze státních a veřejných rozpočtů. Takže pokud připravujete koncepci nějakého takového webu na delší časové období, bylo by prozřetelné alespoň tato základní a obecná pravidla na něm uplatnit -- chráníte tím svoje investice.

jako myslite imagemap se svymi coords a serverova mapa je napr. vystup nejakeho mapserveru a jeho prohlizecka??

Přiznám se, že vám vůbec nerozumím.

Ale vidíte tuhle adresu?

  http://www.lupa.cz/nazory.php3?c_id=3380&showall.x=28&showall.y=5

To showall.x a showall.y udava pocet pixelu od leveho horniho rohu obrazku, na ktery uzivatel klepnul. V tomhle pripade je to input type="image", ale stejne to vypada i u klepnuti na obrazovou mapu (imagemap), ktera je obsluhovana serverem.

aha, ja prave myslel, ze imagemap si obslouzi klient - je to v ramci html, zatimco showall.x a showall.y (coz je imho to same, jako kdyz napr zoomujete mapu na seznamu) si obslouzi server - klient netusi, ze showall.x a showall.y dela to a to ...

Obrazová mapa může být obsluhována na klientu, nebo na serveru (Server-side image maps v HTML 4.01). S tím "imagemapem" jsem nebyl přesný, to vás asi zmátlo, promiňte.

teda pravidla se netroufnu hodnotit, protože nejsem takový odborník jako pixy a spol. ale jednu věc hodnotím až neskutečně pozitivně - to je snad první státní zákon/norma na jehož řešení si přizvali odborníky. Kdyby tomu tak bylo u všech zákonů, tak už jsme asi úplně jinde. Bravo.

Dovolil bych si nesouhlasit. U většiny zákonů jsou aspoň v počáteční fázi přítomni odborníci. Problém je v tom, že po nich to projde ještě přes právníky, poslance a senátory. Ti ovšem nejsou ve valné většině vzděláni v příslušném oboru, a tak se jim nezřídka povede zákon totálně zmršit, občas i tak, že říká pravý opak toho, co bylo v původním návrhu.

Proto je potreba prvne zabit vsechny pravniky ;-)

Ach jo, zase ukazujete, že víte kulový s přehazovačkou. Holt klasická kučerovina.

U přípravy zákonů nejsou většinou právníci těmi, kdo to mrší. Na začátku je ucelá právní norma, která v maximální míře navazuje na stávající právní normy (zákony, vyhlášky etc.). Teprve "kreativní" pozměňovací návrhy z toho dělají ten úžasný paskvil.

Ovšem faktem je, že problém naprosté většiny českých právníků (čest legislativcům, kteří jsou u nás světlou výjimkou!) spočívá v neschopnosti aplikovat právo. Ve škole je to neučili. Mají nabiflované předpisy, ale neví, co s nimi. Proto třeba smlouvy jsou jak od právního kutila.

Tím se ale bohužel dostáváme k problému systému školství, odkud bych mohl plynule přejít k zákonným úpravám českého vzdělávání. Prvotní záměry konzistentní a v zásadě i celkem smysluplné, po opracování politiky (kteří bývali předtím sedláci, malíři, učitelé či jen prostí tlučhubové) nepoužitelné.

Takže zkuste zacílit k jádru problému. Právníci jím skutečně nejsou.

Právníci sice vyrobí ucelenou právní normu, ale často ve snaze vylepšit formulací po stránce právní totálně zmrší věcný obsah. Proto by měli při své práci spolupracovat s tou odbornou skupinou, aby k takovým průšvihům nedocházelo. Souhlasím ale s tím, že v porovnání s ranami, které zákonům uštědřují poslanci a senátoři, jsou ty od právníků jen drobnými šrámy.

Chtěl bych se zeptat, které publikační systémy (free nebo v licenci GPL) byste doporučili pro použití tak, aby tam šly snadno aplikovat doporučení výše uvedená. Tzn. možnost nadesinovat si vzhled pomocí šablony. Používáte něco? Doporučíte?

WordPress wordpress.org
Pivot pivotlog.net
anebo si zkuste vybrat na asymptomatic.net

Taky textpattern a b2evolution a mnohé další. Publikační systém sám o sobě většinou bariéry neklade (pokud nevyužívá navigaci přes JS). Problém bývá až v šablonách.

editor dava xhtml vystupy? jen se ptam ...

Ja bych jen chtel rict, ze lidi, co tady napadnou neuplnost techto pravidel vidim spis jako rejpaly. Osobne jsem vdecny, ze alespon toto a hned v teto podobe bude aplikovano. Jen bych chtel verit, ze v pripade benevolence bude vsem mereno stejne ...

"Každý formulářový prvek má přiřazen výstižný nadpis."

Nebylo by vhodnější slovo popis? Nadpisem bych rozuměl h1,...,h6.

---

V diskuzi taky několikrát zazněly protesty proti rámům. K čemu je asi element noframe? Weby můžou návštěvníkům bez rámů nabídnout na úvodní stránce všechno, co na ni patří a na další stránky odkaz na tuto hlavní stránku.

To by myslím neměl být problém ani pro Dolní Kotěhůlky;)

---

P.S.: Doufám, že část odpovědnosti přenesou obce a kraje na své dodavatele. Že je napadne tento předpis nějak zafačovat do smluv. Samozřejmě s možností reklamace! Jinak to povede k tomu, že budou kraje a obce platit pokuty, ani nebudou vědět za co(a nebo to bude tolerovaný a vyhláška bude k ničemu)...

Nebylo by vhodnější slovo popis? Nadpisem bych rozuměl h1,...,h6.

Jedná se skutečně o značku <label>, jak správně naznačujete. V doplňujícím popisu tohoto bodu bude konkrétně napsáno, že se myslí tato značka a ne značky pro skutečné sémantické nadpisy.

Já labelu říkám návěstí. ;-)

K pokutam se nikdo nikdy nepropracuje, protoze se na Webech proste nic nezmeni!
Co se ale zasadne zmeni, ze se vsechny nesmyslne body budou ve statni sprave vsichni ucit, budou se zkouset, maximalne 5 omylu v cislovani bude povoleno pri atestacich na definitivu.
Mozna se to zacne vyucovat i na nektere velmi vysoke skole. Proste to dopadne jako treba s elektronickym podpisem.

Výborná pravidla - myslím, že by prospěla nejenom státní správě :)

Mel bych pripominku k tomuto pravidlu:

- Předpisy určující velikost písma nepoužívají absolutní jednotky.

Zamerem asi je, aby se nepouzivala jednotka px, kterou majoritni prohlizec nedokaze zvetsovat (uprimne receno, porad lepsi nez pristup Mozilly, ktera to zvetsuje jenom u pisma a u vseho ostatniho ne). Ale px je jednotka relativni. Na druhou stranu zakaz pouzivat absolutni jednotky napr. "cm" ve verzi pro tisk je dost svazujici.

Specialne ve verzi pro tisk byste se mel vyvarovat nejakeho pevneho rozvrzeni. Jednak na spouste webu je verze pro tisk jedina, ktera se da rozumne cist a jednak u tisku mohou mit lide potrebu mit nastaveny zcela jine fonty nez pro zobrazeni a kdyz si treba chcete odnest na papire jizdni rad, a hure vidite, tak moc podekujete tomu, kdo zajisti, ze stranka bude presne 21x30cm a na ni bude pismo velikosti 4 s perfekte zarovnanymi sloupecky.

Specialni HTML soubor pro tisk jsem nemel na mysli - uvazoval jsem specialni CSS soubor u ktereho je nastaveno media: print (ktery si ve vetsine prohlizecu neprohlednete, v Opere by bylo snad podobne vypnout styl). Ja osobne nastavuji ve stylu pro tisk jiny font (obvykle patkovy). Pokud to chce uzivatel zmenit, tak at pouzije metody k tomu urcene (uzivatelske styly).

V Opeře kliknete na ikonku "Print Preview" případně dáte "File - Print Preview" nebo použijete Shift+p. ;-)

Díky za věcnou připomínku. Měl bych k tomu asi následující:

1. Verze pro tisk neřešíme.

2. Co se tyka vyjadření velikosti písma, lze de facto použít čtyři skupiny definic. Písmo můžete definovat:
a) ABSOLUTNĚ - tj. např. small, x-small, medium atp.
b) RELATIVNĚ - tj. např. smaller atp. (tato skupina se někdy řadí do skupiny a) ABSOLUTNĚ - dá se ale rovněž nazvat RELATIVNĚ - pro naše účely je to ale jedno)
c) ABSOLUTNÍMI JEDNOTKAMI - tj. cm, pt, px (ten sem de iure nepatří, ale my jej sem v doplňujícím odstavci autoritativně doplníme) atp.
d) RELATIVNÍMI JEDNOTKAMI - tj. em, % atp.

V našem pravidlu je tedy zakázána skupina c). V doplňujícím odstavci bude vše konkrétně specifikováno.

Pan brn měl asi namysli to, že pixel je jako obrazový bod vždy závislý na zobrazovacím zařízení a jako takový je velmi proměnlivý vůči okolí. Například centimetr by se proěnil asi jen za předpokladu, že by se výrazně změnil obvod země. :-)

Kopta, nedelej ze sebe starsiho nez jsi. Delkove jednotky se prestaly odvozovat od obvodu zeme davno pred tim, nez te vubec napadlo, ze bys nekdy mohl chodit do skoly ... ;-)

No ale kdyby se výrazně změnil obvod zeměkoule, tak by se s tím něco dělat muselo. Protože by si jinak nikdo nepamatoval, jak je Země veliká.

Otázkou ale je, jak změnu obvodu změřit, že. :-) V centimetrech, když jsou od ní odvozeny? :-) Obvod Země je v jednotkách odvozených od obvodu Země konstantní, i kdyby se měnil pětkrát za minutu.

Ale Dan asi odkazuje k tomu ocelovému prutu o délce jednoho metru. Hmm, Takže vlastně centimetr není odvozen od obvodu Země, ale od délky tyče. Když se změní tlak nebo teplota v trezoru, tak se změní i délkové míry. :-)

To jste pořád o dvě definice zpátky. Po onom prototypu (pokud mne paměť neklame, nemá s ocelí nic společného) tu byla ještě definice odvozená od vlnové délky záření emitovaného při přechodu elektronu mezi dvěma energetickými hladinami v atomu kryptonu. Současná definice říká, že metr je 1/299792458 vzdálenosti, kterou světlo ve vakuu urazí za jednu sekundu.

A teď se tedy konečně dostáváme k tomu nejdůležitějšímu. Je potřeba zpomalit nebo zrychlit otáčení Země kolem vlastní osy, aby se změnil délka centimetru. :-)

Nebo jak je vlastně odvozen čas?

Podobnym zpusobem jako ten metr...:-) a se Zemi to ma pramalo spolecneho...

No, o tom by se malinko polemizovat dalo. Delka jedne sekundy, tak je skutecne definovana tak, jak uvedeno v nize zapsanych odkazech - a se Zemi ma skutecne pramalo spolecneho. Tak je definovana sekunda. Otazka ale znela, jak je definovan "cas" - coz ja chapu jako ten v praxi pouzivany cas, ktery vidime na hodinkach. Pro tento pojen je samozrejme klicova ona na Zedmi nezavisle definovan sekunda, ale jeste je ho potreba "absolutne ukotvit" aby nam jen tak volne neplandal (a nemeli jsme poledne pri zapadu slunce). A toto "ukotveni" casu se skutecne provadi (stale jeste) astronomickym pozorovanim a tedy se Zemi uzce souvisi (v praxi se provadi tak, ze dvakrat rocne se na zaklade odchylky mereneho casu od vysledku astronimickych pozorovani zvazi, zda vlozit nebo naopak neubrat jednu sekundu do pocitani casu. (Mimochodem, kdo z vas pri psani pocitacovych programu pracujicich s casem pamatuje na to, ze cas 23:59:60 nemusi byt vadny, ale zcela korektni ?)

Kdyby se tedy zrychlilo otaceni zeme, sekunda by zustala stale stejne dlouha. Ale cas - ten by bezel rychleji ...

Nicmene, uplne puvodne se tady Kopta navazel do "metru" - a cas, tak jak jsem o nem prave mluvil (tedy pripadne jeho zrychleni nebo zpomaleni) by na nej ani tak zadny vliv nemelo ...

Např.

• http://encyclopedia.thefreedictionary.com/SI%20base%20unit
• http://www.physchem.co.za/Basic%20Skills/Units.htm#second
• http://www.wordiq.com/definition/SI_base_unit#Time_(t)

Hm, jenze pak bych byl jinak veliky ja. A zatimco obvod zemekoule si stejne nepamatuju, svoji velikost jo. Takze hlasuju proti ... :-)

Diky za odpoved. Konecne budu mit nejaky argument pro klienty proc nedefinovat velikost pisma v pixelech (kdyz je to vetsi firma/skola tak casto alespon jeden z lidi, co web schvaluje, v IE nedopatrenim pri rolovani koleckem mysi pritiskl CTRL a tim zmensil/zvetsil pismo do krajni hodnoty. Ten clovek to ihned nepozna, protoze 99% webu ma pevnou velikost pisma, a pak se divi, proc vidi tal velka pismena. Mozna by to schtelo zvazit, jestli by nebylo lepsi povolit px pokud je pro zmenu velikosti pisma na webu dostupny jiny (javascriptovy) mechanismus. Ale asi ne.)

jakozto webmaster jednoho ministerskeho webu se uz na tyto pravidla strasne tesim, protoze pak teprve je bude mozne realne uplatnit. dokud `nadrizenym' nebude mozne podobny dokument (urednicky overeny - tzn. ne wcag apod. cancy) omlatit o hlavu, pak se toho moc nezmeni :)

Myslím, že weby státní správy se nemusejí zabývat problémem osmibitového kódování, protože stále platí ČSN ISO/IEC 8859-2. :-)

Uvedena norma se jmenuje "Informační technologie - Jedním 8-bitovým bytem kódované soubory grafických znaků - Část 2: Latinská abeceda č. 2".

Ach jo. Už snad 10 let existuje Unicode a jeho kódování utf-8, jen tady se asi budeme muset patlat s nějakým osmibitem...

Pokud uvažuju jen češtinu, jakou výhodu má UTF-8 proti ISO-8859-2?

Pokud chcete psat skutecne cesky, tak minimalne tu, ze obsahuje ceske uvozovky. Dale jsou v nem ruzne v Evrope potrebne znaky skutecne znaky a ne entity. Je beznou realitou, ze lide maji jmena obsahujici zvlastni znaky a je ponekud slozite, nutit je, aby to do html formularu psali jako entity, pokud to vubec jde.

Typografove uvitaji ruzne typy pomlcek, matematici recka pismena.

V dobe kdy vsechny kancelarske baliky bezi v Unicode je dalsi vyhodou, ze ukladani to html neni ztratove. To u Windows1250 ani u ISO neplati.

Pokud chcete pouzivat znak euro, musite najet na ISO-8859-15, tak to uz je lepsi najet rovnou na unicode, ktery lide alespon znaji.

Jedna vec v tom clanku i v diskusi chybi. A to o to vice ze se stale bavime o minoritach a jejich pristupu k informacim.
Tento predpis je dobry bic na spatne a hojne navstevovane weby bohatych statnich uradu. Ty maji profi spravce a mely by tento predpis splnovat jiz dnes.
Ale co ostatni stranky. Nektere (mistni) urady nejen nemaji profi webare, ale jsou vykonavany pri jinem zamestanani. Nebereme tem lidem chut delat a hlavne aktualizovat stranky?
Je to spise otazka na ten zakon. Ma platit pro vsechny stranky bez rozdilu?

to je imho naprosty nesmysl - imho to nepomuze tem nadsencum, ktere mate na mysli, ale v drtive mire to dovoli profi firmam uplatnit starsi a nevyhovujici soft bez nakladu na obnovu jinde, cili ja bych se spis bavil o podpore informatizace statni spravy, nez, ze bych snizoval latku ...

Ne jako narizeni, spis doporuceni:

1.) preference obsahu pred formou. Ne zanedbavani formy a technickeho zpracovani, ale proste nezapominat, ze primarnim ucelem je POSKYTOVAT INFORMACE/SLUZBY

2.) snazit se minimalizovat velikost stranky v kB. respektive davat pozor, aby neprekrocila urcitou unosnou hranici - uplne zneni zakona samozrejme prilis zmensit nelze, ale treba uvodni strana webu, pripadne jina, podle statistik velmi exponovana mista

3.) aktualnost - nelze to predepisovat jako takove, ale v souvislosti s aktualnosti informaci bych nalehal na osobni zodpovednost za aktualnost jednotlivych casti webu, u vsech podstatnych informaci pak uvadet jasne datum publikace, pripadne jejich platnosti

4.) ostatni dokumenty - mozna bych se nejak pokusil i pripravit doporuceni, jake formaty pouzivat pro dokumenty, ktere nejsou publikovany jako html stranka.

...aby se vzajemne netloukly mezi sebou tak vam zbyde textak ke stazeni...

Jirka