ADA ve yardımcı hata önerileri

"Ne"den "nasıl"a: insanlara çıkış yolu vermek

Birine bir alanın yanlış olduğunu söylemek işin yarısıdır. WCAG 2.1, 3.3.3 başarı ölçütü (AA düzeyi), bir girdi hatası otomatik algılanırsa ve düzeltme önerileri biliniyorsa önerilerin kullanıcıya sunulmasını ister; ancak bu, içeriğin güvenliğini ya da amacını tehlikeye atıyorsa istisnadır.

Anahtar sözcük "biliniyorsa"dır. Site alanın beş hane istediğini ya da geçerli seçeneklerin yalnızca üç saat dilimi olduğunu biliyorsa bunu söylemelidir. Öneriler yazardan ya da kullanıcı aracısından gelebilir. Bilişsel engelli, az gören ve motor engeli olan kişilerin hatayı daha az denemeyle düzeltmesine yardım eder ve yarım bırakılan formları azaltır.

Ne zaman vazgeçilebilir?

• Öneri güvenliği zayıflatırsa; örneğin oturum açarken kullanıcı adı ile parolanın hangisinin yanlış olduğunu söylemek.
• Öneri içeriğin amacını boşa çıkarırsa; örneğin bir imlayı bilip bilmediğini ölçen sınav.
• Gerçekte hiçbir öneri bilinmiyorsa. Ölçüt sizden öneri uydurmanızı istemez.

ADA açısı: insanların tamamlamak zorunda olduğu formlardaki hatalar

Vatandaşlar kamu formlarını randevu almak, ödemek, başvurmak ve bildirmek için kullanır. Bir park rezervasyonunda ya da ruhsat yenilemede "Geçersiz giriş" mesajı onları tahmin etmeye geri gönderir. DOJ rehberi, belirsiz yönergeleri ve eksik hata uyarılarını formlardaki engeller arasında sayar; sorunun nasıl düzeltileceğini söyleyen bir mesaj açık yönerge vermenin bir yoludur. Küçük klavyelerin yeniden yazmayı pahalı kıldığı mobil uygulamalara da bakın.

Web kodu: posta kodları, tarih aralıkları, dolu saatler, parsel numaraları

Posta kodu

<p class="hata" id="posta-hata">Geçersiz posta kodu.</p>

<p class="hata" id="posta-hata">
  Posta kodu: 5 hane girin, örneğin 34130. Siz 4 hane girdiniz.
</p>

Yanlış sıralanmış rezervasyon tarihleri

<p class="hata">Tarih hatası.</p>

<p class="hata">
  Çıkış tarihi giriş tarihinden (14 Haziran) sonra olmalı.
  <button type="button" data-ayarla="cikis" data-deger="2026-06-15">15 Haziran’ı kullan</button>
</p>

Dolu randevu saati

<p class="hata">Bu saat uygun değil.</p>

<p class="hata">09.00 dolu. Bu günde uygun saatler:</p>
<ul>
  <li><button type="button" data-saat="09:30">09.30</button></li>
  <li><button type="button" data-saat="10:15">10.15</button></li>
</ul>

Mobil kod: SwiftUI ve Jetpack Compose

// SwiftUI
if posta.count != 5 { Text("Geçersiz posta kodu").foregroundColor(.red) }

// SwiftUI
if posta.count != 5 {
  Text("Posta kodu: 5 hane girin. Siz \(posta.count) hane girdiniz.")
    .foregroundColor(.red)
}

// Jetpack Compose
OutlinedTextField(
  value = posta, onValueChange = { posta = it },
  isError = posta.length != 5,
  supportingText = { if (posta.length != 5) Text("Geçersiz posta kodu") }
)

// Jetpack Compose
OutlinedTextField(
  value = posta, onValueChange = { posta = it },
  isError = posta.length != 5,
  supportingText = {
    if (posta.length != 5) Text("Posta kodu: 5 hane girin. Siz ${posta.length} hane girdiniz.")
  }
)

Hata dili için test turu

1. Her alana yanlış bir değer girin ve mesajı okuyun. Geçerli bir değerin neye benzediğini açıklıyor mu?
2. Yalnızca kısa bir değer listesi geçerliyse, listenin sunulduğunu ya da adlandırıldığını kontrol edin.
3. Tek başına "Geçersiz", "Hata" ve "İzin verilmiyor" gibi mesajları arayın.
4. Önerinin metinle tekrarlandığını, kaybolan bir yer tutucuda gösterilmediğini doğrulayın.
5. Araçlar faydayı değerlendirmez. Bir denetleyici boş ya da çok kısa bir mesaj dizesini işaretleyebilir; gerçek test her mesajı okumaktır.

Emekliye ayrılacak zayıf mesajlar

• Başka hiçbir şey olmadan "Geçersiz", "Hata", "Yanlış değer".
• Hatadan önce görünüp sonra kaybolan biçim örnekleri.
• Aynı yanlış değeri tekrar önermek (94103 yazmışken "94103 mü demek istediniz?").
• Çözüm geliştiriciye açıkken neyin yanlış olduğunu söyleyip nasıl düzeltileceğini söylememek.

Yayına almadan önce

• Çözümü bilinen hatalar çözümü metinle belirtiyor.
• Sunulan öneriler gerçek, geçerli değerler.
• Bir önerinin güvenlik ayrıntılarını açığa çıkaracağı yerlerde mesaj bilerek genel tutuluyor.

Kaynaklar

• Understanding SC 3.3.3: Error Suggestion (W3C), İngilizce, yeni sekmede açılır
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), İngilizce, yeni sekmede açılır

Standart sürümü: WCAG 2.1 (W3C Tavsiye Kararı, 5 Haziran 2018); Title II web kuralında adı geçen sürüm. Bu sayfa bilgilendirme amaçlıdır ve hukuki tavsiye niteliği taşımaz. Bağlayıcı metin için ADA yasasının ve yönetmeliklerinin resmî metinlerini esas alın ve size nasıl uygulandığını bir avukata sorun.