Poveikis, ne klaidų skaičius
Pradėkite nuo poveikio žmogui
Audito ataskaitoje gali būti kelios dešimtys ar net šimtai pastabų. Jų skaičius nepasako, nuo ko pradėti. Viena klaviatūros gaudyklė atsiskaitymo lange gali visiškai sustabdyti pirkėją, o keliolika pavienių aprašymo trūkumų mažai lankomuose puslapiuose gali turėti gerokai mažesnį poveikį.
Vertindami kiekvieną problemą pirmiausia atsakykite į keturis klausimus:
- Ar žmogus gali užbaigti numatytą užduotį?
- Kuriems naudotojams ir pagalbinėms technologijoms problema trukdo?
- Ar yra aiškus ir lygiavertis alternatyvus kelias?
- Ar klaida gali lemti neteisingą užsakymą, mokėjimą arba duomenų praradimą?
WCAG atitikties lygis ir problemos prioritetas nėra tas pats. A ar AA kriterijus nurodo standarto reikalavimą, bet ne konkrečios klaidos poveikį jūsų svetainėje. Prioritetas turi būti pagrįstas realiu naudotojo scenarijumi.
Trumpa prioritetų taisyklė
Pirmiausia taisykite tai, kas blokuoja žmogų, tada – tai, kas sukelia didelę riziką ar kartojasi svarbiausiose svetainės vietose.
Apsaugokite svarbiausius procesus
E. parduotuvėje didžiausią vertę sukuria ne atskiras puslapis, o visas kliento kelias. Todėl prioritetus tikrinkite pagal procesus: nuo produkto radimo iki sėkmingo mokėjimo ir patvirtinimo.
Pirmojoje darbų eilėje paprastai turi būti problemos, veikiančios šias užduotis:
- Pagrindinė navigacija, paieška, filtrai ir rikiavimas
- Produkto informacijos, kainos, variantų ir likučio supratimas
- Prekės įdėjimas į krepšelį ir kiekio keitimas
- Kontaktinių, pristatymo ir sąskaitos duomenų įvedimas
- Užsakymo peržiūra, klaidų ištaisymas ir mokėjimas
- Prisijungimas, užsakymų istorija ir pagalbos gavimas
Patikrinkite visą procesą vien klaviatūra, su ekrano skaitymo programa ir padidintu vaizdu. Taip pamatysite ne tik pavienes technines klaidas, bet ir jų bendrą poveikį. Pavyzdžiui, netinkama fokuso tvarka gali būti pakenčiama informaciniame puslapyje, bet kritinė mokėjimo patvirtinimo lange.
Pirmiau taisykite bendrus komponentus
Ta pati klaida dažnai kartojasi šimtuose puslapių, nes ją sukuria vienas bendras komponentas. Pataisius antraštę, navigaciją, produkto kortelę, filtrų skydelį, modalinį langą ar formos lauką jų šaltinyje, iš karto pagerėja visa svetainė.
Prieš kuriant daug atskirų užduočių verta patikrinti, ar problemą galima išspręsti dizaino sistemoje, šablone arba komponentų bibliotekoje. Toks pakeitimas paprastai duoda daugiau naudos ir sumažina tikimybę, kad klaida vėl atsiras.
Ypač atidžiai vertinkite komponentus, kurie:
- rodomi kiekviename puslapyje, pavyzdžiui, antraštė ir poraštė;
- naudojami svarbiuose veiksmuose, pavyzdžiui, mygtukai, laukai ir dialogai;
- keičia turinį neperkraunant puslapio;
- teikiami trečiųjų šalių, pavyzdžiui, mokėjimo ar slapukų sutikimo langai.
Naudokite aiškius prioritetų lygius
Komandai lengviau priimti sprendimus, kai visi naudoja vienodas sąvokas. Keturių lygių sistema paprastai yra pakankamai aiški:
P0 – kritinis
Užduoties neįmanoma atlikti arba nėra lygiavertės alternatyvos. Pavyzdžiai: klaviatūros fokusas įstringa lange, negalima pasirinkti pristatymo būdo, mokėjimo laukai neturi suprantamų pavadinimų arba klaidos neleidžia pateikti užsakymo.
P1 – aukštas
Užduotį galima atlikti tik su didele papildoma pastanga, klaidos rizika arba kitų žmonių pagalba. Čia gali patekti nematomas fokusas, neaiškūs validavimo pranešimai, neteisinga skaitymo tvarka ar nepakankamas svarbaus teksto kontrastas.
P2 – vidutinis
Problema sukelia pastebimą trintį, tačiau yra suprantamas alternatyvus kelias ir svarbiausia užduotis lieka įveikiama. Tokias klaidas planuokite į artimiausius produkto ar komponento darbus.
P3 – žemas
Poveikis ribotas, problema pasitaiko retai arba susijusi su ne pagrindiniu turiniu. Tai nereiškia, kad jos galima nepaisyti – tiesiog ji tvarkoma po didesnio poveikio darbų.
Prie kiekvieno lygio sutarkite konkretų terminą, atsakingą žmogų ir išimtis. Be šių susitarimų prioritetas liks tik etikete darbų valdymo sistemoje.
Pastangas vertinkite atskirai
Didelis kūrimo darbas nereiškia mažo prioriteto, o greitas pataisymas nebūtinai yra svarbiausias. Užduoties poveikį ir įgyvendinimo pastangas laikykite dviem atskirais laukais.
- Didelis poveikis ir mažos pastangos – taisykite nedelsiant.
- Didelis poveikis ir didelės pastangos – skaidykite į etapus, paskirkite savininką ir terminą.
- Mažas poveikis ir mažos pastangos – sugrupuokite su artimiausiu susijusiu pakeitimu.
- Mažas poveikis ir didelės pastangos – planuokite vėliau, bet dokumentuokite sprendimą.
Jeigu galutinis sprendimas užtruks, numatykite laikiną, realiai veikiantį būdą žmogui užduotį atlikti. Vien kontaktinio telefono numerio pateikimas ne visada yra lygiavertė alternatyva, ypač kai paslauga reikalinga kitu paros metu ar žmogus negali skambinti.
Patikrinkite rezultatą
Užduotis neturėtų būti uždaroma vien todėl, kad pakeistas kodas. Prie jos pridėkite aiškius priėmimo kriterijus: kam problema trukdė, kaip ją pakartoti, kokio elgesio tikimasi, kuriuos komponentus pakeitimas apima ir kaip bus atliekamas pakartotinis testas.
Po pataisymo patikrinkite:
- tą patį scenarijų ir visą susijusį kliento procesą;
- valdymą klaviatūra ir matomą fokuso vietą;
- pavadinimus, vaidmenis, būsenas ir pranešimus ekrano skaitymo programoje;
- didinimą, turinio persitvarkymą ir mobilųjį vaizdą;
- ar pakeitimas nesukėlė regresijų kituose puslapiuose.
Automatiniai testai naudingi regresijoms stebėti, tačiau jie nepakeičia rankinio patikrinimo. Darbas baigtas tik tada, kai iš naujo įrodyta, kad žmogus gali sėkmingai atlikti užduotį.