Uzlabošanas plānam nav noteikta termiņa. Regulējums nosaka, ka jums jāidentificē un jānovērš problēmas, bet nenorāda konkrētu nedēļu vai mēnešu skaitu. Praktiski izpildes laiks ir atkarīgs no trim faktoriem: cik daudz ir problēmu, kurš tās risina un kā šis cilvēks vai uzņēmums to iekļauj savā darbā.
Tas, kas ir fiksēts, ir secība. Vispirms jūs identificējat problēmas, pēc tam tās prioritizējat, pēc tam tās novēršat, un visbeidzot dokumentējat, kas ir izdarīts un kas vēl atlikts. Katrai fāzei ir savs ritms, un tieši pārejas starp šīm fāzēm ir vietas, kur procesi praktiski apstājas.
Problēmu identificēšanas fāze parasti norises ātri
Galveno lapu un svarīgāko plūsmu skenēšana — pasūtīšanas darbplūsma, autentificēšanas plūsma, kontaktformulārs — parasti aizņem dienas, nevis nedēļas. Automātiskā tūkošana atrod ievērojamu daļu bieži sastopamo problēmu: trūkstošu alternatīvo tekstu, formas laukus bez parakstiem, nepietiekamu kontrastu. Daļa prasību nevar novērtēt automātiski, un tas ir norādīts katrā pārskatā; šīs problēmas pieprasa personu, kas lapas patiešām pārlūko. Ja vēlaties vispirms noskaidrot, vai tas ir svarīgi jūsu organizācijai, pirms veltīsiet laiku skenēšanai, tad īss jautājumu saraksts ar tiešu norādi tam sniedz priekšstatu.
Prioritizēšana prasa laiku nevis tāpēc, ka tas ir grūti, bet tāpēc, ka tas prasa lēmumus
Darbību saraksts ar desmit līdz trīsdesmit punktiem izskatās pārredzams, bet katrs punkts prasa lēmumu: kurš par to atbildīgs, kad un cik steidzami tas ir attiecībā pret citu darbu. Šī ir fāze, kur daudzi procesi palēninās — nevis tehniskās nespējas dēļ, bet tāpēc, ka nevienam nav skaidra atbildība par sarakstu. Darbību saraksts parastu valodu, bez WCAG žargona, palīdz šeit: biroja vadītājam vai HR vadītājam nav jāzina, kas ir ARIA marķieris, lai saprastu, ka kontaktformulārs ir problēma. Ko prioritizēšanu bieži palēnina, nav saturs, bet gan skaidra termiņa trūkums katram punktam — tieši tam domāts uzlabošanas plāns ar termiņiem.
Izpilde ir atkarīga no izstrādātāja, nevis no regulējuma
Faktiskā problēmas labošana — koda pielāgošana, alternatīvā teksta rakstīšana, kontrasta palielināšana — ir ārpus toņošanas pakalpojuma darbības. Axessia veic tūkošanu, prioritizē, dokumentē un paudzina, bet neveic labošanas darbus. Šīs fāzes ilgums ir atkarīgs no jūsu pašu izstrādātāja vai jūsu vietni pārvaldošā uzņēmuma kapacitātes, un no tā, kā šie labojumi iekļaujas sprintā vai plānā. Vienkāršas tēmas e-komercijas vietnei tas var notikt dažu nedēļu laikā; pielāgotam risinājumam ar sarežģītu pasūtīšanas darbplūsmu tas var ilgt mēnešus, īpaši ja labojumi skar norēķinu sistēmu vai autentificēšanas plūsmu un tāpēc prasa papildu testēšanas raundus.
Šeit ir arī pārklājuma logrīka bīstamā vieta: tas solās ātru risinājumu vienas dienas laikā, bet neatbilst pamatprasībai un nemaina pamatā esošo kodu. Kurš iegūst laiku ar pārklājumu, tas to pazaudē vēlāk, kad izrādās, ka problēmas joprojām pastāv.
Dokumentēšana un paziņošana ir īsākais posms, ja pārējais ir pareizs
Ja problēmas ir novērstas, pašas deklarācijas izstrāde ir salīdzinoši ātri — tā galvenokārt ir jūsu pašu novērtējuma pareiza dokumentēšana. Šis posms apstājas tikai tad, ja iepriekšējie posmi nav labi dokumentēti: bez ticamas novērtēšanas pamatnes deklarācijai nav uz kā balstīties. Vairāk informācijas par to, kas nepieciešams, zināšanu bāzē pa tēmām.
Un tad: katrs labojums atsāk ciklu no jauna
Lielākais pārpratums par izpildes laiku ir tas, ka process beidzas pēc deklarācijas publicēšanas. Jauna lapa, pielāgots pasūtīšanas process vai cits tēmas atjauninājums var ieviest jaunus traucējumus, tādējādi sākas jauns cikls testēšanai, prioritizēšanai un labošanai. Tas padara jautājumu "cik ilgi tas aizņem" patiesībā par jautājumu par atkārtojošu procesu, nevis par vienreizēju projektu.
Vai vēlaties zināt, kur pašlaik atrodas jūsu organizācija un kādi konkrēti soļi ir iespējami? Veiciet bezmaksas ātro skenēšanu vai apskatiet, kā informācija pārskatā tiek apkopota un ko abonements tam pievieno, izmantojot tarifu apskatu.