Veebilehe ligipääsetavuse tagamine arendaja perspektiivist

Maailmas on umbes 1 miljard inimest, kellel on mingi puue ja nendest ainuüksi vaegnägijaid on 285 miljonit. Puuetega inimeste kogemus veebis brausimisest erineb enamasti drastiliselt nendest, kellel pole puuet. Arendajatel lasub suur osa vastutusest, et teha veeb kõikidele sellistele inimestele paremini ligipääsetavaks.

Käesolevas postituses räägime sellest, mida tähendab veebisaidi ligipääsetavuse tagamine arendaja perspektiivist ning toome näiteid, mida iga veebiarendaja saab teha selleks, et veebi ligipääsetavamaks muuta.

Semantilise ja tähendusrikka HTML5 kasutamine

Semantilise HTML-i kasutamine on ligipääsetavuse vundament, aga ometi liiga vähestel veebisaitidel on see paigas. Lõviosa veebi sisust on võimalik muuta ligipääsetavaks, tehes kindlaks, et igal ajal kasutatakse õigeid HTML elemente õiges kohas.

Eriti nüüd, React-i ja teiste raamistike ajastul, on lihtne kirjutada ebakorrektset HTML5 koodi, kuna CSS-i ja JavaScripti abil on võimalik iga <div> element panna käituma nii nagu vaja. Veebisait töötab ka <div> elemente kasutades, milleks vaevuda? Kui jätta kõrvale veebisaidi ligipääsetavaks tegemine, siis ainuüksi juba sellepärast, et luua midagi ilusat, mille üle saab arendajana uhkust tunda.

Hea CSS muudab halva HTML-i tavalisele veebi külastajale nähtamatuks. Kuid ükskõik kui hästi või kui palju CSS-i kirjutada ei muutu sellest halb HTML otsimootorite, ekraanilugerite või tõlkemasinate jaoks tähenduslikumaks.

Semantilise HTML-i kirjutamine tähendab luua veebi sisu, millest saavad aru nii inimesed kui ka arvutid. HTML5 on sisend, millest kõik seadmed lähtuvad, et veebisaidist aru saada. Arvutid, nutitelefonid, nutikellad, ekraanilugerid, targad kõlarid, autode kompuutrid ja tulevikus kas või külmkapid või muud seadmed, mis interneti sisu tarbivad. Korrektse HTML5 kirjutamine on oluline mitte ainult ligipääsetavuse, vaid ka jätkusuutlikkuse ning tulevikukindluse mõttes.

Semantiliste täägide kasutamine

Vaikimisi ei saa <div> ja <span> tääge (tag) klaviatuuriga valida. Üks elementaarne näide on järgmine: <div>Play</div> on võimalik ekstra CSS-i ja JavaScriptiga õigesti tööle panna, aga <button>Play</button> on palju parem ja mõistlikum valik, sest:

1. Sellist HTML-i on lihtsam kirjutada, sest korrektsetel täägidel on vaikimisi juba küljes neile vastav funktsionaalsus ja teatavad stiilid. Kasutajad saavad vaikimisi <button> elemendile TAB-i kasutades navigeerida ning neid aktiveerida ENTER nuppu vajutades. Lisaks on selline semantiline kood ka paremini loetav.
2. Töötab mobiilis üldjuhul paremini, sest see on mahult väiksem=kiirem, kui DIV-st JavaScripti ja ekstra CSS-ga nupuks muudetud “spageti” kood.
3. See on kasulik SEO jaoks, kuna otsimootorite jaoks on suurem tähendus semantiliste elementide sees oleval sisul, kui sisul, mis on tavapäraste DIV-de sees. See muudab info ja lehe kasutajate jaoks leitavamaks.

Kasutades soovitud funktsionaalsuse jaoks õigeid elemente saab vältida lisategevusi, sellega seonduvat ajakulu ja probleeme, mis tulenevad valede elementide ligipääsetavaks tegemisest.

Nupu jaoks <div> täägi kasutades tuleks kõigepealt sellele lisada tabindex parameeter, mis võimaldab seda elementi TAB-i kasutades leida. Seejärel tuleks kirjutada pisut JavaScripti, et enterit vajutades oleks võimalik seda nuppu aktiveerida. Kasutades aga <button> täägi on sellised ligipääsetavuse jaoks vajalikud funktsionaalsused vaikimisi saadaval.

DIV-d loovad tähendusetu DOM-i

Modernse veebisaidi lihtsustatud struktuur näeb välja midagi sellist:

<header>
 <h1>Header</h1> 
</header>

<nav>
 <!-- main navigation in here --> 
</nav>

<!-- Here is our page's main content -->
<main>
 <!-- It contains an article --> 
 <article> 
  <h2>Article heading</h2>  
  <!-- article content in here --> 
 </article> 
 <aside> 
  <h2>Related</h2>  
  <!-- aside content in here -->  
 </aside> 
</main>

<!-- And here is our main footer that is used across all the pages of our website -->
<footer>
 <!-- footer content in here --> 
</footer>

Taolise struktuuri saab luua ka tavaliste <div> elementidega, kuid see ei anna ekraanilugeritele infot nende elementide sees oleva sisu kohta. Semantilised täägid nagu <header>, <nav>, <article>, jt võimaldavad ekraanilugeril hüpata veebisaidil koheselt mingi sektsiooni juurde ja käituvad nagu verstapostid. Nii saab ekraaniluger vihjeid sellest, mis sisu antud sektsiooni sees on.

Ligipääsetavuse puu

Brauserid loovad DOM-i põhjal ligipääsetavuse puu (ingl accessibility tree), mis sisaldab ligipääsetavusega seotud infot erinevate HTML elementide kohta. Seda kasutavad näiteks ekraanilugerid kasutajale info edastamiseks ja see on see “puu”, milles ekraanilugerid ja sarnased abistavad tehnoloogiad navigeerivad. Ligipääsetavuse puud saab näha Chrome Devtools-is.

Loomisel on ka AOM (Accessibility Object Model), mis tulevikus lihtsustab arendajatel ligipääsetavate veebide loomist võimaldades ligipääsetavuse puud otse läbi JavaScripti muuta.

Erivajadusega inimese kogemus

Üks põhjusi miks ligipääsetavusele liiga vähe tähelepanu pööratakse võib olla see, et arendajad lihtsalt ei näe ega saa aru, kuidas loodud veebisait töötab mingi abistava tehnoloogiaga nagu näiteks ekraaniluger.

Siinkohal on hea teha lugemisest paus ja testida ise, kuidas kogevad veebisaidil navigeerimist vaegnägijad. ChromeVox lite demo lehel on võimalik Chrome brauserit kasutades testida veebisaidi kasutamist lihtsa JavaScriptil põhineva ekraanilugeriga.

Lisaks on hea mõte loodud veebisait üle käia mingi ekraanilugeriga, nt Macis VoiceOver või Windowsis Narrator. Isegi, kui projekt ei nõua teatud WCAG taset, siis nagu öeldud, veebi ligipääsetavamaks muutmisest võidavad kõik, sest nii muutub veeb ligipääsetavamaks ka näiteks otsimootorite jaoks.

Jätkates <button> ja <div> näidet, siis ekraaniluger loeb tavaliselt ette elemendi nime ja selle tüübi. Kui näiteks kasutada <button>Liitu</button> asemel <div>Liitu</div>, siis ekraaniluger loeks ette “Liitu, group”, aga mitte “Liitu, button”, sest <div> element on selleks, et midagi grupeerida. Sellel elemendil pole küljes spetsiifilist semantikat.

Seega isegi kui <div> abil loodud nupp on visuaalselt nupu moodi ja arusaadav nägijale, siis ekraanilugerit kasutav inimene ei pruugigi üldse aru saada, et tegemist on nupuga, sest ta toetub veebisaidist arusaamisel just semantilistele täägidele.

ARIA atribuudid

Selleks, et muuta HTML täägide semantikat, näiteks <div> semantika <button> omaks, tuleb kasutada ARIA atribuute. ARIA õppimiseks on hea kasutada W3C WAI-ARIA praktilist juhendit, kus on vastavalt kasutusjuhule või komponendile näidatud, kuidas ja milliseid ARIA atribuute peaks kasutama.

ARIA kasutamise reegel nr 1 on, et kasutada ARIA-t nii vähe kui võimalik. Kui on olemas HTML lahendus, siis tuleks seda kasutada. ARIA atribuudid ei ole mõeldud selleks, et halba HTML-i parandada. ARIA vale kasutamine võib ligipääsetavuse seisukohast asjad hoopis halvemaks muuta.

Järgnevalt toome välja mõned ARIA atribuutide kasutusvõimalused.

aria-label

Paljude elementidega pole võimalik kasutada <label> täägi. Näiteks, kui luua tavapärane hamburgeri menüü nupp, siis ekraanilugerit kasutades nupule navigeerides ütleb see kasutajale lihtsalt “button”. Selleks, et kasutaja saaks aru, et tegemist on menüü nupuga tuleks lisada aria-label atribuut. Siis loeb ekraaniluger kasutajale ette näiteks “Peamenüü, button”, mis muudab nupu funktsiooni kohe arusaadavaks.

<button id=”menu-btn” aria-label=”Peamenüü”></button>

aria-labelledby

Kasulik, kui on vaja siduda omavahel mitu labelit või viidata mingile teisele labelile. Kui visuaalselt vaadates võib mingi nupu, checkboxi, või muu interaktsiooni võimalusega elemendi eesmärk olla väga selge, siis ekraanilugeriga veebisaidil navigeerides ei tea kasutaja kui kaugel visuaalselt teineteisest mingid elemendid on.

Poolik näide, mis illustreerib aria-labelledby kasutamist:

<p>Palun valige <span id="durationslider-label">reisi kestus päevades</span></p>
<div id="durationslider" role="slider" aria-labelledby="durationslider-label"></div>

aria-live

Üha enam saavad populaarsemaks üheleherakendused (ingl Single Page Apps) ja sellised lahendused, kus veebilehe sisu muudetakse dünaamiliselt API kaudu.

Dünaamilised muudatused saab kasutajani viia aria-live atribuuti kasutades. Kui aria-live elemendis olev sisu muutub, siis ekraaniluger annab sellest kasutajale teada.

<div aria-live=”polite”>
 <p>Muutuv tekst.</p> 
</div>

Aria-live võimalikud väärtused on “polite” ja “assertive”. Kui aria-live=”polite”, siis muudatused öeldakse kasutajale siis, kui kasutaja on tegevusetu (ingl idle). Kui aria-live=”assertive”, siis muudatused edastatakse esimesel võimalusel.

DOM-i testimine

Lisaks üldtuntud tööriistadele ligipääsetavuse testimiseks on arendaja jaoks suurepärane tööriist axe tarkvara, mille saab Chrome extensioni kaudu lisada inspektorisse ja seda sealt mugavalt kasutada. Axe toob Chrome Devtoolsis välja ligipääsetavusega seotud probleemid.

See tööriist on näiteks Google arendajate poolt kiidetud kuna axe mantra on “no false positives”. Axe ei viska ette suvalisi erroreid, vaid kõik probleemid on ka reaalselt probleemid, mida ideaalis tuleks lahendada. Suuremates tiimides on see suur boonus, sest kõik osapooled saavad kindlad olla, et mingi viga on ka reaalselt viga, mitte testeri bug.

Axe-t saab ka integreerida automatiseeritud testimise protsessiga. Vaata lähemalt axe GitHub lehelt.

DOM Order

Oluline on ka DOM-i järjestus. Seda saab kõige paremini testida TAB-ga lehe läbi klõpsides. Võib juhtuda, et DOM-is on järjestus üks, aga visuaalselt mingi muu (CSS kaudu muudetud). Kui DOM-i järjestus on ebaloogiline, siis inimesele, kes klaviatuuriga veebisaidil navigeerib põhjustab see suure tõenäosusega segadust.