WCAG 3.3.3: Hata Önerisi

Bu Kuralın Anlamı

WCAG 3.3.3 Hata Önerisi, Anlaşılabilirlik ilkesinin altında Seviye AA ölçütüdür. Doğrudan, hataların metinle tanımlanmasını gerektiren 3.3.1 (Hata Tanımlama) üzerine inşa edilir. Hata Önerisi daha da ileri gider: bir girdi hatası otomatik olarak tespit edildiğinde, öneri güvenliği veya içeriğin amacını tehlikeye atmadığı sürece, arayüz aynı zamanda kullanıcının bunu nasıl düzeltebileceğine dair bir öneri sunmalıdır.

Buradaki temel ayrım, hata tanımlama ile hata önerisi arasındadır. Kullanıcıya "Doğum tarihiniz geçersiz" demek tanımlamadır. Kullanıcıya "Doğum tarihiniz geçersiz — lütfen tarihi GG/AA/YYYY formatında girin" demek bir öneridir. Her ikisi de kendi ölçütleri kapsamında gereklidir, ancak Hata Önerisi, mümkün olan her yerde hata mesajına uygulanabilir, düzeltici bir yönlendirmenin eşlik etmesini zorunlu kılar.

Bu ölçüt, bir girdi hatası otomatik olarak tespit edildiğinde geçerlidir — yani, istemci tarafı veya sunucu tarafı doğrulama mantığı, gönderilen veya girilen bir değerin beklenen ölçütleri karşılamadığını belirlediğinde. Tüm form kontrolleri için geçerlidir: metin girişleri, seçim kutuları (select), onay kutuları, radyo düğmeleri, tarih seçiciler, dosya yükleme alanları ve kullanıcı verisi toplayan her türlü etkileşimli bileşen.

Geçer sayılan durumlar: Hata mesajı metin olarak sunulur (yalnızca renk veya ikonla değil), hatalı alanı açıkça tanımlar ve bunu nasıl düzelteceğine dair spesifik bir yönlendirme sağlar. Örneğin: yalnızca "Geçersiz parola" yerine "Parola en az 8 karakter olmalı ve bir büyük harf içermelidir." Öneri, alanın yakınında görünmeli, programatik olarak o alanla ilişkilendirilmiş olmalı (aria-describedby veya benzeri ile) ve yardımcı teknolojiler tarafından algılanabilir olmalıdır.

Başarısız sayılan durumlar: Neyin yanlış olduğunu veya nasıl düzeltileceğini açıklamadan yalnızca bir hata oluştuğunu belirten her türlü hata mesajı. "Hata", "Geçersiz giriş" veya "Zorunlu alan" gibi genel mesajlar, ek bağlam olmadan bu ölçütte başarısız olur. Yalnızca kırmızı kenarlık veya uyarı ikonu ile, açıklayıcı metin olmadan iletilen hatalar da başarısızdır.

Tanımlanmış istisnalar: Ölçüt, önerinin gerekli olmadığı iki açık istisna içerir. Birincisi, öneri sağlamak güvenliği tehlikeye atacaksa — örneğin, bir giriş formunda parolanın neden başarısız olduğunu (yanlış parola mı, yanlış kullanıcı adı mı) ayrıntılı açıklamak kaba kuvvet saldırılarına yardımcı olabileceği için. İkincisi, öneri sağlamak içeriğin amacını tehlikeye atacaksa — örneğin, doğru cevabın açıklanmasının değerlendirme amacını boşa çıkaracağı bir eğitim sınavında. Bu istisnalar dardır ve standart form bağlamlarında gereklilikten kaçınmak için kullanılmamalıdır.

Neden Önemlidir

Hata Önerisi vardır çünkü formları doldurmak, kullanıcıların web üzerinde gerçekleştirdiği bilişsel açıdan en zorlayıcı faaliyetlerden biridir ve aynı zamanda en sonuç doğurucu olanlardan biridir — ödeme formlarında, devlet yardımı başvurularında, tıbbi ön kabul formlarında veya bankacılık portallarında yapılan hatalar, neyin yanlış gittiğini veya nasıl toparlanacağını anlayamayan kullanıcılar için gerçek dünyada sonuçlar doğurabilir.

Bilişsel engeller: Disleksi, DEHB, öğrenme güçlüğü veya sınırlı okuryazarlığı olan kullanıcılar, muğlak hata mesajlarını çözümlemekte ve bunları belirli alan veya gerekli formatla ilişkilendirmekte zorlanabilir. Açık bir düzeltici öneri olmadan formu tamamen terk edebilir veya yanlış bilgi gönderebilirler. Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık her 6 kişiden 1’i — 1,3 milyardan fazla insan — bir tür engelle yaşamaktadır ve bilişsel engeller en yaygın fakat en az karşılanan kategoriler arasındadır.

Kör ve az gören kullanıcılar: Ekran okuyucu kullanıcıları, doğrulama hatalarını anlamak için tamamen metin açıklamalarına güvenir. Bir hata mesajı yalnızca "Geçersiz" deyip hiçbir öneri sunmadığında, kullanıcı bu alan için "geçersiz"in ne anlama geldiğini belirleyecek hiçbir mekanizmaya sahip değildir. Beklenen formatı çıkarsamak için bitişik etiketlere, yer tutucu metne veya görsel biçimlendirme ipuçlarına göz atamazlar. aria-describedby aracılığıyla girdiye programatik olarak bağlanmış net bir öneri, bilgi için tek güvenilir kanaldır.

Motor engelli kullanıcılar: Anahtar erişimi, sesle kontrol veya alternatif giriş cihazlarına güvenen kullanıcılar, form doldururken önemli fiziksel çaba harcar. Ne değişmesi gerektiğini anlamadan bir formu başarısız bir gönderimden sonra yeniden dolaşmak zorunda kalmak, orantısız bir yük getirir. Net öneriler, yeniden giriş yükünü ve başarısız gönderim döngülerinin sayısını azaltır.

Ana dili olmayan konuşurlar ve yaşlı kullanıcılar: Formun diline akıcı olmayan veya web alışkanlıkları konusunda daha az deneyimli kullanıcılar da açık düzeltici önerilerden önemli ölçüde fayda sağlar. "Telefon numaranızı boşluk veya tire olmadan girin, örn. 05321234567" gibi bir mesaj, aksi takdirde formu hiçbir zaman başarıyla tamamlayamayabilecek kullanıcılar için belirsizliği ortadan kaldırır.

Gerçek dünya senaryosu: Bir e-devlet portalı üzerinden sosyal yardım başvurusunda bulunan bir Türkiye Cumhuriyeti vatandaşını düşünün. Başvuru, belirli bir 11 haneli formata sahip bir T.C. Kimlik Numarası gerektirir. Kullanıcı 10 hane girer ve yalnızca "TC Kimlik Numarası hatalı" mesajını alırsa, bilişsel engelli bir kullanıcı, yaşlı bir kullanıcı veya ekran okuyucu kullanıcısı, numaranın çok kısa mı olduğu, geçersiz bir karakter mi içerdiği yoksa bir biçimlendirme sorunu mu olduğu konusunda fikir sahibi olmayabilir. "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" ifadesini eklemek, belirsizliği anında giderir ve kullanıcının kendi kendini düzeltmesini sağlar.

Kullanılabilirlik ve dönüşüm faydaları: Erişilebilirliğin ötesinde, form terk oranı kritik bir iş metriğidir. Araştırmalar, belirsiz hata mesajlarının, kullanıcıların e-ticaret ödeme ve kayıt akışlarını terk etmesinin başlıca nedenleri arasında olduğunu sürekli göstermektedir. Spesifik, uygulanabilir hata önerileri, form terk oranlarını azaltır ve tüm kullanıcılar için tamamlama oranlarını artırır — bu ölçütü yalnızca bir erişilebilirlik gereksinimi değil, aynı zamanda güçlü bir iş gerekçesi haline getirir.

İlgili Axe-core Kuralları

WCAG 3.3.3, otomatik araçlar hata mesajı metninin kalitesini veya tamlığını değerlendiremediği için manuel test gerektirir. Otomatik bir tarayıcı, bir hata mesajının var olduğunu ve programatik olarak bir form alanıyla ilişkilendirildiğini tespit edebilir, ancak mesajın gerçekten yararlı bir düzeltici öneri sağlayıp sağlamadığını belirleyemez. Bu, metnin spesifik, uygulanabilir ve kullanıcıyı geçerli bir girişe yönlendirmek için yeterli olup olmadığını değerlendirmek üzere insan yargısı gerektirir.

• Manuel inceleme — hata mesajı içeriğinin kalitesi: Test uzmanları, her doğrulama koşulunu manuel olarak tetiklemelidir (boş bir zorunlu alan göndermek, veriyi yanlış formatta girmek, karakter sınırlarını aşmak vb.) ve ortaya çıkan her hata mesajını değerlendirmelidir. Test uzmanı şu soruyu sorar: Bu mesaj, kullanıcıya yalnızca bir hata oluştuğunu değil, aynı zamanda bunu düzeltmek için tam olarak ne yapması gerektiğini söylüyor mu? Mesaj genelse ("Geçersiz", "Hata", "Lütfen bu alanı kontrol edin"), programatik olarak açığa çıkarılmış olsa bile 3.3.3’te başarısız olur.
• Manuel inceleme — programatik ilişkilendirme: Test uzmanları, hata önerisi metninin ilgili giriş alanına aria-describedby, aria-live bölgeleri veya satır içi ilişkilendirme kullanılarak programatik olarak bağlandığını doğrulamalıdır; böylece ekran okuyucular, ek bir gezinme gerektirmeden bunu duyurur. Bu, label ve aria-input-field-name gibi axe kurallarıyla kısmen örtüşür, ancak öneri metninin kendisi bu kurallar tarafından kontrol edilmez.
• Manuel inceleme — güvenlik istisnasının geçerliliği: Test uzmanları, güvenlik gerekçesiyle düzeltici önerileri atlayan (örneğin, giriş formları) herhangi bir formun gerçekten güvenlik istisnası kapsamına girip girmediğini ve bu istisnanın hassas olmayan alanlarda gereklilikten kaçınmak için kullanılmadığını doğrulamalıdır.
• Kısmen otomatik — label kuralı: axe-core’un label kuralı, form girişlerinin erişilebilir adlara sahip olduğunu kontrol eder, ancak hata mesajlarının düzeltici öneriler sağlayıp sağlamadığını kontrol etmez. Hata önerisi sorununu daha da ağırlaştıracak eksik etiketleri ortaya çıkarabilir ve etiket sorunlarını düzeltmek, etkili hata önerisi uygulaması için bir ön koşuldur.

Nasıl Test Edilir

1. Otomatik tarama temel seviyesi: Formu içeren sayfaya karşı axe DevTools veya Lighthouse çalıştırın. Form etiketleri, ARIA rolleri veya hata tanımlama (3.3.1) ile ilgili mevcut ihlalleri not edin. Bunlar, etkili hata önerisi için ön koşul olduklarından önce çözülmelidir. Otomatik taramalar eksik önerileri işaretlemez — yalnızca yapısal temel durumu ortaya koyar.
2. Her doğrulama koşulunu tetikleyin: Her form alanı için, mümkün olan her hata durumunu kasıtlı olarak tetikleyin: boş bir zorunlu alan gönderin, veriyi yanlış formatta girin (yanlış tarih formatı, geçersiz e-posta, çok kısa parola, sayısal alana sayısal olmayan değer) ve varsa karakter sınırlarını aşın. Görünen her hata mesajını belgeleyin.
3. Öneri kalitesini değerlendirin: Her hata mesajı için şu soruları sorun: (a) Belirli alanı tanımlıyor mu? (b) Neyin yanlış olduğunu açıklıyor mu? (c) Girişi nasıl düzelteceğine dair uygulanabilir bir yönlendirme sağlıyor mu? Üçüne de yanıt veren bir mesaj 3.3.3’ü geçer. Yalnızca (a)’ya yanıt veren bir mesaj 3.3.1’i geçer, ancak 3.3.3’te başarısız olur.
4. NVDA + Firefox ile ekran okuyucu testi: Sekme ile forma gidin. Geçersiz bir değer girin. Gönderin veya odağı alandan uzaklaştırın. NVDA’nın ne duyurduğunu dinleyin. Hata önerisi metninin, kullanıcıdan bunu manuel olarak aramasını gerektirmeden (aria-live bölgesi veya odağın hataya taşınması yoluyla) otomatik olarak okunduğunu doğrulayın.
5. VoiceOver + Safari (macOS/iOS) ile ekran okuyucu testi: Aynı adımları uygulayın. VO+Sağ ok ile alanı ve ilişkili açıklamasını okuyun. Öneri metninin, atlanabilecek yalnızca yakın metin olarak değil, alanın erişilebilir açıklamasının bir parçası olarak duyurulduğunu doğrulayın.
6. JAWS + Chrome ile ekran okuyucu testi: Hatalı bir form gönderdikten sonra, JAWS’un hata önerisini ya odak yönetimi (odak hata özetine taşınır) ya da aria-live bölge güncellemeleri aracılığıyla okuduğunu doğrulayın. JAWS sanal imlecini kullanarak alana gidin ve önerinin alanın açıklamasının bir parçası olduğunu doğrulayın.
7. Yalnızca klavye ile gezinme: Ekran okuyucu olmadan, yalnızca Sekme, Shift+Sekme ve Enter kullanarak formda gezinin. Hata önerilerinin, başarısız bir gönderimden sonra alan odak aldığında görünüm alanında (viewport) görünür olduğunu, ekran dışında gizlenmediğini veya diğer öğeler tarafından örtülmediğini doğrulayın.
8. Güvenlik istisnalarını doğrulayın: Giriş ve kimlik doğrulama formları için, spesifik önerilerin atlanmasının kasıtlı ve belgelenmiş olduğunu ve güvenlik istisnasının yalnızca asgari gerekli alanlarla sınırlı olduğunu doğrulayın.

Nasıl Düzeltilir

Genel hata mesajı — Yanlış

<!-- Hata mesajı sorunun nasıl düzeltileceğine dair bir öneri sunmuyor -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Genel hata mesajı — Doğru

<!-- aria-describedby, öneri metnini girdiye bağlar;
     öneri, tam olarak hangi formatın beklendiğini açıklar -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Format rehberi olmayan parola doğrulaması — Yanlış

<!-- Kullanıcıya parolanın yanlış olduğu söyleniyor ama neden veya nasıl düzeltileceği söylenmiyor -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Format rehberi olmayan parola doğrulaması — Doğru

<!-- Öneri, parolanın tam olarak ne içermesi gerektiğini listeler
     ve kullanıcının tahmin etmeden kendi kendini düzeltmesini sağlar -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Format hatası belirsiz tarih alanı — Yanlış

<!-- Hangi tarih formatının beklendiğine dair hiçbir bilgi yok -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Format hatası belirsiz tarih alanı — Doğru

<!-- Öneri, gerekli formatı belirtir ve
     tüm belirsizliği ortadan kaldıran somut bir örnek verir -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Sunucu tarafı hata özetli çok alanlı form — Yanlış

<!-- Hata özeti var ancak bağlantılar, önerileri
     tek tek alanlarla ilişkilendirmiyor ve mesajlar muğlak -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Sunucu tarafı hata özetli çok alanlı form — Doğru

<!-- Hata özeti, bağlantılı ve spesifik öneriler içerir;
     her liste öğesi ilgili alana bağlanır;
     satır içi hatalar ayrıca her alanın yanında görünür -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Yaygın Hatalar

• Hata önerileri yerine placeholder kullanmak: Yer tutucu metin, kullanıcı yazmaya başlar başlamaz kaybolur ve ekran okuyucular tarafından bir hata olarak güvenilir şekilde duyurulmaz. Bir hata oluştuğunda hangi formatın gerektiğini iletmek için asla yalnızca yer tutucu metne güvenmeyin.
• Hata mesajlarını yalnızca birkaç saniye sonra kaybolan bir tost bildiriminde göstermek: Geçici bildirimler tüm kullanıcılar tarafından algılanamaz — ekran okuyucu kullanıcıları duyuruyu kaçırabilir ve mesaj, yavaş okuyan bir kullanıcı işleyemeden kaybolur. Hata önerileri, hata düzeltilene kadar kalıcı olmalıdır.
• Öneri metnine işaret eden aria-describedby olmadan aria-invalid='true' kullanmak: aria-invalid ayarlamak, bir alanda hata olduğunu bildirir, ancak öneri öğesine bağlanan aria-describedby olmadan ekran okuyucular, alan odaklandığında öneri metnini okumaz.
• Öneriyi yalnızca görsel tasarımda (örn. üzerine gelince görünen bir araç ipucunda) sunmak ve DOM’da sunmamak: Yalnızca üzerine gelince görünen araç ipuçları, klavye kullanıcıları ve ekran okuyucu kullanıcıları için erişilebilir değildir. Öneri metni DOM’da bulunmalı ve programatik olarak alanla ilişkilendirilmelidir.
• Hangi alanda hata olduğunu belirtmek için yalnızca renk veya ikonografi kullanmak: Kırmızı kenarlık veya uyarı ikonu bir hata önerisi sayılmaz. Öneri, düzeltici eylemi açıklayan bir metin açıklaması olmalıdır, görsel bir gösterge değil.
• Sorunu tanımlayan ancak çözümü tanımlamayan öneriler yazmak: "Parolanız çok kısa" hatayı tanımlar ancak bir çözüm önermez. "Parolanız en az 8 karakter olmalıdır" gerekli düzeltici yönlendirmeyi sağlar. 3.3.3 uyumu için her iki parça da gereklidir.
• Güvenlik istisnasını çok geniş uygulamak: Güvenlik istisnası, öneri sağlamanın gerçekten güvenliği tehlikeye attığı durumlarla sınırlı olarak dar bir şekilde uygulanır — tipik olarak kimlik doğrulama alanlarıyla sınırlıdır. İsimler, adresler veya telefon numaraları gibi standart form alanlarında, genel hatalar için geçerli değildir.
• Hata önerisini gönder düğmesinden sonra veya alandan çok uzakta yerleştirmek: Hata önerileri, tanımladıkları alana görsel ve programatik olarak yakın olmalıdır. Tüm hataları, her alanda satır içi öneriler olmadan uzun bir formun altına yerleştirmek, kullanıcıları bağlam değiştirmeye ve hangi önerinin hangi alana ait olduğunu hatırlamaya zorlar.
• Başarısız sunucu tarafı gönderimden sonra odağı hata özetine taşımamak: Bir sayfa başarısız bir gönderimden sonra yeniden yüklendiğinde, odak genellikle sayfanın en üstüne döner. Odağı programatik olarak hata özetine veya hatalı ilk alana taşımadan, ekran okuyucu kullanıcıları neyin yanlış gittiğini keşfetmek için tüm sayfada gezinmek zorunda kalır.
• "Lütfen girdinizi kontrol edin" veya "Bir şeyler ters gitti" gibi muğlak dil kullanmak: Bu mesajlar, neyin yanlış olduğu veya nasıl düzeltileceği hakkında hiçbir bilgi vermez. Her hata önerisi, alana ve ihlal edilen spesifik doğrulama kuralına özgü olmalıdır.

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

Türkiye’nin erişilebilirlik alanı, 21 Haziran 2025’te 32933 sayılı Resmî Gazete’de yayımlanan 2025/10 sayılı Cumhurbaşkanlığı Genelgesi ile önemli ölçüde ilerlemiştir. Bu genelge, Aile ve Sosyal Hizmetler Bakanlığı tarafından verilen Erişilebilirlik Logosunu almak isteyen kuruluşlar için WCAG 2.2 ile uyumlu, Seviye AA düzeyinde zorunlu web ve mobil erişilebilirlik gereklilikleri getirir.

Seviye AA ölçütü olan WCAG 3.3.3 Hata Önerisi, bu zorunlu gereklilik kapsamına girer. Kapsam dahilindeki ve kayıt, ödeme, hizmet başvurusu veya hesap yönetimi için form işleten her kuruluş, hata mesajlarının yalnızca hataları tanımlamakla kalmayıp, bu ölçütte açıklandığı şekilde uygulanabilir düzeltici öneriler de sağladığından emin olmalıdır.

2025/10 sayılı Cumhurbaşkanlığı Genelgesi kapsamındaki kuruluşlar geniş bir sektör yelpazesine yayılır. Kamu kurum ve kuruluşları uyum sağlamak zorundadır; bu da tüm e-devlet portallarının (örn. e-Devlet hizmetleri, belediye portalları, yardım başvuru sistemleri) uyumlu hata önerisi uygulamaları sunması gerektiği anlamına gelir. Birçok kamu hizmetinin vatandaşlardan karmaşık kişisel veriler — kimlik numaraları, adres kodları, vergi numaraları — talep ettiği düşünüldüğünde, net hata önerileri bu bağlamda özellikle kritiktir.

Bankalar ve finans kuruluşları kapsam dahilindedir; buna çevrim içi bankacılık platformları, yatırım hesabı kayıt formları ve kredi başvuru portalları dahildir. Bu formlar rutin olarak hassas ve kesin formatlı veriler toplar ve düzeltici önerilerin yokluğu, engelli müşteriler için gerçek engeller ve potansiyel hukuki riskler yaratır.

Hastaneler ve sağlık hizmeti sağlayıcıları da uyum sağlamak zorundadır; bu kapsamda hasta kayıt sistemleri, randevu alma formları ve sigorta talep portalları yer alır. Tıbbi formlar genellikle karmaşık alan gereklilikleri içerir (tanı kodları, sigorta poliçe numaraları, hassas tarih formatları) ve net hata önerileri, özellikle yaşlı ve bilişsel engelli hastalar için son derece önemlidir.

200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri kapsam dahilindedir; buna büyük operatörlerin müşteri portalları, SIM kayıt formları ve hesap yönetim arayüzleri dahildir. E-ticaret platformları — ödeme akışları ve hesap kayıtları dahil — uyum sağlamak zorundadır; bu da Hata Önerisi’ni, iş operasyonlarının merkezinde yer alan ürün ve sepet yönetimi formları için doğrudan ilgili hale getirir.

Seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar da kapsam dahilindedir. Bu kuruluşlar tarafından işletilen rezervasyon formları, kayıt başvuruları ve ödeme arayüzleri, 3.3.3 dahil Seviye AA standartlarını karşılamalıdır.

Pratik uyum açısından, Erişilebilirlik Logosu’nu hedefleyen kuruluşlar, WCAG 3.3.3’ü herhangi bir erişilebilirlik değerlendirmesi sırasında temel bir denetim noktası olarak ele almalıdır. Tüm form doğrulama akışlarının — istemci tarafı ve sunucu tarafı hata durumları dahil — manuel test edilmesi gerekir ve düzeltici önerilerin kasıtlı olarak atlandığı alanlar için güvenlik istisnası gerekçesinin belgelenmesi gerekir. Seviye AA gerekliliklerinin, Hata Önerisi dahil, karşılanamaması, logonun verilmesini engelleyecek ve genelge kapsamında kapsanan kuruluşları idari sonuçlara maruz bırakabilecektir.