Parema kasutuskogemuse saamiseks vaata seda lehte suurema ekraaniga.

UX reeglid

UX reeglid lehe eesmärgiks on anda suunised ning näpunäited, kuidas rakendada erinevaid sisuelemente. Nõuded on mõeldud analüütikutele ja programmeerijale kujunduselementide kasutamise näitlikustamiseks ja nendega seonduvate nõuete kirjeldamiseks.
Kokku on kogutud erinevad UX tavad ning suunised. WCAG AA 2.1 standardist tulenevad reeglid on vastavalt märgistatud.
Kasutajaliidese UX reeglid aitavad tagada ühtse, ligipääsetava, kasutatava ja kasutajatele arusaadava veebi.
Lehe peamise allikana on Trinidad Wiseman-i loal kasutatud veebisaidi https://accessibility.twn.ee/ materjale.
Vaata ka UX soovitusi.

Üldnõuded

  1. Veebileht peab olema kasutatav vähemalt 320 CSS piksli laiusel ekraanil ilma horistontaalse kerimisriba tekkimiseta või 256 CSS piksli kõrgusel ekraanil ilma vertikaalse kerimisriba tekkimiseta. (WCAG 1.4.10) Leht peab olema kohanduv (responsive). Lehte peab olema võimalik mobiilis suurendada – ei tohi kasutada meta märgendi user-scalable=”no” atribuuti. (WCAG 1.4.4)
  2. Tuleb kasutada HTML5 struktuurielemente:
    • article – suure iseseisva sisuosa jaoks,
    • section – sektsioonide eristamiseks,
    • header – päise esitamiseks,
    • main – põhisisu märkimiseks,
    • footer – jaluse märkimiseks,
    • nav – menüü jaoks,
    • aside – külgriba jaoks,
    • address – kontaktinfo (soovitatavalt e-posti aadressi) jaoks.
      Elementidele tuleb lisada pealkiri aria-label=”…” atribuudiga või kirjutada vastava pealkirja id aria-labelledby=”…” atribuuti.
  3. Vältida tuleb raame nagu frameset või ifram, sest paljud mobiilseadmed ei toeta neid ning nad on üldiselt vananenud ja problemaatilised. Kui siiski kui kasutatakse raame, tuleb neile anda kirjeldavad title=”…” atribuudid.
  4. Kujundus tuleb luua kasutades laadilehti (stylesheets), mitte style=“…” atribuute. Sisu peab olema kättesaadav ja loogilises järjekorras ka laadilehti kasutamata ehk CSS-iga ei tohi lehe sisu järjekorda oluliselt muuta (WCAG 1.3.2)
  5. Peidetud elemendile tuleb anda CSS-is nii display: none kui ka visibility: hidden stiilid, et ükski ekraanilugeja ei näeks peidetud elementi.
    UX reeglid: Peidetud elemendile tuleb anda CSS-is nii display: none kui ka visibility: hidden stiilid, et ükski ekraanilugeja ei näeks peidetud elementi.
  6. Lehel peab olema võimalik teha kõiki tegevusi (välja arvatud nt joonistamine) kasutades ainult klaviatuuri – tab klahvi või nooleklahve – (WCAG 2.1.1) ja ka ainult hiirt.
    Lehel ei tohi leiduda klaviatuurilõkse ehk olukordi, kus klaviatuuriga mingi funktsiooni juurde minna on võimalik, kuid sealt ära enam mitte. (WCAG 2.1.2)
  7. Klaviatuuri kiirvalikud ei tohi koosneda ainult tähtedest või numbritest. Lisaks tähele või numbrile peab kiirvalik sisaldama ka mõnda teist klahvi (Ctrl, Shift, Alt vms). Kui aga neid siiski kasutatakse, peab kasutajal olema võimalus neid ümber seadistada. Erandiks on kiirvalikud, mis töötavad ainult siis, kui mingi element on parajasti fookuses. (WCAG 2.1.4)
  8. Veebileht või mobiilirakendus ei tohi olla kasutatav ainult portrait või ainult landscape asendis. Erandiks on lehed, mida ei ole võimalik loomupoolest mõlemas suunas kasutada, näiteks klaveri äpp. (WCAG 1.3.4)
  9. Motoorikahäiretega kasutajal võib olla võimatu seadet raputada või keerata. Kõiki liikumise peale aktiveeritavaid tegevusi peab saama teha ka muud moodi. Nt pangaäpis saab telefoni raputades kontojääki näha, kuid on olemas ka nupp “Vaata kontojääki”. (WCAG 2.5.4)
  10. Motoorikahäiretega kasutajal võib olla keeruline liigutada ekraanil sõrmi kindlat rada pidi. Selliste liigutuste jaoks peab võimaldama alternatiivi. Nt kaardi rakenduses, kus kaardi suurendamiseks tuleb sõrmi üksteisest eemale viia, on olemas ka nupud kaardi suurendamiseks ja vähendamiseks. (WCAG 2.5.1)
  11. Päästiksündmustena tuleb vältida hiire allavajutust (onmousedown), lahtilaskmist (onmouseup), topeltklõpsu (ondblclick), kursori peale viimist (onmouseover) ja kursori eemaldamist (onmouseout), sest need pole juurdepääsetavad klaviatuuri ja tugitehnoloogiatega. (WCAG 4.1.2)
  12. Kasutajal peab olema võimalik päästiksündmust nagu hiire allavajutus (onmousedown) tagasi võtta. Nt kui nupu peale vajutada, kuid lahti laskmata nupu pealt ära liikuda, ei tohi seda lugeda nupu vajutuseks. (WCAG 2.5.2)
  13. Kui mingi elemendi peal hiirega hõljumine või millegi tab-iga fokusseerimine toob nähtavale lisasisu, siis peab kasutajal olema võimalik seda sisu kinni panna ilma hiirt või fookust liigutamata (nt vajutades ESC klahvi). Tal peab olema ka võimalus liikuda tekkinud sisu peale, ilma et see kinni läheks. Motoorikahäiretega kasutajal võib olla keeruline hoida hiirt ühe koha peal paigal või liigutada seda väga täpset rada pidi. (WCAG 1.4.13)
  14. Leht ei tohi ennast automaatselt värskendada, sest see võib kustutada kasutaja pooleli jäänud töö ning kasutada piiratud mobiilse interneti mahtu. (WCAG 2.2.1)
  15. Ei tohi kasutada animatsioone, kus info tekib ja kaob, sest kasutaja ei pruugi jõuda piiratud ajaga infot kätte saada. Kui neid siiski kasutatakse, peab olema võimalik neid välja lülitada. (WCAG 2.2.1)
    Kui veebilehe sisu laetakse osade kaupa, võib olla ekraanilugejatel keeruline lugemisjärge hoida. (WCAG 1.3.2)
  16. Miski veebilehel ei tohi miski sähvida rohkem kui 3 korda sekundis, sest see võib tekitada haigushooge. (WCAG 2.3.1)
    Sähvimist peab saama välja lülitada. (WCAG 2.2.2)
  17. Elementi fokuseerides ei tohi juhtuda midagi ettearvamatut – fookus ei tohi minna mõnele teisele elemendile, vorm ei tohi ennast ise ära saata jne. (WCAG 3.2.1)
  18. Märgistuskeeles kirjutatud kood peab valideeruma formaalseid validaatoreid (näiteks W3 validaator) kasutades. (WCAG 4.1.1)
  19. Lehe keel peab olema märgitud ISO 639-1 koodiga html elemendi lang=“…” atribuudis. (WCAG 3.1.1)
    UX reeglid: Lehe keel peab olema märgitud ISO 639-1 koodiga html elemendi lang=“…” atribuudis. (WCAG 3.1.1)
  20. Kasutajalt ei tohi nõuda hõljutamist (hover), lohistamist (drag) ega libistamist (slide), vaid peab lubama ka tavalist hiireklõpsu. Lohistamise asemel peab lubama kopeerimist ja kleepimist.
  21. Elementide suurused tuleb määrata relatiivsetes ühikutes nagu rem ja em. Eranditeks on veerised, raamid ja vooderdus (margin, border ja padding) ning pildi suurused, mis võivad olla määratud pikslites.
  22. Lehe aadress tuleb hoida võimalikult lühikesena, sest mobiilseadmetel veebilehitsejasse aadressi trükkimine on ebamugav. Lühike aadress, näiteks firma.ee peab suunama lehele http://www.firma.ee/index.html ja firma.ee/leht lehele http://www.firma.ee/leht.html. Lehe aadress peab avama alati sama temaatikaga lehe, olenemata seadmest.
  23. Kui võimalik, vältida kaasapandud objekte (nt pistikprogramme) ja skripte, sest need ei pruugi olla toetatud ning võivad pikendada lehe laadimisaega. Kui leht ei tööta ilma JavaScriptita, tuleb kasutajat sellest teavitada.
  24. Vältida tuleb hüpikaknaid ja modaale. Kui neid siiski kasutatakse, peab olema selgelt arusaadav, kuidas neid sulgeda.
  25. Mõistlik on alustada tiitlit alamlehe nimega. Nt: “Kontakt | Firmanimi OÜ” mitte “Firmanimi OÜ | Kontakt”, sest kui vahelehed on kitsad, pole viimasel juhul võimalik alamlehti üksteisest eristada.
  26. Kui lehel on teateid või vigu, tuleb need kirjutada tiitli algusesse. Nt: “1 uus sõnum | Foorum”.
  27. Veebi vaated, vormid ja nende elemendid peavad olema üle veebi ühtlustatud paigutuslikku ja kujundusliku ülesehitusega. Sama tüüpi elemendid nagu näiteks nupud, lingid, sisestusväljad, tabelid jms peavad olema veebi üleselt sarnased.
  28. Sarnaste tegevuste sooritamisviisid peavad toimima sarnaselt. Näiteks nupud “Esita”, “Kustuta”, “Tühista” peab toimina veebi üleselt ühte moodi.
  29. Kasutatud märksõnastus, sh nupu- ja vormiväljanimed, peab olema veebis ühtlustatud. Näiteks samasuguse tegevusega nupud on nimetatud ühtemoodi, samuti sisutekstide keeleline stiil peab olema sarnane.
  30. Sama tööloogika alusel sooritatavad toimingud funktsioneerivad sarnaselt. Näiteks kõigis toimingutes „Salvesta” nupule vajutades kuvatakse teade, et vorm on salvestatud.
  31. Erinevad toimingud peavad välja nägema erinevad. Näiteks peavad lingid, nupud, edasi liikumine, tagasi liikumine jms üksteisest erinema.
  32. Kasutajaliidese teenusedisaini ja graafilise disaini etappides tuleb lähtuda minimalismi põhimõttest.
  33. Kasutajaliides elementide paigutamisel peab olema lähtutud vertikaalsest ja horisontaalsest sümmeetriast.
  34. Domeeninimi võiks võimalusel olla tähenduslik nii eesti kui ka inglise keeles. Näiteks businessregister.rik.ee võiks viia äriregistri ENG lehele. Kui eesti keelt mitte valdav kasutaja soovib äriregistri lehele minna, siis domeeninimi ariregister.rik.ee ei ütle talle sisuliselt midagi.
  35. Domeeninimi peab töötama ka ilma “www“‘ta.
  36. Domeeninimi peab olema meeldejääv ja omama konteksti mõttes tähendust.
  37. Veebilehel peavad olema kergesti leitavad viited kasutustingimustele ja privaatsuspoliitikale, kuid arvestada tuleb, et tegemist ei ole lehe mõttes esmase infoga.
  38. Kasutajaliides peab andma kasutajale andmete laadimisest teada (loader), et kasutaja saaks aru, et leht ei ole hangunud vaid toimub andmetöötlus.
    Page loaderina on soovitav kuvada graafilist elementi, mitte tekstilist. Põhjus selles, et juhul, kui lehe laadimiskiirus on kiire, siis kasutajal on hetkeks näidatavat graafilist elementi lihtsam haarata, kui näiteks teksti “Laen, palun oodake”. Page loaderi puhul võib probleemiks osutuda olukord, kus page loaderit näidatakse iga kord, kuid tema kuvamise pikkus sõltub lehe laadimise kiirusest. Kui leht on kiire, siis sellisel juhul pageloader justkui “vilgub”/ilmub hetkeks ja kasutaja ei saa aru, millega tegu.
    Sellise olukorra lahendamiseks on soovitav kasutada praktikat, kus page loader ilmub (fadein, opacity 0-1) ühe sekundi vältel (0-1sek). Sellisel juhul, kui lehe laadimine on kiirem, kasutaja page loaderit ei näe, kui lehe laadimine võtab rohkem aega, on page loader talle nähtav.
  39. Kasutaja peab saama kõiki enda poolt algatatud tegevusi katkestada. Näiteks sisselogimist, avalduse koostamist jms. Lisaks brauseri akna kinni panemise võimalusele peab kasutajal olema igas vaates katkestamise/väljumise võimalus.
  40. Kasutajale peab olema lihtsasti leitav temaga seotud info, kuhu alla on kokku koondatud kõik, mida süsteem tema kohta teab ja mis võib olla kasutaja jaoks relevantne (minu asjad, profiil, konto seaded).
  41. Kaaluda, millise sisu allkirjastmine on absoluutselt vajalik ja millise sisu puhul piisab kinnitusest. Näiteks tuludeklaratsiooni esitamisel ei ole vajalik deklaratsiooni allkirjastada, sest kasutaja on autenditud ja sellega on piisavalt tugev seos tekitatud kasutaja isiku ja tahteavalduse vahel.
  42. Domeeninimedes ei tohi kasutada kirjavahemärke. Näiteks on kasutajatele keeruline sisestada aadressi reale www.e-toimik.ee, selle asemel peaks olema võimaldatud www.etoimik.ee.
  43. Veebileht peab toetama enamlevinute veebilehitsejate ja operatsioonisüsteemide kolme viimast versiooni.
  44. Veebilehel tuleb luua automaatselt genereeritav sisukaardi fail otsingumootoritele (XML sitemap).
  45. Veebirakenduse kõik avalikud osad peavad olema otsingumootorite jaoks optimeeritud.
  46. Kui on veebirakendusele on tellitud administreerimisliides, siis seal peab saama:
    • lisada ja hallata artiklite, uudiste ja kõikide muude lehe tüüpide sisu, pealkirju ning meta-kirjeldusi (keyword’e).
    • määrata võimalikult kasutajasõbralikke, lihtsaid ja lühikesi URL-e kõikidele lehtedele (ka nendele mille sisu tuleb liideste kaudu).
    • vaadata statistikat lehtede ja funktsionaalsuste, linkide, nuppude jms kasutaja poolt kasutatavate või tehtavate tegevuste jälgimiseks .

Abiinfo

  1. Kui vormivälja täitmisel tuleb kasutajal lähtuda kindlatest reeglitest, mis ei pruugi olla koheselt ilmselged, tuleb lisada abiinfo vastava vormivälja täitmisviisi kohta. Näiteks failide laadimisel, millised failiformaadid on lubatud.
  2. Kõik erialased ja kasutajale arusaamatud terminid peavad olema lahti selgitatud. Selleks võib kasutada lehel kuvatavaid tekste või näiteks süsteemiülest sõnastikku.
  3. Lehel peab olema viide, milliste õigusaktide alusel süsteem töötab.
  4. Lehel peab olema viide, kes süsteemi haldab.
  5. Abiinfo ikoonid koos avaneva lisainfoga tuleb paigutada kohtadesse, kus kasutaja võiks vajada täiendavat selgitust.
  6. Kui abiinfo kuvamiseks on kasutatud tooltipe, siis tooltipi alast välja “klikkides” peab tooltip sulguma.
  7. Lühikeste abitekstide korral on soovitatav kasutada tooltip lahendust, mis peab olema tekstiga sobivaks vormindatud nt ei tohi tooltip “venida” horisontaalselt ega vertikaalselt ebapraktiliselt suureks ning pikemate abitekstide korral tuleks infot kuvada modaalaknas. Lisaks modaalakna lahendusele võib kaaluda pikemate tekstide linkimist näiteks mõnele abiinfo portaalile või teisele süsteemi alamlehele, aga mõlemal juhul tuleb need avada uuele brauseri vahelehele.
    Lisaks abiinfo kuvamisele vormil konkreetsete osade juures on võimalik lisada ka nö “leheülene” abiinfo, kus on konkreetse lehe kohta käiv selgitus. Samas tuleks leheüleseid abisid pigem vältida, sest see on kasutajale koormav, kuna kasutaja tahab konkreetse tegevuse juures näha konkreetset infot. Üleüldiselt tuleks püüelda vähema abiinfo lisamisele ja intuitiivsema veebi poole.
  8. Lisainfo ja abiinfo kuvamisel ei tohi jääda kasutajale muljet, et ta on süsteemist ära liikunud. See tähendab, et igal ajahetkel peab kasutajale näha jääma lehe üldraamistik – näiteks päis, jalus, navigatsioon jms.

Failid

  1. Failile viitamisel/linkimisel peab olema linginime juurde lisatud failitüüp ja maht.
  2. Failide süsteemi üleslaadimisel peavad olema välja toodud lubatud failiformaadid.
  3. Failide süsteemi üleslaadimisel peab olema toodud failide lubatud maht (maht kokku ja üksiku faili maht).
  4. Failide süsteemi üleslaadimise järel peab andma kasutajale ülevaate, millised failid süsteemi lisati.
  5. Failide süsteemi üleslaadimise järel peab kasutajal olema võimalik neid sealt kustutada.
  6. Kui on nõue failide digitaalseks allkirjastamiseks süsteemi sees, peab neid olema võimalik ühe toimingu raames allkirjastada korraga.
  7. Kui vormil on failide üleslaadimise võimalus, siis kasutajale peab näitama, millise sisuga dokumente oodatakse. Näiteks loetelu dokumendi liikidest – riigilõivu kviitung, hagiavaldus jms.

Heli ja video

  1. Heli (mis kestab kauem kui 3 sekundit), videot ja animatsiooni (kerimine, vilkumine, liikumine, mis kestab kauem kui 5 sekundit) peab saama katkestada, kinni panna (WCAG 2.2.2) ning heli tugevust muuta. (WCAG 1.4.2)
  2. Veebilehel olevale helile ja videole peab lisama kirjeldava title=”…” atribuudi. (WCAG 1.1.1)
  3. Ilma helita videole või animatsioonile tuleb nägemispuudega kasutajate jaoks lisada juurde tekstiline sisukirjeldus või helifail, kus räägitakse, mis videos toimub. Näiteks video, kuidas puhastada kohvimasinat, mille taustaks on küll muusika, kuid instruktsioonid ilmuvad ekraanile tekstina – sellisele videole tuleks lisada helifail või tekstiline versioon, kus selgitatakse sõnadega kohvimasina puhastamist sama detailselt kui videos. (WCAG 1.2.1)
  4. Eellindistatud helisalvestusele tuleb lisada kuulmispuudega kasutajate jaoks transkribeeritud tekst, mis sisaldab ka helikirjeldusi nagu naer, aplaus, sammud jms. (WCAG 1.2.1)
  5. Eellindistatud helisalvestusele ja heliga videole tuleb kuulmispuudega kasutajate jaoks lisada sünkroonsed subtiitrid, kus lisaks räägitavale tekstile on kirjeldatud ka teisi helisid nagu [lapsed naeravad] või [vali rokkmuusika]. Sellised subtiitrid on nähtaval kas alati või on antud võimalus kasutajale subtiitrid sisse lülitada, kui need on videole kaasa pandud, näiteks nagu YouTube’is. (WCAG 1.2.2)
  6. Reaalajas edastatavale heliülekandele või heliga videoülekandele tuleb kuulmispuudega kasutajate jaoks lisada sünkroonsed subtiitrid, kus lisaks räägitavale tekstile on kirjeldatud ka teisi helisid nagu [lapsed naeravad] või [vali rokkmuusika]. Neid kirjutatakse ja edastatakse reaalajas. (WCAG 1.2.4)
  7. Eellindistatud videofailile tuleb lisada nägemispuudega kasutajate jaoks sama infot edasi andev tekstiline sisukirjeldus, mis asub või millele viidatakse faili vahetus läheduses või versioon videost koosvideokirjeldustega, kus dialoogi pauside ajal räägi jutustaja, mis videos toimub. (WCAG 1.2.3)
  8. Eellindistatud videofailile tuleb nägemispuudega kasutajate jaoks lisada versioon videokirjeldustega, kus dialoogi pauside ajal räägi jutustaja, mis videos toimub. (WCAG 1.2.5)

Jalus

  1. Veebi jaluses peab olema kuvatud rakenduse versiooni number.
  2. Veebi jaluses peab olema lehe haldaja kontakt.
  3. Jalusele tuleb määrata minimaalne kõrgus, et vältida olukorda, kus lühema sisulehe korral jääks jalus ekraani keskele. Jalusele fikseeritud positsiooni andmise tulemusel on eesmärgiks hoida jalus alati ekraani alumises osas.

Lingid

  1. Lingid peavad olema muust tekstist visuaalselt eristatavad ning mitte ainult teist värvi, vaid näiteks allajoonitud, paksemad või suuremas kirjas. (WCAG 1.4.1)
  2. Fokuseeritud link peab olema teistest visuaalselt eristatav. (WCAG 2.4.7)
  3. Lingi tekstist (ning seda ümbristevast kontekstist) peab saama selgelt aru, mis sellele vajutades juhtub. (WCAG 2.4.4)
    Lingi tekst peaks algama kõige tähtsama ja sisukama sõnaga. Lingi tekst ei tohiks olla lihtsalt “Kliki siia” või “Rohkem” ega lihtsalt URL, sest ekraanilugeja loeb selle ette täht haaval. Lingi tekst ei tohiks sisaldada sõna “link”, sest ekraanilugejad ütlevad, et tegu on lingiga.
  4. Külastatud ja külastamata lingid peaksid olema visuaalselt eristatavad.
  5. Sama tekstiga lingid ei tohi viia erinevatele lehtedele.
  6. Ebavajalikke ja kordavaid linke tuleb vältida – näiteks pilt ja “Loe rohkem” tekst, mis viivad samale lehele kui link ise, tuleb panna kõik ühte a märgendisse.
  7. Lehel ei tohi olla katkiseid linke, mis ei vii kasutajat õigesse kohta.
  8. Kui linke on väga palju, võiks need grupeerida nimekirja ul või ol märgendiga.
  9. Lingid ei tohi paikneda üksteisele liiga lähedal ega ka liiga kaugel.
  10. Link, mis laeb alla faili: Teavitus, et algab faili allalaadimine, peab olema lingi tekstis näha. Ära tuleks märkida ka faili suurus ning formaat, et aeglase või piiratud mahuga interneti kasutajad saaksid vältida aja- ja rahakulu.
    UX reeglid: Teavitus, et algab faili allalaadimine, peab olema lingi tekstis näha. Ära tuleks märkida ka faili suurus ning formaat, et aeglase või piiratud mahuga interneti kasutajad saaksid vältida aja- ja rahakulu.
  11. Peab olema üheselt arusaadav, mis on lingi eesmärk, mida ta teeb või kuhu ta viib. Link peab paiknema sisu suhtes õigesti (vastava sisu läheduses) ja lingi nimi peab olema sisukas.
  12. Lingid, mis viitavad sam veebilehe teisele lehele ei tohiks ettehoiatamata avaneda uues aknas või uuel vahelehel. Kasutaja ei pruugi aru saada, et on sattunud uuele lehele ning võib proovida tulutult veebilehitseja “Tagasi” nuppu kasutada. Mobiilseadmes pole tavaliselt näha, mitu akent on avatud ning nende vahel navigeerimine on ebamugav. Üks võimalus on lisada lingile informatiivne ikoon, peita see ekraanilugejate eest atribuudiga aria-hidden=”true” ning lisada sama infot edasi andev tekstiline kirjeldus, mida visuaalselt pole näha, aga mida ekraanilugejad saavad lugeda. Ikoon tuleb alati paigutada peale linki, et lugemisjärjekord oleks loogiline. 
    UX reeglid: Lisada lingile informatiivne ikoon, peita see ekraanilugejate eest atribuudiga aria-hidden=”true” ning lisada sama infot edasi andev tekstiline kirjeldus, mida visuaalselt pole näha, aga mida ekraanilugejad saavad lugeda.

    Teine võimalus on esitada lisainformatsioon lingi atribuudis aria-label=“…” ning dubleerida lingi tekst atribuudis title=“…”, et kõik ekraanilugejad loeksid välja kogu vajaliku informatsiooni.

    UX reeglid: esitada lisainformatsioon lingi atribuudis aria-label=“…” ning dubleerida lingi tekst atribuudis title=“…”, et kõik ekraanilugejad loeksid välja kogu vajaliku informatsiooni.
  13. Lingid peavad olema tavatekstist eristatud (ikoon, stiil, värv).
  14. Link, mis viib sama lehe teise kohta: Soovitatav on kasutada ülehüppamislingi tekstis nt “Liigu sisuni: …” või lisada lisainformatsioon atribuudis aria-label=“…” ning dubleerida lingi tekst atribuudis title=”…”.
    UX reeglid: Soovitatav on kasutada ülehüppamislingi tekstis nt “Liigu sisuni: …” või lisada lisainformatsioon atribuudis aria-label=“…” ning dubleerida lingi tekst atribuudis title=”...”.
  15. Veebist välja viitavad lingid peavad avanema veebilehitsejas uuel vahelehel.
  16. Lingipealkirja kõrval kuvatav ja sellega seotud pisipilt peab olema samuti lingiks muudetud. Ehk kasutaja peab saama edasi liikuda ka pildil klikkides.
  17. Menüüpunkt ja sellega seotud ikoonike peavad linkima mõlemad samale sisule.
  18. Loeteludes, sh menüüdes peavad linginimed üksteisest visuaalselt hästi eristatud (vahed, jooned jms).
  19. Linkide pealkirjad ei tohi paikneda menüüdes rohkemal kui kahel tekstireal.
  20. Kasutada ei tohi pikemaid kui 4 sõnalisi linginimesid.
  21. Linginimedest peavad olema eemaldatud mõttetud kordused.

Modaalaknad

  1. Modaalakendest väljapoole ei tohi tekkida elementidel fockus olekut.
  2. Kui modaalaken on avatud, siis modaalakna all oleval lehel ei tohi kasutaja saada kerimist (scroll) kasutada.
  3. Modaalakna avades peab olema selle taha jääv taust tumendatud, et aken oleks lihtsasti eristatav ja taustal olev sisu ei tõmbaks tähelepanu.
  4. Modaalakna sulgemiseks peab sellel olema vastav nupp, lisaks peab saama akent sulgeda Esc klahviga ja vajutades hiirega modaalakna alast välja poole jäävale alale.
  5. Modaalaknas tuleb vältida sisu jagamist lehtedele (paging) ja vahelehtedele (tabs) ning modaalaknasse tekkivat scrolli.

Navigatsioon

  1. Navigatsioon peab olema lihtne ja ühtne üle terve veebilehe. Navigatsioon peab lehele minnes olema kohe näha ja see tuleb paigutada see lehe ülaserva või vasakule. Menüüpunktide järjekord ei tohi erinevatel alamlehtedel erinev olla. (WCAG 3.2.3)
  2. Igal lehel peal olema informatiivne ja lehte kirjeldav tiitel title märgendina. (WCAG 2.4.2) 
    UX reeglid: Igal lehel peal olema informatiivne ja lehte kirjeldav tiitel title märgendina.
  3. Konkreetse lehe leidmiseks peab olema vähemalt kaks võimalust: lisaks menüüle näiteks otsing, sisukaart (mis töötab ilma JavaScriptita) või jäljerada (breadcrumbs). Erandiks on leht, mis on mingi protsessi samm või tulemus. (WCAG 2.4.5) 
    UX reeglid: Konkreetse lehe leidmiseks peab olema vähemalt kaks võimalust: lisaks menüüle näiteks otsing, sisukaart (mis töötab ilma JavaScriptita) või jäljerada (breadcrumbs).
  4. Menüüpunktid peavad olema sõnastatud nii, et oleks selge, mis nende all leidub. (WCAG 2.4.4, 2.4.6)
  5. Kui megamenüü avaneb hiirega menüüpunkti kohal hõljudes (hover), peab see avanema ka tab-iga menüüpunktile liikudes. Kasutajal peab olema võimalik megamenüü kinni panna ilma hiirt või fookust liigutamata (nt vajutades ESC klahvi). Kasutajal peab olema võimalus liikuda megamenüü peale, ilma et see kinni läheks. Parem variant on panna megamenüü avanema menüüpunktile vajutades. (WCAG 1.4.13)
  6. Lehe kõige esimene element peab olema link “Liigu põhisisu juurde”, mis teeb tabuleerivate kasutajate jaoks infoni jõudmise lihtsamaks. Sisu, mis kordub mitmel leheküljel, peab saama vahele jätta kasutades mugavaid ülehüppamislinke, näiteks “Jäta … vahele”. Kuigi need lingid võiksid olla alati nähtavad (nägijate jaoks, kellel on raske klaviatuuri kasutada), võib need ka visuaalselt peita. (WCAG 2.4.1) 
    UX reeglid: Lehe kõige esimene element peab olema link “Liigu põhisisu juurde”
  7. Tihedamini külastatavad lehed tuleb teha kiiresti kättesaadavaks, kuid harvem kasutatavate lehtedeni jõudmiseks võib minna rohkem aega (nt kiirlingid).
  8. Otsingukasti juures peab olema selgelt arusaadav, kuidas otsingut käivitada, lisaks peab otsing käivituma enter klahvi vajutusega.
  9. Otsing peab leidma vasteid ka lähedastele otsingusõnadele. Näiteks vaste “nina-kõrva-kurguarst” peab leidma ka kasutades otsingusõna “kurgu-nina-kõrvaarst”.
  10. Juurdepääsetavaim viis navigatsioon esitamiseks on nav role=“navigation” aria-label=“…” märgendiga, mille sees on ul märgendiga esitatud nimekiri. Alammenüüga elemendile võiks lisada aria-haspopup=“true” atribuudi. 
    UX reeglid: Juurdepääsetavaim viis navigatsioon esitamiseks on nav role=“navigation” aria-label=“...” märgendiga, mille sees on ul märgendiga esitatud nimekiri.
  11. Vältida tuleb mitmetasemelisi menüüsid – jääda ühe või kahe taseme juurde.
  12. Veebi keelt vahetades peab kasutaja navigatsiooni mõttes jääma samale vaatele, millelt ta keelt vahetas.
  13. Kui kasutajal on võimalik liikuda ühest süsteemist teise, peab ta igal ajahetkel aru saama, millises süsteemis ta parasjagu on. Arusaadavust toetab vastava lehe päis, logo, lehe pealkiri jms.
  14. Hetkel avatud menüüpunkt peab olema teistest menüüpunktidest koheselt eristatav.
  15. Igal veebi lehel peab olema logo, mis lingib avalehele.
  16. Igal veebi lehel peab olema link avalehele.
  17. Avalehel peab olema link “avalehele” peidetud.
  18. Keerulisemates veebides peab olema kasutusel sisukaart.
  19. Sisukaart peab kajastama veebi sisukorda menüüstruktuuri põhiselt.
  20. Veebis peab olema kasutusel üks menüü. See tähendab, et sama menüü ei tohi olla kuvatud topelt, näiteks vasaku menüüna ja ülemise menüüna korraga.
  21. Menüüs peab olema kasutatud erinevaid pealkirju st erinevad menüüpunktid ei tohi olla sama nimetusega.
  22. Tagasitee tähised (breadcrumbs) peabolema kasutajale kuvatud, kui kasutajal on võimalik navigeerida sügavamale, kui kaks taset.
  23. Tagasitee tähised peavad olema kuvatud iga veebilehe ülemises osas.
  24. Tagasitee tähised peavad kajastama korrektselt veebi menüüstruktuuri st samme ei tohi vahelt ära jätta.
  25. Tagasitee tähistes peavad olema menüüpunktid arusaadavalt eraldatud st tagasitee tähised ei tohi olla kuvatud sellise stiiliga, et neid võiks segi ajada menüüga.
  26. Samalt lehelt samale lehele viitavaid linke olla ei tohi.
  27. Tagasitee tähised peavad olema linkidena, mis viivad lehel vastava sisuni.
  28. Veebilehitseja “back” nupuga peab saama veebis navigeerida.
  29. Kui lehe sisuosa on väga pikk, siis peab veebi menüü (nii ülemise menüü korral, kui vasaku menüü korral) lehe kerimisega kaasa liikuma.
  30. Kui lehe sisuosa on väga pikk, siis peab lehe kerimisel ilmuma “tagasi üles” nupp (lehe paremal allosas), millega kasutaja saab mugavalt suunduda lehe algusesse tagasi.

Nupud

  1. Nupud ja muud funktsionaalsed elemendid peavad kogu lehe ulatuses olema sarnased ja äratuntavad. (WCAG 3.2.4)
  2. Nupud peavad olema vähemalt 44 x 44 CSS piksli suurused ja piisavalt suurte vahedega, et neid oleks puutetundlikul ekraanil mugav vajutada.
  3. Nupu peal olev tekst ja koodis olev nimi peavad olema identsed või vähemalt algama samamoodi. Nt kui nupu tekst on “Saada” ja “name” atribuut on “Saada_vorm”, siis helilist sisendit kasutav inimene saab öelda “Saada” ja nupp aktiveerub. (WCAG 2.5.3)
  4. Nupul peavad olema selgelt visuaalselt eristatavad fokuseeritud (WCAG 2.4.7) ja aktiivne olek. 
    UX reeglid: Nupul peavad olema selgelt visuaalselt eristatavad fokuseeritud
  5. Kui nupu sees on teksti asemel ikoon, pilt või üksik täht, tuleb nupule anda atribuut aria-label=“…”, et nupu funktsioon oleks ekraanilugejat kasutavale inimesele mõistetav. (WCAG 1.3.3) 
    UX reeglid: Kui nupu sees on teksti asemel ikoon, pilt või üksik täht, tuleb nupule anda atribuut aria-label=“…”, et nupu funktsioon oleks ekraanilugejat kasutavale inimesele mõistetav.
  6. Nupud tuleb esitada button või input type=“button” märgendiga. Mitte kasutada a role=“button” märgendit nupu esitamiseks, sest ekraanilugejaga kasutaja võib nupu vajutamiseks kasutada space klahvi, mis linki aga ei aktiveeri. Nuppu ei tohi esitada div või span märgendiga, sest tugitehnoloogiad ei pruugi selliseid nuppe ära tunda.
  7. Nupp peab olema vajutatav kogu oma ulatuses, mitte ainult nupul olev tekst.
  8. Veebis peavad olema ainult nupud kujundatud nupu moodi. See tähendab, et kõik elemendid, mis ei ole nupud peavad nuppudest eristuma (näiteks lingid, menüü, teetähised (breadcrumbs)).
  9. Nupunimed peavad olema tegevust kirjeldavad. Näiteks “Edasi”, “Salvesta”, “Tühista”, “Allkirjasta”, “Esita” jne.
  10. Ühe toimingu piires erinevate vormivaadete vahel liikudes peab kasutajal olema võimalus liikuda edasi ja tagasi, mida üldjuhul lahendatakse vastavate nuppude kuvamisega. Vormi esimeses vaates peaks olema “tagasi” nupu asemel “tühista” ja vormi viimasel vaatel “edasi” asemel näiteks “esita”.
  11. Pikemaid, kui 1-2 sõnalisi nupunimesid ei tohi kasutada.
  12. Nupud peavad olema klikkimiseks piisavalt suured ja terve nupp peab olema klikitav (mitte ainult tekst).
  13. Nupunimedest peavad olema eemaldatud mõttetud kordused. Näiteks “Esita avaldus” asemel tuleb kasutada “Esita”.

Otsing

  1. Leitud otsingutulemuste pealkirjad ja sisu kokkuvõtted peavad olema üksteisest piisavalt hästi eristatatud st pealkiri ja sisu eelvaade ei tohi olla samas stiilis.
  2. Leitud tulemuste pealkirjad peavad linkima leitud sisule.
  3. Leitud failide kohta käiv info – failitüübid ja -mahud peavad olema välja toodud.
  4. Iga tulemuse juures peab olema leitud sisu lühikokkuvõte/eelvaade. Kehtib artiklite puhul.
  5. Otsingutulemuste kuvamisel on eelistatud „näita rohkem“ valik ja lehe kerimist (scroll) kui tulemuste jaotamist erinevatele lehtedele (paging).
  6. Leheülene otsing peab olema kasutajale koheselt leitav st otsing ei tohi olla menüüsse peidetud.
  7. Tavaotsing ja detailne otsing peavad olema eraldatud st kasutajal peab olema võimalus valida lihtsa otsingule lisaks ka detailset otsingut.
  8. Otsinguväli peab olema otsingutingimuste sisestamiseks piisava suurusega (vähemalt 25 tähemärki).
  9. Otsingutulemuste vaates peavad olema kuvatud otsitud parameetrid, et kasutaja näeks, mille järgi otsing teostati.
  10. Otsingutulemuste vaates peab saama otsitud parameetreid kohe muuta ja uusi sisestada.
  11. Otsingu sooritamise järel peab olema kuvatatud leitud tulemuste arv.
  12. Otsingutulemuste mitte leidmisel peab olema kasutajale kuvatatud sellekohane teade.
  13. Otsingu tegemine peab olema võimalikult lihtne ja selge. Otsinguvälju ei tohi olla palju, sest muidu võib kasutajale tekkida küsimus, kas otsingu sooritamiseks pean täitma maksimaalselt või minimaalselt otsinguvälju
  14. Võõrkeelse sisuga lehtedel peab otsing töötama sarnase kvaliteeditasemega nagu eestikeelsel versioonil, kuid otsingute puhul tuleb lisada selgitav info, et otsingu tulemused on valdavalt eestikeelsed, aga otsingu väljanimetused ja abitekstid on vastavalt valitud keelele.

Pildid ja ikoonid

  1. Kui kasutatakse animeeritud galeriid (nt karusell), peab kasutajal olema võimalik animatsiooni peatada. (WCAG 2.2.2)
    Galerii peab olema kasutatav klaviatuuri abil. (WCAG 2.1.1)
    Aktiivne galerii element peab olema eristatav ka tugitehnoloogiatega – sellele võib lisada visuaalselt peidetud teksti. (WCAG 1.3.3)
    UX reeglid: Kui kasutatakse animeeritud galeriid (nt karusell), peab kasutajal olema võimalik animatsiooni peatada.
  2. Kui tegu on illustreeriva pildiga, mida informatsiooni kätte saamiseks näha pole vaja, tuleb lisada pildile tühi alt=“” atribuut, sest siis jätavad ekraanilugejad selle pildi vahele. Kui alt atribuuti ei lisata, loeb ekraanilugeja ette pildi faili nime. Illustreerivate piltide puhul tuleks kasutada CSS-i background, :before või :after reegleid HTML-i img märgendite asemel. (WCAG 1.1.1)
  3. Igal pildil peab olema märgitud tekstiline alternatiiv alt=“…” atribuudiga. Tekstiline alternatiiv peab kandma edasi sama informatsiooni kui pilt ise. Tekstiline alternatiiv ei tohi olla lihtsalt “Pilt” või “Tabel”. Tekstilisse alternatiivi pole vaja kirjutada “Pildi peal on…”, sest ekraanilugeja ütleb, et tegu on pildiga. (WCAG 1.1.1)
    UX reeglid: Igal pildil peab olema märgitud tekstiline alternatiiv alt=“…” atribuudiga.
  4. Ikoon lingi teksti asemel: Kui ikooniga on tähistatud linki, tuleks lingile lisada atribuut aria-label=“…”. Antud atribuut võimaldab ekraanilugejatel kasutajale lisainformatsiooni lugeda. Ikoonile võib lisada ka atribuudi title=“…”, mis annab nägijatele lisainformatsiooni, kui kursoriga elemendi peale liikuda. (WCAG 1.3.3). Ikoon näitab, kuhu link viib. 
    UX reeglid: Kui ikooniga on tähistatud linki, tuleks lingile lisada atribuut aria-label=“…”.
  5. Kui ikoon annab edasi tähtsat informatsiooni, mida tekstiliselt kirja ei taheta panna, tuleks see ekraanilugejate eest peita atribuudiga aria-hidden=”true” ning lisada sama infot edasi andev tekstiline kirjeldus, mida visuaalselt pole näha, aga mida ekraanilugejad saavad lugeda. Ikoonile võib lisada ka atribuudi title=“…”, mis annab nägijatele lisainformatsiooni, kui kursoriga elemendi peale liikuda. (WCAG 1.3.3) Infot annab edasi ainult ikoon. 
    UX reeglid: Kui ikoon annab edasi tähtsat informatsiooni, mida tekstiliselt kirja ei taheta panna, tuleks see ekraanilugejate eest peita atribuudiga aria-hidden=”true” ning lisada sama infot edasi andev tekstiline kirjeldus, mida visuaalselt pole näha, aga mida ekraanilugejad saavad lugeda.
  6. Vältida tuleb hüperpilte (image map), mille eri osadele vajutades avanevad erinevad lingid.
  7. Taustapiltide kasutamisel tuleb kindlaks teha, et tekst on pildi pealt loetav. Sisu peab loetavaks jääma ka taustapildi eemaldamisel. Taustapildi fail peab olema võimalikult väikesemahuline, et lehe laadimisaeg oleks võimalikult lühike.
  8. Pildile tuleb lisada allkiri figcaption märgendiga. Pildi tekstiline alternatiiv ei tohi korrata pildi allkirja, vaid andma lisainfot. 
    UX reeglid: Pildile tuleb lisada allkiri figcaption märgendiga.
  9. Ikoonid peavad olema lihtsad, selged, äratuntavad ja üheselt mõistetavad.
  10. Kui ikoon on pelgalt illustreeriv ega kanna endas lisainformatsiooni, tuleks see ekraanilugejate eest peita atribuudiga aria-hidden=”true”. Antud atribuut ei mõjuta elemendi visuaalset nähtavust, vaid võimaldab ekraanilugejatel antud elemendi vahele jätta. Lisaks ikoonile on olemas sama infot edasi andev tekst. 
    UX reeglid: Kui ikoon on pelgalt illustreeriv ega kanna endas lisainformatsiooni, tuleks see ekraanilugejate eest peita atribuudiga aria-hidden=”true”.

Printimine ja salvestamine

  1. Sisulehtede, mille sisu kasutaja sooviks tõenäoliselt printida või oma arvutisse salvestada, päisesse peab olema lisatud toimingule vastav tegevus (nupp, link, ikoon).
  2. Sisulehed tuleb prindida või salvestada järgides minimaalsuse printsiipi st ilmselt ei ole mõistlik print vaatesse kaasa panna menüüd jms.
  3. Printimisel ja salvestamisel tuleb lisada lehele/lehtedele väljavõtte aeg, koht (veebi aadress) ja vajadusel isiku nimi (väljavõtte tegija).
  4. Lisaks printimisele ja salvestamisele kaaluda sisu saatmise võimalust ka e-postile. Näiteks kinnistusraamatu väljavõte saatmine oma e-postile.

Tabelid ja andmeplokid

  1. Tabel tuleks esitada kasutades table, thead (päiselahtrite grupeerimiseks), tbody (sisuosa eraldamiseks), tfoot (kokkuvõtvate lahtrite grupeerimiseks), tr, td, th märgendeid. (WCAG 1.3.1)
  2. Tabelil peab olema päis. Horisontaalse päise lahtrid tuleb märkida th scope=“col” ja vertikaalse päise lahtrid th scope=“row”. (WCAG 1.3.1)
  3. Tabelile pab andma pealkiri caption märgendiga. (WCAG)
  4. Tabeleid ei tohi kasutada lehe sisu paigutamiseks ja kujundamiseks.
  5. Keerulisele tabelile tuleb lisada pikem kirjeldus aria-describedby=”…” atribuudiga. 
    UX reeglid: Keerulisele tabelile tuleb lisada pikem kirjeldus aria-describedby=”…” atribuudiga.
  6. Tabeleid ei tohi infoga üle koormata, sest sellisel juhul muutuvad nad loetamatuks. Peab olema tehtud valik, milline info on kõige olulisem, mis koheselt tabelis kuvatakse ja vähemoluline info tuleb lisada detailinfo alla või järgnevatesse vaadetesse.
  7. Tegevusnupud tuleb tabeli rea lõppu lisada. Kui on võimalik, siis tegevuste nimetuste tekstid tuleb kuvada koos ikooniga.
  8. Lehe sisuosasse, kus kasutaja soovib tõenäoliselt andmeid filtreerida ja sorteerida, tuleb lisada vastavad tegevused. Näiteks tuleks nimetatud võimalused luua andmetabelite, nimekirjade ja otsingutulemuste juurde.
  9. Tühje andmetabeleid ja andmeplokke ei tohi kuvada.
  10. Kui tühi andmeplokk tuleb ärireeglitest tulenevalt kuvada, siis ei tohi näidata tabeli päiseid, vaid selle asemel tuleb kuvada teade, et andmed puuduvad.
  11. Lehe sisu, andmeplokid ja tabelid peavad olema loogiliselt grupeeritud, sarnane sisu on koos ja erinevad plokid peavad olema visuaalselt eristatud.
  12. Pikemate andmetabelite paremaks lugemiseks võiks kaaluda tabeli ridade “triibutamist”.
  13. Andmetabelite ridade kõrgused peavad olema fondi suurus korda 1,6-1,8px.
  14. Tabeli tulpade vahel peab olema piisavalt, kuid mitte raiskavalt ruumi.
  15. Tabelis pikemate väärtuste kuvamisel on kaks võimalust: kas mitmel real või osa andmetest läheb “peitu” ja lõppu kuvatakse kolm punkti.
    See, kumb variant valitakse sõltub sellest, kui olulised on konkreetsed andmed konteksti vaatest.
  16. Sõltuvalt tabelis kuvatavate andmete iseloomust ja sellest, kas tabelis kuvatava infoga saab tegevusi teha (avada detailsem infovaade, salvestada vms) tuleks kaaluda lisaks rea lõpus olevatele tegevustele, muuta terve tabeli rida “klikitavaks”. Sellisel juhul peab jääma vastava tegevuse viide ka rea lõppu. Selline lahendus muudaks andmete kasutamise mugavamaks. Tähelepanu tuleks pöörata kahele asjaolule: kui terve rida on “klikitav”, siis reas olevaid andmeid ei ole enam mugav hiire kursoriga selekteerida (kas seda üldse tehakse selles tabelis?) ja kui tabeli reaga on võimalik teha mitut tegevust nagu salvestada ja avada, siis milline tegevus tehakse real “klikkimise” tulemusel (kas on intuitiivne?).
  17. Kui lehel kuvatavad tabelid on pikad, peab lehe kerimisel tabeli päis sisuga kaasa liikuma.
  18. Ära on vaja määratleda, milline on tabeli ridade maksimaalne arv, mille ületamisel jaotuvad ülejäänud andmed “lehtedele” (pagination)

Teated

  1. Vigaselt täidetud väljad või täitmata jäetud kohustuslikud väljad peavad olema visuaalselt eristatavad. (WCAG 3.3.1)
    Vigaseid välju ei tohi eristada ainult värviga. (WCAG 1.4.1)
  2. Olekumuudatused (nagu veateated või “Otsin…”, “Leiti 12 vastet”, “Vasteid ei leitud”), tuleb lisada koodi nii, et tugitehnoloogiad saaksid neid ette kanda ilma elemendile fookuse viimist. (WCAG 4.1.3)
    Näiteks veateatele võiks lisada aria-live=“assertive” atribuudi, sest siis katkestab ekraanilugeja oma töö ning loeb koheselt ette veateate.

    UX reeglid: Olekumuudatused uleb lisada koodi nii, et tugitehnoloogiad saaksid neid ette kanda ilma elemendile fookuse viimist.
  3. Vigaselt täidetud välja juures peab olema tekstiline veateade. (WCAG 3.3.1)
    Veateatest peab olema selgelt arusaadav, miks viga tekkis ja kuidas seda parandada. Peab olema kirjas, kas probleem on ajutine või püsiv ning kas kasutaja saab probleemi ise lahendada või tegeleb sellega teenusepakkuja (sellisel juhul peaks lisama teenusepakkuja või kasutajatoe kontakti). (WCAG 3.3.3)
  4. Veateade tuleb kuvada võimalikult lähedal kohale, kus viga tekkis. (WCAG 1.3.1) Vormiväljade puhu kuvatakse veateade vastava sisestuskasti juures.
  5. Kasutajat tuleb teavitada, kui tekkis viga ning ka siis, kui kõik õnnestus.
  6. Kui veateade kuvatakse eraldi lehel, peab seal olema vähemalt üks järgmistest: “Tagasi” link eelmisele lehele (käitub nagu veebilehitseja “Tagasi” nupp), “Proovi uuesti” link (käitub nagu veebilehitseja “Värskenda” nupp) või link avalehele saamiseks.
  7. Vormiväljad, mille täitmine sõltub mõne eelneva vormivälja täitmisest, peavad olema eristatud või algselt peidetud. Näiteks, kui tellimuste valimiseks peab olema e-post sisestatud, siis tellimused peavad olema algselt peidetud või mitteaktiivsed.
  8. Seosed vormiväljade vahel, mille täitmine on seotud mõne eelneva vormivälja täitmisest, peavad olema kasutajale esitatud üheselt arusaadavalt. Näiteks, kui tellimuste valimine sõltub e-posti välja täidetusest, siis peab olema kahe vormivälja vaheline seos kasutajale arusaadavaks tehtud.
  9. Peab olema tagatud, et kasutaja saaks kohe aru, kui valitud toimingut ei saa või pole hetkel võimalik sooritada. Näiteks ei lubata kasutajal täita avaldust, mille esitamise aeg on möödunud.
  10. Vormi täitmisel peab olema kasutusel abistavad tehnoloogiad (nt AJAX), mis annavad reaalajas tagasiside valikute võimalikkusest ja sisestatud andmete sobivusest. Näiteks kas e-post vastab formaadile, parooli valimisel tugevuse aste, postiaadresside ennustus jms.
  11. Toimingute valikud, mida kasutaja ei tohi teostada, peavad olema piiratud. Näiteks võimaldatakse otsida andmeid ja tulemused kuvatakse, aga tulemuse avamisel ilmub teade, mis ütleb, et kasutajal puuduvad õigused sisu vaatamiseks. Sel juhul peaks olema kohe piiratud otsingu teostamine, sest tulemusi ei saa niikuinii vaadata.
  12. Valesti sisestatud andmete puhul tuleb kuvada sellekohane teade.
  13. Veateade peab piisavalt eristuma ülejäänud sisust ja tekitama piisavalt liikumist, et kasutaja märkaks seda. Inimese silm märkab ja reageerib liikumisele.
  14. Veateade peab olema kuvatud silmatorkavas kirjas, see ei tähenda, et kiri peab olema punane.
  15. Süsteemi lehtedele peab olema planeeritud olulise info (nt süsteemi tõrked ja hooldustööd vms) kuvamise koht. Teadete asukoht peab olema kergesti märgatav.
  16. Vormis peab olema küsitud vaid sellist infot, mille küsimata jätmine takistaks toimingu sooritamist. Näiteks ei ole üldjuhul vajalik kohtusse avalduse esitamisel küsida kasutaja käest tema sugu.
  17. Kasutajale peab olema arusaadav, mis eesmärgil andmeid küsitakse. Kui küsitakse andmeid, mis ei ole koheselt seostatav eesmärgiga, tuleb kasutajale selgitada, miks neid andmeid küsitakse.
  18. Peab olema läbi mõeldud kas vormis on küsitud vaid neid andmeid, mille sisestamine on jõukohane kõikidele kasutajatele. Näiteks, kas kõigil süsteemi kasutajatel on olemas e-post või kas kõik kasutajad oskavad valida õiget dokumendi liiki.
  19. Veebil peavad olemas olema nii 404 kui 500 lehed.

Tekstid, sisu ja fondid

  1. Pealkirjad tuleb eristada märgenditega h1 kuni h6, mitte ainult kujundusega. Pealkirjadena h1 kuni h6 ei tohi esitada teksti, mis pole tegelikult pealkiri. (WCAG 1.3.1, 2.4.6)
  2. Pealkiri peab olema lühike, kuid sisukas ning kirjeldama sellele pealkirjale järgnevat sisu. (WCAG 2.4.6) Pealkiri peab algama kõige tähtsama ja sisukama sõnaga.
  3. Igal lehel peaks olema vähemalt üks h1. (WCAG)
  4. Pealkirjad peavad järgnema üksteisele hierarhiliselt korrektses järjekorras. Järjekorra korrektsust saab kontrollida näiteks WAVE tööriistaga. (WCAG 4.1.1)
    UX reeglid: Pealkirjad peavad järgnema üksteisele hierarhiliselt korrektses järjekorras.
  5. Sisu kordamist ühe lehe ulatuses tuleb vältida, sest see võib olla ekraanilugejaga kasutajale olla segadusse ajav ja tüütu. Korduvat sisu peab saama ülehüppamislinkidega vahele jätta. (WCAG 2.4.1)
  6. Tabuleerimisjärjekord peab ühtima sisu loogilise järjekorraga: kasutaja võib olla sunnitud navigeerima klaviatuuriga ning vales järjekorras sisu kaotab oma mõtte. (WCAG 2.4.3)
  7. Teksti suurused tuleb määrata rem ühikutes, et veebilehitseja seadetes teksti suurust muutes muutuks vastavalt ka veebilehe teksti suurused. Teksti (v.a subtiitreid) peab saama suurendada 200% ilma, et sisu ekraanilt kaoks või kattuks. (WCAG 1.4.4)
    Reavahe tuleb määrata ilma ühikuta. Soovituslik universaalne reavahe on 1.5. Kui kasutaja muudab ise teksti reavahe 1.5-ks, ei tohi tekst või funtksionaalsus kaduma minna. (WCAG 1.4.12)
  8. Lõikude vahe tuleb määrata rem ühikutes. Soovituslik universaalne lõikude vahe on võrdne fondi suurusega. Kui kasutaja muudab ise teksti reavahe 2 x fondi suuruseks, ei tohi tekst või funtksionaalsus kaduma minna. (WCAG 1.4.12)
  9. Kui kasutaja muudab ise teksti sõnade vahe 0.16 x fondi suuruseks või tähtede vahe 0.12 x fondi suuruseks, ei tohi tekst või funtksionaalsus kaduma minna. (WCAG 1.4.12)
  10. Teksti peab olema võimalik korrektses järjekorras aktiveerida ning kopeerida. (WCAG 1.3.2)
  11. Teksti asemel ei tohiks kasutada pilti, millel on tekst, sest seda ei saa kopeerida ega lugeda ekraanilugejaga. Erandiks on logod, millele tuleb lihtsalt lisada alt=”…”. Erand tehakse ka olukorras, kus teksti esitamine pildina on mõtte edasi andmiseks ainus võimalus ning olukorras, kus kasutaja saab pildil oleva teksti suurust ja värvi muuta. (WCAG 1.4.5)
  12. Kui osa tekstist on lehe üldisest keelest erinevas keeles, peab see olema märgitud näiteks ISO 639-1 koodiga lang=“…” atribuudis. (WCAG 3.1.2)
  13. Pealkirjad peavad olema visuaalselt hästi eristatavad – suured ja selged.
  14. Kasutaja peab lehelt leidma selle ja ainult selle sisu, mida ta sealt ootas.
  15. Prioriteetne info peba asuma lehe keskel ning olema visuaalselt esile tõstetud.
  16. Lehe sisu tuleb jagada mõistlike suurustega alamlehtedeks, et näidata kasutajale vaid seda, mille järgi ta on tulnud. Liiga pikad lehed võtavad kaua aega laadimiseks, liiga lühikesed lehed nõuavad kasutajalt edasi-tagasi navigeerimist.
  17. Kasutada tuleb lihtsat ja selget keelt, sest veebi kasutavad erineva kultuurilise ja haridusliku taustaga inimesed.
  18. Märkide (näiteks “-“) asemel tuleb kasutada sõnu (näiteks “kuni”), sest tugitehnoloogiad võivad neid valesti lugeda (näiteks “miinus”).
  19. Lühendite kasutamisel tuleb nende seletus esimesel korral välja kirjutada.
  20. Ühes reas tohib olla kuni 90 tähemärki, mobiilis kuni 70 tähemärki.
  21. Tuleb kasutada seriifideta fonti, sest seda on nägemisraskustega inimestel üldiselt lihtsam lugeda.
  22. Kaldkirjas ja paksu allajoonitud kirja tuleb vältida, sest neid on raske lugeda.
  23. Tuleb vältida sõnades läbivaid suurtähti, sest selliseid sõnu on raskem lugeda. Kui aga läbivaid suurtähti siiski kasutatakse, tuleb seda teha CSS-is text-transform: uppercase reegli abil, sest caps-lock’iga kirjutatud sõnu loevad ekraanilugejad täht haaval mitte tervikuna.
  24. Sisutekst peab olema minimaalselt 12px-16px suur.
  25. Kui lehele on sisseehitatud teksti suurendamise võimalus, peaks see asuma päise keskosas, et see lehe suurendamisel ekraanilt ära ei kaoks.
  26. Tekst ei tohi lehel liikuda (olla animeeritud), sest seda võib olla raske lugeda.
  27. Kui osa tekstist on märgistatud tärni või mõne muu sümboliga, peab sümboli seletus asuma enne teksti. Seletuses peab sisalduma “[sümbol] tähistab …”.
  28. Lehe üleselt peavad kõik elemendid, mis avavad või peidavad sisu, olema klikitaval põhimõttel, mitte ülelibisemise (hover) põhimõttel. Nõue tagab, et sisu oleks kasutatav ka puutetundlikel ekraanidel. Näiteks lisainfo avamiseks tuleb elemendil klikkida, mitte sellest üle libiseda.
  29. Tekstide rööp joondusele peab olema eelistatud vasakjoondust. Nõue tuleneb inimese silma liikumise ja teksti töötlemise võimekusest.
  30. Tekstide maht peab olema viidud miinimumini, sest kasutaja on valmis veebis lugema minimaalselt.
  31. Tekstilõigud peavad olema liigendatud.
  32. Sisutekstid ei tohi olla liiga pikad ja laialivalguvad.
  33. Avalehel peab olema toodud lühikirjeldus, et oleks võimalik mõista, millisesse veebi kasutaja on jõudnud.
  34. Lühikirjeldus peab olema silmatorkavalt nähtavas asukohas.
  35. Lühikirjeldus tuleb esitada nii, et selle nägemiseks ei pea ekraanivaate kerimisriba kasutama.
  36. Loetelude kirjed peavad olema järjestatud nii, et kõige olulisemad kirjed kuvatakse eespool.
  37. Sarnastes veebitoimingutes peab kasutatama ühtlustatud märksõnu, sh nupunimetusi.
  38. Igale veebilehele peab olema lisatud eraldi tiitelpealkiri.
  39. Veebilehe pealkiri peab olema vastava menüüpunkti pealkirjaga sarnases sõnastuses.
  40. Uudiste ja teadete juures peab olema selle lisamise kuupäev koos aastanumbriga.
  41. Kasutatud pildid ja ikoonid peavad aitama sisu paremini kirjeldada, kui nad sisule midagi juurde ei anna, tuleb need veebist välja jätta. Arvestama peab ka sellega, et pildid muudavad lehe aeglasemaks.
  42. Süsteemi või lehe nimi peab olema alati päises nähtav.
  43. Veebis peab olema läbivalt kasutatud vabavaralisi veebifonte nagu näiteks Google Fonts.
  44. Tuleks kaaluda, kas on mõistlik süsteemis kuvada erinevat sisu tulenevalt kasutajate gruppidest ja nende teadmistest. Näiteks ametnikule kuvatakse ühe sisuga veeb, tavakodanikule teise sisuga.
  45. Lehel/süsteemis ei tohi kasutada rohkem kui kolme erinevat fonti.
  46. Olulisemat sisu peab saama vaadata ilma kerimisriba kasutamata.
  47. Hiire kursor (pointer/cursor) peab muutuma vastavalt sellele, missugune on tema käitumine: tekstikursor, lingi kursor jms. Millises olukorras millist kursori stiili kasutada leiab MSDN lehelt.
  48. Kirillitsa tugi peab olema tagatud venekeelse versiooni kõigil kuvadel, kirillitsas loodud sisu peab olema kuvatud korrektselt ja kujundus säilima tervikuna.
  49. Pikema sisutekstiga lehtedel, mis sisaldavad vähemalt 6000 tähemärki ja mitut alapealkirja, peab olema eraldi sisukord (nt kasutustingimused, KKK jms lehed).

Tuvastus

  1. Kui lehel on ajalimiit (lühem kui 20 tundi), peab kasutajat sellest hoiatama, lubama limiidi välja lülitamist või pikendamist (selleks peab andma vähemalt 20 sekundit aega). (WCAG 2.2.1)
  2. Ettevaatlik tuleb olla robotilõksude kasutamises, sest CAPTCHA pildid on ekraanilugejaga loetamatud ning nupud ja lohistamisribad ei luba tihti turvakaalutlustel hiireklõpsu simuleerimist olles seega samuti ekraanilugejaga kasutamatud. Lisaks visuaalsele testile tuleb kindlasti ka pakkuda  testi. (WCAG 1.1.1) Robotite eemale hoidmiseks tuleks kasutada teisi vahendeid näiteks IP piirangud, päringute arv sekundi kohta jms.
  3. Kasutaja ei pea samas süsteemis erinevate teenuste kasutamiseks end korduvalt tuvastama.
  4. Kasutaja autentimise sessiooni peab pikenema kasutaja poolt tehtud tegevuste korral. Tegevused, mille korral sessiooni pikendatakse, tuleb valida konkreetses veebis tehtavate põhitegevuste järgi, et sessiooni pikendamise sagedus oleks piisav.
  5. Sessiooni peatsest aegumisest peab kasutajat teavitama (tavaliselt 5 min enne lõppu).
  6. Kasutajale peab teada andma kui palju aega tal on veel sessiooni aegumiseni jäänud, soovitav on kasutada lahendust, kus aja vähenedes seda kasutajale ka kuvatakse (counter).
  7. Kasutajal peab olema võimalik pikendada sessiooni.
  8. Kasutajal peab olema võimalik loobuda sessiooni pikendamisest.
  9. Sessiooni vaikimisi pikkus peab olema optimaalne võrreldes süsteemis tehtavate tegevuste eesmärgi ja kestvusega.
  10. Peale sessiooni aegumist peab võimaldama kasutajal jätkata sealt, kus ta pooleli jäi. See tähendab, et kui kasutajale kuvatakse teade, et sessioon on aegunud, siis peab tal olema võimalus end uuesti autentida ja jätkata pooleli jäänud kohast.
  11. Peale autentimist tuleb kuvada kasutajale erinevate sisselogimise rollide valimiseks rollivalik, kui rolle on rohkem, kui üks. Näiteks juhul, kui kasutajal on lisaks oma eraisiku rollile ka ettevõtte esindaja või asutuse esindaja rollid olemas.
  12. Kui autenditud kasutajal on võimalik siseneda süsteemi vaid ühe rolliga, siis rollivalikut kuvada ei tohi.
  13. Sisseloginud kasutaja roll peab olema minimaalsuse printsiipi arvestades süsteemi päises kuvatud. Näiteks ei ole kasutajale vajalik kuvada korraga nii tema eesnime, perenime kui ka isikukoodi, sest ta teab seda juba ise ka. Küll aga peab olema võimalik eristada, kas kasutaja on eraisikuna või ametnikuna süsteemis.
  14. Veebi sisenemiseks ja sealt väljumiseks peab olema üks koht. Tavapäraselt asub selleks vastav nupp päises.
  15. Kasutajale ei pea kogu aeg olema kuvatud sessiooni aegumiseni jäänud aeg. Kuna sessiooni pikendatakse üldjuhul teatud tegevuste peale, siis pidevalt kuvatav sessiooni aeg ei pruugi muutuda sujuvalt ja võib seetõttu pigem tekitada küsimusi ja segadust.

Vormid

  1. Igal vormiväljal peab olema täpselt üks pealkirja label, mis on temaga seotud id=“…” ja for=“…” atribuutide kaudu. Pealkiri peab visuaalselt paiknema vormivälja suhtes nii, et nende kokkukuuluvus oleks selge. (WCAG 1.3.1, 4.1.2)
    Pealkiri peab selgitama, millist infot on vaja sisestada. (WCAG 3.3.2)

    UX reeglid: Igal vormiväljal peab olema täpselt üks pealkirja label, mis on temaga seotud id=“…” ja for=“…” atribuutide kaudu.
  2. Väljad peavad olemad märgistatud nii, et autofill oskaks neid korrektselt täita. Kasutajalt ei tohi nõuda sisestatud andmete meelde jätmist, vaid tuleb näidata tema eelmisi valikuid ja varem sisestatud andmeid. (WCAG 1.3.5)
  3. Vormielementi fokuseerides või klikkides ei tohi juhtuda midagi ettearvamatut ega muutuda lehe kontekst, välja arvatud juhul, kui kasutajat on sellest eelnevalt teavitatud. (WCAG 3.2.1, 3.2.2)
  4. Kui vormi ära saatmisel on õiguslikud või finantsilised tagajärjed, peab kasutajal olema võimalik sisestatud info üle vaadata, seda parandada ning vajadusel vormi ärasaatmine tagasi võtta. (WCAG 3.3.4)
  5. Kui info tuleb sisestada mingil kindlal kujul, tuleb seda kuju kirjeldada sisestuskastiga seotud label märgendis. Soovitud kuju võib kirjutada ka sisestuskasti placeholder=“…” atribuuti, kuid see ei tohi asendada labelmärgendit. Placeholder=“…” atribuuti ei loe välja paljud ekraanilugejad ning enamus veebilehitsejaid kuvavad seda madala kontrastsusega värvides, mida vaegnägijad ei pruugi näha. (WCAG 1.4.3)
  6. Kui sisestuskasti funktsioon on visuaalselt piisavalt arusaadav, et ei vaja label elementi, tuleb kasutada aria-label=“…” atribuuti, et selgitust saaksid lugeda ainult ekraanilugejad. (WCAG)
  7. Kokkukuuluvatele raadionuppudele tuleb anda ühine name=“…” atribuut, et korraga saaks valida ainult ühe raadionupu. (WCAG 4.1.2) 
    UX reeglid: Kokkukuuluvatele raadionuppudele tuleb anda ühine name=“…” atribuut, et korraga saaks valida ainult ühe raadionupu.
  8. Kohustuslikud väljad peavad olema visuaalselt eristatavad mittekohustuslikest väljadest, kuid mitte ainult värvi abil. (WCAG 1.4.1)
  9. Kui kohustuslikku välja tähistatakse tärniga, peab sellekohane selgitus asuma enne esimest vormivälja. Näiteks “* tähistab kohustuslikku välja”. (WCAG 3.3.2)
  10. Vajalike vajutuste hulk tuleb hoida minimaalsena. Sisestuskastide asemel eelistada kasutada valikukaste, raadionuppe või märkeruute, sest need on mugavamad, eriti mobiilseadmel.
  11. Kokku kuuluvad vormiväljad nagu raadionupud, märkeruudud ja sisestuskastid tuleb grupeerida fieldset elemendi sisse ning anda grupile üldine pealkiri legend elemendi abil. 
    UX reeglid: Kokkukuuluvad vormiväljad nagu raadionupud, märkeruudud ja sisestuskastid tuleb grupeerida fieldset elemendi sisse ning anda grupile üldine pealkiri legend elemendi abil.
  12. Pikemate toimingute sooritamise protsess peab olema jagatud mitme ekraanivaate vahel.
  13. Toimingusammude järjestus peab olema kasutajale hästi nähtav ja jälgitav.
  14. Kui vorm on jaotatud sammudeks, mis asuvad mitmel lehel, tuleb kirjutada lehe title märgendisse, mitmenda sammu juures ollakse.
  15. Tuleb kasutada sisestuskasti tüüpe search, email, url, number, tel, range, date või time, et valideerida sisestatud infot automaatselt ning vältida vigu. Mobiilseadmes kuvatakse sisestuskasti tüübi olemasolul ka vastav klaviatuur, mis teeb sisestamise mugavamaks. Sisestuskasti tüübid pole hetkel veel kõigis veebilehitsejates toetatud. 
    UX reeglid: Tuleb kasutada sisestuskasti tüüpe search, email, url, number, tel, range, date või time, et valideerida sisestatud infot automaatselt ning vältida vigu.
  16. Sisendile võib seada piiranguid min=“…”, max=“…”, maxlength=“…” ja steps=“…” atribuutidega. Veelgi täpsema piirangu saab seada mustrikontrolli ehk pattern=“…” atribuudiga, mis võimaldab kontrollida kasutaja sisendi vastavust regulaaravaldisele ning vältida vigu.

    UX reeglid: Sisendile võib seada piiranguid min=“…”, max=“…”, maxlength=“…” ja steps=“…” atribuutidega.
  17. Parim võimalus on paigutada pealkirjad sisestuskastide kohale, sest selline paigutus töötab hästi nii arvutis kui ka mobiilis.
  18. Kasutajale ei tohi näidata korraga liiga palju valikuid ja võimalusi, sest see võib olla segadusse ajav ja frustreeriv. Valikud tuleb jagada väiksemateks gruppideks. Pikast valikute nimekirjast võiks pakkuda otsimisvõimalust.
  19. Kokku kuuluvad valikud tuleb grupeerida optgroup märgendi abil, et soovitud valiku leidmine oleks kiirem. 
    UX reeglid: Kokkukuuluvad valikud tuleb grupeerida optgroup märgendi abil, et soovitud valiku leidmine oleks kiirem
  20. Kohustuslikud väljad peavad olema esitatud input required märgendiga. Soovituslik on lisada ka atribuut aria-required=“true”, sest kõik tugitehnoloogiad ei pruugi arvestada required atribuuti.
  21. Eelmisesse vaatesse tagasi liikudes peavad alles jääma kõik kasutaja poolt eelnevalt sisestatud andmed.
  22. Ekraanivaadet uuendades (refresh) peavad alles jääma kõik sisestatud andmed.
  23. Sisestusvea avastamisel peavad alles jääma kõik kasutaja poolt sisestatud andmed.
  24. Vormi avades peab olema esimene sisestusväli vaikimisi aktiivne.
  25. Vormi iga sisestusvälja juures peab olema välja pealkiri (label), mis peab olema joondatud vasakule.
  26. Vormipealkirjad peavad olema vormiväljade juurde paigutatud nii, et need on hetkega omavahel seostatavad.
  27. Vormipealkiri peab alles jääma ka peale seda, kui vormiväli on aktiivne ehk kasutaja on alustanud sellesse väärtuse sisestamist.
  28. Sisestusvälja vihje (hint, placeholder) ei tohi jätta muljet, et tegemist on sisestatud andmetega.
  29. Vormides peab saama ühelt vormiväljalt teisele liikuda tabulaatorklahvi kasutades.
  30. Tabulaatorklahviga edasi liikumise järjestus peab vastama vormi andmete tavapärasele sisestusjärjestusele.
  31. Tabulaatorklahviga peab saama liikuda ka toimingu sooritamise nupule, nagu näiteks “esita”, “edasi” jms.
  32. Enter nuppu vajutamine peab olema võrdsustatud aktiivse vormivälja juurde kuuluva tegevuse (call to action)/ toimingu sooritamise nupu vajutusega.
  33. Valikute kastid (radiobuttonid, checkboxid) peavad olema valitavad tühiku klahviga.
  34. Vormidel ei tohi küsida korduvalt samu andmeid.
  35. Varasemalt sisestatud andmeid tuleb kasutada toimingute sooritamiseks korduvalt (nt e-post, isikukood jms), st samu andmeid samas süsteemis kuid erinevates vaadetes ei tohi kasutaja käest küsida. Andmeid tuleb taaskasutada.
  36. Pikemate tekstide sisestamiseks mõeldud vormiväljad peavad arvestama sisestatava sisu mahuga/pikkusega.
  37. Kasutaja peab saama mugavalt üle lugeda teksti, mida ta vormiväljadesse on sisestanud.
  38. Vabateksti välja juures peab olema näidatud järelejäänud tähemärkide arv.
  39. Ei tohi olla vormivälju, mis jätavad mulje, et on aktiivsed, aga ei ole käsitsi muudetavad. Näiteks kuupäeva väli, mida käsitsi muuta ei saa, vaid tuleb vajutada kalendri ikooni ja kuupäev valida kalendrist.
  40. Täidetud vormivälju peab olema võimalik tühjendada ühe toiminguga.
  41. Kindlate ja piiritletud valikutega andmete lisamiseks peab olema välja toodud valikuvariandid. See vähendab eksimuste arvu. Näiteks tuleb vabateksti asemel pakkuda kasutajale valikuid.
  42. Enim kasutatud valikud peavad vaikimisi olema valitud.
  43. Kasutajal peab olema võimalik valikuid lisada, kui ei ole veendutud valikute ammendatuses.
  44. Kuupäeva sisestamisel peab olema võimalus valida kuupäev kalendrist.
  45. Kalendrist peab olema võimalik valida eraldi nii päeva, kuud kui ka aastat.
  46. Kalendri avanedes peab olema vaikimisi avatud optimaalseim kuupäev. Näiteks avalduse koostaja sünniaja sisestamisel ei ole mõistlik avada vaikimisi 2019 aasta kalendrit.
  47. Kasutajal peab olema võimalik kõiki enda poolt sisestatud andmeid muuta ja kustutada.
  48. Kui andmete sisestamiseks on vormid jaotatud erinevatele vahelehtedele (tabid), siis peavad olema eristatud vahelehed, millel mõni kohustuslik väli on veel täitmata.
  49. Kasutajale peavad olema näha kõik tema poolt sisestatud andmed. Näiteks, kui andmete sisestamiseks avaneb vormil modal ja kasutaja kinnitab andmete sisestuse ning sisestatud andmed ilmuvad vormile, tuleb kasutajale näidata kõiki tema poolt sisestatud andmeid.