WCAG 1.3.3: Duyusal Özellikler

Bu Kuralın Anlamı

WCAG Başarı Kriteri 1.3.3 — Duyusal Özellikler (Seviye A), içeriği anlamak ve kullanmak için sağlanan talimatların, şekil, boyut, görsel konum, yönelim veya ses gibi bileşenlerin duyusal özelliklerine yalnızca bunlara dayanarak güvenmemesi gerektiğini belirtir. Başka bir deyişle, arayüzünüz bir kullanıcıya yalnızca nasıl göründüğüne, ekranda nerede göründüğüne veya nasıl ses çıkardığına atıfta bulunarak bir şeyle etkileşime geçmesini söylüyorsa, bu talimat, bu belirli duyusal özellikleri algılayamayan kullanıcılar için anlamsız olacaktır.

Buradaki kilit kelime yalnızcadır. Kriter, duyusal referansların kullanılmasını yasaklamaz — bunların tek tanımlama aracı olmasını yasaklar. "Soldaki yuvarlak yeşil düğmeye tıklayın" gibi bir talimat, kullanıcı yeşili ayırt edemediğinde, düğmenin şeklini göremediğinde veya yeniden akış düzeni nedeniyle solu sağdan ayırt edemediğinde başarısız olur. Ancak " Gönder düğmesine tıklayın (soldaki yuvarlak yeşil düğme)" talimatı geçerlidir, çünkü "Gönder" metin etiketi, renkten, şekilden ve konumdan bağımsız çalışan duyusal olmayan bir tanımlayıcı sağlar.

Bu kriterden etkilenen talimatlar, kullanıcılara bir eylemde bulunmalarını veya bilgi bulmalarını söyleyen her türlü metin, ses veya görsel içeriği kapsar. Yaygın başarısız örüntüler şunları içerir:

• "Devam etmek için sağdaki düğmeye tıklayın" — yalnızca görsel konuma dayanır.
• "Ayarları açmak için kare simgeyi seçin" — yalnızca şekle dayanır.
• "Zorunlu alanlar kırmızı renkle gösterilmiştir" — yalnızca renge dayanır.
• "Zili duyduğunuzda bir sonraki adıma geçin" — yalnızca sese dayanır.
• "Bölümü genişletmek için büyük kutucuğa dokunun" — yalnızca boyuta dayanır.

Geçerli bir talimat her zaman en az bir duyusal olmayan tanımlayıcı içerir — genellikle bir metin etiketi, programatik ad veya başlık — böylece yardımcı teknolojiye güvenen veya duyusal ipuçlarının mevcut olmadığı koşullarda çalışan kullanıcılar yine de talimatları takip edebilir. Bu kriterin özellikle talimatları kapsadığını unutmayın; her bir UI öğesinin yeniden tasarlanmasını gerektirmez, ancak bu öğeler hakkında verilen her türlü yazılı veya sözlü yönlendirmenin duyusal ayrım olmadan algılanabilir olmasını gerektirir.

1.3.3 içinde tanımlanmış resmi istisnalar yoktur, ancak Understanding belgesi, duyusal özellikleri duyusal olmayan tanımlayıcılara ek olarak kullanan içeriğin tamamen uyumlu olduğunu netleştirir. Kriter ayrıca 1.4.1 (Renk Kullanımı) ile tamamlayıcıdır ancak ondan ayrıdır; 1.4.1 özellikle yalnızca rengi ele alırken, 1.3.3 tüm duyusal modaliteleri kapsayan daha geniş bir kapsama sahiptir.

Neden Önemlidir

Yalnızca duyusal ipuçlarına dayanan talimatlar, geniş bir kullanıcı kitlesi için ciddi engeller oluşturur. Etkilenen her grubu ayrı ayrı düşünün:

Kör ve az gören kullanıcılar ekran okuyuculara veya büyütme yazılımlarına güvenir. Bir talimat "sağ üst köşedeki simgeye tıklayın" dediğinde, sekme sırasına veya başlık yapısına göre gezinmekte olan bir ekran okuyucu kullanıcısının görsel yerleşimde "sağ üst köşe" kavramı yoktur. Benzer şekilde, ekranı %400’e kadar yakınlaştırmış ağır görme bozukluğu olan bir kullanıcı, aynı anda yalnızca ekranın küçük bir bölümünü görebilir; bu da "sol panel" veya "alt bölüm" gibi konumsal referansları tamamen güvenilmez hale getirir. Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık 2,2 milyar insanın bir tür görme bozukluğu vardır; bu da bunu en büyük etkilenen popülasyonlardan biri yapar.

Renk körü kullanıcılar — yaklaşık her 12 erkekten 1’ini ve her 200 kadından 1’ini etkiler — belirli renk çiftlerini ayırt edemez. "Kırmızı ile vurgulanan alanlar zorunludur" şeklindeki bir talimat, kırmızı-yeşil renk körlüğü olan biri için ayırt edici bir ipucu olarak görünmezdir. 1.4.1, UI öğesinin kendisi için bunu ele alırken, 1.3.3 talimat metninin de bir alternatif sağlamasını güvence altına alır.

Sağır ve işitme güçlüğü olan kullanıcılar ses tabanlı ipuçlarından etkilenir. Bir e-öğrenme platformu kullanıcılara "zili duyduğunuzda devam edin" diyorsa, zili duyamayan kullanıcılar dışlanır. Bu örüntü, etkileşimli sunumlarda, video tabanlı eğitimlerde ve zamanlı değerlendirmelerde görülür.

Bilişsel ve öğrenme güçlüğü olan kullanıcılar, özellikle yardımcı teknolojileri içeriği görsel konumlandırmayı ortadan kaldıran doğrusal bir biçimde sunuyorsa, yön belirten dil ile zorlanabilir. Anahtarlama cihazı veya göz takibi sistemi kullanan bir kişi de, gören bir tasarımcının hayal ettiği iki boyutlu mekansal yerleşimle hiçbir ilişkisi olmayan diziler halinde gezinir.

Somut bir gerçek dünya senaryosu düşünün: bir Türk devlet e-hizmet portalı vatandaşlara "mavi çerçeveyle belirtilen alanları doldurun ve ardından başvurunuzu göndermek için üçgen düğmeye basın" talimatını veriyor. Form alanları arasında gezinirken alan etiketlerini ekran okuyucusundan duyan kör bir kullanıcının, hangi alanların mavi çerçeveli olduğunu bilmesinin bir yolu yoktur; ayrıca bir düğmeyi üçgen şekliyle tanımlayamaz. Başvuru süreci fiilen engellenmiş olur. Gerçek alan etiketlerini eklemek ("Ad, T.C. Kimlik Numarası ve Doğum Tarihi zorunludur" gibi) ve düğmenin metin etiketini ("Başvuruyu Gönder") belirtmek, engeli anında ortadan kaldırır.

Erişilebilirliğin ötesinde, yalnızca duyusal talimatları kaldırmak herkes için kullanılabilirliği artırır. Duyarlı tasarımlar içeriği yeniden akıtarak konumsal referansları mobilde hatalı hale getirir. Karanlık mod veya yüksek kontrast temalar renk sunumunu değiştirir. Sayfa talimatlarını sesli okuyan sesli asistanlar tüm görsel bağlamı ortadan kaldırır. Talimatları geçici duyusal özellikler yerine kalıcı, programatik etiketler etrafında oluşturmak, içeriği tüm cihaz ve bağlamlarda daha sağlam hale getirir — bu aynı zamanda doğrudan bir SEO ve bakım avantajıdır.

İlgili Axe-core Kuralları

WCAG 1.3.3, otomatik araçlar doğal dildeki talimatların anlamını veya niyetini güvenilir şekilde yorumlayamadığı için manuel test gerektirir. Statik bir analiz motoru bir düğmenin var olduğunu veya bir rengin kullanıldığını tespit edebilir, ancak bir talimat paragrafını okuyamaz, bunun bir düğmeye atıfta bulunduğunu anlayamaz ve ardından bu atfın yalnızca duyusal olup olmadığını belirleyemez. Bu, bağlamsal ve anlamsal bir yargıdır ve insan incelemesi gerektirir.

• Manuel inceleme gereklidir — 1.3.3 için özel bir axe-core kuralı yoktur. color-contrast ve label gibi axe-core kuralları (örneğin, erişilebilir adı olmayan bir düğme gibi) ilgili sorunları ortaya çıkarabilir, ancak farklı kriterleri ele alırlar. 1.3.3 için, bir insan test uzmanı sayfadaki her talimat cümlesini okumalı, herhangi bir duyusal referansı (şekil, renk, boyut, konum, yönelim, ses) belirlemeli ve her referansa en az bir duyusal olmayan tanımlayıcının eşlik ettiğini doğrulamalıdır. Otomatik araçlar, doğal dildeki niyeti ayrıştırmak mevcut kural tabanlı otomasyonun ötesinde olduğundan, "aşağıdaki yeşil düğmeye tıklayın" gibi bir cümleyi ihlal olarak işaretlemez.
• Burada otomasyonun neden başarısız olduğu: "Büyük düğmeye tıklayın" ifadesinin "düğme" kelimesini içerdiğini ve bunun otomatik bir araç tarafından erişilebilir bir role atıf olarak yorumlanabileceğini düşünün. Ancak talimat, bu düğmeyi diğerlerinden ayırt etmek için hâlâ yalnızca boyuta ("büyük") dayanır. Otomatik araçlar, "büyük" ifadesinin tek ayırt edici özellik olup olmadığını veya sayfada yalnızca bir düğme bulunup bulunmadığını (bu durumda "büyük" ifadesi gereksiz ama zararsız olur) belirleyemez. Bu nüansları bağlam içinde değerlendirmek için insan yargısı esastır.
• Manuel incelemeyle birlikte çalıştırılacak tamamlayıcı axe kuralları: color-contrast, label, button-name ve aria-label kontrollerini çalıştırmak, talimatlarda atıfta bulunulan UI öğelerinin gerçekten programatik adlara sahip olmasını sağlamaya yardımcı olur — bu da duyusal olmayan talimatlar yazmak için bir ön koşuldur. Bir düğmenin erişilebilir adı yoksa, hiçbir talimat ona duyusal ipuçlarına başvurmadan anlamlı şekilde atıfta bulunamaz.

Nasıl Test Edilir

1. Önce otomatik bir tarama çalıştırın (axe DevTools veya Lighthouse): Sayfayı Chrome’da açın, axe DevTools uzantısını etkinleştirin ve tam sayfa taraması yapın. Her ne kadar 1.3.3’e doğrudan karşılık gelen bir kural olmasa da, "color", "label" ve "name" kategorileri altında işaretlenen sorunları inceleyin. Bu sonuçlar bir temel sağlar — UI öğelerinin erişilebilir adları yoksa, onlara atıfta bulunan talimat metni neredeyse kesinlikle duyusal ipuçlarına dayanıyordur. Sonuçları dışa aktarın ve programatik etiketi olmayan tüm etkileşimli öğeleri not edin.
2. Tüm talimat metnini manuel olarak belirleyin: Kullanıcıya bir eylemde bulunmasını veya bilgi bulmasını söyleyen sayfadaki her cümleyi okuyun. Buna yardım metni, form ipuçları, araç ipuçları (tooltip), eğitim katmanları, hata mesajları ve onboarding akışları dahildir. Her talimatın bir listesini oluşturun ve herhangi bir duyusal referansı vurgulayın: renk kelimeleri (kırmızı, mavi, yeşil), şekil kelimeleri (yuvarlak, kare, üçgen), boyut kelimeleri (büyük, küçük), konumsal kelimeler (sol, sağ, üst, alt, yukarıda, aşağıda, köşe), yönelim kelimeleri (yatay, dikey) ve ses referansları (zil, bip, uyarı sesi).
3. Her duyusal referansı ek duyusal olmayan tanımlayıcılar açısından değerlendirin: Bulunan her duyusal referans için, duyusal olmayan bir tanımlayıcının da mevcut olup olmadığını belirleyin. Duyusal olmayan tanımlayıcı; öğenin görünür etiketi veya erişilebilir adıyla eşleşen bir metin etiketi, bir başlık, numaralandırılmış bir adım, benzersiz bir programatik rol veya bir ARIA etiketi olabilir. Atıfta bulunulan öğeyi tanımlamanın tek yolu duyusal algı ise, talimat 1.3.3’te başarısız olur.
4. Ekran okuyucu ile test edin (NVDA + Firefox): Sayfada yalnızca klavye ve NVDA kullanarak gezinin. Tüm etkileşimli öğeler arasında sekme ile dolaşın ve NVDA’nın her birini nasıl duyurduğunu dinleyin. Ardından sayfadaki talimat metnini okuyun ve şu soruyu sorun: Yalnızca bu duyuruları duyan bir kullanıcı talimatları takip edebilir mi? Bir talimat "sağdaki simgeye tıklayın" diyorsa ancak NVDA öğeyi "Ayarlar, düğme" olarak duyuruyorsa, konumsal referans gereksizdir ancak etiket talimatı takip edilebilir kılar. NVDA öğeyi adı olmadan "düğme" olarak duyuruyorsa, görsel konuma dayanan talimat tamamen başarısız olur.
5. VoiceOver + Safari ile test edin (macOS/iOS): VoiceOver’ı etkinleştirin ve sayfada gezinin. Rotor’u kullanarak düğmelere, bağlantılara ve form kontrollerine göre göz atın. Talimatta atıfta bulunulan her öğenin, görsel yerleşimindeki konumuna güvenmeden yalnızca duyurulan adıyla erişilebilir ve tanımlanabilir olduğunu doğrulayın.
6. JAWS + Chrome ile test edin: Sayfayı Chrome’da JAWS etkin halde açın. Form Modu’nu kullanarak girdiler arasında gezinin ve alan duyurularını dinleyin. Renk veya konumu kullanarak zorunlu alanları belirten form düzeyindeki talimatlarla çapraz kontrol yapın.
7. Yüksek kontrast ve karanlık modlarda test edin: İşletim sistemini yüksek kontrast moduna alın ve sayfayı yeniden yükleyin. Belirli renklere atıfta bulunan renk kodlu talimatlar, renk sunumu değiştiğinde belirsiz veya görünmez hale gelebilir. Bu, renge tek duyusal ipucu olarak gizli bağımlılığı ortaya çıkarmaya yardımcı olur.
8. Yakınlaştırılmış veya yeniden akışlı mobil görünümde test edin: Tarayıcı penceresini 320px genişliğe yeniden boyutlandırın veya bir mobil cihaz kullanın. "Sol kenar çubuğu" veya "üst gezinme" gibi konumsal dil kullanan talimatlar, düzen tek sütuna yeniden akıtıldığında da anlamlı olmalıdır.

Nasıl Düzeltilir

Yalnızca Renge Dayalı Form Alanı Talimatları — Hatalı

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Yalnızca Renge Dayalı Form Alanı Talimatları — Doğru

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Konumsal Düğme Referansı — Hatalı

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Konumsal Düğme Referansı — Doğru

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Yalnızca Şekle Dayalı Simge Gezintisi — Hatalı

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Yalnızca Şekle Dayalı Simge Gezintisi — Doğru

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Yalnızca Sese Dayalı İlerleme İpucu — Hatalı

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Yalnızca Sese Dayalı İlerleme İpucu — Doğru

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Yaygın Hatalar

• Form talimatlarında veya yardım metninde tek tanımlayıcı olarak "kırmızı düğme" veya "yeşil alan" yazmak ve ayrıca düğmenin görünür etiketini veya alanın adını vermemek — bu hem 1.3.3 hem de 1.4.1’de başarısız olur.
• Yardım dokümantasyonunda veya onboarding akışlarında "soldaki menü" veya "üstteki panel" gibi konumsal ifadeler kullanmak ve menüyü veya paneli adlandırmamak; bu da, duyarlı yeniden akış düzeni yerleşimi tek sütuna daralttıktan sonra talimatları işe yaramaz hale getirir.
• Simgeleri yalnızca şekille tanımlamak ("üçgen oynat düğmesine tıklayın" gibi) yerine, bir ekran okuyucu kullanıcısının klavye ile gezinerek gerçekten bulabileceği simgenin erişilebilir adını veya etiketini kullanmamak.
• Zorunlu form alanlarını yalnızca kenarlık rengi veya arka plan rengiyle belirtmek ve aynı bilgiyi programatik olarak iletmek için bir sembol, etiket son eki veya aria-required='true' özniteliği kullanmamak ("turuncu alanlar doldurulmalıdır" gibi satır içi talimatlarda).
• Etkileşimli süreçler için yalnızca sesli geri bildirim yerleştirmek (dosya yüklemeleri, form gönderimleri, zamanlayıcı bitişleri) ve role='status' veya aria-live='polite' kullanan karşılık gelen görünür bir metin durum güncellemesi sağlamamak.
• Boyutu tek ayırt edici ipucu olarak kullanmak — "büyük kartı tıklayın" gibi talimatlar, kullanıcı yakınlaştırdığında, kartlar daha küçük görünüm alanlarında aynı boyutta render edildiğinde veya bir ekran okuyucu kullanıcısının DOM’daki göreli kart boyutları hakkında hiçbir fikri olmadığında başarısız olur.
• "Yatay kaydırarak gezin" gibi yönelim ipuçlarına güvenmek ve tarif edilen karusel veya slider için alternatif bir etkileşim yöntemi ve yönelime dayalı olmayan bir etiket sağlamamak.
• Hata mesajlarının da talimat olduğunu unutmak — "aşağıda vurgulanan alanlar hata içeriyor" diyen bir hata, görsel vurgulamaya ve konumsal yakınlığa dayanır ve her hatalı alan hata mesajında açıkça adlandırılmadıkça bir ekran okuyucu kullanıcısı için işe yaramaz.
• Bir simgenin alt metni eklenince talimatın düzeldiğini varsaymak — talimat metni hâlâ yalnızca "yuvarlak simgeye tıklayın" diyorsa, görüntü öğesindeki simgenin alt metne sahip olması, talimat metnini uyumlu hale getirmez; metnin kendisi duyusal olmayan bir tanımlayıcı içermelidir.
• Tek sayfa uygulamalarda dinamik olarak eklenen talimatları ihmal etmek — JavaScript ile eklenen araç ipuçları, modallar ve sihirbaz adımları, statik sayfa denetiminde görünmedikleri için genellikle QA incelemesinden kaçan yalnızca duyusal yönlendirmeler içerir.

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

21 Haziran 2025’te 32933 sayılı Resmî Gazete’de yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, Türkiye’de faaliyet gösteren geniş bir kamu ve özel sektör kuruluşu için zorunlu web erişilebilirliği gereklilikleri getirir. Genelge, temel standart olarak WCAG 2.1 Seviye AA’ya uyumu zorunlu kılar ve WCAG 1.3.3 — bir Seviye A kriteri olarak — bu nedenle kapsamdaki tüm kuruluşlar için tamamen zorunludur.

Genelge kapsamında yer alan kuruluşlar arasında kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finans kuruluşları, hastaneler ve 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 bulunur. Kamu kurumlarının, genelgenin yayım tarihinden itibaren bir yıl içinde tam uyumu sağlaması gerekirken, özel sektör kuruluşlarına iki yıllık bir süre tanınmıştır.

WCAG 1.3.3, Türk dijital hizmetleri için özellikle önemlidir; zira Türk e-devlet portallarında, bankacılık uygulamalarında ve e-ticaret ödeme akışlarında renk kodlu form yönlendirmeleri ve yalnızca simgeye dayalı gezinme örüntüleri yaygın olarak kullanılmaktadır. Örneğin, vatandaşlara "kırmızı ile işaretlenen alanları doldurun" ve "sağ alt köşedeki düğmeye basarak gönderin" talimatını veren bir kamu kurumunun çevrimiçi başvuru formu, 1.3.3’ü doğrudan ihlal eder ve Cumhurbaşkanlığı Genelgesi’ne uyumsuzluk anlamına gelir. Benzer şekilde, kullanıcıları çok adımlı işlemler boyunca yalnızca konumsal ve renk ipuçlarıyla yönlendiren bir bankanın mobil web arayüzünün, özel sektör için tanınan iki yıllık süre dolmadan önce revize edilmesi gerekir.

Uyumsuzluk, Türkiye’nin dijital erişilebilirlik alanındaki düzenleyici ortamı olgunlaştıkça itibar ve hukuki risk taşır. Kapsamdaki kuruluşlar, 1.3.3 uyumunu küçük bir editoryal düzeltme olarak değil, tüm talimat içeriğinin — yardım metni, hata mesajları, onboarding akışları ve destek dokümantasyonu dahil — sistematik bir incelemesi olarak ele almalıdır; böylece duyusal referansların her zaman kalıcı, programatik, metin tabanlı tanımlayıcılarla desteklendiğinden emin olunur. Accsible’ın overlay SDK’sı, birçok ilgili sorunun ortaya çıkarılması ve giderilmesine yardımcı olabilir; ancak 1.3.3’ün gerektirdiği manuel içerik incelemesi, nihayetinde otomatik araçlarla birlikte çalışan nitelikli bir insan denetçi tarafından yapılmalıdır.