Web Erişilebilirliğinin Temelleri (WCAG 2.2)

Sonradan eklenen bir katman değil

Erişilebilirlik çoğu projede yayın öncesi son haftaya sıkışır: birkaç alternatif metin yazılır, bir kontrast aracı çalıştırılır, denetim puanı yeşile yaklaşınca iş bitmiş sayılır. Oysa işin büyük kısmı en başta, işaretlemeyi (markup) yazarken kazanılır ya da kaybedilir. Sonradan yamamak hem pahalıdır hem de nadiren gerçekten işe yarar.

Bu yazıda WCAG 2.2 AA seviyesinin pratikte ne istediğini, her projede uyguladığım maddelerle anlatıyorum. Amacım standardı ezberletmek değil; hangi kararın hangi kullanıcıya ne kazandırdığını göstermek.

Türkiye bağlamı: neden şimdi?

Erişilebilirlik bir "iyilik" değil, üç ayrı gerekçesi olan bir gerekliliktir:

• Kitle: Türkiye'de engelli nüfus milyonlarla ifade ediliyor. Buna geçici (kırık kol) ve durumsal (güneş altında telefona bakmak) engelleri de eklemek gerekir. Erişilebilir arayüzden faydalanan kitle, "engelli kullanıcı" etiketinden çok daha geniştir.
• Yasal çerçeve: Kamu hizmetlerinde erişilebilirlik yükümlülükleri artıyor; kamuya iş yapan ya da Avrupa pazarına satan şirketler için erişilebilirlik giderek bir uyum ve ihale şartına dönüşüyor.
• Yan fayda: Anlamlı başlık yapısı, açıklayıcı bağlantı metni ve gerçek metin içeriği aynı zamanda arama motorlarının anladığı sinyallerdir. Erişilebilirlik ile SEO büyük ölçüde aynı temele basar.

Anlamlı HTML: en ucuz erişilebilirlik

Ekran okuyucular sayfayı görünüşünden değil yapısından okur. Doğru etiketi seçmek, sonradan yazılacak onlarca satır ARIA'dan daha değerlidir.

• Sayfada tek bir h1 olsun; başlıklar seviye atlamadan sıralansın.
• Yer imleri (landmark) gerçek etiketlerle verilsin: header, nav, main, footer.
• Tıklanabilir her şey doğru elemanı kullansın: gezinme için bağlantı, işlem tetiklemek için buton.
• Liste liste etiketiyle, veri tablosu tablo etiketiyle işaretlensin.
• Sayfanın başında ana içeriğe atlayan bir bağlantı (skip link) bulunsun.

<a class="skip-link" href="#icerik">İçeriğe geç</a>
<header>…</header>
<nav aria-label="Ana menü">…</nav>
<main id="icerik">
  <h1>Sayfa başlığı</h1>
</main>

En sık gördüğüm hata, bir kutuya tıklama olayı bağlayıp onu buton gibi göstermek. Görsel olarak buton gibi durur ama klavyeyle odaklanamaz, ekran okuyucu onu "buton" diye duyurmaz, Enter tuşu çalışmaz. Doğru elemanı seçmek bu üç sorunu birden bedavaya çözer.

Klavye ile baştan sona

Basit bir test: farenin fişini çek. Sekme tuşuyla sitede baştan sona dolaşabiliyor musun?

• Tüm etkileşimli öğeler sekme sırasına dâhil olmalı ve sıra görsel düzenle uyumlu ilerlemeli.
• Odak hiçbir yerde kilitlenmemeli. Tek istisna, açıkken odağı içinde tutması gereken modaldır; kapanınca odak kendisini açan öğeye dönmelidir.
• Fareyle yapılabilen her işlem klavyeyle de yapılabilmeli. Yalnızca üzerine gelince açılan menüler klavye kullanıcısını dışarıda bırakır.
• WCAG 2.2 ile gelen bir madde: sürükle-bırakla yapılan işlemin tek işaretçili bir alternatifi olmalı (taşı düğmesi, yukarı/aşağı okları gibi).

Odak görünürlüğü

Odak halkasını estetik kaygısıyla silmek, klavye kullanıcısını kör etmektir. Doğrusu halkayı kaldırmak değil, markaya uygun hâle getirmektir:

:focus-visible {
  outline: 3px solid var(--color-accent);
  outline-offset: 2px;
}

WCAG 2.2 ayrıca odaklanan öğenin sabit başlık, çerez çubuğu ya da sohbet balonu tarafından örtülmemesini ister. Sekmeyle gezerken öğenin yapışkan başlığın altında kaybolduğu sayfalar bu ölçütte kalır.

Kontrast: okunabilirlik pazarlık konusu değil

AA seviyesi normal metin için 4.5:1, büyük metin için 3:1 kontrast ister. Sık atlanan iki nokta var:

• Metin dışı öğeler de sayılır. Form alanı kenarlığı, ikon, grafik göstergesi ve odak halkası için de en az 3:1 gerekir.
• Durumlar unutulur. Pasif (disabled) görünüm, yer tutucu metin ve üzerine gelince değişen renkler ayrı ayrı kontrol edilmelidir.

Pratik kural: bir rengi sistemin metin rengi olarak kabul etmeden önce zeminle oranını ölç. Bu projede de canlı bir vurgu tonunu yalnızca dolgu ve degrade içinde kullanıyorum; ince metin ya da tek başına kenarlık rengi olarak asla. Kontrast eşiğini token düzeyinde garanti altına almanın yolunu tasarım sisteminden production'a tutarlılık yazısında anlattım.

Bir de renk körlüğü boyutu var: bilgiyi yalnızca renkle taşıma. "Kırmızı alanlar hatalı" yerine hata ikonu ve açıklayıcı metin de ekle.

Alternatif metin: neyi anlatıyor?

Alternatif metin "görselde ne var" değil, "bu görsel burada ne iş yapıyor" sorusunun cevabıdır.

• Bilgi taşıyan görsel: işlevi anlat. Bir grafik için "satışlar çeyrek bazında arttı" demek, "çubuk grafik" demekten iyidir.
• Dekoratif görsel: boş alternatif metin ver ve erişilebilirlik ağacından gizle. Süs amaçlı ikonu okutmak gürültüdür.
• Bağlantı içindeki görsel: metin görseli değil hedefi anlatmalıdır.
• Metin içeren görsel: metni mümkünse gerçek metne çevir; olmuyorsa tamamını alternatif metne taşı.

Aynı mantık bağlantı metinleri için de geçerli. Ekran okuyucu kullanıcıları sayfadaki bağlantıları liste hâlinde gezebilir; "buraya tıklayın" yazan on bağlantıdan oluşan bir liste hiçbir şey söylemez. Bağlantı metni tek başına anlamlı olsun.

Formlar: etiket, hata ve yardım metni

Form, erişilebilirlik hatalarının en yoğunlaştığı yer — ve dönüşümü en doğrudan etkileyen yer.

• Her alanın görünür bir etiketi olsun; yer tutucu metin etiket yerine geçmez, yazmaya başlayınca kaybolur.
• Etiket alana programatik olarak bağlansın; etikete tıklayınca alan odaklanmalı.
• Yardım metni ve hata mesajı alana aria-describedby ile bağlansın ki okuyucu ikisini birlikte duyursun.
• Hata mesajı ne olduğunu ve nasıl düzeltileceğini söylesin: "Geçersiz" değil, "E-posta adresi ad@site.com biçiminde olmalı".
• Hata özeti sayfanın başında veriliyorsa ilgili alana bağlantı içersin.
• Doğrulama sonucu yalnızca renkle değil, ikon ve metinle de bildirilsin.

<label for="eposta">E-posta</label>
<input id="eposta" type="email" aria-describedby="eposta-yardim eposta-hata" />
<p id="eposta-yardim">Sana yalnızca bu proje hakkında yazacağım.</p>
<p id="eposta-hata" role="alert">E-posta adresi ad@site.com biçiminde olmalı.</p>

WCAG 2.2 iki yeni madde daha getirdi: aynı bilgiyi tekrar girmeye zorlamamak (adres, e-posta gibi alanları önceki adımdan taşı) ve girişte bilişsel bulmaca dayatmamak (parola yapıştırmayı engellemek, bulmaca çözdürmek gibi).

ARIA'yı ne zaman KULLANMAMALI?

En sık verdiğim tavsiye şu: ARIA'yı azalt. Standardın kendi ifadesiyle, hiç ARIA kullanmamak yanlış ARIA kullanmaktan iyidir.

• Doğal karşılığı olan yerde ARIA kullanma; buton varken ona ayrıca buton rolü vermek gereksizdir.
• Var olan anlamı ezme. Bir başlığa yanlış rol vermek ekran okuyucunun sayfa haritasını bozar.
• aria-label ile görünen metni çeliştirme; sesle kontrol eden kullanıcı gördüğü metni söyler.
• aria-hidden yalnızca gerçekten dekoratif öğeye. Odaklanabilir bir öğeyi gizlemek klavye kullanıcısını çıkmaza sokar.
• Canlı bölge (aria-live) her değişiklik için değil, kullanıcının kaçırmaması gereken bildirimler için kullanılır.

ARIA'nın asıl yeri, HTML'de doğal karşılığı olmayan bileşenlerdir: sekme grupları, açılır menüler, birleşik kutular. Orada da klavye davranışını kendin yazmak zorundasın; rol vermek tek başına yetmez.

Hareket duyarlılığı ve zaman baskısı

Büyük paralaks ve otomatik oynayan animasyonlar bazı kullanıcılarda baş dönmesi ve mide bulantısı yaratır. Çözüm animasyondan vazgeçmek değil, kullanıcının tercihine saygı duymaktır:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Bu tercihi işleten arayüzde ağır sahneler statik bir görünüme düşer, içerik aynı kalır. Yanına iki madde daha ekle: otomatik oynayan video ve karusel durdurulabilir olsun; süreli bir işlem varsa kullanıcıya süreyi uzatma hakkı verilsin.

Dokunma hedefi ve işaretçi

WCAG 2.2'nin en somut yeniliklerinden biri hedef boyutu: etkileşimli öğeler en az 24×24 piksellik bir alan sunmalı ya da yeterli boşlukla ayrılmalı. Pratikte ben yönetim arayüzlerindeki sık kullanılan aksiyonları daha da büyük tutuyorum; küçük ikon butonların yan yana dizildiği satırlar en çok yanlış tıklama üreten yerdir.

Bir de ikili işaretçi kuralı: dokunmatikte çalışan her şey klavye ve fareyle de çalışmalı. Yalnızca uzun basmayla ya da yalnızca çift tıklamayla ulaşılan işlev bırakma.

Test: otomatik araç nereye kadar?

Otomatik denetim araçları (Lighthouse, axe) değerlidir ama erişilebilirlik sorunlarının yalnızca bir kısmını yakalar. Kalanı elle test ister:

1. Klavye turu: fareyi bırak, sekme ile baştan sona geç.
2. Yakınlaştırma: sayfayı %200 büyüt. İçerik taşıyor mu, yatay kaydırma çıkıyor mu?
3. Ekran okuyucu: Windows'ta NVDA, macOS ve iOS'ta VoiceOver, Android'de TalkBack. Yarım saatlik bir deneme bile bakış açını değiştirir.
4. Renksiz bakış: sayfayı gri tonlamada aç; bilgi hâlâ anlaşılıyor mu?
5. Gerçek cihaz: küçük ekranda dokunma hedefleri ve odak sırası masaüstünden farklı davranır.

Bu turu yayın öncesi bir kez değil, her önemli arayüz değişikliğinden sonra yapmak gerekir.

Yayın öncesi kontrol listesi

• Tek h1, sıralı başlıklar, gerçek yer imleri, çalışan skip link.
• Klavyeyle tam gezinti; görünür ve örtülmeyen odak.
• Metinde 4.5:1, arayüz öğelerinde 3:1 kontrast; bilgi yalnızca renkle taşınmıyor.
• Anlamlı alternatif metinler; dekoratifler erişilebilirlik ağacında gizli.
• Görünür etiket, bağlı yardım ve hata metni, düzeltmeyi anlatan mesaj.
• ARIA minimumda; doğal HTML tercih edilmiş.
• Azaltılmış hareket tercihine saygı; otomatik hareket durdurulabilir.
• Dokunma hedefleri yeterli büyüklükte ve aralıklı.
• Ekran okuyucuyla en az bir kritik akış denenmiş.

Erişilebilirlik ürünü kısıtlamaz, kapsamını büyütür. Aynı kararlar mobil kullanıcıyı, yaşlanan gözü, kötü ışıkta bakan herkesi kapsar — ve doğrudan dönüşüme de yansır.

Mevcut sitende bu maddelerin nerede kırıldığını birlikte geçirebiliriz; genelde birkaç yapısal düzeltme hem denetim puanını hem deneyimi belirgin biçimde yukarı taşır. UI/UX tasarım yaklaşımıma göz atabilir ya da bir proje konuşmak için yazabilirsin.