Erişilebilirlik Genelgesi: Frontend için WCAG 2.2 Rehberi

31 Ekim 2026Teknik5 dk

Paylaş

21 Haziran 2025'te Resmî Gazete'de yayımlanan 2025/10 sayılı Cumhurbaşkanlığı Genelgesi, kamu kurumlarından e-ticaret sitelerine kadar birçok kuruluştan web sitelerini ve mobil uygulamalarını erişilebilir yapmasını istiyor. Genelgeyi, Bakanlığın duyurusunu ve yönergesini, W3C ile WebAIM kaynaklarını okudum; frontend'i ilgilendiren kısmı topladım.

Genelge Ne Diyor?

Genelge Resmî Gazete'nin 32933 sayılı sayısında yayımlandı. Metin, 5378 sayılı Engelliler Hakkında Kanun gereği bilgi ve iletişim teknolojisinin erişilebilirliğinin yasal zorunluluk olduğunu hatırlatıyor. Kapsamında kamu kurumları, üniversiteler, belediyeler, bankalar, özel hastaneler, yolcu taşıyan özel kuruluşlar, 200.000'den fazla abonesi olan elektronik haberleşme işletmecileri ve 6563 sayılı Kanun kapsamındaki e-ticaret hizmet sağlayıcıları var. Süreler şöyle:

Kimler	Süre	Takvim karşılığı
Kamu, banka, özel hastane, büyük elektronik haberleşme işletmecileri vb.	1 yıl içinde	Haziran 2026
E-ticaret hizmet sağlayıcıları	2 yıl içinde	Haziran 2027

Metin süreyi "1 yıl içinde" ve "2 yıl içinde" diye veriyor, başlangıcı yazmıyor. Yayım tarihinden sayınca ilk süre Haziran 2026'da doldu; e-ticaret için Haziran 2027 geliyor.

Genelgede ceza maddesi yok, metin "bilgilerini ve gereğini rica ederim" diye bitiyor. Yaptırım yerine izleme var: Bakanlık her yıl bir İzleme Planı yayımlayacak, erişilebilir bulunanlara 2 yıl kullanılabilen bir Erişilebilirlik Logosu verecek, izleme sonuçlarını kamuoyuna açıklayacak (yönerge, md. 6 ve 18). Bakanlık duyurusu, süresi içinde şartları sağlamayanların bilgilerinin de kamuoyuyla paylaşılacağını söylüyor (duyuru).

Sürüm karışıklığı

Bazı haber ve rehberlerde WCAG 2.1 ve AA seviyesi geçiyor. Genelge metni ise WCAG 2.2'yi ve Bakanlığın A seviyesi kontrol listesini işaret ediyor.

A Seviyesi Neyi Kapsıyor, Neyi Kapsamıyor?

Genelge iki şeye uyum istiyor: Bakanlığın "Kontrol Listesi - A Seviyesi" ve WCAG 2.2 kılavuzu. Bakanlığa göre liste 31 ilke ve A seviyesi kriterlerine dayanan 122 sorudan oluşuyor (duyuru). Listenin sorularına ulaşamadım. W3C ise kontrastı (1.4.3), odak göstergesini (2.4.7) ve hedef boyutunu (2.5.8) AA seviyesine koyuyor (WCAG 2.2).

Bunun neden önemli olduğunu WebAIM'in verisi gösteriyor. WebAIM, Şubat 2026'da 1.000.000 ana sayfayı otomatik araçla taradı: sayfaların %95,9'unda tespit edilebilir WCAG 2 hatası var, sayfa başına ortalama 56,1 hata düşüyor (WebAIM Million 2026). En yaygın altı hata, tespit edilen tüm hataların yaklaşık %96'sını oluşturuyor (ölçütler WAVE belgelerinden):

Hata	Sayfaların yüzdesi	Ölçüt	Seviye
Düşük kontrastlı metin	%83,9	1.4.3	AA
Alternatif metni eksik görsel	%53,1	1.1.1	A
Etiketi eksik form alanı	%51	1.1.1, 1.3.1, 2.4.6, 3.3.2	A, AA
Boş bağlantı	%46,3	2.4.4	A
Boş düğme	%30,6	1.1.1, 2.4.4	A
Belge dili eksik	%13,5	3.1.1	A

AB tüketicisine e-ticaret hizmeti sunuyorsan Avrupa Erişilebilirlik Yasası da devrede. E-ticaret kapsamda (Avrupa Komisyonu) ve yasa 28 Haziran 2025'ten beri uygulanıyor. Rehberler genellikle WCAG 2.1 AA'yı referans alıyor; kapsam ve muafiyetler için direktif metnine bak.

WCAG 2.2'de Frontend'e Dokunan Yenilikler

WCAG 2.2, Ekim 2023'te W3C Önerisi oldu; güncel metnin tarihi 12 Aralık 2024. 9 yeni ölçüt ekledi, 4.1.1 Parsing'i kaldırdı (W3C). A seviyesine giren iki yeni ölçüt var. 3.2.6 Consistent Help, yardım ve iletişim mekanizmalarının sayfalar arasında aynı sırada durmasını ister. 3.3.7 Redundant Entry, aynı süreçte daha önce girilen bilginin yeniden istenmek yerine otomatik doldurulmasını ya da seçilebilir sunulmasını ister.

Kodu en çok etkileyenler AA seviyesinde, yani A listesinin dışında. Yine de çoğu CSS ya da HTML düzeyinde çözülüyor:

Ölçüt	Ne istiyor?
2.5.8 Target Size (Minimum)	Tıklanabilir hedef en az 24×24 CSS piksel olmalı. Daha küçükse, merkezine konan 24 piksellik daire başka bir hedefle kesişmemeli. Cümle içindeki bağlantılar muaf.
2.4.11 Focus Not Obscured (Minimum)	Klavye odağı alan öğe, sticky header ya da cookie banner'ın arkasında tamamen kalmamalı. W3C çözüm olarak `scroll-padding` öneriyor.
3.3.8 Accessible Authentication (Minimum)	Girişte şifre hatırlamak ya da yazmak tek yol olmamalı. Yapıştırmayı engellemek yazmayı zorunlu kılar; alanlar da şifre yöneticisi doldurabilsin diye doğru etiketlenmeli.
2.5.7 Dragging Movements	Sürükleyerek yapılan her işlemin, sürüklemeden tek işaretçiyle yapılan bir yolu olmalı. Kaydırıcıda ray üzerine tıklamak ya da karuselde ileri ve geri düğmeleri buna örnek.

Tıklanabilir alan en az 24×24 piksel olmalı

İlk üçü için kod şöyle:

html {
	scroll-padding-top: 5rem; /* sticky header yüksekliği */
}
 
.icon-button {
	min-width: 24px;
	min-height: 24px;
}

<input type="password" name="password" autocomplete="current-password">

Nasıl Test Edilecek?

Yönerge incelemeyi kuruma bırakıyor. İzleme Planı'na giren her kurum, biri web ve mobil uygulamalardan sorumlu olmak üzere en az üç kişilik bir İnceleme Komisyonu kurup rapor hazırlıyor (md. 13). İnceleme üç aşamalı: otomatik test (W3C'nin listelediği araçlar), manuel test (formlar, arayüz kontrolleri, iletişim kutuları, hata mesajları, klavye testi ve metin dışı içerik) ve engelli kullanıcı testi (görme, işitme ve ortopedik engelli kullanıcılarla) (md. 14).

Lighthouse'tan 100 almak yetmiyor. Birleşik Krallık hükümetinin dijital servisi GDS, 2017'de bilerek 143 erişilebilirlik hatası eklediği bir sayfada 10 aracı denedi: araçlar birlikte hataların %71'ini buldu, en iyi tek araç %37'sini. 42 hatayı hiçbiri yakalayamadı (GDS). Araçlar o günden beri gelişti, ama yönerge yine de manuel ve kullanıcı testini şart koşuyor.

Kodu bir AI ajanıyla yazıyorsan Jakub Krehel'in better-accessibility skill'i klavye, odak ve ARIA hatalarını yazarken yakalamana yardım edebilir; ben kullanıyorum.

Genelge Ne Diyor?

A Seviyesi Neyi Kapsıyor, Neyi Kapsamıyor?

WCAG 2.2'de Frontend'e Dokunan Yenilikler

Nasıl Test Edilecek?

Kaynaklar