Eiropas IKT produktu un pakalpojumu piekļūstamības standarta EN 301 549 jaunā versija V4.1.1 publicēta 2026. gada septembrī. Tajā iestrādātas WCAG 2.2 prasības, kas digitālos pakalpojumus padara ērtāk lietojamus cilvēkiem ar redzes, kustību un kognitīviem ierobežojumiem. Latvijas iestādēm, uzņēmumiem un izstrādātājiem tas ir praktisks signāls jau tagad pārbaudīt tastatūras fokusu, vadības elementu izmēru, vilkšanas darbību alternatīvas un autentifikāciju.
Vienlaikus jānošķir tehniskā standarta publicēšana no tā juridiskā statusa. Jauna versija nekļūst par Eiropas Savienībā harmonizētu standartu tikai tādēļ, ka ETSI to ir izdevis. Konkrētās versijas atsaucei jābūt publicētai ES Oficiālajā Vēstnesī. Eiropas Komisijas skaidrojumā par harmonizāciju pašlaik kā harmonizētā versija norādīta EN 301 549 V3.2.1.
Ko aptver EN 301 549
EN 301 549 V4.1.1 nosaka piekļūstamības prasības IKT produktiem un pakalpojumiem. Tas nav tikai tīmekļvietņu kontrolsaraksts. Standarts aptver arī lietotnes, dokumentus, programmatūru, saziņas risinājumus, pašapkalpošanās iekārtas un citas tehnoloģijas.
WCAG prasības ir nozīmīga standarta daļa tīmekļa saturam, taču EN 301 549 tvērums ir plašāks. Tāpēc ar paziņojumu “vietne atbilst WCAG” vien nepietiek, ja iepirkumā vai pakalpojumā ietilpst arī mobilā lietotne, elektroniskie dokumenti, klientu terminālis, videokonferenču rīks vai atbalsta dienests.
Praktiskā darbā vispirms jānosaka, kuras produkta daļas lietotājs sastop visā pakalpojuma ceļā. Piemēram, piekļūstama pieteikuma forma nepalīdz, ja identitātes pārbaude, maksājums vai saņemtais PDF nav lietojams ar ekrānlasītāju vai tikai ar tastatūru.
Redzams fokuss, ko neaizsedz citi elementi
Lietotājam, kurš pārvietojas ar Tab taustiņu, vienmēr jāredz, kur atrodas fokuss. WCAG 2.2 papildina šo principu ar prasību, ka fokusēto elementu nedrīkst pilnībā aizsegt cits saturs. Tipiski šķēršļi ir pielipusi sīkdatņu josla, uznirstošs tērzēšanas logs, fiksēta galvene vai kļūdas paziņojums.
Pārbaude ir vienkārša: jāiziet viss pakalpojums tikai ar tastatūru un jāvēro katra saite, poga, izvēlne un formas lauks. Fokusa rādītājam jābūt pamanāmam, un fokusētajam elementam jāpaliek redzamam. Testā jāiekļauj arī mazs ekrāns un palielināts saturs, jo pārklāšanās bieži rodas tieši šādos apstākļos.
Vilkšanai vajadzīga vienkārša alternatīva
Vilkšanas kustība var būt sarežģīta cilvēkam ar trīci, ierobežotu roku kustību vai precizitāti. Ja uzdevumu var izpildīt tikai, velkot kartīti, failu, kartes punktu vai slīdni, daļa lietotāju to nevarēs paveikt.
WCAG 2.2 paredz alternatīvu, ko var izpildīt ar vienu rādītāja darbību. Kārtošanas rīkā tās var būt pogas “uz augšu” un “uz leju”, failu augšupielādē — parasta faila izvēles poga, bet kartē — adreses vai koordinātu ievades lauks. Alternatīvai jānodrošina tāds pats rezultāts, nevis tikai daļa no funkcijas.
Vadības elementu izmērs nav kosmētika
Pārāk mazas ikonas un cieši novietotas saites rada kļūdainus pieskārienus. Tas īpaši ietekmē cilvēkus ar kustību ierobežojumiem, bet problēmu izjūt arī ikviens, kurš telefonu lieto kustībā vai ar vienu roku.
W3C pārskatā par WCAG 2.2 jaunumiem starp jaunajiem kritērijiem ir minimālais mērķa izmērs. Projektētājam jāvērtē ne tikai pašas ikonas grafiskais izmērs, bet klikšķināmā zona un attālums līdz blakus esošiem elementiem. Īpaša uzmanība vajadzīga aizvēršanas ikonām, izvēles rūtiņām, kalendāra datumiem un mobilajām navigācijas pogām.
Palīdzībai jābūt atrodamai vienā un tajā pašā vietā
Ja vairākās lapās atkārtojas palīdzības iespējas, tām jāparādās paredzamā secībā. Lietotājam nevajadzētu katrā solī no jauna meklēt kontaktus, biežāk uzdotos jautājumus vai saziņas pogu.
Vienots novietojums ir svarīgs cilvēkiem ar kognitīviem traucējumiem un lietotājiem, kuri izmanto palielinājumu. Tas samazina nepieciešamību iegaumēt mainīgu saskarni. Labs risinājums ir stabila palīdzības saite galvenajā navigācijā vai vienādi veidots kontaktu bloks visā pakalpojumā.
Atkārtota ievade un autentifikācija
Ja lietotājs vienā procesā informāciju jau ievadījis, sistēmai nevajadzētu bez vajadzības prasīt to ievadīt vēlreiz. Datus var automātiski aizpildīt vai piedāvāt izvēlei. Tas mazina kļūdu risku un slodzi cilvēkiem ar atmiņas, uzmanības vai kustību grūtībām.
Arī pieslēgšanās nedrīkst būt balstīta tikai uz kognitīvu pārbaudījumu, piemēram, paroles pārrakstīšanu no atmiņas vai sarežģītas mīklas atrisināšanu. Jāatbalsta paroļu pārvaldnieki, ielīmēšana un citas pieejamas autentifikācijas metodes. Drošība nav jāmazina — jāizvēlas risinājums, kas drošību nodrošina bez nevajadzīga šķēršļa.
Ko ierakstīt iepirkumā
Frāze “risinājumam jābūt piekļūstamam” ir pārāk neskaidra. Tehniskajā specifikācijā jānorāda precīza standarta versija, produkta daļas, atbilstības līmenis un pierādījumi, ko piegādātājs iesniegs. Jāparedz arī pieņemšanas testi un konstatēto kļūdu novēršanas kārtība.
Noderīga secība ir šāda:
1. inventarizēt visas lietotāja saskarnes, dokumentus un atbalsta kanālus; 2. noteikt piemērojamās EN 301 549 un WCAG prasības; 3. prasīt manuālu testēšanu kopā ar automatizētiem rīkiem; 4. pārbaudīt tastatūru, ekrānlasītāju, palielinājumu un mobilo lietošanu; 5. iesaistīt cilvēkus ar invaliditāti reālu uzdevumu izmēģināšanā; 6. pieņemt risinājumu tikai pēc būtisko šķēršļu novēršanas.
Automatizēts audits atrod tikai daļu problēmu. Tas nevar droši novērtēt, vai fokusa secība ir loģiska, alternatīvais teksts ir jēgpilns vai pakalpojumu iespējams pabeigt bez vilkšanas kustības.
Pieejamība jāuztur arī pēc nodošanas
Atbilstība pieņemšanas dienā negarantē piekļūstamību pēc pusgada. Jauns satura bloks, ārēja maksājumu sistēma, sīkdatņu risinājums vai dizaina sistēmas atjauninājums var radīt šķērsli jau pārbaudītā pakalpojumā. Tāpēc organizācijai vajadzīgs atbildīgais darbinieks, regulārs pārbaužu grafiks un saprotams kanāls lietotāju ziņojumiem.
Ziņojumā par kļūdu jāspēj norādīt lapu, veikto darbību, izmantoto ierīci un to, kas neizdevās. Atbildē lietotājam nepietiek apsolīt problēmu izskatīt — jāpasaka termiņš un, ja iespējams, pieejams alternatīvs ceļš pakalpojuma saņemšanai. Būtiskas funkcijas nepieejamību nevajadzētu atlikt līdz nākamajai lielajai sistēmas versijai.
Regulārā pārbaudē noder neliels nemainīgu uzdevumu komplekts: pieslēgties, atrast informāciju, aizpildīt formu, pievienot dokumentu, samaksāt un saņemt apstiprinājumu. Tas ļauj pamanīt regresijas un salīdzināt rezultātus pēc katra atjauninājuma.
Ko darīt ar jauno versiju jau tagad
Jauns projekts, kas balstīts tikai uz agrāku prasību minimumu, drīz var prasīt pārbūvi. Tāpēc WCAG 2.2 kritērijus ir lietderīgi iekļaut dizaina sistēmā, izstrādes prasībās un kvalitātes pārbaudēs jau tagad. Tas uzlabo pakalpojumu neatkarīgi no harmonizācijas procesa termiņa.
Juridiskajos atbilstības paziņojumos gan jābūt precīziem. Jānorāda faktiski pārbaudītā versija un nevajag apgalvot, ka V4.1.1 jau dod harmonizēta standarta atbilstības prezumpciju, kamēr konkrētā atsauce nav publicēta ES Oficiālajā Vēstnesī. Tehniskā gatavība un juridiskā precizitāte var pastāvēt vienlaikus.
