Form Hata Mesajları Nasıl Yazılır? Kullanıcıyı Kaybetmeyen Uyarı Örnekleri

Bu rehberde form hata mesajları konusunu baştan sona ele alıyoruz: mesajın yeri, zamanlaması, dili, erişilebilirlik gereksinimleri ve yayından önce kontrol etmeniz gereken maddeler. Formun genel kurgusu, alan sayısı ve buton tasarımı gibi konular için form tasarımında dönüşümü artıran ve azaltan unsurlar yazımıza bakabilirsiniz. Burada yalnız tek bir ana odaklanıyoruz: bir şey ters gittiğinde ekranda ne yazdığınız.

Talha Aslan ve ekibi olarak 2012'den beri kurumsal sitelerde, teklif formlarında ve e-ticaret ödeme adımlarında aynı tabloyu görüyoruz. Ziyaretçi çoğu zaman formu doldurmak ister; onu vazgeçiren şey çoğunlukla hatanın kendisi değil, hatanın anlatılma biçimidir. Bu yüzden mesaj metnini tasarımın bir parçası olarak ele alıyoruz.

İyi bir hata mesajı hangi üç soruyu yanıtlar?

Her hata mesajı kullanıcının kafasındaki üç soruya cevap vermelidir. Birincisi, sorun nerede? İkincisi, sorun tam olarak ne? Üçüncüsü, ne yaparsam düzelir? Bu üç sorudan birini atlayan mesaj, kullanıcıyı tahmin yürütmeye zorlar. Tahmin ise zaman ve sabır harcar.

• Konum: Mesaj, ait olduğu alanın yanında durur ve alan adını anar.
• Neden: "Geçersiz giriş" yerine sorunu adlandırır, örneğin "E-posta adresinde @ işareti yok".
• Çözüm: Doğru biçimi gösterir, örneğin "ad@example.com biçiminde yazın".

Örneğin bir telefon alanında yalnızca "Hatalı" yazdığınızı düşünün. Kullanıcı ülke kodunu mu eklemeli, boşlukları mı silmeli, yoksa numara eksik mi? Oysa "Telefon numarası 10 haneli olmalı, başında 0 olmadan yazın" cümlesi üç soruyu birden yanıtlar. Üstelik kullanıcı ikinci denemede genellikle doğru girdiyi verir.

Bu yapı, metin yazımının genel ilkeleriyle de uyumludur. Arayüzdeki kısa metinleri nasıl kurguladığımızı UX writing rehberimizde ayrıntılı anlattık; hata mesajı bu disiplinin en çok test edilen parçasıdır.

WCAG form hata mesajları için ne ister?

Web İçeriği Erişilebilirlik Yönergeleri (WCAG), W3C'nin yayımladığı uluslararası erişilebilirlik standardıdır. Hata mesajlarıyla doğrudan ilgili iki başarı ölçütü vardır. Bunlar hem yasal uyumluluk hem de iyi kullanıcı deneyimi için temel çerçeveyi verir.

WCAG 3.3.1 Hata Tanımlama (A düzeyi), bir girdi hatası otomatik olarak algılandığında hatalı öğenin belirtilmesini ve hatanın kullanıcıya metinle anlatılmasını ister. W3C'nin açıklamasına göre, gönderim başarısız olduktan sonra formu hiçbir mesaj olmadan yeniden göstermek bu ölçütü karşılamaz. Renk veya ikon eklenebilir; ancak metin şarttır.

WCAG 3.3.3 Hata Önerisi (AA düzeyi) bir adım ileri gider. Sistem hatayı algılıyor ve nasıl düzeltileceğini biliyorsa, kullanıcıya düzeltme önerisi sunmalısınız. Tek istisna, önerinin güvenliği veya içeriğin amacını tehlikeye atmasıdır. Örneğin şifre girişinde "doğru şifre şuydu" demezsiniz.

Kısacası 3.3.1 "ne yanlış" sorusunu, 3.3.3 ise "nasıl düzelir" sorusunu karşılar. Erişilebilirlik standartlarının bütün resmi için web erişilebilirliği ve WCAG standartları yazımıza göz atabilirsiniz.

Hata mesajı ekranda nerede durmalı?

En güvenli konum, hatalı alanın hemen altı ya da üstüdür. Nielsen Norman Group'un formlarda hata raporlama yönergeleri de mesajı alanın yanında tutmayı önerir; çünkü kullanıcı mesajı okuduktan sonra onu aklında tutmak zorunda kalmaz. Gözü zaten düzeltmesi gereken yerdedir.

Öte yandan yalnızca formun en üstünde toplu bir uyarı göstermek, özellikle uzun formlarda kullanıcıyı ileri geri kaydırmaya zorlar. Benzer biçimde yalnız bir ünlem ikonu koyup mesajı ipucu balonuna (tooltip) saklamak da sorunludur. Bu ikonlar kolayca gözden kaçar ve mesajı görmek için fazladan bir hareket gerekir.

• Mesajı alanın altına, etiketle aynı hizaya yerleştirin.
• Mesaj göründüğünde sayfa düzeni zıplamasın; alan için önceden boşluk ayırın.
• Birden fazla hata varsa her biri kendi alanının yanında görünsün.
• Mesaj ile alan arasında görsel bağ kurun: aynı kutu, aynı ikon, yakın mesafe.

Yerleşim kararını verirken mobil ekranı da düşünün. Dar ekranda alanın sağına yazılan mesaj kayar ya da yarım kalır; bu nedenle altta durması neredeyse her zaman daha sağlam bir seçimdir.

Satır içi doğrulama ne zaman tetiklenmeli?

Satır içi doğrulama (inline validation), kullanıcı formu göndermeden önce her alanı ayrı ayrı kontrol edip geri bildirim vermektir. Doğru zamanlandığında büyük kolaylık sağlar; yanlış zamanlandığında ise kullanıcıyı daha yazmayı bitirmeden azarlayan bir arayüze dönüşür.

Pratik kural basittir: alan terk edildiğinde kontrol edin. web.dev'in form doğrulama rehberi de kullanıcı alandan çıktığında (blur olayı) doğrulama yapmayı örnekler. NN/g ise girdi tamamlanmadan hata göstermemeyi açıkça önerir. Yani e-posta adresinin ilk üç harfini yazan kişiye "geçersiz e-posta" demek yanlıştır.

Bununla birlikte bir istisna vardır. Kullanıcı hatalı bir alanı düzeltmeye başladığında, mesajı yazarken kaldırmak iyi bir deneyimdir. Böylece kişi düzelttiğini anında görür. Kısacası hatayı geç gösterin, düzeldiğini erken onaylayın.

Ayrıca CSS tarafında da aynı mantık geçerlidir. web.dev, :invalid seçicisinin kullanıcı hiçbir şey yapmadan önce de devreye girdiğini, bunun kafa karıştırabileceğini belirtir ve yalnız etkileşimden sonra çalışan :user-invalid seçicisini önerir. Boş bir formu ilk anda kırmızıya boyamak, ziyaretçiye daha başlamadan hata yaptığını söylemek demektir.

Neden yalnız renkle hata göstermek yetmez?

Kırmızı çerçeve, hata için tanıdık bir işarettir; ancak tek başına yeterli değildir. WCAG 1.4.1 Renk Kullanımı ölçütü, bilginin yalnız renkle aktarılmamasını ister. W3C, zorunlu ya da hatalı alanları sadece renk farkıyla belirtmeyi bu ölçütün başarısızlık örnekleri arasında sayar.

Renk körlüğü olan bir kullanıcı kırmızı çerçeveyi gri bir çizgiden ayıramayabilir. Güneş altında telefon ekranına bakan biri de aynı sorunu yaşar. Bu yüzden renk dışı en az bir işaret ekleyin:

• Hatayı anlatan görünür metin (zorunlu).
• Ünlem veya uyarı ikonu.
• Alan çerçevesinin kalınlaşması ya da biçim değiştirmesi.
• Mesajın başında "Hata:" gibi bir önek.

Renk kullanırken kontrastı da kontrol edin. Açık pembe zemin üzerindeki açık kırmızı yazıyı kimse rahat okuyamaz. Metin ile arka plan arasındaki oranı renk kontrast kontrolü aracımızla birkaç saniyede ölçebilirsiniz. Böylece mesaj hem renk algısı farklı olan kişilere hem de herkese net biçimde ulaşır.

Ekran okuyucu kullanıcıları hatayı nasıl duyar?

Görsel olarak mükemmel duran bir hata mesajı, ekran okuyucu kullanan biri için hiç var olmayabilir. Bu nedenle mesajın programatik olarak alana bağlanması gerekir. Burada üç temel araç kullanırsınız.

1. aria-invalid: Doğrulamadan geçemeyen alana "true" değeri verirsiniz. MDN, boş zorunlu alanlarda bu değeri kullanıcı formu göndermeye çalışmadan önce ayarlamamayı önerir; çünkü kişi hâlâ doldurmaya devam ediyor olabilir.
2. aria-describedby veya aria-errormessage: Hata metnini alana bağlar, böylece alan odaklandığında mesaj da okunur.
3. Canlı bölge (live region): Gönderim sonrası oluşan hata özetini ekran okuyucunun anında duyurmasını sağlar.

Ayrıca alan düzeldiğinde aria-invalid değerini "false" yapmayı unutmayın. Aksi halde ekran okuyucu düzelttiğiniz alanı hâlâ hatalı diye okur. Bu küçük senkron hatası, sahada en sık gördüğümüz erişilebilirlik kusurlarından biridir.

Odak yönetimi de önemlidir. Gönderim başarısız olduğunda odağı ya hata özetine ya da ilk hatalı alana taşıyın. Böylece klavye kullanıcısı sayfanın neresinde olduğunu kaybetmez.

Formun üstündeki hata özeti ne işe yarar?

Hata özeti, gönderim başarısız olduğunda formun en üstünde tüm hataları listeleyen kutudur. Uzun formlarda kullanıcıya genel bir resim verir: kaç sorun var ve nerelerde? Ancak tek başına yeterli değildir; NN/g de yalnız özete güvenmemeyi, her hatayı kendi alanında da göstermeyi önerir.

İyi bir özet şu özellikleri taşır. Önce kaç hata olduğunu söyler, örneğin "Formda 2 alanı düzeltmeniz gerekiyor". Ardından her maddeyi ilgili alana giden bir bağlantı olarak listeler. Böylece kullanıcı tıklayınca doğrudan o alana gider. WCAG teknikleri arasında da hatalı alana atlamayı sağlayan bu yaklaşım yer alır.

Kısa formlarda, örneğin yalnız ad ve e-posta isteyen bir bülten kutusunda, özet gereksiz kalabalık yaratır. Dolayısıyla özeti alan sayısı beş-altıyı geçen formlarda ve çok adımlı süreçlerde kullanmanızı öneririz.

Form hata mesajları için iyi ve kötü örnekler nelerdir?

Aşağıdaki tablo, sahada en sık karşılaştığımız zayıf mesajları ve yerlerine yazabileceğiniz daha iyi örnekleri gösteriyor. Örnekler genel kalıplardır; kendi alan adlarınıza ve kurallarınıza göre uyarlayın.

Tablodaki sayısal kurallar (8 karakter, 5 MB gibi) yalnızca örnek senaryodur. Siz kendi sisteminizin gerçek sınırını yazın; mesajdaki kural ile sunucudaki kural birbirini tutmazsa kullanıcı doğru girdiği halde hata alır.

Kullanıcıyı suçlamadan nasıl yazarsınız?

Ton, hata mesajının görünmeyen yarısıdır. "Yanlış girdiniz", "Hatalı işlem yaptınız" gibi cümleler sorunu kullanıcının üstüne yıkar. Oysa çoğu zaman sorun, kuralı önceden açıklamayan formdadır. Bu nedenle cümleyi kişiye değil, duruma odaklayın.

• "Yanlış telefon girdiniz" yerine "Telefon numarası 10 haneli olmalı" yazın.
• Büyük harf ve ünlem kullanmayın; "HATA!" bağırır, yardım etmez.
• Teknik terimleri çıkarın: "regex eşleşmedi" kullanıcıya hiçbir şey anlatmaz.
• Kısa tutun; bir veya iki cümle çoğu durum için yeterlidir.
• Espri yapmayın; sinirli bir kullanıcı için şakalar genellikle ters teper.

Öte yandan aşırı özür dilemek de gereksizdir. "Çok üzgünüz, maalesef..." ile başlayan uzun bir mesaj çözümü geciktirir. Nazik ama doğrudan bir dil en iyi sonucu verir. Yani bir yardım masası görevlisinin tek cümlede söyleyeceği şeyi yazın.

Son olarak dil tutarlılığına dikkat edin. Bir alanda "siz", diğerinde "sen" diye hitap eden form güven kaybettirir. Hata mesajlarını tek bir metin rehberine bağlayın ve sitedeki tüm formlarda aynı kalıpları kullanın.

Alan türüne göre hangi mesaj kalıplarını kullanabilirsiniz?

Her alan türünün kendine özgü hata nedenleri vardır. Aşağıdaki kalıpları başlangıç noktası olarak kullanabilir, sonra kendi kurallarınıza göre düzenleyebilirsiniz.

• E-posta: Eksik @ işareti, eksik alan adı veya boşluk. Mesajda örnek biçimi gösterin.
• Telefon: Hane sayısı ve ülke kodu. Mümkünse boşluk ve tireleri sistem kendisi temizlesin.
• Tarih: Geçmiş tarih, kapalı gün veya biçim. Takvim seçici kullanıyorsanız seçilemeyen günleri baştan pasif yapın.
• Şifre: Kuralları alanın altında baştan listeleyin ve karşılanan her kuralı işaretleyin.
• Dosya: Boyut sınırı ve kabul edilen türler. Bunları yükleme düğmesinin yanında önceden yazın.
• Kimlik veya vergi numarası: Hane sayısını söyleyin; ancak kontrol algoritmasının ayrıntısını anlatmayın.

NN/g, karmaşık alanlarda başarılı girişi de onaylamayı önerir; şifre gücü göstergesi veya kullanıcı adı uygunluk işareti buna örnektir. Ancak ad soyad gibi basit alanlarda her harfe yeşil tik koymak gereksiz görsel gürültü yaratır.

Örneğin bir randevu formunda tarih alanı en çok hata üreten alandır. Randevu, teklif ve demo formlarının genel kurgusunu randevu, teklif ve demo formu tasarımı yazımızda anlattık.

Sunucu ve sistem hataları nasıl anlatılmalı?

Bazı hataların kaynağı kullanıcının girdisi değil, sistemin kendisidir: bağlantı kopması, oturum süresinin dolması, ödeme sağlayıcısının yanıt vermemesi ya da sunucu hatası. Bu durumlarda kullanıcı hiçbir şeyi yanlış yapmamıştır; dolayısıyla mesajın bunu açıkça belli etmesi gerekir.

İyi bir sistem hatası mesajı üç şey söyler. Ne oldu, girdiğim bilgiler kayboldu mu ve şimdi ne yapabilirim? Örneğin "Bağlantı koptu. Bilgileriniz bu sayfada duruyor; internet bağlantınızı kontrol edip yeniden gönderin." Bu cümle hem paniği önler hem de yolu gösterir.

Ayrıca alternatif bir iletişim kanalı sunun. Form üst üste başarısız oluyorsa kullanıcıya telefon numarası veya e-posta adresi gösterin. Böylece bir teknik sorun yüzünden potansiyel bir müşteriyi tamamen kaybetmezsiniz.

Hata kodlarını tamamen gizlemek zorunda değilsiniz. Destek ekibinin sorunu bulmasını kolaylaştırmak için mesajın altına küçük puntoyla bir referans kodu ekleyebilirsiniz. Ancak ana cümle her zaman insan dilinde olmalıdır.

Hata sonrası kullanıcının girdisi neden korunmalı?

Kullanıcıyı kaybetmenin en hızlı yolu, tek bir hata yüzünden tüm formu boşaltmaktır. On alanı dolduran biri, gönderimden sonra her şeyin silindiğini görünce büyük ihtimalle sekmeyi kapatır. Bu nedenle sayfa yeniden yüklense bile girilen değerleri alanlarda tutun.

Bununla birlikte güvenlik gereği temizlenmesi gereken alanlar vardır. Şifre ve kart doğrulama kodu gibi hassas bilgileri yeniden doldurmazsınız. Bu durumda kullanıcıya neden yeniden girmesi gerektiğini kısaca söyleyin: "Güvenliğiniz için şifrenizi yeniden yazın."

Hatalı değeri de silmeyin. Kullanıcı neyi yanlış yazdığını görürse daha hızlı düzeltir. Örneğin "ali@gmial.com" alanda kalırsa kişi yazım hatasını hemen fark eder. Değeri silip "geçersiz e-posta" demek ise onu sıfırdan başlatır.

Çok adımlı formlarda bu kural daha da kritiktir. Kullanıcı geri düğmesine bastığında önceki adımın verileri kaybolmamalı. Ekip olarak kurduğumuz formlarda adımlar arası geçişte verinin korunup korunmadığını mutlaka test ederiz.

Hataları baştan önlemek için ne yapabilirsiniz?

En iyi hata mesajı, hiç gösterilmeyen mesajdır. Kuralı hatadan sonra değil önce anlatırsanız hata sayısı doğal olarak düşer. web.dev de doğrulama kurallarını kullanıcı hata yapmadan önce bildirmeyi ve açıklamayı aria-describedby ile alana bağlamayı önerir.

• Görünür etiket: Yer tutucu metni (placeholder) etiket yerine kullanmayın; kullanıcı yazmaya başlayınca kaybolur.
• Biçim ipucu: "GG.AA.YYYY" veya "05XX XXX XX XX" gibi örnekleri alanın altında gösterin.
• Doğru alan türü: E-posta, telefon ve sayı için uygun girdi türünü seçin; mobilde doğru klavye açılır.
• Toleranslı girdi: Boşluk, tire veya parantezleri sistem kendisi temizlesin, kullanıcıyı bunlar için uyarmayın.
• Az alan: İhtiyacınız olmayan bilgiyi istemeyin.

Son madde aslında en etkili olanıdır. Her ek alan yeni bir hata ihtimali demektir. Alan sayısının kullanıcının zihnine bindirdiği yükü bilişsel yük ve form alan sayısı yazımızda ele aldık.

Ayrıca tarayıcının yerleşik doğrulamasını temel olarak kullanabilirsiniz. Ancak W3C, yerleşik mesajların genel kalabileceğini, kaybolabileceğini ve yakınlaştırmayla ölçeklenmeyebileceğini hatırlatır. Bu nedenle mesaj metnini kendiniz yazmanızı öneririz.

Mobilde form hata mesajları nasıl görünmeli?

Mobilde ekran dar, klavye ekranın yarısını kaplar. Dolayısıyla masaüstünde iyi görünen bir mesaj telefonda klavyenin altında kalabilir. Mobil form hata mesajları için ilk kural, mesajı hatalı alanın hemen altına yazmak ve alan odaklandığında sayfanın onu ekranın içine kaydırmasını sağlamaktır.

Gönderim sonrası hata oluştuğunda kullanıcıyı ilk hatalı alana taşıyın. Aksi halde kişi düğmeye basar, hiçbir şey olmadığını sanır ve aynı düğmeye tekrar tekrar basar. Ekranın en üstündeki bir özeti, aşağıda düğmeye basan kullanıcı hiç fark etmez.

• Mesaj yazı boyutunu rahat okunacak düzeyde seçin, çok küçük puntodan kaçının.
• Mesaj ile bir sonraki alan arasında yeterli boşluk bırakın.
• Modal pencereyle hata göstermeyin; mobilde kapatması zordur.
• Gönder düğmesini hata varken pasif yapacaksanız nedenini görünür metinle yazın.

Örnek senaryo: bir hizmet firmasının teklif formunu telefonda dolduran kullanıcı, ilçe alanını boş bırakıyor. Hata mesajı sayfanın tepesinde çıkıyor, kullanıcı ise en alttaki düğmenin başında. Kişi formu bozuk sanıp çıkıyor. Mesajı alanın altına taşımak ve odağı oraya kaydırmak bu kaybı önler.

Tekrarlayan hatalar size ne anlatır?

Bir kullanıcı aynı alanda üst üste hata alıyorsa sorun büyük ihtimalle kullanıcıda değil, tasarımdadır. NN/g, aynı denemede üç veya daha fazla tekrarlanan hatayı bir tasarım sorununun işareti olarak görür ve ek yardım sunmayı önerir.

Ek yardım farklı biçimler alabilir. İkinci hatadan sonra daha ayrıntılı bir açıklama gösterebilir, örnek bir değer önerebilir ya da destek iletişim bilgisini görünür yapabilirsiniz. Örneğin vergi numarası alanında ikinci hatadan sonra "Şahıs şirketiyseniz T.C. kimlik numaranızı da yazabilirsiniz" gibi bir not, kullanıcının gerçek sorununu çözebilir.

Bununla birlikte asıl çözüm kalıcı olmalıdır. Hangi alanın sık hata ürettiğini tespit edin, sonra kuralı mı, etiketi mi yoksa ipucunu mu değiştirmeniz gerektiğine karar verin. Kısacası tekrarlayan hata bir veri kaynağıdır; onu görmezden gelmek yerine formu iyileştirmek için kullanın.

Form hata mesajları nasıl test edilir ve ölçülür?

Bir formun hata mesajlarını ancak test ettikten sonra gerçekten iyi diye değerlendirebilirsiniz. Yayından önce her alanı kasıtlı olarak yanlış doldurun: boş bırakın, yanlış biçim girin, sınırı aşın. Her durumda bir mesaj çıkıyor mu ve bu mesaj üç soruyu yanıtlıyor mu, kontrol edin.

1. Yalnız klavye ile formu doldurun ve hataya kadar gidin; odak nereye gidiyor?
2. Bir ekran okuyucuyla aynı akışı deneyin; mesaj okunuyor mu?
3. Ekranı gri tonlamaya alın; hatalı alanı hâlâ ayırt edebiliyor musunuz?
4. Sayfayı yüzde 200 yakınlaştırın; mesaj kesiliyor mu?
5. Telefonda klavye açıkken hatayı tetikleyin; mesaj görünüyor mu?

Yayından sonra ise davranış verisine bakın. Hangi alanda kullanıcıların takıldığını oturum kayıtları ve ısı haritalarıyla görebilirsiniz. Bunun nasıl kurulduğunu Microsoft Clarity rehberimizde anlattık. Ayrıca doğrulama hatalarını analitik aracınıza ayrı bir olay olarak göndermek, en sorunlu alanı sayıyla görmenizi sağlar.

Formun başarıyla gönderildiği anı da unutmayın. Hata kadar başarı geri bildirimi de önemlidir; bunun için form sonrası teşekkür sayfası rehberimize bakabilirsiniz.

Yayın öncesi kontrol listesi neleri kapsamalı?

Aşağıdaki listeyi her yeni formda ve her form güncellemesinde kullanabilirsiniz. Ekip olarak teslimden önce bu maddelerin tamamını tek tek işaretliyoruz.

1. Her doğrulama kuralının görünür bir hata metni var.
2. Mesaj hatalı alanın yanında ve alan adını anıyor.
3. Mesaj sorunu adlandırıyor ve çözüm öneriyor (WCAG 3.3.1 ve 3.3.3).
4. Hatayı yalnız renk değil, metin ve ikon da gösteriyor (WCAG 1.4.1).
5. Mesaj metni ile arka plan arasındaki kontrast yeterli.
6. Doğrulama alan terk edildiğinde çalışıyor, yazarken değil.
7. Düzeltilen alanda hata mesajı ve aria-invalid durumu kalkıyor.
8. Gönderim sonrası odak ilk hataya veya özete gidiyor.
9. Kullanıcının girdisi, hassas alanlar hariç, korunuyor.
10. Sunucu hatalarında insan diliyle mesaj ve alternatif iletişim yolu var.
11. Mesajdaki kurallar ile sunucudaki kurallar birebir aynı.
12. Mobilde mesaj klavyenin altında kalmıyor.
13. Tüm formlarda hitap ve ton tutarlı.

Bu listeyi geçen bir form, kullanıcıyı hatada bırakmaz; her hatadan sonra bir sonraki adımı gösterir.

Çok dilli sitelerde hata mesajları nasıl yönetilir?

Siteniz birden fazla dilde yayındaysa hata mesajlarını da her dilde ayrı ayrı yazmanız gerekir. Makine çevirisiyle üretilen mesajlar çoğu zaman anlamı korur ama tonu bozar. Örneğin Türkçede nazik duran bir cümle, Almancada fazla resmi ya da İngilizcede gereksiz uzun kalabilir.

Bu yüzden mesajları tek bir metin dosyasında, her dil için ayrı anahtarlarla tutmanızı öneririz. Böylece bir kuralı değiştirdiğinizde tüm dillerdeki mesajı birlikte güncellersiniz. Ayrıca tarih, telefon ve posta kodu biçimleri ülkeye göre değişir; dolayısıyla biçim ipucunu da dile ve ülkeye göre uyarlayın.

Son olarak tarayıcının varsayılan mesajlarına dikkat edin. Kullanıcının tarayıcı dili ile sitenizin dili farklıysa, aynı sayfada iki ayrı dilde uyarı görebilir. Kendi mesajlarınızı yazmak bu karışıklığı da ortadan kaldırır.

Hangi hataları en sık görüyoruz?

Kurumsal sitelerin formlarını incelerken bazı kusurlar sürekli karşımıza çıkıyor. Bunları bilmek, kendi formunuzu hızlıca değerlendirmenize yardımcı olur.

• Tüm alanlar için tek bir genel mesaj: "Lütfen formu kontrol edin."
• Formun daha ilk saniyede kırmızı çerçevelerle dolması.
• Gönderim sonrası tüm alanların boşalması.
• Yalnız tarayıcının varsayılan balonlarına güvenmek; bu balonlar tarayıcıya ve dile göre değişir.
• Ön yüzde kabul edilen ama sunucuda reddedilen değerler.
• İngilizce kalmış sistem mesajları, Türkçe bir sitede.

Bu kusurların çoğunu birkaç satırlık düzeltmeyle giderebilirsiniz. Ancak bazen sorun formun altyapısındadır; örneğin kullanılan form eklentisi mesajları özelleştirmeye izin vermez. Böyle durumlarda formu yeniden kurmak, sürekli yamamaktan daha ucuza gelir.

Form hata mesajlarını sitenizde kim kurar?

Form hata mesajları küçük bir ayrıntı gibi görünse de tasarım, metin, erişilebilirlik ve yazılımın kesiştiği bir noktadır. Mesaj metnini yazmak kolaydır; onu doğru zamanda, doğru yerde, ekran okuyucuya bağlı ve sunucu kurallarıyla uyumlu çalıştırmak ise ekip işidir.

Talha Aslan ve ekibi olarak web tasarım hizmetimizde formları yalnız görsel olarak değil, hata durumlarıyla birlikte kurarız. Her alan için kural, ipucu ve hata metnini birlikte yazar, mobilde ve klavyeyle test ederiz. Mevcut sitenizdeki formların hatalı akışlarını da aynı kontrol listesiyle inceleriz.

Sitenizdeki teklif, iletişim veya ödeme formunun ziyaretçi kaybettirdiğini düşünüyorsanız, kapsamı ve süreyi netleştiren bir teklif için web tasarım sayfamızdan bize ulaşabilirsiniz. Böylece formunuzu tahmine değil, sınadığınız kurallara dayandırırsınız.