V článku o open-source sme si spomínali, že každý používateľ softvéru, bez ohľadu na jeho technické pozadie sa stáva členom jeho komunity. Práve prostredníctvom ľudí rôznych expertíz, schopností, uvažovaní a potrieb sa projekt dostáva do kontextov, o ktorých sa jeho autorom možno ani nesnívalo, čo ho robí univerzálnejším, flexibilnejším, kvalitnejším a celkovo užitočnejším. To isté platí aj o prístupnosti. Nie je lepší spôsob ako spraviť program prístupným, než dať ho do rúk skutočným zrakovo hendikepovaným používateľom.
Aby tento cyklus ale mohol fungovať, je kriticky dôležitá jedna vec. A tou je komunikácia. V prvom rade jej existencia, ak sa neozvete vy so svojimi problémami, nikto iný to za Vás neurobí. Zdá sa ale, že toto by až taký veľký problém v prípade zrakovo postihnutých byť nemusel. Ibaže, je tu druhý dôležitý predpoklad. Keď už komunikácia začne, mala by spĺňať určité štandardy kvality. Byť konštruktívna, výstižná, berúca ohľad na pozíciu protistrany, motivačná.
Inými slovami, každý report sa dá napísať veľmi veľmi dobre, a dá sa napísať veľmi veľmi zle. Pričom platí, že čím lepšie hlásenie spíšete, tým väčšie sú Vaše šance, že sa bude problémom niekto zaoberať a ak to bude čo i len trochu možné, tak ho aj vyrieši. Ako ale napísať hlásenie, ktoré bude spĺňať takéto požiadavky?
Osobne sa venujem vývoju softvéru už 11 rokov. Viem tak z vlastnej skúsenosti povedať, že napísať kvalitnú pripomienku nie je vôbec ťažké, a zvládne to aj používateľ, ktorý sám neprogramuje a možno ani nie je príliš technický typ. Stačí sa držať niekoľkých základných bodov, na ktoré sa pozrieme v tomto článku, a programátori budú s vami veľmi radi spolupracovať.
Programátor je väčšinou na vašej strane
V slepeckej komunite sa vyskytuje mýtus, podľa ktorého sa vývojári prístupnosťou nechcú zaoberať, považujú ju za stratu času, malú cieľovú skupinu a tak podobne. Našťastie, ide skutočne o mýtus.
Vysvetlím to na príklade. Predstavte si, že ste amatérsky spisovateľ, ktorý píše knižky, ktoré bezplatne zverejňuje komukoľvek na prečítanie. Nie je to veľmi nerealistická predstava, Wattpad je podobných ľudí plný a nájde sa na ňom nejedno vysoko kvalitné dielo. Ak ste však už niekedy napísali čo i len poviedku, viete, že je jedna vec písať pre seba, a vec druhá pre publikum. Keď píšete pre seba, text môže byť uletený ako sa vám páči, nemusí nutne dávať zmysel (hlavne ak vás baví) a štylistika tiež nie je prvoradá starosť. Avšak keď už svoju prácu chcete dať druhým, cítite určitú zodpovednosť za ich čitateľský zážitok, a rovnako chcete, aby vás vedeli pri čítaní čo najlepšie pochopiť. Dáte si tak oveľa viac práce s textovou úpravou, opravou gramatiky, formátovania, zachovaním istej konzistencie príbehu. Stojí vás to oveľa viac práce, ale je to obojstranne výhodná záležitosť. Vy budete mať dobrý pocit, že ste vytvorili niečo skutočne poriadne a hodnotné, zatiaľ čo vaši čitatelia budú mať super zážitok, a ideálne vám aj zanechajú pozitívny komentár či dokonca vytvoria fan fiction.
Úplne rovnako to funguje s open-source projektami, za ktorými stoja dobrovoľníci. Je jedna vec spraviť program, ktorý viem používať ja a niečo úplne iné program, ktorý budú bez problémov vedieť používať moji používatelia. To, že nájdete na GitHube program s rozsiahlym readme, kompletnou dokumentáciou, ktorý po spustení nepadá, nevypne sa v polovici rozrobenej práce, je intuitívny na používanie, všetky položky menu, tlačidlá, ovládacie prvky fungujú, sú všetko indície, že vývojári venovali obrovské množstvo času a úsilia tomu, aby urobili program prívetivý pre druhých, nie len seba.
A do tej skupiny patria aj zrakovo či ináč postihnutí používatelia. Viem vám zaručiť, že ako programátor nikdy nevyvíjam s úmyslom urobiť svoju prácu pre kohokoľvek neprístupnú. Ak majú moje programy nedostatky, je to zvyčajne neznalosťou. Viem toho pomerne veľa o potrebách čítačov obrazoviek. Ale čo by na moje rozhrania povedali napríklad ľudia s poruchami pozornosti či mobility? Obávam sa, že nie veľa pozitívneho. Jednoducho neviem nič o ľuďoch z týchto komunít ani o ich potrebách, a tak ich, žiaľ, neviem pri práci zohľadniť, kým sa mi niekto neozve, že niečo potrebuje.
Čo si z tejto sekcie odniesť? V prvom rade to, že pri spisovaní prístupnostného reportu nemusíte vývojárov evangelizovať, oni vo väčšine prípadov už sú na vašej strane. Čo spomenúť môžete je:
- že odvádzajú skvelú prácu, hlavne ak ide o otvorený projekt vyvíjaný vo voľnom čase,
- že by vám navrhované zmeny pomohli robiť X Y,
- že dobrá prístupnosť im prinesie používateľov z miest regulovaných prístupnostnými vyhláškami.
Ale vo väčšine prípadov to vôbec nie je potrebné. Sústreďte sa hlavne na jasné a zrozumiteľné popísanie problému, a snažte sa písať zdvorilo a pozitívne. Len tieto 2 prvky vo vašej komunikácii vám dajú veľmi dobrý základ na úspech.
Šablóna chybového hlásenia
Na prvý pohľad možno nemusí byť zrejmé, čo presne znamená jasne a zrozumiteľne popísať problém. Našťastie, v open-source komunite existuje dlhodobo zaužívaná šablóna hlásenia chýb. Vo väčšine prípadov ju stačí dodržať a vaše hlásenie bude na veľmi kvalitnej úrovni. V markdown syntaxi vyzerá asi takto:
# Jednovetný *výstižný* popis problému
Tu môžete pár vetami rozviesť, v čom problém spočíva a spomenúť kontext. Sekcia by však nemala byť pridlhá, nechajte za seba hovoriť reprodukčné kroky.
## Reprodukčné kroky
Uveďte *presný* zoznam krokov, ktoré má programátor vykonať, aby sa spoľahlivo dostal do chybového stavu aplikácie. Tu je veľmi dôležité napísať jednotlivé kroky tak, ako keby ste ich vysvetľovali človeku, ktorý s počítačom nikdy nepracoval. To znamená, že napríklad namiesto "prejdite na nadpis výsledky" uveďte "stláčajte klávesu H, kým čítač obrazovky nepovie výsledky". Je to veľmi dôležité preto, lebo programátor potrebuje presne reprodukovať, čo ste na klávesnici stláčali, kedy a ako. Aj najmenší rozdiel v metóde vykonania komplexnejších operácií môže spôsobiť, že sa chyba u vývojára neprejaví.
## Očakávané správanie
Tu uveďte, čo čakáte, že by sa po vykonaní krokov z predchádzajúcej sekcie stalo, ak by všetko fungovalo ako má.
## Aktuálne správanie
Popíšte, čo sa v skutočnosti po vykonaní reprodukčných krokov deje. Uveďte akékoľvek chybové hlásenia v presnom znení, ak na nejaké natrafíte.
## Prostredie
V tejto sekcii popíšte vaše zariadenie a relevantný softvér, ktorý používate, spolu s verziami. To znamená, Operačný systém - verzia, architektúra, čítač obrazovky a jeho verzia, verzia programu, webového prehliadača (ak je aplikácia webová a či ste skúšali reprodukovať bez doplnkov), pokiaľ sa chyba týka mobilnej aplikácie tak aj značku a model smartfónu.
A to je všetko. Relatívne jednoduchý neustále sa opakujúci vzor, pomocou ktorého viete ľahko nahlásiť aj pomerne komplikované problémy. Pokiaľ zodpovedne vyplníte a dodáte každú jednu časť (všetky sú veľmi dôležité), ste na dobrej ceste. Tu je ukážkové chybové hlásenie:
# Čítač obrazovky nedetekuje popisky editačných polí
Pri navigácii tabulátorom po prvkoch aplikácie čítač obrazovky neoznamuje popisky patriace k editačným políčkam. Plošným prezeraním sú viditeľné, zdá sa teda, že po stránke prístupnosti sú v poriadku, čítač ich má ale problém priradiť k widgetom.
## Reprodukčné kroky
1. Otvorte aplikáciu
2. Spustite čítač obrazovky klávesovou skratkou Alt+Super+S (Ctrl+Windows+Enter na systéme Windows)
3. Stláčajte tabulátor až kým kurzor nevstúpi do editačného políčka prihlasovacieho mena
## Očakávané správanie
Čítač obrazovky vysloví "Prihlasovacie meno vstup"
## Aktuálne správanie
Čítač obrazovky povie len "vstup" bez zmienky o funkcii políčka.
## Prostredie
Ubuntu Mate 22.04 64-bit, Orca 44.2, verzia aplikácie X.Y
Aby ste ešte posilnili kontext, môžete voliteľne pridať screenshoty, prípadne je aktuálnym trendom chybové stavy nahrávať na pár sekundové videá, kde predvediete reprodukčné kroky (je dobré si pritom dať pozor, aby ste nejakým spôsobom dali najavo čo robíte ak to nie je z obrazu zrejmé, pokiaľ napríklad nevidno vašu klávesnicu a fokus sa vizuálne neprejavuje).
Ak budete týmto spôsobom vypĺňať chybové hlásenia, myslím že môžem povedať za väčšinu programátorov, že sa potešia.
Top chyby pri vypĺňaní chybových hlásení
S dobre nahláseným problémom viem ako programátor často niečo urobiť. Avšak, veľakrát sa stretávam s reportmi (a to aj od technicky zdatných používateľov), nad ktorými iba krútim hlavou. Toto nie je umelo vytvorený list, ale sumár toho, s čím sa pri práci obvykle stretávam. Čo teda (ne)robiť pri hlásení chýb.
Program mi nefunguje
To je mi naozaj ľúto, a rád by som pomohol. Potrebujem ale vedieť, čo vlastne nefunguje. Táto jedna veta mi veľa nepovie, a nadpis „Problém“ tiež nie.
Niečo mi to píše
Z dôvodov komfortu a diskrétnosti programy (vrátane tých mojich) zvyčajne komunikujú s používateľom prostredníctvom textu. Ide teda o normálny stav a mojim odporúčaním je text si prečítať, program s najväčšou pravdepodobnosťou niečo oznamuje alebo potrebuje. Som ochotný hlásenie dovysvetliť, ale budem k tomu najprv potrebovať jeho obsah.
Hádže mi to chybu
Platí to isté čo v predchádzajúcej sekcii, program len upozorňuje na nejaký problém. Pokiaľ je podstata hlásenia nejasná, budem opäť potrebovať jeho obsah, aby som sa k nemu vedel vyjadriť. Účelom varovaní a chýb nie je používateľa vystrašiť, ale mu ľudskou rečou oznámiť, v čom je problém a umožniť chybu napraviť. Bez neho môžeme len hádať čo sa deje.
Nefunguje mi funkcia X Y
Super, oceňujem schopnosť sformulovať, čo presne nefunguje, tak ďaleko sa mnohé hlásenia nedostanú. Ale potrebujem trocha viac kontextu – čo presne používateľ robil keď sa do chybového stavu dostal, aké hlásenia to obnášalo a tak podobne, v opačnom prípade môžem len špekulovať, ako sa mu to mohlo podariť.
Chýbajúce informácie o prostredí a verziách programov
Aby som mohol problém opraviť, musím ho v prvom rade u seba zreprodukovať. A to sa niekedy robí ťažko, keď používateľ nezdieľa použitú platformu, verziu programu a iné dôležité údaje. Potom sa stáva, že skúšam dokola reprodukčné kroky v snahe vyvolať hlásený jav, až sa nakoniec pomedzi reč v konverzácii dozviem, že používateľ program spúšťa na 32-bitových Windows 7.
Nereprodukovateľné problémy
Toto je trocha komplikovaný bod, pretože sa mu nie vždy dá celkom vyhnúť. Podstatou drvivej väčšiny riešenia problémov je, že ich musím u seba vyvolať, pomocou programátorských nástrojov zistiť, čo presne sa pri nich deje a ktorá časť kódu akým spôsobom zlyháva, a túto časť opraviť. Ideálne chybové hlásenie by teda malo byť deterministicky spoľahlivo reprodukovateľné – obsahujúc isté kroky, ktoré ak vykonám 100-krát tak 100-krát uvidím chybu.
Ibaže toto nie vždy ide. Každý jeden problém je deterministický, ibaže niektoré sa odohrávajú za tak veľmi špecifických podmienok, že to navonok vyzerá, ako keby sa objavovali náhodne. Napríklad, systém Ubuntu Mate 20.04 obsahoval konfiguračnú chybu, ktorá spôsobovala, že služby sprístupnenia nabiehali v nešpecifikovanom poradí. No a keď dôsledkom task schedulingu nabehli v nesprávnych časoch, výsledkom bolo, že celé desktopové prostredie vyplo prístupnosť a pre Orcu sa stalo neviditeľným. To sa ale dialo pri jednom z desiatich štartov.
Nemala by byť zodpovednosť bežného používateľa hľadať takéto skryté súvislosti, to si môže vyžadovať rozsiahle technické znalosti, rovnako neplatí, že by problémy, ktoré nejdú spoľahlivo reprodukovať nemali byť nahlasované, práve naopak. Tým že sú zriedkavé, hlásenia o nich môžu byť jediným spôsobom, ako o nich niečo zistiť.
Len si v podobných prípadoch treba realisticky nastaviť latku očakávaní. Ja a ktorýkoľvek iný programátor urobíme čo budeme vedieť, aby sme problém vysvetlili a vyriešili. Ale môže to byť tak trocha ako vysvetľovať pôvod guľových bleskov.
S povzbudením možno dodať, že aj ťažko reprodukovateľné problémy sa zvyčajne napokon vyriešia. Ubuntu Mate 22.04 už netrpí problémom s neštartujúcimi službami sprístupnenia – len to niekedy môže chvíľu trvať.
Nahlásil som problém vzorne podľa šablóny. Bude teraz vyriešený?
Povedzme to skôr tak, že ste urobili to najlepšie čo ste urobiť mohli, aby sa problém vyriešil. Či sa tak naozaj stane závisí od viacerých faktorov.
V prvom rade je veľkou otázkou, čo si opravenie problému z programátorského hľadiska vyžaduje. Znova poslúži príklad. Predstavte si poschodovú drevenicu. Nahlásite problém, že zábradlie na balkóne už poriadne nedrží a mohlo by byť nebezpečné. To je pomerne drobná vec, postačí materiál spevniť, v najhoršom tých pár dosiek jednoducho vymeniť za nové. Keby ste naproti tomu ale nahlásili, že steny domčeka nie sú z obloženého betónu, ale ide o čisto neopracované drevené trámy, ktoré nespĺňajú protipožiarne predpisy, to by bol už väčší problém.
Veľmi podobným spôsobom funguje softvér. To, aké možnosti má programátor v oblasti prístupnosti je do veľkej miery závislé na tom, z čoho (akého GUI frameworku) postavil rozhranie svojej aplikácie. Pokiaľ tento framework dobre podporuje prístupnosť, jej zlepšenie môže byť len vecou kozmetických úprav (nahradenie pár widgetov, pridanie popiskov a tak podobne). Avšak ak framework vôbec nepodporuje prístupnosť (a také existujú), požiadavka na jej zapracovanie vlastne znamená, že od programátora očakávate, aby celú svoju aktuálnu prácu – v lepšom prípade aspoň čo sa týka rozhrania – zahodil a začal úplne odznova.
Človek nemusí oplývať extrémnymi dávkami empatie ani byť programátor aby vedel pochopiť, že do toho sa chce asi len málokomu. Prístupnosť je veľmi fajn vec, inklúzia tak isto, niekedy však môže byť cena za ňu pre jedného človeka privysoká.
Našťastie, pri otvorených projektoch ani toto nemusí byť stopka, ak je projekt skutočne hodný úsilia, skôr či neskôr sa nájde niekto, kto vytvorí alternatívne rozhranie. Prístupnosť je témou, ktorá získava čoraz väčšiu pozornosť medzi GUI frameworkmi, a preto je stále zriedkavejšie vidieť projekty, s ktorými by sa nedalo nič urobiť.
Ako teda naplno využiť komunitný potenciál a robiť projekty lepšími? Stačí byť v komunikácii jasný, zrozumiteľný, pozitívny, zdvorilý, empatický, a dajú sa dosiahnuť veľké veci.
Okomentujte ako prví