Poletna šola ARIA: kaj je ARIA in zakaj jo sploh potrebujemo?

Za večino uporabnikov so ti elementi vidni in razumljivi predvsem zaradi njihovega videza.

Gumb je oblikovan kot gumb.
Izbrani zavihek je drugačne barve.
Odprti meni se prikaže pod ikono.
Napaka v obrazcu je označena z rdečim okvirjem.
Obvestilo se pojavi na vrhu zaslona.
Rezultati iskanja se samodejno posodobijo.
Ko uporabljamo chat vidimo, da nasprotna stran piše odgovor…

Toda vsi uporabniki spletnih strani ne zaznavajo uporabniškega vmesnika predvsem vizualno.

Uporabniki različnih podpornih tehnologij, kot so na primer bralniki zaslona, mora informacije o elementih dobiti v programsko določljivi obliki. Podporna tehnologija mora razumeti:

• kaj posamezen element predstavlja;
• kako se imenuje;
• ali je interaktiven;
• v kakšnem stanju je;
• kakšna je njegova trenutna vrednost;
• kateri drugi element upravlja;
• ali se je na strani nekaj spremenilo.

Pri tem pomembno vlogo, kjer takšnih funkcionalnosti ni moč najti v samem HTML, igra ARIA.

Kaj pomeni ARIA?

ARIA je kratica za:

Accessible Rich Internet Applications

V slovenščini bi jo lahko opisali kot nabor pravil in atributov za dostopnejše »bogate« spletne aplikacije, torej napredne spletne aplikacije.

ARIA je standard Konzorcija za splet (W3C), s katerim lahko razvijalci brskalniku in podpornim tehnologijam posredujejo dodatne informacije o elementih uporabniškega vmesnika.

Z ARIA lahko na primer sporočimo:

• da je neki element zavihek,
• da gumb odpira dodatno vsebino,
• da je določeni zavihek trenutno izbran,
• da je vnos v obrazcu neveljaven,
• da element predstavlja drsnik,
• da se je na strani pojavilo pomembno sporočilo,
• da je neko območje trenutno zaposleno s posodabljanjem,
• da gumb upravlja določen meni ali razdelek,

ARIA končnim uporabnikom ni neposredno vidna. Njene informacije brskalnik posreduje prek dostopnostnega API-ja, podporne tehnologije pa jih nato uporabijo pri predstavitvi in upravljanju spletne strani.

Zakaj običajni HTML včasih ni dovolj?

HTML že vsebuje veliko dostopnih elementov.

Na primer:

<button>Pošlji</button>

Brskalnik razume, da gre za gumb.

Prav tako razume:

<a href="/kontakt">Kontakt</a>

kot povezavo in:

<h2>Naše storitve</h2>

kot naslov druge ravni.

Takšni elementi imajo že vgrajeno semantiko. Brskalnik ve, kaj pomenijo, podporne tehnologije pa lahko to informacijo posredujejo uporabniku.

HTML vsebuje tudi obrazce, tabele, sezname, navigacijska območja, segmente strani (glavna vsebina, glava, noga) in številne druge elemente z jasno določenim pomenom.

Težava nastane pri bolj kompleksnih uporabniških gradnikih, ki jih HTML (še) nima.

HTML na primer nima posebnega elementa za:

• sistem zavihkov.
• drevesni prikaz.
• napredno kombinirano polje s predlogi.
• interaktivno mrežo podatkov.
• menijsko vrstico aplikacije.
• območje, ki mora samodejno sporočiti novo vsebino
• nekatere vrste prilagojenih drsnikov in izbirnikov…

Razvijalec lahko takšne gradnike ustvari s kombinacijo elementov HTML, CSS in JavaScripta.

Toda brez dodatnih informacij podporna tehnologija ne more vedeti, kaj takšen gradnik predstavlja in v kakšnem stanju je. Torej takšna komponenta lahko deluje povsem uporabna za videče uporabnike, za podporne tehnologije pa je povsem nevidna.

Tu nastopi ARIA.

ARIA opisuje pomen uporabniškega vmesnika

Predstavljajmo si sistem zavihkov.

Vizualno lahko uporabnik takoj opazi:

• tri zavihke;
• kateri zavihek je izbran;
• kateri razdelek vsebine je prikazan;
• kam lahko klikne, da zamenja vsebino.

Uporabnik bralnika zaslona potrebuje enake informacije v programsko določljivi obliki.

Gradnik mu mora sporočiti:

• da se nahaja v seznamu zavihkov;
• da je posamezen element zavihek;
• koliko zavihkov obstaja;
• kateri zavihek je izbran;
• kateri vsebinski razdelek pripada izbranemu zavihku.

Pri tem lahko uporabimo vloge in atribute, kot so:

<div role="tablist" aria-label="Podatki o izdelku">
  <button
    role="tab"
    aria-selected="true"
    aria-controls="opis">
    Opis
  </button>

  <button
    role="tab"
    aria-selected="false"
    aria-controls="lastnosti">
    Lastnosti
  </button>
</div>

ARIA v tem primeru ne določa videza zavihkov. Prav tako sama ne poskrbi, da se bodo zavihki odzivali ko uporabimo tipkovnico.

Posreduje pa pomembne semantične informacije o njihovem pomenu – torej vlogi, stanju in medsebojnih odnosih.

Tri osnovne skupine informacij ARIA

Pri ARIA pogosto govorimo o treh vrstah informacij:

1. vlogah,
2. stanjih,
3. lastnostih.

Vloge: kaj je ta element?

Vloga pove, kakšno vrsto elementa ali gradnika predstavlja neki element.

Primeri vlog so:

role="button"
role="tab"
role="dialog"
role="alert"
role="navigation"
role="slider"

Vloga lahko podporni tehnologiji pove:

Ta element je gumb.

ali:

Ta element je zavihek.

ali:

To območje predstavlja pogovorno okno.

Pri izvornih elementih HTML vloge ni treba zapisati, ker jo brskalnik že pozna.

Na primer:

<button>Izbriši</button>

že ima vlogo gumba.

Zapis:

<button role="button">Izbriši</button>

je zato povsem odvečen.

ARIA je najbolj koristna tam, kjer potrebne semantike ne moremo ustrezno izraziti samo z izvornim elementom HTML.

Stanja: v kakšnem položaju je element?

Stanje pove, kakšen je trenutni položaj elementa ali gradnika.

Primeri so:

aria-expanded="true"
aria-selected="false"
aria-checked="true"
aria-pressed="false"
aria-invalid="true"
aria-busy="true"

Gumb lahko na primer odpira in zapira navigacijski meni:

<button
  aria-expanded="false"
  aria-controls="glavna-navigacija">
  Meni
</button>

Ko se meni odpre, se mora stanje spremeniti:

aria-expanded="true"

Podporna tehnologija lahko uporabniku nato sporoči, da je gumb trenutno razširjen oziroma da je pripadajoča vsebina odprta.

Stanja se med uporabo pogosto spreminjajo. Zato mora aplikacija skrbeti, da vrednost atributa ARIA vedno ustreza dejanskemu stanju uporabniškega vmesnika. Te spremembe stanj moramo urejati z JavaScriptom..

Lastnosti: dodatne informacije in odnosi

Lastnosti podrobneje opisujejo element ali njegovo povezavo z drugimi elementi.

Značilni primeri so:

aria-label
aria-labelledby
aria-describedby
aria-controls
aria-required

Z njimi lahko na primer:

• določimo dostopno ime;
• povežemo element z vidnim naslovom;
• dodamo opis ali navodilo;
• povemo, kateri element neki gumb upravlja;
• sporočimo, da je vnos obvezen.

Primer:

<button aria-describedby="brisanje-opis">
  Izbriši račun
</button>

<p id="brisanje-opis">
  Tega dejanja ni mogoče razveljaviti.
</p>

Uporabnik podporne tehnologije lahko poleg imena gumba prejme tudi dodatno opozorilo o posledicah dejanja.

Kako informacije pridejo do uporabnika?

Pri poenostavljenem prikazu poteka komunikacija tako:

1. razvijalec pripravi HTML in po potrebi doda ARIA;
2. brskalnik interpretira strukturo, semantiko, CSS in atribute;
3. brskalnik pripravi drevo dostopnosti (ki poda le dejansko semantiko strani);
4. operacijski sistem informacije izpostavi prek dostopnostnega API-ja;
5. bralnik zaslona ali druga podporna tehnologija jih predstavi uporabniku (in komunicira neposredno z njimi).

Uporabnik bralnika zaslona zato praviloma ne bere neposredno kode HTML.

Prejema interpretacijo, ki jo na podlagi kode pripravita brskalnik in operacijski sistem.

To je pomembno, ker lahko na videz majhna sprememba v kodi zelo spremeni način, kako podporna tehnologija element predstavi.

Element:

<div>Pošlji</div>

je v osnovi samo splošen vsebinski element.

Element:

<button>Pošlji</button>

je gumb.

Element:

<div role="button">Pošlji</div>

je podpornim tehnologijam predstavljen kot gumb, čeprav je v izvorni kodi še vedno element div.

S tem smo spremenili le njegovo programsko semantiko – manjka pa nam še interaktivnost, ki je ARIA ne doda samodejno (podpora za tipkovnico ipd.).

Komu je ARIA namenjena?

ARIA se najpogosteje omenja v povezavi z bralniki zaslona, vendar ni namenjena samo slepim uporabnikom.

Semantične informacije lahko uporabljajo različne podporne tehnologije, na primer:

• bralniki zaslona,
• programi za glasovno upravljanje,
• povečave zaslona z dodatno podporo,
• preklopne naprave,
• prilagodljive vhodne tehnologije,
• programska oprema, ki uporabniški vmesnik predstavi na drugačen način,
• agenti umetne inteligence.

Pravilno ime, vloga, stanje in vrednost lahko pomagajo uporabniku prepoznati kontrolnik, razumeti njegov namen in ga upravljati z načinom, ki mu je dostopen.

ARIA ni ločena plast, ki nadomesti HTML

ARIA ne bi smeli razumeti kot nadomestek za HTML.

Praviloma velja naslednji vrstni red:

1. najprej izberemo ustrezen element HTML;
2. nato zagotovimo pravilno strukturo in vedenje;
3. ARIA dodamo samo tam, kjer moramo posredovati dodatne informacije.

Če potrebujemo običajen gumb, uporabimo:

<button>Odpri meni</button>

Če gumb odpira in zapira meni, lahko osnovni element dopolnimo:

<button
  aria-expanded="false"
  aria-controls="meni">
  Odpri meni
</button>

HTML zagotovi osnovni gumb. ARIA doda informacijo o stanju in povezavi z menijem.

To je tipičen primer dobrega sodelovanja med HTML in ARIA.

ARIA ne določa videza

Atributi ARIA sami po sebi praviloma ne spremenijo tega, kar uporabnik vidi.

Če dodamo:

aria-invalid="true"

polje zaradi tega ne bo samodejno dobilo rdečega okvirja.

Če dodamo:

aria-expanded="true"

se vsebina ne bo samodejno odprla.

Če dodamo:

role="dialog"

element ne bo postal vidno pogovorno okno.

Za vizualni prikaz je odgovoren CSS, za delovanje in spremembe stanj pa običajno JavaScript in vedenje izvornih elementov HTML.

ARIA predstavlja predvsem semantični opis uporabniškega vmesnika za brskalnike in podporne tehnologije.

ARIA sama ne zagotovi dostopnosti

Pravilno uporabljena ARIA je pogosto nujen del dostopnega gradnika, ki nam ni na voljo v HTML. Sama po sebi pa ni dovolj.

Dostopen gradnik mora poleg ustrezne semantike zagotavljati tudi:

• uporabo s tipkovnico;
• logično upravljanje fokusa;
• vidno označen fokus;
• razumljiva navodila;
• ustrezne barvne kontraste;
• pravilno posodabljanje stanj;
• razumljive napake in povratne informacije;
• dovolj velike ciljne površine;
• združljivost s podpornimi tehnologijami.

ARIA je torej pomemben del dostopnosti, ni pa sinonim za dostopnost.

Dodajanje atributa ARIA še ne pomeni, da je element dostopen.

Enako pa tudi odsotnost atributov ARIA ne pomeni nujno, da stran ni dostopna. Dobro strukturirana stran, izdelana z izvornimi elementi HTML, lahko za številne vsebine in osnovne gradnike potrebuje zelo malo dodatne ARIA in je lahko mnogo bolj robustna.

Zakaj ARIA razvijalcem pogosto povzroča težave?

ARIA je videti preprosta.

Atribut:

aria-label="Zapri"

lahko dodamo v nekaj sekundah.

Toda njegova pravilna uporaba zahteva razumevanje:

• kako nastane dostopno ime (algoritem prioritet);
• katera semantika že obstaja;
• ali atribut prepiše drugo informacijo;
• kateri elementi atribut podpirajo (je ARIA atribut sploh dovoljen);
• ali se stanje med uporabo spreminja;
• kaj bo podpornim tehnologijam dejansko posredoval brskalnik;
• kako se mora gradnik upravljati s tipkovnico.

Zato se v praksi pogosto srečujemo z dvema skrajnostma.

Na eni strani so razvijalci, ki se ARIA popolnoma izogibajo, ker se jim zdi preveč zapletena.

Na drugi strani so rešitve, pri katerih so atributi ARIA dodani skoraj vsakemu elementu, tudi kadar niso potrebni ali so napačni. Slednje je po naših izkušnjah tudi velikokrat posledica napačne uporabe umetne inteligence za generiranje kode.

Namen Poletne šole ARIA je poiskati strokovno in praktično sredino:

uporabiti pravilen HTML, razumeti semantiko in ARIA dodati premišljeno tam, kjer uporabniku dejansko posreduje koristno informacijo.

Kaj bomo obravnavali v Poletni šoli ARIA?

V naslednjih člankih bomo posamezne koncepte predstavili na praktičnih primerih.

1. Kaj je ARIA in zakaj jo potrebujemo?

V uvodnem članku smo spoznali vloge, stanja, lastnosti in drevo dostopnosti.

2. Pet pravil varne uporabe ARIA

Zakaj izvorni HTML praviloma uporabimo pred ARIA in kako lahko napačna vloga uporabniku posreduje zavajajoče informacije.

3. Dostopno ime

Kaj uporabnik podporne tehnologije sliši kot ime gumba, povezave ali polja in kako se to ime izračuna.

4. aria-label, aria-labelledby in aria-describedby

Kakšne so razlike med njimi, kdaj jih uporabimo in kako lahko aria-label prekrije obstoječe besedilo.

5. aria-expanded in razkrivanje vsebine

Kako pravilno označiti gumbe, menije, harmonike in druge elemente, ki odpirajo ali zapirajo vsebino.

6. aria-current, aria-selected, aria-checked in aria-pressed

Štirje na videz podobni atributi, ki imajo zelo različne pomene.

7. Žive regije, role="status" in role="alert"

Kako uporabnika obvestiti o spremembah, ki nastanejo brez ponovnega nalaganja strani.

8. Dostopni zavihki

Vloge tablist, tab in tabpanel, pričakovano upravljanje s tipkovnico ter pravilno spreminjanje stanj.

9. Modalna pogovorna okna

Uporaba elementa dialog, aria-modal, dostopnega imena in pravilno upravljanje fokusa.

10. Kombinirana polja in samodejni predlogi

Zakaj je combobox eden zahtevnejših vzorcev ARIA in kako deluje aria-activedescendant.

11. aria-hidden, role="presentation" in skrivanje vsebine

Razlika med vizualno skrito vsebino, odstranitvijo iz drevesa dostopnosti in izgubo pomembne semantike.

12. Kako ARIA dejansko testiramo?

Pregled drevesa dostopnosti, uporaba tipkovnice, preverjanje z bralnikom zaslona in omejitve avtomatiziranih orodij.

ARIA je jezik pomena

Najpomembnejša misel uvodnega članka je preprosta:

ARIA je jezik, s katerim podpornim tehnologijam opisujemo pomen, stanje in odnose v uporabniškem vmesniku.

Ne nadomesti pravilnega HTML.

Ne nadomesti JavaScripta.

Ne nadomesti uporabe s tipkovnico.

Ne nadomesti testiranja.

Pomaga pa brskalniku in podpornim tehnologijam razumeti gradnike, ki bi bili brez dodatne semantike za nekatere uporabnike nejasni ali povsem nevidni.

V naslednjem delu bomo pogledali pet osnovnih pravil, ki nam pomagajo preprečiti najpogostejše napake pri uporabi ARIA.