Form hata mesajları.
Bir form hatası erişilebilir sayılmak için üç şey yapmalıdır: hatayı metinle tanımlamalı, hatalı alana programatik olarak bağlanmalı ve ekran okuyucuya duyurulmalıdır.
Form, çoğu sitede tek dönüşüm yoludur — ziyaretçinin müşteriye dönüştüğü yer. Bu yüzden formdaki bir erişilebilirlik kusuru, sitedeki başka herhangi bir kusurdan daha pahalıdır: ana sayfada okunmayan bir metin can sıkar, gönderilemeyen bir form iş kaybettirir. Yine de formlar en sık ihmal edilen alandır çünkü test genelde formu doldurmadan yapılır.
Dört ölçüt bir arada
Form hataları tek bir ölçütle değil, birbirini tamamlayan dörtle düzenlenir. Dördünü birlikte görmek, «hata mesajı koyduk, oldu» yanılgısını önler.
- 3.3.2 Etiketler veya Yönergeler — A. Her alan etiketli olmalı ve gereken biçim önceden söylenmeli. Hata olmadan ÖNCE.
- 3.3.1 Hata Tanımlama — A. Hata oluştuğunda hangi alanda olduğu METİNLE bildirilmeli. Yalnız kırmızı çerçeve yetmez.
- 3.3.3 Hata Önerisi — AA. Mümkünse nasıl düzeltileceği de söylenmeli. «Geçersiz» değil, «gg.aa.yyyy biçiminde girin».
- 4.1.3 Durum Mesajları — AA. Odak değişmeden ortaya çıkan mesaj, ekran okuyucuya duyurulmalı.
Sıralamadaki mantık şudur: en iyi hata mesajı hiç oluşmayan hata mesajıdır. 3.3.2 bu yüzden ilk gelir — biçim beklentisi baştan söylenirse hata oranı düşer. Sonra hatanın tanımlanması, sonra düzeltme önerisi, sonra duyurulması gelir. Çoğu ekip yalnız ikincisini yapar ve diğer üçünü atlar.
Yalnız renk yetmez
En yaygın kusur, hatanın yalnızca görsel olarak işaretlenmesidir: alanın çerçevesi kırmızıya döner ve başka hiçbir şey olmaz. Bu, WCAG'in birden fazla maddesini aynı anda ihlal eder. Renk körlüğü olan bir kullanıcı kırmızıyı ayırt edemez; ekran okuyucu kullanan bir kullanıcı rengi hiç görmez; ve hiçbiri hatanın NE olduğunu öğrenemez.
Doğru davranış, rengi bir ek işaret olarak kullanmaktır — tek işaret olarak değil. Hatanın kendisi metinle ifade edilmeli, metin hatalı alanın hemen yanında durmalı ve programatik olarak o alana bağlanmalıdır. Renk bunun üstüne gelen bir vurgu katmanıdır ve tek başına hiçbir bilgi taşımamalıdır.
Aynı mantık ikonlar için de geçerlidir. Alanın yanına konan bir ünlem ikonu, alternatif metni yoksa ekran okuyucu için görünmezdir; alternatif metni «hata» ise bilgi taşımaz. İkonun taşıması gereken bilgi zaten metin olarak varsa, ikon dekoratif sayılıp boş alternatifle geçilmelidir.
Programatik bağ: mesajı alana bağlamak
Hata metninin ekranda alanın altında durması, görsel bir ilişki kurar ama programatik bir ilişki kurmaz. Ekran okuyucu kullanıcısı alana odaklandığında, altındaki metni duymaz — çünkü o metin, alanın erişilebilir açıklamasının parçası değildir. İlişkinin açıkça bildirilmesi gerekir.
İki şey birlikte yapılır. Alan hatalı olarak işaretlenir, böylece ekran okuyucu odaklandığında «geçersiz giriş» der. Ve hata metni alanın açıklaması olarak bağlanır, böylece metnin kendisi de okunur. İkisi birlikte, kullanıcı alana geldiğinde hem hatalı olduğunu hem neden hatalı olduğunu duyar.
Sık yapılan bir hata, alanı hatalı işaretleyip metni bağlamamaktır. Bu durumda kullanıcı «geçersiz giriş» duyar ama neyin geçersiz olduğunu öğrenemez — ve formu düzeltemez. Yarım uygulanan bir erişilebilirlik özelliği, kullanıcıyı bilgilendirmek yerine yalnızca huzursuz eder.
Duyurma: canlı bölge
Form gönderildiğinde sayfa yenilenmiyorsa — ki modern formların çoğunda yenilenmiyor — sonuç mesajı sayfada sessizce belirir. Gören kullanıcı onu fark eder; ekran okuyucu kullanıcısı fark etmez, çünkü odağı hâlâ gönder düğmesindedir ve ekranda bir şeylerin değiştiğinden haberi yoktur.
Çözüm, mesajın göründüğü bölgeyi canlı bölge olarak işaretlemektir. Bu işaret, ekran okuyucuya «buranın içeriği değişirse kullanıcıya söyle» der. Kritik olan ayrıntı şudur: canlı bölge, içeriği değişmeden ÖNCE sayfada bulunmalıdır. Mesajla birlikte oluşturulan bir canlı bölge çoğu ekran okuyucuda duyurulmaz.
Yani doğru kalıp, boş bir canlı bölgeyi sayfada baştan bulundurmak ve mesajı onun içine yazmaktır. Bu ayrıntı belgelerde küçük bir not gibi görünür ama uygulamada duyurulan ile duyurulmayan mesaj arasındaki tüm farkı yaratır.
Canlı bölge mesajla birlikte doğarsa, mesaj duyulmaz.
Üç durumlu akış
Bir formun erişilebilir sayılması için üç durumun da tanımlı olması gerekir ve çoğu form yalnız ikisini tanımlar. Bu sitedeki iletişim formu üçünü de taşıyor ve süit üçünü de ayrı ayrı ölçüyor.
- Bekliyor — gönder düğmesine basıldıktan sonra, sonuç gelene kadar. Düğme devre dışı bırakılır ve durum metinle bildirilir; yalnız dönen bir animasyon ekran okuyucu için sessizdir.
- Başarılı — mesajın gönderildiği canlı bölgeden duyurulur ve odak sonuca taşınabilir.
- Hatalı — hata metni canlı bölgeden duyurulur, hatalı alan işaretlenir, ve odak ilk hatalı alana taşınır.
Son maddedeki odak taşıma, kullanıcıyı doğrudan düzeltmesi gereken yere götürür ve uzun formlarda büyük fark yaratır. On alanlı bir formda «bir alan hatalı» mesajını duyup hangisi olduğunu bulmak için baştan Tab'lamak, gereksiz bir yük.
Bir de fail-open ilkesi var ve bu, erişilebilirlikten çok güvenilirlikle ilgili: form gönderimi teknik bir sebeple başarısız olursa, kullanıcı çıkmaza düşmemelidir. Bu sitede sunucu yanıt vermezse akış e-posta bağlantısına devrediyor — yani kanal hiçbir durumda tamamen kapanmıyor. Tek dönüşüm yolu olan bir formda bu, erişilebilirlik kadar önemlidir.
Hata metni nasıl yazılır
Ölçütlerin teknik tarafı çözüldükten sonra geriye bir yazı işi kalır ve o iş çoğu zaman en çok fark yaratandır. 3.3.3 «Hata Önerisi» yalnız hatanın bildirilmesini değil, mümkünse nasıl düzeltileceğinin söylenmesini ister — ve bu, bir mesajı işe yarar kılan şeydir.
Kötü hata mesajları birbirine benzer: «Geçersiz giriş», «Hata oluştu», «Lütfen tekrar deneyin». Hiçbiri kullanıcıya ne yapacağını söylemez. İyi mesaj üç şeyi taşır — hangi alan, ne yanlış, ne yapılmalı. «Telefon numarası 10 haneli olmalı, başında sıfır olmadan girin» cümlesi üçünü de karşılar ve kullanıcıyı tahmin etmek zorunda bırakmaz.
- Alanı adıyla an — «Bu alan» değil, «E-posta adresi». Ekran okuyucu kullanıcısı mesajı bağlamdan kopuk duyabilir.
- Ne beklendiğini söyle — biçim, uzunluk, izin verilen karakterler. Örnek vermek tarif etmekten iyidir.
- Suçlayıcı dilden kaçın — «Yanlış girdiniz» yerine «Bu biçim tanınmadı». Hata kullanıcının değil, formun beklentisinin sonucudur.
- Teknik terim kullanma — «Doğrulama başarısız» kullanıcıya hiçbir şey anlatmaz.
- Kaç hata olduğunu söyle — formun başında özet varsa, «3 alan düzeltilmeli» demek kullanıcıya kapsamı verir.
Bir de zamanlama meselesi var. Kullanıcı henüz yazarken hata göstermek — her tuş vuruşunda doğrulama yapmak — hem sinir bozucudur hem ekran okuyucu için gürültü üretir, çünkü canlı bölge sürekli konuşur. Doğru zaman genellikle alandan çıkıldığı andır; gönderim anında ise tüm hatalar birlikte toplanır.
Son olarak: en iyi hata mesajı hiç oluşmayan hata mesajıdır. Beklenen biçim alanın altında baştan yazılıysa, tarih için takvim seçici sunuluyorsa, telefon alanı otomatik biçimlendiriyorsa — hata oranı düşer. Erişilebilirlik burada kullanılabilirlikle tamamen örtüşür; iyi bir form her iki başlıkta da aynı şeyleri yapar.