Form hatalarında kullanıcıyı doğru alana nasıl yönlendirirsiniz?
Uzun bir teklif formunda Gönder düğmesine basıldığında sayfanın başında bir hata kalabilir. Kullanıcı aşağıdaysa neyi düzeltmesi gerektiğini göremeyebilir. Buradaki tasarım kararı, hata olduğunu bildirmekle birlikte düzeltilecek alana ulaşmayı da kolaylaştırmaktır. Hata özeti, alan yanındaki açıklama ve korunmuş girişler bu akışın birlikte ele alınması gereken parçalarıdır. Aşağıdaki teklif örneği temsili bir uygulama senaryosudur.
Hatayı görsel işaretten açık açıklamaya taşıyın
W3C'nin hata tanımlama açıklaması, otomatik tespit edilen hatanın hangi alanda olduğunu ve sorunu metinle belirtmeyi ele alır. Yalnız rengi değişmiş bir kutu, hatanın ne olduğunu söylemez. Temsili teklif formunda “Hata oluştu” yerine “E-posta adresinde @ işareti eksik” gibi duruma uygun bir açıklama kullanabilirsiniz. Gerçek doğrulama kuralını yansıtın; geçerli bir adres biçimini gereksiz yere reddeden aşırı dar kuralları da inceleyin. Hata mesajının kendisi yanlış yönlendirmemelidir.
Özet ile alan mesajını aynı düzeltmeye bağlayın
GOV.UK Design System, hata özeti ve alan yanındaki mesajları birlikte kullanır; özetten ilgili alana bağlantı verir. Bu somut arayüz örneğini kendi formunuza uyarlarken kısa bir başlık ve anlaşılır hata listesi hazırlayın. Özet ile alan yanındaki ifade aynı sorunu anlatmalıdır. Örneğin listede e-posta düzeltmesi yazarken altta genel bir zorunlu alan uyarısı bırakmayın. Bağlantının yalnız sayfayı aşağı kaydırması değil, kullanıcının doğru girişle devam edebilmesi de kontrol edilmelidir.
Odağı ve mevcut cevapları birlikte düşünün
Gönderim sonrası hata gösterildiğinde klavye kullanıcısının yeni durumu fark etmesini sağlayan bir odak akışı tasarlayın; GOV.UK örneğinde odak hata özetine gider. Kendi uygulamanızda bu davranışı gerçek klavye ve ekran okuyucu denemesiyle kontrol edin. Temsili formda e-posta yanlış diye proje açıklamasını, seçilen hizmeti ve doğru girilmiş diğer cevapları silmeyin. Kullanıcının bütün formu yeniden doldurması gerekmemelidir. Dosya yüklemesinin yeniden seçilmesi gerekiyorsa bunu ayrıca ve açıkça belirtin.
Alan hatası ile sistem sorununu ayırın
Eksik e-posta ile sunucuya ulaşılamaması aynı durum değildir. Bağlantı hatasında kullanıcıya doğru yazdığı alanları düzeltmesini söylemek yanıltır. İşlemin kaydedilip kaydedilmediği bilinmiyorsa başarı mesajı üretmeyin. Sistem kaynaklı sorunda neyin doğrulandığını ve kullanıcının hangi güvenli adımı atabileceğini açık anlatın. Teklif örneğinde alandaki düzeltme tamamlandığında aynı form üzerinden devam edilebilmelidir; iş tekrar gönderim veya mükerrer kayıt oluşturuyorsa bunun ayrı teknik kontrolü gerekir.
Yayından önce birkaç gerçek hata yolunu deneyin
Bir zorunlu alanı boş bırakın, farklı bir alanı hatalı doldurun ve formu telefon genişliğinde gönderin. Özette doğru alanlar var mı, bağlantılar çalışıyor mu, klavye odağı görünür mü, diğer cevaplar korunuyor mu? Ardından tek hatayı düzeltip yeniden deneyin; artık geçerli olan alan için eski uyarı kalmamalıdır. Bu denemeyi sadece ideal başarı yolu üzerinden değerlendirmeyin. Web tasarım tesliminde hata yollarını da kabul kontrolüne ekleyin ve teklif formunun gerçek iş akışıyla birlikte inceleyin. Bu kontroller erişilebilirliğin tamamının doğrulandığı veya dönüşüm artışı ölçüldüğü anlamına gelmez.
Sık sorulan sorular
Tek bir hata varsa özet gereksiz mi?
GOV.UK kendi bileşeninde tek doğrulama hatasında da özeti kullanır. Kendi formunuzda hatanın fark edilmesi ve düzeltmeye erişim birlikte değerlendirilmelidir.
Tarayıcının uyarısı tek başına yeterli mi?
Bunu formun gerçek davranışını test etmeden söylemek doğru olmaz. İstemci ve sunucu kontrollerinin kullanıcıya tutarlı bir düzeltme yolu sunması gerekir.