Form Hatasını Ne Zaman, Nerede ve Nasıl Göstermeli
Formlarda terk oranını yükselten şey genelde doğrulama kuralının kendisi değil, o kuralın hangi anda ve nerede görünür olduğu. Aynı e-posta kontrolü yanlış anda tetiklendiğinde yardımcı olmaktan çıkıp azarlamaya dönüşüyor. Aşağısı zamanlama, konum ve duyurulma üzerine; kural listesi değil, sıralaması bozuk olan üç karar üzerine.
Anında doğrulama ile erken uyarı aynı şey değil
Bu ikisi çoğu kılavuzda yan yana duruyor ve birbirini yalanlıyor. Bir yerde "kullanıcı yazarken doğrula" yazıyor, birkaç madde sonra "alan bitmeden hata gösterme" deniyor. Beş karakter yazmışken "geçersiz e-posta adresi" uyarısı almak, doğru kuralın yanlış anda çalışmasıdır.
İşleyen düzen şu: bir alanı ilk kez odak çıkışında doğrula. Hata verdiyse o alan için dinleyiciyi değiştir ve kullanıcı düzeltirken canlı kontrol et. Böylece kimse yazarken uyarı yemiyor, düzeltirken de gönder tuşuna basmayı beklemiyor. Alanın bir kez doğrulandığını tek bir bayrakla tut, dinleyiciyi ondan sonra değiştir; bunun için ayrı bir doğrulama kütüphanesi kurmaya gerek yok.
Mesaj alanın yanında durmalı
Hata metninin yeri ilgili alanın hemen altı. Tooltip bunun yerini tutmuyor: dokunmatik ekranda hover yok, klavyeyle gezen kullanıcı ipucunu hiç açmayabilir, ekran daraldığında balon alanı örtüyor. Görülmesi ekstra çaba isteyen mesaj, pratikte gösterilmemiş mesajdır.
Çok hatalı uzun formlarda üstte özet liste iyi çalışır, ama tek başına yeterli değil. Özetin her maddesini ilgili alana götüren bir bağlantı yap, alanın yanındaki açıklamayı da yerinde bırak. Kullanıcı hatayı listede okuyup düzeltmeyi aşağıda yapıyor, iki yerde de metin bulunmalı.
Metin ne yapılacağını söylesin
"Geçersiz değer" cümlesi kullanıcıya hiçbir şey vermiyor. Kuralı ve düzeltmeyi tek cümlede ver: "Şifre en az 10 karakter olmalı ve bir rakam içermeli." Aynı bilgi hata anında değil, alanın altında baştan dursun; kuralı yalnızca hata mesajında açıklayan form, kullanıcıyı kural öğrenmek için hata yapmaya zorluyor.
Renk tek başına sinyal değil
Kırmızı çerçeve tek gösterge olduğunda kırmızı-yeşil ayrımı zayıf olan kullanıcı hiçbir şey görmüyor. WCAG'nin 1.4.1 ölçütü tam da bunu söylüyor: renk, bilgiyi taşıyan tek araç olamaz. Yanına ikon ve metin koy. Hata metninin kendi kontrastı da unutuluyor; açık gri zemine açık kırmızı yazan formlar 4.5:1 eşiğinin çok altında kalıyor.
Ekran okuyucu kırmızıyı görmüyor
Görsel tarafı doğru kurulmuş bir formun erişilebilirlik tarafı çoğu zaman boş oluyor. Hatalı alana aria-invalid="true" ver, hata metninin id'sini alana aria-describedby ile bağla; böylece alan okunduğunda mesaj da okunuyor. Sonradan beliren mesajın duyulması için kapsayıcı, içi boşken sayfada bulunmalı ve aria-live="polite" taşımalı. Gönderim başarısızsa odağı ilk hatalı alana ya da özet listesine taşı, kullanıcıyı formun sonunda bırakma.
Sunucu aynı cümleyi kurmalı
İstemci tarafındaki doğrulama kolaylıktır, kuralı uygulayan yer sunucudur. Sorun, aynı kuralın iki yerde ayrı ayrı yazılıp zamanla birbirinden ayrı düşmesi. Kullanıcı ekranda onay alıp gönderiyor, dönen yanıtta hiç görmediği bir cümleyle karşılaşıyor. Mesaj metinlerini tek yerde tut ve iki tarafa da oradan besle. Başarısız gönderimde girilen veriyi de geri yaz; kullanıcıya formu ikinci kez doldurtan hata mesajı, mesajın kendisinden daha çok zarar veriyor.
Aynı hata tekrar ediyorsa sorun kullanıcıda değil
Bir alanda aynı hata sürekli tekrarlıyorsa çözüm daha iyi bir uyarı metni yazmak değil, kuralı gevşetmek. Telefon numarasında boşluk ve tire kabul et, sonra normalize et; kart numarasında dörtlü grupları temizle; e-postanın başındaki ve sonundaki boşluğu sessizce kırp. Bunlar sunucuda üç beş satır tutuyor ve kullanıcıya hiç göstermediğin hata, en iyi hata mesajından daha iyi.