WCAG 1.3.1: Bilgi ve İlişkiler

Bu Kuralın Anlamı

WCAG 1.3.1 — Bilgi ve İlişkiler, Algılanabilir ilkesinin altında Seviye A ölçütüdür. Temel gereksinimi basit ama kapsamlıdır: görsel olarak iletilen her türlü bilgi veya ilişki, yardımcı teknolojilerin algılayıp kullanıcılara aktarabileceği bir biçimde de ifade edilmelidir. Tasarımınız girintiyi listeyi ima etmek için, kalın yazıyı zorunlu alanı işaretlemek için, rengi hatayı göstermek için veya boyutu başlığı belirtmek için kullanıyorsa, aynı anlamlar alttaki kodda da bulunmalıdır.

Bu ölçüt, web içeriğinin sunum yoluyla düzenli olarak aktardığı üç anlam kategorisine uygulanır:

• Bilgi — sayfada iletilen olgular veya veriler; hangi form alanlarının zorunlu olduğu ya da hangi tablo hücrelerinin bir ilişkiyi paylaştığı gibi.
• Yapı — içeriğin örgütsel şeması; başlık hiyerarşileri, sıralı veya sırasız listeler ve veri tabloları gibi.
• İlişkiler — öğeler arasındaki bağlantılar; bir etiket ile girdisi, bir tablo başlığı ile veri hücreleri veya bir terim ile tanımı arasındaki ilişki gibi.

Bir sayfa, gören bir kullanıcının erişebildiği her yapısal veya ilişkisel bilgi parçası, ya geçerli, semantik HTML ile kodlandığında ya da yardımcı teknolojilerin yorumlayabileceği doğru bir ARIA rolü, özelliği veya durumu ile açığa çıkarıldığında 1.3.1’i geçer. Bir sayfa, görsel yapının yalnızca CSS veya görsellerde bulunması ya da ARIA işaretlemesinin sunulan DOM yapısıyla çelişmesi veya ondan tamamen eksik olması durumunda başarısız olur.

Resmî istisnalar asgaridir. Ölçüt, tüm görsel süslemelerin semantik anlam taşımasını gerektirmez — dekoratif bir kenarlık veya arka plan rengi gibi salt estetik biçimlendirmelerin programatik bir karşılığa sahip olması gerekmez. Ancak, bir kullanıcının makul olarak anlam taşıdığını düşüneceği her biçimlendirme (zorunlu alan yıldızları, sözlükte kalın terimler, numaralandırılmış adımlar) için karşılık gelen programatik bir ifade bulunmalıdır.

Neden Önemlidir

Bilgi ve ilişkiler, bir kullanıcının bir web sayfasıyla kurduğu neredeyse her etkileşimin temelini oluşturur. Bu yapı yalnızca görsel sunumun içine hapsolduğunda, nüfusun önemli bir bölümü içeriği hiç anlayamaz hâle gelir.

Ekran okuyucu kullanıcıları — genellikle kör veya az gören bireyler — sayfalarda, semantik HTML ve ARIA’dan oluşturulan erişilebilirlik ağacını sorgulayarak gezinir. Bir geliştirici gerçek bir <h2> yerine başlık gibi görünen stillendirilmiş bir <div> kullandığında, H tuşuyla başlıklar arasında atlayan bir ekran okuyucu kullanıcısı bu başlığı tamamen atlar. Tanıttığı bölümü asla bulamayabilir. 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 ve on milyonlarcası her gün ekran okuyuculara güvenmektedir.

Bilişsel engelli kullanıcılar da net yapıdan en az bu kadar fayda sağlar. Doğru iç içe geçmiş başlıklar, anlamlı liste işaretlemesi ve etiketlenmiş form kontrolleri, öngörülebilir kalıplar sağlayarak bilişsel yükü azaltır. Bir ekran okuyucunun "2. seviye başlık, Ürünler" ardından "3. seviye başlık, Dizüstü Bilgisayarlar" demesi, sayfanın bilişsel bir haritasını sunar. Yapısal dayanak noktaları olmayan, sadece stillendirilmiş düz bir metin duvarı herkes için, ama özellikle dikkat veya hafıza zorlukları yaşayan kullanıcılar için yönünü şaşırtıcıdır.

Klavye ile gezinmeye, anahtar erişimine veya sesle kontrol yazılımlarına güvenen motor engelli kullanıcılar da programatik yapıya ihtiyaç duyar. Dragon NaturallySpeaking gibi sesle kontrol yazılımları, etiketler ve rollere dayalı erişilebilir adlardan tıklanabilir hedefler üretir — ilişkili etiketi olmayan form girdileri sesli komutla güvenilir biçimde hedeflenemez.

Somut bir senaryo düşünün: bir hastane hasta portalı, yaklaşan randevuların yer aldığı bir tablo gösteriyor. Tablo, tarihleri doktorlarla ilişkilendirmek için görsel hizalama ve arka plan rengi kullanıyor, ancak <th> öğelerinde scope öznitelikleri yok ve veri hücreleri başlıklara referans vermiyor. Ekran okuyucu kullanan kör bir kullanıcı, "09:00", "Dr. Ayşe Kaya", "Kardiyoloji" gibi birbirinden kopuk hücre değerleri duyuyor, ancak hangi değerin hangi sütuna ait olduğunu bilemiyor. Randevu saatini yanlış anlayabilir veya yanlış kliniğe gidebilir. Başlıklarda scope='col' ve hücrelerde headers özniteliklerinin doğru kullanımı, bu ilişkileri işitilebilir hâle getirirdi.

Erişilebilirliğin ötesinde, yapısal HTML önemli SEO değeri taşır. Arama motoru tarayıcıları, sayfa konularını anlamak için başlık hiyerarşilerini, sıralı içeriği belirlemek için liste işaretlemesini ve form amacını anlamak için etiket ilişkilerini kullanır. 1.3.1’i geçen bir sayfa, neredeyse her zaman arama motorlarının daha doğru biçimde ayrıştırıp sıralayabildiği bir sayfadır.

İlgili Axe-core Kuralları

Aşağıdaki axe-core kuralları, doğrudan WCAG 1.3.1 ihlallerine karşılık gelir. Her kural, programatik yapı veya ilişkiyle ilgili belirli bir yönü hedefler:

• aria-required-children — Belirli ARIA rolleri olan öğelerin, gerekli alt rollerini içerip içermediğini denetler. Örneğin, bir role='list' öğesi, role='listitem' rolüne sahip alt öğeler içermelidir. Doğru alt yapı olmadan, bir kapsayıcı ile öğeleri arasındaki ilişki yardımcı teknolojiler için bozulur.
• aria-required-parent — Yukarıdakinin tersi: Belirli bir üst bağlam gerektiren rollere sahip öğelerin gerçekten o üst öğeye sahip olup olmadığını denetler. role='listitem' olup da bir role='list' veya <ul>/<ol> içinde bulunmayan bir öğe, ilişki bağlamı eksik olduğu için işaretlenir.
• aria-roles — Tüm role öznitelik değerlerinin geçerli ARIA rolleri olduğunu doğrular. Geçersiz veya yanlış yazılmış bir rol (örneğin, bir başlık öğesi kullanmak yerine role='heading' veya tamamen uydurma bir rol) yardımcı teknolojinin hiçbir yararlı bilgi alamaması ve öğeyi tamamen yok sayması anlamına gelir.
• definition-list — <dl> öğelerinin yalnızca izin verilen alt öğeleri içerdiğini doğrular: <dt>, <dd>, <div>, <script> ve <template>. Bir <dl> içine doğrudan <p> gibi başka öğeler eklemek, terim-tanım ilişki yapısını geçersiz kılar.
• dlitem — <dt> ve <dd> öğelerinin yalnızca <dl> öğeleri içinde kullanıldığını denetler. Bu öğeleri gerekli üst bağlamı dışında kullanmak, terim-tanım çiftinin semantik anlamını yok eder.
• heading-order — Belge taslağında atlanan başlık seviyelerini işaretler (örneğin, <h2>’den <h4>’e atlamak). Her zaman kesin bir başarısızlık olmasa da, seviye atlamak yardımcı teknolojileri sayfanın hiyerarşik yapısı hakkında yanlış yönlendirir ve başlıklarla gezinen kullanıcıları şaşırtır.
• label — Her form girdisinin programatik olarak ilişkili bir etikete sahip olduğunu doğrular; bu, <label for='...'>, aria-label, aria-labelledby veya sarmalayan bir <label> öğesi aracılığıyla olabilir. Erişilebilir etiketi olmayan bir girdi, kör ve sesle kontrol kullanan kullanıcıların ne girmeleri gerektiğini anlamasını engeller.
• list — <ul> ve <ol> öğelerinin doğrudan alt öğe olarak yalnızca <li> (artı <script> ve <template>) içerdiğinden emin olur. Geçersiz alt öğeler, ekran okuyucuların öğe sayısını ve konumlarını duyurmak için kullandığı liste yapısını bozar.
• listitem — <li> öğelerinin yalnızca <ul>, <ol> veya role='list' kapsayıcıları içinde kullanıldığını denetler. Sahipsiz liste öğeleri, semantik anlamlarını tamamen kaybeder.
• scope-attr-valid — <th> öğelerindeki scope özniteliğinin yalnızca izin verilen değerleri içerdiğini doğrular: col, row, colgroup veya rowgroup. Karmaşık bir veri tablosunda geçersiz veya eksik bir scope değeri, ekran okuyucuların hangi başlığın hangi veri hücresine uygulandığını güvenilir biçimde duyurmasını engeller.
• td-headers-attr — Veri hücreleri headers özniteliğini kullandığında, referans verilen her kimliğin gerçekten aynı tabloda var olup bir başlık hücresine ait olduğunu denetler. Bozuk veya eksik referanslar, veriler ile açıklayıcı başlıkları arasındaki programatik ilişkiyi koparır ve ekran okuyucu kullanıcılarını bağlamsız bırakır.

axe-core gibi otomatik araçların 1.3.1’in her ihlalini yakalayamayacağını unutmayın. Örneğin, bir geliştirici görsel olarak stillendirilmiş bir <div> üzerinde role='list' ve doğru yapılandırılmış alt role='listitem' öğeleri kullanabilir — axe bunu geçer — ancak bir insan testçi, görsel girintinin ARIA yapısında temsil edilmeyen iç içe bir alt listeyi ima ettiğini fark edebilir. Görsel hiyerarşi karmaşık olduğunda, manuel inceleme ve ekran okuyucu testleri, otomatik taramaya vazgeçilmez bir tamamlayıcıdır.

Nasıl Test Edilir

1. axe DevTools veya Lighthouse ile otomatik tarama: axe DevTools tarayıcı eklentisini (Chrome veya Firefox) kurun. Test edilecek sayfayı açın, DevTools’u açın, axe sekmesine gidin ve tam sayfa taraması çalıştırın. Sonuçları wcag131 etiketiyle filtreleyin veya "Info and Relationships" altında etiketlenen tüm sorunları inceleyin. Özellikle yukarıda listelenen on bir axe kuralının ihlallerine bakın. Lighthouse’ta (Chrome DevTools Audits paneli) bir erişilebilirlik denetimi çalıştırın ve "Accessibility" kategorisinde başlık sırası, etiket ve listeyle ilgili hataları kontrol edin. Düzeltme için işaretlenen tüm öğeleri ve DOM seçicilerini not alın.
2. Başlık yapısının manuel incelenmesi: HeadingsMap tarayıcı eklentisini veya axe DevTools içindeki "Headings" panelini kullanarak sayfanın tam başlık taslağını görüntüleyin. Taslağın mantıklı ve hiyerarşik olduğunu doğrulayın — iyi yapılandırılmış bir içindekiler tablosu gibi okunmalıdır. Hiçbir başlık seviyesinin atlanmadığından ve başlık metninin anlamlı olduğundan, yalnızca başlık olmayan öğelere uygulanan görsel stil olmadığından emin olun.
3. Form etiketlerinin doğrulanması: Sayfadaki her etkileşimli form öğesi üzerinde sekme ile gezinin. Her input, select ve textarea için, görünür bir etiketin bulunduğunu ve programatik olarak ilişkili olduğunu doğrulayın (öğeyi DevTools’ta kontrol edin ve eşleşen bir for/id çifti veya bir aria-label/aria-labelledby arayın). Her kontrol için hesaplanan erişilebilir adı doğrulamak üzere Chrome DevTools’taki erişilebilirlik ağacını kullanın (Elements paneli → Accessibility sekmesi).
4. NVDA + Firefox ile ekran okuyucu testi: NVDA’yı başlatın ve sayfayı Firefox’ta açın. H tuşuna basarak başlıklar arasında dolaşın ve duyurulan başlık seviyelerinin görsel hiyerarşiyle eşleştiğini doğrulayın. F tuşuna basarak form alanları arasında ilerleyin ve her alanın etiketinin duyurulduğunu doğrulayın. T tuşuna basarak tablolara gidin ve hücreler arasında ok tuşlarıyla gezinirken başlık duyurularını dinleyin. L tuşuna basarak listeler arasında dolaşın ve öğe sayılarının duyurulduğunu doğrulayın.
5. VoiceOver + Safari (macOS/iOS) ile ekran okuyucu testi: VoiceOver’ı etkinleştirin (macOS’ta Cmd+F5). Rotor’u açın (Ctrl+Option+U) ve Headings, Links, Form Controls ve Tables bölümlerini inceleyin. Tüm yapısal öğelerin Rotor’da göründüğünü ve duyurulan adlarının anlamlı ve doğru olduğunu doğrulayın.
6. JAWS + Chrome ile ekran okuyucu testi: JAWS’ı ve sayfayı Chrome’da açın. Başlık ağacını incelemek için JAWS Başlık Listesini kullanın (Insert+F6). Etiket ilişkilerini doğrulamak için Insert+F5 ile form alanları listesini açın. Tablolarda ok tuşlarıyla gezin ve JAWS’ın her veri hücresi için sütun ve satır başlıklarını duyurduğunu doğrulayın.
7. Tablo başlık ilişkilerinin kontrolü: Sayfadaki tüm veri tablolarını belirleyin. Basit tablolar için, <th> öğelerinin uygun scope özniteliklerine sahip olduğunu doğrulayın. Çok seviyeli başlıklara sahip karmaşık tablolar için, veri hücrelerinin doğru id değerlerine referans veren headers özniteliğini kullandığını doğrulayın. Her hücreyi görsel olarak mantıksal satır ve sütun başlıklarına kadar izleyin, ardından aynı yolun kodda temsil edildiğini doğrulayın.

Nasıl Düzeltilir

Görsel başlıkların stillendirilmiş div’lerle uygulanması — Hatalı

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Görsel başlıkların stillendirilmiş div’lerle uygulanması — Doğru

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

İlişkili etiketi olmayan form girdisi — Hatalı

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

İlişkili etiketi olmayan form girdisi — Doğru

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

scope öznitelikleri olmayan veri tablosu — Hatalı

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

scope öznitelikleri olmayan veri tablosu — Doğru

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Liste kapsayıcısı dışında kullanılan liste öğeleri — Hatalı

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Liste kapsayıcısı dışında kullanılan liste öğeleri — Doğru

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Yaygın Hatalar

• <div> veya <span> öğelerinde yalnızca font-size ve font-weight CSS kullanarak görsel başlık görünümü oluşturmak, ancak hiçbir zaman role='heading' ve aria-level eklememek veya bunları gerçek <h1>–<h6> öğelerine dönüştürmemek — ekran okuyucular bunları gezinilebilir başlıklar olarak keşfedemez.
• Form girdileri için tek etiket olarak placeholder metni kullanmak; bu, kullanıcı yazmaya başlar başlamaz etiketin kaybolmasına ve giriş süresince alanın etiketsiz kalmasına neden olur — girdileri her zaman kalıcı bir <label> öğesiyle eşleştirin.
• Zorunlu alanları, yalnızca formun üst kısmındaki görsel bir açıklamada anlatılan kırmızı bir yıldız (*) ile işaretlemek, ancak aria-required='true' eklememek veya "zorunlu" ifadesini programatik etikete dahil etmemek; böylece ekran okuyucu kullanıcıları aynı bilgiyi alamaz.
• Bir <ul> üzerinde CSS ile list-style: none uygulamak, ancak bazı ekran okuyucuların (özellikle Safari + VoiceOver) bu durumda öğeyi artık liste olarak duyurmayabileceğini bilmemek — liste anlamı önemliyse, bu anlamı korumak için açıkça role='list' ekleyin.
• Başlık seviyelerini atlamak — örneğin, tasarımcının daha küçük metin istemesi nedeniyle bir <h2>’nin hemen ardından bir <h4> yerleştirmek — bunun yerine doğru başlık seviyesini kullanıp görsel görünümü CSS ile kontrol etmek gerekir.
• Birleştirilmiş hücrelere (colspan/rowspan) sahip karmaşık veri tabloları oluşturmak, ancak veri hücrelerine headers özniteliği eklememek; bu, ekran okuyucu kullanıcılarının belirsiz birleştirilmiş hücreyi hangi başlığın yönettiğini belirleyememesine yol açar.
• Düzen amaçlı <table> öğeleri kullanmak ve ardından role='presentation' rolünü tutarsız biçimde eklemek — bazı hücreler hâlâ bağlam dışı duyurulan başlıklar içerir ve tablonun tamamen dekoratif olduğunu göremeyen kullanıcıları şaşırtır.
• Bir <dt>/<dd> çiftini, doğrudan bir <dl>’nin altı olan bir <p> veya <div> içine sarmak, ancak HTML5’te <dl> içinde yalnızca <div> sarmalayıcıların izinli olduğunu ve diğer blok öğelerin karıştırılmasının tanım listesi yapısını bozduğunu bilmemek.
• Bir input üzerinde, DOM’da var olmayan bir kimliğe referans veren aria-labelledby eklemek veya metin olmayan bir öğenin kimliğine referans vermek — hesaplanan erişilebilir ad boş olur ve input, yardımcı teknolojiler için fiilen etiketsiz hâle gelir.
• Bir sayfanın görsel olarak doğru göründüğü ve Lighthouse puanının 90’ın üzerinde olduğu için 1.3.1’e uyduğunu varsaymak — otomatik araçlar, ARIA rol hiyerarşisinde yansıtılmayan görsel iç içe ilişkiler gibi her yapısal ihlali tespit edemez; bu nedenle manuel ve ekran okuyucu doğrulaması zorunludur.

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 WCAG 2.2 ile uyumlu zorunlu web erişilebilirliği yükümlülükleri getirir. WCAG 1.3.1 bir Seviye A ölçütüdür; bu, uyumun temel katmanında — asgari kabul edilebilir erişilebilirlik düzeyinde — yer aldığı ve bu nedenle genelge kapsamındaki tüm kuruluşlar için tamamen zorunlu olduğu anlamına gelir.

Genelge iki uyum takvimi tanımlar. Merkezi idare kurumları, belediyeler, devlet üniversiteleri ve kamu hastaneleri dâhil kamu kurumları, genelgenin yürürlüğe girmesinden itibaren bir yıl içinde tam Seviye A uyumuna ulaşmak zorundadır. Düzenleme kapsamındaki özel sektör kuruluşlarının uyum için iki yıllık bir süresi vardır. Ancak yükümlülük her iki grup için de isteğe bağlı değildir: uyumsuzluk, kapsam dâhilindeki kuruluşları düzenleyici incelemeye ve olası yaptırım işlemlerine maruz bırakır.

Genelgede açıkça belirtilen özel sektör kuruluşları arasında e-ticaret platformları, bankalar ve finans kuruluşları, özel 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) izniyle faaliyet gösteren özel okullar yer alır. Bu kuruluşlardan herhangi biri, kamuya açık bir web sitesi veya mobil web uygulaması işletiyorsa, dijital varlıklarının tamamında 1.3.1’in sağlandığından emin olmalıdır.

Pratik uyum açısından, 1.3.1, temel sayfa yapısını düzenlediği için en etkili Seviye A ölçütlerinden biridir. Ürün kategori sayfalarında başlıklar için stillendirilmiş <div> öğeleri kullanan, ödeme formu girdilerinde etiket ilişkileri bulunmayan veya sipariş özetini scope öznitelikleri olmayan yapılandırılmamış bir tabloyla sunan bir Türk e-ticaret sitesi, 1.3.1’i kapsamlı biçimde ihlal eder. Düzeltme yalnızca yasal bir yükümlülük değildir — çevrimiçi alışveriş yapmak, bankacılık işlemleri gerçekleştirmek, sağlık hizmetlerine erişmek ve kamu hizmetleriyle çevrimiçi etkileşim kurmak için yardımcı teknolojilere güvenen, Türkiye’deki tahmini 700.000 veya daha fazla kör ve az gören bireyin deneyimini doğrudan iyileştirir.

Uyumu belgelemek isteyen kuruluşlara, dijital içeriklerinin tamamını kapsayan hem otomatik axe-core taramaları hem de manuel ekran okuyucu denetimleri yapmaları tavsiye edilir. 1.3.1’in zorunlu kıldığı yapısal erişilebilirlik, içerik oluşturulup güncellenirken uyumun sürdürülebilmesi için tasarım sistemlerine ve bileşen kütüphanelerine yerleştirilmelidir; tek seferlik bir düzeltme çalışması olarak ele alınmamalıdır.