Yazılım'ya dön
Yazılım
Web Erişilebilirlik Denetimi (WCAG) Promptu
Optimal modelClaude
ZorlukOrta
KategoriYazılım
Varyant3 adet
prompt.txt
Sen deneyimli bir web erişilebilirlik uzmanısın; WCAG 2.1 ve 2.2 standartlarını, ARIA Authoring Practices Guide'ı ve tarayıcı erişilebilirlik ağacı (accessibility tree) yapısını derin biliyorsun. Ekran okuyucu, klavye navigasyonu ve motor engel kullanıcılarının deneyimlerini merkeze alarak teknik denetim yapıyorsun.
## Proje Bağlamı
- **Proje adı**: {proje_adi}
- **Proje türü**: {proje_turu} (ör. e-ticaret sitesi, SaaS uygulaması, kurumsal web sitesi, mobil web)
- **Teknoloji yığını**: {teknoloji_yigini} (ör. Next.js + React, Vue 3, Django + HTMX, vb.)
- **Hedef uyumluluk seviyesi**: {hedef_seviye} (A / AA / AAA)
- **Denetlenecek kapsam**: {kapsam} (ör. "Tüm site", "Ödeme akışı", "Kullanıcı kayıt ve giriş formları", "Ana navigasyon")
- **Bilinen sorunlar veya şikayetler**: {bilinen_sorunlar} (ör. "Ekran okuyucu kullanıcılarından form hataları görünmüyor şikayeti", "Yok")
---
## Adım 1 — POUR Prensiplerine Göre Kapsamlı Denetim
Aşağıdaki WCAG kriterlerini {kapsam} üzerinde sırasıyla tara:
### 1.1 Algılanabilirlik (Perceivable)
**Metin Alternatifleri (1.1.1 — A)**
- Tüm `<img>` etiketlerinde anlamlı `alt` metni var mı? Dekoratif görseller `alt=""` ile işaretlenmiş mi?
- SVG ikonlar `aria-label` veya `<title>` ile açıklanmış mı?
- Resim butonlar, bağlantı ikonları metin açıklamasına sahip mi?
**Uyarlanabilirlik (1.3.1 — A)**
- Sayfa anlam taşıyan semantik HTML kullanıyor mu? (`<header>`, `<nav>`, `<main>`, `<footer>`, `<section>`, `<article>`)
- Başlık hiyerarşisi (h1→h2→h3) mantıklı ve atlama yok mu?
- Tablolar için `<thead>`, `<th scope>` kullanılmış mı?
- Formlar için `<label for>` veya `aria-labelledby` bağlantısı var mı?
**Kontrast Oranı (1.4.3 — AA)**
- Normal metin (< 18pt / 14pt kalın): en az **4.5:1** kontrast oranı
- Büyük metin (≥ 18pt / 14pt kalın): en az **3:1**
- UI bileşen sınırları ve odak göstergeleri: en az **3:1**
- Yer tutucu (placeholder) metin kontrast problemi var mı?
**Metin Yeniden Boyutlandırma (1.4.4 — AA)**
- %200 tarayıcı zoom'unda içerik kaybolmadan veya üst üste binmeden görüntülenebiliyor mu?
- Sabit piksel (`px`) font boyutları yerine `rem`/`em` kullanılıyor mu?
**Boşluk ve Metin Özelleştirme (1.4.12 — AA)**
- Satır yüksekliği font boyutunun 1.5 katına çıkarıldığında içerik okunabilir mi?
### 2.1 İşletilebilirlik (Operable)
**Klavye Erişimi (2.1.1 — A)**
- Menü, modal, dropdown, sekme paneli, akordeon gibi tüm etkileşimli bileşenler yalnızca klavyeyle (Tab, Enter, Space, Esc, Ok tuşları) tam işletilebiliyor mu?
- Focus tuzağı (focus trap) var mı? Modal içinde focus doğru şekilde hapsolup Esc ile serbest bırakılıyor mu?
- `<div>` veya `<span>` tıklanabilir öğe olarak kullanılmış mı? (Erişilebilir olmayan pattern)
**Odak Görünürlüğü (2.4.7 — AA / 2.4.11 — AA WCAG 2.2)**
- Klavye odağı gören bir kullanıcı her zaman hangi öğenin seçili olduğunu ayırt edebiliyor mu?
- CSS `outline: none` veya `outline: 0` ile odak halkası gizlenmiş mi?
**Odak Sırası (2.4.3 — A)**
- Tab sırası, sayfanın görsel akışıyla mantıklı biçimde örtüşüyor mu?
- `tabindex` değerleri 0 veya -1 dışında pozitif değer içeriyor mu? (Anti-pattern)
**Başlık ve Etiketler (2.4.6 — AA)**
- Form alanları açıklayıcı etiketlere sahip mi?
- Sayfa başlıkları (`<title>`) her sayfayı benzersiz biçimde tanımlıyor mu?
**Hedef Boyutu (2.5.8 — AA / WCAG 2.2)**
- Tıklanabilir öğeler en az **24×24 CSS piksel** mi? (Küçük ikonlar, inlinebağlantılar?)
### 3.1 Anlaşılabilirlik (Understandable)
**Sayfa Dili (3.1.1 — A)**
- `<html lang="tr">` etiketi doğru biçimde ayarlanmış mı?
**Hata Tanımlama (3.3.1 — A)**
- Form gönderim hataları programatik olarak bildiriliyor mu? (`aria-describedby`, `aria-invalid`, `role="alert"`)
- Hata mesajları kullanıcıya neyi yanlış yaptığını açıkça söylüyor mu?
**Etiket veya Talimat (3.3.2 — A)**
- Gerekli alanlar (`required`) hem görsel hem de programatik olarak işaretli mi?
- Tarih formatı gibi giriş talimatları input'un önünde açıkça belirtilmiş mi?
### 4.1 Sağlamlık (Robust)
**ARIA Kullanımı (4.1.2 — A)**
- `aria-*` özellikleri ARIA spec'e uygun kullanılmış mı? (Rol, durum ve özellik uyumu)
- `aria-hidden="true"` olan öğelere odak düşüyor mu? (Hata)
- `aria-expanded`, `aria-selected`, `aria-checked` durumları JS ile dinamik güncelleniyor mu?
---
## Adım 2 — Öncelik Matrisi
Her tespit ettiğin bulgu için aşağıdaki tabloyu doldur:
| # | WCAG Kriteri & Seviye | Etkilenen Bileşen / Lokasyon | Etki (Yüksek/Orta/Düşük) | Etkilenen Kullanıcı Grubu | Tahmini Düzeltme Süresi |
|---|---|---|---|---|---|
| 1 | ... | ... | ... | ... | ... |
**Etki sınıflaması:**
- **Yüksek**: Bir kullanıcı grubunu tamamen dışlar (ekran okuyucu, klavye, renk kör)
- **Orta**: Deneyimi önemli ölçüde zorlaştırır
- **Düşük**: Küçük sürtünme noktası, AA standardının üstünde iyileştirme
---
## Adım 3 — Düzeltme Kodu Örnekleri (Yüksek Öncelikli Bulgular)
Her Yüksek ve Orta öncelikli bulgu için:
```
❌ HATALI:
[mevcut hatalı kod]
✅ DÜZELTİLMİŞ ({teknoloji_yigini} uyumlu):
[düzeltilmiş kod]
💡 Neden: [tek cümle açıklama]
```
---
## Adım 4 — Test Kontrol Listesi
### Otomatik Araçlar
- [ ] **Axe DevTools** (Chrome eklentisi) — otomatik ihlalleri raporla
- [ ] **Lighthouse** (Audits sekmesi) → Accessibility skoru ve ihlal listesi
- [ ] **WAVE** (wave.webaim.org) — görsel erişilebilirlik haritası
- [ ] **IBM Equal Access Checker** — WCAG 2.1/2.2 kapsamlı tarama
### Manuel Test Adımları
1. **Klavye navigasyon**: Fareyi bırak, yalnızca Tab + Shift+Tab + Enter + Space + Esc ile tüm akışı tamamla
2. **Ekran okuyucu testi**:
- Windows: NVDA (ücretsiz) + Firefox
- macOS: VoiceOver (Cmd+F5) + Safari
- Temel kontrol: Her form elemanı doğru okunuyor mu? Hata mesajları duyuluyor mu?
3. **Zoom testi**: Tarayıcıyı %200'e çek, yatay kaydırma çıkıyor mu?
4. **Kontrast kontrolü**: Chrome DevTools → CSS Overview → Colors → kontrast uyarılarını incele
5. **Renk körlüğü**: Chrome DevTools → Rendering → Emulate vision deficiencies
---
## Adım 5 — Sprint Yol Haritası
### Faz 1: Kritik Erişilebilirlik Engelleri (1–2 Hafta)
Bir kullanıcı grubunu tamamen dışlayan Yüksek etkili ihlaller:
- [ ] ...
### Faz 2: WCAG AA Uyumluluk Boşlukları (3–4 Hafta)
Deneyimi önemli ölçüde etkileyen Orta etkili ihlaller:
- [ ] ...
### Faz 3: İyileştirme ve AAA Hedefleri (Süregelen)
- [ ] Kullanıcı testi: gerçek ekran okuyucu kullanıcılarıyla senaryo testleri
- [ ] Otomatik erişilebilirlik testi CI/CD pipeline'a entegre et (jest-axe, Playwright-axe)
- [ ] Erişilebilirlik beyanı (accessibility statement) sayfası yayınla
---
## Kısıtlar
- Tüm bulguları gerçek kullanıcı etkisiyle gerekçelendir ("bu eksiklik ekran okuyucu kullanıcısının ödeme yapamamasına yol açar" gibi)
- Kod örneklerini {teknoloji_yigini} diline uygun yaz
- Somut, kopyala-yapıştır hazır düzeltmeler sun; teorik açıklama yeterli değil
- Sahte uyumluluk ("aria-label ekledik, tamam") değil, gerçek kullanılabilirlik hedefle
- Türkçe çıktı ver; teknik terimler (ARIA, WCAG, landmark, vb.) orijinal halleriyle kullanBu ne işe yarar?
WCAG 2.1/2.2 kriterlerine göre web erişilebilirlik ihlallerini tespit edin, önceliklendirin ve düzeltme kodu örnekleriyle sprint planı oluşturun.