Poslepu.cz na novém URL

Od ledna 2014 najdete blog na adrese poslepu.cz.

pátek 28. prosince 2012

Apple jako kompenzační pomůcka pro zrakově postižené - 9. díl

Editace textu a přepínání kontextů

Dnes dokončíme práci s textem a řekneme si zejména to, jak text pohotově editovat. V druhé polovině si potom představíme nabídky VoiceOveru pro přepínání aplikací a oken a související systémové klávesové zkratky.

Vyčítání pozice v textu

Vraťme se ještě k tomu, jak VoiceOver popisuje pozici textového kurzoru, pokud VoiceOver kurzor či fokus ukazují na textové pole. V hlášení o pozici je zejména zmíněno, v rámci kterého slova se kurzor nachází, za kterým znakem je umístěn, popř. nachází-li se na začátku nebo konci textu. V případě, že úsek textu je označený nebo je označený celý text, je to VoiceOverem příslušně okomentováno. Máme tak k dispozici poměrně stručnou a vyčerpávající zprávu o tom, kde se v textu nacházíme. Jestliže nám toto hlášení nestačí, nabízí VoiceOver příkazy umožňující vyčíst příslušný úsek textu, v němž se VoiceOver kurzor nachází. Opět, protože standardně VoiceOver kurzor sleduje textový kurzor, budeme to pro lepší pochopení brát tak, že vyčítají tyto příkazy de facto okolí textového kurzoru.

Klávesová zkratka
Popis
VO+C
Přečíst znak zaměřený VoiceOver kurzorem
VO+C,C
Přečíst foneticky znak zaměřený VoiceOver kurzorem
VO+W
Přečíst slovo zaměřené VoiceOver kurzorem
VO+W,W
Vyhláskovat slovo zaměřené VoiceOver kurzorem
VO+W,W,W
Vyhláskovat foneticky slovo zaměřené VoiceOver kurzorem
VO+S
Přečíst větu, v níž se nachází VoiceOver kurzor
VO+L
Přečíst řádek, na němž se nachází VoiceOver kurzor
VO+P
Přečíst odstavec, v němž se nachází VoiceOver kurzor
VO+B
Spustit plynulé čtení celého textu, v němž se nachází VoiceOver kurzor
VO+A
Spustit plynulé čtení od aktuální pozice VoiceOver kurzoru až do konce textu
Ctrl
Zastavit čtení, popř. i pohyb VoiceOver kurzoru při plynulém čtení

Pro lepší pochopení je vhodné na tomto místě zmínit ještě několik poznámek k uvedeným příkazům:

  • Všechny uvedené příkazy kromě posledních tří nijak nepohybují s textovým nebo VoiceOver kurzorem.
  • Znak pod kurzorem je čten v závislosti na tom, zda je nastavená volba VoiceOveru, zda číst znak, přes který přechází kurzor, nebo znak vpravo od kurzoru.
  • Slovem je myšlen sled znaků skládající se pouze z písmen a číslic. Větou je myšlen takový text, který začíná velkým písmenem a končí tečkou, při čemž slovo následující za tečkou musí mít první písmeno velké.
  • Odstavcem je myšlen úsek textu nacházející se mezi dvěma pevnými konci řádku (stisk Enteru).

Editace textu

Abychom návod k tomu, jak v OS X s VOiceOverem pracovat s textem, měli v základu ucelený, není možné nezmínit editační funkce. V podcastu k minulému dílu jsme si na okraj řekli, že většina nastavení VoiceOveru včetně odezvy klávesnice při psaní je k nalezení v kategorii Podrobnost a zde na kartě Text. To je důvod, abychom možnosti přizpůsobení VoiceOveru našim potřebám při práci s textem hledali právě tam. Na neštěstí není dosud pravý čas na rozbor nastavení VoiceOveru, proto si každý musí toto přizpůsobení vyzkoušet sám.

Klávesa Clear (Backspace) maže znak vlevo od kurzoru a hodí se tak zcela běžně pro opravování právě psaného textu. Není-li na klávesnici klávesa Delete, což jsou v podstatě všechny mobilní klávesnice Apple, používáme pro mazání znaku vpravo od kurzoru FN+Clear. Přidáme-li navíc ke klávesám na mazání Alt, maže se tímto stiskem až k začátku nebo konci slova od umístění kurzoru.

Pohybujeme-li kurzorem klávesovými zkratkami uvedenými v minulém dílu a přistiskneme k nim Shift, rozšiřuje se označený blok textu o úsek, přes který přešel kurzor. VoiceOver vždy přečte úsek textu, o nějž se označený blok rozšířil či zúžil. Pro práci s bloky textu můžeme využít nikoli neznámé příkazy:

Klávesová zkratka
Popis
Smazání bloku a započetí psaní na jeho místo
Provedení příkazu pro pohyb kurzoru od příslušného okraje bloku a zrušení označení
Clear
Vymazání označeného bloku
CMD+X
Vyjmutí označeného bloku do schránky
CMD+C
Zkopírování označeného bloku do schránky
CMD+V
"Vepsání" obsahu schránky na místo kurzoru či označeného bloku

Protože běžně editační pole v dialozích mají svůj celý obsah předoznačen do bloku, vyvolá psaní smazání původního obsahu a započetí psaní nového. Nebo též označený blok textu si můžeme představit jako nafouknutý kurzor, což vysvětluje chování příkazů pro pohyb kurzoru, Je-li něco označeno. Kurzor se totiž přemístí z jednoho z obou okrajů o daný úsek - pohneme-li se zpět vychází z levého okraje a vpřed z pravého, což je odlišné od chování Windows, které vycházejí vždy z levého okraje, tj. počátku označení.

Přepínání aplikací

Jak jsme se zmiňovali v jednom z předchozích dílů, dock je jedním ze způsobů, jak lze přepínat mezi spuštěnými aplikacemi. Protože obzvláště při malém počtu spuštěných aplikací se pro nás, uživatele používající VoiceOver, jeví tento způsob jako méně přehledný, s výhodou využijeme další dvě možnosti.

První z nich je přepínání mezi posledně používanými aplikacemi. Funkce pracuje stejně jak ve WIndows s tím rozdílem, že místo klávesové zkratky Alt+Tab používáme CMD+Tab. Držíme tedy CMD a přistiskáváme Tab tak dlouho, dokud neuslyšíme název spuštěné aplikace, do níž se chceme přepnout. Chceme-li některou z vyslovených aplikací bezprostředně ukončit, není nic snažšího, než k drženému CMD přistisknout Q. Po uvolnění CMD dojde k přepnutí do aplikace, která byla naposledy přečtena.

Naopak při větším počtu spuštěných aplikací, pokud nechceme využít dock, se nám hodí nabídka pro výběr aplikací přístupná přes klávesovou zkratku VO+F1,F1. V nabídce je možné zjistit, která aplikace je aktuálně v popředí a která byla tou předchozí v popředí. Kromě toho každý z názvu aplikace je podnabídka, a tak pokud rozbalíme podnabídku šipkou vpravo, získáme seznam oken, jež k aplikaci náleží. Takto je možné se přepnout nejen do konkrétní aplikace aktivováním příkazu Otevřít aplikaci, ale i do konkrétního okna aplikace.

Drtivá většina oken náleží k nějaké spuštěné aplikaci, můžeme se však setkat s okny, jež k žádné aplikaci nepatří. Výhoda nabídky pro výběr aplikací je právě ta, že dovoluje skrze tuto nabídku VoiceOveru přístup z klávesnice k takovýmto oknům, která se sdružují do podnabídky Systémové dialogy.

Přepínání oken

Každá spuštěná aplikace může mít okno jedno či více, ale i okno žádné, což je oproti Windows rozdíl, jenž nám ze začátku bude připadat zvláštní. V OS X platí, že aplikace je ustanovena již svými aplikačními nabídkami a žádné aplikační okno mít nemusí. Pokud se nám podaří zavřít i to jediné okno, které většina aplikací má, lze vše napravit přes aplikační nabídku okno, kde je možné vybrat, které z oken se má zobrazit.

Aplikace mívající více oken, typicky např. editory dovolují editovat více dokumentů najednou, pak můžeme ovládat pomocí klávesových zkratek na přepínání oken. První z nich je příkaz systému pro přecházení mezi okny klávesovou zkratkou CMD+¨a druhý z nich nabídka VoiceOveru pro přepínání oken pomocí VO+F2,F2. V některých případech je jedno, který ze způsobů použijeme, vyskytují se však případy, kdy nabídka VoiceOveru pro výběr oken je jediným způsobem, jak mezi okny aplikace přepínat. Nestává se to často, ale je nutné na to pamatovat ve chvílích, kdy máme dojem, že by aplikace měla mít více oken. Klávesová zkratka CMD+¨ funguje bezpečně v aplikacích, které nabízí práci s více pohledy či dokumenty - Finder, Mail, Safari ad.

Podcast

V podcastu k dnešnímu dílu si vykopírujeme výpis vyhledávání z Knihovny digitálních dokumentů, upravíme a promažeme vše nepotřebné. Tímto si procvičíme práci s textem a přepínání mezi aplikacemi. Až budeme mít vše hotové, rozhodneme se, že s výsledkem nejsme spokojeni. Vrátíme se tedy k některé z předchozích verzí pomocí funkce procházení verzí v editoru TextEdit, čímž si procvičíme přepínání oken a zopakujeme práci s dialogy.

Podcast ke stažení ve formátu mp3 (14,1 MB)

Autorem článku je Roman Kabelka.

Další díly seriálu

středa 26. prosince 2012

TalkBack a Firefox významně zlepšují přístupnost Androidu

Kromě jednoduché zvětšovací lupy, o které jsem psal nedávno, mají nyní uživatelé Androidu, kteří s ním pracují pomocí asistivní technologie, k dispozici dva další nástroje, usnadňující jeho používání. Rád bych Vás s nimi alespoň krátce seznámil.

Talkback 3.2.1

Aktualizace screen readeru TalkBack doposud spočívaly spíše v opravách bugů a nové funkce byly přidávány jen velmi pozvolna. To se nyní mění a odečítač obrazovky Talkback začíná svým uživatelům přinášet i nové funkce a vylepšení.

Nový TalkBack je k dispozici pro Android 2.2 a vyšší a některé jeho novinky tak mohou využívat i majitelé starších verzí systému.

Co nového TalkBack 3.2.1 přináší? Kromě řady drobných vylepšení jsou to hlavně

  • globální kontextové menu (Global Context Menu), umožňující rychlý přístup k některým funkcím - například zopakování poslední hlášky či k nastavení odečítače TalkBack. K aktivaci globálního kontextového menu slouží dvoufázové gesto, při kterém nejprve švihnete prstem dolů a pak doprava.
  • Funkce plynulého čtení (Full-screen reading menu), nabízející možnost lineárního vyčítání všech položek dostupných na obrazovce zařízení. Menu pro vyčítání obrazovky lze otevřít opět pomocí dvoufázového gesta - tentokrát směrem nahoru a doprava.

Firefox pro mobilní zařízení

Firefox pro mobilní zařízení přináší - zatím pouze v nočních verzích - možnost rychlé navigace na webových stránkách i pro čistě dotyková zařízení. Tu podporuje Firefox již dlouho, ale doposud k ní bylo třeba použít hardwarovou klávesnici. Aktuálně je dostupná rychlá navigace po odkazech, nadpisech, položkách seznamů a formulářových prvcích.

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

pátek 7. prosince 2012

Android 4.2 nabízí jednoduchou softwarovou lupu

Minulý týden dostal můj telefon nejnovější Android 4.2. Kromě celé řady novinek přináší i jedno užitečné vylepšení v oblasti přístupnosti pro slabozraké uživatele - má integrovanou jednoduchou lupu.

Po zvětšovací funkci volali uživatelé už dávno a pro mnoho z nich byl chybějící zvětšovací program důvodem, proč si Android nevybrat. To se teď může změnit.

Zvětšovací funkci, která se v Androidu jmenuje Gesta pro přiblížení obrazovky, si zapneme v Nastavení pod položkou Usnadnění. Nejedná se o klasickou softwarovou lupu, kterou bychom si jednou spustili a lupa by nám od té doby stále zvětšovala informace z obrazovky (jako je tomu třeba u softwarových lup pro MS Windows), ale pokud si chceme něco zvětšit, aktivujeme si zvětšení trojitým poklepáním na displej.

Toto chování může určitá skupina slabozrakých uživatelů, kteří potřebují permanentní zvětšování, vnímat jako negativum, protože si musí na každé obrazovce lupu znovu aktivovat. Naopak pro uživatele, kteří potřebují zvětšovat jen občas, je toto chování ideální.

Na zvětšené obrazovce pak můžeme pracovat následujícím způsobem:

  • oddalováním minimálně dvou prstů od sebe si můžeme úroveň zvětšení ještě zvýšit,
  • analogicky přibližováním minimálně dvou prstů k sobě můžeme úroveň zvětšení snížit,
  • pokud se chceme posouvat po zvětšené obrazovce, táhneme po obrazovce minimálně dvěma prsty.

Zvětšení zrušíme opakovaným trojím poklepáním na obrazovku, či provedením nějaké akce (například spuštěním aplikace). Pokud chceme ve zvětšeném prostředí pracovat i na další obrazovce, musíme si je znovu trojím poklepáním aktivovat.

Zvětšení je také možné aktivovat jen dočasně tak, že poklepeme třikrát na obrazovku, držíme na ní prst a pak se prstem pohybujeme po obrazovce. Zvětšení je aktivní do doby, než prst zvedneme.

Tímto způsobem bohužel nelze zvětšit klávesnici - což pro některé uživatele může být také překážka.

I přes výše zmíněné potencionální nevýhody se ale jedná o další docela velký krok ke zpřístupnění Androidu a věřím, že pro některé uživatele může být existence této lupy důvod si telefon či tablet s Androidem pořídit.

Videoukázka

Související odkazy

čtvrtek 29. listopadu 2012

Zdroje informací o přístupnosti HTML5

Při přípravě prezentace na letošní DevFest a článku na Zdroják jsem kromě vlastního testování nastudoval i spoustu již publikovaných informací. V poznámkách z přípravy mi tak zůstalo docela dost odkazů a o ty nejzajímavější by určitě byla škoda se nepodělit.

Pro HTML5 Accessibility
V současnosti asi nejlepší kniha zabývající se touto tématikou. Verze pro Kindle stojí 25 dolarů a z vlastní zkušenosti mohu říci, že je to opravdu dobrá investice.
Book Review: Pro HTML5 Accessibility
Podrobná recenze knihy Pro HTML5 Accessibility. Pokud byste náhodou byli na vážkách, zda si ji koupit, tak tato recenze Vás určitě přesvědčí.

Pro HTML5 Accessibility na Amazon.com

HTML5 - A vocabulary and associated APIs for HTML and XHTML
Aktuální verze návrhu specifikace HTML5 od W3C z 11. listopadu 2012, momentálně ve stádiu Editor's Draft.
Accessible Rich Internet Applications (WAI-ARIA) 1.0
Aktuální verze specifikace WAI-ARIA, která už je i součástí HTML5. V současné době je k dispozici jako W3C Candidate Recommendation.
WAI-ARIA 1.0 Authoring Practices
Dokument z dílny W3C o tom, jak rozumět požadavkům z WAI-ARIA a jak je implementovat.
HTML5
Podtitul "vše co potřebujete vědět o HTML5" je myslím dostatečně výstižný ;-)
JAWS, IE and Headings in HTML5
Praktický test toho, jak si screen reader JAWS poradí s různými způsoby strukturování stránky pomocí nadpisů.
ARIA Gone Wild (pdf; 13,4 MB)
Jared Smith prezentoval tématiku WAI-ARIA na Accessibility Summitu. Slajdy k jeho prezentaci jsou informačně bohaté i bez doprovodného mluveného slova.
Using ARIA to Enhance Web Application Accessibility
A Jared Smith ještě jednou. Praktická a interaktivní HTML prezentace plná konkrétních příkladů toho, jak pomocí WAI-ARIA zlepšit přístupnost HTML.
Using ARIA in HTML
Neoficiální draft dokumentu, který má sloužit webdeveloperům jako praktický rádce při implementaci ARIA do HTML. Autorem je Steve Faulkner.

A na závěr dvě videa.

Making Your Web Apps Accessible Using HTML5 and ChromeVox

John Foliot - HTML5 Accessibility

pondělí 26. listopadu 2012

Psaní na iPhonu poslepu

Moderní chytré telefony zastanou funkci mnoha jednoúčelových zařízení, a tak jejich koupě se vyplatí a to i zrakově postiženým. Přestože tyto telefony jsou výhradně dotykové, nabízí způsob ovládání, jenž i nevidomý poměrně snadno zvládne a může tak telefon využívat se všemi jeho výhodami. Jak už z POSLEPU víte, patří mezi takové telefony i Apple iPhone.

K dotykovému ovládání nejen nevidomý, ale i běžní uživatelé mají často averzi a odmítají jej. Překonají-li nakonec ostych a dotykové ovládání si vyzkouší, zjistí, že nejproblematičtější je psaní na softwarové klávesnici. Nutno říct, že právem a že psaní na dotykové klávesnici je pro zrakově postiženého v nejlepším případě o polovinu pomalejší - vyslechnutí správně trefeného znaku a jeho napsání. Jsou si toho dobře vědomi i tvůrci aplikací, které si dnes představíme a které se snaží přinést na dotykový displej iPhonu něco nového a rychlejšího.

Na začátek je nutno říci, že žádná z těchto aplikací v době psaní tohoto článku nepodporuje češtinu, ale pokud bude zájem ze strany našich uživatelů, může se to jistě změnit. Rovněž tak jisté nepohodlí je v tom, že se jedná o samostatné aplikace, v nichž se text napíše a potom pomocí schránky nebo vestavěných dialogů systému iOS pošle dále. iOS totiž neumožňuje rozšiřovat funkce integrovaných klávesnic.

Vestavěné metody VoiceOveru

Pro úplnost je vhodné zmínit, co v základu iPhone s aktivovaným Voice Overem nabízí. Obě metody tzv. standardního a dotykového psaní jsme už blíže rozvedli např. v článku iPad: standard přístupnosti dotykových zařízení - 3. díl, proto si jen uveďme, že přesnost trefení žádaného znaku a sledování odezvy odečítače, zda zaměřujeme správný znak, je právě to, co psaní činí pomalejším. S iOS nově 6 odpadla nutnost na znaku nějakou dobu setrvat, aby se napsal, přesto rychlost se rapidně snižuje, nejsme-li schopni trefit žádaný znak na první pokus a musíme provést korekční tah prstem na to správné místo na klávesnici.

Fleksy - Happy Typing: přibližná QWERTY klávesnice

Problém související s tím, že nevidomý se vždy na poprvé netrefí do žádaného znaku, se snaží vyřešit aplikace Fleksy. Tímto způsobem psaní může nevidomý dosáhnout srovnatelné rychlosti s běžným uživatelem. Jednoduše ťukáme na místa na displeji, kde si myslíme, že žádané znaky jsou. Na Fleksy potom je, aby vyhodnotila, co jsme měli na mysli. Vezmeme-li si ku příkladu slovo "ahoj", můžeme jít na to následovně:

a
zcela vlevo, ani nahoře, ani dole
h
někde uprostřed ve zhruba stejné linii s a
o
vpravo trochu od okraje, o něco více nahoře než h
j
podobně jako h, ale o trochu více vpravo

Slovo potvrzujeme vložením mezery gestem švihnutím doprava, při čemž se vysloví rozpoznané slovo. Jde-li o chybnou interpretaci, je možné šviháním nahoru a dolů vybírat z dalších zamýšlených slov.

Lze namítnout, že de facto metodu Fleksy již teď nabízí iOS 6 v integrované klávesnici, problém je však ve slovnících, které Fleksy pro svoji funkci potřebuje a které se jeví zatím jako kvalitnější než u integrované klávesnice v iOS. Navíc Fleksy dovoluje slovo korigovat i po napsání mezery, zatímco VoiceOver přítomnost automatických korektur oznamuje pouze zvukem a je na uživateli, aby si implicitně šviháním nahoru a dolů zkontroloval správnost korektury, kterou nelze po stisku mezery v prostředí iOS již odvolat. S Fleksy tedy děláme jen ty gesta, jenž jsou opravdu nutná, a tím vyniká ve své rychlosti.

Více viz Fleksy - Happy Typing.

Type Brailler Learn Braille: Dotykový Perkins

Jak už název napovídá, tato aplikace dovoluje na displeji iPhonu nejen psát v Braillu, ale i naučit se jej. iPhone je třeba držet na šířku, při čemž při psaní používáme obou rukou - z každé ruky vždy ukazováček, prostředníček a prsteníček. Před započnutím psaní je nutné ťuknout prsty pravé a poté levé ruky na displej, aby se správně nastavilo umístění jednotlivých kláves na virtuálním psacím stroji. Rozložení kláves odpovídá běžnému obouručnímu Pichtovu nebo Perkinsovu psacímu stroji, avšak prsty je potřeba mít na displeji poskládané zhruba do tvaru písmene V, protože displej není tak široký.

Umíme-li tedy Braillovo písmo, je psaní na takovém virtuálním psacím stroji rychlé, protože znak vkládáme současným ťuknutím příslušných prstů, jenž odpovídají bodům 1 až 6. Navíc jsou k dispozici gesta umožňující mazání a pohyb v textu a to bez toho, abychom postavení prstů museli měnit:

Pootočení pravým ukazováčkem a prostředníčkem
vložit mezeru
Pootočení levým ukazováčkem a prostředníčkem
smazat znak (Backspace)
Švihnutí pravým ukazováčkem
posunout kurzor vpravo
Švihnutí levým ukazováčkem
posunout kurzor vlevo

Aby všechna gesta psaní a pohybu byla správně rozpoznávána musí být vypnutý Voice Over, proto aplikace je samoozvučovací a mluví hlasem Alex, jenž je známý z prostředí OS X. Samozřejmě kromě samotného psaní je i ozvučené menu, kde na jednotlivé braillské body jsou namapovány různé funkce jako např. výuka základů Braillu, výuka braillské abecedy nebo test psaní. Funkce se spustí po poklepání na příslušné klávese. Test psaní zahrnuje i takové funkce jako napsání a vytočení telefonního čísla nebo jednoduchý kalkulátor.

Type Brailler Learn Braille je tedy všestrannou aplikací s propracovanými funkcemi, a tak její vývojář, pan Radomír Brúder, který nám zdarma poskytl k testování plnou verzi, si jistě zaslouží uznání. Přesto je zřejmé, že aplikace cílí na začátečníky a pro běžné každodenní použití je až příliš výřečná. Nebylo by tedy od věci vytvořit ořezanou verzi aplikace, jež bude určená jen ke psaní. Jistou nevýhodu v porovnání s ostatními prezentovanými metodami v tomto článku je nutnost zaměstnat při psaní obě ruce, což není prakticky použitelné v terénu.

Více viz Type Brailler Learn Braille.

TypeInBraille: Braill tvořený gesty

Braillovo písmo, jež by bylo možné psát i v terénu jednou rukou, nám představuje aplikace Type In Braille. Ze začátku tento způsob psaní vyžaduje trochu tréningu, protože přece jen nejde o standardní metodu, kterou by bylo možné začít ihned používat. Rovněž rychlost není zrovna silnou stránkou tohoto způsobu psaní, nicméně díky jednoduchým gestům se uplatní nejlépe právě v terénu.

Každý znak v závislosti na braillské reprezentaci tvoří dvě až tři gesta. Šestibod je rozdělen do tří dvojic po řádcích, tj. body 1-4, 2-5 a 3-6, při čemž zadáváme gesta postupně pro jednotlivé dvojice bodů tak, jak jsou ve znaku zastoupeny:

Klepnutí vlevo
ve znaku je přítomný levý bod (1, 2 nebo 3)
Klepnutí vpravo
ve znaku je přítomný pravý bod (4, 5 nebo 6)
Klepnutí dvěma prsty
ve znaku jsou přítomny oba body (1-4, 2-5 nebo 3-6)
Klepnutí třemi prsty
ve znaku není přítomný žádný z dvojice bodů
Švihnutí vpravo
ukončit znak a přejít na další

Příklad použití ukazuje následující tabulka pro napsání slova "auto".

ZnakBodyGesta
a1Klepnutí vlevo, švihnutí vpravo
u1-3-6Klepnutí vlevo, klepnutí třemi prsty, klepnutí dvěma prsty
t4-2-5-3Klepnutí vpravo, klepnutí dvěma prsty, klepnutí vlevo
o1-5-3Klepnutí vlevo, klepnutí vpravo, klepnutí vlevo

Aplikace dále nabízí gesta, kterými můžeme text editovat a manipulovat s ním:

Švihnutí vlevo
zrušit poslední zadávání znaku nebo smazat znak (Backspace)
Švihnutí dolů
Nový řádek
Švihnutí nahoru
Vyvolat menu s nabídkou funkcí pro odeslání textu
Točení dvěma prsty (rotor) = Přelaďování mezi vkládacím, navigačním a označovacím režimem

Je tedy vidět, že se jedná o metodu zadávání textu v zásadě jednoduchou. Vtip je v tom, abychom měli dobrou, až grafickou, představu o podobě jednotlivých znaků v Braillově písmu. Jedině tak budeme moci tvořit gesty text kdekoli a relativně rychle.

Více viz TypeInBraille.

Závěr

Tento článek měl za cíl představit tři alternativní různá řešení, jak je možné psát na dotykovém displeji iPhonu. Je zřejmé, že prostor na nové nápady tu je a že se mohou najít i budoucí řešení pro ty uživatele, kteří by s dotykovým displejem rádi začali, ale bojí se ho a chtějí si pro začátek zvolit způsob psaní, který bude nejbližší jejich požadavkům nebo bude připomínat to, co znají z dřívějška.

Autorem článku je Roman Kabelka.

Související odkazy

středa 14. listopadu 2012

Apple mapy v rovině technické přístupnosti zatím vedou nad těmi od Googlu

Zatímco podle ohlasů uživatelů by si nové Apple mapy zasloužily vysokoškolskou známku E, což znamená, že prošly s odřenýma ušima, či spíše F neboli totální propadák (fail), nevypadají z pohledu nevidomého tak tragicky. Apple totiž i nové mapy vyvíjel postupem sobě vlastním, tj. vyvojáři při jejich vývoji brali v potaz i přístupnost. Pojďme si tedy představit způsob, jak s mapami může pracovat nevidomý.

Samozřejmě i pro uživatele odečítací funkce VoiceOver je přesnost mapových podkladů klíčová. Na druhou stranu oblačné satelitní snímky, černobílé záběry a jiné grafické nedokonalosti jsou nevidomému srdečně jedno, proto prvotní zkušenosti s Apple mapami nemusí být tak odstrašující. Navíc je evidentní, že jde o pozitivní posun v přístupnosti oproti původním vestavěným Google mapám.

Sledování směru

Pokud najedeme prstem do dolního pravého rohu, měl by nám VoiceOver ohlásit tlačítko Nastavení. Gestem švihnutí jedním prstem vpravo najdeme tlačítko Sledování. Někdy se může stát, že tlačítka se na spodním okraji displeje neobjeví, v tom případě použíjeme gesto klepnutí čtyřmi prsty ve spodní části displeje pro přesun na poslední prvek a šviháme zpátky. Nebo též můžeme švihat doprava tak dlouho, až tlačítka nalezneme.

Tedy jestliže nám VoiceOver oznámil tlačítko Sledování, můžeme jej opakovaným poklepáním přepínat mezi třemi stavy:

  • Vypnuto: Nesleduje se poloha ani směr, kterým stojíme. Toto je vhodné pro prohlížení mapy na místě, jenž nesouvisí s aktuální polohou - typicky něco vyhledaného.
  • Zapnuto: Mapa odroluje na místo se současnou polohou a můžeme si prohlížet jeho okolí. Pokud šviháním doprava a doleva nalezneme na mapě značku se současnou polohou a vydáme se na cestu, bude VoiceOver oznamovat, kde se právě pohybujeme - typicky číslo domu, ulice a obec. Toto je vhodné pro případy, kdy potřebujeme dohledat konkrétní dům.
  • Zapnuto s indikací směru: VoiceOver automaticky oznamuje, na které ulici se nacházíme a k jaké se blížíme. Navíc se odemče rotace mapy, tudíž po vypnutí sledování je mapa orientovaná tak, jak stojíme - horní část displeje ukazuje to, co máme před sebou. Tento režim je vhodný pro případy, kdy oblast relativně známe a nechceme minout důležitou odbočku. Má ovšem nevýhodu v tom, že skrze VoiceOver nelze mapu prohlížet, proto je nutné sledování pro prohlížení vypnout.

Navigace

Pokud opět vyjdeme z pravého dolního rohu a šviháme až k tlačítku Trasa, jenž potvrdíme, můžeme zadat začátek a konec trasy. Kromě napsání adresy lze napsat i název záložky nebo jméno kontaktu, u kterého máme uloženou polohu. Též stačí zadat jen několik písmen a vybrat si poklepáním položku ze seznamu v pravé části displeje nad zobrazenou klávesnicí. Ponecháme-li pole Začátek prázdné, vezme se současná poloha.

Druhou možností je, že vyjdeme opět od tlačítka Nastavení a šviháme doleva až k tlačítku Záložky. Po poklepání na něm můžeme na dolním okraji displeje přepínat mezi třemi seznamy - Záložky, Historie a Kontakty. Na panelu Historie můžeme již předvybrat trasu, kterou jsme v minulosti absolvovali. Pokud si vybereme některý z kontaktů nebo záložek a poklepeme na ně, objeví se mapa daného místa, přes kterou je překryt tzv. informační popup. Pokud poklepeme kamkoli mimo něj, dostaneme se do mapy. Popup má prozatím tu nepříjemnou vlastnost, že se v něm nelze orientovat šviháním vlevo a vpravo a musíme jej tak najít jetím po displeji od horní části displeje až k popupu. Je nutné jet prstem relativně pomalu, protože se jedná o úzký proužek ve středu displeje. V levé části je název místa a vpravo tlačítko Další informace. Pro aktivování tohoto tlačítka je praktické využít tzv. rozdělené klepnutí, kdy jedním prstem si držíme tlačítko a druhým přiklepneme. Na obrazovce s detailem o místě jsou dvě důležitá tlačítka - Navigovat sem (ze současné polohy do vybraného místa) a Navigovat odsud (z vybraného místa do současné polohy).

Na obrazovce s trasou si poklepáním na příslušném přepínači můžeme vybrat mezi navigací autem, pěšky a veřejnou dopravou. Též si zde můžeme vybrat některou z alternativních tras. Chceme-li si vybranou trasu prohlédnout ještě před vyražením na cestu, lze zobrazit detail trasy poklepáním na tlačítko ZObrazit jako seznam, které je nejsnáže přístupné tak, že klepneme čtyřmi prsty v dolní části dospleje a dostaneme se na poslední ovládací prvek. Tento seznam instrukcí pro navigaci si můžeme přečíst obvyklými gesty VoiceOveru.

Pokud máme vše nastaveno, vyrazíme na trasu a poklepeme na tlačítko Start. V závislosti na zvoleném druhu navigace se řídíme instrukcemi následovně:

  1. Trasa veřejnou dopravou: Objeví se nabídka alternativních aplikací pro navigaci, neboť tento druh navigace není v České republice podporován.
  2. Trasa autem: Na iPhonu 4S a iPhonu 5 se řídíme podle instrukcí, které nám v pravý čas VoiceOver řekne. Můžeme tento způsob použít i pro pěší navigaci, avšak jsou zohledňovány jednosměrky, cíl je hlášen instrukcí k zastavení v relativně velkém okruhu (cca 50 m) a pokyny pro zabočení nejsou oznamovány tak vhodně, jak při větší rychlosti v autě - např. mohou být oznámeny až po zabočení nebo po minutí ulice.
  3. Trasa pěšky: Musíme se přesunout nejprve šviháním vlevo a vpravo na pole instrukcí, v němž přecházíme mezi jednotlivými kroky šviháním nahoru a dolů. Někdy dojde k automatickému přejití na další krok, ujdeme-li daný úsek, nelze se ovšem na to spoléhat a VoiceOver změnu nehlásí, i když je zaměřen na poli instrukcí. K samotnému listování instrukcí musíme mít tedy zapnuté ještě sledování směru a to během cesty s indikací směru a v cílové ulici sledování současné polohy.

Až dojdeme do cíle nebo přejeme-li si navigaci předčasně ukončit, poklepeme na tlačítko Konec v levém horním rohu.

Audioukázka

Poslechněte si reportáž z navigování (mp3; 7,6 MB).

Prohlížení mapy

Mapu s aktivním VoiceOverem si můžeme prohlížet až překvapivě jednoduše a poměrně srozumitelně. Běžně při horním okraji displeje je sever, dole jih atd. Je-li mapa orientovaná jinak, dozvíme se to tak, že z tlačítka Nastavení švihneme jednou doleva a tam při změněné orientaci je tlačítko kompasu s informací o orientaci mapy. Poklepeme-li na kompas, zmizí a mapa se přeorientuje na sever.

Klepnutím třemi prsty se dozvíme, jakou oblast mapy vidíme a jak je tato oblast velká. Záběr můžeme měnit tak, že rotor točením dvěma prsty přeladíme na hodnotu Zvětšení a potom šviháním nahoru a dolů měníme měřítko. Menší měřítko sice umožňuje větší záběr, ale snižuje se zároveň schopnost cesty VoiceOverem sledovat, nehledě na to, že některé méně důležité cesty jsou zcela zamlčeny pro množství detailů. Potřebujeme-li prohlížet část mapy mimo viditelnou oblast, potáhneme třemi prsty mapu daným směrem - tj. chpro odkrytí toho, co je za horním okrajem displeje, potáhneme mapu třemi prsty dolů. Mapa se vždy neposune o celou délku displeje v daném směru, ale zhruba o polovinu, což nedovoluje ztratit návaznost v prozkoumávání.

Šviháme-li vlevo a vpravo, můžeme si projít všechny místa, které aktuální výsek mapy zobrazuje. Při poklepání na vybraném místě zobrazíme informační popup, o němž jsme se zmínili dříve. Pravé kouzlo v prohlížení je ovšem v tom, že můžeme jet prstem po displeji a VoiceOver bude říkat, co právě máme pod prstem. U rovných cest navíc říká, odkud kam cesta vede, což se hodí pro její další sledování. Pokud totiž na cestě prst podržíme a VoiceOver říká, že se jedná o severojižní silnici, víme, že při tažení prstu z vrchu dolů budeme cestu sledovat. Při sledování cesty a tažení prstu se ozývá zvuk indikující, zda dodržujeme správný směr. V případě, že se prst od cesty vzdaluje, zvuk má vyšší tón. Tímto způsobem můžeme poměrně dobře sledovat zakřivení cesty , její orientaci a místa, v kterých se protíná s jinými cestami. VoiceOver reaguje až příliš aktuálně, což má za následek, že křižovatku přečte jen ve chvíli, kdy na ní tažený prst zastavíme.

Videoukázka

Hodnocení

Apple mapy z hlediska přístupnosti přinášejí nové funkce oproti Google mapám pro iOS - zejména při prohlížení mapy. Nelze je ovšem zatím příliš prakticky využít pro pěší navigaci, která je pro nevidomé nejdůležitějším způsobem navigace, jenž by byl využitelný při samostatném pohybu. Prozatím tedy pro samostatný pohyb je praktičtější sáhnout po některé z ověřených navigací v AppStore, byť Apple mapy mohou být vhodným doplňkem pro zorientování se na daném místě.

Autorem článku je Roman Kabelka.

Související odkazy

pondělí 12. listopadu 2012

DevFest Praha 2012 se vydařil

DevFest 2012

Výborná atmosféra, skvělí lidé, networking, zajímavé prezentace a tak vůbec. Pro mě velmi příjemná tečka za letošními konferenčními a jinými akcemi, kterou jsem opouštěl maximálně spokojený.

Přístupnost

Když mě na konci září oslovil Pavel Vybíral s nabídkou zúčastnit se DevFestu jako přednášející a seznámit účastníky s tématikou přístupnosti, byl jsem opravdu potěšen. Docela rychle jsme se domluvili na tématu, kterým bylo letos ještě mnou nikde neprezentované téma přístupnosti HTML5 a WAI-ARIA. Jedná se o téma široké, které nebylo možné v 45 minutách detailně projít, takže jsem je pojal jako úvod do této tématiky s ukázkami některých konkrétních věcí, které už dnes fungují a je možné je používat a motivovat účastníky k jejich používání při běžné praxi. Snad se mi to povedlo - soudě aspoň podle množství dotazů, na které jsem odpovídal ještě půl hodiny po přednášce v předsálí.

Slajdy k mé prezentaci HTML5 v kombinaci s WAI-ARIA

Accessibility CodeLab, který jsme měli společně s Pavlem Ondrou, šéfem GDG Accessibility Brno, nebyl nakonec stánek, ale prostor pro hodinový workshop v samostatné místnosti. Toto řešení se nakonec ukázalo jako velmi dobré a s Pavlem jsme celou dobu diskutovali s účastníky o všem možném kolem přístupnosti a nebýt toho, že jsme museli v 13:20 skončit, abychom všichni stihli oběd, povídali bychom si tam určitě mnohem déle.

Hodně mě potěšil velký zájem o přístupnost - byl jsem velmi mile překvapen tím, kolik účastníků přišlo na prezentaci, Accessibility CodeLab či si o přístupnosti jen tak popovídat. Díky za zájem!

Organizace

Organizační tým byl skvěle sehraný (aspoň co jsem měl možnost sledovat v místnosti se zázemím pro přednášející ;-) a organizace celé akce šlapala na výbornou. Rád bych organizátorům poděkoval za to, jaký prostor přístupnosti na DevFestu věnovali.

Prezentace

Protože s našimi aktivitami kolem přístupnosti jsme skončili v půl druhé a pak šli s Pavlem na oběd, stihli jsme až odpolední prezentace. Z nich mě nejvíce zaujalo povídání Víta Vrby o jeho failech a úspěších - prezentace formou "cesty tam a zase zpátky" byla super - a Kuby Čížka (asi se dám na mapování Wi-Fi sítí v Bystrci ;)

A celkový dojem?

Z Prahy jsem odjížděl odjížděl unavený, ale spokojený. Ve vlaku jsem ještě doplnil textový komentář ke slajdům, lehce poladil jejich vzhled na základě zpětné vazby od Jeanne Trojan (díky!) a protože jsem to zvládl docela rychle, tak jsem si stihl i 30 minut zdřímnout ;-)

Tož tak.

Na DevFestu 2013 ahoj.

P.S. Pokud pořádáte nějakou podobnou akci a měli byste zájem o prezentaci tématiky přístupnosti, dejte vědět. Určitě se domluvíme. Jo a kdybyste mě chtěli odměnit tričkem, mám velikost XXL ;-)

Související odkazy

pátek 9. listopadu 2012

Apple jako kompenzační pomůcka pro zrakově postižené - 8. díl

Efektivnější vyčítání oken a textu

V minulém díle jsme si ukázali základní příkazy pro pohyb VoiceOver kurzoru, které si dnes shrneme a doplníme o další zpříjemňující práci. Rovněž přijdou na řadu příkazy umožňující se zorientovat v tom, kde se právě nacházíme a jak se pohybovat v textových polích.

Rychlá navigace a další užitečné příkazy

Abychom při navigaci VoiceOver kurzoru spolu se šipkami nemuseli stále stiskávat klávesy VO (Ctrl+Alt), existuje režim rychlé navigace, na který si rychle zvykneme. Přepíná se soustiskem levé a pravé kurzorové šipky a stačí poté stiskávat pouze šipky. Následující tabulka ukazuje příkazy pro VoiceOver kurzor, které mají alternativu v rychlé navigaci:

PříkazBez rychlé navigaceS rychlou navigací
Přesunout VoiceOver kurzor na další prvekVO+Šipka dopravaŠipka doprava
Přesunout VoiceOver kurzor na předchozí prvekVO+Šipka dolevaŠipka doleva
Přesunout VoiceOver kurzor na další prvek daného typuVO+Šipka dolůŠipka dolů
Přesunout VoiceOver kurzor na předchozí prvek daného typuVO+Šipka nahoruŠipka nahoru
Zahájit interakci s prvkem pod VoiceOver kurzoremVO+Shift+Šipka dolů Šipka dolů+Šipka doprava
Ukončit interakci s prvkem pod VoiceOver kurzoremVO+Shift+Šipka nahoru/td>Šipka dolů+Šipka doleva
Aktivovat (stisknout) prvek pod VoiceOver kurzoremVO+MezerníkŠipka nahoru+Šipka dolů

Když už uvádíme výčet příkazů, zmíníme si i ty, které nás v rámci zkoumané oblasti VoiceOver kurzorem přesouvají po menších či větších úsecích:

Přejít mírně daným směrem (VO+Shift+Šipka doleva, VO+Shift+Šipka doprava):
Tyto příkazy umožňují v textových polích pohyb VoiceOver kurzoru po znacích textu.
Přejít na viditelný začátek (VO+Home) a viditelný konec (VO+End):
Přesune VoiceOver kurzor na první, rresp. poslední,, prvek v aktuálním řádku tabulky či textu.
Přejít na začátek (VO+Shift+Home):
Přesune VoiceOver kurzor na první prvek aktuální oblasti interakce - např. v tabulce se přesune na buňku v prvním řádku a prvním sloupci.
Přejít na konec (VO+Shift+End):
Přesune VoiceOver kurzor na poslední prvek aktuální oblasti interakce - např. na tlačítko OK ve spodní části dialogového okna.
Výběr položek (VO+I):
vyvolá menu se všemi položkami aktuálního okna, v němž lze vybrat položku šipkami či obsaženými písmeny a Enterem na ni VoiceOver kurzor přesunout. Více viz o výběrových nabídkách později v podkapitole o přepínání aplikací a oken.

Pozor na to, že na většině Apple klávesnic je nutné namísto Home stisknout kombinaci FN+šipka doleva, namísto Page Up FN+Šipka nahoru apod.

Rotor

V tuto chvíli se pozastavme u příkazů pro přechod VoiceOver kurzoru na další a předchozí prvek daného typu. To, po jakých prvcích šipky nahoru a dolů přechází, záleží na nastavení tzv. rotoru. Rotor přelaďujeme (přepínáme) při zapnuté rychlé navigaci vpřed soustiskem horní a pravé kurzorové šipky a vzad soustiskem horní a levé kurzorové šipky. Význam rotoru plně doceníme až v oblastech webového obsahu, proto jej zde zmiňujeme jen pro úplnost, jak lze VoiceOver kurzor ovládat.

Mimo oblasti webového obsahu je možné rotor přelaďovat mezi navigací a pohybem po znacích a slovech. Pro běžnou práci v oknech aplikací je ovšem vhodné mít rotor naladěn na volbě Navigace, neboť ta šipkám nahoru a dolů dává kýženou a očekávanou funkci - to jest např. v tabulkových seznamech šipky nahoru a dolů přechází mezi řádky.

Informace o aktuální pozici

V jakoukoli chvíli při aktivovaném VoiceOveru si můžeme ověřit, kde v systému se nacházíme, jak jsou zaměřené jednotlivé kurzory a co je vybráno. Tyto informace zjíšťujeme pomocí funkčních kláves F1 až F6 v kombinaci s klávesami Vo a mají následující význam:

VO+F1
Přečte název aplikace v popředí
VO+F2
Přečte název aktuálního okna v popředí
VO+F3
Popíše prvek pod VoiceOver kurzorem
VO+F4
Popíše prvek zaměřený fokusem
VO+F5
Popíše prvek zaměřený ukazatelem myši
VO+F6
Přečte vybraný text či vybrané položky v seznamu

Přestože VoiceOver kurzor a fokus se navzájem následují, jak jsme si již říkali, nedávají příkazy pro popsání pozice VoiceOver kurzoru a fokusu vždy stejnou odpověď. Je to zapříčiněno již známým faktem, že fokus se nedostane na všechny prvky, na které VoiceOver kurzor,, proto k jejich svázání dochází jen na prvcích, které jsou schopny oba kurzory zaměřit.

Hlášení o popisovaných prvcích se mohou poměrně dosti lišit v závislosti na tom, jaký prvek je zaměřen. Nebudeme si blíže tyto hlášení rozebírat, neboť jsou v zásadě srozumitelná. Stojí pouze za zmínku, že pokud VoiceOver kurzorem nebo fokusem je zaměřeno textové pole, je popsána pozice i textového kurzoru (ukazatele). Dále při popisování položky pod VoiceOver kurzorem je i přečten nápovědný text říkající jak s prvkem pracovat. Tento nápovědný text je možné si kdykoli nechat přečíst pomocí klávesové zkratky VO+Shift+N, popř. je čten automaticky při nejvyšší podrobnosti čtení.

Jestliže funkční klávesu patřící danému kurzoru stiskneme dvakrát, dozvíme se dodatečné informace o prvku či pozici. Je-li např. VoiceOver kurzor v textovém poli, můžeme stiskem VO+F3,F3 zjistit, kolik řádků text má a kolik jich je viditelných.

Pohyb v textu

Když už jsme u textových polí, pojďme si říci, jak se pohybovat v textu. Přestože několik rozdílů najdeme, není na práci s textem v prostředí OS X zásadně nic jiného oproti Windows. Zde je srovnávací tabulka funkcí pro pohyb v textu, které oba systémy nabízí:

FunkceWindowsMac
Posunout kurzor o znakŠipka doleva/dopravaŠipka doleva/doprava
Posunout kurzor o slovoCtrl+Šipka doleva/dopravaAlt+Šipka doleva/doprava
Posunout kurzor na okraj řádkuHome/EndCMD+Šipka doleva/doprava
Posunout kurzor o řádek a optimálně zachovat sloupecŠipka nahoru/dolůŠipka nahoru/dolů
Posunout kurzor o odstavecCtrl+Šipka nahoru/dolůAlt+Šipka nahoru/dolů
Posunout kurzor o obrazovkuPage Up/DownAlt+Page Up/Down
Posunout kurzor na okraj celého textuCtrl+Home/EndCMD+Šipka nahoru/dolů

Musíme si dát pozor na to, že při aktivní rychlé navigaci VoiceOveru je nutné před započetím pohybu v editačním poli zahájit s polem interakci. Rovněž musíme počítat s tím, že rychlá navigace mění význam kurzorových šipek, protože ty pohybují přímo s Voiceover kurzorem. V praxi to znamená, že v textu je základním prvkem pro pohyb VoiceOver kurzoru slovo. Při aktivní rychlé navigaci tedy je nutno používat pro pohyb po znacích již zmíněné klávesové zkratky VO+Shift+Šipka doleva/doprava. Na první pohled se může zdát primární navigace šipkami doleva a doprava po slovech nezvyklá, má však svoji logiku ve smyslu širšího záběru okolního kontextu než jsou znaky.

Ještě jednu, avšak nesporně větší, nezvyklost přináší VoiceOver při odezvě pohybu v textu. V základním nastavení nečte totiž text, který je vpravo od kurzoru, ale text, přes který při pohybu kurzor přešel. Prakticky to má dopad takový, že si musíme dobře uvědomit, na jakém konci vysloveného úseku textu (znaku či slova) se kurzor nachází. Při pohybu vpřed je kurzor umístěn za ním, zatímco při pohybu vzad před ním. De facto to odpovídá režimu čtení, jenž používají odečítače ve Windows pouze při označování a odznačování textu. Je dobré si na tuto vlastnost zvyknout, neboť VoiceOver v systému iOS vyčítá změny pozice kurzoru stejně a toto chování nelze na mobilních zařízeních v současné době přenastavit.

Podcast

V podcastu k dnešnímu dílu si nejprve napíšeme v editoru TextEdit krátký text a odzkoušíme funkce pro přečtení aktuální pozice. Dále si procvičíme práci s rychlou navigací a obecně práci s uživatelským rozhraním. Poslouží nám k tomu utilita VoiceOver, kde si přenastavíme vyslovování číslic a to, aby VoiceOver četl text vpravo od kurzoru a nikoli text, přes který kurzor přechází.

Podcast ke stažení ve formátu mp3 (12,3 MB)

Autorem článku a podcastu je Roman Kabelka.

Další díly seriálu

úterý 6. listopadu 2012

HTML5 a WAI-ARIA na DevFest Praha 2012

DevFest 2012

Letošní koncertní - totiž prezentační, pardon - šňůru zakončím na vývojářském festivalu DevFest Praha 2012. Organizátoři mě požádali, abych přispěl do programu tématikou přístupnosti a z mnou nabídnutých možností si vybrali právě přístupnost HTML5 v kombinaci s WAI-ARIA. Musím přiznat, že to od nich byla dobrá volba, protože na toto téma jsem ještě letos nepřednášel, takže prezentace bude nová, neokoukaná a neoposlouchaná ;) A ještě z toho bude článek pro Zdroják ;-)

Pro koho to bude?

Pro všechny, kdo používají - či se chystají používat - HTML5 a rádi by při tvorbě webů a aplikací brali na zřetel i přístupnost.

O čem to bude a co si z přednášky odnesete?

Na několika praktických příkladech si ukážeme, jak jednoduše můžeme pomocí WAI-ARIA zlepšit přístupnost HTML kódu. Ukážeme si, jak lépe strukturovat obsah, vytvořit přístupné formuláře a ošetřit dynamické změny obsahu.

Nedělám si ambice účastníky přednášky za 45 minut naučit HTML5 (na to vám mohu doporučit třeba Martina Michálka), ale chtěl bych vám poskytnout praktické rady a doporučit, jaké techniky pro zpřístupnění můžete už dnes bez obav používat.

Accessibility CodeLab

Kromě prezentace budeme mít s Pavlem Ondrou i Accessibility CodeLab - pokud Vás tématika přístupnosti zajímá, přijďte si o ní popovídat či si nechat otestovat nějaké své řešení. Těšíme se na vás.

Jestli zvažujete, zda se přístupností zabývat, a nejste si úplně jisti, zda je pro vás přístupnost atraktivní, projděte si slajdy k mé prezentaci Přístupnost není charita z letošního WebExpa. Obsahuje několik příkladů ze života a také případových studiích o tom, jak je přístupnost velmi úzce provázána s dalšími oblastmi webu a jak pomáhá skutečně všem uživatelům.

pátek 2. listopadu 2012

INSPO 2013: Call for papers pro sekci Přístupnost (nejen) webu

Nabízíte nějakou zajímavou službu, web nebo aplikaci pro neziskovky či uživatele se zdravotním postižením a chcete ji veřejně představit? Pokud ano, pak čtěte dále ;-)

Stejně jako letos, budu mít i příští rok na konferenci INSPO na starost sekci Přístupnost (nejen) webu. Konference INSPO - Internet a informační systémy pro osoby se specifickými potřebami je zaměřena na na využití Internetu a informačních technologií ve prospěch lidí se zdravotním postižením. Každoročně se jí zúčastní přibližně 300 účastníků z řad osob s těžkým zdravotním postižením a zástupců neziskovek.

Momentka z odpoledního jednání v sekci Přístupnost nejen webu. Fotil Ivan Navrátilík.

Co bych potřeboval?

Prakticky zaměřenou prezentaci (v publiku budou sedět v drtivé většině koncoví uživatelé služby), na které ukážete, k čemu je vaše služba dobrá, v čem spočívají její výhody a jak může uživatelům usnadnit život.

Co mohu nabídnout?

  • Možnost publikovat článek ve sborníku,
  • přibližně 25 minut k prezentování,
  • oběd,
  • nějaký drobný dárek od některého ze sponzorů konference. Doufám, že budou - dárky i sponzoři ;) Letos přednášející dostali 4 GB flash paměť.

Pokud tedy máte téma, kterým byste chtěli tuto cílovou skupinu oslovit, neváhejte a své návrhy, prosím, pište do komentářů nebo na můj mail. Rád také zodpovím případné dotazy.

Předpokládám a doufám, že stejně jako letos se mi sejde nápadů spousta a že budu mít z čeho vybírat. Na konferenci se dostane jen přibližně 7 nejlepších. Děkuji za pochopení.

Těším se na Vaše návrhy.

čtvrtek 1. listopadu 2012

WebAIM vydal betaverzi nástroje WAVE5 pro testování přístupnosti

Po otestování Accessibility Checkeru v MS Wordu 2010 jsem tento týden vyzkoušel i další testovací nástroj - betaverzi WAVE5 od WebAIMu. K dispozici je zatím i původní verze na adrese wave.webaim.org, takže si je v případě zájmu můžete i porovnat.

Novinky ve verzi 5

  • Postranní panel, umožňující interakci s výsledky, které Vám WAVE5 poskytne.
  • Vylepšen je i systém hledání potencionálních problémů v přístupnosti tak, aby WAVE5 poskytoval co možná nejlepší zpětnou vazbu a výsledky co nejlépe odpovídaly potřebám koncového uživatele.
  • Spousta nových ikonek, informujících například o odkazech, kterým chybí zvýraznění focusu, chybějící definici primárního jazyka dokumentu, HTML5 a ARIA značkách, atp.
  • Nástroj pro testování kontrastu založený na WCAG 2.0 AA. Zde jsem využil aktuálního beta testování a zeptal se, zda je v plánu umožnit i výběr barev pro porovnání přímo z webové stránky - tak, jako to má třeba Colour Contrast Analyser. Ještě dnes jsem dostal pozitivní odpověď - doplnění této funkcionality je na to-do listu.
  • Možnost filtrovat výsledky podle WCAG AA, WCAG A a Section 508.
  • Možnost zobrazit si kód stránky přímo během testování. Pokud Vás zajímá, jak je konkrétní věc, na kterou WAVE5 upozorňuje nakódována, stačí kliknout na ikonku, která na potencionální problém upozorňuje a ve spodní části se okamžitě zobrazí konkrétní část kódu.
  • Vylepšená dokumentace, díky níž se během používání WAVE5 dozvíte spoustu věcí o přístupnosti webu.

Mně osobně WAVE5 přijde jako velký krok kupředu a pokud WebAIM zapracuje i další věci (například onu zmiňovanou možnost testovat kontrast barev), asi pomalu nebudu mít potřebu používat k testování nic jiného ;-)

Tak si jej také vyzkoušejte.

WAVE5 - web accessibility evaluation tool

Související odkazy

středa 31. října 2012

Automatická kontrola přístupnosti dokumentu v MS Wordu 2010

Přístupnost dokumentů je v současnosti stále trochu opomíjené téma. S jejich narůstajícím počtem je ale zřejmé, že i jejich přístupnosti bude třeba věnovat pozornost. A to minimálně stejnou, jako přístupnosti webu.

Vzhledem k jejich množství bude třeba kontrolu jejich přístupnosti nějakým způsobem zautomatizovat, protože není možné manuálně testovat každý dokument. Manuální kontrola je s ohledem na dnes běžně publikovaný počet dokumentů nereálná a tak chtě nechtě (byť s tím ještě nejsem vnitřně úplně ztotožněn), přichází ke slovu automatická kontrola. Ta sice nemusí odhalit všechny nedostatky, ale může autorovi - nebo tomu, kdo přístupnost dokumentu kontroluje - pomoci pohlídat některé věci, které by mu při manuální kontrole mohli uniknout. Automatická kontrola vyžaduje zodpovědnou interpretaci výsledků - což bohužel nebývá vždy pravidlem a zde právě vidím jedno ze slabých míst tohoto způsobu testování.

Přístupnost dokumentu by dle mého názoru měla být v první řadě starost jeho autora. Pokud autor na přístupnost myslí už při tvorbě dokumentu, neměl by být výsledkem testu přístupnosti nijak zaskočen. Skutečnost je ale taková, že autoři bohužel často nemají dostatečné znalosti, jak přístupné dokumenty tvořit (a občas mi přijde, že můžeme vynechat i to přídavné jméno přístupné) a dokumenty mnohdy vypadají, jako by je někdo napsal na psacím stroji - v dokumentu chybí strukturování, textové alternativy, je plný nadbytečných formátovacích znaků, mezer, atp. Což jsou všechno věci, které přístupnost dokumentu hodně komplikují.

Reklamní vsuvka: Jednou z možností, jak potřebné znalosti získat, je třeba naše Školení tvorby přístupných dokumentů.

Accessibility checker (Zkontrolovat usnadnění)

Microsoft Word nabízí pro automatickou kontrolu jednoduchý nástroj, který umožní zkontrolovat některé (ale zdaleka ne všechny) potencionální problémy s přístupností. Zatímco v anglické verzi se nástroj pro kontrolu přístupnosti jmenuje poměrně výstižně - Accessibility Checker, česky byl tento nástroj pojmenován ne úplně intuitivně jako Zkontrolovat usnadnění. Najdeme jej pod položkou Soubor - Informace - Zkontrolovat problémy - Zkontrolovat usnadnění.

Co vše Accessibility Checker kontroluje?

Jak už jsem zmínil výše, Accessibility Checker otestuje některé vybrané problémy technického charakteru, které mohou působit potíže s přístupnosti. Nalezené (potencionální) problémy jsou rozděleny do tří skupin: chyby, varování a tipy.

Chyby

Jedná se o zásadní nedostatky, které mohou práci s dokumentem výrazně zkomplikovat. Pokud uživatelům nechcete komplikovat život, pak

  • všem objektům přiřaďte relevantní textovou alternativu.
  • V tabulkách korektně vyznačte záhlaví sloupců.
  • Rozsáhlých dokumentech strukturujte pomocí stylů.
Varování

Problémy, vyznačené jako varování, mohou uživatelům působit při práci s dokumentem potíže. Accessibility checker vás proto upozorní, pokud porušíte některé z následujících pravidel:

  • odkazy mají smysluplné textové popisky.
  • Tabulky mají jednoduchou strukturu (tzn. tabulky jsou obdélníkové tabulky bez sloučených buněk, rozdělených buněk nebo vložených tabulek).
  • V tabulkách nejsou prázdné řádky nebo sloupce.
  • V dokumentu nejsou použity řetězce prázdných znaků (například mezer či tabulátorů).
  • Nadpisy nejsou příliš dlouhé.
  • Na stránkách nejsou použity plovoucí objekty.
Tipy

Následující návrhy, zařazené ve skupině tipy, neřeší přímé problémy s přístupností, ale mohou pomoci přístupnost ještě více zlepšit.

  • Vložený audio nebo video záznam obsahuje skryté titulky.
  • Pokud jsou použity tabulky pro rozvržení obsahu na stránce, pak jsou strukturovány tak, aby nekomplikovaly navigaci.
  • V dokumentu nejsou použity vodoznaky.
  • V dokumentu je dodržena hierarchie nadpisů.

Úskalí nástroje aneb na co si dát pozor

Jistě by se dalo polemizovat o zařazení toho kterého pravidla do konkrétní skupiny - ze stávajícího návrhu je zřejmé cílení nástroje na kontrolu požadavků primárně na nevidomé uživatele - ale i přesto platí, že jakýkoliv nástroj, který může pomoci zlepšit přístupnost, je dobrý.

Stejně tak překlad pravidel do češtiny není v některých případech moc srozumitelný, proto jsem do části Související odkazy v závěru tohoto příspěvku zařadil i odkazy na anglické stránky k tomuto nástroji.

Je třeba také mít na paměti, že nástroj kontroluje technickou stránku věci - tzn. je schopen například zjistit, zda v dokumentu používáte styly pro nadpisy, ale už není schopen zjistit, zda nadpisy jsou smysluplné či výstižné.

Všechna tato omezení je třeba mít při práci s nástrojem na paměti, jinak to nebude dobrý sluha, ale zlý pán ;-)

Jak probíhá kontrola

Po spuštění nástroje dojde k otestování přístupnosti. V pravé části okna je zobrazen panel Kontrola usnadnění a v něm se zobrazí Výsledky kontroly. Pokud se zde nějaké Chyby, Upozornění či Tipy objeví, je třeba jim věnovat pozornost a případné problémy vyřešit. Nástroj pracuje on-the-fly, tzn. pokud si necháte panel Kontroly usnadnění otevřený a budete chyby přímo opravovat, nástroj bude na vaše úpravy reagovat a pokud vaším zásahem dojde k odstranění chyby, Accessibility checker na Vaši opravu hned zareaaguje a upozornění na chybu zmizí.

Videoukázka

Až tedy příště napíšete nějaký dokument ve Wordu, nechte si jej tímto nástrojem zkontrolovat a opravte případné chyby, na které Vás tento nástroj upozorní. I přesto, že nástroj má své limity, může Vám pomoci dokument lépe zpřístupnit.

Nástroj Accessibility checker (Zkontrolovat usnadnění) lze použít i v dalších programech MS Office, konkrétně v Excelu a PowerPointu.

Související odkazy

úterý 30. října 2012

5 let POSLEPU

Přesně před 5 lety jsem napsal první příspěvek na tento blog. Ještě nebyl o přístupnosti - jednalo se o takové symbolické vykopnutí a zkoušku sebe sama, zda se do psaní vůbec pustím (nejhorší je začít, pak už to většinou jde samo ;). Od té doby se na POSLEPU objevilo 230 příspěvků, zaměřených na tématiku přístupnosti webu, kompenzační pomůcky a asistivní technnologie pro uživatele se zrakovým postižením. Ty jsem napsal buď sám, nebo někdo z kolegů (druhým nejaktivnějším přispěvatelem je Roman Kabelka).

Protože mě zajímalo, které příspěvky byly nejčastěji zobrazované a pro čtenáře nejatraktivnější, tak jsem kouknul do Google Analytics a zjistil toto:

  1. Eliška - další kvalitní český hlas
  2. Přístupnost internetového bankovnictví - ČSOB Internet Banking 24
  3. Jak přístupně strukturovat webovou stránku pomocí nadpisů – praktický návod
  4. Je definování velikosti písma v pixelech stále ještě vážný problém?
  5. Zuzana - nový český hlas

Jak už to tak bývá, tak "vyhrál" příspěvek, který mi ani nedal moc práce - jedná se vlastně jen o stručné upozornění na existenci syntézy Infovox Desktop s českým hlasem Eliška.

Z hlediska ocenění lze za nejúspěšnější rok považovat rok 2009, kdy jsem si do sbírky přidal hned dvě ceny. První za nejlepší blog neziskové organizace, kterou jsem obdržel na konferenci Online marketing pro neziskovky, druhou pak bylo 3. místo v kategorii děl uveřejněných na internetu v soutěži Cena vládního výboru pro zdravotně postižené občany.

V roce 2010 jsem pak k blogu přidal i YouTube kanál POSLEPU, na kterém najdete videoukázky práce s webem a asistivními technologiemi. Nejvíce zobrazení má video, v němž Roman Kabelka prakticky předvádí jak se programuje poslepu.

Ačkoliv by se zdálo, že v přístupnosti už není za ty roky co řešit, opak je pravdou a přístupnost je dnes možná ještě větší výzvou, než před těmi cca 12 lety, kdy jsme s ní tady začínali.

Zatímco tenkrát byl web jen "text, odkaz, obrázek a sem tam nějaký jednoduchý formulář" a asistivní technologie toho z dnešního pohledu moc neuměly (o nějaké práci s nadpisy si mohli nevidomí nechat jen zdát), dnes je web multimediální prostor, kde se můžeme setkat prakticky s jakýmkoliv typem obsahu. Jsou zde dynamické webové aplikace, dokumenty, formuláře, obsah tvořený uživateli, atp. A to vše by rádi používali i lidé se zdravotním handicapem, protože web je prakticky jediné místo, kde mohou řadu činností vykonávat samostatně a nemusí se spoléhat na pomoc někoho druhého. Zlepšují se asistivní technologie, objevují se nové pomůcky či postupy, jejichž cílem je kompenzovat nějaký druh postižení.

Rozhodně je tedy stále co testovat, o čem psát a co se snažit zlepšovat. Nejméně dalších pět let ;)

Čtenářům POSLEPU přeji spoustu zajímavých a informačně bohatých příspěvků, kolegům, kteří na blog příležitostně píší, pak hodně inspirace (aby psali ještě víc ;-) a ať jim jde (a mně taky ;) psaní od ruky ;-)

A vám všem DÍKY - jsem rád, že POSLEPU čtete.

pondělí 29. října 2012

Nevidomí a dotykové ovládání poslepu

V polovině října jsem zde publikoval svou reakci na reportáž České televize "Opravdu jsou nevidomí z dotykových displejů bezradní?". Svůj příspěvek jsem zakončil pozváním redaktorů ČT k nám do Brna, pokud by chtěli natočit reportáž o tom, jak je to s dotykovým ovládáním poslepu ve skutečnosti.

Zatím nikdo nepřijel, ale už to možná ani nebude třeba, protože s rozumnou a realitě odpovídající reportáží o dotykovém ovládání poslepu včera přišlo Živě.cz v reportáži Týden Živě 199: Jak používá tablet nevidomý. Hostem Jakuba Čížka byl můj kolega Roman Kabelka, kterého určitě z POSLEPU znáte a který v reportáži pěkně popovídal o přístupnosti, znovu zmínil i některá úskalí dotykových displejů (ne každému mohou vyhovovat) a na závěr na několika příkladech prakticky předvedl, jak pracuje s iPadem.

Tak se na to mrkněte, Roman začíná v 21:37.

Pokud by vás toto téma zajímalo více, pak zajímavou úvahu s názvem Nevidomí a dotykové telefony, bezradní či ne? napsal Pavel Ondra - další aktivní nevidomý uživatel dotykových zařízení.

neděle 28. října 2012

Apple jako kompenzační pomůcka pro zrakově postižené - 7. díl

Změny v pracovním prostředí a jednoduché vyčítání oken

Dnes ještě za čerstva se přeučíme to, co jsme si minule pěkně vysvětlili, neboť v nedávno vyšlé nové verzi systému OS X 10.8 Mountain Lion došlo ve stavových nabídkách ke změnám. Dojde ovšem i v tomto díle na nové dovednosti - popíšeme si způsob základního vyčítání oken.

Nové stavové nabídky

Zkráceně řečeno, ve verzi OS X 10.8 Mountain Lion došlo ke sloučení oblasti stavových nabídek a Spotlightu a přibylo ještě něco navíc. Nyní tedy opakovaným stiskem VO+M se přepínáme pouze mezi aplikačními nabídkami a stavovými nabídkami, při čemž při vstupu do stavových nabídek se vždy nacházíme na té ikoně, která byla posledně vybrána. Spotlight je tak jednou z ikon ve stavových nabídkách. Vedle něj nově můžeme najít ikonu oznamovacího centra, což je dialog schraňující na jednom místě informace o důležitých událostech v systému a aplikacích. Budeme se o něm více bavit dále.

Každou z nabídek nyní nelze rozbalit jednoduše šipkou dolů, musíme k tomu využít příkaz pro kliknutí na položku - VO+Mezerník. Nic zásadního se ale dále v ovládání stavových nabídek a Spotlightu nemění a platí o jejich funkčnosti to, co jsme si popsali v minulém díle. Používáme-li ke vstupu do Spotlightu klávesovou zkratku CMd+Mezerník, žádnou změnu ani nezaznamenáme.

Přece jen ještě jedné pozitivní změny si můžeme povšimnout a to zpřístupnění stavových nabídek aplikací třetích stran. Padá tedy bariéra nemožnosti ovládat rychle DropBox či Skype. Ikony aplikací, které mají svoji stavovou nabídku lze nalézt v levé části stavových nabídek.

Standardní kurzory v OS X

Dříve než si popíšeme, jak vyčítat obsah na obrazovce a jak se v něm efektivně pohybovat, je vhodné se zmínit o kurzorech, s kterými se v OS X můžeme setkat a jak ovlivňují navigaci po obrazovce. První z nich je ukazatel myši, který se v základním nastavení pohybuje nezávisle na ostatních dvou kurzorech, proto jeho chování nebudeme v tuto chvíli brát v úvahu.

Druhý z nich je systémový kurzor nebo také v terminologii nápovědy VoiceOveru "zaměření z klávesnice", my však jej budeme nazývat fokus, neboť je to blíže anglickému originálu "Keyboard focus". Ten primárně ovládáme klávesou Tabulátor, resp. Shift+Tabulátor, kdy fokus přechází po položkách v tzv. kruhu tab order. V případě, že v rámci ovládacího prvku zaměřeného fokusem lze pozici dále upřesňovat kurzorovými šipkami, budeme o takové pozici hovořit jako o pozici kurzoru (v terminologii nápovědy též "ukazatel"), neboť se jedná o zažitý pojem, mluvíme-li např. o kurzoru v textových polích. Prakticky to tedy funguje tak, že pokud začneme na klávesnici psát, vkládá se text do ovládacího prvku zaměřeného fokusem na příslušnou pozici kurzoru. Pokud se fokus nachází na tlačítku, zaškrtávacím políčku nebo jiném klikatelném ovládacím prvku, používáme k jeho aktivaci mezerník, což je ostatně stejné jako v systému Windows. Existuje-li v aktuálním okně, resp. dialogu, výchozí tlačítko, aktivujeme jej odkudkoli Enterem.

VoiceOver kurzor

Protože navigace pomocí tabulátoru funguje spolehlivě pouze v dialozích a pomocí tabulátoru se nelze donavigovat na prvky, které jsou reálně jenom pro čtení, existuje pro vyčítání veškerého obsahu tzv. VoiceOver kurzor, jenž používáme při zapnutém VoiceOveru. Je to vždy oblast uživatelského rozhraní, kterou VoiceOver naposledy přečetl. Tato oblast je též pro přehlednost na obrazovce vizuálně ohraničena orámováním. Základní pohyb VoiceOver kurzoru provádíme klávesovými zkratkami VO+Šipka doprava pro přechod na následující prvek uživatelského rozhraní a VO+Šipka doleva pro přechod na předchozí prvek. Postupným posouváním VoiceOver kurzoru si můžeme přečíst celý obsah aktuální oblasti okna. VoiceOver kurzor přechází nejen přes ovládací prvky jako tlačítka, editační pole a vyskakovací tlačítka, ale i přes statický text, obrázky, indikátory průběhu apod. Kliknutí VoiceOver kurzoru na prvcích, jako jsou tlačítka nebo zaškrtávací políčka, provádíme již známou klávesovou zkratkou VO+Mezerník.

Jelikož v základním nastavení se fokus a VoiceOver kurzor navzájem následují a stejně tak pozice kurzoru s VoiceOver kurzorem, je v zásadě jedno, s kterým s kurzorů pohybujeme. To, že fokus následuje VoiceOver kurzor, můžeme s výhodou využít a pokud např. chceme-li do nějakého editačního pole vpisovat, stačí na něj přesunout VoiceOver kurzor. Na tomto místě se může zdát, že je jedno, zda tlačítko stiskneme samotným mezerníkem nebo v kombinaci s klávesami VO. Není tomu ale tak. Jednak se mohou vyskytnout situace, kdy samotný mezerník klik neprovede, zatímco VO+Mezerník ano a jednak se při ovládání složitějších funkcí setkáme s případy, kdy je nutné fokus a VoiceOver kurzor rozpojit, proto je dobré si na příkaz VO+Mezerník zvyknout.

Interakce s oblastmi obsahu

VoiceOver kurzor umí pomocí tzv. interakce prozkoumávat blíže obsah prvků uživatelského rozhraní. Stiskneme-li VO+Shift+Šipka dolů, zahájíme s prvkem interakci neboli zanoříme se do aktuálního prvku či oblasti a pohybujeme se následovně výše zmíněnými příkazy VO+Šipka doleva a VO+Šipka doprava jen v rámci oblasti, do níž jsme se zanořili. Pokud chceme interakci ukončit a vrátit se na předchozí úroveň zkoumání obsahu na obrazovce, stiskneme VO+Shift+Šipka nahoru.

Pomocí příkazů pro interakci se tak můžeme zanořit do oblastí obsahu, jako jsou panely nástrojů, tabulkové seznamy, editační pole nebo obsah ve formě webové stránky, ale i do jednoduchých prvků uživatelského rozhraní, u nichž si chceme pouze podrobnějším zkoumáním upřesnit, jak se co píše.

Podcast

V podcastu k dnešnímu dílu si prakticky ukážeme, jak VoiceOver kurzor můžeme použít k vyčtení informací z dialogu O tomto Macu a z oznamovacího centra, u něhož si názorně ukážeme interakci s oblastmi obsahu.

Podcast ve formátu mp3 (9 MB).

Autorem článku i podcastu je Roman Kabelka.

Další díly seriálu

pátek 26. října 2012

Přečetl jsem: Simon Mawer - Dívka, která spadla z nebe

Ačkoliv tématika druhé světové války mě vždycky zajímala (knihy o našich letcích na západní frontě jsem jako kluk četl jak na běžícím pásu), o francouzském odboji jsem toho moc nevěděl. Proto mě velmi zaujala kniha Simona Mawera, která se právě této tématice věnuje.

Sedí na okraji otvoru v podlaze s nohama spuštěnýma ven do vzdušného víru. Jako by seděla na kameni u řeky, máčela si chodidla ve vodě a proud ji strhával. A už zhasíná červené světlo, rozsvěcí se zelené a pomocník zařve "GO!", na zádech cítí jeho ruku a skočí, vrhne se ze spartánského pohodlí v trupu letounu do rozbouřené temnoty nad Francií.

Marian Sutro (nebo Alice?, nebo Anne-Marie Laroche?), která za chvílí dopadne na francouzskou zem, je napůl Angličanka, napůl Francouzka. Francouzská sekce britských zvláštních jednotek ji vyšle do okupované Francie nejen pomoci domácímu odboji, ale splnit mnohem důležitější úkol: přesvědčit mladého fyzika Clémenta, jehož vědecký výzkum by spojenci rádi využili při vývoji atomové bomby, aby opustil svou zemi a odletěl do Anglie.

Simon Mawer se při psaní soustředil na hlavní hrdinku a vše se "točí kolem ní". O válce toho tedy nevíme o nic víc, než ona, včetně jejích myšlenek, pochyb, názorů či rozhodnutí, co v dané chvíli udělá. Nesetkáme se zde s technickými a faktografickými popisy událostí - žádné svazy bombardérů, uskupení letadlových lodí, masivní útoky pěchoty či tanků opravdu nečekejte. Je to boj "jedna proti všem", protože Marian za chvíli neví, komu může a komu nemůže věřit, kdo je spojenec a kdo zrádce.

Obzvlášť válečná Paříž je zde vykreslena značně depresivně a nebezpečí zde číhá na každém kroku a její pobyt zde jsem s Marian opravdu prožíval, měl radost i se bál tehdy, kdy se radovala či bála ona.

Vrátit se do Toulouse je jako opustit jeden kontinent, přeplout oceán a nechat se vyhodit na břeh druhého kontinentu, jiného světa. Jistě, jsou tu nebezpečí, ale taková, o kterých člověk ví, která lze vidět a zvážit, proti nimž se lze bránit jako proti infekci. To nástrahy Paříže jsou jako rakovina, neviditelná a zřejmě nevyléčitelná.

Jak to s Marian dopadne a zda a jak splní své poslání, vám pochopitelně neřeknu. Pokud vás to zajímá, knížku si kupte, dá se přečíst za jeden dva dny a i přes z mého pohledu trochu pomalejší rozjezd (pořádná akce začíná až ve Francii) je to dobré čtení.

Za poskytnutí reading copy děkuji Knize Zlín.

čtvrtek 25. října 2012

Nové verze screen readeru JAWS

Tento týden byly vydány hned dvě verze screen readeru JAWS. Pojďme se společně podívat, jaké novinky svým uživatelům přinášejí.

JAWS 14

V pondělí 22. října 2012 oznámil Freedom Scientific uvolnění verze 14. Její asi nejvíce očekávanou novinkou je podpora Windows 8. Freedom Scientific v posledním roce úzce spolupracoval s Microsoftem a upravili JAWS tak, aby s Windows 8 co nejlépe spolupracoval. Ozvučena je tedy jak nová úvodní obrazovka či aplikace jako e-mail, prohlížeč či kalendář.

Mezi další novinky patří nové hlasy Vocalizer Direct od Nuance. Ty nabízejí vyšší kvalitu a rychlejší odezvu oproti původním hlasům (v praxi to znamená, že Zuzana má teď lepší odezvu i v situacích, kdy předtím "nestíhala").

Flexible web umožňuje uživatelům uzůsobit si webové stránky tak, aby se co nejrychleji dostali k tomu, co potřebují, a nebo si ze stránek odstranili to, co nepotřebují.

JAWS 14 také přináší lepší podporu standardu WAI-ARIA a poradí si tak lépe se stránkami, které tento standard používají.

Další informace k JAWSu 14

JAWS 13 CZ

V úterý jsme pak v GALOPu uvolnili českou verzi screen readeru JAWS 13. Ta kromě desítek drobných vylepšení obsahuje řadu užitečných novinek jako je například funkce Rozpoznání textu z obrázků, další lokalizované zdroje ve funkci Prozkoumat či nové skupinové klávesové zkratky pro práci s tabulkami.

O některých novinkách jste se mohli dovědět z prezentace na letošním Tmavomodrém festivalu, z níž existuje i audio záznam. Podrobněji vás s novinkami JAWSu 13 seznámím v sérii článků zde na blogu.

Další informace k JAWSu 13

Tak si JAWS stáhněte, vyzkoušejte, co vše umí a proč patří mezi nejoblíbenější screen readery na celém světě.

úterý 23. října 2012

Umíš vytvořit (přístupný) přehrávač ve Flashi? A byl bys, prosím, ochoten mi pomoci?

Stále častěji se na mě v poslední době obracejí mí nevidomí klienti či kamarádi, kteří mají problémy s flashovými přehrávači videa na nejrůznějších webech. A bohužel i na takových, které by měly být ze své podstaty přístupné komukoliv (Český rozhlas, ČT24, atp.).

Momentálně je situace v této oblasti značně roztříštěná a nepřehledná.

  • Přehrávání videa lze v jednom prohlížeči spustit, ale v jiném ne.
  • Přehrávání videa lze sice spustit, ale další ovládací prvky přehrávače nejsou přístupné.
  • Některé přehrávače s jedním screen readerem fungují, ale s jiným ne.

A určitě jsem na nějakou kombinaci zapomněl ;-)

Samozřejmě mohu provozovatelům napsat, ať si to dají do pořádku, ale bez toho, aniž bych jim poradil, jak konkrétně mají ten přehrávač zpřístupnit, tento postup bohužel nefunguje (ověřeno praxí :-(

Já sám ve Flashi neumím. Proto bych se rád zeptal, zda mezi čtenáři POSLEPU (či mezi jejich kamarády, kolegy, spolupracovníky atp.) není někdo, kdo by uměl takový přehrávač ve Flashi vytvořit.

Napsali bychom pak společně krátký tutoriál, na co si dát při tvorbě flashového přehrávače pozor a co vše vzít v potaz, aby takový přehrávač byl přístupný.

Pokud byste měl někdo čas a chuť mi s tím pomoci, napište mi, prosím, do komentářů nebo přímo na radek.pavlicek@gmail.com.

Děkuji.

čtvrtek 11. října 2012

Opravdu jsou nevidomí z dotykových displejů bezradní?

Ale kdepak. Naprosto normálně s nimi mohou pracovat a dnes pro ně nejsou dotykové displeje překážkou. Samozřejmě za předpokladu, že použijí vhodnou asistivní technologii, která jim práci s dotykovým displejem umožní (což ale platí o všech pomůckách, založených na výpočetní technice).

Česká televize ve středu 10. 10. 2012 odvysílala reportáž Nevidomí jsou z dotykových displejů bezradní, obsahující řadu zavádějících tvrzení, která bych rád uvedl na pravou míru. Celkově mně reportáž vyznívá tak, jak se píše v prvním odstavci: “Řada výrobců zapomíná na nevidomé, přístroje s dotykovým displejem jsou pro ně fakticky neovladatelné. Nadějí by pro ně mohla být speciální technologie Sensek, kterou by mohly být tablety vybaveny v následujícím roce.”

A také tak, že ČT hledá problém někde, kde vlastně vůbec není a trh už jej dávno vyřešil.

Začněme hned titulkem reportáže. Jsou nevidomí z dotykových displejů bezradní? Někteří možná ano (viz ti dva pánové na začátku reportáže), ale myslím že v obecné rovině rozhodně nijak víc, než z běžného (nepřizpůsobeného) počítače či mobilního telefonu. Ty je totiž také třeba pro to, aby s nimi mohl nevidomý člověk pracovat, doplnit asistivní technologií, která to umožní. V případě nevidomých uživatelů se typicky jedná o screen reader, doplněný hlasovou syntézou, eventuálně hmatovým zobrazovačem. Tyto technologie zajišťují to, že nevidomý člověk je pak schopen s běžným počítačem, notebookem, tabletem nebo telefonem pracovat. Nejedná se o nic zvláštního ani převratného, tyto technologie už jsou tady docela dlouhou dobu.

Úplně stejně bych totiž mohl napsat, že nevidomí jsou bezradní z běžných osobních počítačů, vozíčkáři z běžných automobilů, atp. A měl bych pravdu. Protože pokud si je (nebo jim je někdo) nepřizpůsobí, tak jsou pro ně celkem pochopitelně nepoužitelné. Na tom není nic překvapivého ani divného. Titulek reportáže se v nás ale bohužel snaží vyvolat dojem, že zařízení s dotykovými displeji jsou obecně pro nevidomé uživatele nepoužitelné a ti jsou z nich bezradní.

V úvodu reportáže se říká “řada výrobců zapomíná na nevidomé a dotykové přístroje jsou pro ně fakticky neovladatelné”. Toto tvrzení se snaží potvrdit to, co už naznačuje titulek, tedy problematičnost dotykového ovládání pro nevidomé. Nevím, jak je ta řada dlouhá, ale když to otočíme, tak majoritní operační systémy (iOS a Android) jsou už dnes pro nevidomé přístupné out-of-the-box a pokud si nevidomý uživatel vybere některý z nich, tak s ním může prakticky bez obtíží pracovat. Pokud si vybere nějaký jiný (nepřístupný), tak je to jeho (špatná) volba, za kterou mu ale nikdo nemůže, protože přístupná zařízení na trhu jsou.

Další tvrzení “Bez hlasového ovládání je nemají šanci používat.” také neodpovídá realitě. Nevidomí uživatelé k ovládání výpočetní techniky nepotřebují hlasové ovládání (tedy technologii, pomocí níž budou počítači zadávat příkazy hlasem), ale hlasový výstup (tedy technologii, která jim naopak bude informace z obrazovky číst).

Tvrzení o problematičnosti dotykového ovládání nám mají potvrdit i dva nevidomí pánové. Ten první používá přes deset let staré systémy, protože výrobci podle něj na nevidomé zapomínají a práci s dotykovým displejem si představit nedokáže. Druhý pán se kvůli trendu dotykových displejů cítí být na okraji společnosti. Naprosto seriózně by mě zajímalo, zda oba dva pánové měli možnost (a chuť) si někým znalým věci nechat ukázat ovládání přístroje s dotykovým displejem poslepu a vyzkoušet si, jak to funguje. Mám za to, že ne. Protože kdyby ano, tak by takto mluvit nemohli.

Nyní se reportáž otáčí do pozitivního duchu v tom, že někteří přední výrobci dotykových zařízení na nevidomé myslí a stále zdokonalují systém hlasového ovládání. Následuje ale ukázka hlasového výstupu, konkrétně screen readeru Voice Over.

Pokračujeme informací o tom, že některé tablety či dotykové telefony dokáží nevidomým zprostředkovat přes 90 % veškerého obsahu. Tady by mě docela zajímalo, proč zrovna 90 %? Z jakého průzkumu či studie toto číslo vychází?

Revolucí má pak být dotyková technologie Sensek. "To funguje tak, že se dotýkáte běžného hladkého skla, ale ten pocitový vjem je, jako byste se dotýkali nějaké struktury," upřesnil šéfredaktor počítačového portálu David Polesný. Asi jsem málo důvtipný, ale mně tedy David nic neupřesnil, tato věta mi přijde naprosto vytržená z kontextu a vůbec jsem z reportáže nepochopil, jak má tato technologie fungovat a pomoci nevidomým.

Pěknou tečkou na závěr, která to ale nezachrání, je pak otevření mého blogu na iPadu (děkuji za reklamu ;-). Jen ho asi bohužel ti, co reportáž připravovali, nečetli, protože jinak by se třeba v seriálu od Romana Kabelky iPad: standard přístupnosti dotykových zařízení dočetli, jak že to s tím dotykovým ovládáním poslepu vlastně je.

A ještě by si to mohli i prohlédnout na videu, které obsahuje i ukázku toho, jak si na iPadu pustit právě ČT24.

Shrnutí

Shrňme si tedy, co jsme se z reportáže dozvěděli. Nevidomí jsou z dotykových displejů bezradní a někteří se kvůli nim dokonce cítí být i na okraji společnosti, protože většina výrobci na nevidomé zapomíná. Naštěstí někteří přední výrobci na nevidomé myslí a jejich zařízení jim dokáží zprostředkovat až 90 % veškerého obsahu. Zachránit situaci by pak měla technologie Sensek, o které jsme se v reportáži dozvěděli ale jen to, že když se dotýkáme běžného hladkého skla, tak máme pocitový vjem takový, že se dotýkáme nějaké struktury.

A jaká je skutečnost?

Samozřejmě nic není černobílé a jistě se najdou mezi nevidomými uživateli tací, kterým dotykové displeje z nějakého důvodu vyhovovat nebudou (ale takové uživatele najdeme i mezi lidmi bez zrakového hendikepu).

Dle mého názoru je důležité vědět, že s dotykovým displejem je možné už dnes pracovat i poslepu, že uživatelé mají dokonce na výběr z několika možností, jak si přístroje s dotykovým ovládáním zpřístupnit a nemusí čekat na Sentek. To, že se způsob práce liší od zaběhnutého ovládání z klávesnice a to, že nemusí vyhovovat každému, je pochopitelné.

Pravdou je, že o dotykové ovládání je mezi nevidomými uživateli velký zájem. Když jsme tuto tématiku zařadili do programu loňských doprovodných aktivit Tmavomodrého festivalu, praskal sál ve švech. Nevidomý Matěj Plch se tématice přístupnosti Androidu soustavně věnuje už dva roky a publikuje o tom na www.blind-android.cz. Můj nevidomý kolega Roman Kabelka si na letošní WebExpo už ani notebook nebral a veškeré prezentování přístupnosti zvládl s iPadem, iPhonem a hmatovým zobrazovačem. Nevidomý Pavel Ondra, šéf accessibility.gug.cz, už vystřídal několik telefonů s dotykovým ovládáním. A tak bych mohl pokračovat.

Proto mi přijde docela škoda, že reportáž nebyla pojata v opačném duchu a naopak neukázala, co všechno už lze dnes poslepu s dotykovým displejem dělat a namotivovala tak i další nevidomé lidi, kteří se z nějakého důvodu dotykového ovládání bojí, aby si je vyzkoušeli a začali je používat.

Trochu se obávám, že tato reportáž bude mít účinek přesně opačný. “Vždyť i v televizi říkali, že nevidomí jsou z dotykových displejů bezradní. Tak ono to asi ještě pro mě není přístupné,” řeknou si ti, co o problematice moc neví. Ti znalí věci z toho pak budou mít akorát srandu.

Úplně na závěr bych proto rád pozval redaktory České televize - pokud by chtěli natočit reportáž o tom, jak je to s dotykovým ovládáním poslepu ve skutečnosti - k nám do Brna, kde je rádi přivítáme a vše předvedeme ;-)