Web Erişilebilirliği ve WCAG Temelleri: HTML Yazanlar İçin Rehber

Ölçütler ve A, AA, AAA seviyeleri

Her ilke yönergelere (guideline), her yönerge de numaralı başarı ölçütlerine (success criteria) ayrılır. "1.4.3 Minimum kontrast (AA)" gibi bir ölçütün numarası ilkeyi (1: Algılanabilir), yönergeyi (1.4) ve ölçütün sırasını gösterir; parantezdeki harf ise uygunluk seviyesidir. A en temel seviyedir, AA onun üzerine ek gereksinimler koyar, AAA en sıkı seviyedir. MDN'nin tablolarında bazı AAA ölçütleri, bir A veya AA ölçütünün "daha ileri adımı" olarak tanımlanır: örneğin 2.1.3, 2.1.1'deki klavye erişimini istisnasız hale getirir.

1. Algılanabilir: metin alternatifleri, altyazı, renk

Bu ilkenin çıkış noktası, metnin başka biçimlere çevrilebilmesidir: ekran okuyucu seslendirebilir, büyük puntoya dönüştürülebilir, braille ekranda gösterilebilir. Bu yüzden 1.1.1 (A) ölçütü anlam taşıyan her görselin uygun bir alternatif metne sahip olmasını ister. Karmaşık grafikler için aynı sayfada ya da bir bağlantıyla erişilebilir bir alternatif (metin açıklaması veya erişilebilir bir veri tablosu) sunulmalıdır; MDN longdesc özniteliği yerine normal bir bağlantı önerir. Süs görselleri ise yardımcı teknolojiye görünmemelidir: CSS arka planı olarak eklenir ya da <img> ile ekleniyorsa alt="" verilir; aksi halde ekran okuyucu dosya yolunu okumaya çalışabilir.

<!-- Anlam tasiyan gorsel -->
<img src="grafik.png" alt="2026 yılı aylık ziyaretçi sayısı: ocaktan hazirana düzenli artış" />
<p><a href="ziyaretci-tablosu.html">Grafiğin veri tablosu</a></p>

<!-- Sus gorseli: bos alt -->
<img src="ayirici.png" alt="" />

<!-- Dugme metni islevi anlatir -->
<button type="submit">Görseli yükle</button>

1.2 yönergesi zamana bağlı medya içindir. Önceden kaydedilmiş yalnızca ses içeriği için transkript, web'deki video için altyazı (1.2.2, A), transkript veya sesli betimleme (1.2.3, A) istenir; canlı ses içeren yayınlar için senkron altyazı ve önceden kaydedilmiş videoya sesli betimleme AA seviyesindedir. HTML tarafında altyazı <track> öğesiyle eklenir; ayrıntılar video ve audio etiketi yazısında.

1.3 yönergesi içeriğin farklı biçimlerde sunulabilmesini ister. 1.3.1 (A), görsel olarak kurulan ilişkilerin kodda da belirlenebilir olmasını söyler: etiket ile alan <label> ile bağlanmalı, sıralı listeler <ol> ile yazılmalıdır. 1.3.2 (A) okuma sırasının anlamlı olmasını, 1.3.3 (A) talimatların tek bir duyuya dayanmamasını ister: "yuvarlak düğmeye tıklayın" veya "sesli yönergeyi dinleyin" tek başına yeterli değildir. 1.3.5 (AA), alanların amacının programatik olarak belirlenmesini ister; bunun HTML'deki karşılığı autocomplete belirteçleridir (autocomplete yazısı).

1.4 yönergesi renk ve kontrastla ilgilidir. 1.4.1 (A) bilginin yalnızca renkle verilmemesini ister: zorunlu alanları sadece kırmızıyla işaretlemek yerine yıldız işaretiyle birlikte "zorunlu" metni de kullanın. 1.4.3 (AA) normal metin ile arka plan arasında en az 4.5:1, büyük metin (en az 18 punto veya kalın 14 punto) için en az 3:1 kontrast ister; AAA seviyesindeki 1.4.6 bu oranları 7:1 ve 4.5:1'e çıkarır. 1.4.4 (AA) metin boyutu iki katına çıktığında sayfanın okunur ve kullanılabilir kalmasını, 1.4.10 (AA) yatay kaydırma gerektirmeden yeniden akışı (büyük veri tabloları gibi istisnalarla), 1.4.11 (AA) arayüz bileşenleri ve grafik nesneler için en az 3:1 kontrastı ister.

<label for="ad-soyad">
  Ad soyad <span aria-hidden="true">*</span>
  <span class="gorunmez-metin">(zorunlu)</span>
</label>
<input id="ad-soyad" name="ad-soyad" required />

Bu örnekte zorunluluk bilgisi rengin yanında metinle de veriliyor; required özniteliği tarayıcıya ve yardımcı teknolojiye de aynı bilgiyi iletir. "gorunmez-metin" sınıfının görsel olarak nasıl gizleneceği bir CSS konusudur; önemli olan bilginin yalnızca renge emanet edilmemesidir.

2. Kullanılabilir: klavye, zaman, gezinme

2.1.1 (A) tüm işlevlerin klavyeyle kullanılabilmesini ister (serbest çizim gibi doğası gereği klavyeyle yapılamayan işler hariç) ve MDN burada yerleşik denetimleri kullanmayı, özel işlevi yalnızca gerektiğinde yazmayı önerir. 2.1.2 (A) klavye tuzağını yasaklar: klavyeyle girdiğiniz bir bölümden yine yalnızca klavyeyle çıkabilmelisiniz; örneğin Enter ile açılan bir seçenek penceresi klavyeyle kapatılabilmeli ve odak ana içeriğe dönebilmelidir. 2.1.4 (A), tek karakterlik kısayollar varsa bunların kapatılabilmesini, yeniden atanabilmesini veya yalnızca ilgili bileşen odaktayken etkin olmasını ister.

2.2 yönergesi zamanla ilgilidir. 2.2.1 (A) zaman sınırı olan işlerde kullanıcının süreyi ayarlayabilmesini, uzatabilmesini veya kapatabilmesini ister (20 saatten uzun sınırlar ve gerçek zamanlı olaylar gibi istisnalarla). 2.2.2 (A) kendiliğinden başlayan, 5 saniyeden uzun süren ve başka içerikle birlikte gösterilen hareketli veya yanıp sönen içerik için duraklatma, durdurma veya gizleme denetimi ister; kayan metinler ve döner banner'lar bunun tipik örnekleridir. 2.3.1 (A) saniyede üçten fazla yanıp sönen içerikten kaçınmayı (veya eşiklerin altında kalmayı) ister.

2.4 yönergesi gezinmeyle ilgilidir ve HTML'e en çok dokunan bölümdür. 2.4.1 (A) tekrar eden bloklardan (logo, menü) doğrudan ana içeriğe atlama yolu ister; bu genellikle sayfa kaynağının başına konan bir "atlama bağlantısı" ile yapılır. MDN'ye göre başlıklar ve semantik kapsayıcılarla düzgün bir yapı kurulduysa ayrıca atlama bağlantısına gerek kalmayabilir. 2.4.2 (A) her sayfada içeriği anlatan bir <title> ister, 2.4.3 (A) odak sırasının mantıklı olmasını, 2.4.4 (A) bağlantının amacının bağlantı metninden veya çevresinden anlaşılmasını, 2.4.6 (AA) başlık ve etiketlerin amacı açıkça anlatmasını, 2.4.7 (AA) odaklanan öğenin görünür bir göstergesi olmasını ister.

<body>
  <a href="#icerik">Ana içeriğe atla</a>
  <header>
    <nav aria-label="Ana menü">
      <a href="/">Anasayfa</a>
      <a href="/blog">Blog</a>
    </nav>
  </header>
  <main id="icerik">
    <h1>Hosting paketleri karşılaştırması</h1>
    <p>Paketlerin ayrıntılı özelliklerini <a href="/paketler">paket karşılaştırma sayfasında</a> bulabilirsiniz.</p>
  </main>
</body>

Bu örnekteki bağlantı metni "buraya tıklayın" değil, hedefi anlatan bir ifadedir. MDN, ekran okuyucu kullanıcılarının bağlantıları çoğu zaman bağlamından kopuk bir liste halinde açtığını, bu listede art arda "buraya tıklayın" görmenin kafa karıştırdığını not eder. MDN tablosundaki daha yeni ölçütlerden 2.4.11 (AA) klavye odağı alan bileşenin, yazarın eklediği içerik tarafından tamamen örtülmemesini; 2.5.8 (AA) işaretçi hedeflerinin en az 24 x 24 CSS pikseli olmasını (yeterli aralık, aynı işi yapan eşdeğer bir denetim, metin satırı içindeki hedefler gibi istisnalarla) ister. 2.5.3 (A) ise görünür etiketi olan bileşenlerde erişilebilir adın bu etiketi içermesini ister.

Klavye erişimi için HTML kuralları

MDN'nin klavye erişimi sayfası, yalnızca klavye kullananların (ekran okuyucu kullanıcıları, fare kullanmakta zorlananlar ya da klavyeyi tercih edenler) sayfayı tam olarak kullanabilmesi için birkaç kural sıralar:

• Klavyeyle odaklanabilen bir öğe etkileşimli olmalıdır; kullanıcı onunla bir şey yapabilmeli ve bir değişiklik görmelidir. tabindex="0" yalnızca öğeye gerçekten etkileşim (örneğin klavye olay işleyicileri) eklediyseniz verilmelidir.
• Sıfırdan büyük tabindex kullanmaktan kaçının. Pozitif değerler öğeyi varsayılan sıranın önüne alır ve odak sırası sayfanın mantıksal sırasından kopar. Bunun yerine HTML'deki sırayı düzeltin.
• Fareyle tıklanabilen her öğe klavyeyle de odaklanabilmeli ve etkinleştirilebilmelidir; tıklama işleyicisi tanımladıysanız aynı işi yapan bir klavye işleyicisi de tanımlayın.
• Odaklanabilen her öğenin görünür bir odak stili olmalıdır. Bağlantı ve form alanı gibi standart öğelere tarayıcı varsayılan bir stil verir; kendi bileşenlerinizde bunu siz tanımlayın.

Bu kuralların en kolay yolu yine yerel öğelerdir: <button>, <a> ve form alanları odaklanabilir, klavyeyle etkinleşir ve tarayıcının odak göstergesini taşır. tabindex değerlerinin ayrıntıları ve odak yönetimi tabindex ve klavye erişimi yazısında, modal pencerelerde odak davranışı dialog etiketi yazısında.

3. Anlaşılabilir: dil, öngörülebilirlik, hata yardımı

3.1.1 (A), her sayfanın varsayılan dilinin kodla belirlenebilmesini ister; en basit yolu <html> öğesine lang özniteliği vermektir. 3.1.2 (AA), sayfanın ana dilinden farklı bir dildeki sözcük veya ifadeleri kendi lang değeriyle işaretlemenizi ister; MDN, dilden bağımsız özel adlar ve teknik terimler için buna gerek olmadığını belirtir. Ayrıntılar lang ve dir yazısında.

<html lang="tr">
  <head>
    <meta charset="utf-8" />
    <title>Sipariş formu - Örnek Mağaza</title>
  </head>
  <body>
    <p>Ödeme sayfasında <span lang="en">checkout</span> adımı tek ekranda toplanır.</p>
  </body>
</html>

3.2 yönergesi öngörülebilirliktir. 3.2.1 (A) bir öğe odak aldığında bağlamın kullanıcıyı şaşırtacak biçimde değişmemesini, 3.2.2 (A) bir alana veri girildiğinde veya bir ayar değiştirildiğinde bağlamın beklenmedik biçimde değişmemesini ister. 3.2.3 ve 3.2.4 (AA) gezinme menülerinin ve aynı işi yapan bileşenlerin sayfalar arasında tutarlı olmasını, 3.2.6 (A) ise birden fazla sayfada tekrar eden yardım mekanizmalarının aynı sırada yer almasını ister.

3.3 yönergesi hata önlemeyle ilgilidir ve formlar için doğrudan HTML'e yansır. 3.3.1 (A) algılanan hatanın hangi alanla ilgili olduğuyla birlikte açıkça bildirilmesini ister; MDN istemci tarafı doğrulamanın kolayca kapatılabileceğini, bu yüzden sunucu tarafı doğrulamanın her zaman birlikte kullanılması gerektiğini vurgular. 3.3.2 (A) veri girişi gerektiğinde açık talimat ister: tek alanlar için <label>, birlikte doldurulan alanlar (doğum tarihi, adres) için <fieldset> ve <legend>. 3.3.3 (AA) düzeltme önerisi bilinen hatalarda öneri sunmayı, 3.3.4 (AA) hukuki, mali veya kişisel veri içeren işlemlerde geri alınabilirlik, kontrol veya son onay adımı ister. 3.3.7 (A) aynı süreçte daha önce girilen bilginin tekrar istenmemesini, 3.3.8 (AA) ise kimlik doğrulamada şifre hatırlama gibi bilişsel testlerin, kopyala yapıştır veya şifre yöneticisi gibi bir yardımcı olmadan zorunlu tutulmamasını ister.

4. Sağlam: geçerli HTML, ad, rol ve değer

MDN'nin "Sağlam" özeti üç ölçüt sayar. 4.1.1 (A) içeriğin tarayıcılar ve ekran okuyucular tarafından sorunsuz ayrıştırılabilmesi için iyi biçimlendirilmiş olmasını ister; MDN, HTML'inizi mümkün olduğunca geçerli tutmanızı ve W3C doğrulayıcısını kullanmanızı önerir. 4.1.2 (A) form alanları, düğmeler ve bağlantılar gibi bileşenlerin ad ve rolünün programatik olarak belirlenebilmesini ister: semantik öğeleri amacına uygun kullandığınızda bu ölçüt kendiliğinden karşılanır, özel bileşen yazıyorsanız WAI-ARIA rolleri gerekir. 4.1.3 (AA) sayfaya eklenen yeni durum mesajlarının yardımcı teknoloji kullanıcılarına bildirilmesini ister; bunun aracı canlı bölgelerdir. Geçersiz iç içe kullanım ve tekrar eden id gibi ayrıştırma hataları için sık yapılan HTML hataları yazısına bakın.

Canlı bölgeler: değişiklikleri duyurmak

JavaScript ile sayfanın bir kısmı yenilendiğinde (arama sonuçları, sepet sayısı, kaydedildi bildirimi) gören kullanıcı değişikliği fark eder ama ekran okuyucu kullanıcısı fark etmeyebilir. MDN'ye göre ARIA canlı bölgeleri bu boşluğu doldurur. En önemli öznitelik aria-livedır ve üç değer alır: polite değişikliği kullanıcı boştayken okur ve normalde kullanılması gereken değerdir; assertive o anki duyuruyu keser, yalnızca acil ve zaman kritik bildirimlerde idareli kullanılmalıdır; off ise sezgiye aykırı biçimde "hiç duyurma" demek değildir, değişiklik yalnızca odak bölgenin içindeyken duyurulur.

<form action="/ara" method="get">
  <label for="arama">Alan adı ara</label>
  <input type="search" id="arama" name="q" />
  <button type="submit">Ara</button>
</form>

<!-- Bolge baslangicta bos ve sayfanin ilk HTML'inde bulunuyor -->
<p id="durum" role="status" aria-live="polite"></p>

MDN'nin canlı bölge rehberindeki pratik kurallar şunlardır. Yardımcı teknolojiler genellikle yalnızca bölgenin içeriğindeki dinamik değişiklikleri duyurur; bu yüzden bölgeyi önce kurun, sonra içeriğini güncelleyin. En güvenilir yol bölgeyi sayfanın ilk HTML'ine boş olarak koymaktır. Bölgeyi JavaScript ile oluşturuyorsanız içerik güncellemesini sonraki bir olay döngüsü adımına (örneğin setTimeout() ile) erteleyin. Canlı bölgeler genellikle düz metin olarak duyurulur; içerideki bağlantı ve düğmelerin anlamı duyuruya yansımayabilir.

Bazı roller örtük olarak canlı bölgedir: status (durum çubuğu), log (sohbet veya hata günlüğü), alert (önemli uyarı), timer, marquee ve progressbar. MDN status ve log için uyumluluğu artırmak üzere fazladan aria-live="polite" eklemeyi önerir. alert rolünde ise dikkatli olun: MDN, alert ile birlikte aria-live kullanmanın iOS'taki VoiceOver'da çift okumaya yol açtığını not eder. aria-atomic="true" bölgenin yalnızca değişen kısmı yerine tamamının okunmasını sağlar (MDN'nin saat örneğinde "17:34" yerine yalnızca "34" duyurulmasını engeller); aria-relevant ise hangi tür değişikliklerin (additions, removals, text, all) duyurulacağını belirler, varsayılanı additions text değeridir.

Mobil erişilebilirlik kontrol listesi

MDN'nin mobil uygulama geliştiricileri için hazırladığı kontrol listesi, yukarıdaki ölçütlerin dokunmatik cihazlardaki karşılığını özetler:

• Renk: kontrast WCAG 2.2 AA düzeyini karşılamalı (normal metin 4.5:1, büyük metin 3:1); renkle verilen bilgi başka bir yolla da verilmeli (bağlantılarda alt çizgi gibi).
• Görünürlük: o an görünmeyen ekranlar gerçekten gizlenmeli (hidden özniteliği veya display/visibility); sıfır opaklık, z-index sırası veya ekran dışına itme tek başına kullanılmamalı; kaçınılmaz olmadıkça aria-hidden kullanılmamalı.
• Odak: etkinleştirilebilen her öğe odaklanabilmeli; standart olmayan denetimlere button, link veya checkbox gibi uygun bir ARIA rolü verilmeli; odak mantıklı ve tutarlı bir sırada ilerlemeli.
• Metin eşdeğerleri: süs olmayan her metin dışı öğe için metin eşdeğeri; metin görsellerinden kaçınma; görünür etiketin programatik adda da yer alması; her form alanı için <label>.
• Durum: standart olmayan denetimlerde durum değişiklikleri aria-checked, aria-disabled, aria-selected, aria-expanded ve aria-pressed ile bildirilmeli.
• Yönlendirme: içerik, zorunlu olmadıkça (piyano uygulaması gibi) dikey veya yatay tek bir yöne kilitlenmemeli.
• Genel: uygulamanın bir başlığı olmalı, başlık hiyerarşisi bozulmamalı, banner, main, navigation gibi yer işaretleri kullanılmalı, dokunma hedefleri yeterince büyük olmalı ve işlev dokunmanın başladığı anda değil bittiği anda tamamlanmalı.

Görünüm alanı ve duyarlı tasarımın genel mantığı için mobil uyumluluk yazısına bakabilirsiniz.

HTML yazarken hızlı WCAG kontrolü

• <html> öğesinde lang var mı, her sayfanın anlamlı bir <title> öğesi var mı?
• Başlıklar <h1> ile başlayıp seviye atlamadan ilerliyor mu? (başlık etiketleri)
• Her görselin uygun bir alt değeri, süs görsellerinin boş alt değeri var mı?
• Her form alanı bir <label> ile bağlı mı, hata mesajları alanla ilişkilendirilmiş mi?
• Tüm işlevler yalnızca klavyeyle kullanılabiliyor mu, odak görünür mü, pozitif tabindex var mı?
• Bağlantı metinleri hedefi anlatıyor mu?
• Videoların altyazısı, ses kayıtlarının transkripti var mı?
• Dinamik bildirimler bir canlı bölgede mi?
• HTML bir doğrulayıcıdan hatasız geçiyor mu?

Sık Sorulan Sorular

Hangi WCAG sürümünü hedeflemeliyim?

MDN'ye göre yeni sürümler eskilerin yerini almak için değil üzerine eklemek için yayımlanır ve WAI, en iyi erişilebilirlik için en güncel sürümü (şu an 2.2) kullanmayı önerir. WCAG 3.0 henüz çalışma taslağıdır.

AA seviyesi ne demek?

A ve AA seviyesindeki başarı ölçütlerinin birlikte karşılanması demektir. Hangi seviyenin sizin için zorunlu olduğu bulunduğunuz ülkenin mevzuatına bağlıdır; MDN bu konuda hukuki tavsiye vermediğini açıkça belirtir.

Semantik HTML yazmak WCAG için yeterli mi?

Çok şeyi kendiliğinden karşılar: 4.1.2 ad, rol ve değer ölçütü semantik öğeler doğru kullanıldığında otomatik olarak karşılanır, klavye erişimi de yerel denetimlerle gelir. Ama alt metinlerin içeriği, kontrast, altyazı ve hata mesajlarının açıklığı gibi konular içerik ve tasarım kararlarıdır.

aria-live="assertive" ne zaman kullanılır?

Yalnızca kullanıcının hemen dikkatini gerektiren, zaman kritik bildirimlerde. Assertive bir güncelleme ekran okuyucunun o anki duyurusunu keser; MDN bunun çok rahatsız edici olabileceğini ve idareli kullanılması gerektiğini vurgular.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: HTML öğrenme rehberi · ARIA nedir · erişilebilir ad · tabindex ve klavye erişimi · lang ve dir · form doğrulama · mobil uyumluluk