Web formunda erişilebilir hata mesajı nasıl yazılır?

Web formunda erişilebilir hata mesajı, hatalı alanı metinle tanımlamalı, sorunun nedenini açıklamalı ve mümkünse düzeltme yolunu göstermelidir.

WCAG 2.2, otomatik tespit edilen giriş hatalarının yalnızca kırmızı kenarlık veya ikonla anlatılmasını yeterli görmez. Hata, kullanıcıya metin olarak sunulmalı ve ilgili form alanıyla programatik biçimde ilişkilendirilmelidir.

Erişilebilir form hata mesajı neyi açıkça söylemelidir?

Erişilebilir form hata mesajı, hangi alanın hatalı olduğunu, hatanın neden oluştuğunu ve kullanıcının ne yapacağını açıkça söylemelidir. Sadece Hata oluştu veya Bilgileri kontrol edin gibi ifadeler yeterli değildir.

WCAG 2.2’deki 3.3.1 Hata Tanımlama başarı kriteri, otomatik tespit edilen giriş hatalarının metinle tanımlanmasını ister. Bu nedenle kırmızı kenarlık, ünlem ikonu veya renk değişimi tek başına kullanılamaz. Alanın yanında E-posta adresi geçersiz. example.com biçiminde yazın mesajı bulunmalıdır.

Mesajın alanla ilişkisi de önemlidir. Kullanıcı ekranı büyüttüğünde, klavyeyle ilerlediğinde veya ekran okuyucu kullandığında hatanın hangi girişe ait olduğunu anlamalıdır. Bu ilişkiyi yalnızca görsel yakınlıkla kurmak, özellikle mobil ve yardımcı teknolojilerde güvenilir değildir.

Renk kullanımı tamamen kaldırılmak zorunda değildir. Renk, hızlı görsel taramayı destekleyen ikincil bir işaret olabilir. Ancak metin, ikon ve alan adı olmadan anlam taşımamalıdır. Renk seçiminin okunabilirliğini değerlendirmek için erişilebilirlikte renk kontrastı nasıl ölçülür rehberindeki yöntemi uygulayabilirsiniz.

Hata mesajı form alanıyla nasıl ilişkilendirilir?

Hata mesajı, ilgili form alanının programatik açıklaması olarak bağlanmalıdır. Bunun pratik karşılığı, hata metnine benzersiz bir id vermek ve input üzerinde aria-describedby niteliğini kullanmaktır.

Örneğin e-posta alanının id değeri email ise hata metni email-error id’sini taşıyabilir. Input öğesinde aria-describedby='email-error' bulunur. Böylece ekran okuyucu, alan odaklandığında hata açıklamasını da okuyabilir.

Hatalı alan için aria-invalid='true' kullanılması, alanın geçersiz durumunu yardımcı teknolojilere bildirir. Bu nitelik, hata mesajının yerine geçmez. aria-invalid yalnız başına kullanıldığında kullanıcı hatanın ne olduğunu veya nasıl düzelteceğini öğrenemez.

Mesajı alanın hemen sonrasında göstermek görsel taramayı kolaylaştırır. Uzun formlarda ayrıca bir hata özeti kullanılabilir. Özet içindeki bağlantılar, kullanıcının doğrudan ilgili alana gitmesini sağlamalıdır. Aynı hata metnini hem özet hem alan altında tekrarlıyorsanız, tekrarın ekran okuyucuda gereksiz çoğalmadığını test edin.

Bir hata sadece genel sayfa üstünde gösterilirse ilişki zayıflar. Kullanıcı, Üyelik bilgileri eksik mesajının ad, telefon veya parola alanından hangisine ait olduğunu tahmin etmek zorunda kalır. Alan adı ve hata nedeni birlikte yazılmalıdır.

Hata metni kullanıcıya ne söylemelidir?

İyi hata metni, kullanıcıyı suçlamadan belirli bir problemi ve uygulanabilir çözümü ifade eder. Kısa cümle kullanın; teknik doğrulama kodlarını, veritabanı terimlerini veya geliştirici notlarını kullanıcıya göstermeyin.

Yanlış: Geçersiz giriş. Doğru: Telefon numarasını 05XX XXX XX XX biçiminde yazın. İlk ifade sorunu belirsiz bırakır. İkinci ifade alanı tanımlar, beklenen biçimi verir ve düzeltme için doğrudan yol gösterir.

Mesajda beklenen koşulu mümkün olduğunca baştan belirtmek hatayı azaltır. Şifre alanında En az 8 karakter, bir büyük harf ve bir rakam kullanın gibi bir açıklama, kullanıcının deneme yapmadan doğru veriyi girmesine yardımcı olur. Ancak bu koşullar gerçekten sistem tarafından uygulanıyorsa yazılmalıdır.

Hata metni için üç parçalı bir kalıp kullanılabilir: alan adı, sorun ve çözüm. E-posta adresi alanında e-posta adresi, @ işareti içermiyor ve adresi [email protected] biçiminde yazın şeklinde kurulabilir. Gereksiz özür, ünlem ve belirsiz ifadeler mesajı uzatır.

Sunucu tarafında oluşan hatalarda nedeni güvenli biçimde açıklayın. Ödeme başarısız oldu demek yerine Kart bilgileri doğrulanamadı. Kart numarasını ve son kullanma tarihini kontrol edin yazılabilir. Kartın neden reddedildiği bilinmiyorsa banka reddetti gibi kesin bir iddia kurmayın.

Düzeltme önerisi hangi form hatalarında verilmelidir?

Düzeltme önerisi, sistem hatanın nedenini güvenilir biçimde bildiğinde ve öneri kullanıcıyı doğru sonuca götürdüğünde verilmelidir. WCAG 2.2’nin 3.3.3 başarı kriteri, bilinen ve makul önerilerin sunulmasını bekler.

Biçim hatalarında öneri vermek genellikle kolaydır. Tarih alanında Geçerli bir tarih girin demek yerine Tarihi GG.AA.YYYY biçiminde yazın denebilir. Telefon numarası için beklenen ülke kodunu veya karakter düzenini açıklamak da aynı kapsamdadır.

Öneri her zaman otomatik düzeltme anlamına gelmez. Kullanıcının yazdığı e-posta adresini sistemin izinsiz değiştirmesi, özellikle isim ve alan adı içeren adreslerde yeni hata üretebilir. Öneri sunun; otomatik değişiklik yapacaksanız kullanıcıya sonucu açıkça gösterin.

Önerinin işe yaramadığı durumlarda mesajı genelleştirmeyin. Örneğin ödeme sağlayıcısı yalnızca işlem reddedildi bilgisi veriyorsa, Kart numarası yanlıştır demek doğru değildir. Kart bilgilerini veya farklı ödeme yöntemini kontrol edin gibi doğrulanabilir seçenekler sunulabilir.

1. Hata nedenini sistemin gerçekten bilip bilmediğini belirleyin.
2. Bilinen nedene karşılık gelen en kısa çözüm önerisini yazın.
3. Önerinin güvenlik veya mahremiyet riski oluşturmadığını kontrol edin.
4. Öneriyi klavye, ekran okuyucu ve mobil ekranla test edin.
5. Başarısız denemelerde mesajın anlaşılır kalıp kalmadığını ölçün.

Form hatası ne zaman gösterilmeli ve odak nereye taşınmalı?

Hata mesajı, kullanıcının hatayı düzeltebileceği anda gösterilmelidir. Zamanlama, form türüne ve hatanın türüne göre değişir; her alanı kullanıcı yazarken sürekli uyarmak erişilebilir bir deneyim oluşturmaz.

Basit biçim hataları için alan odağını kaybettiğinde doğrulama yapılabilir. Ancak kullanıcı daha yazmayı bitirmeden her tuşta hata göstermek, ekran okuyucuda kesintili duyurular ve klavyede dikkat kaybı oluşturabilir. E-posta alanında eksik @ işaretini, kullanıcı yazmayı tamamlamadan duyurmak gereksizdir.

Gönderim sonrasında birden fazla hata varsa odağı genellikle hata özetine veya ilk hatalı alana taşıyabilirsiniz. Özet kullanıyorsanız başlığını programatik olarak belirginleştirin ve bağlantıların ilgili alanlara gitmesini sağlayın. Kullanıcıyı sayfanın başına göndermek, uzun checkout ekranlarında zaman kaybettirir.

Tek bir alan hatasında odağı doğrudan ilgili alana taşımak daha kısa bir yol olabilir. Yine de otomatik odak değişiklikleri beklenmedik olmamalıdır. Kullanıcı bir alanı düzelttikten sonra odağın başka bir bölüme sıçraması, özellikle klavye kullanıcılarının kontrolünü azaltır.

Dinamik hata duyuruları için role='alert' veya aria-live kullanılabilir. Bunları her küçük değişiklikte çalıştırmayın. Aynı mesajın iki kez okunması, eski mesajın yeni mesajı kesmesi veya duyurunun hiç anlaşılmaması, gerçek cihaz ve ekran okuyucuyla test edilmelidir.

HTML ve ARIA ile erişilebilir hata mesajı nasıl uygulanır?

Uygulama, doğru HTML etiketleriyle başlamalı ve ARIA’yı mevcut semantiği desteklemek için kullanmalıdır. Önce label, input, hata metni ve form gönderim akışını kurun; sonra gerekli durum niteliklerini ekleyin.

Aşağıdaki örnekte hata metni email alanına aria-describedby ile bağlanır. aria-invalid yalnızca alan geçersiz olduğunda eklenir. Başarılı durumda niteliği false olarak bırakmak veya kaldırmak, uygulamanın tutarlı durum yönetimine bağlıdır.

<label for='email'>E-posta adresi</label>
<input id='email' name='email' type='email' aria-invalid='true' aria-describedby='email-error' value='ali@'>
<p id='email-error'>E-posta adresini [email protected] biçiminde yazın.</p>

Hata metni sadece JavaScript ile görsel olarak ekleniyorsa, DOM’a gerçekten eklenip eklenmediğini kontrol edin. İçeriği CSS background-image, placeholder veya yalnızca title niteliğiyle sunmayın. Placeholder, label yerine geçmez ve kullanıcı yazmaya başladığında kaybolabilir.

Sunucu tarafı doğrulama da aynı HTML yapısını üretmelidir. JavaScript kapalı olduğunda veya istek sırasında beklenmeyen veri gönderildiğinde mesaj kaybolmamalıdır. Hata metninin benzersiz id değerleri, aynı sayfada yinelenen formlarda çakışmamalıdır.

Teklif, üyelik ve checkout formlarında hata akışı nasıl tasarlanır?

Teklif, üyelik ve checkout formlarında hata akışı, alanın riskine ve işlem maliyetine göre tasarlanmalıdır. Her form aynı doğrulama zamanını veya aynı hata özetini gerektirmez.

Teklif formunda ad, e-posta, telefon ve açıklama alanları bulunabilir. E-posta ve telefon biçim hataları alan altında gösterilir. Zorunlu açıklama eksikse mesaj, minimum beklenen içeriği açıklar. Kullanıcının yazdığı teklif metni hata sonrası silinmemelidir.

Üyelik formunda parola kuralları, benzersiz e-posta ve koşul onayı farklı hata türleridir. Parola koşullarını gönderimden sonra ilk kez göstermek yerine label sonrasında açıklama olarak sunmak daha anlaşılırdır. E-posta zaten kayıtlıysa, kullanıcıyı hesabına erişim seçeneklerine yönlendiren güvenli bir mesaj düşünülebilir.

Checkout ekranında hatalar adım bazında gruplanmalıdır. Teslimat adresi, fatura bilgisi ve ödeme alanları birbirine karıştırılmamalıdır. Stok veya fiyat değiştiyse bu durum form alanı hatası gibi gösterilmemeli; ürün satırında, kullanıcıya etkisini anlatan ayrı bir durum mesajı sunulmalıdır.

Erişilebilir form hata mesajı nasıl test edilir ve izlenir?

Erişilebilir hata mesajı, otomatik tarama, klavye kullanımı, ekran okuyucu ve gerçek form senaryolarıyla birlikte test edilmelidir. Tek bir araç, mesajın anlaşılır veya doğru zamanda duyurulduğunu kanıtlamaz.

Önce hata senaryolarını bir tabloya yazın. Boş bırakma, yanlış biçim, minimum uzunluk, eşleşmeyen alan, sunucu reddi ve bağlantı kesintisi ayrı satırlarda bulunmalıdır. Her satır için beklenen mesajı, mesajın id değerini ve odak davranışını tanımlayın.

Klavyeyle yalnızca Tab, Shift+Tab ve Enter kullanarak formu tamamlayın. Hata oluştuğunda mesajın görünür olup olmadığını, odağın nereye gittiğini ve hata düzeltildikten sonra durumun güncellendiğini kontrol edin. Hata alanına ulaşmak için fare zorunluysa akış tamamlanmış sayılmaz.

NVDA, VoiceOver veya kullanılan test ortamındaki başka bir ekran okuyucuyla alan adını, geçersiz durumunu ve hata açıklamasını dinleyin. Mesaj iki kez okunuyorsa, hiç okunmuyorsa veya yanlış alanla eşleşiyorsa aria-describedby ve canlı bölge kullanımını inceleyin.

• Hata yalnızca renkle mi gösteriliyor, yoksa metin de var mı?
• Mesaj hangi alanın hatalı olduğunu açıkça söylüyor mu?
• Hata metni ilgili alanla programatik olarak bağlı mı?
• aria-invalid durumu yalnızca geçersiz alanlarda mı kullanılıyor?
• Bilinen durumlarda düzeltme önerisi veriliyor mu?
• Form, klavyeyle baştan sona tamamlanabiliyor mu?
• Hata sonrası girilen diğer bilgiler korunuyor mu?
• Mobil ekranda mesaj alanı veya düğmeyi örtüyor mu?

Test sonuçlarını hata türü, cihaz, tarayıcı, ekran okuyucu ve tekrar üretme adımlarıyla kaydedin. Bu kayıt, yeni tasarım veya doğrulama kuralı eklendiğinde regresyon kontrolü sağlar. Erişilebilirlik kapsamını ayrıca web sitesine erişilebilirlik bildirimi nasıl eklenir içeriğinde açıklanan geri bildirim kanalıyla izleyebilirsiniz.

Form erişilebilirliği, yalnızca teknik bir kontrol listesi değildir. Bir teklif formunun yer aldığı landing page dönüşüm optimizasyonu çalışmasında hata sonrası tamamlanma oranını, terk edilen alanı ve tekrar gönderim sayısını ayrıca takip edin. Erişilebilirlik hedefleri için ilgili web sitesi erişilebilirlik zorunluluğu değerlendirmesini güncel mevzuat ve kurum kapsamıyla birlikte inceleyin.