Dostopnost spletišč v javnem sektorju: zahteve in cena

Kaj pomeni dostopnost spletišča v javnem sektorju#

Dostopnost spletišča pomeni, da lahko vsak uporabnik, ne glede na fizično, senzorno ali kognitivno oviranost, dostopa do vsebin, izpolni obrazce in uporablja storitve prek spletišča ali mobilne aplikacije. Za javni sektor to ni izbirna funkcionalnost, temveč zakonsko določena zahteva, ki velja za organe državne uprave, javne zavode, agencije in izvajalce javnih storitev. Naročnik mora dostopnost obravnavati kot del funkcionalnih zahtev projekta že od začetka, ne kot dodatek po zaključku razvoja.

Dostopnost ne zajema le vizualnega dela vmesnika. Vključuje strukturo vsebine, način krmarjenja s tipkovnico, berljivost za bralnike zaslona, razumljivost jezika in dostopnost dokumentov, ki jih spletišče ponuja za prenos. Ko naročnik pripravlja zahteve za nov ali prenovljen sistem, mora določiti, kateri deli spletišča spadajo v obseg presoje - javni del, prijavljeni del, obrazci, dokumenti in morebitna mobilna aplikacija.

Za naročnika to pomeni, da mora dostopnost umestiti med merila za izbiro izvajalca in med prevzemna merila ob zaključku projekta. Zahteva mora biti zapisana v razpisni dokumentaciji ali projektni specifikaciji, sicer se presoja izvede šele po uvedbi, ko so popravki dražji in počasnejši.

Kdo mora zagotoviti dostopnost in za katera spletišča velja#

Zahteve veljajo za spletišča in mobilne aplikacije organov javnega sektorja - ministrstev, občin, javnih zavodov, agencij in izvajalcev javnih storitev. Zajema tako informativna spletišča kot transakcijske portale, prek katerih državljani oddajajo vloge, rezervirajo termine ali dostopajo do osebnih podatkov. Naročnik mora najprej popisati, katera spletišča, portale in aplikacije upravlja, in za vsako določiti, ali gre za novo razvit sistem, prenovo ali sistem, prevzet od prejšnjega izvajalca.

Kadar organ upravlja več sistemov hkrati - na primer osrednje spletišče, portal za oddajo vlog in informativni zaslon na lokaciji - je treba za vsakega posebej presoditi obseg dostopnosti, ker se razlikujejo po vsebini, uporabniških vlogah in tehnični zasnovi. Zaslon na dotik v javnem prostoru ima drugačne zahteve za dostopnost kot spletni portal, saj gre za fizično napravo z lastnim vmesnikom.

Kjer organ prevzema obstoječ ali nedokončan sistem od prejšnjega izvajalca, je dostopnost del vstopnega pregleda. Pregleda se izvorna koda, arhitektura vmesnika in obstoječa dokumentacija, na podlagi česar se oceni, koliko dela zahteva uskladitev z zahtevano ravnjo dostopnosti in ali gre za manjše popravke ali za prenovo vmesnika.

Kateri elementi spletišča morajo biti dostopni#

Presoja dostopnosti ne obravnava spletišča kot celote, temveč gre skozi posamezne gradnike vmesnika in vsebine. Naročnik mora vnaprej določiti, kateri deli sistema spadajo v obseg pregleda, saj se od tega obsega neposredno določi obseg dela in časovnica projekta. V nadaljevanju so gradniki, ki jih projektne ekipe pri presoji dostopnosti javnih spletišč najpogosteje obravnavajo.

Obseg presoje se razlikuje glede na to, ali gre za javni del spletišča, ki ga obiskujejo vsi državljani, ali za prijavljeni del, namenjen zaposlenim ali registriranim uporabnikom. Naročnik mora določiti prioritete - kateri deli sistema imajo največ obiska in katere funkcionalnosti so kritične za izpolnjevanje obveznosti organa.

Ko je obseg določen, projektna ekipa pripravi seznam ugotovitev po posameznih gradnikih, razvrščenih po nujnosti popravka. To naročniku omogoča, da popravke načrtuje v sklopih in jih uvršča v redne objave, namesto da čaka na enkraten obsežen popravek celotnega sistema.

• Struktura vsebine in krmarjenje s tipkovnico brez uporabe miške
• Berljivost za bralnike zaslona in opisi slik ter grafičnih elementov
• Barvni kontrast, velikost pisave in prilagodljivost postavitve
• Obrazci, potrditvena sporočila in sporočila o napakah
• Dokumenti za prenos (PDF in drugi formati)
• Video in avdio vsebine s podnapisi ali prepisom
• Mobilna aplikacija, kadar je del istega sistema

Kako poteka presoja in testiranje dostopnosti#

Presoja dostopnosti poteka podobno kot drugo funkcionalno in QA testiranje - kombinira ročno testiranje, avtomatizirana orodja in testiranje s ključnimi uporabniškimi scenariji. Ročno testiranje vključuje krmarjenje s tipkovnico, preverjanje z bralnikom zaslona in preverjanje razumljivosti vsebine. Avtomatizirano testiranje hitro odkrije tehnične pomanjkljivosti v kodi, ne odkrije pa vseh težav, povezanih z razumljivostjo in uporabnostjo.

Presojo dostopnosti umestimo v obstoječi proces QA, ki vključuje testne scenarije, ročno in avtomatizirano testiranje ter testiranje v razvojnem in testnem okolju, ločenem od produkcije. To pomeni, da se popravki testirajo, preden pridejo v produkcijsko okolje, in da se pri večjih projektih lahko vključi neodvisen QA, ločen od razvojne ekipe, kar poveča zanesljivost ugotovitev.

Po zaključeni presoji naročnik prejme seznam ugotovljenih odstopanj, razvrščenih po resnosti in vplivu na uporabnika. Na podlagi tega seznama se pripravi načrt popravkov, ki ga je mogoče uvesti postopoma, skladno z rednimi objavami sistema, ali kot enkraten poseg pred uvedbo novega sistema.

Kaj dostopnost pomeni za obstoječe in podedovane sisteme#

Veliko javnih spletišč in portalov je bilo razvitih pred leti, pogosto pri drugem izvajalcu, brez izrecne zahteve po dostopnosti. Kadar naročnik prevzame tak sistem, je prvi korak pregled izvorne kode, arhitekture in infrastrukture, na podlagi katerega se oceni, ali je uskladitev z zahtevano dostopnostjo mogoča s prilagoditvami obstoječega vmesnika ali zahteva prenovo posameznih delov sistema.

Odločitev med prenovo in prilagoditvijo je odvisna od tega, kako je sistem zasnovan. Če je vmesnik grajen modularno, je pogosto mogoče popraviti posamezne gradnike brez posega v celotno arhitekturo. Če je sistem zastarel ali slabo dokumentiran, je prenova dela vmesnika pogosto hitrejša in cenejša pot kot vrsta posameznih popravkov.

Naročnik mora pri prevzemu obstoječega sistema zahtevati dostop do izvorne kode, dokumentacije, gesel in infrastrukture, saj brez tega presoja dostopnosti in kasnejši popravki niso mogoči. To velja tudi, kadar gre za sistem, ki ga je razvil zunanji izvajalec in ni več aktiven partner organa.

Vloge in odgovornosti pri projektu dostopnosti#

Projekt uskladitve dostopnosti vključuje več vlog na strani naročnika in izvajalca, zato je smiselno vloge in odgovornosti določiti pred začetkom dela. Pri večjih projektih se določi projektni vodja, ki usklajuje ekipe, roke in način poročanja naročniku, naročnik pa določi svojo kontaktno osebo, ki potrjuje prioritete in prevzema rezultate.

Jasna delitev odgovornosti prepreči, da bi se popravki izgubili med organizacijskimi mejami - denimo kadar je vsebina v pristojnosti naročnika, koda vmesnika pa v pristojnosti izvajalca. Naročnik mora vnaprej vedeti, kdo pri njem skrbi za redno objavljanje vsebin, in to osebo vključiti v usposabljanje o zahtevah dostopnosti.

Ob zaključku projekta se izvede formalna primopredaja, ki vključuje izvorno kodo, dokumentacijo, dostope in gesla, saj so ti last naročnika. To naročniku omogoča, da dostopnost sistema v prihodnje vzdržuje sam ali z drugim izvajalcem, ne da bi bil vezan na enega ponudnika.

Kako izbrati izvajalca za presojo in uskladitev dostopnosti#

Pri izbiri izvajalca za projekt dostopnosti je smiselno preveriti, ali ponudnik obvlada celoten obseg dela - od presoje in QA testiranja do popravkov v kodi in prilagoditve vsebine - ali pokriva le del procesa. Projekt je mogoče prevzeti v celoti ali kot posamezen sklop, na primer samo presojo ali samo popravke po že opravljeni presoji drugje. Izkušnje z javnim sektorjem, na primer razvoj interaktivnih vsebin za javni prostor pri projektu za Občino Sevnica, so pri tem pomembna referenca.

Naročnik naj od izvajalca zahteva opredelitev, kako bo potekalo poročanje o napredku, kdo bo določen za projektnega vodjo in kako se bodo ugotovitve presoje razvrščale po nujnosti. To naročniku omogoča primerjavo ponudb na podlagi procesa, ne le na podlagi obljubljenega rezultata.

Priporočljivo je preveriti tudi, ali izvajalec loči presojo od popravkov - torej ali isto ekipo, ki je pripravila popravke, uporabi tudi za preverjanje rezultata, ali vključi ločen QA. Neodvisna presoja poveča zanesljivost ugotovitev, zlasti pri sistemih s širokim obsegom uporabnikov.

• Izkušnje z javnim sektorjem in podobnimi sistemi (portali, informacijski sistemi, kioski)
• Sposobnost izvedbe ročnega in avtomatiziranega testiranja
• Jasna delitev razvojnega, testnega in produkcijskega okolja
• Pripravljenost prevzeti obstoječ ali nedokončan sistem po pregledu kode
• Jasna primopredaja dokumentacije, dostopov in gesel ob zaključku
• Možnost dogovora o podpori in odzivnih časih po uvedbi

Kaj vpliva na ceno projekta dostopnosti#

Cena projekta dostopnosti se ne določi pavšalno, temveč po pregledu obsega in stanja obstoječega sistema. Nanjo vpliva, koliko spletišč, portalov in aplikacij je treba pregledati, koliko obstoječih sistemov je treba povezati ter ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega. Prav tako je pomembno, koliko podatkov in vsebin je treba pregledati in urediti ter kakšne so zahteve glede varnosti in revizijske sledi, ki v javnem sektorju pogosto presegajo zahteve zasebnega sektorja.

Na obseg dela vpliva tudi, ali je potreben mobilni del sistema in za katere platforme, kakšen je obseg testiranja - ali zadošča ročno testiranje ali je potreben tudi avtomatiziran in neodvisen QA - ter kakšna raven podpore po uvedbi je predvidena, vključno z dogovorjenimi odzivnimi časi. Vsak od teh dejavnikov spremeni obseg dela in s tem ceno projekta.

Pred oceno cene predlagamo krajšo analizo, ki obseg razčleni na sklope - na primer presojo, popravke v kodi, prilagoditev vsebine in testiranje - tako da je vsak sklop ocenljiv in izvedljiv ločeno. To naročniku omogoča, da projekt izvede postopoma in prilagaja obseg glede na razpoložljiva sredstva v posameznem letu.

Vzdrževanje dostopnosti po uvedbi#

Dostopnost ni enkraten projekt, temveč se mora vzdrževati ob vsaki spremembi vsebine ali funkcionalnosti sistema. Nova objava, nov obrazec ali nova funkcionalnost lahko ponovno odpre vprašanje dostopnosti, zato je smiselno, da naročnik po uvedbi uredi način spremljanja in odprave novih odstopanj, ne le enkratno uskladitev.

Po uvedbi lahko izvajalec prevzame nadzor delovanja, odpravo napak, tehnične in varnostne posodobitve ter nadaljnji razvoj sistema v okviru dogovorjenega SLA. Napake se razvrstijo v razrede glede na resnost - od izpada sistema, prek motnje pri posamezni funkciji, do manjše napake brez vpliva na poslovanje, ki se uvrsti v naslednjo redno objavo. Za spremembe in nadgradnje se obseg oceni posebej in uskladi termin izvedbe.

Vsaka sprememba gre pred objavo v produkcijo skozi pregled in testiranje, kar velja tudi za popravke, povezane z dostopnostjo. To zagotavlja, da nov popravek ne poruši že usklajenih delov sistema in da naročnik ohrani pregled nad stanjem dostopnosti skozi čas, ne le ob enkratni presoji.