Erişilebilir Web Yol Haritası: WCAG Kontrol Listesinden Ürün Sistemine

1. Uyum Hedefini, Kapsamı ve Kullanıcı Görevini Birlikte Tanımlayın

WCAG 2.2; A, AA ve AAA olmak üzere üç uygunluk düzeyi tanımlar. AA uygunluğu, A ve AA düzeyindeki tüm başarı ölçütlerinin karşılanmasını gerektirir; uygunluk tam sayfa için değerlendirilir ve responsive görünümler de bu kapsama dahildir. W3C ayrıca tüm siteler için AAA düzeyini genel politika olarak zorunlu tutmayı önermez. Kurum önce tabi olduğu hukuk, sözleşme ve sektör şartlarını uzmanlarıyla doğrulamalı; ardından teknik hedefini açıkça yazmalıdır.W3C — Web Content Accessibility Guidelines (WCAG) 2.2

Standart hedefi tek başına kapsam değildir. Alan adları, mobil web, giriş gerektiren ekranlar, belge ve video türleri, üçüncü taraf ödeme ya da randevu akışları, desteklenen diller ve eski uygulamalar listelenmelidir. Kontrol sizde olmayan bileşenler kapsam dışı diye unutulmaz; tedarikçi riski, alternatif yol ve düzeltme takvimiyle yönetilir. ‘Yeni ana site, WCAG 2.2 AA’ gibi kısa bir cümleye bu sınırlar ve istisna süreci eklenmedikçe ekipler farklı projeleri ölçer.

Kapsamı hesap açma, ürün bulma, ödeme ve destek alma gibi kullanıcı görevlerine bağlayın. Düşük trafikli bir şifre sıfırlama ekranı kritik erişim kapısı olabilir; önceliği trafik kadar görevin zorunluluğu ve engelin şiddeti belirler.

2. Sayfa Saymak Yerine Şablon, Bileşen ve İçerik Envanteri Çıkarın

Binlerce URL'yi tek tek listelemek tekrar eden kök nedenleri gizler. Sayfaları ana şablonlara ayırın: ana sayfa, liste, detay, arama, form, hesap ve işlem ekranı. Ardından ortak menü, modal, sekme, açılır seçim, veri tablosu, bildirim ve dosya yükleme gibi bileşenleri eşleyin. İçerik tarafında başlık düzeni, bağlantı metni, alternatif metin, altyazı, transkript ve PDF üretim sürecini ayrı görünür kılın.

Başlangıç ölçümü dengeli örneklem kullanmalıdır. Yüksek trafik, kritik görev, farklı teknoloji, eski içerik ve bilinen şikâyetlerden sayfalar seçin. Otomatik tarama; eksik etiket, bazı renk kontrastları ve kod örüntülerini hızlı bulabilir. Fakat odak sırasının anlamlı olup olmadığını, hata mesajının anlaşılır olup olmadığını ya da ekran okuyucuda görevin tamamlanıp tamamlanmadığını tek başına kanıtlayamaz.

W3C'nin uygunluk değerlendirme kaynakları, WCAG-EM'i sitelerin WCAG'e uygunluğunu belirlemek için bir yaklaşım olarak sunar; rapor aracı ise kontrolü sizin yerinize yapmaz, değerlendirme adımlarını ve raporlamayı destekler. Bu ayrım önemlidir: araç çıktısı kanıt girdisidir, uygunluk kararı değildir.W3C WAI — Conformance Evaluation and Reports

3. Bulguları Şiddet, Yaygınlık ve Tekrar Riskiyle Sıralayın

Her bulguya yalnızca WCAG numarası vermek ürün kuyruğu oluşturmaz. Kullanıcı etkisini tarif edin: görev tamamen engelleniyor mu, ciddi ek çaba mı gerekiyor, yoksa küçük bir rahatsızlık mı? Kaç şablon ve bileşeni etkilediğini, geçici çözüm bulunup bulunmadığını ve düzeltmenin başka akışları bozma riskini ekleyin. Ortak menüdeki klavye tuzağı tek sayfadaki küçük kontrast sapmasından önce gelebilir.

Sahiplik katmanlıdır. Ürün yöneticisi kapsam ve önceliği; tasarım erişilebilir durumları ve etkileşimleri; içerik ekibi dil, yapı ve medya alternatiflerini; geliştirme semantik uygulamayı; kalite ekibi tekrar edilebilir testleri sahiplenir. Hukuk hedefi yorumlar, fakat kullanılabilir çözümü tek başına tasarlamaz. Her iş kartında kabul ölçütü, test ortamı, sorumlu ve doğrulayacak kişi bulunmalıdır.

Kök nedeni tasarım sistemi, içerik şablonu, uygulama kodu, üçüncü taraf veya editoryal süreç olarak etiketleyin. Tekil hatalar yerine ortak bileşeni düzeltin; farklı durumları ve kullanan şablonları regresyon testine alın.

• Her bulguda etkilenen kullanıcı ve görev açıkça yazılı.
• Şiddet, yaygınlık, geçici çözüm ve tekrar riski değerlendirildi.
• İşin uygulama sahibi ile bağımsız doğrulama sahibi belli.
• Ortak bileşen kaynaklı sorunlar tekil URL'lerden ayrıldı.
• Kabul kriterinde klavye, ekran okuyucu ve yakınlaştırma koşulları var.
• Üçüncü taraf engeller için tedarikçi ve alternatif yol planlandı.

4. Erişilebilirliği Tasarım ve Yayın Kalite Kapılarına Yerleştirin

Tasarım aşamasında her bileşenin klavye davranışı, odak görünümü, hata ve boş durumları, metin büyütme tepkisi ve yardımcı teknoloji adı tanımlanmalıdır. Yalnızca ideal ekran görüntüsü devredilirse geliştirici görünmeyen davranışları tahmin eder. İçerik modeli de başlık seviyesini, anlamlı bağlantı metnini ve medya alternatifini editörün iş akışına dahil etmelidir.

Kod aşamasında semantik HTML'yi temel alın; özel etkileşimleri ancak gerçek ihtiyaç varsa kurun. Bileşen testleri erişilebilir ad, rol, durum ve klavye davranışını; sayfa testleri odak akışını ve hata kurtarmayı kapsar. Otomatik kontroller pull request içinde hızlı geribildirim verir. Manuel senaryo ve yardımcı teknoloji testi, sürüm adayı üzerinde yapılır. Engelli kullanıcılarla araştırma ise ekibin ölçütü teknik olarak geçip gerçek görevi zorlaştıran kararları görmesini sağlar.

Kritik engeller yayını durdurur; daha düşük riskli bulgular, sahibi ve tarihi olan borç kaydına girebilir. İstisnada etkilenen kullanıcı, alternatif erişim, gerekçe ve son kullanma tarihi görünür olmalıdır.

5. Varsayımsal Senaryo: Başvuru Akışını Yeniden Önceliklendirmek

Bu senaryo varsayımsaldır; bir müşteri sonucu veya performans vaadi değildir. Bir hizmet platformunda 400 içerik sayfası, 12 ortak şablon ve dört adımlı başvuru akışı olsun. Otomatik tarama çoğunlukla dekoratif görsellerde alternatif metin ve düşük etkili kontrast bulguları üretiyor. Klavye testi ise tarih seçiciden çıkılamadığını; ekran okuyucu testi, üçüncü adımda hata özetinin okunmadığını gösteriyor. Başvuru, kurumun temel hizmetine erişim kapısıdır.

Ekip girdileri trafik, görev kritikliği, engel şiddeti ve ortak kök neden olarak puanlıyor. Karar, yüzlerce görsel kaydını önce kapatmak değil; tarih seçici ile hata özetini sürümü durduran işler yapmak oluyor. Tasarım sistemi ekibi erişilebilir tarih girişi ve hata örüntüsünü düzeltirken içerik ekibi dekoratif ve bilgi taşıyan görseller için karar ağacı hazırlıyor. Üçüncü taraf kimlik doğrulama ayrıca tedarikçi kaydına alınıyor.

Doğrulama, tek başarı puanı yerine iki gerçek görevi izliyor: yalnızca klavyeyle başvuru gönderme ve ekran okuyucuyla hatayı bulup düzeltme. Düzeltmeler desteklenen tarayıcı-yardımcı teknoloji kombinasyonlarında yeniden test ediliyor. Karar mantığı nettir: önce hizmete erişimi engelleyen sorun, sonra geniş tekrar alanı olan sistemik sorun, ardından düşük şiddetli içerik borcu.

6. İlk 90 Günlük Erişilebilirlik Operasyon Planı

İlk 30 günde sponsor, ürün sahibi ve teknik sorumluyu belirleyin; standart hedefini, kapsamı ve desteklenen test kombinasyonlarını yazın. Kritik kullanıcı yolculuklarını seçip şablon-bileşen envanteri çıkarın. Kullanıcı şikâyetlerini, otomatik taramayı ve manuel görev testini birleştirerek başlangıç tablosu oluşturun. Bu dönemin çıktısı kusursuz site değil, üzerinde uzlaşılmış risk resmi olmalıdır.

31–60. günlerde kritik engelleri ve ortak bileşen kök nedenlerini düzeltin. Tasarım sistemine erişilebilir durumları, içerik rehberine başlık-bağlantı-medya kurallarını, geliştirme şablonuna kabul ölçütlerini ekleyin. Tedarikçilere ölçülebilir gereksinimler iletin. En az bir kritik yolculuğu engelli katılımcılarla veya uygun uzman kullanıcı değerlendirmesiyle sınayın; bulguları ürün kararına bağlayın.

61–90. günlerde otomatik testleri sürekli entegrasyona, manuel kontrolleri sürüm listesine yerleştirin. Düzeltme süresi, tekrar eden hata ve kritik görev başarısını izleyin. Erişilebilir geri bildirim kanalını ürün kuyruğuna bağlayın; kalan risk ile istisna tarihlerini yönetime sunun.

• 0–30 gün: hedef, kapsam, görevler ve başlangıç değerlendirmesi tamam.
• 31–60 gün: kritik engeller ve ortak bileşen sorunları düzeltiliyor.
• 31–60 gün: tasarım, içerik ve kod rehberleri güncellendi.
• 61–90 gün: otomatik ve manuel kalite kapıları devrede.
• 61–90 gün: geri bildirim, gösterge ve istisna yönetimi çalışıyor.

7. Sınırlar ve Başarısızlık Modları: Uygunluk Kullanılabilirliğin Tamamı Değildir

WCAG güçlü ve test edilebilir bir ortak taban sağlar; yine de her engel türünün, bağlamın ve kişi kombinasyonunun tüm ihtiyaçlarını tek başına kapsamaz. Teknik uygunluk iddiası, ürünün herkes için kolay olduğu anlamına gelmez. Bu yüzden standart testi; görev başarısı, destek geri bildirimi, içerik anlaşılırlığı ve engelli kullanıcı araştırmasıyla tamamlanmalıdır. Bu yazı da hukuki uygunluk görüşü değildir; ülke, sektör ve sözleşme yükümlülükleri uzmanlarla doğrulanmalıdır.

Yaygın başarısızlıklar otomatik skoru uygunluk ilan etmek, erişilebilirliği tek uzmana devretmek ve üçüncü tarafları görmezden gelmektir. Overlay araçları temel kod sorunlarının yerini tutmaz; tek denetim yeni değişikliklerin regresyonunu yakalayamaz.

Programın sürdürülebilirliği için az ama anlamlı gösterge seçin. Açık hata sayısı tek başına kötü bir ölçüdür; daha iyi rapor, kritik görevlerdeki engelleyici hata, ortak bileşenlerin test kapsamı, düzeltme süresi, tekrarlayan kök neden ve kullanıcı geri bildirimini birlikte gösterir. Amaç raporu yeşile boyamak değil, erişim engelinin üretim sisteminde tekrar oluşmasını zorlaştırmaktır.