Spletna dostopnost (2. del): razvoj dostopne spletne strani

Razvoj dostopne spletne strani
Profile picture of blog post author
Avtor:
Tjasa
Objavljeno:
21 Apr 2020
Digitalno

V prvem delu smo si ogledali zakonsko ureditev in standarde spletne dostopnosti, v drugem delu pa bomo malo bolje spoznali uporabnike z ovirami ter s kakšnimi izzivi se ti lahko na spletu srečujejo. Pri razvoju dostopnih spletnih strani je potrebno razumeti uporabnike, enako pomembno pa je tudi razumeti, na kakšen način s spletno stranjo upravljajo. Testiranje spletne strani namreč pogosto poteka skozi oči teh uporabnikov in bolje kot jih razumemo, bolj prilagojena bo lahko naša spletna stran.

Uporabniki z ovirami

Da bi lahko naredili spletno stran ali aplikacijo dostopno za vse, se moramo najprej zavedati uporabnikove perspektive ter ovir, s katerimi se ti lahko na spletu srečujejo.

Poznamo več vrst ovir, s katerimi se uporabniki lahko srečujejo:

  • vizualne,
  • slušne,
  • kognitivne in nevrološke,
  • fizične,
  • govorne.
Uporabniki z ovirami in razvoj dostopne spletne strani

Uporabnik ima lahko eno ali več izmed naštetih tipov ovir različnih stopenj. Vsak tip ovire prinaša določene izzive: nekdo, ki slabo vidi, ima lahko probleme na primer z branjem drobnega teksta, slep uporabnik pa vsebine na spletni strani sploh ne more videti. Uporabnik, ki ima ovirano gibalno sposobnost rok, ne more uporabljati miške, gluhi in naglušni uporabniki pa ne morejo slišati video in avdio vsebine na spletu. Pri tem se je potrebno zavedati, da se vsak izmed nas v življenju vsaj enkrat sreča z določeno oviro (poškodovana roka, starostno slabšanje vida in sluha, itd.), oviranost pa lahko izhaja tudi iz trenutnih okoliščin (na primer glasna okolica nam onemogoča poslušanje video in avdio vsebin, nedelujoča miška, močna svetloba zmanjša vidljivost, itd.). Za uporabnike z ovirami je nujno, da je spletna stran dostopna, hkrati pa s tem izboljša uporabniško izkušnjo vsem uporabnikom.

Določene probleme iz naslova dostopnosti rešujemo že v fazi načrtovanja in oblikovanja spletne strani, še posebno izzive uporabnikov s kognitivnimi in nevrološkimi ovirami (pregledna in intuitivno zasnovana spletna stran s poenotenim navigacijskim sistemom, preglednimi in kratkimi spletnimi obrazci, jasnimi navodili interakcijskih elementov, prilagojenimi barvni kontrasti za barvno slepe uporabnike, itd.), spet druge pa rešujemo v fazi razvoja ter vnašanju vsebine. Pri razvoju spletne strani se moramo zavedati načinov, na katere si uporabniki spletno stran lahko prilagodijo, pa tudi različnih tehnologij, s katerimi uporabniki lahko dostopajo do spletnih vsebin, saj mora biti spletna stran kompatibilna z njimi.

Prilagoditev spletnih strani 

Najpogostejša prilagoditev spletne strani je povečava, uporabniki pa lahko tudi povečajo razmike med črkami in/ali vrsticami, zamenjajo fonte in barve, vklopijo visoki kontrast (Windows nastavitev - High contrast mode), prilagodijo funkcije tipkovnice ipd. Spletna stran mora tako biti narejena na način, ki dopušča te prilagoditve in uporabnikom nudi enake informacije, ne glede na izbrano prilagoditev. 

Nekaj nasvetov za prilagoditev:

  • Pri povečavi spletne strani je potrebno paziti, da je spletna stran vizualno prilagojena. V kolikor je spletna stran prilagojena za manjše zaslone (tablice in mobilne ekrane) bo verjetno prilagojen prikaz tudi v povečavi.
  • Paziti moramo, da fiksno pozicionirani elementi, ki nimajo opcije zapiranja (gumb za zapiranje) ne pokrivajo celotnih zaslonov.
  • Pomembna vsebina znotraj elementov ne sme biti odrezana (namesto ‘overflow: hidden’ uporabimo ‘overflow: auto’ ali ‘overflow: scroll’).

Pomožne tehnologije

Poznamo več tehnologij, s katerimi uporabniki lahko dostopajo do spletnih vsebin:

  • tipkovnica (navadna ali prilagojena za uporabnike z vizualnimi ovirami),
  • bralec zaslona (screen reader),
  • različni kazalci (ustni ali naglavni),
  • zaslonski povečevalnik,
  • enojni gumb za upravljanje (single switch device),
  • sledilniki gibanja glave in oči itd.

Različnih tehnologij je sicer veliko, a večina teh temelji bodisi na funkcionalnosti tipkovnice ali bralca zaslona. Pri razvoju dostopnih spletnih strani nam je znanje operiranja s tema dvema tehnologijama lahko v veliko pomoč, saj si na ta način lahko približamo izkušnjo uporabnika ter testiramo implementirane rešitve.

WAI-ARIA

Stoji za Web Accessibility Initiative - Accessible Rich Internet Applications in gre za set atributov, ki HTML elementom omogočajo kompatibilnost s pomožnimi tehnologijami (zlasti z bralci zaslona). Uporabnikom sporočajo vlogo posameznih elementov, dodaten opis, trenutno stanje interaktivnih elementov ter razmerja med elementi. Na podlagi teh atributov uporabniki tudi dobijo informacijo, kako z določenimi interaktivni elementi upravljati.  W3C skrbi za tehnične dokumente WAI-ARIE, v katerem so zajeti opisi in tehnične specifikacije vseh obstoječih atributov. Ta dokument dopolnjuje še WAI-ARIA-Authoring Practices,v katerem so posamezni atributi še podrobneje razloženi, dodani pa so tudi praktični primeri, v katerih poleg konkretnega primera najdemo tudi specifikacijo podpore za tipkovnice, ter korektni primer HTML, CSS in JS code (npr. primer za Listbox vlogo).

Prilagoditev za tipkovnico

Ko spletno stran upravljamo samo s pomočjo tipkovnice, je izredno pomembna jasna vidljivost fokusiranega elementa, za to da vemo, kje na strani se nahajamo, pa tudi za to, da lahko z interaktivnimi elementi upravljamo. Zaporedje fokusiranih elementov mora biti inuitivno in pričakovano (fokus zaporedje sledi strukturi HTML elementov in ne vizualni prilagoditvi), vsi interaktivni elementi pa morajo biti operativni s tipkovnico (zlasti so prilagoditve potrebne za elemente delane po meri - ne nativne). Zagotoviti moramo, da so vse interakcije, ki so na voljo uporabnikom z miško, na voljo tudi uporabnikom s tipkovnico.

Nekaj nasvetov za prilagoditev:

  • Vedno poskrbite, da so interaktivni elementi sposobni sprejeti fokus (premikanje s TAB ali Shift + TAB). Fokus sami po sebi lahko dobijo nativni HTML interaktivni elementi, kot so a, button, input, ipd., ostali elementi, kot sta npr. span in div, pa ne. Ti elementi potrebujejo tabindex atribut, vrednost katerega mora biti 0 ali višja (višjih vrednosti od 0 sicer ni priporočljivo uporabljati).
  • Ko element lahko prejme fokus, je potrebno poskrbeti tudi za vidno in jasno izraženo fokusirano stanje (brskalniki ponavadi uporabijo modro ali črno polno ali črtkano obrobo). V kolikor se odločimo odstraniti fokus stanje, ki ga določa brskalnik, moramo s CSS vedno dodati svojo alternativo (.element-selector:focus).
  • Interaktivni elementi, ki so le vizualno skriti, ne smejo prejeti fokusa. V kolikor na teh elementih ne uporabimo ‘display: none’ ali ‘visibility: hidden’, ki element skrijejo tudi za tipkovnico, moramo elementom določiti tabindex atribut v vrednosti -1.
  • Zaporedje fokusiranja naj odraža HTML strukturo, ali pa zaporedje fokusiranja prilagodite s pomočjo JS tako, da bo odražal vidno strukturo strani.
  • Namesto JS eventov, ki so specifično vezani na miško (mousedown, mouseup, itd.) uporabimo evente, ki niso specifično vezani na tehnologijo (click) ali pa dodamo enakovreden event, ki je specifičen za tipkovnico (keydown, keyup, itd.).
  • Ob prihodu na spletno stran uporabnikom zagotovimo povezavo, ki jim omogoča preskok glavne navigacije, saj se le-ta pojavlja na vseh straneh in je lahko zelo dolga (‘Skip to main content’ link).
  • Ko prilagajamo po meri narejene interaktivne elemente, upoštevamo specifikacijo za tipkovnico, zapisano v WAI-ARA dokumentaciji v priloženih primerih.
Kako spletno stran prilagoditi, da bo dostopna vsem uporabnikom?

Prilagoditev za bralnike zaslonov

Poznamo kar nekaj bralnikov zaslona. Med najpogosteje uporabljenimi so:

  • Mac: Voice Over (je že nameščen, vklopimo ga s kombinacijo tipk cmd ⌘ + F5)
  • Windows: Jaws in NVDA (potrebna namestitev)
  • Iphone: Voice Over (vklopimo v nastavitvah)
  • Android: aplikacija Talk Back (potrebna namestitev)

Bralci zaslona imajo lahko svoje ukaze na tipkovnici, zaradi česar je potrebno preveriti, ali so vsi naši eventi kompatibilni in še vedno delujoči v kombinaciji z njimi. Uporabnikom sporočajo vsebino spletne strani, pa tudi trenutno stanje interaktivnih elementov ter navodila, kako z njimi upravljati. Pri tem se zanašajo predvsem na WAI-ARIA atribute. Ker uporabniki nimajo dostopa do informacij, ki jih lahko imajo vizualni uporabniki, jim moramo te informacije zagotoviti, hkrati pa zopet velja, da informacije, ki niso vidne, vizualnim uporabnikom skrijemo tudi pred bralci zaslona.

Nekaj nasvetov za prilagoditev:

  • Vsi vizualni mediji (slike, video, itd.) na strani morajo imeti opis (alt atribut), ki mora jasno opisati kaj medij prikazuje (uporabnik mora prejeti informacijo, kaj ta medij vsebuje, ter pomembne informacije, ki jih ta medija vsebuje).
  • Teksti znotraj povezav in interaktivnih elementov morajo biti opisni (zgolj ‘Preberite več’ ni dovolj, bolje bi bilo ‘Preberite več o …’).
  • Interaktivni in strukturni elementi, ki niso semantični (header, footer, button, ul, itd.), morajo imeti role atribute, ki uporabnikom sporočajo vlogo tega elementa. Na podlagi te vloge moramo implementirati še ostale specificirane atribute in ukaze tipkovnic za interakcijo (WAI-ARIA).
  • Poskrbeti moramo, da imajo vsi interaktivni elementi informacijo o trenutnem stanju (na button elementu na primer lahko uporabimo ‘aria-expanded’ atribut).
  • Vse elemente, ki morajo biti skriti pred bralci zaslona in nimajo ‘display: none’ ali ‘visibility: hidden’, lahko skrijemo s pomočjo aria-hidden atributa.
  • Poskrbeti moramo za to, da bralci zaslona berejo samo pomembno vsebino (dekorativni elementi, kot so ikone in dekorativne slike, ki ne sporočajo bistvene vsebine, lahko ostanejo skriti: slike kot background-image ali s praznim alt atributom, lahko pa tudi z aria-hidden atributom).

Koristni pripomočki

Obstaja kar nekaj pripomočkov, ki nam poleg dokumentacije lahko pomagajo pri razvoju dostopne spletne strani in aplikacije:

Koristne povezave

Zapis o spletni dostopnosti je nastal na podlagi AgileTalka, internega izobraževanja, ki ga imamo v Agiledropu 1-krat mesečno. Pripravili sva ga Tjaša in Dea :) Spoznajte še druge ugodnosti, ki jih Agiledrop nudi razvijalcem!
 

Sorodne objave