WCAG uyumu zorunlu mu?

Bu, faaliyet gösterdiğiniz ülkeye, sektöre ve hizmet verdiğiniz pazara göre değişir. Örneğin AB'de Avrupa Erişilebilirlik Yasası birçok dijital hizmeti kapsar. Kesin yükümlülükleriniz için hukuki danışmanlık almanız önerilir.

Otomatik test araçları yeterli mi?

Hayır. Otomatik araçlar kontrast ve eksik etiket gibi sorunları hızla bulur, ancak odak sırası, anlamlı alt metin ve akışın ekran okuyucuyla anlaşılırlığı gibi konular manuel test gerektirir.

Mevcut bir siteyi erişilebilir hale getirmek mümkün mü?

Evet. Genellikle önce bir denetimle sorunlar listelenir, ardından etkisi en yüksek olanlardan başlanarak düzeltilir. Tasarım sistemi ve ortak bileşenler üzerinde yapılan düzeltmeler, birçok sayfayı aynı anda iyileştirir.

WCAG Erişilebilirlik Rehberi: Web ve Mobil İçin Temeller

Erişilebilirlik; görme, işitme, motor ya da bilişsel farklılıkları olan kişilerin de dijital ürünleri rahatça kullanabilmesi demektir. Bu WCAG erişilebilirlik rehberinde web sitelerinde ve mobil uygulamalarda dikkat edilmesi gereken temel kuralları, tasarım ve geliştirme tarafındaki pratik karşılıklarını ve test yöntemlerini bir araya getirdik.

WCAG nedir?

WCAG (Web Content Accessibility Guidelines), W3C bünyesinde geliştirilen ve web içeriğinin erişilebilirliği için uluslararası referans kabul edilen yönergelerdir. Güncel sürüm WCAG 2.2'dir ve 2023'te yayımlanmıştır. Yönergeler web için yazılmış olsa da ilkeleri mobil uygulamalara da büyük ölçüde uygulanabilir.

WCAG, başarı kriterlerini üç seviyede gruplar:

Seviye	Anlamı	Pratikte
A	Temel gereklilikler	Karşılanmazsa bazı kullanıcılar içeriğe hiç erişemez
AA	Standart hedef	Yasal düzenlemelerin ve kurumsal politikaların çoğunlukla referans aldığı seviye
AAA	En yüksek seviye	Tüm içerik için her zaman ulaşılabilir değildir, belirli alanlarda hedeflenir

Çoğu proje için gerçekçi hedef WCAG 2.2 AA uyumudur. Avrupa Birliği'nde Avrupa Erişilebilirlik Yasası (European Accessibility Act) Haziran 2025 itibarıyla birçok dijital ürün ve hizmet için uygulanmaya başladı; AB pazarına hizmet veren şirketler için erişilebilirlik artık yalnızca iyi bir uygulama değil, yasal bir konu da olabilir. Kendi durumunuz için hukuki danışmanlık almanızı öneririz.

Dört temel ilke: POUR

WCAG'deki tüm kriterler dört ilke altında toplanır:

Algılanabilir (Perceivable): Bilgi, kullanıcının algılayabileceği şekilde sunulmalı. Görsellere alternatif metin, videolara altyazı bu ilkenin örnekleridir.
Kullanılabilir (Operable): Arayüz; fare, klavye, dokunma ya da yardımcı teknolojilerle kullanılabilmeli.
Anlaşılabilir (Understandable): İçerik ve davranış öngörülebilir, hata mesajları anlaşılır olmalı.
Sağlam (Robust): İçerik, ekran okuyucular dahil farklı teknolojilerce doğru yorumlanabilmeli.

Tasarım aşamasında erişilebilirlik

Erişilebilirlik sorunlarının önemli bir kısmı tasarım dosyasında başlar ve orada çözülmesi en ucuzudur. UI/UX tasarım sürecinde kontrol ettiğimiz başlıca noktalar:

Renk kontrastı

Normal boyutlu metin için arka planla en az 4.5:1 kontrast oranı (AA).
Büyük metin için en az 3:1.
Buton kenarlığı, form alanı çerçevesi ve ikon gibi anlam taşıyan arayüz öğeleri için en az 3:1.

Sadece renge dayanmamak

Hatalı bir form alanını yalnızca kırmızı çerçeveyle belirtmek, renk körlüğü olan kullanıcılar için yeterli değildir. Renge ek olarak ikon ya da açıklayıcı metin kullanın.

Dokunma ve tıklama alanları

WCAG 2.2, AA seviyesinde hedeflerin en az 24x24 CSS piksel olmasını (bazı istisnalarla) ister. Platform rehberleri daha cömerttir: Apple en az 44x44 pt, Google Material Design ise 48x48 dp önerir. Mobil tasarımda bu platform değerlerini hedeflemek güvenli bir yaklaşımdır.

Odak ve etkileşim durumları

Tasarım dosyasında yalnızca varsayılan ve basılı durumlar değil, klavye odağı durumu da çizilmelidir. Odak göstergesi tasarımda tanımlanmadığında geliştirici ya tarayıcı varsayılanını bırakır ya da görsel olarak rahatsız edici bulup tamamen kaldırır. Tasarım sistemine her etkileşimli bileşen için belirgin bir odak stili eklemek bu sorunu kökünden çözer. Benzer şekilde hata, uyarı ve başarı mesajlarının hangi metinle ve nerede gösterileceği de tasarım aşamasında netleşmelidir.

Tipografi ve metin boyutu

Kullanıcılar sistem ayarlarından yazı boyutunu büyüttüğünde arayüz bozulmamalıdır. iOS'ta Dynamic Type, Android'de ölçeklenebilir birimler (sp) ve web'de rem gibi göreli birimler bu esnekliği sağlar.

Web geliştirmede erişilebilirlik

Tasarım doğru olsa bile kodlama sırasında erişilebilirlik kaybolabilir. Web tarafında öncelikli konular:

Semantik HTML: Buton için button, bağlantı için a, başlık hiyerarşisi için h2, h3 gibi doğru etiketleri kullanmak, yardımcı teknolojilerin sayfayı anlamasının temelidir.
Klavye erişimi: Tüm etkileşimli öğelere Tab tuşuyla ulaşılabilmeli ve odak sırası mantıklı olmalı.
Görünür odak göstergesi: Odaklanan öğe net şekilde belli olmalı; tarayıcının odak çerçevesini tamamen kaldırmak sık yapılan bir hatadır.
Alternatif metin: Anlam taşıyan görsellere açıklayıcı alt metin, dekoratif görsellere boş alt verilmeli.
Form etiketleri: Her form alanı görünür bir etiketle ilişkilendirilmeli; hata mesajları ekran okuyucuya iletilmeli.
ARIA'yı ölçülü kullanmak: ARIA, semantik HTML'in yetmediği durumlar içindir; yanlış kullanılan ARIA hiç kullanılmamasından daha fazla sorun çıkarabilir.

Modern çatılarda, örneğin Next.js ile geliştirdiğimiz web yazılım projelerinde, bu kuralları bileşen seviyesinde çözerek tüm sayfaların otomatik olarak doğru davranmasını hedefliyoruz.

Mobil uygulamalarda erişilebilirlik

iOS ve Android, güçlü yerleşik erişilebilirlik araçları sunar; uygulamanın bunlarla uyumlu olması gerekir:

Ekran okuyucular: iOS'ta VoiceOver, Android'de TalkBack. Her etkileşimli öğenin anlamlı bir erişilebilirlik etiketi olmalı; yalnızca ikondan oluşan butonlar özellikle kontrol edilmeli.
Dinamik yazı boyutu: Büyük yazı ayarlarında metinlerin kesilmediği, düzenin kaydırılabilir kaldığı test edilmeli.
Hareketi azaltma: Kullanıcı sistemde hareketi azaltmayı seçtiyse, büyük animasyonlar sadeleştirilmeli.
Jest alternatifleri: Kaydırarak silme gibi jestlerin bir buton ya da menü karşılığı olmalı.

SwiftUI ve Jetpack Compose, erişilebilirlik özelliklerini bileşen seviyesinde tanımlamayı kolaylaştırır. Mobil uygulama geliştirme projelerimizde bu kontrolleri geliştirme sürecine dahil ediyoruz.

Erişilebilirlik nasıl test edilir?

Otomatik araçlar sorunların bir kısmını yakalar, ancak tamamını yakalayamaz. Etkili bir test süreci şu katmanları birleştirir:

Otomatik tarama: Lighthouse, axe gibi araçlarla kontrast, eksik etiket ve alt metin sorunlarını bulmak.
Klavyeyle gezinme: Fareyi bırakıp tüm sayfayı yalnızca klavyeyle kullanmayı denemek.
Ekran okuyucu testi: VoiceOver, TalkBack ya da NVDA ile temel akışları baştan sona tamamlamak.
Yazı boyutu ve yakınlaştırma: Sistem yazı boyutunu büyütmek ve web'de sayfayı yüzde 200 yakınlaştırmak.
Gerçek kullanıcılar: Mümkünse yardımcı teknoloji kullanan kişilerle test yapmak.

Erişilebilirliği tek seferlik bir denetim olarak görmek yerine sürekli bir kalite kontrolü haline getirmek en sürdürülebilir yöntemdir. Otomatik kontrolleri sürekli entegrasyon (CI) sürecine eklemek, yeni bir sürümde kontrast ya da etiket hatası oluştuğunda bunu yayından önce yakalar. Yeni bir özellik tamamlandığında klavye ve ekran okuyucu ile kısa bir kontrol yapmayı "bitti" tanımının parçası yapmak da ekibe güçlü bir alışkanlık kazandırır.

Sonuç

WCAG erişilebilirlik uyumu, sonradan eklenen bir özellik değil, tasarım ve geliştirmenin baştan bir parçası olduğunda en az maliyetle sağlanır. Yeterli kontrast, doğru semantik, klavye ve ekran okuyucu desteği ile esnek yazı boyutları; yalnızca engelli kullanıcılar için değil, herkes için daha iyi bir ürün demektir.

BernSoftware olarak web ve mobil projelerimizde erişilebilirliği tasarım sisteminden koda kadar sürecin içine yerleştiriyoruz. Mevcut ürününüzün erişilebilirlik değerlendirmesi ya da yeni bir proje için bizimle iletişime geçin.