Predstavitev področja in stanja digitalne dostopnosti v Sloveniji – analiza

Ideja je nastala nekaj mesecev pred GAAD, nato pa sta Tilen in Bogdan staknila glavi in določila obseg projekta. Inspiracija je bila zagotovo najbolj znan masovni test dostopnosti – WebAIM-ov projekt Million. Tilen je vzpostavil zmogljivo strežniško arhitekturo, skupaj sta zasnovala arhitekturo podatkovne baze, Bogdan pa je poskrbel za implementacijo avtomatskih preverjanj dostopnosti, ki jo bomo podrobneje pojasnili v nadaljevanju.

Metodologija merjenja stanja dostopnosti ter na kratko o orodjih

Grobe ocene stanja digitalne dostopnosti v Sloveniji kažejo na podobno stanje, kot ga lahko najdemo v svetu. Velika večina, praktično skoraj vse spletne strani in mobilne aplikacije, imajo vsaj nekaj očitnih težav z dostopnostjo ali pa so celo povsem nedostopne za skupine ljudi z oviranostmi. Predno lahko govorimo o konkretnih metodologijah merjenja stanja dostopnosti se lahko na kratko dotaknemo vseh možnosti kako se lahko dostopnost sploh da meriti:

• Dokumentirane izjave oseb z oviranostmi (torej opisane neposredne izkušnje, ko osebe naletijo na premostljive ali pa tudi povsem nepremostljive ovire, ki jih onemogočajo in s tem tudi diskriminirajo),
• Tako imenovane ročne analize strokovnjakov za dostopnost, ki zajemajo ročni pregled vseh zakonsko določenih kriterijev na podlagi vzorca strani,
• Analize narejeno s pomočjo avtomatskih orodij, ki preverjajo stanje nabora kriterijev na podlagi programske kode.

Za najboljši možni pregled stanja bi bilo idealno, če bi za vsako spletno stran / mobilno aplikacijo lahko pridobili množico podatkov pridobljenih na vse tri možne načine, vendar pa je realno stanje takšno, da je povratnih informacij od oseb bore malo, ročne analize pa so časovno precej potratne in s tem tudi drage. Poleg tega javno dostopnih ročnih analiz v celotni Sloveniji skoraj da ne najdemo.

V analizi smo se omejili na javni sektor, torej zavezance Zakona o dostopnosti spletišč in mobilnih aplikacij (ZDSMA), ker je zaenkrat zakonodaja pač omejena le na javni sektor (zakon se uporablja za državne organe, organe samoupravnih lokalnih skupnosti in osebe javnega prava po zakonu, ki ureja javno naročanje). Bralce opozarjamo, da se bo situacija kmalu spremenila in bo od leta 2025 naprej dostopnost zakonsko zahtevana tudi za dele zasebnega sektorja (še posebno banke, večje online trgovine, e-knjige, digitalne kanale transportnih podjetij itn.). Več o tem v kakšnem drugem prispevku.

Za primer časovnega obsega ročne analize lahko teoretično na grobo izračunamo porabo časa:

Če bi za preizkus vsakega od 137 kriterijev standarda EN 301 549 porabili samo eno minuto in bi morali preveriti vseh 50 url naslovov bi za takšno analizo potrebovali 6850 minut (približno 114 ur). Glede na to, da je v Sloveniji približno 3100 zavezancev bi tako ročna analiza trajala približno 353400 ur (približno 40 let, neprekinjeno 24 ur na dan).

Poleg tega se moramo zavedati tudi, da je 50 url naslovov pri nekaterih zavezancih lahko povsem premajhen vzorec, da bi bil relevanten za celotno stran.

V sami prezentaciji se pred metodologijo dotaknemo tudi Microsoftovega Inclusive Design Toolkit-a, da na ta način širša javnost spozna dejstvo o razširjenosti oviranosti. Oviranosti niso samo stalne ampak tudi začasne in situacijske. S tem dejstvom lahko potem razmišljamo o dostopnosti kot o nujnosti za vso populacijo in ne samo za osebe z oviranostmi. Ob GAAD se nam je to zdelo še posebej pomembno poudariti.

Kako torej “meriti nivo dostopnosti hitreje in bolj učinkovito? S pomočjo avtomatskih orodij. Ampak naj že v začetku poudarimo, da zgolj avtomatska orodja absolutno niso dovolj. Dajejo uporabne indikacije, odkrivajo nekatere očitne napake v kodi in so odličen pripomoček za usposobljene strokovnjake. Odsotnost napak pri takšnih orodjih nikakor ni garancija za odsotnost vseh možnih napak z dostopnostjo. Torej kljub svoji efektivnosti in uporabnosti lahko zaradi nepoznavanja dajejo lažne občutke in sporočila.

Avtomatska orodja so torej odlična za hitro in masovno preverjanje spletnih strani, kjer večinoma zelo uspešno najdejo očitne napake v sami kodi (HTML, CSS in JavaScript), še vedno pa je potrebno njihove rezultate tolmačiti in preverjati. Nenazadnje so avtomatska orodja sprogramirana in kot taka lahko tudi sama vsebujejo napake ali pa celo podajajo napačne rezultate (označijo da so našla napako na strani kjer te napake sploh ni).

Konkreten primer testa dostopnosti narejenega z avtomatskim orodjem na kodi za sliko:

1. <img src=”/slika-dogodka-2023-05-18.webp”> – avtomatsko orodje javi napako ker slika nima potrebnega atributa (alt). To je definitivno napaka.
2. <img src=”/slika-dogodka-2023-05-18.webp” alt=”slika.webp”> – avtomatsko orodje ne javi napake, ker alt atribut vsebuje “nekaj”. Nekatera avtomatska orodja imena datotek prepoznajo kot potencialne napake, vedno pa mora takšno kodo preveriti oseba, ker je treba preveriti, da je alternativno besedilo relevantno za dotično sliko in kontekst.
3. <img src=”/slika-dogodka-2023-05-18.webp” alt=””> – avtomatsko orodje ne javi nobene napake. Nekatera avtomatska orodja morda opozorijo na prazno besedilo v alt atributu. Vsekakor pa mora tukaj zopet človek presoditi ali je slika res dekorativna ali ne.

Večina avtomatskih orodij vsebuje torej podobne teste, ki preverjajo kodo in kako se ta odraža v brskalniku. Testi so torej lahko v teoriji tudi napačni ali pa ne pokrivajo vseh scenarijev. Hkrati je trenutno pri takšnih testih težko ali pa celo nemogoče umeščati elemente spletne strani v kontekst strani, kar zopet omejuje zanesljivost in kakovost. Vsekakor pa so avtomatski testi neprecenljivi ko gre za preverjanje kode in večkrat odkrijejo napake, ki jih tudi ročni testi težje najdejo. Na primer neveljavni ARIA atributi oz. njihove kombinacije, podvojene vrednosti id atributov in podobne težave v kodi.

Različna orodja uporabljajo različne teste in s tem se tudi rezultati testov med orodji včasih razlikujejo. Hkrati je ena od razlik med orodji tudi kako poročajo morebitne napake. Nekatera orodja tako stremijo k poročanju le res dejanskih napak, spet druga pa poročajo tudi morebitne napake. Takšna raznolikost še poveča potrebo po tolmačenju rezultatov s strani oseb, ki so specializirane za spletno dostopnost. Accessibility Conformance Testing”(ACT) skupina pri Kozorciju za svetovni splet (W3C) se sicer trudi vse takšne teste poenotiti in s tem zmanjšati razlike med orodji. V ACT skupino so sicer vključena nekatera orodja, niso pa del skupine vsa orodja, še posebej to velja za ne-odprtokodna orodja. Tako lahko predvidevamo, da bodo rezultati med orodji različni tudi v prihodnosti. Hkrati se lahko zavestno odločamo, da uporabljamo orodja, ki so narejena v skladu z ACT, ker nam to sporoča, da bo naše orodje temeljilo na konsenzih skupine, ki je del konzorcija.

Za našo analizo smo najprej potrebovali nabor domen zavezancev, ker takšni seznami še niso na voljo javnosti. Nato smo sprogramirali orodje, ki vse te domene pregleda in poda do 50 spletnih naslovov za vsako domeno. Naslednji korak je bila implementacija avtomatskega preverjanja dostopnosti in shranjevanja takšnih poročil v podatkovno bazo. Zadnji korak je bil zagon skript, ki so preverjale prav vsako url povezavo in zanjo zbirale podatke o dostopnosti.

Podobne analize na svetovnem nivoju milijona najpopularnejših domačih spletnih strani letno objavlja tudi organizacija WebAIM preko svojega projekta Million. Njihovo orodje za avtomatsko preverjanje dostopnosti je eno izmed najbolj znanih, a žal ni odprtokodno, zato smo za naše teste izbrali drugo, odprtokodno, imenovano axe podjetja Deque .

Rezultati analize stanja dostopnosti spletnih strani v Sloveniji

Pred samo analizo smo pričakovali podoben rezultat, kot ga je letos objavil WebAIM v svojem projektu Million, kjer so ugotovili, da ima 96,3% spletnih strani z avtomatičnimi orodji zaznane napake. Po naših izkušnjah iz prakse smo že pred rezultati analize na grobo ocenjevali, da je situacija v Sloveniji podobna, ocenili smo namreč, da je približno 95% vseh spletnih strani zavezancev ZDSMA nedostopnih.

Ker javno dostopnih podatkov o domenah vseh približno 3100 zavezancev ni moč dobiti smo se najprej lotili zbiranja vseh relevantnih domen. Nabrali smo jih 1138, kar je statistično precej relevanten nabor. Z testiranjem smo pričeli par mesecev pred dogodkom GAAD.

Ker imajo nekatere domene ogromno povezav (URLjev), nekatere pa sploh ne, smo se odločili, da bomo pri vsaki domeni preverjali le do 50 URLjev. Tako se nam je nabralo kar 25541 URLjev in prav vsakemu smo z našim orodjem “izmerili dostopnost”. Torej na domeno smo povprečno preverili okoli 22 URLjev.

Od vseh 25541 preverjenih URLjev je avtomatsko preverjanje dostopnosti samo za 53 URLjev javilo, da so brez kakršnihkoli napak. To torej pomeni, da sta samo 2.075 promila vseh preverjenih URLjev brez očitnih napak – kar pa še ne pomeni, da je teh 53 URLjev dejansko brez napak, če jih preverimo ročno. Roko na srce – tudi samodejna preverjanja v določenih primerih javljajo napake kjer dejansko ni napak. Ampak takšne situacije so vseeno redke.

Vsekakor nam ta analiza lahko služi kot zelo solidna indikacija stanja dostopnosti med zavezanci.

Zanimivo je tudi dejstvo, da sta za vsemi 53 URLji le dve organizaciji, ena spada med šolstvo, druga pa med digitalno storitev javnega sektorja. Očitno torej imamo vsaj dve organizaciji v Sloveniji, ki sta posvetila nekoliko pozornosti dostopnosti, vsaj kjer se le-ta lahko preverja s samodejnimi orodji.

Sektor	WCAG 1.1.1	WCAG 1.3.1	WCAG 1.4.1	WCAG 2.1.1	WCAG 2.4.4	WCAG 4.1.2
Javni	8036	5850	6162	5	23441	44522
Zasebni	6723	3349	1982	68	11900	27423

Še kot postranska zanimivost: pri analizi se je tako nabralo za približno 20GB podatkov. Za lažjo predstavo lahko rečemo, da bi s temi podatki lahko pokrili širino dveh nogometnih igrišč, če bi vse skupaj natisnili na A4.

Čisto za konec današnjega povzetka pa še eno pomembno dejstvo. Kljub večletnim naporom mnogih veteranov spletne dostopnosti se samodejno testiranje le stežka približuje 30% pokritosti vseh zahtev po WCAG. Prosimo vas torej za previdnost pri hitrih rešitvah, kot so na primer vtičniki za dostopnost, ker samodejna orodja kljub vsemu razvoju nikakor ne morejo pokriti vseh petdeset zahtev.