Satır içi doğrulama (inline validation): ne zaman, nasıl?

Kısaca

Satır içi doğrulama (inline validation), formdaki bir değerin doğru olup olmadığını alanın yanında söyler. Kullanıcı formu gönderip hatayı sayfanın başında aramak zorunda kalmaz. Türkçede anlık form doğrulama ya da canlı doğrulama da denir.

Asıl soru doğrulamanın zamanıdır. Üç seçenek var: yazarken, alandan çıkınca ve gönderince. Yanlış zamanlama, iyi yazılmış bir hata mesajını bile can sıkıcı hale getirir.

Bu sayfa zamanlamayı ve hatanın ekranda nasıl duyurulacağını anlatıyor. Mesajın kendisini nasıl yazacağınızı hata mesajları kalıbında, formun genel düzenini form tasarımı sayfasında anlattım.

Ne zaman doğrulanır: üç zamanlama

Şekil: Aynı alanda üç zamanlama. Kutular kullanıcının adımları, kalın çerçeveli kutu hatanın ilk göründüğü an.

Yazarken

Her tuşa basışta kontrol edilir. Kâğıt üstünde en hızlı geri bildirim budur. Pratikte ise kullanıcı adresin ilk harfini yazar yazmaz "geçersiz e-posta" uyarısıyla karşılaşır.

Alandan çıkınca

Kullanıcı alanı bitirip bir sonrakine geçince kontrol edilir. Teknik adı blur olayıdır. NN/g'den Rachel Krause'a göre çoğu durumda hata, kullanıcı alanla işini bitirip sonrakine geçene kadar gösterilmemeli.

Baymard'dan Edward Scott da aynı şeyi söyler: alanın geçerliliği kullanıcı alandan çıkınca kontrol edilmeli. Posta kodu, telefon ve kart numarası gibi alanlarda ek bir yol önerir. Değer doğru uzunluğa ulaşınca da kontrol edilebilir.

Gönderince

GOV.UK Design System bu konuda farklı düşünür. Validation kalıbı, kullanıcı alandan çıkınca doğrulama yapmamanızı söyler. Kontrol, kullanıcı Devam ya da Gönder butonuna basınca yapılır.

GOV.UK yazarken doğrulamaya yalnızca bir koşulla izin verir. Kullanıcı araştırması, bunun çözdüğü sorunların yarattıklarından fazla olduğunu göstermelidir. Verdiği örnek, cevap çok uzayınca uyaran karakter sayacıdır.

Ünlü %22 çalışması

Satır içi doğrulama denince en çok anılan rakam Luke Wroblewski'den gelir. 1 Eylül 2009'da A List Apart'ta yayımlanan yazısında, Londra'daki Etre ile yaptıkları bir testi anlatır. 21 ile 49 yaş arası 22 kullanıcı, bir kayıt formunun altı sürümünü denedi.

Kontrol sürümü yalnızca "hesap oluştur" butonuna basınca doğruluyordu. En iyi satır içi sürümde başarı oranı %22 arttı, hatalar %22 azaldı. Memnuniyet %31 arttı, tamamlama süresi %42 kısaldı.

Bu rakamları okurken bağlamı unutmayın. Tek bir kayıt formu, 22 kişi ve 2009'un arayüzleri söz konusu. Bu sonuç sizin formunuzda aynı artışı vaat etmez, yalnızca yönü gösterir.

Aynı çalışmanın zamanlama bulgusu bence rakamlardan daha değerli. Alandan çıkınca doğrulayan sürümde katılımcılar formu, yazarken doğrulayanlara göre 7 ila 10 saniye daha hızlı bitirdi. Yazarken doğrulamada hata görünce bir harf daha yazıp mesajın yenilenmesini bekliyorlardı. Hata sürerse aynı döngü tekrarlanıyordu.

Deneyin: aynı form, üç zamanlama

Aşağıdaki formda bir e-posta ve bir şifre alanı var. Zamanlamayı değiştirince iki alanın davranışı da değişir. Hata mesajları her modda aynıdır, yalnızca ortaya çıktıkları an farklıdır.

Yazarken modunda e-postanın ilk harfinde hata çıktığını görürsünüz. Alandan çıkınca modunda aynı adresi rahatça yazarsınız. Hata çıksa bile, düzelttiğiniz harfte kaybolur.

Gönderince modunda iki hatayı birden, formun üstündeki özette görürsünüz. Özetteki bağlantıya basınca imleç ilgili alana gider.

Erken hata gösterme sorunu

Erken hata, kullanıcı daha yazmayı bitirmeden ona yanlış yaptığını söylemektir. Krause bunu açıkça yazar: yazmayı bitirme fırsatı verilmeden hata mesajı görmek sinir bozucudur.

Baymard'ın testlerinde bir katılımcı, adresini daha bitirmeden e-postasının yanlış olduğunun söylenmesine tepki gösterdi. Scott'a göre aşırı erken doğrulama deneyimin bütününe zarar verir. Kullanıcılar yazmayı bırakıp mesajı okudu, bazen doğru girdiyi yanlış sandı.

Wroblewski'nin testinde de en kötü sonucu, kullanıcı yazmaya başlamadan önce ve yazarken kontrol eden sürüm verdi. En yüksek hata oranı ve en düşük memnuniyet o sürümdeydi. Wroblewski'nin önerisi şu: açık uçlu cevapları kullanıcı bitirdikten sonra doğrulayın.

Şifre gibi kuralı sıkı alanlarda erken yardım gerekebilir. Testte kullanıcı adı ve şifre alanları her sürümde yazarken, kısa bir gecikmeyle doğrulandı. Wroblewski böyle durumlarda geri bildirimi yazarken, uygun bir gecikmeyle vermeyi önerir.

Ben bunu hata olarak değil, kuralın yanında ilerleyen bir gösterge olarak tasarlamayı tercih ederim.

Hata düzelince hemen kalkmalı

Alandan çıkınca doğrulamanın bir yarısı da hatanın ne zaman kaybolduğudur. Scott'a göre hata mesajı her tuşta güncellenmeli ve geçerli değer girildiği an kaybolmalıdır.

Bu kural birbirine bağlı alanlarda daha da önemlidir. Baymard'ın testindeki bir örnekte katılımcı ilk şifreyi düzeltti, ama "şifreler eşleşmiyor" hatası onay alanına yeniden tıklayana kadar kaldı. Scott'a göre böyle bir durumda kullanıcı, düzelttiği değerin hâlâ hatalı olduğunu sanabilir.

Başarı işaretleri

Başarı işareti, doğru girilen değerin yanına konan onaydır: bir onay işareti ya da "Adresin biçimi doğru" gibi kısa bir yazı. Baymard'ın testlerinde bu işaretler kullanıcıya ilerleme hissi verdi. Formun tamamını yeniden kontrol etme yükünü de azalttı.

Krause ise ölçülü olmayı önerir. Tek kuralı boş bırakılmamak olan bir alan için başarı mesajı gereksizdir. Kullanıcı adının uygun olması ya da şifrenin gücü gibi bilgi taşıyan durumlarda işe yarar.

Wroblewski'nin testinde iki ders daha çıktı. Kaybolan başarı mesajları, ekranda kalanlardan kötü sonuç verdi. Yalnız bir yeşil onay işareti de katılımcıların kafasını karıştırdı: "doğru" mu demek, "geçerli" mi?

Bu yüzden demodaki onaylar yazıyla gelir ve yalnızca kuralı olan iki alanda görünür. Ad gibi basit bir alana onay koymam. Wroblewski'nin katılımcılarından biri, ad alanındaki onayın geçerli bir ad mı yoksa doğru yazılmış bir ad mı demek olduğunu sormuştu.

Hata özeti

Hata özeti, gönderimde formun üstünde açılan ve bütün hataları listeleyen kutudur. Zamanlama hangisi olursa olsun gönderimde bir özet gösteririm. Kullanıcı alandan çıkınca gelen hataları görmeden de Gönder'e basabilir.

GOV.UK'nin Error summary bileşeni bu kutunun kurallarını şöyle koyar:

• Özet ana içeriğin en üstünde, sayfanın ana başlığından (h1) önce durur. Klavye odağı özete taşınır.
• Her madde, hatalı alana giden bir bağlantıdır. Tarih gibi çok parçalı bir soruda bağlantı, hata içeren ilk alana gider.
• Özetteki metin, alanın yanındaki hata mesajıyla birebir aynıdır.
• Tek bir hata olsa bile özet gösterilir.

Özet tek başına yetmez. Krause, özetin tek hata göstergesi olmamasını ister. Kullanıcı ilgili alanı aramak zorunda kalır ve oraya varana kadar mesajı unutabilir. GOV.UK da hem özeti hem alanın yanındaki mesajı birlikte ister.

Validation kalıbı bir şey daha ekler: hata varken sayfa başlığının başına "Error: " yazılır, böylece ekran okuyucu bunu olabildiğince erken okur. Türkçe sayfada ben "Hata: " kullanırım. Kullanıcının yazdıkları da silinmez. Sayfa yeniden açılınca girdiği değerler alanlarda durur.

Erişilebilirlik: aria-invalid, aria-describedby, WCAG

Satır içi doğrulama gözle görenler için kolayca çalışır. Ekran okuyucu kullanan biri için ise hatanın alanla bağlı olması gerekir. Ben üç parçayı birlikte kurarım.

1. aria-invalid="true" hatalı alana eklenir. W3C'nin ARIA21 tekniği bunun doğrulama yapılmadan önce eklenmemesi gerektiğini yazar. Sayfa açılırken boş bir alanı hatalı diye işaretlemeyin.

2. aria-describedby alanı hata metnine bağlar. Aynı teknik, alanın hata mesajına bu öznitelikle işaret ettiği bir örnek verir. Ekran okuyucu alana gelince etiketten sonra ipucunu ve hatayı da okur.

3. Canlı bölge (aria-live) hatanın çıktığını, odağı alandan koparmadan duyurur. W3C, ARIA19 tekniğini 3.3.1 için biçim hataları altında sayar. Demodaki "Ne oldu?" kutusu bu şekilde çalışır.

Bunlar iki WCAG 2.2 başarı ölçütüne dayanır. 3.3.1 Hata tanımlama (A düzeyi), otomatik bulunan hatada hatalı alanın belirtilmesini ve hatanın metinle anlatılmasını ister. Renk kullanılabilir ama metne ek olarak.

3.3.3 Hata önerisi (AA düzeyi) bir adım ileri gider. Hata bulunmuş ve düzeltme önerisi biliniyorsa öneri kullanıcıya gösterilir. Güvenliği ya da içeriğin amacını tehlikeye atacaksa bu şart aranmaz.

Demodaki "E-posta adresini [email protected] biçiminde yazın" mesajı, 3.3.3'ün istediği türden bir öneridir. Şifre alanında ise kullanıcının yazdığı şifreyi mesajda tekrarlamam, bence bu güvenliği zayıflatır. Orada kuralı söylemek yeterli.

Demoda bir de ilk adımı uyguladım: GOV.UK'nin önerdiği gibi forma novalidate ekledim, böylece tarayıcının kendi baloncukları çıkmaz. GOV.UK sunucuda da her zaman doğrulama yapılmasını ister, çünkü tarayıcıdaki kontrol çalışmayabilir. Mobilde doğru klavyeyi açmak da hatayı baştan azaltır, bunu mobil form klavyesi kalıbında anlattım.

Kontrol listesi

Satır içi doğrulaması olan bir formu yayına almadan önce şu listeden geçerim.

• Kullanıcı yazarken hata çıkmıyor.
• Hata, alandan çıkınca ya da gönderimde görünüyor.
• Düzeltilen hata, doğru değer girildiği an kalkıyor.
• Bağlı alanlar, ilk alan değişince yeniden kontrol ediliyor.
• Başarı işareti yalnızca kuralı olan alanlarda ve yazıyla birlikte.
• Gönderimde üstte bir özet açılıyor, odak oraya gidiyor.
• Özetteki her madde alana bağlı ve aynı metni taşıyor.
• Hatalı alanda aria-invalid ve aria-describedby var.
• Hata metinle anlatılıyor, yalnızca renkle değil.
• Sunucu tarafında da doğrulama var.

Benim notum

Audit'lerde en sık gördüğüm doğrulama hatası, ilk harfte çıkan kırmızı uyarıdır. Ekip bunu hızlı geri bildirim diye ekler. Kullanıcı ise daha başlamadan azarlanmış gibi hisseder.

Ben kaynakların ortasında bir yol izliyorum. Yazılmış ama yanlış biçimli değeri alandan çıkınca gösteriyorum. Boş alanı ise gönderime bırakıyorum, çünkü kullanıcı o alana birazdan dönebilir.

GOV.UK'nin gönderimde doğrulama tercihini de ciddiye alıyorum. Tek soruluk sayfalardan oluşan kısa bir formda bu sade yol iyi çalışır. Uzun bir ödeme ya da kayıt formunda ise alandan çıkınca doğrulama daha çok zaman kazandırır.

Formunuzun hangi anda hata gösterdiğini bilmiyorsanız bir kez kendiniz yavaşça doldurun. Sonra aynı turu yalnız klavyeyle ve bir ekran okuyucuyla tekrarlayın. UX Audit içinde bu kontrolü sizin akışınızda ben yapıyorum.