Web sitesi erişilebilirlik testi nasıl yapılır? Ücretsiz araçlarla 6 adım

Erişilebilirlik testi neye göre yapılır?

Erişilebilirlik testi, sayfaları W3C'nin WCAG yönergelerine göre sınar. Hangi sürüm ve düzeyin esas alınacağı, sitenizin hangi düzenlemeye tabi olduğuna bağlı.

Dikkat: metin kontrastı (1.4.3), görünür odak (2.4.7) ve yeniden akış (1.4.10) AA düzeyinde, yani Genelge'nin zorunlu A listesinde değil. Az gören ve klavyeyle gezinen kullanıcı için yine de gerekliler ve AB'ye hizmet veriyorsanız EAA bunları istiyor. Bu yüzden aşağıdaki adımlar ikisini birlikte sınar. Kapsam ayrıntısı: Genelge kimleri kapsar? ve EAA rehberi.

Kaynak: Lexpera, Aile ve Sosyal Hizmetler Bakanlığı, EUR-Lex

1. adım: Hangi sayfaları test etmelisiniz?

Her şablondan bir sayfayı ve en önemli akışınızın her adımını test edin. Siteler birkaç şablondan üretilir; şablondaki bir düzeltme o şablondan çıkan bütün sayfaları düzeltir. W3C'nin değerlendirme yöntemi WCAG-EM 2.0 (Temmuz 2026) da aynı mantığı kullanır: temsil eden sayfalardan yapılandırılmış bir örneklem ve gözden kaçanı yakalamak için birkaç rastgele sayfa.

Kaynak: W3C WAI

2. adım: Otomatik erişilebilirlik testi nasıl yapılır?

Örneklemdeki her sayfada kural tabanlı bir test aracı çalıştırın. Ücretsiz seçenekler: axe DevTools tarayıcı eklentisi, WAVE ve Lighthouse'un erişilebilirlik denetimleri. Lighthouse da bizim taramamız da Deque'in açık kaynak motoru axe-core'u kullanır. Aile ve Sosyal Hizmetler Bakanlığının Erişilebilirlik Portalı da (erisilebilirlik.gov.tr) kendini "web erişilebilirlik analiz ve raporlama platformu" olarak tanımlıyor. Her bulgu bir kural adı, öğe ve WCAG başarı ölçütü içerir.

Sonuçları iki grupta okuyun. Kesin bulgular tartışmasızdır: alt özniteliği olmayan görsel, adı olmayan buton. İnsan kontrolü gerekir olanlar motorun karar veremediği durumlardır, ör. arka plan görseli üstündeki metin; axe-core bunları yanlış alarm vermemek için bilerek ayrı listeler. Temiz bir rapor "otomatik bulunabilen sorun çıkmadı" demektir, "sayfa erişilebilir" değil. Lighthouse'ta 100 puan için de aynısı geçerli.

Tipik bir bulgu: axe'in button-name kuralı (WCAG 4.1.2), yalnız ikon içeren ve adı olmayan butonu işaretler. Ekran okuyucu bunu sadece "düğme" diye okur.

Benzer düzeltmeler için: en sık 10 erişilebilirlik hatası ve çözümleri.

Kaynak: Deque Systems, Deque Systems, GitHub, Deque Systems, WebAIM, Chrome for Developers (Google), Aile ve Sosyal Hizmetler Bakanlığı

3. adım: Klavyeyle test nasıl yapılır?

Fareyi kenara koyun ve ana akışı yalnız klavyeyle baştan sona tamamlayın. Bu adım, axe-core'da hiçbir kuralı olmayan ölçütleri sınar: 2.1.2 klavye tuzağı olmaması, 2.4.3 odak sırası (ikisi de A düzeyi, Genelge kapsamında) ve 2.4.7 görünür odak (AA).

Takıldığınız, odağı kaybettiğiniz ya da görünmeyen bir öğeye düştüğünüz her yeri not edin. Sık görülen örnek: kapalı yan sepet ya da menüdeki bağlantıların hâlâ odak alması. Kapalı panel aria-hidden="true" ile işaretliyse axe-core bunu yakalar (aria-hidden-focus kuralı); düzeltme, kapalı panele inert özniteliği ya da display:none vermektir.

Kaynak: W3C, Deque Systems, GitHub

4. adım: Yakınlaştırma nasıl test edilir?

Tarayıcıyı %200'e yakınlaştırın; metin kesilmemeli ve üst üste binmemeli (1.4.4 metni yeniden boyutlandırma, AA). Sonra pencereyi 1280 piksel genişliğe getirip %400'e yakınlaştırın. Bu, WCAG 1.4.10'un kullandığı 320 CSS piksellik görüntü alanına denk gelir: içerik yana kaydırma gerektirmeden tek sütuna sığmalı; veri tabloları ve haritalar istisna.

Telefonda iki parmakla yakınlaştırmanın çalıştığını kontrol edin. axe'in meta-viewport kuralı bunu engelleyen etiketi işaretler:

Kaynak: W3C, Deque Systems, GitHub

5. adım: Formlar ve hata mesajları nasıl test edilir?

Her formu önce boş, sonra bilerek hatalı gönderin: @ işareti olmayan bir e-posta, 10 haneli bir T.C. kimlik numarası. Her hata, alanın yanında metinle açıklanmalı; yalnız kırmızı çerçeve 3.3.1 hatanın belirtilmesi ölçütünü (A) karşılamaz. Aynı bilgiyi aynı süreçte ikinci kez istemek (ör. adresi her adımda yeniden yazdırmak) WCAG 2.2 ile gelen 3.3.7 tekrarlı giriş ölçütüne (A) takılır.

axe-core alanın etiketi olup olmadığını (label kuralı) ve aria-describedby'nin var olan bir id'ye işaret edip etmediğini (aria-valid-attr-value kuralı) denetler. Hata mesajının anlamlı olup olmadığını değerlendiremez. Aşağıdaki düzeltme alana görünür bir etiket verir ve hata metnini alana bağlar; ekran okuyucu ikisini birlikte okur:

Kaynak: W3C, Deque Systems, GitHub

6. adım: Ekran okuyucuyla test nasıl yapılır?

Kullanıcılarınızın kullanma olasılığı yüksek bir ekran okuyucu seçin. NVDA Windows'ta ücretsiz ve 50'den fazla dile çevrilmiş; VoiceOver Mac ve iPhone'da, TalkBack Android'de yerleşik. Ana akışta 15 dakika, en belirgin sorunları gösterir.

Dört şeyi dinleyin: görseller işe yarar biçimde tanımlanıyor mu; fiyat ve seçenekler mantıklı sırayla okunuyor mu; butonların adı ne yaptıklarını söylüyor mu; "Sepete ekle" ya da bir form hatasından sonra duyuru geliyor mu. "Düğme, düğme, bağlantı, grafik" duyuyorsanız iş çıktı demektir.

Kaynak: NV Access, Apple

Sonuçları nasıl kaydetmeli ve güncel tutmalısınız?

Her bulguyu sayfa, adım, WCAG ölçütü, ne olduğu ve bir ekran görüntüsüyle kaydedin. Bu kayıt düzeltme listeniz, Bakanlığın kontrol listesini madde madde doldururken kanıtınız, erişilebilirlik beyanınızın dayanağı ve bir sonraki testin başlangıç noktası olur.

Her sürümden sonra tekrar test edin. İlkbaharda geçen bir site, sonbaharda bir tema güncellemesi ya da yeni bir kampanya sayfasıyla geri düşebilir. Otomatik tarama 2. adımı her hafta tekrarlayabilir; 3–6. adımları sürüm kontrol listenize ekleyin.

Sonuç hakkında ne söylediğinize dikkat edin. Hiçbir test, bizimki de dahil, bir sitenin WCAG'ye uyduğunu tek başına kanıtlamaz. ABD Federal Ticaret Komisyonu (FTC) 22 Nisan 2025'te accessiBe'ye 1 milyon $ ödeme ve ürününün siteleri WCAG'ye uyumlu yaptığını kanıtsız iddia etmeme yükümlülüğü getiren kararı kesinleştirdi. Neyi, ne zaman test ettiğinizi ve neyin açık kaldığını yazın.

Kaynak: Aile ve Sosyal Hizmetler Bakanlığı, ABD Federal Ticaret Komisyonu (FTC)