WCAG: Web Content Accessibility Guidelines (Web İçeriğinin Erişilebilirlik Kılavuzu) Anlamak: Teknik Ekipler İçin En Kritik 4 Kılavuz İlke

Birçok teknik ekip için WCAG, uzun bir PDF’ten ibaret.

Açılıp bakılan, sonra kapatılan, gerektiğinde “kontrol edilen” bir belge.

Oysa WCAG bir kural listesi değil, bir tasarım ve geliştirme rehberidir.

Bu fark anlaşılmadığında şu olur:

Kod “uyumlu” görünür, ama deneyim çalışmaz.

Testler geçer, kullanıcı takılır.

Checklist tamamlanır, erişilebilirlik yine kırılır.

Bu yazı, WCAG’i bir belge olarak değil, bir deneyim yaklaşımı olarak nasıl okumak gerektiğini anlatmak için var.

WCAG neyi tarif eder, neyi etmez?

WCAG, teknik ekipler için çoğu zaman yanlış bir beklentiyle okunur. Sanki her kriter, birebir uygulanacak bir kod kuralıymış gibi.

Oysa WCAG:

• Bir bileşenin nasıl yazılacağını söylemez
• Hangi framework’ün kullanılacağını önermez
• Tasarım sistemini tanımlamaz

Bunun yerine WCAG, şunu tarif eder: Bir kullanıcı bir dijital üründe deneyimi nasıl yaşamalıdır.

Yani WCAG’in dili, kod dili değil; davranış dilidir.

Örneğin WCAG, “butona şu attribute’u ekle” demez.

Şunu der: Kullanıcı, o butonun ne işe yaradığını ve bastığında ne olacağını anlayabilmelidir.

Bu fark kritik bir zihniyet değişimi yaratır.

Teknik ekipler kriterleri “bunu koda nasıl eklerim?” diye okuduğunda, uyumlu ama anlamsız arayüzler ortaya çıkar.

Ama kriterler “kullanıcı burada ne yaşamalı?” sorusuyla okunduğunda, erişilebilirlik doğal olarak tasarıma ve koda yerleşir.

Bu yüzden WCAG, bir checklist değil, teknik kararları yönlendiren bir çerçevedir.

Ve doğru okunduğunda, yalnızca erişilebilirliği değil, ürünün genel kalitesini de yükseltir.

WCAG’i checklist gibi uygulamak neden başarısız olur?

Çünkü checklist, bağlamı görmez.

Örneğin:

• aria-label eklenir, ama yanlış yerde kullanılır
• Odak vardır, ama mantıksız ilerler
• Renk kontrastı sağlanır, ama bilgi sadece renk ile anlaşılır
• Hata mesajı vardır, ama ekran okuyucu kullanıcıya seslendiremez

Bu durumda kod uyumludur. Ama deneyim değildir.

WCAG’i doğru uygulamak için, kriterleri değil, ilkeleri anlamak gerekir.

WCAG’i gerçekten anlamak: Teknik ekipler için 4 temel ilke

1️⃣ Algılanabilirlik (Perceivable)

Bilgi, herkes için gerçekten var mı?

Ekranda görünen bir içerik, yardımcı teknolojiler için de var olmalıdır.

Bu, yalnızca alt text eklemekten ibaret değildir; içeriğin anlamlı bir yapıyla sunulması anlamına gelir.

Teknik olarak bu ilke şunları kapsar:

• Doğru semantik HTML (div yerine button, span yerine label vb.)
• Mantıklı başlık hiyerarşisi (h1–h6)
• Alternatif metinlerin bağlama uygun yazılması
• Dinamik içeriklerin (toast, modal, validation mesajı) screen reader’a bildirilmesi

Algılanabilirlik bozulduğunda, kullanıcı içeriği “kaçırmaz”. İçeriğin varlığından hiç haberdar olmaz. Bu, erişilebilirliğin en görünmez ama en kritik kırılma noktasıdır.

2️⃣ Kullanılabilirlik (Operable)

Deneyim gerçekten kontrol edilebilir mi?

Bir kullanıcı içeriği algılayabilir ama kontrol edemiyorsa, deneyim tamamlanamaz.

Bu ilke, etkileşimin mühendislik kalitesini belirler.

Burada teknik ekiplerin en çok etki ettiği alanlar:

• Klavye ile tam gezinme (hiçbir yerde takılmayan akış)
• Odak sırasının görsel ve mantıksal olarak tutarlı ilerlemesi
• Focus göstergesinin görünür ve anlamlı olması
• Zaman sınırlı işlemlerde kullanıcıya kontrol verilmesi
• Mobilde dokunma alanlarının ergonomik boyutta olması

Kullanılabilirlik bozulduğunda kullanıcı “nerede kaldığını” kaybeder. Ve bu, screen reader testlerinde en sık karşılaşılan kopma anıdır.

3️⃣ Anlaşılabilirlik (Understandable)

Kullanıcı ne olduğunu, ne olacağını anlayabiliyor mu?

Bir arayüz teknik olarak çalışabilir, ama davranışları öngörülemezse kullanıcıyı yorar ve güvensiz hissettirir.

Bu ilke şunları kapsar:

• Bileşenlerin her zaman aynı davranışı göstermesi
• Bir aksiyon sonrası ne olacağının tahmin edilebilir olması
• Hata mesajlarının açık, yönlendirici ve doğru yerde okunması
• Form alanlarının kullanıcıyı düzeltmeye yönlendirmesi
• Beklenmedik sayfa değişimlerinden kaçınılması

Anlaşılabilirlik, erişilebilirliğin psikolojik boyutudur.

Kullanıcıyı rahatlatır, güven verir ve süreci tamamlamasını sağlar.

4️⃣ Sağlamlık (Robust)

Deneyim her ortamda tutarlı şekilde çalışıyor mu?

Bir arayüz yalnızca tek tarayıcıda, tek cihazda ya da tek ekran okuyucuda çalışıyorsa, sağlam değildir.  Bu ilke, erişilebilirliğin sürdürülebilirliğini güvence altına alır.

Teknik karşılığı:

• Standartlara uygun, temiz HTML yapısı
• ARIA’nın doğru ve minimal kullanımı
• State değişimlerinin (açık/kapalı, seçili/seçili değil) doğru bildirilmesi
• NVDA, JAWS, VoiceOver, TalkBack gibi farklı yardımcı teknolojilerle tutarlılık
• Farklı tarayıcı ve cihazlarda aynı davranışın korunması

Sağlamlık, “bugün çalışan” değil, yarın da çalışacak erişilebilirlik demektir.

Bu dört ilke birlikte çalıştığında, WCAG bir yük olmaktan çıkar. Teknik ekipler için bir mühendislik standardına dönüşür.

WCAG’i doğru uygulamak, kriterleri ezberlemek değil;  bu dört ilkeyi her teknik kararda refleks haline getirmektir.

Bu ilkeler neden gerçek hayatta kırılıyor?

Çünkü çoğu ekip WCAG’i:

• QA aşamasında kontrol edilen bir liste
• Yayın öncesi yapılan bir zorunluluk
• Proje sonu “temizlik” işi

olarak görüyor.

Oysa WCAG ilkeleri,  tasarım kararında, component yazımında ve review sürecinden başlayarak uygulanmalıdır.

Aksi halde her düzeltme, bir sonraki sprint’te geri bozulur.

Türkiye’de teknik ekiplerin rolü neden kritik?

21 Haziran 2025’te yayımlanan dijital erişilebilirlik genelgesiyle birlikte, 2026 itibarıyla dijital erişilebilirlik Türkiye’de ilk kez bağlayıcı bir yükümlülük haline geliyor.

Bu düzenleme, erişilebilirliği yalnızca bir “iyi niyet” konusu olmaktan çıkarıp,  doğrudan kurumsal sorumluluk ve denetlenebilir bir standart haline getiriyor.

Bu noktada önemli bir kırılma var:  Erişilebilirlik artık yalnızca UX ekiplerinin tasarım kararıyla ya da hukuk ekiplerinin metinleriyle sağlanabilecek bir konu değil.

Genelge, doğrudan şunu soruyor: Bir engelli kullanıcı, bu dijital hizmeti gerçekten kullanabiliyor mu?

Bu sorunun cevabı:

• Tasarımda değil, kodda
• Politikada değil, bileşen davranışında
• Niyette değil, gerçek kullanım senaryosunda

Bu yüzden teknik ekipler ilk kez sürecin merkezine yerleşiyor.

Çünkü denetimler artık yalnızca “kriter var mı?” diye bakmıyor; akış çalışıyor mu, hata doğru iletiliyor mu, kullanıcı yönünü kaybediyor mu gibi soruların cevabını arıyor.

Bu da şu anlama geliyor:

• Yanlış odak sırası, bir tasarım hatası değil, uyumsuzluk riski
• Eksik state bildirimi, küçük bir bug değil, kullanılabilirlik ihlali
• Yanlış ARIA kullanımı, teknik detay değil, denetimde karşılığı olan bir problem

Erişilebilirlik, ilk kez bu kadar net biçimde teknik kaliteyle eşitlenmiş durumda.

Kısacası:  2026’ya giden yolda erişilebilirlik,  “tasarlandı mı?” değil,  “kodda gerçekten çalışıyor mu?” sorusuyla ölçülecek.

Ve bu sorunun cevabı, teknik ekiplerin yazdığı her satır kodda yatıyor.

Doğru yaklaşım: WCAG’i koda değil, sürece yazmak

WCAG uyumu, tek tek kriterlerin sağlanmasıyla değil,

ilkelerin geliştirme sürecine gömülmesiyle mümkün olur.

Bu da:

• Design review’larda erişilebilirlik kontrolü
• Component bazlı erişilebilirlik standartları
• Release sonrası izleme
• Gerçek kullanıcı testleri

ile sağlanır.

BlindLook teknik ekiplerle nasıl çalışır?

BlindLook, WCAG’i teknik ekiplere “ne yapmalısınız” diye anlatmaz.

Neden ve nasıl sorularına birlikte cevap verir.

Bu yüzden:

• Kriterleri bileşen seviyesine indirger
• Geliştiricilerin uygulayabileceği net yönlendirmeler üretir
• Web, iOS ve Android için ayrı teknik yorumlar sunar
• Screen reader testleriyle kodun sahadaki karşılığını doğrular
• İzleme ve denetleme ile erişilebilirliği korur

Teknik ekipler BlindLook ile WCAG’i bir kontrol listesi değil, mühendislik standardı olarak uygular.

Özet: WCAG bir doküman değil, bir zihniyettir

WCAG’i gerçekten anlamak, kriterleri ezberlemek değil, ilkeleri içselleştirmektir.

Algılanabilirlik, kullanılabilirlik, anlaşılabilirlik ve sağlamlık kodun kalitesini doğrudan belirler.

Ve doğru uygulandığında, erişilebilirlik ekstra bir yük değil, daha iyi bir ürünün doğal sonucu haline gelir.

Eğer teknik ekibiniz WCAG’i bir yük değil, bir kalite standardı olarak uygulamak istiyorsa,

BlindLook’un uzman yaklaşımıyla tanışmak doğru bir başlangıç olacaktır.

Buraya tıklayarak bizimle iletişime geçin!