Večina težav z dostopnostjo se pojavi pri oblikovanju, nato pa pri kodi, nizkokodni ali brezkodni rešitvi
Po navdihu drugih sem razmišljal o izvoru težav z dostopnostjo pri oblikovanju. To ni tako čudno, če pomislimo, da je oblikovanje načrt izvedbe, in če že načrt ni dostopen, potem tudi končni izdelek zagotovo ne bo. To velja za kodne, nizkokodne in brezkodne rešitve.
Po najboljših močeh se trudim ugotavljati, kako izboljšati procese, ki vodijo k dostopnim digitalnim izdelkom. Učenje od drugih je ključ do izboljšav, ki lahko prihrani veliko časa in tudi denarja, zato se splača prebirati članke in se udeleževati spletnih seminarjev ter konferenc. To je pravzaprav logično – pridobite širši vpogled, izločite morebitne prodajne ponudbe in se učite iz napak, ki so jih storili drugi, ter tako pridobite pravo znanje. Vendar je to le začetek. Najprej morate imeti načrt, ob tem pa je dobro vedeti, kaj morate storiti in kako.
Oblikovanje je pogosto del načrta. V popolnem svetu bi bil razvijalec tudi oblikovalec. To mislim popolnoma resno. Drži tudi obratno – oblikovalec bi bil tudi razvijalec. Izdelovanje estetskih, semantičnih, uporabnih in dostopnih izdelkov z učinkovito, semantično, varno in zmogljivo kodo.
Izdelovanje estetskih, semantičnih, uporabnih in dostopnih izdelkov z učinkovito, semantično, varno in zmogljivo kodo.
Oblikovalec in razvijalec, morda bi lahko rekli full-stack oblikovalec, ali kot nekdaj, skrbnik spletišč (webmaster)?
Full-stack oblikovalci – vzpon skrbnika spletišč
V prvih letih interneta smo poznali tako imenovane skrbnike spletišč (webamasters oziroma spletne mojstre), ki so znali narediti vse – od oblikovanja do čelne (front-end) in zaledne (back-end) kode. Trenutno smo vedno bolj specializirani, saj se področje razvija v številne smeri, tako oblikovanje kot programiranje pa postajata vedno bolj zapletena. Zato moramo običajno imeti ekipo specialistov, ki jo sestavljata vsaj oblikovalec in razvijalec.
Toda z novo revolucijo tako imenovanih »nekodnih« ali »nizkokodnih« rešitev se spet približujemo »skrbnikom spletišč« – ljudem, ki lahko prevzamejo projekt in s sodobnimi orodji WYSIWYG (What You See Is What You Get – kar vidiš, to dobiš) skupaj naklikajo celotna spletišča. Z njimi je mogoče zelo preprosto uvesti vedno več integracij, od sprejemanja plačil do celotne e-trgovine ali celo upravljanja odnosov s strankami (Customer Relationship Management – CRM), vse pa je centralizirano in mogoče uveljaviti v enem samem vmesniku.
Te rešitve so nekoč veljale za precej neugledne, vendar se zdi, da imajo čedalje več uporabnikov in tudi boljšo podporo dostopnosti. To je zelo pomembno, saj bolj ko se bodo uporabljale, večji bo njihov vpliv na Splet. Osebno sem bil bolj naklonjen izdelavi čisto od začetka, vendar vsekakor razumem motiv in vodilo kar najhitrejšega vstopa na trg. S takimi orodji bi lahko v nekaj mesecih ali celo tednih izdelali spletni izdelek, da bi preizkusili, ali je izvedljiv, in nato po potrebi naredili nekaj izboljšav ali rešitev po meri, ko bi bil že na trgu.
Oblikovalčeva odgovornost za dostopnost
Rešitve brez kode, z malo kode ali samo z žičnim modelom (wireframe), pri vseh oblikovalci nosijo veliko odgovornost za splošno dostopnost izdelka. V tem prispevku ne bom obravnaval vseh smernic WCAG in naštel vseh meril uspešnosti, ki bi morala biti vključena v dobro oblikovanje, vendar je glede na raziskave večina težav z dostopnostjo posledica oblikovanja, veliko prej, preden lahko razvoj razmere še poslabša.
Oblikovalci bi morali več vlagati v popolno razumevanje svojega vpliva na dostopnost. Upoštevanje oviranosti pri opredeljevanju oseb, zagotavljanje dostopnosti žičnih modelov in njihovo dopolnjevanje z opombami o dostopnosti, kot sta zaporedje fokusa in interaktivnost tipkovnice, uporabniško testiranje z osebami z oviranostmi, poznavanje najboljših praks na področju semantike, možnosti in omejitev izvirnega HTML-ja, razumevanje možnosti, ki jih je mogoče doseči z ARIA – če povzamem – vse to daleč presega tipografijo in barvne kontraste.
Oblikovalci ne bi smeli pričakovati, da bodo razvijalci sprejemali odločitve, ki bi jih morali sprejeti oblikovalci. Dialog z razvijalci lahko zagotovo pomaga pri sprejemanju učinkovitejših odločitev pri oblikovanju, kjer se moramo spopasti s težavami v kodi, vendar bremena oblikovanja za interakcijo ne bi smeli prenašati na razvijalce, vsaj ne brez ustreznih pogovorov in smernic, najbolje v okviru oblikovanja.
Oblikovalci morajo tudi razumeti, kako nekateri končni uporabniki uporabljajo internet (ali aplikacije) na popolnoma drugačen način. Kako izdelek uporablja uporabnik bralnika zaslona? In kako uporabnik podporne tehnologije z govornim nadzorom? Kaj pa naprave s stikali, ki jih morajo uporabljati nekateri uporabniki? Ko želimo, da so naši izdelki resnično dostopni, moramo veliko vedeti in pomisliti na marsikaj. Vendar je to izvedljivo, potrebni pa so le zavedanje, empatija, sodelovanje in znanje.
WCAG je najmanj, kar je treba zagotoviti
O tem sem že veliko pisal, vendar je tako pomembno, da moram ponoviti. WCAG je minimalna zahteva, vsaj WCAG 2.1 na ravni AA. Zato res ne razumem ljudi, ki ne morejo izpolniti niti teh meril. Smernice so morda nekoliko preširoke in ljudje, ki jih prvič preberejo, iščejo recepte in ne le navodila. Odprtost smernic lahko predstavlja težavo nekaterim, ki nimajo dovolj izkušenj. To je popolnoma razumljivo. Resnično upam, da bo WCAG različica 3 to popravila. Prezgodaj je še, da bi bil o tem prepričan, vendar sem optimist.
Toda nekatera merila uspeha iz veljavnih smernic WCAG na ravni AA so zelo preprosta, vendar jih kljub temu kršimo. Ne pravim, da to počnejo samo oblikovalci, saj je očitno, da bi morali tudi razvijalci storiti več za dostopnost. Pisal sem že o samodejnem testiranju dostopnosti (stran se odpre v ločenem zavihku) in ne bom se ponovno spuščal v podrobnosti, vendar se pri težavah, ki izvirajo iz kode, zelo dobro obnese. Po drugi strani pa je včasih koda še najmanjša težava. Vendar pa se samodejno testiranje slabo obnese pri drugih vidikih dostopnosti, zlasti pri oblikovanju in vsebini. Morda je tudi to razlog za miselnost, da morajo težave z dostopnostjo odpravljati razvijalci, saj lahko določene težave v kodi odkrijemo s samodejno delujočimi orodji. Mogoče to drži, o tem lahko le ugibam. Dejstvo pa je, da bi morali tako oblikovalci kot razvijalci vložiti več časa v to, da bi resnično spoznali WCAG in kako ga upoštevati. Enako velja tudi za ponudnike vsebine, pisce in urednike – tudi oni bi morali opraviti svoj del naloge, saj je ta lahko ključnega pomena. Kaj pomaga, če oblikovalec in razvijalec naredita popolnoma dostopno spletišče, nato pa dodana ali spremenjena vsebina krši nekatere vidike dostopnosti?
Ko funkcije dodajamo ali spreminjamo, morajo biti dostopne, in ko dodajamo ali urejamo vsebino, mora biti dostopna tudi ta. In tako naprej. To je ekipni šport in potovanje, ki se nikoli ne konča.
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