Dijital Erişilebilirlik Hazırlık Kılavuzu: İhtiyacınız Olan Kontrol Listesi

Mevzuata Uygun WCAG (Web İçeriği Erişilebilirlik Yönergeleri – Web Content Accessibility Guidelines) Uyum Rehberi (Web, iOS, Android)

Erişilebilirlik çalışmaları çoğu zaman “bir rapor çıkaralım” ya da “yayına yetiştirelim” yaklaşımıyla başlıyor. Ancak erişilebilirlik; tek seferlik bir kontrol değil, ürün geliştirme sürecinin içine yerleşmesi gereken bir kalite standardı.

Bu blog içeriği, aynı zamanda sayfa içinde kullanılabilen bir ücretsiz e-book olarak tasarlandı:

Amaç, ekiplerin erişilebilirliği daha hızlı ve daha doğru yönetebilmesi için uygulanabilir bir checklist sunmak.

WCAG (Web İçeriği Erişilebilirlik Yönergeleri – Web Content Accessibility Guidelines) Bilmek Yetmez: Regülasyon Uyumu Ne Demektir?

WCAG (Web Content Accessibility Guidelines), web siteleri ve mobil uygulamalar dahil dijital ürünlerin; farklı ihtiyaçları olan kullanıcılar tarafından algılanabilir, kullanılabilir, anlaşılabilir ve sağlam şekilde kullanılmasını hedefleyen uluslararası erişilebilirlik standartlarıdır.

Regülasyon uyumu ise, kurumların dijital kanallarını yürürlükteki mevzuat ve denetim beklentileri doğrultusunda belirli bir erişilebilirlik seviyesinde sunması anlamına gelir. Örneğin; Türkiye’de 21 Haziran 2025 tarihli Dijital Erişilebilirlik Genelgesi, Avrupa Birliği’nde EAA (European Accessibility Act: Avrupa Erişilebilirlik Yasası) gibi düzenlemeler; dijital ürün ve hizmetlerin belirli WCAG seviyelerinde erişilebilir olmasını zorunlu kılar.

Pratikte bu, yalnızca “WCAG’i biliyoruz” demek değildir. Asıl mesele; kredi başvurusu, ödeme adımı, üyelik oluşturma veya form doldurma gibi kritik akışların ekran okuyucu, klavye navigasyonu ve farklı kullanıcı senaryoları ile baştan sona gerçekten tamamlanabildiğini kanıtlayabilmektir. Regülasyon uyumu, dokümantasyon beyanı değil; test edilmiş, ölçülmüş ve doğrulanmış kullanıcı deneyimidir.

Günlük Hayattan Örnekler

“Küçük” Görünen Detaylar Neden Büyük Sonuçlar Doğurur?

Aşağıdaki örnekler, erişilebilirliğin doğrudan “işlem tamamlanabilirliği” ile ilgili olduğunu gösterir:

Görme engelli kullanıcı için ekran okuyucu deneyimi: Mobil bankacılık uygulamasına giriş yapıyorsunuz ve elektrik faturanız için otomatik ödeme talimatı vermek istiyorsunuz. Ekran okuyucu ile ilerliyorsunuz. Parmağınızı kaydırarak bir sonraki öğeye geçtiğinizde ekran okuyucu yalnızca “Button” diyor. Hangi buton? Devam mı, iptal mi, kaydet mi? Bir adım daha ilerliyorsunuz, bu kez görsel olarak net duran bir ikon hiç okunmuyor. Talimatı onaylamanız gereken kritik noktada hangi seçeneğin ne işe yaradığını anlayamıyorsunuz. Özellikle giriş, ödeme, transfer veya doğrulama gibi kritik akışlarda bu belirsizlik işlemin daha tamamlanamadan tıkanmasına neden olur. Yanlış bir işlem yapma riskiyle karşı karşıya kalırsınız ya da süreci tamamen bırakmak zorunda kalırsınız. Bu nedenle etkileşimli öğelerin anlamlı şekilde etiketlenmesi ve odak sırasının doğru yönetilmesi yalnızca teknik bir detay değil; işlemi bağımsız ve güvenli biçimde tamamlayabilmeniz için kritik bir gerekliliktir.

• Gürültülü ortamda doğrulama: OTP veya kritik bilgilendirme adımı yalnızca sesle iletiliyorsa, gürültülü ortamda veya ses açmanın mümkün olmadığı bir durumda süreç aksar. Metin alternatifleri bu yüzden kritiktir.
• Tek elle kullanım & küçük hedefler: Çok küçük kapatma ikonu (“X”) veya dar dokunma alanları, motor becerileri kısıtlı kullanıcılar için zorlayıcıdır; aynı zamanda hareket halindeyken tek elle telefon kullanan herkes için hataya açıktır.
• Renkle anlatılan hata: “Kırmızı alanları doldurun” gibi yönlendirmeler, renk görme farklılıkları olan kullanıcılar için risklidir; ayrıca güneş altında ekrana bakarken herkes için kaçabilir.
• Altyazısız video: İşitme engeli olan kullanıcıların yanı sıra, sessiz ortamda ses açmadan içerik tüketen kullanıcılar için de erişimi düşürür.
• Belirsiz buton isimleri: Birden fazla “Devam” butonu, kullanıcıyı kararsız bırakır; “Ödemeye geç / Adres seç / Siparişi onayla” gibi net adlandırmalar bilişsel yükü azaltır.

Bu E-book’un Amacı

Bu checklist ile hedefimiz şunları mümkün kılmak:

• Erişilebilirlik çalışmalarında nereden başlanacağını netleştirmek
• Tasarım, yazılım ve test ekipleri için ortak bir kontrol listesi oluşturmak
• “Uyumluyuz” demenin ötesine geçip, kullanıcıların kritik işlemleri baştan sona tamamlayabildiğini doğrulamak
• Süreci “son dakika düzeltmesi” olmaktan çıkarıp, sürdürülebilir hale getirmek

BlindLook Bu Süreci Nasıl Yürütür?

BlindLook, erişilebilirliği yalnızca “bulgu listesi” olarak değil, dijital ürün yaşam döngüsüne yerleşen bir kalite standardı olarak ele alır:

• Erişilebilirlik denetimi (Audit): Web ve mobil kanallarda erişilebilirlik sorunlarını tespit eder ve uygulanabilir önerilerle raporlar.
• Gerçek kullanıcı testleri: özellikle ekran okuyucu senaryolarında kritik akışların gerçekten tamamlanabilir olup olmadığını doğrulamayı amaçlar. Bu kapsamda iOS cihazlarda VoiceOver, Android cihazlarda TalkBack, Windows işletim sisteminde JAWS (Job Access With Speech) ve NVDA (NonVisual Desktop Access), macOS’ta ise yine VoiceOver kullanılarak testler gerçekleştirilir.
• Uygulanabilir geliştirme önerileri: accessibilityLabel, contentDescription, odak yönetimi, form/hata mesajları gibi alanlarda ne yapılacağını doğrudan uygulanabilir hale getirir.
• WCAG yol haritası: kurumun ürün ve sprint döngüsüne entegre edilmiş, sürdürülebilir bir gelişim planı oluşturmayı hedefler. Bu yaklaşım yalnızca belirli bir denetim dönemine odaklanan geçici iyileştirmeler değil; erişilebilirliğin yazılım geliştirme yaşam döngüsünün (SDLC – Software Development Life Cycle) tüm aşamalarına sistematik biçimde dahil edilmesini kapsar. Analiz, tasarım, geliştirme, test ve yayına alma süreçlerinde WCAG kriterlerinin gözetilmesi sağlanarak, erişilebilirlik tek seferlik bir proje değil, ürünün doğal bir kalite standardı haline getirilir.

Özet

Bu e-book, erişilebilirlik çalışmalarını “tek seferlik kontrol” olmaktan çıkarıp ekiplerin uygulayabileceği net bir hazırlık checklist’i haline getirir. iOS, Android ve web için ortak bir çerçeve sunar; tasarım, geliştirme ve test ekiplerinin aynı maddeler üzerinden ilerlemesini kolaylaştırır.

Checklist’in odağı; kullanıcıların kritik akışları (giriş, ödeme/transfer, şifre yenileme gibi) yardım almadan baştan sona tamamlayabilmesi için en çok kırılan alanlardır:

• Buton ve alanların doğru/adresli okunması (accessibilityLabel, contentDescription)
• Odak (focus) yönetimi ve popup/modal davranışları
• Formlar ve hata mesajlarının anlaşılır olması
• Dinamik durum mesajlarının kullanıcıya iletilmesi
• Doğrulama adımlarının (OTP/CAPTCHA vb.) erişilebilir kurgulanması

Ayrıca düşük görme, işitme, motor ve bilişsel ihtiyaçlar için tamamlayıcı kontrol setleri ve pratik bir test yaklaşımı da içerir. Amaç; erişilebilirliği sonradan “düzeltilecek” bir konu değil, ürünün kalıcı bir kalite standardı olarak yönetilebilir bir sürece dönüştürmektir.

Ücretsiz E-book Dijital Erişilebilirlik Hazırlık Kılavuzu

Mevzuata Uygun WCAG Uyum Rehberi 

Dijital erişilebilirlik,platformları tek seferlik bir denetimden geçirmekten ibaret değildir. Regülasyon uyumu; dijital ürünlerin (web ve mobil) kritik akışlarının farklı ihtiyaçları olan kullanıcılar tarafından baştan sona tamamlanabilir olmasını gerektirir. Bu e-book; ekiplerin aynı hedefe hizalanmasını, doğru sırayla ilerlemesini ve Level A kapsamındaki temel gereklilikleri pratik biçimde uygulamasını kolaylaştırmak için hazırlanmıştır.

Bu sayfa nasıl kullanılır?

Önerilen uygulama sırası:

1. Ürünün en kritik 2–3 akışını seçin (giriş, ödeme/transfer, şifre yenileme/OTP).
2. “Hızlı Tarama” ile ilk riskleri yakalayın.
3. “WCAG 2.2 Level A Checklist” bölümündeki maddeleri uygulayın.
4. “Test ve Doğrulama” adımlarını tamamlayın.
5. Bulgu kayıt şablonuyla çıktıyı standardize edin.

İçindekiler

1. Hızlı Tarama (15–30 dk)
2. WCAG 2.2 Level A Checklist (4 İlke)
3. 2.1 Algılanabilir (Perceivable)
4. 2.2 Kullanılabilir (Operable)
5. 2.3 Anlaşılabilir (Understandable)
6. 2.4 Sağlam (Robust)
7. Platform Notları (Web / iOS / Android)
8. Test ve Doğrulama (Manuel + Otomatik + Senaryo)
9. Bulgu Kaydı Şablonu

1) Hızlı Tarama (15–30 dk)

Bu bölüm, en yaygın “işlem tamamlanamıyor” problemlerini hızlıca yakalamak için hazırlanmıştır.

Hızlı Kontrol Adımları

• Keyboard Navigation: Tab tuşu ile tüm sayfa gezinilebiliyor mu?
• Alt Text: Tüm görsellerde uygun alt text var mı?
• Form Labels: Tüm form alanlarında label var mı?
• Color Contrast: Metin okunabilir kontrasta sahip mi?
• Page Title: Sayfa başlığı açıklayıcı mı?
• HTML Validity: HTML geçerli mi?
• Focus Indicators: Focus göstergeleri görünür mü?
• Error Messages: Hata mesajları açık ve anlaşılır mı?

Bu 8 madde, pratikte Level A’da en sık yakalanan kritik kırılımların büyük bölümünü ortaya çıkarır.

2) WCAG 2.2 Level A Checklist

Aşağıdaki checklist, Level A kapsamındaki başarı kriterlerinin “ne istiyor?” ve “nasıl çözülür?” karşılığını pratik hale getirir.

2.1 Algılanabilir (Perceivable)

1.1 Metin Alternatifleri

1.1.1 Metin Dışı İçerik (A)

Gereklilik: Tüm metin dışı içerikler için eşdeğer metin alternatifleri sağlanmalıdır.

Uygulama Checklist’i

• Tüm anlamlı görsellerde açıklayıcı alt var.
• Dekoratif görseller alt="" ile boş bırakılmış.
• Grafik/diyagram gibi karmaşık görseller için detaylı açıklama sağlanmış.
• Form kontrolleri için uygun etiketleme yapılmış.
• CAPTCHA varsa alternatif sunulmuş.

1.2 Zamana Bağlı Medya

1.2.1 Sadece Ses / Sadece Video (Önceden Kaydedilmiş) (A)

• Ses kayıtları için transkript mevcut.
• Sessiz videolar için açıklama/metin alternatifi mevcut.

1.2.2 Altyazılar (Önceden Kaydedilmiş) (A)

• Videolarda doğru altyazı mevcut.
• Önemli ses efektleri altyazıda belirtilmiş.
• Uygun altyazı formatı kullanılmış.

1.2.3 Ses Açıklaması veya Medya Alternatifi (Önceden Kaydedilmiş) (A)

• Görsel açıdan kritik bilgi için sesli betimleme veya tam metin alternatif mevcut.

1.3 Uyarlanabilir

1.3.1 Bilgi ve İlişkiler (A)

• Başlık yapısı doğru (h1–h6).
• Tablolarda th ve scope kullanılmış.
• Listeler ul/ol/li ile kurulmuş.
• Form alanlarında label var.
• Gerekli yerlerde doğru ARIA kullanılmış.

1.3.2 Anlamlı Sıra (A)

• DOM sırası mantıklı.
• CSS ile görsel sıra değişse bile okuma sırası bozulmuyor.
• Flex/Grid order kullanımı odak/okuma sırasını bozmayacak şekilde.

1.3.3 Duyusal Özellikler (A)

• Talimatlar sadece “sağdaki kırmızı buton” gibi duyusal ifadelerle verilmemiş.
• Renk/konum yerine metinle net tanımlama yapılmış.

1.4 Ayırt Edilebilir

1.4.1 Rengin Kullanımı (A)

• Renk tek başına bilgi taşıma aracı değil.
• Zorunlu alanlar sadece renkle değil sembol/metinle de belirtilmiş.
• Linkler sadece renkle değil ek göstergelerle ayırt edilebilir.

1.4.2 Ses Kontrolü (A)

• 3 saniyeden uzun otomatik ses varsa durdur/duraklat kontrolü var.
• Otomatik oynatma yerine kullanıcı onayı tercih edilmiş.

2.2 Kullanılabilir (Operable)

2.1 Klavye Erişilebilirliği

2.1.1 Klavye (A)

• Tüm işlevler klavyeyle kullanılabiliyor.
• Custom kontrollerde keyboard event’ler tanımlı.
• tabindex doğru kullanılmış.
• Focus management doğru.

2.1.2 Klavye Tuzağı Yok (A)

• Focus bir bileşene girdiyse klavyeyle çıkabiliyor.
• Modal’larda çıkış/odak kapanma davranışı doğru.

2.1.4 Karakter Tuşu Kısayolları (A)

• Tek karakter kısayollar kapatılabilir/yeniden atanabilir.

2.2 Yeterli Zaman

2.2.1 Zamanlama Ayarlanabilir (A)

• Zaman sınırı kapatılabilir/uzatılabilir.
• Süre dolmadan uyarı ve uzatma seçeneği var.

2.2.2 Duraklat, Durdur, Gizle (A)

• Hareketli/yanıp sönen/otomatik güncellenen içerik kontrol edilebilir.
• Carousel için play/pause var.
• Azaltılmış hareket tercihi destekleniyor.

2.3 Nöbetler ve Fiziksel Tepkiler

2.3.1 Üç Yanıp Sönme veya Eşiğin Altı (A)

• Saniyede 3’ten fazla yanıp sönen içerik yok.

2.4 Gezinilebilir

2.4.1 Blokları Atla (A)

• “Ana içeriğe atla” (skip link) mevcut.
• Landmark/başlık yapısı doğru.

2.4.2 Sayfa Başlıklı (A)

• Her sayfanın benzersiz ve açıklayıcı başlığı var.

2.4.3 Focus Sırası (A)

• Focus sırası anlamı ve kullanılabilirliği koruyor.
• Modal’larda focus trap doğru.

2.4.4 Link Amacı (Bağlamında) (A)

• “Buraya tıklayın” yerine açıklayıcı link metinleri var.
• Link amacı metinden/bağlamdan anlaşılabiliyor.

2.3 Anlaşılabilir (Understandable)

3.1 Okunabilir

3.1.1 Sayfanın Dili (A)

• Varsayılan dil lang ile belirtilmiş.
• Çok dilli içerikte ilgili bölümlere doğru lang atanmış.

3.2 Öngörülebilir

3.2.1 Focus’ta (A)

• Bir bileşen focus aldığında beklenmedik bağlam değişikliği olmuyor.

3.2.2 Girdi Halinde (A)

• Dropdown/radio/checkbox değişiklikleri otomatik yönlendirmeye neden olmuyor; kullanıcı onayı var.

3.3 Girdi Yardımı

3.3.1 Hata Tanımlama (A)

• Hatalı alan tanımlanıyor.
• Hatanın ne olduğu açıklanıyor.
• Hata mesajı ilgili alanla ilişkilendiriliyor (aria-describedby, aria-invalid).

3.3.2 Etiketler veya Talimatlar (A)

• Tüm alanlarda açık etiket/talimat var.
• Gerekli alanlar belirtilmiş.
• Format örnekleri verilmiş.

2.4 Sağlam (Robust)

4.1 Uyumlu

4.1.1 Ayrıştırma (A)

• HTML geçerli.
• Etiketler doğru kapanıyor, benzersiz ID’ler var.
• Eski/terk edilmiş etiketler kullanılmıyor.

4.1.2 İsim, Rol, Değer (A)

• Tüm UI bileşenlerinin isim/rol/değeri programsal olarak belirlenebilir.
• Semantic HTML kullanılmış.
• Custom kontroller erişilebilirlik API’larını destekliyor.

3) Platform Notları (Web / iOS / Android)

Bu bölüm, checklist maddelerinin platformlara nasıl yansıdığını pratikleştirir.

Web

• “Klavye ile tam kullanım” (Tab/Shift+Tab/Enter/Space/Esc) birincil doğrulama yöntemidir.
• Skip link, doğru başlık hiyerarşisi, açıklayıcı link metinleri Level A’da çok yüksek etki üretir.

iOS (VoiceOver)

• Etkileşimli öğelerin erişilebilir adı, rolü ve durumu doğru olmalıdır (buton gibi davranan öğe, ekran okuyucuda da buton gibi sunulmalı).
• İkon butonlarda anlamlı isimlendirme kritik: accessibilityLabel.

Android (TalkBack)

• İkon/görsel öğelerde anlamlı isimlendirme kritik: contentDescription.
• Odak sırası, dinamik bildirimler ve form hatalarının kullanıcıya iletilmesi kritik.

4) Test ve Doğrulama

Manuel Test (önerilen minimum set)

• Web: yalnızca klavye ile kritik akış tamamlanıyor mu?
• Web: alt text / form label / hata mesajı / odak göstergesi kontrolü.
• Mobil: VoiceOver/TalkBack ile kritik akış tamamlanıyor mu?

Senaryo Bazlı Test (örnek)

• Giriş → doğrulama → hata verdirme → hatayı düzeltme → başarı mesajı
• Arama/filtre → liste → detay → işlem → sonuç

5) Bulgu Kaydı Şablonu 

• Bulgu ID:
• Platform: Web / iOS / Android
• Ekran / Sayfa / URL:
• İlgili WCAG Kriteri:
• Sorun Tanımı:
• Kullanıcı Etkisi (işlem tamamlanıyor mu?):
• Önerilen Çözüm:
• Kanıt (video/screenshot):
• Durum: Açık / Devam / Kapandı
• Not: