Kontaktformas piekļūstamību pārbaudi, izpildot visu pieteikuma ceļu bez peles: sasniedz laukus, ievadi datus, izlabo kļūdu un saņem saprotamu nosūtīšanas rezultātu. Ja fokuss pazūd vai kļūdas paziņojums nenorāda labojamo lauku, forma vēl nav pieņemama tikai tāpēc, ka to var nosūtīt ar peli.
Pārbaude jāveic tai pašai formai un stāvokļiem, ko lieto klients. Kontroles laukums dizaina failā neparāda, kas notiek pēc neveiksmīgas validācijas, faila pievienošanas vai servera kļūdas. Būtiska ir arī formai priekšā esoša sīkdatņu izvēlne vai atvēršanas dialogs, ja bez tā līdz pieteikumam nevar tikt.
Šis ceļvedis palīdz atkārtot konkrētu defektu un pieņemt tā labojumu. Vienas formas pārbaude neapliecina visas vietnes WCAG vai juridisku atbilstību. Automātisks rīks ir palīgs, bet pilns cilvēka ceļš jāpārbauda arī manuāli.
Kontaktformas pārbaudei nosaki sākumu un beigas
Pieraksti lapas adresi, pārlūku, operētājsistēmu un formas versiju, ja tā zināma. Izvēlies vienu uzdevumu, piemēram, iesniegt pakalpojuma jautājumu ar pielikumu. Beigu nosacījums ir saprotama atbilde par iesniegumu, ne vienkārši nospiesta poga.
Izmanto testa vidi vai saskaņotu testa pieteikumu. Neievadi īsta klienta personas datus tikai defekta demonstrācijai. Ja produkcijā tests rada reālu pārdošanas uzdevumu, iepriekš nosaki marķējumu un atbildīgo, lai to nesajauc ar klienta pieprasījumu.
Sākumā izpildi normālu ceļu, pēc tam apzināti atstāj obligātu lauku tukšu vai ievadi neatbilstošu formātu. Tādējādi pārbaudi gan aizpildīšanu, gan atgūšanos pēc kļūdas. Servera nepieejamību vai citus tehniskus scenārijus testē kontrolēti ar izstrādātāju, ne bojājot publisko pakalpojumu.
W3C WAI formu pamācība aptver etiķetes, instrukcijas, validāciju un lietotāja paziņojumus. Formu piekļūstamības pamats. Šīs sastāvdaļas jāvērtē kopā: tehniski sasniedzams lauks vēl var būt nesaprotams.
Vai ar tastatūru iespējams sasniegt visas darbības
Sāc ar Tab un Shift+Tab, lai pārvietotos uz priekšu un atpakaļ. Standarta vadīklās izmanto tām paredzētos taustiņus. Pārbaudi teksta laukus, izvēles, piekrišanas rūtiņu, faila pievienošanu un nosūtīšanu. Ja ir pielāgots kalendārs vai izvēlne, jābūt saprotamai tastatūras darbībai arī tur.
WCAG tastatūras kritērijs attiecas uz funkcionalitātes izmantošanu ar tastatūras saskarni, ar precīzi noteiktiem izņēmumiem. Keyboard skaidrojums. Kontaktformas pogai vai izvēlei parasti nav pamata būt pieejamai tikai peles klikšķim. Izstrādātājam jānovērš cēlonis, ne jāpievieno padoms “izmantojiet peli”.
Pieraksti pirmo vietu, kur turpinājums vairs nav iespējams. Piemēram, fokuss sasniedz datuma lauku, bet kalendāru nevar aizvērt vai izvēlēties datumu. Defekta ziņojumā nepieciešami taustiņi un novērotais rezultāts. “Forma nav piekļūstama” ir pārāk plašs uzdevums precīzam labojumam.
Pārbaudi arī atgriešanos no atvērtas vadīklas. Lietotājs nedrīkst iestrēgt dialogā vai nejauši pāriet uz paslēptiem fona elementiem. Darbībai jābūt paredzamai, un atgriešanās vietai jāpalīdz turpināt iesākto uzdevumu.
Redzams fokuss parāda, kur notiks darbība
Katrā solī jāspēj redzēt, kura vadīkla ir aktīva. Ja dizainā noņemts kontūrlīnijas stils bez piemērota aizvietojuma, lietotājs var nezināt, kur raksta vai kuru pogu aktivizēs. W3C Focus Visible.
Testā atšķir neredzamu fokusu no nepareizas secības. Pirmajā gadījumā vadīkla var būt sasniegta, bet pazīme nav redzama. Otrajā fokuss var lēkt starp savstarpēji nesaistītām vietām. Ekrāna ieraksts ar taustiņu secību palīdz izstrādātājam redzēt, kura problēma jālabo.
Pārbaudi formu arī ar atvērtu kļūdas paziņojumu, lipīgu galveni vai apakšā novietotu paziņojumu joslu. Fokusa pazīme var eksistēt, bet aktīvais lauks būt aizsegts. Nevērtē tikai sākotnējo, tukšo formas ekrānu.
Pozitīvu rezultātu formulē konkrēti: testētajā pārlūkā visi vajadzīgie elementi ir sasniedzami un fokuss redzams. No tā neizriet, ka pārbaudītas visas ierīces vai palīgtehnoloģijas. Pārbaudes tvērumu saglabā kopā ar rezultātu.
Etiķetei jābūt saistītai ar lauku
Redzams uzraksts virs ievades lauka ne vienmēr nozīmē tehnisku saiti. W3C iesaka identificēt vadīklu ar atbilstoši saistītu etiķeti. Standarta HTML formā to bieži veido ar label un lauka identitāti. Lauku etiķešu pamācība.
Placeholder teksts pazūd, sākot rakstīt, un nav pilnvērtīgs etiķetes aizstājējs. Lietotājam joprojām jāspēj noteikt, ko laukā ievada. Paskaidrojumam par formātu vai obligātumu jābūt pieejamam pie attiecīgā lauka. Ar krāsu vai vizuālu novietojumu vien nepietiek.
Ekrāna lasītāja testā pieraksti, ko tas paziņo, sasniedzot lauku: nosaukumu, vadīklas veidu, vajadzīgo paskaidrojumu un kļūdas stāvokli. Negaidi vienādu balsī nolasītu teikumu visās programmās; pārbaudi, vai vajadzīgā nozīme ir pieejama.
Ja formai ir vairākas valodas, katru pārbauda savā versijā. Latviska lauka etiķete ar angļu kļūdu vai nepareizu lapas valodas iestatījumu var radīt neskaidru lietojumu. Tulkojuma esamība datubāzē vēl nepierāda, ka tas parādās faktiskajā kļūdas stāvoklī.
Kļūdas paziņojumam jāpalīdz atgriezties pie darba
Pēc neatbilstošas ievades lietotājam jāzina, kas nav pieņemts un ko labot. W3C paziņojumu pamācība skaidro kļūdu un veiksmīga rezultāta paziņošanu. User Notifications. Sarkana apmale viena pati nenodod visu nepieciešamo informāciju.
Praktiskajā testā izmanto vienu kļūdainu lauku. Pārbaudi, vai paziņojums nosauc problēmu un vai ar tastatūru var nokļūt pie labojuma. Ja izvēlēts kļūdu kopsavilkums, pārbaudi tā saites. Ja fokusu pārvieto uz kļūdaino lauku, pārbaudi, ka konteksts nepazūd. Viens risinājums nav automātiski obligāts visām formām; tam jādarbojas konkrētajā plūsmā.
Saglabā korekti ievadītos datus, kur tas droši iespējams. Ja pēc vienas kļūdas pazūd viss apraksts vai pielikuma statuss, lietotājam jāsāk no jauna. Sensitīviem laukiem var būt īpaši ierobežojumi, tāpēc uzvedību nosaka apzināti un skaidri paskaidro.
Tehniska nosūtīšanas kļūme jāatšķir no nepareizas ievades. “Pārbaudiet formu” nepalīdz, ja serveris neatbild. Lietotājam jāsaņem saprotams statuss un nākamā darbība, nepiespiežot akli nosūtīt vienu pieteikumu vairākas reizes.
Manuālā testa soļi un sagaidāmais rezultāts
Tabula ir veidne vienai formai. Aizpildi faktisko rezultātu un pierādījumu katram solim. Ja darbība nav piemērojama, atzīmē to, nevis uzrādi kā veiksmīgi pārbaudītu.
|
Solis |
Darbība |
Sagaidāmais rezultāts |
|
Sākums |
Atver formu un sāk ar tastatūru |
Pieteikuma ceļš sasniedzams |
|
Pārvietošanās |
Iziet laukus uz priekšu un atpakaļ |
Saprotama secība un redzams fokuss |
|
Pielāgota izvēle |
Atver un aizver kalendāru vai izvēlni |
Var izvēlēties un turpināt bez peles |
|
Etiķete |
Sasniedz lauku ar ekrāna lasītāju |
Nosaukums un paskaidrojums ir pieejams |
|
Ievades kļūda |
Nosūta ar vienu neatbilstošu vērtību |
Saprotams iemesls un ceļš uz labojumu |
|
Atgūšanās |
Izlabo lauku un atkārto nosūtīšanu |
Korektie dati nav nepamatoti pazuduši |
|
Noslēgums |
Saņem iesnieguma rezultātu |
Lietotājs saprot, vai pieteikums pieņemts |
Defektam pievieno adresi, soļus, sagaidāmo un faktisko rezultātu, vides aprakstu un piemērotu ekrāna ierakstu. Neiekļauj sensitīvas vērtības. Ja problēmu redzi tikai noteiktā loga platumā vai pēc konkrētas izvēles, tas ir svarīgs atkārtošanas nosacījums.
Pirms labojuma pieņemšanas atkārto tieši to pašu scenāriju. Pēc tam pārbaudi blakus ceļus: bez kļūdas, ar citu izvēli un atgriežoties iepriekšējā solī. Viena fokusa labojums nedrīkst padarīt citu lauku nesasniedzamu.
Ko automātiska pārbaude nepierāda
Rīks var atrast tehniskas problēmas un palīdzēt atkārtot noteiktas pārbaudes. Tomēr tas pats neapliecina, ka etiķete cilvēkam ir saprotama, secība loģiska vai kļūdas atgūšana praktiski izpildāma. Tukšs kļūdu saraksts jālasa kopā ar pārbaudes tvērumu.
Arī manuāls tastatūras tests neaizstāj ekrāna lasītāja pārbaudi. Tie atklāj dažādas problēmas. Ja komandai nav pieredzes ar attiecīgo palīgtehnoloģiju, precīzi norādi ierobežojumu un plāno kompetentu pārbaudi. Neatzīmē neizpildītu soli kā PASS.
Labošanas prioritāti nosaki pēc tā, vai cilvēks spēj pabeigt būtisko darbību. Pilnībā nesasniedzama nosūtīšanas poga vai iestrēgšana izvēlnē ir tiešs šķērslis. Kosmētiskas atšķirības novērtē atsevišķi, nezaudējot kritisko pieteikuma ceļu.
Labojuma pieņemšana un turpmāka uzturēšana
Pieņemšanas ierakstā saglabā formas versiju, pārbaudīto vidi un rezultātu. Ja maina komponentu bibliotēku, validāciju vai trešās puses formu, atkārto būtiskos scenārijus. Piekļūstamība var mainīties arī tad, ja lauku saturs palicis tas pats.
Komandai vajadzīgs neliels atkārtojams tests, ne tikai vispārīga prasība projektā. Sasaisti to ar pieteikuma plūsmu, lai izstrādātājs, redaktors un pasūtītājs saprot, ko uzskata par gatavu. Faktisko rezultātu atšķir no vēl nepārbaudītām vides kombinācijām.
Vai pietiek pievienot ARIA atribūtus?
Nē. Atribūtiem jāatbilst faktiskajai vadīklai un tās uzvedībai. Standarta semantiska vadīkla bieži ir piemērots sākums, bet tastatūras darbība un paziņojumi joprojām jāpārbauda.
Vai pēc kļūdas fokuss vienmēr jāpārvieto uz pirmo lauku?
Svarīgi, lai cilvēks saprastu kļūdu un varētu to izlabot. Konkrēto fokusa un paziņojuma risinājumu pārbauda kopā ar formas struktūru un palīgtehnoloģiju, ne mehāniski ievieš vienu noteikumu visur.
Vai šis tests apliecina visas vietnes atbilstību?
Nē. Tas aptver izvēlēto plūsmu un testētās vides. Pilnam izvērtējumam vajadzīgs plašāks tvērums un attiecīgās prasības.
Ja jāizvēlas paši kvalifikācijas jautājumi, lasi par klienta pieteikuma formas saturu. Plašākas nodošanas pārbaudes atrodamas mājaslapas pieņemšanas testēšanas ceļvedī. Mājaslapas uzlabojumu izvērtējumam atsūti formas adresi un precīzu neveiksmīgo lietošanas scenāriju.