Temel çıkarım: WCAG 2.2 AA, çoğu AB erişilebilirlik yasasının işaret ettiği teknik standarttır ve dört ilkeye dayanır — algılanabilir, işletilebilir, anlaşılabilir, sağlam — ama pratikte, çoğu WordPress sitesi küçük, tekrarlanabilir bir sorun setinde başarısız olur: renk kontrastı, eksik alt metin, klavye navigasyonu boşlukları ve bozuk başlık hiyerarşisi.
Bu Neden Şimdi Önemli, Gelecekte Değil
Avrupa Erişilebilirlik Yasası (Direktif (AB) 2019/882), 28 Haziran 2025'ten beri yürürlükte, AB tüketicilerine satılan belirli ürün ve hizmet kategorilerinin — e-ticaret, bankacılık, e-kitaplar, ulaşım hizmetleri ve telekomünikasyon bunlar arasında — erişilebilirlik gereksinimlerini karşılamasını gerektiriyor. Artık gelecekteki bir son tarih değil; AB üye devletlerinde zaten aktif bir yasa.
Yasa, EAA'nın kendisi daha geniş yasal dilde yazılmış olsa bile, çoğu kuruluşun uyumluluğu göstermek için kullandığı pratik teknik standart olarak AA uyumluluk seviyesinde WCAG 2.2'ye atıfta bulunuyor. Bu, belirli bir sitenin EAA'nın tam kapsamına girip girmediğinden bağımsız olarak, WCAG 2.2 AA'yı doğru inşa edilmeye değer somut hedef yapıyor.
WCAG 2.2 AA Gerçekte Ne Gerektiriyor
WCAG, gereksinimlerini yaygın olarak POUR olarak kısaltılan dört ilke etrafında düzenler:
- Algılanabilir — içerik, kullanıcıların algılayabileceği şekillerde sunulabilir olmalı, görseller için alt metin ve metin için yeterli renk kontrastı gibi şeyleri kapsar.
- İşletilebilir — arayüz bileşenleri sadece fareyle değil, tek başına klavyeyle de kullanılabilir olmalı, ve kullanıcıların içeriği okuması ve etkileşime girmesi için yeterli zamanı olmalı.
- Anlaşılabilir — içerik ve arayüz davranışı öngörülebilir ve okunabilir olmalı, net form etiketleri ve tutarlı navigasyon dahil.
- Sağlam — içerik, ekran okuyucular gibi yardımcı teknolojiler genelinde güvenilir bir şekilde çalışmalı, bu da büyük ölçüde temiz, semantik HTML'e ve doğru ARIA kullanımına bağlı.
WCAG 2.2, 2.1'in üzerine dokuz yeni başarı kriteri ekledi, birkaçı özellikle mobil ve bilişsel erişilebilirliği hedefliyor — tıklanabilir öğeler için minimum bir hedef boyutu, sayfalar genelinde yardım mekanizmalarının tutarlı yerleşimi, ve klavye kullanıcıları için daha net görünür odak göstergeleri.
En Yaygın WordPress Erişilebilirlik Hataları
Bu sitede tam bir axe-core artı Playwright erişilebilirlik denetimi çalıştırdık — hem karanlık hem aydınlık modda 14 sayfa — ve bulunan sorunlar tamamen siteye özgü olmaktan çok tipik olduğu için bu, WordPress sitelerinin tam olarak nerede başarısız olma eğiliminde olduğuna dair kullanışlı bir gerçek dünya örneği.
- Dekoratif öğelerde renk kontrastı. Kategori etiketleri ve renkli rozetler, tonlanmış arka planlar üzerinde ham marka hex renklerini doğrudan metin rengi olarak kullanıyordu, sadece yaklaşık 3.3-4.0:1'i geçiyordu — AA'da normal metin için 4.5:1 minimumun altında. Çözüm, marka renklerini doğrudan metin olarak yeniden kullanmak yerine ayrı, amaca yönelik "metin-güvenli" renk token'ları tanımlamaktı.
- Başlık hiyerarşisi atlamaları. Bir listeleme sayfası, H1'den doğrudan H3 bölümlere aralarında H2 olmadan atlıyordu, bu görsel olarak görünmez ama ekran okuyucu kullanıcılarının gezinmek için güvendiği mantıksal belge taslağını bozuyor.
- Sadece renkle ayrılan bağlantılar. Daha uzun metin bloklarındaki satır içi bağlantılar çevredeki metinden farklı renkte ama altı çizilmemişti, bağlantı-metin ayrımının sadece renk algısına bağlı olmaması gereksinimini başarısızlığa uğratıyordu.
- Özel etkileşimli bileşenlerde eksik ARIA öznitelikleri. Özel bir SSS akordiyonunda aria-expanded, aria-controls veya role="region" yoktu — bir fare kullanıcısı için işlevsel, ama akordiyonun durumu hakkında hiçbir sinyal olmayan bir ekran okuyucu kullanıcısı için belirsiz.
Bunların hiçbiri sadece sayfaya göz atarak yakalanmadı — kombine otomatik tarama ve manuel inceleme yoluyla yüzeye çıktı, bu da herhangi bir WordPress sitesinde tekrarlanmaya değer bir desen.
Pratik Bir Denetim Süreci
| Adım | Araç/Yöntem | Yakaladığı |
|---|---|---|
| Otomatik tarama | axe-core veya WAVE tarayıcı eklentisi | Eksik alt metin, kontrast hataları, eksik form etiketleri |
| Sadece klavye geçişi | Fare kullanmadan tüm sayfada tab ile gez | Bozuk odak sırası, ulaşılamayan etkileşimli öğeler |
| Ekran okuyucu nokta kontrolü | VoiceOver (Mac) veya NVDA (Windows) | Belirsiz ARIA, kafa karıştırıcı başlık yapısı |
| Manuel kontrast kontrolü | Tarayıcı geliştirici araçları veya bir kontrast denetleyici | Otomatik araçların kaçırdığı durum kontrastı sorunları (hover, focus) |
| İki renk modu da | Yukarıdakilerin hepsini karanlık ve aydınlık modda tekrarla | Sadece bir temada görünen kontrast regresyonları |
Yaygın WordPress'e Özgü Sorun Alanları
- Tema ve page builder varsayılanları genellikle şablonlara gömülü kontrast veya başlık yapısı sorunlarıyla gelir, bu da o şablonu kullanan her sayfada tekrarlanır.
- Eklenti tarafından eklenen widget'lar (slider'lar, akordiyonlar, sekmeler), her eklenti yazarı yardımcı teknolojiyle test etmediği için sıklıkla düzgün ARIA özniteliklerinden yoksundur.
- Alt metinsiz yüklenen görseller, en yaygın ve düzeltilmesi en kolay ihlallerden biridir — bir medya kütüphanesini eksik alt metin için toplu kontrol etmek, yıllarca birikmiş boşlukları bir seferde yakalar. Erdo Image Optimizer, görsel SEO rehberimizde ele aldığımız dosya boyutu optimizasyonunun yanı sıra, tüm medya kütüphanesi genelinde alt metni eksik görselleri işaretleyen yerleşik bir denetim içerir.
- Cookie consent banner'ları ve modal'lar, ana sayfa yüklendikten sonra eklendikleri ve kolayca bir sitenin normal tab sırasının dışında kaldıkları için klavye odağı testinde yaygın olarak atlanır.
Erişilebilirlik Bakımdır, Tek Seferlik Bir Proje Değil
Bir WCAG denetimi, çalıştırıldığı anda var olanı düzeltir; her yeni blog yazısı, her yeni eklenti ve her şablon değişikliği, o denetimin zaten kapattığı bir sorunu yeniden ortaya çıkarmak için taze bir fırsattır. Erişilebilirlik kontrollerini bir kez tamamlandı olarak işaretlenen bir proje değil, düzenli yayınlama ve geliştirme iş akışının bir parçası olarak ele almak, bir sitenin sadece lansman gününde değil altı ay sonra da uyumlu kalmasını sağlayan şeydir.
Yaygın Hatalar
- Sadece otomatik bir tarayıcıya güvenmek, hiçbir tarayıcının yargılayamayacağı manuel klavye ve ekran okuyucu sorunlarını kaçırmak.
- Sadece aydınlık modda kontrastı düzeltmek, karanlık mod geçişi olan bir sitenin her ikisinin de bağımsız olarak kontrol edilmesi gerekirken.
- Popüler bir temanın veya page builder'ın varsayılan olarak erişilebilir olduğunu varsaymak, şablon seviyesi kontrast ve başlık sorunları ondan inşa edilen her sayfada tekrarlanırken.
- Bir erişilebilirlik denetimini tek seferlik bir görev olarak ele almak, yayınlandıkça yeni içeriğe ve özelliklere uygulanan sürekli bir kontrol yerine.
- Toplu bir denetim mevcut birikimi düzelttikten sonra bile yeni görsel yüklemelerinde alt metni atlamak, boşluğun sessizce yeniden birikmesine izin vermek.
Özetle
Kısacası, bir WordPress sitesi için WCAG 2.2 AA uyumluluğu, sadece otomatik tarama ve manuel test kombinasyonuyla güvenilir bir şekilde yakalanan ve tek bir denetim yerine sürekli bir alışkanlıkla sürdürülen kısa, tekrarlanabilir bir gerçek dünya hata noktaları listesine dayanır — renk kontrastı, eksik alt metin, klavye navigasyonu, başlık yapısı ve özel bileşenlerde ARIA kullanımı. AB Erişilebilirlik Yasası artık beklemede değil yürürlükte olduğuna göre, bunu gelecekteki bir yapılacaklar listesi yerine rutin bakım olarak ele almak, uyumlu bir site ile bir yükümlülük arasındaki farktır.