Hata Önerisi

Kısaca

"Geçersiz girdi" yazısı, nasıl düzeltileceğini bilmekle aynı şey değildir. Öğrenme engeli, az görmesi ya da hareket kısıtı olan kişiler, form yalnızca bir şeyin yanlış olduğunu söylediğinde çok zaman kaybedebilir ya da vazgeçebilir.

Bu kriter, bir girdi hatası otomatik olarak algılanırsa ve düzeltme önerileri biliniyorsa, önerilerin kullanıcıya sunulmasını ister; içeriğin güvenliğini ya da amacını tehlikeye atmadıkça.

Neleri kapsar?

• İki koşul: Hata otomatik algılanmıştır ve düzeltme bilinmektedir. Sayfa nasıl düzeltileceğini bilemiyorsa, öneri gerekmez.
• 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.
• Gereken biçim: Girdi gereken biçimle eşleşmediğinde biçimi açıklayın ya da bir örnek gösterin (G85, G177).
• Sınırlı değer kümesi: Değer bir listeden gelmek zorundaysa, izin verilen değerlerin neler olduğunu söyleyin (G84).
• Önerilen düzeltme metni: Amaçlanan değeri çıkarabiliyorsanız, sunun (G177); örneğin "Şunu mu demek istediniz: [email protected]?".
• İstisna: Öneri, içeriğin güvenliğini ya da amacını tehlikeye atacaksa gerekmez. Örneğin bir giriş sayfasının kullanıcı adı ve parolanın hangisinin yanlış olduğunu söylemesi gerekmez.
• Kim açıklar: Yazar hatayı açıklayabilir ya da kullanıcı aracı bunu programatik bilgiden yapabilir.
• Kapsam dışı: Hatayı belirlemek 3.3.1'dir. Önemli işlemlerde hataları önlemek 3.3.4'tür.

Kimleri etkiler?

Nasıl düzeltileceği söylenince formları başarıyla tamamlayan öğrenme ve bilişsel engelli kişiler. Hatayı ve düzeltmeyi daha iyi anlayan körler ve az görenler. Değerleri bu sayede daha az yeniden giren hareket engelli kişiler.

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. Hataları düzeltme yardımı, "anlaşılabilirlik" ilkesinin parçasıdır.

Teknik karşılığı EN 301 549 standardında bulunur. Standart, WCAG 3.3.3'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.3 kriterinin metni WCAG 2.1 ve 2.2'de aynıdır. AA düzeyinde bir kriterdir.

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. Nasıl düzeltileceğini söyleyin

Mesaj yalnızca değerin geçersiz olduğunu söylememelidir.

<p class="error">Geçersiz tarih.</p>

<p class="error">Tarih GG/AA/YYYY biçiminde olmalıdır; örneğin 31/03/2026.</p>

2. Olası düzeltmeyi önerin (G177)

Amaçlanan değer çıkarılabiliyorsa, sunun.

<p class="error">Geçersiz e-posta alan adı.</p>

<p class="error">Şunu mu demek istediniz: <button type="button">[email protected]</button>?</p>

3. İzin verilen değerleri sıralayın (G84)

Değerin bir kümeden gelmesi gerekiyorsa, kümeyi adlandırın.

<p class="error">Değere izin verilmiyor.</p>

<p class="error">Şunlardan birini seçin: küçük, orta, büyük.</p>

4. Parola kuralını açıklayın

Hangi kuralın karşılanmadığını ve neyin gerektiğini söyleyin.

<p class="error">Zayıf parola.</p>

<p class="error">Parolanız en az 12 karakter ve bir rakam içermelidir. Şu an 9 karakter var ve rakam yok.</p>

5. Güvenlik istisnası

Bir girişin, saldırgana yardım edebileceği için hangi kısmın yanlış olduğunu açıklaması gerekmez.

<p class="error">Bu e-posta için hesap yok.</p> <!-- saldırgana yardım eder -->

<p class="error">E-posta ya da parola doğru değil. Tekrar deneyin ya da parolanızı sıfırlayın.</p>

6. Yeniden yazmadan düzeltmeyi sunun

Mümkün olduğunda, kullanıcı öneriyi tek eylemle kabul edebilsin.

<p class="error">Posta kodu bulunamadı.</p>

<p class="error">34000 posta kodunu bulamadık. 34010 (İstanbul) mu demek istediniz?
  <button type="button">Bu posta kodunu kullan</button></p>

Mobil için kod örnekleri

Mobilde yazmak daha yavaş, düzeltmeler daha pahalıdır; bu yüzden öneriler daha da yardımcı olur. Dokununca kabul edilen bir öneri sunun ve mesajı alanın yanında tutun.

iOS (SwiftUI)

import SwiftUI

struct EmailEntry: View {
    @State private var email = "[email protected]"

    var body: some View {
        VStack(alignment: .leading) {
            TextField("E-posta", text: $email)
            if email.hasSuffix("@gmial.com") {
                // Neyin yanlış olduğunu söyleyin ve olası düzeltmeyi sunun
                Text("Şunu mu demek istediniz: gmail.com?")
                Button("[email protected] kullan") {
                    email = email.replacingOccurrences(of: "gmial.com", with: "gmail.com")
                }
            }
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.*
import androidx.compose.runtime.*

@Composable
fun EmailEntry() {
    var email by remember { mutableStateOf("[email protected]") }
    Column {
        OutlinedTextField(value = email, onValueChange = { email = it }, label = { Text("E-posta") })
        if (email.endsWith("@gmial.com")) {
            // Neyin yanlış olduğunu söyleyin ve olası düzeltmeyi sunun
            Text("Şunu mu demek istediniz: gmail.com?")
            TextButton(onClick = { email = email.replace("gmial.com", "gmail.com") }) {
                Text("[email protected] kullan")
            }
        }
    }
}

Nasıl test edilir?

• Her hatayı tetikleyin: Geçersiz, eksik ve aralık dışı değerler girin. Her mesaj nasıl düzeltileceğini söylüyor mu?
• Biçimi kontrol edin: Bir biçim gerekiyorsa, mesaj onu belirtiyor ya da örnekle gösteriyor mu?
• İzin verilen değerleri kontrol edin: Değer bir listeden gelmek zorundaysa, liste veriliyor mu?
• Bilinen düzeltmeleri arayın: Sayfa, yanlış yazılmış bir alan adı gibi amaçlanan değeri çıkarıp önerebilir mi?
• İstisnayı uygulayın: Bir öneri güvenlik bilgisini açığa çıkarır ya da amacı bozar mı; örneğin bir giriş ya da sınavda?
• Mesajı tek başına okuyun: Formu görmeden, bir kişi mesaja göre hareket edebilir mi?
• Denetleyiciyi başlangıç olarak kullanın: Otomatik araçlar bir önerinin yardımcı olup olmadığını değerlendiremez. Her mesajı bir kişi okumalıdır.

Sık yapılan hatalar

• Yalnızca "geçersiz": Mesaj bir şeyin yanlış olduğunu söyler, nasıl düzeltileceğini söylemez.
• Biçim için örnek yok: Tarih ya da telefon biçimi hiç gösterilmez.
• Adlandırılmamış izin verilen değerler: Kullanıcı seçenekleri tahmin etmek zorunda.
• Açık bir düzeltmeyi yok saymak: Tanınmış bir alan adındaki yazım hatası önerilmez.
• Sayfanın bilemeyeceği şeyi önermek: Yanlış tahmin kafa karışıklığını artırır.
• Girişte çok fazla şey açığa çıkarmak: Kullanıcı adı ve parolanın hangisinin yanlış olduğunu söylemek.
• Kullanıcıların kaçırdığı yerde öneriler: Alan ekran dışındayken en üstteki mesaj.
• Teknik hata kodları: Kullanıcının bir şey yapamayacağı mesajlar.

Kaynaklar

• Understanding SC 3.3.3: Error Suggestion (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
• G177: Providing suggested correction text (W3C), İngilizce, yeni sekmede açılır
• ARIA18: Using aria-alertdialog 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.