# SaaS ürünleri ve web uygulamaları için WCAG 2.2 AA kontrol listesi

<https://www.fixreports.com/tr/blog/wcag-2-2-checklist-saas-web-apps>

Güncelleme: 2026-10-26

Bir SaaS ürününün iki erişilebilirlik yüzeyi vardır: ürünü satan pazarlama sitesi ve insanların her gün kullandığı uygulama. Pazarlama sitesi her web sitesinin hata yaptığı yerlerde hata yapar: düşük kontrast, eksik alt metin ve etiketsiz formlar. Uygulama ise kendi sorunlarını ekler: parola yöneticilerini engelleyen giriş akışları, klavye odağını hapseden diyaloglar, ekran okuyucuların fark etmediği tek sayfa gezinme, metin karşılığı olmayan veri tabloları ve grafikler, alternatifi olmayan sürükle-bırak ve uyarı vermeden sona eren oturumlar. Bu kontrol listesi, WCAG 2.2 AA seviyesini tipik bir SaaS ürününün bölümlerine göre ele alır.

**Temel noktalar**

- WCAG 2.2, Ekim 2023'te W3C Tavsiyesi oldu ve altısı A veya AA seviyesinde olmak üzere dokuz başarı kriteri ekledi ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA), kullanıcılar parolayı yapıştıramıyor veya bir parola yöneticisi kullanamıyorsa girişin parolayı hatırlamaya ya da bakarak yeniden yazmaya dayanamayacağı anlamına gelir ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Etkileşimli hedefler en az 24 x 24 CSS piksel olmalı ya da çevrelerinde yeterli boşluk bulunmalıdır (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- "Kaydedildi" veya "3 sonuç" gibi mesajlar, odağı taşımadan ekran okuyuculara ulaşmalıdır (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Kurumsal ve kamu alıcıları sık sık bir Accessibility Conformance Report (Erişilebilirlik Uygunluk Raporu) ister; bu rapor genellikle Information Technology Industry Council'ın VPAT şablonuyla hazırlanır ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Erişilebilirlik SaaS için neden tanıtım sitesinden daha önemli?

İnsanlar bir SaaS ürününü saatlerce kullanır ve çoğu zaman bunu işverenleri o ürünü seçtiği için yapar. Bir pazarlama sayfasındaki engel bir ziyaretçiyi kaybettirir; üründeki bir engel ise birinin işini yapmasını engelleyebilir. Bu yüzden büyük müşteriler, üniversiteler ve kamu kurumları satın almadan önce erişilebilirliği giderek daha sık soruyor; bu yüzden de verilen yanıtın yalnızca web sitesini değil, uygulamayı da kapsaması gerekiyor.

Bu ayrıca önemlidir, çünkü otomatik testler sorunun yalnızca bir kısmını yakalar. axe-core gibi araçlar işaretlemedeki eksik etiketler ve düşük kontrast gibi hataları bulur. Ancak bir diyaloğun odağı doğru yere geri verip vermediğini, bir grafiğin verilerinin metin olarak sunulup sunulmadığını ya da bir iş akışının klavyeyle tamamlanıp tamamlanamadığını söyleyemez. Bir uygulamanın hem otomatik kontrollere hem de manuel teste ihtiyacı vardır.

## Kayıt ve girişi nasıl erişilebilir hale getirirsiniz?

Kimlik doğrulama, WCAG 2.2'nin SaaS için en önemli yeni gerekliliği eklediği alandır.

- **Yapıştırmaya ve parola yöneticilerine izin verin (3.3.8, AA).** Parola veya kod alanlarına yapıştırmayı engellemeyin; tarayıcıların ve parola yöneticilerinin bu alanları doldurabilmesi için `autocomplete="username"`, `autocomplete="current-password"` ve `autocomplete="one-time-code"` kullanın.
- **Bulmacaları tek giriş yolu yapmayın.** Kullanıcılardan bozulmuş bir metni yeniden yazmalarını veya bir bulmaca çözmelerini isteyen bir CAPTCHA, bilişsel bir işlev testidir. Bir alternatif sunun ve kullanıcının bir şey yapmasını gerektirmeyen kontrolleri tercih edin ([W3C](https://www.w3.org/TR/turingtest/)).
- **Her alanı etiketleyin (1.3.1 ve 3.3.2, A).** Alanına bağlı görünür bir `<label>` kullanın; yer tutucu metin, kullanıcı yazmaya başlayınca kaybolur ve bir etiket değildir.
- **Hataları metinle belirtin (3.3.1, A) ve düzeltme önerin (3.3.3, AA).** "Parola en az 12 karakter içermelidir" yardımcı olur; tek başına kırmızı bir kenarlık olmaz.
- **İki kez sormayın (3.3.7, A).** Çok adımlı bir kayıt akışında şirket adı veya adres zaten sorulduysa, kullanıcıya yeniden yazdırmak yerine bu bilgiyi doldurun ya da seçilebilir hale getirin.
- **Yardımı aynı yerde tutun (3.2.6, A).** Canlı sohbet, yardım bağlantısı veya iletişim bilgileri sunuyorsanız bunları akıştaki her sayfada aynı göreli konuma yerleştirin.

## En çok hatayı hangi form ve hata kalıpları üretiyor?

Uygulama hatalarının çoğu formlarda yaşanır. WebAIM'in 2026'da bir milyon ana sayfa üzerinde yaptığı incelemede sayfaların %51'inde eksik form etiketleri bulundu ([WebAIM](https://webaim.org/projects/million/)); uygulamalarda ise ana sayfalardan çok daha fazla form vardır.

- Her alana programatik bir ad verin ve radyo düğmeleri gibi birbiriyle ilişkili kontrolleri `<fieldset>` ve `<legend>` ile gruplayın.
- Hataları kullanıcıların fark edeceği yerde bildirin: odağı formun üstündeki hata özetine ya da ilk geçersiz alana taşıyın ve özetteki her maddeyi kendi alanına bağlayın.
- Zorunlu alanları yalnızca renkle değil, metinle de belirtin (1.4.1, A).
- Kullanıcı yalnızca bir seçenek seçtiğinde formu göndermeyin veya bağlamı değiştirmeyin (3.2.2, A); açık bir işlem yapılmasını bekleyin.

## Diyaloglar, menüler ve açılır pencereler nasıl davranmalı?

Klavye ve ekran okuyucu desteğinin en sık bozulduğu yer özel bileşenlerdir. WAI-ARIA Authoring Practices Guide, her kalıp için beklenen davranışı açıklar ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Diyaloglar**: Açıldığında odağı diyaloğun içine taşıyın, açık kaldığı sürece Tab tuşunu içinde tutun, Escape ile kapatın ve odağı diyaloğu açan kontrole geri verin. Yerleşik `<dialog>` öğesini ya da `aria-modal="true"` ve bir adla birlikte `role="dialog"` kullanın.
- **Klavye tuzağı olmamalı (2.1.2, A)**: Her bileşenden klavyeyle çıkılabilmelidir.
- **Görünür odak (2.4.7, AA)**: Odak; yapışkan başlıkların, çerez bildirimlerinin veya canlı sohbet widget'larının arkasında kalmamalıdır (2.4.11, AA, 2.2'de yeni).
- **Araç ipuçları ve açılır pencereler (1.4.13, AA)**: Kullanıcı bunları Escape ile kapatabilmeli, üzerine gelindiğinde kaybolmamalı ve kapatılana kadar görünür kalmalıdır.
- **Tek tuşlu kısayollar (2.1.4, A)**: Bir harf tuşuna basmak bir işlemi tetikliyorsa kullanıcıların kısayolları kapatmasına veya başka tuşlara atamasına izin verin ya da kısayolları yalnızca ilgili bileşen odaktayken etkin tutun.

## Tek sayfalı bir uygulamada gezinmeyi nasıl yönetirsiniz?

Tek sayfalı bir uygulamada URL, sayfa yüklenmeden değişir; bu yüzden ekran okuyucular bir şey olduğunu duyurmayabilir.

- Her rota değişikliğinde belge başlığını güncelleyin; böylece her görünümün açıklayıcı bir başlığı olur (2.4.2, A).
- Odağı yeni görünümün ana başlığına taşıyın ya da değişikliği polite bir canlı bölgede (live region) duyurun; Next.js gibi çatılar bunun için bir rota duyurucusu (route announcer) içerir.
- Mantıklı bir odak sırası koruyun (2.4.3, A): Bir öğe silindikten sonra odak sayfanın en üstüne değil, makul bir komşu öğeye gitmelidir.
- Tekrarlanan gezinmeyi atlamanın bir yolunu sunun (2.4.1, A); örneğin bir atlama bağlantısı veya yer işaretleri (landmark).

## Panoları, veri tablolarını ve grafikleri nasıl erişilebilir yaparsınız?

- **Tablolar**: Başlıklar için `<th>` ve `scope` içeren gerçek `<table>` işaretlemesi ve bir başlık (caption) kullanın (1.3.1, A). `<div>` öğeleriyle kurulan ızgaralar, doğru uygulanması çok daha zor olan ARIA grid kalıbının tamamını gerektirir.
- **Grafikler**: Her grafiğe ana mesajı söyleyen bir metin alternatifi verin ve verileri bir tablo olarak da sunun (1.1.1, A). Serileri ayırt etmek için yalnızca renge güvenmeyin (1.4.1, A); etiketler veya desenler ekleyin.
- **Kontrast**: Metin 4.5:1 gerektirir (1.4.3, AA); grafik çizgileri, simgeler ve alan kenarlıkları ise arka planlarına karşı 3:1 gerektirir (1.4.11, AA). Karanlık modu ayrıca kontrol edin. [Renk kontrastı kontrol aracımız](/tr/color-contrast-checker) her renk çiftini test eder.
- **Durum mesajları (4.1.3, AA)**: "Kaydedildi", "Yükleme tamamlandı" ve sonuç sayıları için `role="status"` veya bir canlı bölge kullanın; böylece ekran okuyucu kullanıcıları yerlerini kaybetmeden bunları duyar.

## WCAG 2.2'nin yeni kriterleri web uygulamaları için neyi değiştiriyor?

| Kriter | Seviye | Uygulamada ne anlama geliyor |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Yapışkan araç çubukları, bildirim şeritleri ve canlı sohbet widget'ları odaklanan öğeyi tamamen örtmemelidir |
| 2.5.7 Dragging Movements | AA | Bir kanban panosunu yeniden sıralamak gibi sürükleyerek yapılan her işlemin tek işaretçili bir alternatifi olmalıdır; örneğin bir menü veya yukarı-aşağı düğmeleri |
| 2.5.8 Target Size (Minimum) | AA | Düğmeler ve bağlantılar en az 24 x 24 CSS piksel olmalı ya da her birinin çevresindeki 24 piksellik daire diğerleriyle çakışmayacak şekilde aralıklı yerleştirilmelidir |
| 3.2.6 Consistent Help | A | Yardım bağlantıları, canlı sohbet ve iletişim bilgileri her sayfada aynı göreli yerde bulunur |
| 3.3.7 Redundant Entry | A | Aynı süreçte daha önce girilmiş bilgiler otomatik doldurulur veya seçilebilir olur |
| 3.3.8 Accessible Authentication (Minimum) | AA | Yapıştırma, parola yöneticileri veya başka bir yönteme izin verilmedikçe giriş, ezberlemeye ya da bakarak yeniden yazmaya dayanmaz |

WCAG 2.2 ayrıca artık erişilebilirlik üzerinde pratik bir etkisi kalmayan 4.1.1 Parsing kriterini kaldırdı ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Zaman aşımları, düzen ve yakınlaştırma ne olacak?

- **Oturum zaman aşımları (2.2.1, A)**: Süre sınırı zorunlu olmadıkça veya 20 saatten uzun olmadıkça, oturum sona ermeden önce kullanıcıları uyarın ve süreyi basit bir işlemle uzatmalarına izin verin. Devam eden çalışmayı kaydetmek en kötü sonucu önler.
- **Yeniden akış (1.4.10, AA)**: İçerik 320 CSS piksel genişlikte (1280 piksellik bir ekranda %400 yakınlaştırmaya eşdeğer) iki yönde kaydırma gerektirmeden çalışmalıdır; veri tabloları ve benzeri içerikler bundan muaftır.
- **Metin aralığı (1.4.12, AA)**: Satır yüksekliğini ve harf aralığını artırmak metnin kesilmesine yol açmamalıdır; sabit yükseklikli kapsayıcılarda bu sık görülür.
- **Yön (1.3.4, AA)**: Zorunlu olmadıkça uygulamayı dikey veya yatay yöne kilitlemeyin.

## ACR nedir ve size gerekli mi?

Accessibility Conformance Report (ACR), bir ürünün her erişilebilirlik kriterini nasıl karşıladığını belgeler: destekliyor (supports), kısmen destekliyor (partially supports) veya desteklemiyor (does not support), açıklamalarla birlikte. Çoğu ACR, Information Technology Industry Council'ın yayımladığı VPAT şablonuyla hazırlanır; bu şablonun WCAG, ABD Section 508 standartları ve Avrupa standardı EN 301 549 için ayrı sürümleri vardır ([ITI](https://www.itic.org/policy/accessibility/vpat)).

ABD federal kurumları Section 508 kapsamında erişilebilir teknoloji satın almak zorundadır ([Section508.gov](https://www.section508.gov/)), AB kamu kurumları da EN 301 549'a atıf yapar; bu yüzden bu müşterilere satış yapan B2B ürünlerden satın alma sürecinde sık sık ACR istenir. Bilinen eksikleri listeleyen dürüst bir ACR, tam destek iddia eden bir rapordan alıcılar için daha faydalıdır. ACR, manuel test dahil olmak üzere ürünün test edilmesine dayanmalıdır; yalnızca otomatik bir tarama ile doldurulamaz.

AB'deki tüketicilere satış yapıyorsanız çevrimiçi satış biçiminize Avrupa Erişilebilirlik Yasası da uygulanabilir; [EAA rehberimiz](/tr/blog/european-accessibility-act-online-stores) kapsamını açıklar. Bu bir hukuki tavsiye değildir.

## Bir SaaS ekibi erişilebilirliği nasıl test etmeli?

1. **Temel kontrolleri otomatikleştirin.** Uçtan uca testlerinizde ve pazarlama sitesinde axe-core veya benzeri bir motoru çalıştırın ve yeni ihlallerde derlemeyi başarısız sayın. [Ücretsiz erişilebilirlik testimiz](/tr/website-accessibility-checker), aynı motoru herkese açık her sayfada çalıştırır.
2. **Klavyeyle test edin.** Kayıt olma, kayıt oluşturma ve ayarları değiştirme gibi ana iş akışlarınızı yalnızca Tab, Shift+Tab, Enter, Space, Escape ve ok tuşlarıyla tamamlayın.
3. **Ekran okuyucuyla test edin.** Windows'ta NVDA, macOS ve iOS'ta VoiceOver ücretsizdir. Adların, rollerin, durumların ve mesajların duyurulup duyurulmadığını kontrol edin.
4. **Yakınlaştırın ve boyutlandırın.** %200 metin yakınlaştırmasını ve 320 piksel genişliğinde bir pencereyi kontrol edin.
5. **Tasarım sisteminde düzeltin.** Hataların çoğu ortak bileşenlerden gelir; bir düğmeyi veya diyaloğu bir kez düzeltmek onu her yerde düzeltir.

## Sık sorulan sorular

### WCAG, bir web uygulamasının giriş yapılan bölümlerine uygulanır mı?

WCAG, giriş gerektiren sayfalar dahil her web içeriğine uygulanır. Belirli bir ürünün bunu karşılamasının yasal olarak zorunlu olup olmadığı yargı bölgesine ve müşteriye bağlıdır; ancak erişilebilirliği soran alıcılar genellikle ürünün tamamını kasteder.

### Bir overlay, bir SaaS ürününü erişilebilir yapabilir mi?

Hayır. Overlay'ler özel bileşenlerin temel kodunu değiştirmez; uygulama hataları da tam olarak orada bulunur. [Erişilebilirlik overlay'leri](/tr/blog/accessibility-overlays-ftc-order) hakkındaki rehberimiz, FTC'nin önde gelen bir overlay sağlayıcısına karşı yürüttüğü işlemi ele alır.

### Otomatik araçlar WCAG'nin ne kadarını kontrol edebilir?

Yalnızca bir kısmını. Otomatik kurallar eksik adları, etiketleri ve kontrast hatalarını güvenilir şekilde bulur; ancak anlamlı bir odak sırası, işe yarar alt metin ve anlaşılır hata mesajları gibi birçok kriteri bir insanın değerlendirmesi gerekir.

### Hangi WCAG sürümünü hedeflemeliyiz?

Güncel sürüm WCAG 2.2 AA seviyesidir. Birçok yasa ve satın alma kuralı hâlâ WCAG 2.1 AA'ya atıf yapar; 2.2 AA'yı karşılamak, kaldırılan Parsing kriteri dışında 2.1 AA'yı da karşılar.

### AAA seviyesini karşılamamız gerekir mi?

W3C, bazı içerikler her AAA kriterini karşılayamadığı için ürünlerin tamamı için AAA şartı konmasını önermez. Olağan hedef AA seviyesidir.

## Kaynaklar

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)