WCAG Başarı Kriterleri · Level AA

WCAG 3.3.4: Hata Önleme (Hukuki, Finansal, Veri)

WCAG 3.3.4, hukuki taahhütler, finansal işlemler veya hassas veriler içeren web gönderimlerinin, sonlandırılmadan önce kontrol edilebilmesini, düzeltilebilmesini veya geri alınabilmesini gerektirir. Bu, tüm kullanıcıları — özellikle bilişsel ve motor engelli olanları — geri döndürülemez, yüksek riskli hatalardan korur.

Bu Kuralın Anlamı

WCAG Başarı Ölçütü 3.3.4, Hata Önleme (Hukuki, Finansal, Veri) başlığını taşır ve İlke 3 (Anlaşılabilir) ile Yönerge 3.3 (Girdi Yardımı) kapsamında Seviye AA gereksinimidir. Özellikle, kullanıcıların hukuki taahhütlere veya finansal işlemlere sebep olabildiği ya da kullanıcının bir veri depolama sisteminde kullanıcı tarafından kontrol edilebilen verileri değiştirdiği veya sildiği web sayfaları için geçerlidir.

Bu ölçüt, bu tür her gönderim için aşağıdaki üç güvenlik önleminden en az birinin sağlanmasını zorunlu kılar:

  • Geri alınabilir: Gönderim yapıldıktan sonra geri alınabilir. Örneğin, bir sipariş tanımlı bir zaman aralığı içinde iptal edilebilir veya silinen bir kayıt geri yüklenebilir.
  • Kontrol edilmiş: Kullanıcı tarafından girilen veriler girdi hatalarına karşı kontrol edilir ve kullanıcıya, gönderim tamamlanmadan önce bu hataları düzeltme fırsatı verilir.
  • Onaylanmış: Nihai gönderimden önce bilgileri gözden geçirme, onaylama ve düzeltme mekanizması sağlanır. Bu genellikle, gönder düğmesinin işlemi tamamlamasından önce bir özet veya gözden geçirme adımı şeklinde olur.

Bu üç koşuldan yalnızca birinin sağlanmasının geçer not için yeterli olduğunu unutmamak önemlidir. Yalnızca bir gözden geçir ve onayla adımı sunmak yeterlidir; gönderim sonrası iptal süresi sunmak da yeterlidir; düzeltme fırsatı içeren sağlam gerçek zamanlı doğrulama da yeterlidir. Ancak en iyi uygulama, birden fazla güvenlik önlemini bir arada kullanmaktır.

Ölçütün kapsamı: Kural üç işlem kategorisi için geçerlidir. Birincisi, abonelik için kayıt olmak, bir sözleşmeyi kabul etmek veya bağlayıcı bir hukuki form göndermek gibi hukuki taahhütleri kapsar. İkincisi, satın almalar, para transferleri, kredi başvuruları ve fatura ödemeleri dahil finansal işlemleri kapsar. Üçüncüsü, bir veri depolama sisteminde kullanıcı tarafından kontrol edilen verileri değiştiren veya silen herhangi bir eylemi kapsar — örneğin profil bilgilerinin güncellenmesi, bir bulut hizmetinden dosyaların silinmesi veya bir yönetim panelinde kayıtların düzenlenmesi.

Geçer bir örnek: son adımda bir sipariş özeti, bir "Düzenle" bağlantısı ve "Siparişi Ver" düğmesi sunan bir e-ticaret ödeme süreci. Başarısız bir örnek: "Şimdi Satın Al" düğmesine tıklamanın, herhangi bir gözden geçirme ekranı, iptal seçeneği veya doğrulama adımı olmadan karttan anında ücret çektiği tek sayfalık bir satın alma formu.

Ölçütün tanımlı bir istisnası vardır: yanlış bilgi gönderiminin sonuçlarının önemli olmadığı ve gönderimin kolayca tekrarlanabildiği formlar için geçerli değildir. Basit iletişim formları veya bülten kayıtları genellikle kapsam dışındadır, ancak iyi uygulama bu formlarda da doğrulama yapılmasını teşvik eder.

Neden Önemlidir

Yüksek riskli işlemler sırasında yapılan hatalar ciddi, bazen geri döndürülemez sonuçlara yol açabilir: yanlış hesaba para transferi, yanlış beyanlarla imzalanan bir hukuki anlaşma, hatalı bilgilerle güncellenen tıbbi kayıtlar veya yanlış pakette satın alınan bir abonelik. Engeli olmayan kullanıcılar için bu hataları fark etmek ve düzeltmek çoğu zaman görece kolaydır. Pek çok engelli kullanıcı grubu için ise, bu ölçütün gerektirdiği güvenlik önlemleri olmadan bu hataları düzeltmek son derece zor veya imkânsız olabilir.

Bilişsel engelli kullanıcılar — disleksi, DEHB, hafıza bozuklukları veya zihinsel yetersizlikler dahil — veri girişi hatalarına daha yatkındır ve gönder düğmesine tıklamadan önce bu hataları fark etme olasılıkları daha düşüktür. Bir gözden geçirme ekranı, hataları fark edebilmeleri için ihtiyaç duydukları zaman ve netliği sağlar. Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık 1 milyar insan, günlük işlevselliği etkileyen bir tür bilişsel, nörolojik veya ruh sağlığı durumuyla yaşamaktadır.

Motor engelli kullanıcılar ise anahtar erişimi, göz izleme cihazları veya alternatif klavyelere güveniyorlarsa, kazara etkinleştirmelere ve istenmeyen tuş vuruşlarına daha yatkındır. Bir onay adımı kritik bir tampon görevi görür: "Gönder" yanlışlıkla etkinleştirilse bile, kullanıcı işlemin tamamlanmasından önce iptal etmek için ikinci bir fırsata sahip olur. Bu güvenlik önlemi olmadan tek bir yanlış dokunuş, kullanıcının geri alamayacağı bir finansal işlemi tetikleyebilir.

Ekran okuyucu kullanıcıları uzun formlarda satır satır gezinirken, girdiklerine dair bütünsel bir görüşe sahip olmayabilir. Onay aşamasında girilen değerlerin sesli özetlenmesi, görsel olarak tarayamadıkları hataları yakalamalarını sağlar.

Kaygı bozukluğu veya dikkat güçlüğü yaşayan kullanıcılar, bir güvenlik ağı olduğunu bilmekten büyük ölçüde fayda sağlar. Araştırmalar, kullanıcılar bir süreci hata tolere edici olarak algıladıklarında, sürece daha güvenle katıldıklarını ve işlemleri daha az yarıda bıraktıklarını tutarlı biçimde göstermektedir. Bu durum, dönüşüm oranlarını ve kullanıcı memnuniyetini doğrudan artırır; 3.3.4 uyumunu hem etik bir yükümlülük hem de ticari bir avantaj haline getirir.

Gerçek dünya senaryosu: İstanbul’da görme engelli bir kullanıcı, bir ekran okuyucu kullanarak yurt içi uçuş rezervasyonu yapıyor. Bir tarih seçiyor ancak yolcu sayısı alanını fark etmeden üzerinden geçip varsayılan değer olan iki yolcu yerine bir yolcu girmeden devam ediyor. Rezervasyon sitesi, "Onayla"yı etkinleştirdiği anda kartından ücret çekerse, iki bilet satın almış olur ve iade edilmeyen tarife cezalarıyla karşılaşabilir. "1 yolcu: Ayşe Yılmaz, Ankara’dan İstanbul’a, 14 Mart, Ekonomi — Toplam: ₺850" şeklinde okunan bir gözden geçirme ekranı, hatayı anında fark etmesini sağlar.

İlgili Axe-core Kuralları

WCAG 3.3.4, manuel test gerektirir. İstediği güvenlik önlemleri — geri alınabilirlik, düzeltme fırsatı içeren doğrulama ve onay adımları — iş akışı ve iş mantığıyla ilgili olduğundan, hiçbir otomatik axe-core kuralı bu ölçüte doğrudan karşılık gelmez; bunlar işaretleme yapısı veya DOM öznitelikleriyle ilgili değildir. Otomatik araçlar HTML ve ARIA’yı ayrıştırabilir, ancak bir "Şimdi Öde" düğmesinin geri alınamaz bir ücretlendirmeyi tetikleyip tetiklemediğini, bir iptal politikasının var olup olmadığını veya bir gözden geçirme ekranında gösterilen verilerin gerçekten girilen verileri yansıtıp yansıtmadığını belirleyemez.

  • Otomasyonun bunu yakalayamamasının nedeni: Otomatik bir tarayıcı, metni "Gönder" olan ve geçerli işaretlemeye sahip bir <button> öğesi görür. Bu düğmenin etkinleştirilmesinin bağlayıcı bir finansal işlemi başlatıp başlatmadığını, bir onay iletişim kutusunun takip edip etmeyeceğini veya işlemin sonradan geri alınıp alınamayacağını bilmesinin hiçbir yolu yoktur. Bunlar, tek tek DOM düğümlerinin üzerinde yer alan mimari ve UX kararlarıdır ve tüm kullanıcı yolculuğunu anlayan bir insan test uzmanı gerektirir.
  • Otomatik taramalarda bakılacak kısmi sinyaller: Axe-core doğrudan 3.3.4 ihlallerini işaretlemese de, denetçiler bazen riski artıran ilgili sorunları belirlemek için axe kullanır — ödeme alanlarında eksik autocomplete öznitelikleri (1.3.5 ile ilgili), eksik hata mesajları (3.3.1 ve 3.3.3 ile ilgili) veya form kontrollerinde eksik etiketler (1.3.1 ve 4.1.2 ile ilgili) gibi. Bu ilişkili hatalar, hata önlemeyi daha da zorlaştırır.
  • Önerilen manuel denetim yaklaşımı: Test uzmanları, hukuki, finansal veya veri değiştirme içeren her kullanıcı yolculuğunu haritalandırmalı ve ardından her yolculuğu üç ölçüte göre değerlendirmelidir: Bunu geri almanın bir yolu var mı? Düzeltme fırsatı içeren satır içi doğrulama var mı? Bir gözden geçir ve onayla adımı var mı? Bu üçünden herhangi birinin sağlanmadığı her yolculuk, 3.3.4 için bir başarısızlık oluşturur.

Nasıl Test Edilir

  1. Yüksek riskli formların envanterini çıkarın: Test başlamadan önce, sitede finansal işlemleri (ödeme, tahsilat, faturalama), hukuki taahhütleri (sözleşme imzalama, abonelik kaydı, onay formları) veya veri değiştirme/silme işlemlerini (profil düzenleme, dosya silme, hesap kapatma) içeren tüm form veya etkileşimli iş akışlarının bir listesini oluşturun. Yalnızca bunlar 3.3.4 kapsamındaki akışlardır.
  2. İlgili sorunlar için otomatik tarama çalıştırın: Her kapsam içi sayfada form düzeyinde erişilebilirlik hatalarını belirlemek için axe DevTools veya Lighthouse kullanın. Bu araçlar 3.3.4’ü doğrudan işaretlemese de, eksik etiketler, eksik autocomplete öznitelikleri ve eksik hata duyuruları gibi sorunların çözülmesi, hata önleme güvenlik önlemini değerlendirmeden önce bir form kalitesi tabanı oluşturur.
  3. "Kontrol edilmiş" güvenlik önlemini test edin: Her kapsam içi formu bilerek hatalarla gönderin — kart numarasında yer değiştirmiş rakamlar, geçersiz bir tarih, eşleşmeyen e-posta doğrulama alanı gibi. Sistem gönderimi durduruyor mu, belirli hatayı tanımlıyor mu, hatanın nasıl düzeltileceğini açıklıyor mu (3.3.3’e uygun olarak) ve kullanıcıyı düzeltme yapması için form üzerinde tutuyor mu gözlemleyin. Form sessizce gönderiliyorsa veya yalnızca hangi alanın başarısız olduğunu belirtmeyen genel bir hata gösteriyorsa, bu güvenlik önlemi karşılanmamış demektir.
  4. "Onaylanmış" güvenlik önlemini test edin: Her kapsam içi formu geçerli verilerle doldurun ve tam akış boyunca ilerleyin. Nihai gönderimden önce bir gözden geçirme adımı sunulup sunulmadığını belirleyin. Gözden geçirme adımının girilen tüm verileri okunabilir bir formatta gösterdiğini, geri dönüp düzenleme mekanizması içerdiğini ve gönderimi tamamlamak için kasıtlı bir son eylem gerektirdiğini doğrulayın. NVDA ile Firefox ve JAWS ile Chrome kullanarak bu gözden geçirme adımında ekran okuyucu ile gezinerek tüm değerlerin duyurulduğunu ve düzenle ve onayla kontrollerinin klavye ile erişilebilir olduğunu doğrulayın.
  5. "Geri alınabilir" güvenlik önlemini test edin: Bir gönderimi tamamlayın ve ardından bunu geri almaya çalışın. E-ticaret için, onay e-postasında veya sipariş geçmişi sayfasında bir iptal bağlantısı arayın. Veri silme için, geri yükleme veya çöp kutusu mekanizması arayın. Geri alma süresinin yalnızca sonrasında değil, kullanıcı gönderim yapmadan önce de açıkça iletişim kurulduğunu değerlendirin.
  6. Ekran okuyucu ile uçtan uca gezinme (macOS/iOS’ta VoiceOver + Safari): Tüm ödeme veya gönderim akışında yalnızca klavye ve VoiceOver kullanarak gezinin. Gözden geçirme ekranının girilen tüm değerleri mantıklı bir sırayla okuduğunu, düzenleme bağlantılarının yeterli bağlamla duyurulduğunu (örneğin yalnızca "Düzenle" değil "Teslimat adresini düzenle") ve son onay düğmesinin amacının açık olduğunu doğrulayın.
  7. Bilişsel yük kontrolü: Gözden geçirme adımının sade bir dille sunulup sunulmadığını değerlendirin. Ham veritabanı alan adlarını listeleyen veya açıklama olmadan hukuki jargon kullanan bir özet, teknik olarak bir gözden geçirme ekranı sayılabilir ancak pratikte bilişsel engelli kullanıcılar için başarısız olur.

Nasıl Düzeltilir

Gözden geçirme adımı olmayan tek adımlı ödeme — Hatalı

<!-- Sorunlu: "Satın Almayı Tamamla"ya tıklamak karttan anında ücret çekiyor -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

Gözden geçirme adımı eklenmiş tek adımlı ödeme — Doğru

<!-- Adım 1: form verileri toplar, nihai olmayan gözden geçirme sayfasına gönderir -->
<form action='/checkout/review' method='post'>
  <!-- ödeme ve teslimat alanları -->
  <button type='submit'>Review Order</button>
</form>

<!-- Adım 2: gözden geçirme sayfası girilen tüm verileri özetler ve düzenleme bağlantıları sunar -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- Son düğme bağlayıcı eylem olarak açıkça etiketlenmiştir -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

Onay olmadan geri alınamaz veri silme — Hatalı

<!-- Sorunlu: sil düğmesi herhangi bir onay iletişim kutusu olmadan doğrudan gönderim yapıyor -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

Onay iletişim kutusuyla geri alınamaz veri silme — Doğru

<!-- Tetikleyici düğme yıkıcı eylemi değil, bir onay iletişim kutusunu açar -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Satır içi doğrulaması olmayan finansal form — Hatalı

<!-- Sorunlu: doğrulama yok, yanlış IBAN sessizce kabul ediliyor -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

Doğrulama ve gözden geçirme adımı olan finansal form — Doğru

<!-- Hata ilişkilendirmesi için aria-describedby ile satır içi doğrulama -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Doğrudan yürütme yerine gözden geçirme sayfasına gönderir -->
  <button type='submit'>Review Transfer</button>
</form>

Yaygın Hatalar

  • "Gözden geçirme" mekanizması olarak araç ipucu kullanmak: Gönder düğmesinden önce girilen değerleri bir hover araç ipucunda göstermek, bir gözden geçirme adımı sayılmaz; çünkü araç ipuçları yalnızca klavye kullanan veya ekran okuyucu kullanan kullanıcılar için erişilebilir değildir ve kullanıcı harekete geçmeden önce kaybolur.
  • Son düğmeyi eylemi tanımlamak yerine "Devam" olarak etiketlemek: Bir gözden geçirme sayfasında "Devam" yazan bir düğme, tıklamanın bir finansal işlemi tamamlayacağını açıkça belirtmez. Düğme, "₺850 ödeyerek siparişi ver" veya "Sözleşmeyi imzala" gibi bağlayıcı eylemi tartışmasız biçimde tanımlamalıdır.
  • İptal politikasını yalnızca hizmet şartlarında sunmak: Geri alma mekanizmasını, çoğu kullanıcının okumayacağı bağlantılı bir hukuki belgede gizlemek, geri alınabilirlik gereksinimini karşılamaz. İptal imkânı ve bunun kullanılabileceği süre, işlemin kendi akışı içinde iletişim kurulmalıdır.
  • Tek onay mekanizması olarak window.confirm() kullanmak: Tarayıcıya özgü onay iletişim kutuları bazı yardımcı teknolojiler tarafından zayıf desteklenir, okunabilirlik için stillendirilemez ve belirli tarayıcı yapılandırmalarında engellenir. Yüksek riskli gönderimler için tek güvenlik önlemi olarak kullanılmamalıdır.
  • Doğrulama başarısız olduğunda formu geçerli alan değerlerini korumadan sıfırlamak: Bir form doğrulamadan geçemediğinde tüm alanları temizlemek, özellikle motor engelli kullanıcılar için tüm verileri yeniden girmeyi zorunlu kılar. Yalnızca geçersiz alan temizlenmeli veya vurgulanmalı; tüm geçerli girişler korunmalıdır.
  • Gözden geçirme sayfasındaki "Düzenle" bağlantısını programatik ilişki olmadan yerleştirmek: Her veri grubunun yanındaki bir "Düzenle" bağlantısı, açıklayıcı bir erişilebilir ada sahip olmalıdır (örneğin, aria-label='Edit billing address'). Birden çok kez tekrarlanan yalın bir "Düzenle", bağlantılara göre gezinirken ekran okuyucu kullanıcıları için belirsizdir.
  • Gözden geçirme adımını ekran okuyuculara duyurmamak: Gözden geçirme sayfası, odağı başlığa veya bir özet bölgesine taşımadan yüklenirse, ekran okuyucu kullanıcıları bir gözden geçirme sayfasında olduklarını fark etmeyebilir ve özeti okumadan gönder düğmesini etkinleştirebilir.
  • Ölçütü yalnızca ödeme sayfalarına uygulanır sanmak: Kapsam, herhangi bir hukuki taahhüdü (abonelik kaydı, onay formları, sözleşme kabulü) ve herhangi bir kullanıcı verisi değişikliğini (dosya silme, tıbbi kayıtları güncelleme, hesap ayarlarını değiştirme) içerir. Geliştiriciler, yönetim panellerini ve ayar sayfalarını sıklıkla gözden kaçırır.
  • Geri almayı yalnızca telefon veya e-posta ile sunmak: İptal için bir destek hattını aramak gerekiyorsa, konuşma veya işitme engeli olan kullanıcılar geri alma mekanizmasına erişemeyebilir. Geri alma yolu da erişilebilir olmalıdır — tercihen uygulama içi bir iptal akışı.
  • Mobil web görünümlerinde ölçütü atlamak: Bazı ekipler masaüstünde bir gözden geçirme adımı uygular ancak ekran alanını azaltmak için mobilde sıkıştırılmış tek adımlı bir akış kullanır. Ölçüt, tüm görüntüleme boyutları için eşit şekilde geçerlidir ve duyarlı veya mobil web uygulamalarında atlanmamalıdır.

Türkiye’nin Erişilebilirlik Mevzuatıyla İlişkisi

Türkiye’nin 21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanan 2025/10 sayılı Cumhurbaşkanlığı Genelgesi, teknik standart olarak WCAG 2.2’ye atıfta bulunan kapsamlı bir ulusal erişilebilirlik çerçevesi oluşturur. Genelge, dijital hizmetlerin en az WCAG 2.2 Seviye AA uyumunu sağlamasını zorunlu kılar; buna WCAG 3.3.4 Hata Önleme (Hukuki, Finansal, Veri) de dahildir.

Genelge kapsamında açıkça belirtilen kuruluşlar geniş bir sektör yelpazesini kapsar. Kamu kurum ve kuruluşları, hukuki taahhütler ve veri değişikliklerini sıklıkla içeren çevrimiçi başvurular, e-devlet portalları ve dijital kimlik hizmetleri dahil tüm vatandaş odaklı dijital hizmetleri erişilebilir kılmakla yükümlüdür. BDDK (Bankacılık Düzenleme ve Denetleme Kurumu) tarafından düzenlenen bankalar ve finansal kuruluşlar uyum sağlamak zorundadır; bu da 3.3.4’ü sundukları her çevrimiçi bankacılık işlemi, para transferi ve kredi başvurusu için doğrudan ilgili hale getirir. Dijital hasta portalları, randevu sistemleri ve elektronik sağlık kayıtları işleten hastaneler ve sağlık kuruluşları, bu sistemlerdeki her veri girişi veya değişikliğinin hata önleme standartlarını karşıladığından emin olmalıdır. 200.000 veya daha fazla abonesi olan telekomünikasyon sağlayıcıları — Turkcell, Vodafone TR ve Türk Telekom dahil — abonelik yönetimi, tarife değişiklikleri ve ödeme akışlarının kapsandığından emin olmalıdır. E-ticaret platformları, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar da kapsam dahilindedir; bu da Türkiye pazarındaki yüksek hacimli işlemsel web hizmetlerinin önemli bir bölümünü kapsar.

Bu çerçeve kapsamında 3.3.4’e uyum, yalnızca teknik bir onay kutusu değildir. Aile ve Sosyal Hizmetler Bakanlığı tarafından verilen Erişilebilirlik Logosunu almak isteyen kuruluşlar, tam WCAG 2.2 AA uyumunu göstermek zorundadır. Logo, kamuya yönelik bir güven işareti olarak hizmet eder ve tüketiciler ile tedarik makamları tarafından giderek daha fazla beklenmektedir. Finansal veya hukuki iş akışlarında hata önleme güvenlik önlemlerini uygulamamak, hem logonun reddedilmesine hem de Genelge’nin yaptırım hükümleri kapsamında idari işlemlere yol açabilir.

Özellikle e-ticaret ve fintech sektörlerindeki Türk kuruluşları için 3.3.4, Türk hukukundaki mevcut tüketici koruma gereklilikleriyle yakından uyumludur. Tüketicinin Korunması Hakkında Kanun (No. 6502) ve ilgili e-ticaret düzenlemeleri, mesafeli sözleşmeler için açık ön bilgilendirme ve cayma haklarını hâlihazırda zorunlu kılmaktadır. WCAG 3.3.4’e uygun bir gözden geçir ve onayla adımının uygulanması, hem erişilebilirlik gereksinimini hem de alıcıyı bağlamadan önce sipariş özetlerini sunma yönündeki tüketici hukuku yükümlülüğünü aynı anda karşılar. Bu ikili uyum, doğru hata önleme UX’ine yatırım yapmayı, Türk dijital hizmet sağlayıcıları için yüksek değerli ve düşük mükerrer bir çaba haline getirir.