WCAG 3.3.2: Etiketler veya Talimatlar

Bu Kuralın Anlamı

WCAG Başarı Ölçütü 3.3.2 — Etiketler veya Yönergeler (Seviye A) şöyle der: "İçerik, kullanıcının girdi yapmasını gerektirdiğinde etiketler veya yönergeler sağlanır." Pratikte bu, bir kullanıcıdan bilgi girmesini veya seçmesini isteyen her form alanının, girdi kontrolünün, metin alanının ve select öğesinin, kullanıcı etkileşime geçmeden önce alanın amacını açık hale getiren, görünür ve anlamlı bir etikete veya yönergeler setine sahip olması gerektiği anlamına gelir.

Ölçüt kapsam bakımından bilerek geniş tutulmuştur. Bir kullanıcının veri sağladığı her mekanizmayı kapsar: tüm türlerdeki <input> öğeleri (text, email, password, number, date, checkbox, radio, dosya yükleme), çok satırlı metin için <textarea> öğeleri ve <select> açılır listeleri. Ayrıca role='combobox' veya role='listbox' gibi ARIA rolleriyle oluşturulmuş özel etkileşimli kontrollere de uygulanır.

Bu ölçütü karşılayan bir etiket çeşitli şekillerde sağlanabilir. En sağlam yöntem, görsel olarak mevcut olan ve eşleşen bir for/id çifti aracılığıyla kontrole bağlanan, programatik olarak ilişkilendirilmiş bir <label> öğesidir. Alternatif olarak, görünür etiket metni mevcut bir öğeye işaret eden aria-labelledby kullanılarak ilişkilendirilebilir veya ek yönergeler aria-describedby ile bağlanabilir. Temel gereklilik, etiketin veya yönergenin sağlanmış olmasıdır — kullanıcının algılayabileceği bir biçimde var olmalıdır. Yalnızca placeholder metni bu ölçütü karşılamaz; çünkü kullanıcı yazmaya başlar başlamaz kaybolur ve tüm yardımcı teknolojiler tarafından kalıcı bir etiket olarak güvenilir biçimde iletilmez.

Başarılı sayılmak için her girdinin, görünür (veya en azından programatik olarak belirlenebilir) bir etikete sahip olması, kullanıcının alanı doldurmaya başlamasından önce mevcut olması ve beklenen verinin ne olduğunu aktaracak kadar açıklayıcı olması gerekir. Başarısızlık ise bir alanın hiç etiketi olmadığında, tek etiketin placeholder niteliği olduğunda, etiket görsel olarak mevcut olup programatik olarak ilişkilendirilmediğinde veya gerekli biçimle ilgili yönergeler (örneğin "Tarihi GG/AA/YYYY biçiminde girin") tamamen yok olduğunda ortaya çıkar.

WCAG dar bir istisnaya da dikkat çeker: bir form tek, bariz bir alan içerdiğinde — örneğin, hemen yanında açıkça etiketlenmiş bir gönder düğmesi bulunan site genelinde bir arama çubuğu — bağlamın kendisi yeterli yönerge sağlayabilir. Ancak bu istisna dardır ve çok alanlı formlarda etiketleri atlamak için genel bir gerekçe olarak kullanılmamalıdır.

Neden Önemlidir

Form etiketleri, çok geniş bir kullanıcı yelpazesi için tek başına en etkili erişilebilirlik özelliğidir. Etiketlerin yokluğu, birçok kişinin işlemleri tamamlamasını, hizmetlere kayıt olmasını veya bir kuruluşla iletişime geçmesini imkânsız hale getiren engeller yaratır.

Ekran okuyuculara güvenen kör ve az gören kullanıcılar için etiketsiz bir alan yalnızca "metin düzenle" veya "boş" şeklinde, bağlam olmadan anons edilir. Kullanıcı, adını mı, e-posta adresini mi yoksa kredi kartı numarasını mı girmesi gerektiğini bilemez. 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 bunların milyonları web ile etkileşim kurmanın birincil yolu olarak ekran okuyucuları kullanmaktadır.

Bilişsel ve öğrenme güçlüğü olan kullanıcılar — disleksi, DEHB ve hafıza ile ilgili durumlar dahil — için placeholder metni özellikle zararlıdır. Placeholder’lar odaklanıldığında veya giriş yapıldığında kaybolduğu için, formun ortasında duraklayan bir kullanıcının, doldurmaya başladığı bir alanda ne beklendiğine dair hiçbir referansı kalmaz. Bu, yönergeyi yeniden okuyabilmek için alanı temizlemeye zorlar; bu da kafa karışıklığı ve hayal kırıklığı yaratır. Kalıcı, görünür etiketler bu bilişsel yükü tamamen ortadan kaldırır.

Motor engelli kullanıcılar için — klavye, switch cihazı veya sesle kontrolle gezinirken — etiketler ek bir işlev görür: Dragon NaturallySpeaking gibi sesle kontrol yazılımları aracılığıyla bir alanı etkinleştirmek için kullanılan konuşma komutlarını sağlarlar. Görünür etiket metni programatik erişilebilir adla eşleşmiyorsa, ses komutu sessizce başarısız olur.

Somut bir gerçek dünya senaryosunu düşünün: az gören bir kullanıcı, bir Türk kamu kurumunun portalında bir devlet yardımına başvuruyor. Form, etiketler yerine placeholder metni kullanıyor. Kullanıcı ekranı okuyabilmek için %200’e yakınlaştırdıkça, placeholder’lar okunamadan kayboluyor. Kullanıcı alanları tahmin ederek dolduruyor ve hatalar içeren bir form gönderiyor; ancak hangi alanların hatalı olduğunu belirtmeyen, genel bir hata mesajı alıyor. Bu senaryo, kritik bir kamu hizmetinden dışlanma ile sonuçlanıyor — ve tamamen önlenebilir.

Erişilebilirliğin ötesinde, etiketli formlar SEO’yu iyileştirir; çünkü arama motoru tarayıcıları formun amacını daha iyi anlayabilir ve tüm kullanıcılar için kullanılabilirliği artırır; buna, küçük dokunma hedeflerinde, ilişkili girdinin etkinleştirme alanını genişleten dokunulabilir etiket alanlarından fayda sağlayan mobil kullanıcılar da dahildir.

İlgili Axe-core Kuralları

• label — Bu kural, her <input> öğesinin (şu türler hariç: type='hidden', type='image', type='button', type='submit' ve type='reset'), her <textarea> ve her <select> öğesinin erişilebilir bir ada sahip olduğunu kontrol eder. Kural, ilişkili bir <label>, bir aria-label niteliği, bir aria-labelledby referansı veya bir title niteliği bulunmayan öğeleri işaretler. Bu, standart form kontrollerinde 3.3.2 ihlalleri için birincil otomatik sinyaldir.
• select-name — Bu kural özellikle <select> açılır liste öğelerini hedefler ve boş olmayan bir erişilebilir ada sahip olduklarını doğrular. Geliştiriciler bazen bir açılır listenin seçeneklerinin amacını kendiliğinden belli ettiğini varsayar; ancak etiket olmadan ekran okuyucu kullanıcıları yalnızca o anda seçili olan seçenek değerini duyar — bu da "Birini seçin" gibi genel bir varsayılan olabilir — ve hangi kategoriden seçim yaptıklarına dair hiçbir fikirleri olmaz. Axe, standart etiketleme mekanizmalarından herhangi birinin eksik olduğu <select> öğelerini işaretler.
• textarea-label — Bu kural, <textarea> öğelerini erişilebilir bir ad açısından kontrol eder. Çok satırlı metin alanları sıklıkla yorumlar, mesajlar veya ayrıntılı girişler için kullanılır; ancak çevredeki bağlamın yeterli olduğu yanılgısıyla sıkça etiketsiz bırakılır. Axe, <label for>, aria-label, aria-labelledby veya title aracılığıyla programatik olarak bir etiketle ilişkilendirilemeyen tüm <textarea> öğelerini işaretler.

Bu ölçüt için otomatik testlerin sınırlarını anlamak önemlidir. Axe-core, programatik bir etiketin yokluğunu tespit edebilir; ancak mevcut bir etiketin gerçekten anlamlı veya doğru olup olmadığını belirleyemez. "Alan 1" şeklinde etiketlenmiş bir alan veya yalnızca "*" yazan bir etiket, otomatik kontrollerden geçer; ancak kullanıcılar açısından tamamen başarısız olur. Etiketlerin beklenen girdiyi açıkça tanımladığını, biçim yönergelerinin gerektiği yerde mevcut olduğunu (örneğin tarih biçimleri, parola gereksinimleri) ve gerekli alanların — ideal olarak hem görsel hem programatik olarak — tanımlandığını doğrulamak için her zaman manuel inceleme gereklidir.

Nasıl Test Edilir

1. axe DevTools veya Lighthouse ile otomatik tarama: Formu içeren sayfayı Chrome veya Firefox’ta açın. axe DevTools tarayıcı eklentisini çalıştırın ve sonuçları label, select-name ve textarea-label kurallarına göre filtreleyin. İşaretlenen tüm öğeleri not edin. İkincil bir kontrol olarak Google Lighthouse’u (Erişilebilirlik denetimi) çalıştırın. Tüm ihlalleri dışa aktarın veya ekran görüntüsü alın. Otomatik raporun temiz olmasının uyumluluğu garanti etmediğini unutmayın — manuel adımlara devam edin.
2. Görsel inceleme: Herhangi bir yardımcı teknoloji kullanmadan sayfadaki her form alanını inceleyin. Her alanın, alanın yakınında (genellikle üstünde veya solunda) açıkça konumlandırılmış, görünür, statik bir etikete — yalnızca placeholder’a değil — sahip olduğunu doğrulayın. Biçim gereksinimlerinin (örneğin "Parola en az 8 karakter olmalıdır") yalnızca başarısız bir gönderimden sonra değil, girişten önce veya giriş sırasında gösterildiğini doğrulayın. Gerekli alanların yalnızca renkle tanımlanmadığını doğrulayın.
3. Klavye ile gezinme testi: Her form alanı arasında Tab ile ilerleyin. Her alan odak aldığında, amacının görünür etiketten hemen anlaşılır olduğundan emin olun. Klavye ile erişilebilen hiçbir alan, o anda görünür, kalıcı bir etikete sahip olmadan erişilebilir olmamalıdır.
4. NVDA ve Firefox ile ekran okuyucu testi: NVDA çalışırken formu açın. Her etkileşimli kontrol arasında ilerlemek için Tab tuşuna basın. NVDA, etiketi, rolü (örneğin "düzenle", "combo box") ve varsa durumu (örneğin "gerekli") anons etmelidir. NVDA yalnızca rol ve durumu, etiket olmadan anons ediyorsa, alan başarısızdır. Gerçekçi kullanıcı gezinmesini simüle etmek için NVDA’nın form modunu (etkileşimli öğelerde otomatik olarak tetiklenir) kullanın.
5. VoiceOver ve Safari ile ekran okuyucu testi (macOS/iOS): VoiceOver’ı etkinleştirin (Mac’te Command + F5). Her form alanına gitmek için Tab tuşunu veya kaydırma hareketlerini kullanın. VoiceOver, rolden önce etiketi anons etmelidir. iOS’ta her alana dokunun ve klavye görünmeden önce etiketin sesli okunduğunu doğrulayın. Yalnızca placeholder içeren alanlar genellikle ilk odakta placeholder olarak okunur; ancak metin girildikten sonra sessiz hale gelir.
6. JAWS ve Chrome ile ekran okuyucu testi: JAWS’ı açın ve formda Tab ile gezinerek ilerleyin. JAWS’ın Forms Mode’unu kullanın. Her alanın anons edilen adının, görünür etiketiyle tam olarak eşleştiğini doğrulayın. aria-describedby aracılığıyla ek açıklamalar olup olmadığını kontrol etmek için JAWS’ın Insert + F1 (alan yardımı) özelliğini kullanın.
7. Dragon NaturallySpeaking ile sesle kontrol testi: Dragon’u etkinleştirin ve her alanla, görünür etiketini söyleyerek etkileşime geçmeye çalışın. Konuşulan etiket programatik erişilebilir adla eşleşmiyorsa, alan ses komutuna yanıt vermez; bu da hem 3.3.2’nin hem de ilgili ölçütlerin ihlal edildiğini gösteren bir uyumsuzluk anlamına gelir.

Nasıl Düzeltilir

Metin girdisinde eksik etiket — Hatalı

<!-- Etiket yok; tek ipucu placeholder -->
<input type='text' name='email' placeholder='Email address' />

Metin girdisinde eksik etiket — Doğru

<!-- Görünür <label>, eşleşen for/id öznitelikleriyle ilişkilendirilmiş.
     Placeholder hâlâ ek ipucu olarak kullanılabilir,
     ancak birincil, kalıcı tanımlayıcı etiketin kendisidir. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

Etiketsiz select açılır listesi — Hatalı

<!-- Etiket yok; ekran okuyucular yalnızca seçili seçenek değerini anons eder -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Etiketsiz select açılır listesi — Doğru

<!-- Programatik olarak ilişkilendirilmiş etiket,
     kullanıcı açılır listeyi açmadan önce alanın amacını netleştirir. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Etiketsiz textarea — Hatalı

<!-- Textarea'nın etiketi yok; çevredeki paragraf metni
     programatik olarak ilişkilendirilmemiştir ve ekran okuyucular
     tarafından alanın etiketi olarak okunmayacaktır. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Etiketsiz textarea — Doğru

<!-- Mevcut görünür başlığı textarea ile ilişkilendirmek için
     aria-labelledby kullanmak veya alternatif olarak <label> ile sarmak. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

Tarih alanı için biçim yönergeleri yok — Hatalı

<!-- Etiket var ancak beklenen tarih biçimi hakkında yönerge yok;
     kullanıcılar 01/06/2025 mi yoksa 2025-06-01 mi gireceklerini tahmin etmek zorunda. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

Tarih alanı için biçim yönergeleri var — Doğru

<!-- Biçim yönergesi görünür ve aria-describedby ile bağlanmış,
     böylece ekran okuyucular alan odak aldığında bunu anons eder. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

Yaygın Hatalar

• placeholder’ı tek etiket olarak kullanmak: Placeholder metni giriş yapıldığında kaybolur, tüm ekran okuyucular tarafından güvenilir biçimde etiket olarak anons edilmez ve kalıcı referans metne ihtiyaç duyan bilişsel engelli kullanıcılar için başarısız olur. Her zaman herhangi bir placeholder’a ek olarak görünür bir <label> sağlayın.
• Bir etiketi, programatik ilişki olmadan alanın yakınına görsel olarak yerleştirmek: Bir girdinin üstüne görsel olarak yerleştirilmiş bir <p> veya <span>, gören kullanıcılar için etiket gibi görünür; ancak ekran okuyucular tarafından yok sayılır. <label for='id'>, aria-labelledby kullanın veya girdiyi bir <label> öğesinin içine alın.
• Görünür etiketle eşleşmeyen metinle aria-label kullanmak: Programatik erişilebilir ad, görünür metinden farklı olduğunda, sesle kontrol kullanıcıları ekranda okuduklarını söyleyerek alanı etkinleştiremez; bu da SC 2.5.3’ü (İsimde Etiket) ihlal eder ve ekran okuyucu kullanıcıları için kafa karışıklığı yaratır.
• Bir radyo düğmesi grubunu etiketleyip grup başlığını (legend) atlamak: Tek tek radyo düğmeleri, kendi seçenek metinleriyle etiketlenmiş olabilir; ancak genel soru (örneğin "Ödeme yöntemi") bir <fieldset> ve <legend> aracılığıyla sağlanmamışsa, klavye ile gezinirken kullanıcılar her seçeneği, ne arasında seçim yaptıklarını anlamadan tek başına duyar.
• Gerekli alanları yalnızca renk veya yıldız işaretiyle tanımlamak: Bir etiketin yanındaki yıldız işareti (*), anlamı açıklanmadıkça (örneğin formun üstünde " * ile işaretli alanlar zorunludur" notu) ekran okuyucu kullanıcılarına hiçbir şey ifade etmez ve gerekli alanlar ayrıca required veya aria-required='true' niteliğini de taşımalıdır.
• Biçim yönergelerini, başarısız bir gönderime kadar göstermemek: Parola kurallarını veya tarih biçimi gereksinimlerini yalnızca gönderim sonrası hata mesajlarında göstermek, kullanıcıları ne beklendiğini öğrenmeden önce hata yapmaya zorlar. Yönergeler, kullanıcı alanla etkileşime geçmeden önce veya geçerken mevcut olmalıdır.
• Etiketleri display:none veya visibility:hidden ile gizlemek: Bu CSS özellikleri, etiketleri erişilebilirlik ağacından tamamen kaldırır. Bir etiket görsel olarak gizlenmek zorundaysa (örneğin minimal bir tasarım için), öğeyi erişilebilirlik ağacında tutup ekrandan uzaklaştıran, görsel olarak gizli bir CSS sınıfı kullanın.
• title niteliğini tek etiket olarak kullanmak ve bunun yeterli olduğunu varsaymak: axe-core, yalnızca title içeren bir etiketi işaretlemeyebilir; ancak title niteliği yalnızca fareyle üzerine gelindiğinde görünen bir araç ipucu olarak görünür ve yalnızca klavye kullanan kullanıcılar ile mobil kullanıcılar için erişilebilir değildir. Birincil etiket olarak değil, ek açıklama olarak kullanılmalıdır.
• Bir kapsayıcı <div> öğesine tek bir aria-label uygulayıp bunun alt girdileri etiketleyeceğini varsaymak: Kapsayıcı öğelerdeki ARIA etiketleri, alt form kontrolleri tarafından devralınmaz. Her etkileşimli kontrol ayrı ayrı etiketlenmelidir.
• Dinamik içerik güncellemelerinden sonra etiketleri yeniden ilişkilendirmemek: Form alanları JavaScript ile dinamik olarak eklendiğinde (örneğin bir adres satırı eklemek), yeni eklenen girdiler genellikle ilişkili etiketlerden yoksundur; çünkü geliştirici yalnızca görünür etiket metnini kardeş öğe olarak eklemiş, ancak doğru for/id bağlamasını yapmamıştı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, WCAG 2.2 ile uyumlu zorunlu web erişilebilirliği gereklilikleri getirmektedir. WCAG Başarı Ölçütü 3.3.2 — Etiketler veya Yönergeler, Seviye A gerekliliğidir; yani uyumun temelinde yer alır ve genelge kapsamında en sıkı şekilde uygulanan hükümler arasındadır.

Genelge, geniş bir kurum yelpazesini kapsar ve uyum takvimleri sektöre göre farklılık gösterir. Kamu kurumları — bakanlıklar, belediyeler, devlet kurumları ve kamu kaynaklarıyla finanse edilen kuruluşlar dahil — genelgenin yayımlanmasından itibaren bir yıl içinde tam Seviye A uyumu sağlamak zorundadır. Kapsam içindeki özel sektör kuruluşları ise iki yıl içinde uyumlu olmak zorundadır. Açıkça kapsanan özel sektör kuruluşları arasında e-ticaret platformları, bankalar ve finans kuruluşları, hastaneler ve özel sağlık hizmeti sağlayıcıları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar yer alır.

Tüm bu kuruluşlar için form alanlarını etiketlememek, yalnızca bir kullanılabilirlik eksikliği değil — doğrudan mevzuata aykırılık anlamına gelir. Formlar, kapsanan tüm dijital hizmetlerde yaygındır: vatandaşlar devlet portallarında başvuru yapar, hastalar hastane web sitelerinde randevu alır, müşteriler e-ticaret platformlarında alışverişlerini tamamlar ve öğrenciler okul portalları üzerinden kayıt yaptırır. Bu yolculukların her biri formlara dayanır ve bu formlardaki her etiketsiz alan, denetçilerin belgeleyip raporlayabileceği somut bir WCAG 3.3.2 ihlalidir.

Genelge kapsamındaki kuruluşlar, SC 3.3.2 uyumunu herhangi bir erişilebilirlik denetimi veya belgelendirme süreci için ön koşul olarak görmelidir. Bu bir Seviye A ölçütü olduğundan, ertelenemez veya feragat edilemez — Seviye A maddelerini hariç tutan kısmi uyum iddiaları kabul edilmez. Tüm halka açık formlarında etiketli girdiler sunamayan kuruluşlar, düzenleyici tespitler, uyumsuzluğun kamuya açık raporlanması ve dijital güvenin giderek kapsayıcı tasarımla ilişkilendirildiği bir pazarda itibar kaybı riskiyle karşı karşıya kalır.

Pratik açıdan bakıldığında, 3.3.2 uyumunu sağlamak, bir kuruluşun atabileceği en düşük çaba, en yüksek etki adımlarından biridir. Mevcut form kontrolleriyle etiketleri ilişkilendirmek genellikle yalnızca küçük HTML değişiklikleri gerektirir ve doğru uygulandığında görsel tasarımı etkilemez. Accsible’ın overlay SDK’sını kullanan kuruluşlar için, eksik etiketlerin otomatik tespiti bu ihlalleri rutin taramalar sırasında ortaya çıkarabilir ve geliştirme ekiplerine, düzenleyici son tarihler gelmeden önce uygulanabilir iyileştirme rehberi sağlayabilir.