2026’da Web Erişilebilirliği: WCAG 2.2 Kontrol Listesi

Web erişilebilirliği uzun süre “yapılsa iyi olur” başlığı altında konuşulan bir konuydu. 2025/10 sayılı Cumhurbaşkanlığı Genelgesi ile bu durum değişti ve 2026 itibarıyla iş artık uygulama ve değerlendirme tarafına geçti.

21 Haziran 2025’te yayımlanan Genelge; kamu kurumları, üniversiteler, belediyeler, bankalar, özel hastaneler ve bazı özel sektör kuruluşlarından web sitelerini ve mobil uygulamalarını erişilebilir hale getirmelerini istiyor. Bu kurumların çoğu için tanınan bir yıllık süre Haziran 2026’da doldu. E-ticaret hizmet sağlayıcılarının ise Haziran 2027’ye kadar zamanı var.

Genelgenin kapsamını ve kimleri etkilediğini daha önce ayrıntılı olarak anlatmıştık. Bu yazıda daha pratik bir soruya odaklanıyoruz: Sitemizin bugünkü durumunu nasıl ölçeceğiz ve eksikleri hangi sırayla kapatacağız?

Güncel Kontrol Listesi Neyi Değerlendiriyor?

Aile ve Sosyal Hizmetler Bakanlığının yayımladığı Web Siteleri ve Mobil Uygulamaların Erişilebilirliği Kontrol Listesi – A Seviyesi, WCAG 2.2’nin A seviyesindeki başarı kriterlerini temel alıyor. Şu an geçerli olan sürüm V2.2.30.01.

Liste, 31 başarı kriterini WCAG’nin dört prensibi altında topluyor:

Bu 31 kriter toplamda 126 kontrol sorusuna açılıyor. Sorular yalnızca HTML hatalarıyla sınırlı kalmıyor; görseller, formlar, klavye kullanımı, videolar, hata mesajları ve ARIA yapıları gibi geniş bir alanı kapsıyor.

Kontrollerin ne kadar ayrıntıya indiğini birkaç örnekle görmek mümkün. Bir görselde alt özelliğinin bulunması yetmiyor, yazılan metnin görselin amacını doğru anlatması da bekleniyor. Bir butonun ekranda görünmesi de tek başına yeterli sayılmıyor. Ekran okuyucu gibi yardımcı teknolojilerin o butonun adını, rolünü, durumunu ve değerini doğru okuyabilmesi gerekiyor.

Resmî WCAG 2.2 A Kontrol Listesini görüntüleyin (PDF, Aile ve Sosyal Hizmetler Bakanlığı) →

Otomatik Tarama Sonucu Neyi Söyler, Neyi Söylemez?

Erişilebilirlik değerlendirmelerinde en sık karşılaştığımız yanlışlardan biri, otomatik tarama raporunu doğrudan WCAG uyum raporu gibi okumak.

axe-core gibi araçlar DOM üzerinde birçok sorunu saniyeler içinde yakalar: alternatif metni olmayan görseller, adı olmayan butonlar, hatalı ARIA kullanımı, etiketsiz form alanları, tanımlanmamış sayfa dili gibi. Büyük bir sitede bu hız ciddi bir avantaj sağlar.

Fakat bazı soruların cevabı kodda yazmaz. Bir bağlantı metni, tıklandığında ne olacağını kullanıcıya gerçekten anlatıyor mu? Alt metin, grafikteki bilgiyi eksiksiz aktarıyor mu? Klavyeyle gezinirken odak mantıklı bir sırayla mı ilerliyor? Videodaki bilgi, izleyemeyen biri için de erişilebilir mi? Bunlara ancak bir insan bakarak karar verebilir.

Bu yüzden otomatik taramadan çıkan bir sonucu “WCAG uyumluluğu %82” diye raporlamak yanıltıcı olur. Daha doğru ifade, “Otomatik erişilebilirlik kontrollerinde 82/100 teknik skor” olacaktır.

Bakanlığın kontrol listesi de bu ayrımı gözetiyor. Her kontrol, ilgili sayfanın ya da uygulama ekranının bağlamında ayrıca değerlendiriliyor. Listede sağlanması zorunlu koşullar ★ ile, erişilebilirliği olumsuz etkilediği için bulunmaması gereken durumlar ise ★★ ile işaretleniyor.

Web sitenizin erişilebilirlik durumunu bilmiyor musunuz?
WCAG 2.2 kapsamında teknik ön değerlendirme gerçekleştirerek otomatik tespit edilebilen sorunları ve manuel inceleme gerektiren alanları belirleyebiliriz.

Erişilebilirlik analizi talep edin →

Sadece Ana Sayfayı Test Etmek Yeterli mi?

Kısa cevap: Hayır. Kurumsal sitelerde ana sayfa, sitede kullanılan bileşenlerin küçük bir kısmını gösterir. Haber detayları, iletişim ve başvuru formları, arama sonuçları, tablolar, doküman sayfaları, video içerikleri ve etkileşimli özel bileşenler çoğu zaman farklı şablonlarda yer alır.

Ana sayfada hiç form yoksa, form etiketleriyle ilgili bir sorun da raporda görünmez. Oysa aynı sitenin başvuru sayfasındaki tek bir formda onlarca hata çıkabilir. Gerçekçi bir analiz için her sayfa şablonundan temsili örnekler seçmek gerekiyor.

2026’da Öncelikli Olarak Kontrol Edilmesi Gereken Alanlar

Bir erişilebilirlik çalışmasına başlarken şu başlıkları birlikte ele almanızı öneriyoruz:

• Görsel, ikon ve grafiklerde anlamlı metin alternatifleri
• Başlıkların doğru bir semantik hiyerarşiyle kurulması
• Form alanlarının uygun etiketlerle ilişkilendirilmesi
• Buton ve bağlantıların erişilebilir bir isme sahip olması
• Sayfanın yalnızca klavyeyle kullanılabilmesi ve odak sırasının mantıklı ilerlemesi
• Bilginin yalnızca renk üzerinden aktarılmaması
• Video ve ses içerikleri için gerekli alternatiflerin sunulması
• Tablolarda başlık ve hücre ilişkilerinin doğru kurulması
• Sayfa dilinin programatik olarak belirtilmesi
• ARIA rol, durum ve özelliklerinin doğru kullanılması
• Açılır menü, sekme, modal, slider gibi bileşenlerde durum değişikliklerinin yardımcı teknolojilere aktarılması

Son madde güncel listede ayrıca öne çıkıyor. Bir accordion açıldığında yalnızca görsel olarak açılması yetmiyor; aria-expanded gibi niteliklerin de yeni durumu yansıtması gerekiyor. Listenin 124–126 numaralı kontrolleri, arayüz bileşenlerinin ad, rol, durum ve değer bilgilerinin yardımcı teknolojilere programatik olarak aktarılmasını ele alıyor.

“Erişilebilirlik Widget’ı Ekledik” Demek Yeterli mi?

Yazı boyutu, kontrast ya da okuma ayarları sunan erişilebilirlik araçları kullanıcılar için faydalı olabilir. Ama bu araçlar kaynak koddaki sorunları ortadan kaldırmaz. Adı olmayan bir buton, yanlış kurulmuş form ilişkileri ya da karışık bir odak sırası, sayfaya bir menü eklemekle düzelmez.

Bu yüzden erişilebilirliği iki katmanda düşünmek gerekiyor. Bir yanda kullanıcı deneyimini destekleyen araçlar, diğer yanda sitenin kaynak kodu, içerik yapısı ve etkileşimlerinin WCAG kriterlerine uygunluğu var. Kalıcı sonuç, ikinci katmanda yapılan iyileştirmelerden gelir.

Otomatik Testin Asıl Katkısı: Ölçek

Yüzlerce ya da binlerce sayfası olan bir sitede her sayfayı baştan elle incelemek pratik değil. Otomatik tarama burada tekrar eden sorunları ortaya çıkarır. Örneğin header bileşenindeki bir hata 500 sayfada görünüyorsa, bu 500 ayrı sorun değil; tek bir bileşende yapılacak tek bir düzeltmedir.

Otomatik testler; tespit, sınıflandırma, önceliklendirme, düzeltme ve yeniden test adımlarından oluşan döngünün ilk halkasını hızlandırır. Sonrasında manuel kontrol gerektiren kriterlerin ayrıca ele alınması gerekir.

Erişilebilirlik Bir Kerelik Proje Değil

Bugün erişilebilir hale getirilen bir site, yarın eklenecek yeni bir form, banner, video ya da özel bileşenle yeniden sorunlu hale gelebilir. Bu nedenle erişilebilirliği proje tesliminde yapılan son kontrol gibi görmemek gerekiyor.

Bizim önerdiğimiz yaklaşım şu: Erişilebilirliği tasarım ve geliştirme sürecinin en başından bir parçası yapmak, belirli aralıklarla otomatik tarama çalıştırmak ve kritik kullanıcı akışlarını düzenli olarak elle yeniden test etmek.

Bakanlığın mevzuat sayfasında 2025/10 Genelgesinin yanında Web Siteleri ve Mobil Uygulamaların Erişilebilirliği Genelgesi Uygulama Usul ve Esasları Hakkında Yönerge de yer alıyor. Bu da sürecin tek seferlik bir düzenlemeyle bitmeyeceğini, takip edilen bir uygulamaya dönüştüğünü gösteriyor.

Erişilebilirlik çalışmalarının sürdürülebilir olması için Oorly gibi otomatik analiz ve izleme araçlarından yararlanılabilir. Bu tür araçlar teknik erişilebilirlik sorunlarını düzenli olarak tespit etmeyi ve yapılan iyileştirmeleri takip etmeyi kolaylaştırır. Otomatik kontroller tüm erişilebilirlik kriterlerini kapsamadığı için manuel değerlendirme gerektiren alanlar ayrıca ele alınmalıdır.

Web sitenizin erişilebilirlik durumunu görmek için Oorly’yi inceleyin →

Nereden Başlamalı?

İlk adımın siteyi baştan yazmak olması gerekmiyor. Önce mevcut durumu ölçmek, otomatik olarak yakalanabilen sorunları çıkarmak ve WCAG 2.2 kapsamında manuel inceleme gerektiren alanları belirlemek çok daha sağlıklı bir başlangıç.

Bu çalışmanın sonunda hangi sorunların kritik olduğu, hangilerinin site genelinde tekrarlandığı ve hangi geliştirmelerin önce yapılması gerektiği net biçimde ortaya çıkar.

Drupart olarak web sitelerinin WCAG 2.2 kriterlerine göre teknik erişilebilirlik analizini yapıyor, tespit edilen sorunları kaynak kod seviyesinde gideriyor ve erişilebilirliğin sürdürülebilir şekilde izlenmesine destek oluyoruz. Dijital erişilebilirliği yalnızca mevzuat gereği değil, bir sitenin herkes tarafından kullanılabilmesini sağlayan temel bir kalite standardı olarak görüyoruz.

Erişilebilirlik analizi için bizimle iletişime geçin →

Sıkça Sorulan Sorular

WCAG 2.2 nedir?

WCAG (Web Content Accessibility Guidelines) 2.2, web içeriklerinin farklı kullanıcı ihtiyaçları açısından daha erişilebilir hazırlanması için W3C tarafından geliştirilen erişilebilirlik kılavuzudur. Bakanlığın güncel kontrol listesi, WCAG 2.2’nin A seviyesindeki başarı kriterlerini temel alır.

Otomatik erişilebilirlik testi yeterli midir?

Hayır. Otomatik testler teknik sorunların önemli bir bölümünü hızla belirleyebilir; ancak içeriğin anlamı, klavye deneyimi ve bazı yardımcı teknoloji etkileşimleri manuel değerlendirme gerektirir.

2025/10 sayılı Genelge kimleri kapsıyor?

Kamu kurumları, üniversiteler, belediyeler ve Genelgede tek tek sayılan özel sektör gruplarını kapsıyor. Bu kurumlar için bir yıllık süre öngörülürken, elektronik ticaret hizmet sağlayıcıları için iki yıllık süre tanınıyor. Ayrıntılar için Genelge rehberimize göz atabilirsiniz.

Erişilebilirlik widget’ı WCAG uyumluluğu sağlar mı?

Tek başına sağlamaz. Widget’lar kullanıcı deneyimini destekler; ancak kaynak kod, semantik yapı, klavye erişimi ve yardımcı teknoloji uyumluluğunun ayrıca değerlendirilmesi ve gerekirse düzeltilmesi gerekir.