WCAG 3.3.1: Hata Tanımlama

Bu Kuralın Anlamı

WCAG 3.3.1 Hata Tanımlama, Anlaşılabilir ilkesinin altında Seviye A başarı ölçütüdür. Şöyle der: "Bir girdi hatası otomatik olarak tespit edilirse, hatalı olan öğe tanımlanır ve hata kullanıcıya metinle açıklanır." Pratikte bu, web siteniz veya uygulamanız kullanıcı girdisini ne zaman otomatik olarak doğruluyorsa — form gönderiminde, alan odak kaybında (blur) veya gerçek zamanlı olarak — bir hata tespit edildiğinde iki şeyin gerçekleşmesi gerektiği anlamına gelir: hatayı içeren belirli alan veya kontrol açıkça tanımlanmalı ve hatanın niteliği yalnızca renk, ikon veya sesle değil, gerçek metin içeriği kullanılarak iletilmelidir.

Bu ölçüt, kullanıcılardan girdi alındığı ve doğrulamanın otomatik olarak yapıldığı her duruma uygulanır. Buna <input>, <select>, <textarea> gibi HTML form öğeleri ile ARIA kullanılarak oluşturulmuş özel etkileşimli bileşenler dahildir. JavaScript ile tetiklenen istemci tarafı doğrulamayı, required, pattern, minlength ve type gibi öznitelikleri kullanan yerel tarayıcı kısıtlama doğrulamasını ve sayfa yeniden yüklendikten sonra sunucu tarafı doğrulama sonuçlarının gösterilmesini veya dinamik olarak DOM’a enjekte edilmesini kapsar.

Başarılı sayılmak için: (1) hatalı olan her alan, yardımcı teknolojilerin bunu duyurabilmesi için programatik olarak bir hata mesajıyla ilişkilendirilmelidir — genellikle aria-describedby veya aria-errormessage aracılığıyla; (2) hata mesajı, arayüzde görünür olan düz metin olmalıdır (gören kullanıcılardan gizlenmemelidir); ve (3) metin, yalnızca bir şeylerin yanlış gittiğini değil, neyin yanlış gittiğini açıkça açıklamalıdır. Örneğin, "E-posta adresi zorunludur" geçerli bir hata açıklamasıdır; yalnızca kırmızı bir kenarlık veya metin alternatifi olmayan bir ünlem ikonu göstermek ise başarısızlıktır.

Başarısızlık şu durumlarda ortaya çıkar: hatalar yalnızca renk değişiklikleriyle belirtiliyorsa (metin olmadan kırmızı kenarlık), hatalar yalnızca role="alert" aracılığıyla duyuruluyor ancak hangi alanın etkilendiği belirtilmiyorsa, hata mesajı metni boş veya çok genelse (örneğin, "Geçersiz girdi"), ya da hata mesajları DOM’da mevcut ancak ilgili alanla programatik olarak ilişkilendirilmemişse ve bu nedenle ekran okuyucular bunları ilişkilendiremiyorsa.

WCAG 3.3.1, otomatik tespit yapılmadığı durumlarda uygulanmaz — örneğin, bir form gönderildiğinde sunucu yalnızca sayfayı yeniden yüklüyor ve neyin yanlış gittiğine dair hiçbir işaret vermiyorsa, bu ayrı bir kullanılabilirlik sorunudur ancak bu ölçütün katı kapsamının dışına düşer. Ancak, sisteminiz otomatik tespit yapıyorsa (ki neredeyse tüm modern formlar yapar), ölçüt tamamen kapsam dahilindedir. Ölçütün kendisinde belirli girdi türleri veya kullanım senaryoları için tanımlanmış herhangi bir istisna yoktur.

Neden Önemli

Hata tanımlama, birden fazla engelli kullanıcı grubunu doğrudan ve önemli ölçüde etkiler. NVDA, JAWS veya VoiceOver gibi ekran okuyuculara güvenen kör ve az gören kullanıcılar için kırmızı bir kenarlık veya uyarı ikonu hiçbir şey ifade etmez. Bir hata mesajı gerçek metin olarak mevcut değilse ve hatalı alanla programatik olarak ilişkilendirilmemişse, ekran okuyucu bunu duyurmaz ve kullanıcı, neden başarısız olduğunu anlamadan formu tekrar tekrar gönderebilir. Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık 2,2 milyar kişinin bir tür görme bozukluğu vardır ve milyonlarca kişi web içeriğiyle etkileşim kurmak için her gün yardımcı teknolojilere güvenmektedir.

Bilişsel engelleri olan kullanıcılar — disleksi, dikkat eksikliği bozukluğu ve hafıza bozuklukları dahil — "Bir şeyler ters gitti" gibi muğlak hata mesajlarıyla büyük engellerle karşılaşır. Bu kullanıcılar, hangi alanın düzeltmeye ihtiyaç duyduğunu ve doğru formatın veya değerin ne olması gerektiğini tam olarak söyleyen net, açıklayıcı hata metninden büyük ölçüde fayda sağlar. Örneğin, "Geçersiz tarih" yerine "Doğum tarihi GG/AA/YYYY formatında olmalıdır" gibi bir mesaj çok daha uygulanabilirdir.

Motor engelleri olan ve klavye veya anahtarlama cihazlarıyla gezinmek zorunda olan kullanıcılar, bir formda ilerlerken önemli çaba harcar. Hata belirsiz veya tanımlanmamış olduğunda, sorunu bulmak için formun tamamını yeniden dolaşmak zorunda kalırlar; bu da formu tamamlama sürecinin bilişsel ve fiziksel maliyetini büyük ölçüde artırır. Net hata tanımlaması, bu kullanıcıların doğrudan sorunlu alana atlamasına olanak tanır.

Şu gerçek dünya senaryosunu düşünün: Engelli aylığına başvurmak için bir e-devlet hizmet portalına kayıt olmaya çalışan bir Türkiye Cumhuriyeti vatandaşı. Form, belirli bir formatta T.C. kimlik numarası gerektiriyor. Kör olan kullanıcı kimlik numarasını giriyor. Gönderimden sonra form, kırmızıyla vurgulanmış alanlarla yeniden yükleniyor ancak hiçbir metin hatası ilişkilendirilmemiş. Ekran okuyucu yalnızca alan etiketlerini tekrar duyuruyor — kullanıcı neyin yanlış gittiğini veya hangi alanın sorunlu olduğunu bilmiyor. Süreci tamamen bırakıyor ve kritik bir kamu hizmetine erişimini kaybediyor. WCAG 3.3.1 tam olarak bu durumu önlemek için tasarlanmıştır.

Erişilebilirliğin ötesinde, net hata tanımlaması tüm kullanıcılar için dönüşüm oranlarını ve kullanılabilirliği artırır. UX araştırmalarındaki çalışmalar, açıklayıcı satır içi hata mesajlarının form terk oranını azalttığını tutarlı şekilde göstermektedir. SEO açısından, daha uzun sitede kalma süresi ve başarılı form gönderimleri gibi iyileştirilmiş kullanıcı etkileşimi sinyalleri, zaman içinde arama sıralamasını olumlu yönde etkiler.

İlgili Axe-core Kuralları

WCAG 3.3.1, tam doğrulama için manuel test gerektirir. Bunun nedeni, otomatik araçların yapısal kalıpların varlığını veya yokluğunu (örneğin aria-describedby veya aria-errormessage) tespit edebilmesi, ancak bir hata mesajının metin içeriğinin anlamlı, doğru veya kullanıcıya hatayı anlaması ve düzeltmesi için yeterli olup olmadığını değerlendirememesidir. Otomatik bir araç, bir role="alert" öğesinin var olduğunu görür; ancak "4. satırda hata" mesajının bir ekran okuyucu kullanıcısına doğrulama hatasını yeterince açıklayıp açıklamadığına karar veremez.

• aria-required-attr: Bu axe-core kuralı, belirli ARIA rolleri olan öğelerin tüm gerekli ARIA özniteliklerine sahip olup olmadığını kontrol eder. Yalnızca hata tanımlama kuralı olmasa da, bir hata durumundaki form alanı role="textbox" veya benzeri bir rol kullanıp gerekli özniteliklere sahip değilse, durum bilgisini yardımcı teknolojilere iletemeyebileceği için hata iletişimini zayıflatması bakımından önemlidir.
• aria-valid-attr-value: Bu kural, ARIA özniteliklerinin DOM’da var olmayan ID’lere referans verdiği durumları işaretler. Örneğin, bir alan aria-describedby="email-error" kullanıyor ancak id="email-error" olan bir öğe yoksa, ilişki kopar ve hata mesajı ekran okuyucular tarafından okunmaz. Bu, 3.3.1 için yaygın bir kalıp hatasıdır.
• Manuel değerlendirme gerekliliği: Test uzmanları, doğrulama hatalarını manuel olarak tetiklemeli ve ardından ekran okuyucu kullanarak şu hususları doğrulamalıdır: hatalı alan ad veya etiketle tanımlanıyor mu, hata açıklaması duyuruluyor mu, mesaj anlamlı ve uygulanabilir mi ve hata yalnızca metin dışı yollarla mı iletiliyor. Otomatik taramalar, kullanıcı etkileşim dizilerini simüle edemez veya mesaj metninin anlamsal kalitesini değerlendiremez; bu da bu ölçüt için insan yargısını vazgeçilmez kılar.

Nasıl Test Edilir

1. axe DevTools veya Lighthouse ile otomatik tarama: Doğrulama hatalarını tetiklemeden önce ve sonra formu içeren sayfada bir axe DevTools taraması çalıştırın. Özellikle bozuk aria-describedby veya aria-errormessage referansları, dinamik hata enjeksiyonu için kullanılan eksik role="alert" veya aria-live bölgeleri ve etiketleri eksik form alanları (bu da doğru hata ilişkilendirmesini engeller) ile ilgili ihlallere bakın. Lighthouse’ta, Erişilebilirlik denetiminde form ile ilgili ihlalleri kontrol edin. Otomatik raporun temiz olmasının 3.3.1 uyumluluğunu doğrulamadığını, yalnızca belirli yapısal hataları dışladığını unutmayın.
2. Manuel klavye ile gezinme testi: Yalnızca klavye kullanarak (Tab, Shift+Tab, Enter, Space), bilerek yanlış veya eksik değerlerle formu göndermeye çalışın. Şunları doğrulayın: odak, ilk hatalı alana veya yakınına taşınıyor mu, her hata mesajı görünüm alanında mı ve hata mesajları belirli alanı adıyla tanımlayıp sorunu düz metinle açıklıyor mu.
3. NVDA + Firefox ile ekran okuyucu testi: Formu Firefox’ta NVDA açıkken açın. Formu hatalarla gönderin. Dikkatle dinleyin: NVDA hangi alanda hata olduğunu duyuruyor mu? Hata açıklaması sesli okunuyor mu? Hatalı alana Tab ile girin — NVDA, alanın erişilebilir açıklamasının bir parçası olarak ilişkili hata mesajını okuyor mu? aria-live bölgeleri kullanılıyorsa, duyurunun gecikmediğini veya bastırılmadığını doğrulayın.
4. VoiceOver + Safari (macOS/iOS) ile ekran okuyucu testi: Aynı süreci Safari’de VoiceOver kullanarak tekrarlayın. Gönderimden sonra formu VO+Sağ Ok tuşlarıyla okuyun. Hata içeren her alanın, erişilebilir adında veya açıklamasında hata metnini içerdiğini doğrulayın. iOS’ta, dokunma ile gezinme ve kaydırma hareketleriyle test edin.
5. JAWS + Chrome ile ekran okuyucu testi: JAWS, Chrome’da çalışırken formu hatalarla gönderin. JAWS sanal imlecini kullanarak hatalı her form alanına gidin. Hata mesajı metninin, JAWS’in alanı okumasına dahil edildiğini doğrulayın. Ayrıca, bazı canlı bölge duyurularını bastıran form modunun davranışını da kontrol edin.
6. Renk ve metin dışı ipuçları denetimi: Her hata durumunu görsel olarak inceleyin. CSS’yi geçici olarak kaldırın veya devre dışı bırakın (tarayıcı geliştirici araçları veya bir bookmarklet kullanarak) ve hata tanımlamasının hâlâ DOM’da metin olarak mevcut olduğunu doğrulayın. Bu, hata iletişiminin yalnızca renk veya ikonografiye dayanmadığını doğrular.
7. Dinamik enjeksiyon kontrolü: Tek sayfa uygulamaları veya gerçek zamanlı doğrulamalı formlar için, bir hata tetiklendikten sonra DOM’u incelemek üzere tarayıcı geliştirici araçlarını kullanın. Hata mesajı öğesinin DOM’da var olduğunu, boş olmayan metin içerdiğini ve ilgili girdi tarafından aria-describedby veya aria-errormessage aracılığıyla referans verildiğini doğrulayın.

Nasıl Düzeltilir

Senaryo 1: Hatanın yalnızca renkle belirtilmesi — Yanlış

<!-- Başarısız: sınıf aracılığıyla kırmızı kenarlık eklenmiş, ilişkili hata metni yok -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- CSS, .input-error için border: 2px solid red ayarlıyor -->
<!-- DOM'da hiçbir hata mesajı metni oluşturulmuyor -->

Senaryo 1: Hatanın yalnızca renkle belirtilmesi — Doğru

<!-- Başarılı: hata metni mevcut, görünür ve input ile ilişkilendirilmiş -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid, hata durumunu yardımcı teknolojilere bildirir -->
<!-- aria-describedby, input'u ID'siyle hata mesajına bağlar -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

Senaryo 2: Alan tanımlaması olmadan genel hata özeti — Yanlış

<!-- Başarısız: bir özet uyarısı var ancak hangi alanların başarısız olduğu belirtilmiyor -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- Alan bazında hata mesajı yok; kullanıcı hangi alanın başarısız olduğunu belirleyemez -->

Senaryo 2: Alan tanımlaması olmadan genel hata özeti — Doğru

<!-- Başarılı: özet, hatalı alanları listeliyor ve her alanın satır içi hata metni var -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- aria-describedby ile ilişkilendirilmiş satır içi hata -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

Senaryo 3: Bozuk aria-describedby referansı — Yanlış

<!-- Başarısız: aria-describedby, DOM'da var olmayan bir ID'ye referans veriyor -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- id='username-msg' olan öğe hiç oluşturulmamış veya kaldırılmış -->
<!-- Ekran okuyucular hedef bulamaz ve açıklama için hiçbir şey duyurmaz -->

Senaryo 3: Bozuk aria-describedby referansı — Doğru

<!-- Başarılı: referans verilen öğe DOM'da mevcut ve ID'si eşleşiyor -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- Eşleşen ID'ye sahip öğe mevcut ve açıklayıcı metin içeriyor -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

Senaryo 4: Gerçek zamanlı doğrulama hatasının dinamik olarak enjekte edilmesi — Yanlış

<!-- Başarısız: hata DOM'a enjekte ediliyor ancak input ile ilişkilendirilmemiş; canlı bölge yok -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- Blur sonrası, JavaScript bu öğeyi ekliyor ancak input üzerinde aria-describedby yok -->
<div class='error-text'>Password is too short.</div>

Senaryo 4: Gerçek zamanlı doğrulama hatasının dinamik olarak enjekte edilmesi — Doğru

<!-- Başarılı: hata konteyneri DOM'da önceden (boş) mevcut, input onu referans veriyor; aria-live değişiklikleri duyuruyor -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Sayfa yüklenirken boş span mevcut; JavaScript metni doldurur ve hata durumunda aria-invalid='true' ayarlar -->
<span id='password-error' aria-live='polite'></span>
<!-- Blur olayında JavaScript: -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

Yaygın Hatalar

• DOM’da karşılık gelen hiçbir metin olmadan hataları belirtmek için yalnızca CSS sınıf değişiklikleri kullanmak (örneğin, border-color: red eklemek). Yalnızca renk, kör kullanıcılar veya renk körlüğü olan kullanıcılar tarafından algılanamaz ve hem 3.3.1 hem de 1.4.1 ölçütlerini karşılamaz.
• Input üzerinde aria-describedby yazıp, doğrulama sıfırlamasında koşullu olarak oluşturulan veya DOM’dan kaldırılan bir ID’ye işaret etmek. Bozuk referans, ekran okuyucunun ilişkili içerik bulamaması ve hatanın yardımcı teknoloji kullanıcıları için fiilen görünmez olması anlamına gelir.
• Hata mesajı olarak yalnızca placeholder metni kullanmak. Placeholder metni, kullanıcı yazmaya başladığında kaybolur, genellikle düşük kontrastlıdır ve hata durumlarında tüm ekran okuyucular tarafından alan açıklamasının bir parçası olarak güvenilir şekilde duyurulmaz.
• Hata mesajlarını DOM’a dinamik olarak enjekte edip, bunların aria-describedby aracılığıyla üst alanlarıyla ilişkilendirildiğinden emin olmamak. Görsel olarak bitişik bir hata mesajı, bir input ile otomatik olarak ilişkilendirilmez — programatik bağlantı açıkça kurulmalıdır.
• Her özet öğesini hatalı belirli alanla ilişkilendirmeden sayfa düzeyinde hata özeti göstermek. Ekran okuyucu veya klavye kullanıcılarının, hata açıklamasından doğrudan düzeltme gerektiren alana gidebilmesi gerekir.
• Bir alanda aria-invalid='true' ayarlayıp hiçbir hata mesajı metni sağlamamak. aria-invalid özniteliği, alanın hata durumunda olduğunu bildirir ancak hatayı açıklamaz — açıklayıcı bir mesajla birlikte kullanılmalıdır.
• "Geçersiz girdi" veya "Alanda hata" gibi çok genel hata mesajları sağlamak. Bu açıklamalar, neyin yanlış olduğunu veya nasıl düzeltileceğini açıklamaz; 3.3.1’in açıklayıcı olma gerekliliğini karşılamaz ve tüm kullanıcılar için hata düzeltmeyi gereksiz yere zorlaştırır.
• Bir form sıfırlanırken hata konteynerlerinden aria-live bölgelerini veya role='alert' özniteliklerini kaldırmak ve konteynerlerin ekran okuyucular içeriklerini duyurmayı bitirmeden kaybolmasına neden olmak. Hata duyuruları yarıda kesilebilir ve kullanıcı doğrulama sonucundan habersiz kalabilir.
• Özelleştirme yapmadan yerel tarayıcı doğrulama baloncuklarına (varsayılan tarayıcı araç ipucu açılır pencereleri) güvenmek. Yerel tarayıcı doğrulama arayüzleri, tarayıcılar ve yardımcı teknoloji kombinasyonları arasında tutarsızdır ve karmaşık form senaryolarında genellikle hata tanımlama ve açıklama için WCAG gerekliliklerini karşılamaz.
• Hata mesajlarını, ilişkili alanlarından görsel olarak çok uzakta — yalnızca üst kısımda bir uyarı kutusunda — göstermek ve her alanın yanında satır içi mesajlar sağlamamak. Ekranı büyüten az gören kullanıcılar, odak input alanındayken üst düzey uyarıyı görmeyebilir ve klavye kullanıcıları hatayı okumak için önemli bir mesafe kat etmek zorunda kalı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, Türkiye’de faaliyet gösteren geniş bir yelpazedeki kuruluş için zorunlu web erişilebilirliği gereklilikleri getirmektedir. Genelge, teknik standart olarak WCAG 2.2’yi benimsemekte ve tüm Seviye A başarı ölçütlerini — WCAG 3.3.1 Hata Tanımlama dahil — kapsama giren kuruluşlar için hukuken zorunlu kılmaktadır.

Genelgede belirlenen uyum takvimi, yayımlanma tarihinden itibaren kamu kurumları için bir yıl ve özel sektör kuruluşları için iki yıldır. Bu, kamu kurumlarının Haziran 2026’ya kadar WCAG 2.2 Seviye A uyumunu sağlaması, özel sektör kapsamındaki kuruluşların ise Haziran 2027’ye kadar uyumlu hale gelmesi gerektiği anlamına gelir.

Genelge kapsamındaki kuruluşlar, Türkiye’deki dijital hizmetlerin geniş bir kesimini içerir. Kamu kurumları — tüm merkezi hükümet bakanlıkları, belediyeler, devlet üniversiteleri ve kamu kurumları dahil — dijital hizmetlerini erişilebilir hale getirmekle yükümlüdür. Özel sektörde ise genelge; e-ticaret platformlarını, bankalar ve finans kuruluşlarını, hastaneler ve özel sağlık hizmeti sağlayıcılarını, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketlerini, seyahat acentelerini, özel ulaşım şirketlerini ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okulları kapsamaktadır.

Tüm bu kuruluşlar için, çevrimiçi formların kullanıldığı her yerde WCAG 3.3.1 doğrudan geçerlidir — ki pratikte bu, neredeyse her dijital temas noktası anlamına gelir. E-ticaret ödeme formları, banka hesap açma akışları, hastane hasta kayıt portalları, kamu yardımı başvuru formları, hava yolu ve otobüs rezervasyon sistemleri ve okul kayıt sayfaları, form doğrulamasına dayanır. Bu sistemlerden herhangi biri bir girdi hatasını otomatik olarak tespit eder ve alanı tanımlamayıp hatayı metinle açıklamada başarısız olursa, genelgenin gerekliliklerini doğrudan ihlal etmiş olur.

Genelgeye uyulmaması, Türkiye’nin dijital erişilebilirlik denetim çerçevesi olgunlaştıkça, kapsama giren kuruluşları düzenleyici incelemeye, itibar riskine ve potansiyel yaptırımlara maruz bırakabilir. Hukuki uyumun ötesinde, 3.3.1’e uyum, kapsayıcı hizmet sunumuna bağlılığı gösterir — TÜİK verilerine göre Türkiye’deki yaklaşık 8,5 milyon engelli kişinin de dahil olduğu tüm vatandaşların, temel hizmetlere çevrimiçi ortamda engelsiz erişebilmesini sağlar. Accsible’ın SDK çerçevesi altında faaliyet gösteren kuruluşlar, hata işleme süreçlerinin bu temel ölçütü tam olarak karşıladığından emin olmak için hem otomatik yapısal uyumu hem de kapsamlı manuel testleri önceliklendirmelidir.