Pazite na vrzeli v dostopnosti – večina težav z dostopnostjo izvira iz oblikovanja. Kako jih odpraviti?

Menim, da je oblikovanje preveč osredotočeno na vizualne vidike, zato breme nevizualnega oblikovanja pade na ramena razvijalcev. Kaj lahko storimo, da bi to izboljšali? Kako lahko zapolnimo vrzeli?

Raziskave kažejo, da 67% težav z dostopnostjo izhaja iz oblikovanja (povezava se odpre v ločenem oknu).

Graf, ki kaže naraščanje časa potrebnega za dostopnost glede na fazo razvoja spletišča oziroma rešitve.
Izpostavljeno je, da kar 67% težav z dostopnostjo izvira iz oblikovanja.
vir: deque.com

Če dobro pomislimo, to ni tako čudno. Oblikovanje je načrt, zasnova, želeni rezultat. Če načrt ne vključuje invalidov, je logično, da jih tudi končni rezultat ne more vključevati. Zato nastane vrzel med oblikovanjem in končnim rezultatom (v tem prispevku imam v mislih predvsem spletne strani, vendar teza velja za vse izdelke).

Z besedo oblikovanje nimam v mislih le vizualnega oblikovanja, temveč tudi oblikovanje uporabniške izkušnje.

Enako lahko velja tudi za digitalne izdelke – ko jih oblikujemo, moramo pomisliti, kako bodo delovali, razmišljati moramo tudi o drugih vizualnih elementih, kot so barve, vizualna hierarhija, vizualni namigi o funkcionalnosti, odzivno oblikovanje in tako naprej.

Razmišljati moramo o osebah z oviranostmi in kako bodo izdelek uporabljale, zato jih je treba predstaviti v personah, kadar jih uporabljamo. Zato moramo vizualno oblikovanje opremiti z mehaniko, ki stoji za njo.

Poleg tega moramo razmišljati tudi o različnih načinih uporabe vmesnika, pa ne le z miško in na dotik, temveč tudi s tipkovnico, glasovnim upravljanjem, bralniki zaslona, Brajevimi vrsticami, stikali, napravami za upravljanje s pihom in tako naprej. Skratka razumeti moramo uporabnika, kajne? Ker povprečnega uporabnika ni (povezava se odpre v ločenem oknu), moramo, kadar želimo vključiti čim širši krog ljudi, upoštevati “ekstremne uporabnike”.

Vrzeli v znanju in razumevanju zahtevajo učenje

Da, pravzaprav pravim, da se morajo oblikovalci naučiti vsega tega. Vem, da lahko stvari včasih hitro postanejo zelo tehnične, vendar moramo pri oblikovanju za platformo poznati tudi platformo. Splet kot platforma pa pomeni vsaj HTML.

Ne trdim, da morajo oblikovalci pisati kodo, čeprav bi bilo to optimalno (vsaj na ravni prototipa).

V mislih imam predvsem to, da morajo poznati možnosti in omejitve spleta kot platforme. Če vemo, kaj je mogoče doseči z gradniki platforme – začenši s HTML-jem (in tudi, kaj ni), lahko svoje spletišče že na začetku naredimo dostopnejše. Tudi jezik HTML ni popoln, vendar z njegovo uporabo namesto izmišljevanja novih stvari izboljšamo svoje izdelke.

Ker vemo, da je HTML precej omejen pri naprednih interakcijah in komponentah, ki so potrebne za bolj interaktivne spletne aplikacije, je jasno, da morajo oblikovalci poznati tudi osnove vlog in atributov ARIA (Accessible Rich Internet Applications (povezava se odpre v ločenem oknu). ARIA razširja HTML, zlasti za bralnike zaslona in druge podporne tehnologije, ter omogoča dodatne možnosti, ki jih ni mogoče doseči samo s HTML-jem, zato moramo vedeti, kakšne možnosti ponujata, če oblikujemo za platformo, ki je omejena na HTML in atribute ARIA.

Tako lahko vodimo razvijalce in poskrbimo, da bo naš izdelek (bolj) dostopen. Kot oblikovanje vodi pri opredelitvi vizualnih elementov, mora začeti voditi tudi pri opredelitvi vedenja. Z vedenjem mislim tudi na nevizualno vedenje, denimo kar bralniki zaslona sporočajo uporabnikom.

In že smo pri misli, da bi morali oblikovalci razumeti tudi osnove podpornih tehnologij. Naj ponovim, ne trdim, da bi morali poznati vse napredne možnosti, ki jih ponujajo, vendar bi osnove prišle zelo prav. Poznavanje zgolj miške in dotika ne zadostuje, če želimo, da so naši izdelki dostopni. Oblikovalci bi moralo razumeti vsaj še delovanje tipkovnice, povečave (zooma), bralnika zaslona in glasovnega upravljanja.

Tako izkušnje teh uporabnikov ne bo oblikoval zgolj razvijalec. Oblikovalci morajo oblikovati izkušnje za vse uporabnike.

Praktično smo prišli do procesa. Na začetku lahko temelji na kontrolnih seznamih, nato pa postane samoumevna. Delo v osami lahko prinese tudi veliko težav. Če oblikovanje in razvoj potekata ločeno, s kratkimi poročili in sestanki ter hitrimi opombami, dobimo še eno vrzel, tisto med oblikovanjem in kodo.

Vrzeli med oblikovanjem in kodo

Oblikovanje je treba pretvoriti v kodo. Če želimo, da bo izdelek dostopen, si mora razvijalec oblikovanje razlagati z mislijo na dostopnost. Če oblikovalec in razvijalec dostopnosti ne razumeta in je ne uresničujeta, je jasno, da končni izdelek ne bo dostopen.

Če oblikovalci ne opredelijo, kako bodo elementi delovali pri uporabnikih s pomožnimi tehnologijami, potem razvijalec verjetno, ne bo pripravil potrebne kode. Lahko se zgodi, da se razvijalec zaveda manjkajočih delov in sprejme lastne predpostavke ter jih vgradi, vendar potem tvegamo izdelek, ki ne bo deloval, kot bi si želeli oblikovalci. Opredelitev oblikovanja seveda ni odgovornost razvijalcev.

Primer: če oblikovalec izdela komponento po meri in opredeli le, kako se bo uporabljala z miško in prek dotika, mora razvijalec oblikovati še izkušnjo za tipkovnico in druge podporne tehnologije. Seveda če so razvijalci ozaveščeni in imajo znanje o dostopnosti. Pogosto take izkušnje utonejo v pozabo in končni izdelek zelo verjetno določenim uporabnikom ostane nedostopen.

Tudi če imajo razvijalci poglobljeno znanje in razumevanje, to ni dovolj. Sami ne morejo oblikovati celotne izkušnje in morajo svoje odločitve vsaj uskladiti z oblikovalcem, pod pogojem, da oblikovalec sploh razume njihov pomen. Naj ponovim, v mislih nimam le vizualnih oblikovalcev, temveč tudi oblikovalce uporabniške izkušnje. Navsezadnje je treba oblikovati uporabniško izkušnjo, ne le vizualno.

Odpravljanje vrzeli pomeni ustrezno kulturo, znanje in sodelovanje

Za odpravo vrzeli med oblikovanjem in kodo so potrebni oblikovalci z znanjem o HTML-ju in atributih ARIA ter podpornih tehnologijah (že z osnovnim znanjem in zmožnostjo branja dokumentacije lahko dosežemo veliko), ki določajo nevidno uporabniško izkušnjo in vodijo razvijalce, ko ti pretvorijo oblikovanje v kodo.

Na drugi strani vrzeli so razvijalci, ki morajo bolje razumeti podrobnosti HTML-ja in atributov ARIA (zlasti kaj je podprto in katere so najboljše prakse uvajanja podpore podpornim tehnologijam), vendar morajo obenem biti sposobni uporabljati podporne tehnologije na taki ravni, da bodo znali testirati svoje delo, preden ga predajo v uporabo javnosti. Za premik v levo je to potrebno, sicer bomo spet v nevarnosti, da bomo pri testiranju čisto na koncu (ali končni uporabniki namesto nas) našli nedostopne dele uporabniške poti.

Kot verjetno razumemo, je za tovrstno znanje in izkušnje dejansko potreben kulturni premik. Oblikovalce in razvijalce je treba usposobiti in jih ne prepustiti samotnemu iskanju po spletu ali, še huje, reševanje problemov zaupati umetni inteligenci in velikim jezikovnim modelom.

Na spletu je tisoče blogov z različnimi informacijami, včasih celo nepravilnimi ali preprosto zastarelimi, brezplačni uradni viri, z izjemo standardov, so pogosto omejeni, ujeti pri osnovah ali prav tako zastareli, usposabljanje pa pogosto terja čas in denar, ki ju je včasih težko najti sredi projekta s strogimi roki.

Zato je vodstvo organizacije kot vedno ključno vlogo, vrzeli pa ni mogoče odpraviti brez naložb na vseh ravneh. Tudi ko bo uradno izobraževanje vključevalo dostopnost za vse vloge (ta proces je v veliki meri še vedno nedokončan, čeprav je bil WCAG 1.0 objavljen že leta 1999), bomo še vedno morali zgraditi kulturo, usposabljati ljudi in uvajati dostopnost (povezava se odpre v ločenem oknu) v vse ključne procese, da bodo naši izdelki (bolj) dostopni.


Avtor članka je Bogdan Cerovac, vodja strokovnega sveta Zavoda A11Y.si. Članek je v originalu objavljen na cerovac.com (stran se odpre v novem zavihku). Članek je prevedel Grega Fajdiga, prevajalec in presojevalec pripravnik v Zavodu A11Y.si