Sinu veeb ei vasta ligipääsetavuse (WCAG) kriteeriumitele – meie arendajad annavad nõu, kas teha vana korda või luua uus
WCAG (Web Content Accessibility Guidelines) kriteeriumite järgimine on iga tarkvaralahenduse loomise väga oluline osa. Loe lähemalt meie varasemast blogist, kuidas kõik juurdepääsetavusest võidavad.
Meie ligipääsetavuse spetsialisti Mari-Ell Metsa sõnul kehtib aastast 2019 avalikule sektorile Euroopa Liidu direktiiviga kehtestatud ligipääsetavuse tagamise kohustus, mis sisuliselt tähendab, et veebilehed ja mobiilirakendused peavad vastama WCAG 2.1 standardi AA tasemele.
Aastast 2025 hakkab antud kohustus kehtima ka erasektori teatud valdkondadele. Täpse ülevaate kohustusest leiad seadusest. Ligipääsetavuse tagamine lähtub neljast põhimõttest: tajutavus, talitlusvõime, mõistetavus ja töökindlus, mis jagunevad omakorda kriteeriumiteks, mille täitmisel võib veebileht saavutada vajaliku taseme (AA). Ligipääsetavuse tagamine on üldjuhul aeganõudev protsess ning üleminekuks on soovitatav alustada ettevalmistustega juba praegu.
Kui sinu veeb ei vasta veel WCAG 2.1 standardi AA tasemele, siis on sul 2 varianti: kas arendada täiesti uus leht, mis vastab kohe ligipääsetavuse kriteeriumitele või uuendada olemasolevat (front-endi facelift). Käesolevas blogis aitame sul meie arendajate Mairo Aljaste ja Sander Rautam abiga selgusele jõuda, kumb lahendus sobib kõige paremini sinu jaoks.
Kuidas arendusprotsessiga algust teha?
Koos arenduspartneriga on tarvis otsustada, kas on mõistlik luua uus veeb või kohandada vana WCAG kriteeriumitele vastavaks.
Juhul kui soovid uut veebi, tuleb kõigepealt disaineritel lasta valmis teha UX/UI-le ning WCAG nõuetele vastav kujundus. Valides aga facelift’i olemasolevale lehele WCAG nõuetega vastavusse viimiseks, soovitame alustada auditi tegemisest, et tuvastada probleemsed kohad sinu veebis. Auditi tulemusi soovitame analüüsida koos arendajatega, et hinnata, mis tasemel sinu veebi WCAG hetkel on ning mida on võimalik parandada ja mida mitte.
On erineva tasemega WCAG suunised ja kõike ei pea kindlasti korraga tegema. Arenduspartneriga koostöös saad paika panna prioriteetide järjekorra ja otsustada ka seda, millistele vahenditele peaks keskenduma (ekraanilugeja, brauserid, operatsioonisüsteemid jne).
1. Variant: olemasoleva veebi ligipääsetavuse parendamine
Siin all mõtleme seda, kui sinu veebis on juba mingil määral järgitud ligipääsetavuse standardeid ja soovid olemasolevat lahendust kas täiendada või parendada. Võib öelda, et see samm arvestab kasutajatega ja on kindlasti palju parem valik, kui vanale tasemele jäämine. Arenduse ja kulude poolest võib see valik aga osutuda väljakutsuvaks. Räägime lähemalt plussidest ja miinustest.
Plussid
Tänu ligipääsetavuse täiendustele ja muudatustele tõenäoliselt laieneb ka sinu veebi kasutajate ring. Näiteks kui sa oma veebis varasemalt ei arvestanud nägemisvaegusega kasutajatega, kuid nüüd soovid panustada ka ekraanilugeja võimekusse. Või kui sa varasemalt ei arvestanud kasutajatega, kes ei saa käsi kasutada (ajutine või püsiv trauma), kuid nüüd soovid lisada häälkäskluse kasutamise võimaluse.
Oluline on ära märkida, et nägemisvaegus ei ole ainult püsiv või kaasasündinud nägemispuue, vaid see võib mingil eluhetkel puudutada meid kõiki: ajutine silmatrauma või haigus, samuti nägemise halvenemine vananedes. Uuringute järgi esineb igal 12nendal mehel mõni värvipimeduse vorm. Meie varasemast blogipostitusest saad lugeda ligipääsetavate värvide kasutamise kohta veebidisainis.
Miinused
Oleneb veebist, kuid sageli kipub olemasoleva veebi ligipääsetavaks tegemine olema arenduse seisukohalt keerulisem kui uue veebi arendus. Miks nii? Arendajal tuleb „lahti muukida“ olemasolev kood ja aru saada praeguste komponentide tööst ning selle põhjal välja nuputada, kas ja kuidas on võimalik sinna lisada soovitud ligipääsetavust. Tüüpiliselt on see kellegi teise kirjutatud ja sageli dokumenteerimata.
Projekt võib osutuda väga ajamahukaks – ajakulu oleneb sellest, kui suur ligipääsetavuse tugi on praegusel veebil ja kui keeruline on olemasoleva koodi „lahti muukimine“. Samuti sellest, kui lihtne või keeruline on lisada olemasolevale veebile uusi ligipääsetavuse funktsionaalsusi.
Ajakulu aitab planeerida eelnevalt tehtud audit, millest rääkisime blogi alguses, kuid olemasolevat veebi täiendades võib ilmneda ka ebameeldivaid üllatusi, mida mahuhinnangusse pole võimalik kuidagi planeerida. Näiteks võib selguda, et veebileht on 10-15 aastat vana ja aegunud ning sellel esinevad tehnilise toe raskused.
Võibolla ei tööta mõned komponendid või koodid või need on vaja ringi kirjutada selleks, et oleks võimalik lisada uusi soovitud ligipääsetavuse tugifunktsioone. Ennetamiseks ja aja kokkuhoidmiseks palume tellijal enne arendusega alustamist kindlasti välja tuua juba teadaolev info selle kohta, mis praeguse veebi juures ei tööta.
Eelnevast tulenevalt on praktikas sageli olemasoleva veebi täiendamine lõppkokkuvõttes kulukam, kui täiesti uue ja kohe ligipääsetava veebi arendamine. Esmalt on tarvis teha audit ja see maksab. Seejärel oleneb projekti enda maksumus sellest, kui keerulise veebiga on tegemist, kui palju ja mis kvaliteediga ligipääsetavuse tugi on veebil juba olemas ning mida soovitakse lisada ja kui keeruliseks osutub lisamine.
Suure tõenäosusega ei piisa olemasoleva veebi ligipääsetavuse täiendamisel ainult front-end’i uuendamisest, vaid tarvis on mingil määral muuta ka back-end’i arendusi ja disaini. Keerulisemate süsteemide ja veebilehtede korral peaksid vastavaid muudatusi tegema ka partnerid, kellega tellija veeb on liidestatud. Näiteks kui tellija veeb kasutab ainukese lahendusena Google Maps’i või Pipedrive’i vorme, siis peaksid ka need vastama ligipääsetavuse nõuetele, sest tellija arenduspartner neid ise muuta ei saa.
Näiteid TWNi tehtud projektidest
TWNis on ligipääsetavus olnud alati meie südameasjaks. Pakume ka oma klientidele WCAG auditite ja veebide arendamise teenust vastavalt WCAG kriteeriumitele. Seepärast peavad ka meie veeb ja blogi, mis on ühtlasi meie visiitkaardiks, vastama WCAG kriteeriumitele.
Vaegnägijad kasutavad veebis ringiliikumiseks ja teksti ettelugemiseks ekraanilugejaid ning meie arendajate ülesandeks sai muuta meie veeb ja blogi ekraanilugejatele ligipääsetavaks. Muutsime oma lehe küllaltki keerulise ülesehituse ja ka värvide kontrastsuse WCAG kriteeriumitele vastavaks ja ekraanilugejate sõbralikuks.
Samuti lisasime ekraanilugejate jaoks vastavad märguanded menüüde ja akordionite avamise ja sulgemise teavitamiseks. Viisime sisse ka lisatõlked ekraanilugejate jaoks (mida tavakasutaja ei näe).
Kuvatõmmis Trinidad Wisemani veebist, kus on näha, et tab'iga (klaviatuuriga) liikumisel on fokusseeritud elemendil nähtav kontrastne fookuskast. Teksti värvid on ka taustaga õiges kontrastsussuhtes.
Selle projekti puhul ei tehtud ligipääsetavuse töid vanale veebile, kuid need teostati erinevalt esialgselt planeeritust hoopis lõpus eraldi etapina. Kuna uue veebi valmimise tähtaeg hakkas kiiresti lähenema, otsustasime koos kliendiga, et kui portaal on avalik, siis teostame kohe põhjaliku WCAG testimise eraldi veel lisaks ja teeme seejärel vastavad täiendused ja muudatused.
Testimises osales lisaks arendajale ja testijale ka meie sertifitseeritud veebi ligipääsetavuse spetsialist Mari-Ell Mets, kes testis kolme erineva ekraanilugeja tarkvaraga. Testimise tulemusena selgunud ligipääsetavuse puudujäägid jagasime prioriteedi ja kriitilisuse alusel kolme rühma:
- lihtsamad näpuvead (umbes pooled neist), mille parandamine läks kiiresti - nt aria labelite/nimetuste puudumine või vale pealkirja stiil.
- keskmise prioriteediga vigade alla läksid erinevad ekraanilugejate käitumisega seotud teemad - nt ühes ekraanilugejas toimis korrektselt, teises mitte, samuti erinev käitumine desktopi ja mobiilivaadetes.
- kõrge prioriteediga täienduste (umbes 10%) alla läksid olukorrad, kus rakenduse kasutamine oli tõsiselt häiritud - näiteks mobiilivaates avanes vale klaviatuur, menüüs olevatel linkidel oli vale fookusjärjekord või teatud tingimustel ei leidunud otsingus ühtki vastet.
Rääkides väljakutsetest, siis mõningate keskmise ja kõrge prioriteediga vigade lahendamine nõudis juba tõsisemat algse lahenduse ümbertegemist ning ühel juhul polnudki võimalik saavutada soovitud tulemust, sest kasutatav raamistik ei võimaldanud rakendada kasutajamugavat disaini, mis oleks ühtlasi ka ligipääsetav.
Praeguseks on avalik juba uus versioon, kus antud raamistikku enam ei kasutata ja seega on kõrvaldatud ka see konkreetne probleem.
Õppetund, mille saime ja mille peale sageli ei mõtle on see, et kui arendaja kasutab PC-d, siis Mac-i ekraanilugejal arenduses oleva koodi testimine on paras peavalu. Seega, mõtle hoolega läbi projektis kasutatavad seadmed.
Meie arendaja ülesandeks on hinnata tööde mahtu, mis kulub olemasolevate alamlehtede muutmisele ligipääsetavuse kriteeriumitele vastavaks. Samuti selgitab ta välja riskid ehk mis võib vanades koodides katki minna uute funktsionaalsuste lisamise käigus ja kuidas võib uuendamine mõjutada olemasolevaid veebilehti. Meie testija aga vastutab igapäevaselt uute arenduste ligipääsetavuse tagamise eest.
2. Variant : uue ligipääsetava veebi arendus
Siin all mõtleme seda, kui sul on veebileht olemas, aga soovid sellele täiesti uut WCAG standarditele vastavat disaini või veebileht puudub üldse ja soovid seda luua, arvestades kohe WCAG standarditega. Arenduse ja kulude poolest võib see olla parem valik, kui olemasoleva lehe WCAG kriteeriumitele vastavaks kohendamine. Räägime plussidest ja miinustest.
Plussid
Täiesti uue ja kohe ligipääsetava veebi arendamine on kõigi osapoolte jaoks lihtsam, mugavam ja läbipaistvam lahendus. Tehtud on analüüs ja kõik soovitud ligipääsetavuse funktsionaalsused lepitakse juba projekti algusfaasis kokku.
Arendajad ei pea lahkama hakkama kellegi teise kirjutatud koodi (kui see on kehvasti dokumenteeritud või dokumentatsioon puudub) ega ennustama, kas uut soovitud funktsionaalsust on võimalik vanale veebile juurde lisada või mitte (sageli selgub tegelikkus alles töö käigus). Samuti on võimalik otsast peale uut veebi arendades kogu arendajate töö kvaliteetselt ja detailselt dokumenteerida nii, et edaspidi on must-valgel kirjas, mis tehtud sai.
Uus ligipääsetavuse standarditele vastav veebileht arvestab kohe väga paljude erinevate kasutajagruppidega (nt lisaks tavakasutajale ka vaegnägijate, ajutise või püsiva traumaga kasutajatega). Uue veebi arendamise korral on võimalik kohe kliendile välja arvestada ajakulu ja projekti maksumus.
Miinused
Arendada on keeruline, kui puudub eelanalüüs ega ei ole täpselt teada, mida klient soovib. Oht on „üllatusmomentideks“, kui arendajad katsetavad uusi lähenemisi, funktsionaalsusi või tehnoloogiaid ja seda, kui hästi need toetavad ligipääsetavust. Üldjuhul saab neil üllatustel sabast kinni juba disainifaasis.
Näiteid TWNi tehtud projektidest
EAS.ee pealeht
Haridusportaal
Visittallinn.ee
Kokkuvõtteks
Nagu rääkisime, siis aastal 2025 hakkab ligipääsetavuse kohustus kehtima ka erasektori teatud valdkondade veebidele (avalikus sektoris kehtib juba praegu) ja TTJA võib tulla sinu veebi kontrollima. Õige aeg oma veebi ligipääsetavuse peale mõelda on juba praegu, sest arendustegevused vajavad planeerimist ja võtavad aega.
Loodame, et meie artikkel annab sulle mõtteainet ja suuna kätte, kas minna olemasoleva veebi ligipääsetavuse nõuetele vastavaks tegemise teed või arendada uus – kohe WCAG nõuetele vastav veeb. Kindlasti soovitame alustada auditist. Kui see on tehtud, saad võtta arendusmahtude pakkumised nii ühele kui teisele lahendusele ja seejärel otsustada. Optimaalsema arendusmahtude pakkumise saad, kui uue veebi puhul on juba olemas ka uus disain.
Proovi Trinidad Wisemani ligipääsetavuse tööriista siit. Kui vajad abi, siis Trinidad Wiseman pakub nii ligipäästavuse auditeid kui ka koolitusi.
