Hata Tanımlama

Kısaca

Yanlış giden bir şeyin işaretini vermeden yeniden yüklenen bir form, insanları tahmine bırakır. Kırmızı çerçeveyi göremeyenler, ekran okuyucu kullananlar ya da bilişsel engeli olanlar, bir hata olduğunu ve nerede olduğunu sözcüklerle öğrenmelidir.

Bu kriter, bir girdi hatası otomatik olarak algılanırsa hatalı öğenin belirlenmesini ve hatanın kullanıcıya metinle açıklanmasını ister.

Neleri kapsar?

• Girdi hatası: Girdi hatası, kullanıcının sağladığı ama kabul edilmeyen bilgidir. Atlanan zorunlu bilgiyi ve gereken biçim ya da değerlerin dışındaki bilgiyi kapsar.
• Otomatik algılanan: Kriter, sayfa hatayı kendisi algıladığında geçerlidir; örneğin zorunlu bir alanı ya da bir biçimi doğrularken.
• Öğeyi belirleyin: Hangi alanın hatalı olduğunu söyleyin; örneğin mesajda adını anarak ya da mesajı yanına koyarak.
• Metinle açıklayın: Hata metinle belirtilmelidir. Renk, simge ve diğer görsel ipuçlarına ek olarak izin verilir, tek başlarına verilmez.
• Hatanın niteliği: Açıklama neyin yanlış olduğunu anlatır. Nasıl düzeltileceğini söylemek 3.3.3'tür.
• Nasıl gösterildiği: Kriter belirli bir kalıp şart koşmaz. Özet, satır içi mesajlar, uyarı ya da iletişim kutusu işe yarayabilir.
• Otomatik düzeltilen değerler: Sayfa aralık dışı bir değeri sessizce değiştirirse, hata yine de açıklanmalıdır.
• Yerel doğrulama: Tarayıcı doğrulama mesajları kriteri karşılayabilir; ama kalıcı olmayabilir, yakınlaştırmayla ölçeklenmeyebilir, çoğu zaman geneldir ve bir seferde tek hata gösterir.
• Kapsam dışı: Programatik hata bilgisi 4.1.2, durum mesajları 4.1.3 kapsamındadır.

Kimleri etkiler?

Kırmızı çerçeveye güvenemeyen körler, az görenler ve renk görme eksikliği olanlar. Bir gönderimin neden başarısız olduğunu anlaması gereken bilişsel, dil ve öğrenme engelli kişiler. Hatanın olduğunu ve nerede olduğunu öğrenmesi gereken ekran okuyucu kullanıcıları. Formun yalnızca bir bölümünü gören büyüteç kullanıcıları.

EAA ve EN 301 549'da

Avrupa Erişilebilirlik Yasası (Direktif (AB) 2019/882) 28 Haziran 2025'ten sonra piyasaya sunulan kapsamdaki ürün ve hizmetler için geçerlidir. Yasanın 47. gerekçesi web siteleri ve mobil uygulamalar için dört ilkeyi sayar: algılanabilirlik, işletilebilirlik, anlaşılabilirlik ve sağlamlık. Metinle belirlenen hatalar, "anlaşılabilirlik" ilkesinin parçasıdır.

Teknik karşılığı EN 301 549 standardında bulunur. Standart, WCAG 3.3.1'i atıfla alır ve ortama göre ayrı maddelere dönüştürür.

Kriterin web dışı dokümanlara uygulanıp uygulanmadığı ve nasıl uygulandığı standardın 10. maddesinde belirtilir. Madde numaraları EN 301 549'un "9. + WCAG numarası" düzenine göredir. V3.2.1'de yazılım maddesi, açık ve kapalı işlevsellik için ayrı alt maddelere bölünmüştür. Kaynak gösterirken tam numaraları standarttan kontrol edin.

Standart sürümü: EN 301 549 V4.1.1 (Eylül 2026), WCAG 2.2'yi esas alan ve EAA için hazırlanan ilk sürümdür. Henüz AB Resmî Gazetesi'nde atıf almamıştır; bu nedenle EAA gereksinimlerini karşılamanın gönüllü teknik yolu olarak görülmelidir. Atıf yapıldığında EAA ile ilgili uygunluk karinesi sağlayacaktır. 3.3.1 kriterinin metni WCAG 2.1 ve 2.2'de aynıdır.

EAA bağlamında dikkat: Yasanın Madde 2/4 hükmü bazı içerikleri gereksinimlerin dışında bırakır; örneğin 28 Haziran 2025'ten önce yayımlanmış ofis dosya biçimleri ve bu tarihten sonra güncellenmeyen arşivler. Bu tarihten sonra yayımladığınız ya da değiştirdiğiniz içerik bu istisnaların kapsamında değildir.

Directive (EU) 2019/882, EUR-Lex, İngilizce, yeni sekmede açılır

Web için kod örnekleri

1. Yalnızca renkle gösterilen hata

Kırmızı bir çerçeve tek başına metin açıklaması değildir.

<input id="email" style="border:2px solid red">

<label for="email">E-posta</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-err">
<p id="email-err" class="error">Bir e-posta adresi girin; örneğin [email protected].</p>

2. Alanı işaretleyin ve mesajı bağlayın (ARIA21)

aria-invalid alanı işaretler, aria-describedby mesajı ona bağlar.

<input id="phone">
<span class="error">!</span>

<input id="phone" aria-invalid="true" aria-describedby="phone-err">
<span id="phone-err">Telefon numarası 10 haneli olmalıdır.</span>

3. Atlanan zorunlu alanı adlandırın (G83)

Hangi zorunlu alanın boş bırakıldığını söyleyin. Form yeniden gösterildiğinde diğer girdileri koruyun.

<p class="error">Lütfen formu düzeltin.</p>

<p class="error">"Soyadı" alanı zorunludur.</p>

4. Hatayı duyurun

Bir canlı bölge ya da role="alert", mesaj göründüğünde ekran okuyucuların onu okumasını sağlar (ARIA19).

<div class="error" style="display:none">…</div> <!-- sessizce gösteriliyor -->

<div id="errors" role="alert"></div>
<script>
errors.textContent = "\"Soyadı\" alanı zorunludur.";
</script>

5. Hata özeti

Hataları en üstte listeleyin; her biri kendi alanına bağlansın ve odağı özete taşıyın.

<!-- Form, özet ve mesaj olmadan yeniden yükleniyor -->

<div role="alert" tabindex="-1" id="summary">
  <h2>2 hata</h2>
  <ul>
    <li><a href="#email">E-posta: geçerli bir adres girin</a></li>
    <li><a href="#phone">Telefon: 10 hane gerekli</a></li>
  </ul>
</div>

6. Sessizce düzeltilen değer

Sayfa kullanıcının girdiği bir değeri değiştiriyorsa, bunu söyleyin.

qty.value = Math.min(qty.value, 10); // mesaj olmadan değiştirildi

if (qty.value > 10) {
  qty.value = 10;
  msg.textContent = "En fazla 10 olabilir, bu yüzden miktar 10 yapıldı.";
}

Mobil için kod örnekleri

Hatayı alanın yanında metinle gösterin ve ekran okuyuculara bildirildiğinden emin olun. Yerel bir ekranda da renk tek başına yetmez.

iOS (SwiftUI)

import SwiftUI

struct EmailField: View {
    @State private var email = ""
    @State private var error: String?

    var body: some View {
        VStack(alignment: .leading) {
            TextField("E-posta", text: $email)
                .onSubmit { validate() }
            if let error {
                // Hata yalnızca kırmızı bir çerçeve değil, metindir
                Text(error).foregroundStyle(.red)
            }
        }
    }

    private func validate() {
        if email.contains("@") { error = nil; return }
        error = "Bir e-posta adresi girin; örneğin [email protected]."
        // VoiceOver kullanıcılarına hatanın göründüğünü bildirin
        AccessibilityNotification.Announcement(error ?? "").post()
    }
}

Android (Jetpack Compose)

import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Text
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.semantics.error
import androidx.compose.ui.semantics.semantics

@Composable
fun EmailField() {
    var email by remember { mutableStateOf("") }
    val message = if (email.isNotEmpty() && !email.contains("@"))
        "Bir e-posta adresi girin; örneğin [email protected]." else null

    OutlinedTextField(
        value = email,
        onValueChange = { email = it },
        label = { Text("E-posta") },
        isError = message != null,
        // Hata yalnızca kırmızı bir çerçeve değil, metindir
        supportingText = { message?.let { Text(it) } },
        modifier = Modifier.semantics { message?.let { error(it) } }
    )
}

Nasıl test edilir?

• Hatalarla gönderin: Zorunlu alanları boş bırakın ve geçersiz değerler girin. Sayfa bir hata olduğunu metinle söylüyor mu?
• Öğeyi kontrol edin: Hangi alanın hatalı olduğu, mesajdan ya da konumundan anlaşılıyor mu?
• Rengi kaldırın: Sayfayı gri tonlamada ya da renkler kapalıyken görüntüleyin. Hataların nerede olduğunu hâlâ söyleyebiliyor musunuz?
• Ekran okuyucu kullanın: Hata göründüğünde duyuruluyor mu ve alana bağlı mı?
• Yerel doğrulamayı kontrol edin: Tarayıcı mesajlarına güveniyorsanız %200 yakınlaştırmada ve birkaç hata aynı anda varken test edin.
• Otomatik düzeltmeleri kontrol edin: Sayfa bir değeri değiştiriyorsa kullanıcıya söyleniyor mu?
• Denetleyiciyi başlangıç olarak kullanın: Otomatik araçlar eksik aria-invalid ve bağlanmamış mesajları bulabilir, ama metnin hatayı açıklayıp açıklamadığını değerlendiremez. Bunu bir kişi okumalıdır.

Sık yapılan hatalar

• Tek ipucu olarak renk: Metinsiz kırmızı çerçeve ya da simge.
• Genel mesaj: Hangi alan olduğunu söylemeyen "Lütfen hataları düzeltin".
• Alandan uzak mesaj: Ona bağlantı ya da gönderme olmadan.
• Duyurulmayan hatalar: Sessizce eklenen ve ekran okuyucuların hiç okumadığı içerik.
• Formu temizlemek: Hata gösterildiğinde kullanıcının girdiğini kaybetmek.
• Hata olarak yer tutucu metin: Kullanıcı yazınca kaybolur.
• Sessiz düzeltmeler: Bir değeri açıklamadan değiştirmek.
• Her şey için alert(): İletişim kutusu kapatılınca mesaj kaybolur ve alanın yanında kalmaz.

Kaynaklar

• Understanding SC 3.3.1: Error Identification (W3C), İngilizce, yeni sekmede açılır
• G83: Providing text descriptions to identify required fields that were not completed (W3C), İngilizce, yeni sekmede açılır
• G85: Providing a text description when user input falls outside the required format or values (W3C), İngilizce, yeni sekmede açılır
• ARIA21: Using aria-invalid to Indicate An Error Field (W3C), İngilizce, yeni sekmede açılır
• ARIA19: Using ARIA role=alert or Live Regions to Identify Errors (W3C), İngilizce, yeni sekmede açılır
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), İngilizce, yeni sekmede açılır
• EN 301 549 V4.1.1 (ETSI), İngilizce, yeni sekmede açılır
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), İngilizce, yeni sekmede açılır

Standart sürümü: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. Bu sayfa bilgilendirme amaçlıdır ve hukuki tavsiye niteliği taşımaz; bağlayıcı metin için Avrupa Erişilebilirlik Yasası'nın (Direktif (AB) 2019/882) ve EN 301 549 standardının resmî metinlerini esas alın.