WCAG 3.3.6: Hata Önleme (Tümü)

Bu Kuralın Anlamı

WCAG 3.3.6 — Hata Önleme (Tümü), Anlaşılabilir ilkesinin altında Seviye AAA başarı ölçütüdür. 3.3.4 (Hata Önleme: Hukuki, Finansal, Veri) gerekliliklerini, gönderimin hukuki taahhütler, finansal işlemler veya kişisel olarak tanımlanabilir veriler içerip içermediğine bakılmaksızın, kullanıcının bilgi göndermesini gerektiren tüm sayfaları kapsayacak şekilde genişletir.

Özünde, bu ölçüt, kullanıcının bilgi gönderdiği herhangi bir web sayfası için aşağıdaki üç koşuldan en az birinin sağlanmasını gerektirir:

• Geri alınabilir: Gönderimler sonradan geri alınabilir olmalıdır. Kullanıcı makul bir süre içinde bir işlemi geri alabilir, iptal edebilir veya geri çekebilir. Örneğin, gönderilmiş bir mesaj geri çağrılabilir veya gönderilmiş bir form, bir onay kuyruğundan iptal edilebilir.
• Kontrol edilmiş: Kullanıcı tarafından girilen veriler, nihai gönderimden önce giriş hatalarına karşı kontrol edilir ve kullanıcıya bu hataları düzeltme fırsatı verilir. Bu, satır içi doğrulama, gönderim öncesi özetler veya adım adım gözden geçirme akışlarını içerir.
• Onaylanmış: Gönderim kesinleşmeden önce bilgileri gözden geçirmek, onaylamak ve düzeltmek için bir mekanizma sağlanır. Bu, bir gözden geçirme ekranı, bir onay iletişim kutusu veya son gözden geçirme adımı içeren çok adımlı bir sihirbaz olabilir.

3.3.4 ile 3.3.6 arasındaki temel fark kapsamdır. 3.3.4 ölçütü yalnızca hukuki anlaşmalar, finansal işlemler, test yanıtları ve kullanıcı kontrolündeki verilerin silinmesi için geçerlidir. 3.3.6 ölçütü ise kapsamı, iletişim formları, bülten kayıtları, yorum bölümleri, anket yanıtları, profil güncellemeleri, arama ayarları ve diğer tüm kullanıcı kontrolündeki veri girişleri dahil olmak üzere, herhangi bir biçimde kullanıcı girişi gönderimi gerektiren her sayfaya genişletir.

Geçer sayılan durumlar: Bir form, yukarıdaki üç mekanizmadan en az birini tutarlı şekilde uygularsa geçer. Nihai gönderimden önce bir onay sayfası, "Düzenle" seçeneği olan bir özet ekranı, hata düzeltme fırsatları sunan istemci tarafı veya sunucu tarafı doğrulama ya da açıkça iletilmiş bir geri alma süresi bu ölçütü karşılar.

Başarısız sayılan durumlar: Verileri, hiçbir doğrulama, gözden geçirme ekranı veya geri alma mekanizması olmadan, tek adımda düğmeye tıklandığı anda gönderen bir form bu ölçütte başarısız olur. Benzer şekilde, doğrulama yapan ancak yeniden gönderimden önce hataları düzeltme fırsatı sunmayan bir form da başarısız olur.

WCAG spesifikasyonu aynı anda üç mekanizmanın da kullanılmasını zorunlu kılmaz—herhangi birinin sağlanması yeterlidir. Ancak iki veya üç mekanizmanın bir arada kullanılması, derinlemesine savunma sağlar ve daha geniş bir kullanıcı ve bağlam yelpazesine hizmet eder.

Neden Önemlidir

Hata önleme yalnızca bir kullanılabilirlik inceliği değildir—girdi hatası riskinin engellilik veya durumsal kısıtlar nedeniyle yükseldiği kullanıcılar için temel bir erişilebilirlik gerekliliğidir.

Bilişsel ve öğrenme güçlükleri: Disleksi, DEHB veya hafıza bozuklukları olan kullanıcılar sıklıkla yazım hataları yapar, rakamları karıştırır veya çok alanlı karmaşık formların takibini kaybeder. Bir gözden geçirme mekanizması olmadan, iletişim formunda yanlış yazılmış bir e-posta adresi kaçırılmış bir yanıt anlamına gelebilir veya teslimat formuna yanlış girilen bir adres kaybolan paketlere neden olabilir. Bunlar uç örnekler değildir—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 veya nörolojik durumla yaşamaktadır.

Motor bozukluklar: Titremeleri olan, ince motor kontrolü sınırlı olan veya anahtar erişimi ya da sesli giriş yazılımına güvenen kullanıcılar, form gönderimlerini sıkça yanlışlıkla tetikler veya istenmeyen karakterler girer. Parkinson hastalığı olan ve karmaşık bir formu anahtar arayüzüyle dolaşan bir kullanıcı, istemeden eksik veya hatalı bir form gönderebilir. Geri alınabilirlik veya onay adımları olmadan bu hatalar kalıcı hale gelir.

Ekran okuyucu kullanıcıları: JAWS, NVDA veya VoiceOver ile gezinme yapan görme engelli kullanıcılar, gönderimden önce tamamlanmış bir formun görsel genel görünümüne, gören kullanıcıların sahip olduğu şekilde sahip olmayabilir. Ekran okuyucu tarafından sesli okunan bir onay ekranı veya özet, bu kullanıcılara verileri geri döndürülemez şekilde gönderilmeden önce son bir doğrulama şansı verir.

Düşük dijital okuryazarlık ve yaşlanan nüfus: Yaşlı yetişkinler ve dijital arayüzlere yeni kullanıcılar, özellikle yanlışlıkla gönderimlere karşı savunmasızdır. Açık dilli özetler içeren bir onay adımı, destek maliyetlerini ve kullanıcı hayal kırıklığını dramatik biçimde azaltan bir güvenlik ağı sağlar.

Gerçek dünya senaryosu: Bir vatandaşın bir işletme kaydı için uzun bir bürokratik form doldurduğu bir Türk e-devlet portalını düşünün. Vatandaş yanlışlıkla zorunlu bir alanı boş bırakır veya vergi kimlik numarasını hatalı girer ve form, herhangi bir gözden geçirme adımı olmadan hemen gönderilirse, hatayı ancak günler sonra resmi bir ret bildirimi aldığında fark edebilir. Nihai gönderimden önce girilen tüm verileri gösteren basit bir onay ekranı bunu tamamen önlemiş olurdu.

SEO ve kullanılabilirlik faydaları: Güçlü hata önleme uygulayan sayfalar, daha düşük form terk oranlarına, daha yüksek dönüşüm oranlarına ve daha iyi kullanıcı memnuniyeti skorlarına sahip olma eğilimindedir. Arama motorları giderek daha fazla kullanıcı deneyimi sinyallerini sıralamalara dahil etmekte ve form hatalarına bağlı yüksek hemen çıkma oranlarına sahip sayfalar, organik görünürlükte dolaylı olarak zarar görmektedir.

İlgili Axe-core Kuralları

WCAG 3.3.6, manuel test gerektirir çünkü hiçbir otomatik araç, belirli bir form gönderim akışının bu ölçütün geri alınabilirlik, hata kontrolü veya onay gerekliliklerini karşılayıp karşılamadığını belirleyemez. axe-core gibi otomatik erişilebilirlik tarayıcıları, tek tek ARIA özniteliklerinin, etiketlerin ve hata mesajlarının varlığını doğrulayabilir, ancak genel gönderim akışı mantığını, bir onay adımının varlığını veya bir geri alma mekanizmasının gerçekten işlevsel olup olmadığını değerlendiremez. Ölçüt, temelde etkileşim tasarımı ve kullanıcı deneyimi akışıyla ilgilidir—statik işaretlemeyle değil.

• 3.3.6 için özel bir axe-core kuralı yoktur. Axe-core ve benzeri motorlar, tek tek DOM öğelerini belirli öznitelik veya rol gerekliliklerine karşı test eder. Çok sayfalı bir formun, nihai gönderimden önce bir gözden geçirme adımı içerip içermediğini belirlemek, uygulamanın gezinme akışını ve sunucu tarafı davranışını anlamayı gerektirir—statik analiz araçlarının erişemeyeceği bilgiler. Uygunluğu değerlendirmek için bir insan testçinin, gönderim yolculuğunun tamamını adım adım deneyimlemesi gerekir.
• Genel form kalitesini destekleyen ilgili kurallar (özellikle 3.3.6 için olmasa da): label (her girdinin ilişkili bir etiketi var), aria-required-attr (gerekli ARIA öznitelikleri mevcut) ve form-field-multiple-labels (girdilerin çelişen etiketleri yok) gibi kurallar, erişilebilir formların temelini oluşturur. Bunların geçmesi, anlamlı hata önleme için bir ön koşuldur, ancak bunların geçmesi 3.3.6 uyumluluğunu garanti etmez.
• Otomasyonun neden yetersiz kaldığı: Bir ödeme sayfasının otomatik taraması, tüm giriş alanlarının etiketleri olduğunu ve hata mesajlarının girdilerle programatik olarak ilişkilendirildiğini doğrulayabilir. Ancak "Gönder"e tıklamanın kullanıcıyı bir gözden geçirme ekranına götürüp götürmediğini, bir "İptal" seçeneğinin var olup olmadığını veya sistemin iptal bağlantısı içeren bir onay e-postası gönderip göndermediğini belirleyemez. Bunlar, yalnızca insan değerlendirmesinin yanıtlayabileceği davranışsal ve süreçle ilgili sorulardır.

Nasıl Test Edilir

1. Temel olarak otomatik bir tarama çalıştırın: Form içeren tüm sayfaları taramak için axe DevTools, Lighthouse veya Accsible bileşeninin yerleşik denetim modunu kullanın. Bu araçlar 3.3.6 ihlallerini doğrudan işaretlemese de, eksik etiketleri, olmayan hata mesajlarını veya yanlış ilişkilendirilmiş doğrulama geri bildirimlerini tespit ederek bir temel oluşturur. Manuel testlere geçmeden önce tüm otomatik bulguları çözün.
2. Sitedeki tüm gönderim formlarını belirleyin: Kullanıcı girdisini kabul eden ve gönderen her sayfanın—iletişim formları, kayıt formları, oturum açma formları, arama tercih formları, profil güncelleme sayfaları, yorum bölümleri, bülten kayıtları ve çok adımlı sihirbazlar dahil—tam bir envanterini oluşturun. Her biri bağımsız olarak test edilmelidir.
3. Kasıtlı hatalarla mutlu yolu test edin: Her formda, bilerek yanlış, eksik veya bozuk veriler girin (örneğin, geçersiz bir e-posta adresi, harf içeren bir telefon numarası, boş bırakılan zorunlu alanlar). Formu gönderin ve gözlemleyin: Sayfa gönderimi engelleyip hata mesajları sağlıyor mu? Hata mesajları doğru alanlarla ilişkilendirilmiş mi? Kullanıcının düzeltme yapıp yeniden göndermesi için net bir fırsat var mı?
4. Onay veya gözden geçirme mekanizmalarını test edin: Doğrulamayı geçen formlar için, formu geçerli verilerle doldurun ve gönderin. Veriler geri döndürülemez şekilde gönderilmeden önce bir onay ekranı, özet iletişim kutusu veya gözden geçirme adımı görünüp görünmediğini gözlemleyin. Gözden geçirme adımının, kullanıcının geri dönüp girdileri düzenlemesine izin verdiğini doğrulayın.
5. Gönderim sonrası geri alınabilirliği test edin: Başarılı bir gönderimden sonra, bir iptal, geri alma veya geri çekme mekanizmasının olup olmadığını kontrol edin. Bu, bir onay e-postasındaki "Gönderimi iptal et" bağlantısı, bir yönetim alanındaki kuyruk yönetimi ekranı veya geri alma eylemi içeren uygulama içi bir bildirim olabilir. Mekanizmanın çalıştığını ve kullanıcılara açıkça iletildiğini doğrulayın.
6. NVDA + Firefox ile ekran okuyucu testi: NVDA ve Firefox kullanarak her forma gidin. Tüm alanlar arasında sekme ile gezin, veri girin ve formu gönderin. Hata mesajlarının göründüklerinde duyurulduğunu, gözden geçirme ekranının (varsa) belge sırasına göre tamamen okunabilir olduğunu ve onay ekranındaki tüm etkileşimli denetimlerin (düzenle düğmeleri, onayla düğmeleri, iptal düğmeleri) klavye ile erişilebilir ve düzgün etiketlenmiş olduğunu doğrulayın.
7. VoiceOver + Safari (macOS/iOS) ile ekran okuyucu testi: Yukarıdaki süreci Safari’de VoiceOver kullanarak tekrarlayın. Dinamik içerik güncellemelerine özellikle dikkat edin—doğrulama hataları sayfa yeniden yüklenmeden JavaScript ile dinamik olarak görünüyorsa, VoiceOver’ın bunları kullanıcı sayfayı elle keşfetmek zorunda kalmadan duyurabilmesi için canlı bölgeler (aria-live) aracılığıyla yüzeye çıkarıldıklarını doğrulayın.
8. Yalnızca klavye ile test: Fare kullanmadan, yalnızca Tab, Shift+Tab, Enter ve Space tuşlarını kullanarak tüm form gönderim akışında gezinin. Gözden geçirme ekranlarındaki düzenle, geri, onayla ve iptal et düğmeleri dahil olmak üzere her etkileşimli öğenin, işaretçi aygıtı olmadan erişilebilir ve kullanılabilir olduğunu doğrulayın.

Nasıl Düzeltilir

Doğrulama veya Gözden Geçirme Olmayan İletişim Formu — Hatalı

<!-- 3.3.6’da başarısız: doğrulama yok, gözden geçirme yok, geri alma yok; anında gönderim -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Doğrulama ve Onay Adımı Olan İletişim Formu — Doğru

<!-- Adım 1: Gönderimden önce istemci tarafı doğrulama içeren form -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Gözden geçirme düğmesi, nihai gönderimden önce bir onay özetini tetikler -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Adım 2: Doğrulama geçtikten sonra gösterilen onay/gözden geçirme ekranı -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Düzenleme seçeneği, 'nihai işlemden önce geri alınabilir/düzeltilebilir' gerekliliğini karşılar -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Özet Adımı Olmayan Çok Adımlı Sihirbaz — Hatalı

<!-- 3.3.6’da başarısız: kullanıcıya önceki adımları gözden geçirme imkânı vermeden son adım doğrudan gönderiyor -->
<form action='/register' method='post'>
  <!-- 3 / 3. Adım — 1 ve 2. adımları gözden geçirme imkânı yok -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Son Gözden Geçirme Adımı Olan Çok Adımlı Sihirbaz — Doğru

<!-- 4 / 4. Adım: Nihai gönderimden önce özet gözden geçirme -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Kullanıcı tüm verileri gözden geçirdikten sonra nihai gönderim -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Anında Gönderim ve Geri Alma Olmayan Form — Hatalı

<!-- 3.3.6’da başarısız: yorumu, geri alma veya onay olmadan anında siliyor -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Onay İletişim Kutulu Yıkıcı İşlem — Doğru

<!-- 3.3.6’da geçer: yıkıcı işlem yürütülmeden önce kullanıcı onay vermek zorunda -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Yaygın Hatalar

• Doğrulamayı uygulayıp ekran okuyuculara yansıtmamak: Hata mesajlarını, girdiye aria-describedby ile ilişkilendirmeden veya bir aria-live bölgesine enjekte etmeden, yalnızca CSS renk değişiklikleri veya simgelerle görsel olarak göstermek, görme engelli kullanıcıların hatayı hiç duymaması anlamına gelir—form, gerçekte eksik kalmışken başarılı şekilde gönderilmiş gibi görünür.
• 3.3.4 uyumluluğunu AAA için yeterli görmek: Ekipler genellikle yalnızca finansal veya hukuki formlar için hata önleme uygular (3.3.4’ü karşılayarak) ve tüm formların kapsandığını varsayar. 3.3.6 ölçütü, sitedeki her form için—bülten kayıtları, yorumlar ve profil güncellemeleri dahil—aynı korumaları gerektirir.
• Düzenleme yolu olmayan salt okunur bir onay ekranı sağlamak: Yalnızca gönderilmiş verileri gösteren ve sadece bir "Onayla" düğmesi sunan—geri dönüp hataları düzeltme yolu olmayan—bir gözden geçirme sayfası, ölçütün ruhunu tam olarak karşılamaz ve kullanıcıları, gözden geçirme sırasında bir hata fark ettiklerinde çaresiz bırakır.
• Tek onay mekanizması olarak window.confirm() kullanmak: Tarayıcıya özgü onay iletişim kutuları tüm kullanıcılar için erişilebilir değildir ve netlik için stillendirilemez veya yapılandırılamaz. Ayrıca yardımcı teknolojiler arasında tutarsız davranırlar. Bunun yerine uygun ARIA özniteliklerine sahip bir <dialog> öğesi kullanın.
• Doğrulama hatasında formun tamamını sıfırlayıp geçerli girdileri korumamak: Kullanıcı 10 alanlı bir formu bir hatayla gönderdiğinde ve form tüm alanları temizlediğinde, tüm verileri yeniden girmesi gerekir. Bu, özellikle motor engelli kullanıcılar veya bilişsel yorgunluğu olanlar için son derece zahmetlidir. Geçerli verileri her zaman koruyun ve dikkati yalnızca hatalı alanlara odaklayın.
• Hata özet mesajlarını görünüm alanının veya klavye odak sırasının dışında yerleştirmek: Başarısız bir gönderimden sonra sayfanın üst kısmına enjekte edilen bir hata özeti bandı, odağı formun ortasında olan kullanıcılar için hiçbir işe yaramaz. Özet kapsayıcısında aria-live='assertive' kullanın ve gönderim hatasında odağı programatik olarak buraya taşıyın.
• Onay düğmelerini "Tamam" veya "Evet" gibi belirsiz etiketlerle işaretlemek: Bir gözden geçirme ekranında düğmeler, ne olacağını açıkça ifade etmelidir. "Confirm and Send Message" (Mesajı Onayla ve Gönder) açık ve nettir; "OK" değildir—özellikle çevresindeki görsel bağlama sahip olmayan ekran okuyucu kullanıcıları için.
• Yalnızca sunucu tarafı doğrulamanın ölçütü karşıladığını varsaymak: İstemci tarafı doğrulama yoksa, her gönderimden önce kullanıcının bir hatayı öğrenmesi için sunucuya tam bir gidiş-dönüş gerekir. Yavaş bağlantılardaki kullanıcılar veya gönderim sırasında ağı kaybedenler, net bir hata geri bildirimi olmadan belirsiz bir durumda kalabilir.
• Geri alma mekanizmasını gerçekçi koşullarda test etmemek: Ekipler bazen bir onay e-postasında "iptal" seçeneği uygular ancak iptal bağlantısının erişilebilir olup olmadığını, süresi dolduktan sonra çalışıp çalışmadığını veya bağlantının ekran okuyucular tarafından kullanılabilir olup olmadığını hiç test etmez. Erişilemeyen bir geri alma mekanizması ölçütü karşılamaz.
• Gözden geçirme ekranlarında otomatik doldurma uç durumlarını ele almamak: Tarayıcı veya parola yöneticisi otomatik doldurma ile form alanlarını doldurduğunda, gözden geçirme ekranında gösterilen değerler, JavaScript gözden geçirme verilerini otomatik doldurma tamamlanmadan önce DOM’dan çekiyorsa, gerçekte gönderilenlerle eşleşmeyebilir. Değerleri her zaman gözden geçirme ekranını oluşturmadan hemen önce çekin, ilk sayfa yüklemesinde değil.

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

21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, Türkiye’de faaliyet gösteren geniş bir yelpazedeki kuruluş için zorunlu dijital erişilebilirlik yükümlülükleri getirir. Genelge, kapsamdaki kuruluşların asgari olarak WCAG 2.2 Seviye AA’ya uyum sağlamasını şart koşar. Açıkça kapsanan kuruluşlar arasında kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finansal kuruluşlar, hastaneler ve sağlık hizmeti sağlayıcıları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, lisanslı seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar yer alır.

WCAG 3.3.6, Seviye AAA ölçütüdür ve bu nedenle 2025/10 sayılı Genelge kapsamında doğrudan yasal bir gereklilik değildir. Ancak, Türk düzenleyici bağlamında önemi göz ardı edilmemelidir. Kapsamdaki kuruluş türlerinin birçoğu—özellikle bankalar, e-ticaret platformları ve sağlık hizmeti sağlayıcıları—hata önlemenin yalnızca iyi bir uygulama değil, hukuki ve etik bir zorunluluk olduğu yüksek riskli işlem formları işletir. Onay adımları veya hata düzeltme mekanizmaları olmayan bir Türk bankasının çevrimiçi para transfer formu, bir sağlık portalının randevu alma sistemi veya bir e-ticaret ödeme akışı, 3.3.6’yı hukuken uygulanabilir anlamda ihlal etmeyebilir, ancak engelli kullanıcılar için önemli zarar riskleri yaratır ve kurumu itibar ve operasyonel risklere maruz bırakır.

Ayrıca genelge, Türkiye’nin uyum sağladığı Avrupa Erişilebilirlik Yasası (EAA) çerçevesiyle tutarlı olarak, zaman içinde artan erişilebilirlik gerekliliklerine yönelik net bir gidişatı işaret eder. Bugün 3.3.6 gibi AAA ölçütlerini uygulayan kuruluşlar, gelecekteki düzenleyici sıkılaşmalara proaktif olarak hazırlanmış olur ve asgari uyumun ötesine geçen kapsayıcı tasarım taahhüdü sergiler. Özellikle yaşlanan nüfusa veya bilişsel ve motor bozuklukları orantısız derecede yüksek oranlarda yaşayan kullanıcılara hizmet veren özel hastaneler ve finansal kuruluşlar gibi varlıklar için, tüm formlarda 3.3.6’yı uygulamak, yasal statüsünden bağımsız olarak sağlam bir risk yönetimi kararıdır. Accsible’ın katman SDK’sı, hata mesajlarını yüzeye çıkarmaya, doğrulama durumlarını güçlendirmeye ve Türk kuruluşlarının erişilebilirlikte öncü olmaya çalışırken ek bir koruma katmanı olarak tamamlayıcı onay istemleri sağlamaya yardımcı olabilir.