Tarama Tabanlı mı, Denetim Tabanlı mı? Otomatik Tarama Neden Sahte Uyum Hissi Yaratır

Birçok ekip “erişilebilirlik taraması yaptık, sorunlar kapandı” cümlesini bir tür güvence olarak görüyor. Oysa tarama tabanlı araçlar, WCAG uyumluluğu açısından yalnızca görünen buzdağının küçük bir bölümünü yakalar. Sonuç: ölçülmüş ama anlaşılmamış riskler, yanlış önceliklendirme ve en önemlisi sahte bir uyum hissi.

Bu yazıda tarama tabanlı (scan-based) yaklaşımla denetim tabanlı (audit-based) yaklaşımın farkını, otomatik taramaların neden kaçınılmaz olarak eksik kaldığını ve erişilebilirlik uyumunu sürdürülebilir şekilde nasıl yöneteceğinizi ele alacağız.

Tarama tabanlı ve denetim tabanlı yaklaşımlar: Kısa tanımlar

Tarama tabanlı (scan-based) yaklaşım nedir?

Tarama tabanlı yaklaşım, bir web sitesini otomatik araçlarla (crawler, lint, tarayıcı eklentileri vb.) tarayıp makine tarafından tespit edilebilen hataları raporlar. Örneğin: eksik alt metinleri, düşük renk kontrastı, eksik form etiketleri, bazı ARIA hataları gibi.

Denetim tabanlı (audit-based) yaklaşım nedir?

Denetim tabanlı yaklaşım ise otomasyonu, manuel değerlendirme, yardımcı teknolojilerle (ekran okuyucu, klavye, büyütme araçları) kullanım testleri ve tasarım/akış incelemesiyle birleştirir. Amaç yalnızca “hata listesi” değil; kullanılabilirlik, engelli kullanıcı deneyimi ve WCAG başarı kriterleri açısından gerçek uyumu doğrulamaktır.

Otomatik taramalar neden “uyumlu” olduğunuz izlenimini verir?

Otomatik tarama raporları genellikle yüzlerce satır bulgu üretir. Bu “çok ölçüm yapıldı” hissi, gerçek uyumla karıştırılır. Ayrıca bazı araçlar skor/rozet gibi göstergelerle uyumu basitleştirir. Oysa WCAG bir “puanlama” sistemi değil; kullanıcıların içerik ve işlevlere erişebilmesini hedefleyen bir standarttır.

1) WCAG kriterlerinin önemli bir kısmı otomasyonla doğrulanamaz

Endüstride sık atıf yapılan gerçek şudur: WCAG kriterlerinin tamamı otomatik olarak test edilemez. Bunun nedeni, birçok kriterin bağlam, anlam ve kullanıcı niyeti gerektirmesidir. Örnekler:

• Alt metin var mı? Otomasyon kontrol eder. Alt metin doğru mu? Çoğu zaman manuel değerlendirme gerekir.
• Başlık hiyerarşisi teknik olarak var olabilir, ancak sayfa yapısını gerçekten açıklıyor mu? Bu, içerik bağlamıyla anlaşılır.
• Hata mesajları: “Geçersiz değer” demek yerine kullanıcıya nasıl düzeltileceğini söylüyor mu?
• Odak sırası: Klavye ile gezerken odak mantıklı bir akış izliyor mu? Bu genellikle gerçek etkileşimle anlaşılır.

2) Dinamik arayüzlerde (SPA, modallar, bileşen kütüphaneleri) tarama körleşir

Modern web uygulamalarında içerik, kullanıcı etkileşimiyle yüklenir. Otomatik tarayıcılar her durumu tetikleyemez: açılır menüler, doğrulama hataları, çok adımlı formlar, sepet akışları, takvim bileşenleri… Bu nedenle “sayfa tarandı” demek “akış erişilebilir” demek değildir.

3) “Overlay/Widget ekledik, tamamdır” yanılgısı

Bazı ekipler tarama raporunda az hata görünce üstüne bir erişilebilirlik overlay’i ekleyerek uyumluluk sağladığını düşünür. Ancak overlay’ler çoğu zaman temel sorunları çözmez; hatta yardımcı teknolojilerle çakışma ve yanlış beklenti yaratabilir. Bu konunun arka planı için Erişilebilirlik Overlay’leri Gözden Düşüyor: Yerine Ne Geliyor? yazısındaki yaklaşımlar, “ürün içi düzeltme” ve süreç olgunluğu açısından iyi bir çerçeve sunar.

Tarama yakalar, denetim doğrular: Kaçırılan “kritik” örnekler

Otomatik taramalar genellikle bulunması kolay ve tekrarlanabilir hatalarda iyidir. Denetimler ise kullanıcı için gerçekten engel oluşturan durumları ortaya çıkarır. Aşağıdaki örnekler, sahada sık görülen “tarama temiz ama deneyim bozuk” senaryolarıdır:

Klavye tuzağı ve odak yönetimi

Bir modal açıldığında odak modal içine alınmıyorsa, Esc ile kapanmıyorsa veya tab ile arka plana kaçıyorsa; kullanıcı akıştan kopar. Tarama bu durumu çoğu zaman “hata” olarak işaretlemez, çünkü sorun etkileşim anında ortaya çıkar.

Ekran okuyucu ile isim-rol-değer (Name/Role/Value) uyumsuzluğu

Bir buton görsel olarak doğru olabilir ama ekran okuyucu “button, unlabeled” diyebilir. Veya bir sekme (tab) bileşeni ARIA ile “tab” gibi görünse de klavye davranışı WAI-ARIA Authoring Practices ile uyumlu değildir. Bu tür hataları anlamanın yolu, NVDA/JAWS/VoiceOver ile test etmektir.

Hata önleme ve yardım (özellikle formlarda)

Form alanında hata çıkıyor ama hata mesajı alana programatik olarak bağlanmıyorsa (ör. aria-describedby), ekran okuyucu kullanıcıları hatayı fark etmeyebilir. Ayrıca “neden hata aldım, nasıl düzelteceğim?” açıklaması yoksa, kullanıcı görevi tamamlayamaz. Tarama “hata metni var” diyebilir; ama kullanılabilirlik ve anlaşılırlık denetimde ortaya çıkar.

“Tarama”yı çöpe atmayın: Doğru yerde çok değerlidir

Otomatik taramalar gereksiz değildir; tersine doğru konumlandığında çok güçlüdür:

• CI/CD içinde regresyonları yakalar (yeni bir bileşen kontrastı bozdu mu?).
• Sürekli izleme ile içerik güncellemelerinden doğan hataları erken görür.
• Önceliklendirme için trend verisi sağlar (hangi şablonlar en çok hata üretiyor?).

Örneğin Corpowid (corpowid.ai) ile otomatik tarama ve izleme süreçleri kurulup, tekrar eden teknik hatalar erken yakalanabilir; böylece denetimdeki manuel emek “anlam ve deneyim” gerektiren kritik alanlara ayrılır.

Denetim tabanlı uyum: Sadece rapor değil, süreç tasarımı

Gerçek uyum, tek seferlik bir “denetim raporu” değil; tasarım, geliştirme ve içerik üretiminin tamamına yayılan bir sistemdir. Denetim tabanlı yaklaşımda aşağıdaki bileşenler birlikte düşünülür:

1) WCAG kapsamı ve seviye hedefi (2.2 dahil)

“WCAG 2.1 AA” hedefi hâlâ yaygın; ancak güncel beklentiler ve kurum içi standartlaşma için 2.2’nin temel seviye olarak ele alınması giderek önem kazanıyor. Bu konuda WCAG 2.1 vs 2.2: Yeni Temel Seviyeyi Neden Şimdi Benimsemelisiniz? yazısındaki farklar, denetim planınıza doğrudan etki eder.

2) Akış bazlı test (kritik görevler)

Sayfa sayfa taramak yerine “kullanıcı görevi” düşünün: kayıt olma, ödeme, randevu alma, PDF indirme, destek talebi açma. Denetim, bu akışları klavye ve ekran okuyucu ile gerçekçi şekilde doğrular.

3) Tasarım sistemine geri besleme

En büyük kazanım, aynı hatayı 50 sayfada tek tek düzeltmek değil; tasarım sistemi/komponent kütüphanesinde düzeltip tüm ürüne yaymaktır. Bu aynı zamanda “AI ile hızlı site üretimi” trendinde bir tür borç birikimini de engeller. Çünkü yapay zekâ ile üretilen arayüzlerde erişilebilirlik hataları kolayca çoğalır; bu riskin dinamiklerini “Vibe Coding” ve Yapay Zekâ ile Yapılan Sitelerin Gizli Erişilebilirlik Borcu yazısında görebilirsiniz.

Uyumluluk, risk ve kanıt: “False sense of compliance”ın maliyeti

Sahte uyum hissi sadece kullanıcı deneyimini değil, kurumsal riski de büyütür. Çünkü tarama raporu “yeşil” olsa bile:

• Şikâyetler ve erişim engeli devam edebilir (itibar ve müşteri kaybı).
• Hukuki/ihale uyumluluğu için istenen kanıtlar (denetim kapsamı, yöntem, örneklem) eksik kalabilir.
• Ekipler yanlış metriklerle başarıyı ölçer (skor yükseldi ama dönüşüm düşüyor gibi).

Özellikle AI destekli araçlarda “tam otomatik uyum” iddialarına karşı temkinli olmak gerekir; güvenlik bariyerleri ve insan doğrulaması ihtiyacını Yapay Zekâ Erişilebilirlik Araçları İçin Kör Güven Değil, Korkuluklar Gerek yaklaşımı iyi özetler.

Pratik yol haritası: Taramayı denetimle birleştiren hibrit model

Erişilebilirlikte en iyi sonuçlar genellikle hibrit bir modelle gelir. Aşağıdaki adımlar, “tarama = başlangıç, denetim = doğrulama” mantığıyla uygulanabilir:

• 1) Baz çizgi taraması: Şablonlarınızı ve kritik sayfaları otomatik tarayın; tekrar eden teknik hataları sınıflandırın.
• 2) Risk bazlı denetim: En çok kullanılan akışları (kayıt, ödeme, arama, form) manuel test edin; ekran okuyucu + klavye kombinasyonunu standart hale getirin.
• 3) Düzeltmeleri sistemleştirin: Komponent seviyesinde düzeltip tasarım sistemine işleyin; kod inceleme checklist’i oluşturun.
• 4) Sürekli izleme: Yayına çıktıktan sonra yeni içerik ve release’lerle hataların geri gelmesini engelleyin.
• 5) Şeffaflık: Erişilebilirlik beyanınızı güncel tutun; kapsam, bilinen sınırlılıklar ve iletişim kanalı net olsun.

Corpowid (corpowid.ai), otomatik denetim/tarama ve izleme çıktılarının düzenli takip edilmesini kolaylaştırıp, ekiplerin “sürekli uyum” yaklaşımına geçmesine yardımcı olabilir; ancak en iyi sonuç, bu verilerin manuel denetim bulguları ve süreç iyileştirmeleriyle birlikte yönetilmesiyle ortaya çıkar.

Sonuç

Otomatik taramalar, erişilebilirlik yolculuğunda değerli bir araçtır; fakat tek başına WCAG uyumu kanıtı değildir. Uyumun gerçek ölçütü, engelli kullanıcıların kritik görevleri başarıyla tamamlayabilmesi ve bunun denetimle doğrulanabilmesidir. “Tarama temiz” çıktısını bir varış noktası değil, daha kapsamlı bir denetim ve iyileştirme sürecinin başlangıç sinyali olarak konumlandırdığınızda sahte uyum hissi yerine sürdürülebilir erişilebilirliğe yaklaşabilirsiniz.