Web Erişilebilirliği (Accessibility) Nedir, Nasıl Sağlanır?

Web erisilebilirligi (accessibility, kisaca a11y), bir web sitesinin engelli kullanicilar dahil herkes tarafindan algilanabilir, calistirilabilir ve anlasilabilir olmasini saglayan tasarim ve gelistirme yaklasimidir. Pratikte bu; gorme engelli bir kullanicinin ekran okuyucuyla sayfayi dinleyebilmesi, motor engelli bir kullanicinin fareye dokunmadan yalnizca klavyeyle her seye ulasabilmesi, dusuk gorusu olan birinin metni yeterli kontrastla okuyabilmesi ve bilissel zorlugu olan birinin hata mesajini anlayabilmesi demektir. Erisilebilirligin olcusu dunya genelinde W3C/WAI'nin yayimladigi WCAG (Web Content Accessibility Guidelines) standardidir; guncel surum 5 Ekim 2023'te resmi W3C Recommendation olan WCAG 2.2'dir ve ayni icerik ISO/IEC 40500:2025 olarak da bir ISO standardidir. Yani erisilebilirlik bir "iyi niyet" konusu degil, olculebilir kriterleri olan teknik bir disiplindir.

Erisilebilirligi cogu marka "engelli kullanicilar icin ek ozellik" sanir; oysa dogru cerceve sudur: erisilebilirlik, herkesin deneyimini iyilestiren bir altyapidir. Tek elle telefon kullanan, parlak guneste ekrani zor goren, gurultulu ortamda videoyu sessiz izleyen, yavas baglantidaki ya da yasi ilerlemis bir kullanici da erisilebilir tasarimdan birebir fayda gorur. Engelliligin daimi olmasi da gerekmez: kirik bir kol gecici, elinde bebek tasiyan birinin tek eli mesgul olmasi durumsal bir engeldir; iyi tasarlanmis bir arayuz bu uc durumu da ayni anda kapsar. Bu yuzden a11y'yi, biz iyi web tasariminin ayrilmaz bir parcasi olarak ele aliyoruz; sonradan eklenen bir "eklenti" degil, UI/UX tasarim surecinin ilk gununden itibaren icine orulen bir ilke olarak.

Web Erisilebilirligi Tam Olarak Neyi Kapsar?

WCAG, erisilebilirligi dort temel ilke (kisaca POUR) uzerine kurar; bu cerceve, "erisilebilir site nedir?" sorusunun en net cevabidir. Bir sayfayi denetlerken her basari kriteri bu dort ilkeden birine baglanir:

• Algilanabilir (Perceivable): Bilgi ve arayuz ogeleri kullanicinin algilayabilecegi bicimde sunulmali. Ornek: her anlamli gorselin alternatif metni (alt text), videolarin altyazisi, ses iceriginin transkripti, yeterli renk kontrasti ve bilginin renge tek basina bagli olmamasi.
• Calistirilabilir (Operable): Arayuz ve gezinme kullanilabilir olmali. Ornek: sitenin tamami yalnizca klavyeyle gezilebilmeli, fareye mahkum olmamali; gorunur bir odak halkasi bulunmali; otomatik kayan/yanip sonen iceriklere kontrol verilmeli; surukleme gerektiren her etkilesimin tek dokunusluk alternatifi olmali.
• Anlasilabilir (Understandable): Icerik ve arayuzun isleyisi anlasilir olmali. Ornek: tutarli gezinme, ongorulebilir davranis, net ve cozum onerili hata mesajlari, sayfanin dilinin (lang="tr") dogru tanimlanmasi.
• Saglam (Robust): Icerik, ekran okuyucu gibi yardimci teknolojiler dahil farkli araclarca guvenilir bicimde yorumlanabilmeli. Ornek: anlamli (semantic) HTML kullanimi, gecerli isaretleme ve ARIA'nin yalnizca gerektiginde, dogru biçimde devreye girmesi.

WCAG'in uc uygunluk seviyesi vardir: A (asgari), AA (yasal ve sektor standardi, gercek hedef) ve AAA (en yuksek; her sayfada tam karsilanmasi beklenmez). Sektorde ve yasal duzenlemelerde hedeflenen seviye neredeyse her zaman AA'dir; pratikte bir projeye "erisilebilir" diyebilmek icin referans cizgi WCAG 2.2 AA'dir. Asagidaki tablo, ayni temel kriterin uc seviyede nasil sertlestigini somutlastiriyor:

WCAG 2.2, bir onceki surum 2.1'e gore 9 yeni basari kriteri ekledi; bunlarin arasinda odak gorunurlugu, surukleme hareketlerine alternatif sunma, minimum dokunmatik hedef boyutu (SC 2.5.8: en az 24x24 CSS pikseli), tutarli yardim, gereksiz tekrar girisin onlenmesi ve erisilebilir kimlik dogrulama gibi modern, mobil caga uygun kriterler bulunur. Ozellikle "erisilebilir kimlik dogrulama" kriteri dikkat ceker: kullaniciyi ezbere bilgi (sifre hatirlama, CAPTCHA bilmecesi cozme) zorunlulugundan kurtaran giris akislari (ornegin sifre yoneticisiyle yapistirmaya izin vermek) artik beklenen iyi pratiktir. WCAG 3.0 ise hala taslak/arastirma asamasindadir; henuz uygulanmasi gereken bir standart degildir, dolayisiyla bugunun referansi 2.2'dir ve bir projede 3.0'a gore plan yapmak erkendir.

Erisilebilirlik Neden Onemli? Bes Somut Gerekce

Erisilebilirlige yatirim yapmanin gerekcesi tek boyutlu degil; etik, yasal, pazar, SEO ve donusum olmak uzere birbirini guclendiren bes ayri eksende karsiligi vardir. Musterilerimizde gordugumuz kadariyla en ikna edici olan, bu gerekcelerin hepsinin ayni yone isaret etmesidir: erisilebilir site, olculebilir bicimde daha iyi bir sitedir. Asagida her gerekceyi ayri ayri aciyoruz.

1. Etik ve esit erisim

En temel gerekce ilkeseldir: web, kamusal bir alandir ve bir kullanicinin gorme, isitme, motor veya bilissel bir engeli olmasi, onu bilgiye veya hizmete erisimden mahrum birakmamalidir. Bir e-ticaret sitesinde alternatif metni olmayan urun gorselleri, ekran okuyucu kullanan gorme engelli bir musteriyi dogrudan satin almadan dislar; etiketsiz bir adres formu, motor engelli bir kullanicinin siparisini tamamlamasini imkansiz kilar. Erisilebilirlik, dijital varliginizi toplumun tamamina acmanin en dogrudan yoludur; bu, marka itibarinin da bir parcasidir ve bir kez "herkes icin tasarlama" refleksi kazanildiginda ekibin tum is kalitesini yukseltir.

2. Yasal zorunluluk: EAA ve KVKK cercevesi

Erisilebilirlik artik bircok pazarda hukuki bir yukumluluktur. Avrupa Erisilebilirlik Yasasi (EAA), 28 Haziran 2025'te yururluge girdi ve 27 AB uye devletinde uygulanmaya basladi. EAA, EN 301 549 teknik standardina ve dolayisiyla WCAG 2.1 AA seviyesine uyumu zorunlu kilar. Ihlal cezalari ulkeye gore degismekle birlikte 100.000 EUR'a veya yillik cironun %4'une kadar cikabilir; piyasada olan eski hizmetler icin gecis suresi 28 Haziran 2030'a uzatilmistir, yani "eski sistemim muaf" varsayimi belirli bir takvime baglidir.

Burada Turkiye icin kritik bir nokta var: EAA, yalnizca AB merkezli sirketleri degil, AB'ye urun veya hizmet satan firmalari da kapsayabilir. E-ticaret, bankacilik, e-kitap, ulasim gibi alanlarda AB pazarina satis yapan bir Turk firmasi da bu kapsama girebilir; ornegin Avrupa'ya satis yapan bir Shopify magazasinin odeme ve katalog akisinin AA seviyesinde olmasi beklenir. Turkiye'de ozel sektor icin EAA kadar kapsamli ve sert genel bir erisilebilirlik yasasi henuz ayni duzeyde degildir (kamu/e-Devlet siteleri icin duzenlemeler mevcuttur), ancak AB'ye satis yapan her firma icin erisilebilirlik artik bir uyum maddesidir. Buna ek olarak KVKK (6698) cercevesinde aydinlatma metinlerinin, cerez bandinin ve onay sureclerinin de herkesce okunabilir ve anlasilabilir olmasi, erisilebilirlikle dogrudan kesisir: kontrasti dusuk ya da klavyeyle kapatilamayan bir cerez bandi hem erisilebilirlik hem KVKK acisindan zayif bir noktadir.

3. Pazar genislemesi: goz ardi edilen kullanici kitlesi

Engelli kullanicilar, kucumsenecek bir azinlik degil, ciddi bir pazar payidir. Bunun uzerine, erisilebilir tasarimin sagladigi kolayliklar (buyuk ve okunabilir dokunmatik hedefler, net hiyerarsi, basit dil) yasli kullanicilari, dusuk teknik okuryazarligi olanlari ve gecici/durumsal engeli olanlari (kirik kol, parlak isik, gurultu, zayif sebeke) da kapsar. Mobil-oncelikli tasarimda onerdigimiz en az 44-48px dokunmatik hedef boyutu hem WCAG 2.2 SC 2.5.8 kriterini karsilar hem de Fitts Yasasi geregi herkesin tiklama hizini artirir. Mobil trafigin kuresel olarak yaklasik %60'a ulastigi (2026; kaynaga gore degisebilir) ve Turkiye gibi pazarlarda %80'e ciktigi dusunulurse, kucuk ekranda zor dokunulan bir buton yalnizca engelli kullaniciyi degil, kitlenin cogunlugunu yorar. Erisilebilirligi gormezden gelen bir site, bilincli olarak musteri kitlesinin bir bolumunu disarida birakir.

4. SEO faydasi: erisilebilirlik ile aramada gorunurluk ortusur

Erisilebilirlik icin yaptiginiz islerin buyuk bolumu, dogrudan SEO performansini da yukseltir; cunku Google'in botu da, ekran okuyucu gibi, sayfayi "gormeden" anlamlandirmaya calisir. Anlamli HTML yapisi, dogru baslik hiyerarsisi (sayfada tek h1, ardindan mantikli h2-h3 duzeni), gorsellerdeki alt metinler, aciklayici baglanti metinleri ve sayfa dilinin tanimlanmasi hem yardimci teknolojilerin hem arama motorlarinin icerigi dogru yorumlamasini saglar. Bos baglantilar ("buraya tiklayin" yerine aciklayici metin), etiketli formlar ve net yapi, hem erisilebilirlik denetiminden gecer hem de arama gorunurlugunu besler. Ayrica WCAG'in altyazi ve transkript gereksinimleri sayfaya tarananabilir metin ekleyerek icerigi zenginlestirir. Bu ortusme tesaduf degildir; ikisi de ayni temel iyi pratiklere dayanir. Bu konuyu derinlestirmek icin sayfa ici (on-page) SEO rehberimize ve sitenizin teknik saglik durumunu olcmek icin GEO denetim aracimiza goz atabilirsiniz.

5. UX ve donusum: erisilebilir site daha cok donusturur

Erisilebilirligin belki de en az konusulan ama en karli boyutu budur: erisilebilir bir site, herkes icin daha kullanilabilir bir sitedir ve kullanilabilirlik dogrudan donusume yansir. Yeterli kontrast (WCAG AA icin govde metninde en az 4.5:1, buyuk metinde 3:1), net odak halkalari, klavyeyle gezilebilir formlar, acik hata mesajlari ve tutarli arayuz; engelli olsun olmasin her kullanicinin gorevini daha hizli tamamlamasini saglar. Erisilebilirlik kriterleriyle Core Web Vitals da kesisir: ornegin her gorsele ve iframe'e acik genislik/yukseklik (ya da aspect-ratio) vermek hem beklenmedik duzen kaymalarini (CLS ≤ 0,1 hedefi) onler hem de gorsel kararliligi artirir; font yuklemesini dogru yonetmek hem metni erken gosterir hem LCP'yi iyilestirir. Bir odeme formunda etiketsiz alanlari duzeltmek, gorme engelli kullanici kadar acelesi olan herkesin formu dogru doldurmasina yardimci olur ve sepet terkini dusurur. Yani erisilebilirlik, donusum odakli tasarimin bir alt kumesi degil, onu guclendiren bir temeldir.

En Sik Yapilan Erisilebilirlik Hatalari

WebAIM'in her yil yayimladigi milyon sayfalik tarama raporu, web genelinde tespit edilen erisilebilirlik hatalarinin ezici cogunlugunun ayni birkac kaliptan olustugunu yillardir tutarli bicimde gosteriyor. Iyi haber su: bu hatalarin neredeyse tamami otomatik araclarla yakalanabilen ve dusuk maliyetle kapatilabilen turden. Musteri sitelerinde de en sik karsilastigimiz hatalar tam olarak bunlardir:

Son satir Turkiye baglaminda ozellikle kritik: lang ozniteliginin tanimlanmamasi yalnizca ekran okuyucunun yanlis telaffuz etmesine degil, Turkce karakterlerin (c, g, i, I, o, s, u) ve ozellikle noktali/noktasiz I ayriminin yanlis islenmesine yol acabilir. Sayfanin UTF-8 olmasi, secilen yazi tipinin Turkce karakter setini eksiksiz desteklemesi ve lang="tr" tanimi bir arada calismalidir; aksi halde "ISTANBUL/istanbul" gibi buyuk-kucuk donusumleri bozulur.

Dikkat cekici olan su: bu hatalarin neredeyse tamami, tasarim asamasinda akilda tutuldugunda neredeyse sifir ek maliyetle onlenir; sonradan tamir edildiginde ise hem pahali hem yamali olur. Bir butona aria-label eklemek tasarim sirasinda saniyelik bir istir; canliya alinmis, binlerce sayfali bir sitede ayni eksigi toplu duzeltmek haftalar surebilir. Bu yuzden erisilebilirligi, tipki web guvenligi gibi, projenin basinda konusulmasi gereken bir kalite boyutu olarak ele aliyoruz; sona birakilan bir "denetim maddesi" olarak degil. Ayni mantik bir site yenileme (redesign) projesinde de gecerlidir: yeni tasarim, eski erisilebilirlik borclarini temizlemek icin en dogru andir.

Sitenizin erisilebilirlik, performans ve donusum acisindan nerede durdugunu gormek isterseniz, ucretsiz analiz uzerinden bir degerlendirme talep edebilir; tasarim ve gelistirme tarafinda UI/UX tasarim hizmetimizle erisilebilirligi gun-1'den itibaren projenize orebilirsiniz. Ilerleyen bolumlerde bu ilkeleri pratik adimlara, kod duzeyinde uygulamalara (semantic HTML, klavye gezinmesi, ARIA, kontrast) ve test araclarina donusturecegiz.

WCAG 2.2, Erişilebilirlik Seviyeleri ve Avrupa Erişilebilirlik Yasası: Tam Çerçeve

Kısa cevap: Web erişilebilirliğinin küresel teknik standardı WCAG (Web Content Accessibility Guidelines)'dir; güncel sürümü WCAG 2.2, 5 Ekim 2023'te resmî "W3C Recommendation" (web standardı) oldu ve Aralık 2024'te güncellendi. Üç uygunluk seviyesi vardır: A (asgari), AA (yasal/sektör standardı ve gerçek hedef), AAA (en yüksek). Tüm kriterler dört temel ilkeye dayanır: Algılanabilir, İşletilebilir, Anlaşılır, Sağlam (İngilizce baş harfleriyle POUR). Bunların pratik önemi 28 Haziran 2025'te keskinleşti: Avrupa Erişilebilirlik Yasası (EAA) yürürlüğe girdi ve AB'ye ürün/hizmet satan firmalar için WCAG 2.1 AA seviyesini fiilen zorunlu hale getirdi. Aşağıda bu çerçeveyi tarih, seviye ve yasa düzeyinde somutlaştırıyoruz; uygulama tarafını web erişilebilirliği rehberinin diğer bölümlerinde ele alıyoruz.

WCAG nedir ve sürüm geçmişi nasıl ilerledi?

WCAG, W3C bünyesindeki WAI (Web Accessibility Initiative) tarafından yayımlanan, web içeriğinin engelli kullanıcılar için nasıl erişilebilir hale getirileceğini tanımlayan standarttır. Müşterilerimizde sıkça gördüğümüz bir kafa karışıklığı şudur: WCAG bir "öneri listesi" değil, ölçülebilir başarı kriterleri (success criteria) bütünüdür ve denetlenebilir. Her başarı kriteri, doğru ya da yanlış olarak işaretlenebilen test edilebilir bir ifadedir; bu yüzden iki farklı denetçi aynı sayfayı büyük ölçüde aynı sonuçla puanlayabilir. Standardın katmanlı yapısı da bunu destekler: en üstte 4 ilke (POUR), altında tematik kılavuz ilkeler (guidelines), en altta da gerçek uyum kararının verildiği başarı kriterleri bulunur. Uyum iddiası (conformance claim) yaparken sayfa, seçtiğiniz seviyedeki tüm kriterleri karşılamak zorundadır; tek bir kriteri ihlal eden sayfa o seviyeye "uyumlu" sayılmaz. Sürüm tarihçesi net:

• WCAG 2.0 — 2008. Standardın temel iskeleti ve POUR ilkeleri burada tanımlandı; aynı zamanda 2012'de ISO/IEC 40500 olarak ilk kez uluslararası ISO standardı statüsü kazandı.
• WCAG 2.1 — 2018. Mobil erişilebilirlik, az gören kullanıcılar ve bilişsel/öğrenme güçlükleri için yeni kriterler ekledi (örneğin reflow, metin aralığı, yön/orientation, dokunma hedefleri). EAA'nın atıf yaptığı seviye budur.
• WCAG 2.2 — 5 Ekim 2023'te resmî W3C Recommendation oldu, Aralık 2024'te güncellendi. 2.1'e göre 9 yeni başarı kriteri getirdi. Ayrıca ISO/IEC 40500:2025 olarak uluslararası ISO standardı statüsü taşır.

Bir önemli geriye dönük uyum notu: WCAG sürümleri "geriye uyumludur" mantığıyla ilerler, yani WCAG 2.2 AA'yı karşılayan bir sayfa, çok büyük oranda WCAG 2.1 AA'yı da karşılar. Tek istisna, 2.2'de kaldırılan tek kriter olan 4.1.1 Parsing'tir; bu kriter modern tarayıcılar artık bozuk işaretlemeyi tutarlı biçimde işlediği için geçersiz sayılmıştır. Pratik sonucu şudur: hedefinizi en güncel sürüm olan 2.2'ye göre belirlerseniz, EAA'nın istediği 2.1 AA'yı da otomatik olarak kapsamış olursunuz; iki ayrı standardı paralel yönetmenize gerek kalmaz.

Bir sonraki büyük adım olan WCAG 3.0 ise henüz taslak/araştırma aşamasındadır; 2026 Haziran itibarıyla resmî bir standart değildir ve bugün üzerine uyum planı kuracağınız sürüm değildir. WCAG 3.0, "doğru/yanlış" ikili modeli yerine puana dayalı esnek bir değerlendirme modeli önermektedir; ancak takvimi belirsiz olduğundan bugün için yalnızca yön gösterici bir araştırmadır. Pratik tavsiyemiz: hedefinizi WCAG 2.2 AA olarak belirleyin; bu hem yasal beklentiyi (EAA'nın atıf yaptığı 2.1 AA'yı zaten kapsar) hem de en güncel teknik iyi uygulamayı karşılar. Erişilebilirliğin neden bir "ekstra" değil altyapı kararı olduğunu, iyi web tasarımının ne olması gerektiğini anlattığımız yazıda da vurguluyoruz.

POUR: WCAG'ın dört temel ilkesi nedir?

Tüm başarı kriterleri dört ilke altında toplanır. Bu ilkeleri tek tek anlamak, tek tek kriterleri ezberlemekten çok daha kullanışlıdır çünkü yeni bir tasarım kararıyla karşılaştığınızda "bu hangi ilkeyi zedeliyor?" diye sorabilirsiniz:

• Algılanabilir (Perceivable): İçerik, kullanıcının algılayabileceği bir biçimde sunulmalı. Pratikte: her görsele anlamlı alt metni, videoya altyazı, ses içeriğine metin alternatifi, ve yeterli renk kontrastı. WCAG AA gövde metni için en az 4.5:1, büyük metin için 3:1 kontrast oranı ister; renk asla tek başına bilgi taşıyamaz (renk körlüğü). Örneğin form hatasını yalnızca kırmızıyla işaretlemek yetmez; metin ve ikonla da belirtmek gerekir.
• İşletilebilir (Operable): Arayüz ve gezinme herkes tarafından çalıştırılabilmeli. Pratikte: klavyeyle tam gezilebilirlik (fare olmadan), görünür odak halkası, yeterli dokunmatik hedef boyutu, "içeriğe atla" (skip link) bağlantısı, klavye tuzağının olmaması, ve kullanıcıya zaman baskısı dayatmamak. Bir özellik yalnızca fareyle ya da yalnızca dokunmayla çalışıyorsa bu ilke zaten ihlal edilmiştir.
• Anlaşılır (Understandable): İçerik ve arayüz davranışı öngörülebilir olmalı. Pratikte: sayfanın lang tanımı, tutarlı gezinme, açık form etiketleri ve çözüm önerili hata mesajları. Bir alana odaklanmanın beklenmedik biçimde sayfayı değiştirmesi (örneğin formu otomatik göndermesi) bu ilkeyi bozar.
• Sağlam (Robust): İçerik, ekran okuyucular dahil farklı yardımcı teknolojilerle güvenilir biçimde yorumlanabilmeli. Pratikte: anlamlı (semantic) HTML kullanmak (button, nav, main, label) ve ARIA'yı yalnızca gerçekten gerektiğinde devreye almak. WAI-ARIA'nın birinci kuralı zaten "yapabiliyorsan ARIA kullanma, yerel HTML öğesini kullan"dır; çünkü yanlış kullanılan ARIA, erişilebilirliği iyileştirmek yerine bozar.

Bu dört ilke, görsel hiyerarşi ve tutarlılık gibi temel UI/UX tasarım ilkeleriyle birebir örtüşür; erişilebilir bir tasarım neredeyse her zaman daha iyi bir kullanıcı deneyimi de üretir. WebAIM Million yıllık raporunda tespit edilen hataların büyük çoğunluğu da tam olarak bu ilkelerin ihlalidir: düşük metin kontrastı, alt-metni olmayan görseller, boş bağlantılar, etiketsiz form alanları, boş butonlar ve eksik dil tanımı. Dikkat çekici olan, bu hataların neredeyse tamamının "Algılanabilir" ve "Anlaşılır" ilkelerine ait, ucuz ve hızlı düzeltilebilir kalemler olmasıdır; yani en yaygın erişilebilirlik sorunları aslında en kolay çözülenlerdir.

WCAG 2.2 hangi 9 yeni kriteri getirdi?

WCAG 2.2'nin eklediği 9 başarı kriteri, özellikle mobil dokunmatik kullanım, az gören ve bilişsel zorluk yaşayan kullanıcılar için somut iyileştirmeler içerir. Tasarım ve geliştirme tarafında en sık karşımıza çıkanları, seviyeleriyle birlikte bir tabloda topladık:

Buradaki minimum hedef boyutu (SC 2.5.8) kriteri, mobil-öncelikli çalışma biçiminde özellikle kritiktir; çünkü dar ekranda küçük ve birbirine yapışık butonlar hem erişilebilirlik hem dönüşüm kaybı yaratır. Bu konuyu mobil uyumlu responsive tasarım rehberinde dokunmatik hedef boyutu ve tek elle erişim başlıklarıyla daha ayrıntılı işliyoruz. Erişilebilir kimlik doğrulama kriteri ise pratikte sıkça gözden kaçar: kullanıcıdan bir görseli ezberden çözmesini isteyen veya şifre yapıştırmayı engelleyen giriş ekranları, görünüşte "güvenlik" amacı taşısa da artık WCAG 2.2 AA'yı ihlal eder. Bu da erişilebilirlik ile web güvenliği tasarımının birlikte düşünülmesi gereken iki konu olduğunu gösterir; güvenliği kullanıcıyı dışlamadan kurmak gerekir.

A, AA, AAA seviyeleri arasındaki fark nedir?

WCAG'ın her başarı kriteri bir uygunluk seviyesine atanır ve bir seviyeye "uymak" o seviyedeki tüm kriterleri (ve alt seviyelerini) karşılamak demektir. Yani AA uyumu için hem tüm A hem de tüm AA kriterleri sağlanmalıdır; AAA için üçü de. Üç seviye şu mantıkla ayrışır:

Önemli bir nüans: AAA, "daha iyi" olduğu için körü körüne hedeflenecek bir seviye değildir. W3C bile her sayfada tam AAA uyumunun beklenemeyeceğini açıkça belirtir. Somut farkları görmek için iki kriteri karşılaştıralım:

Görüldüğü gibi 7:1 kontrast bazı marka renk paletleriyle tüm sayfa için sağlanamayabilir; markanın ana mavisi açık bir zeminde 4.5:1'i geçse bile 7:1'i tutturamayabilir. Bu yüzden doğru strateji şudur: tüm site için AA'yı garanti altına alın, kritik akışlarda (giriş, ödeme, çok adımlı form) mümkün olduğunca AAA kriterlerine yaklaşın. Bu mantık, dönüşüm-kritik sayfaları ayrı optimize etme yaklaşımıyla da örtüşür; dönüşüm odaklı landing page rehberinde sürtünmeyi azaltan form ve net CTA prensiplerini bu çerçevede ele alıyoruz. Uygulamada AAA'yı hedefe değil "kalite tavanı" olarak görmek daha sağlıklıdır: her sayfayı AAA'ya zorlamak yerine, kullanıcının en çok zorlandığı ve hata maliyetinin en yüksek olduğu adımları AAA'ya yaklaştırmak en iyi getiriyi verir.

Avrupa Erişilebilirlik Yasası (EAA) neyi, kimi zorunlu kılıyor?

Erişilebilirliği 2026 itibarıyla "iyi olur" seviyesinden "yapılması zorunlu" seviyesine taşıyan kritik gelişme EAA'dır. Net tarih ve kapsam şöyle:

• Yürürlük tarihi: EAA, 28 Haziran 2025'te yürürlüğe girdi ve 27 AB üye devletinde uygulama başladı. Her üye devlet yasayı kendi ulusal mevzuatına aktardığı için yaptırım ve denetim detayları ülkeden ülkeye farklılaşır.
• Teknik referans: Uyum, EN 301 549 teknik standardına ve dolayısıyla WCAG 2.1 AA seviyesine bağlandı. Yani yasa "erişilebilir olun" demekle kalmıyor, ölçülebilir teknik eşiği WCAG üzerinden tanımlıyor. EN 301 549 yalnızca web'i değil, mobil uygulamaları, dokümanları ve donanım arayüzlerini de kapsayan daha geniş bir Avrupa standardıdır; web içeriği için merkezine WCAG'ı alır.
• Kapsam: E-ticaret, bankacılık ve finansal hizmetler, e-kitaplar, ulaşım/biletleme, elektronik haberleşme, ve tüketiciye yönelik dijital hizmetler açıkça hedeflenir.
• Mikro işletme istisnası: Hizmet sağlayan çok küçük işletmeler (genel olarak 10'dan az çalışan ve belirli ciro eşiğinin altındakiler) hizmetler bakımından muafiyetten yararlanabilir; ancak ürün üreticileri için bu muafiyet aynı biçimde geçerli değildir ve istisnanın kapsamı dikkatle değerlendirilmelidir.
• Geçiş süresi: Piyasada hâlihazırda bulunan eski hizmetler için belirli koşullarda 28 Haziran 2030'a kadar uyum geçişi tanınmıştır. Bu, "2030'a kadar hiçbir şey yapmaya gerek yok" anlamına gelmez; 28 Haziran 2025 sonrası sunulan yeni hizmetler zaten uyumlu olmalıdır.
• Yaptırım: İhlal cezaları üye devlete göre değişmekle birlikte, kaynaklarda 100.000 EUR'a kadar veya yıllık cironun %4'üne kadar seviyelere ulaşabilmektedir. Ceza dışında pazar gözetim otoritelerinin ürünü/hizmeti piyasadan çektirme veya düzeltme talep etme yetkisi de vardır.

Türkiye merkezli firmalar için kritik soru şu: "Bu bizi neden ilgilendiriyor?" Cevap, satış coğrafyasında: AB'ye ürün ya da hizmet satan Türk firmaları da EAA kapsamına girebilir. AB'deki müşteriye satış yapan bir e-ticaret sitesi, Avrupa pazarına açılan bir SaaS ürünü veya AB kullanıcısına hizmet veren bir rezervasyon/ödeme akışı, yasanın kapsama alanındadır. Dolayısıyla bu artık yalnızca "Avrupalı şirketlerin sorunu" değildir. AB'ye e-ihracat yapan, Avrupa'da müşterisi olan veya çok dilli bir mağaza işleten markalar için EAA, tıpkı KVKK ve mesafeli satış mevzuatı gibi, baştan planlanması gereken bir uyum kalemidir. Bu konuyu özellikle kurumsal ve sınır ötesi satış yapan firmalar için B2B web sitesi tasarımı ve kurumsal web sitesi yazılarında da güven ve uyum başlığı altında ele alıyoruz.

Türkiye'de erişilebilirlik hukuken nerede duruyor?

Yerel tabloyu olduğu gibi aktaralım, çünkü abartmak da küçümsemek de yanlış olur. 2026 Haziran itibarıyla Türkiye'de kamu siteleri/e-Devlet için erişilebilirlik düzenlemeleri mevcuttur; ancak özel sektör için EAA kadar kapsamlı ve aynı sertlikte genel bir yasa henüz aynı düzeyde değildir. Buna rağmen üç gerçek, erişilebilirliği TR firmaları için de "yapılması gereken" hâline getiriyor:

• İhracat/AB satışı: AB'ye satan firmalar doğrudan EAA'ya tabidir; iç pazardaki yasal boşluk, AB müşterisi karşısında koruma sağlamaz. Tek bir ürünü Avrupa'daki bir tüketiciye satmanız bile sizi kapsama sokabilir.
• SEO ve dönüşüm faydası: Anlamlı HTML, alt metinleri, kontrast, klavye gezilebilirliği ve net etiketleme yalnızca erişilebilirliği değil, arama motoru performansını ve dönüşümü de iyileştirir. Erişilebilir site, çoğu zaman daha hızlı ve daha iyi taranan sitedir; alt metni olan görseller görsel aramada da avantaj sağlar, anlamlı başlık hiyerarşisi ise hem ekran okuyucuya hem arama motoruna yardımcı olur.
• KVKK ve yasal metin tutarlılığı: Erişilebilirlik, kullanıcının aydınlatma metni, çerez tercihi ve onay kutularını gerçekten algılayıp işletebilmesi anlamına da gelir; etiketsiz/erişilemez bir rıza akışı hukuki açıdan da zayıftır. Klavyeyle ulaşılamayan bir çerez bandı veya ekran okuyucunun okuyamadığı bir onay kutusu, "açık rıza alındı" iddiasını fiilen zayıflatır.

Erişilebilirliğin Türkiye'ye özgü bir boyutu daha vardır: dil ve karakter desteği. Sayfanın lang="tr" tanımı, ekran okuyucunun metni doğru telaffuz etmesi ve büyük/küçük harf dönüşümünün doğru yapılması için gereklidir; özellikle Türkçedeki noktalı/noktasız I ayrımı bu nedenle önemlidir. Site mutlaka UTF-8 olmalı ve seçilen yazı tipi Türkçe karakterleri (ç, ğ, ı, İ, ö, ş, ü) eksiksiz desteklemelidir. Bu, hem erişilebilirliğin "Anlaşılır" ilkesine hem de yerel kullanıcı deneyimine doğrudan dokunan, sık atlanan bir ayrıntıdır.

Pratik tavsiyemiz nettir: TR'de bugün doğrudan ceza riski görece düşük olsa bile, yeni kurulan veya yenilenen her projeyi gün 1'den WCAG 2.2 AA hedefiyle kurmak hem 2030 geçiş takvimine hazırlık hem de SEO/dönüşüm yatırımıdır. Var olan bir siteyi elden geçiriyorsanız, erişilebilirlik denetimini sürecin baştan bir parçası yapın; bunu web sitesi yenileme (redesign) rehberinde denetim ve test aşamalarıyla birlikte anlatıyoruz. E-ticaret tarafında AB pazarına bakan markalar için bu konu, web güvenliği ve KVKK uyumuyla birlikte tek bir uyum paketi olarak ele alınmalıdır.

WCAG uyumu nasıl ölçülür ve denetlenir?

Erişilebilirlik bir "tek seferlik kontrol" değil, sürekli bir kalite sürecidir; bu yüzden ölçüm yöntemini baştan kurmak gerekir. Pratikte üç katmanlı bir yaklaşım işe yarar:

• Otomatik tarama: Tarayıcı tabanlı denetçiler (örneğin Lighthouse'un erişilebilirlik bölümü veya açık kaynak axe motoru) kontrast, eksik alt metni, etiketsiz form alanı gibi makinece tespit edilebilen hataları saniyeler içinde yakalar. Ancak bu araçlar WCAG kriterlerinin yalnızca bir bölümünü (genel kabule göre yaklaşık üçte birini) otomatik doğrulayabilir; "100/100 Lighthouse skoru" tam uyum anlamına gelmez.
• Manuel test: Geri kalan kriterler insan değerlendirmesi gerektirir. En temel iki manuel test, sayfayı baştan sona yalnızca klavyeyle (Tab, Shift+Tab, Enter, ok tuşları) gezmek ve bir ekran okuyucuyla (NVDA, JAWS, VoiceOver) dinlemektir. Klavye testi tek başına en yaygın "İşletilebilir" hatalarının çoğunu açığa çıkarır.
• Gerçek kullanıcı testi: Mümkünse yardımcı teknoloji kullanan gerçek kullanıcılarla test, otomatik ve manuel testlerin kaçırdığı bağlamsal sorunları yakalar. Bu, erişilebilirliği bir "uyum kutusu" olmaktan çıkarıp gerçek deneyime bağlar.

Bu üç katmanın hiçbiri tek başına yeterli değildir; doğru yöntem üçünü birleştirmektir. Yeni geliştirme yapan ekipler için en sağlıklı yaklaşım, otomatik erişilebilirlik denetimini sürekli entegrasyon (CI) hattına ekleyerek her dağıtımda regresyonu yakalamak, manuel klavye/ekran okuyucu testini ise yayın öncesi kontrol listesinin sabit bir maddesi yapmaktır. Bu da erişilebilirliği, performans ve güvenlik gibi, bir kalite kapısı olarak sürece gömmek anlamına gelir.

Nereden başlamalı?

Özetle: standardınız WCAG 2.2, hedef seviyeniz AA, çerçeveniz POUR ilkeleri, ve yasal arka planınız 28 Haziran 2025'te yürürlüğe giren EAA'dır. Bu üçlü, bugün dünyadaki erişilebilirlik gerekliliklerinin neredeyse tamamını tanımlar. İlk üç adımınız net olmalı: (1) mevcut sitenizi otomatik bir tarama ve bir klavye turuyla hızlıca denetleyin, (2) en yaygın ve en ucuz hataları (kontrast, alt metni, form etiketleri, dil tanımı) önce kapatın, (3) yeni geliştirmelerde WCAG 2.2 AA'yı baştan kabul kriteri yapın.

Sitenizin hangi seviyede olduğunu öğrenmenin en sağlıklı yolu, gerçek bir denetimle başlamaktır; mevcut altyapınızı ve teknik durumunuzu hızlıca görmek için denetim aracımızı kullanabilir, kapsamlı bir erişilebilirlik ve uyum değerlendirmesi için ücretsiz analiz formumuz üzerinden bizimle iletişime geçebilirsiniz. AB pazarına satış yapan ya da yeni bir kurumsal proje kuran firmalar için erişilebilirliği baştan doğru kurmak, sonradan düzeltmekten her zaman daha ucuz ve daha hızlıdır; bu yaklaşımı web ve mobil UI/UX tasarım hizmetimizin standart bir parçası olarak uyguluyoruz.

Erişilebilirliği pratikte nasıl uygularız?

Erişilebilirlik (a11y) soyut bir hedef değil, somut altı uygulama alanının disiplinle yürütülmesidir: yeterli renk kontrastı, anlamlı alt metin, klavyeyle tam gezilebilirlik, doğru kullanılmış ARIA, etiketli form alanları ve mantıklı başlık yapısı. Müşterilerimizde gördüğümüz tablo nettir: WebAIM Million yıllık raporuna göre tespit edilen erişilebilirlik hatalarının ezici çoğunluğu yalnızca birkaç tekrar eden kök nedenden gelir; düşük metin kontrastı, alt-metni olmayan görseller, boş bağlantılar, etiketsiz form alanları, boş butonlar ve eksik dil tanımı. Yani bu altı başlığı doğru kurarsanız, ölçülen hataların büyük bölümünü daha en baştan yok edersiniz. Bu bölümde her birini "ne, neden, nasıl" sırasıyla, kodla değil karar kriterleriyle ele alıyoruz. Erişilebilirliğin neden artık bir "özellik" değil altyapı olduğunu ve EAA/WCAG 2.2 çerçevesini erişilebilirlik rehberinin üst bölümlerinde ele aldık; burada uygulamaya iniyoruz.

Çalışma yöntemimiz şudur: önce hatanın kullanıcıyı nasıl etkilediğini görünür kılarız (bir ekran okuyucu kullanıcısı bu sayfada gerçekten ne duyuyor?), sonra düzeltmenin tasarım ve geliştirme maliyetini belirleriz. Müşterilerimizde gördüğümüz pratik gerçek şu: erişilebilirlik hatalarının büyük çoğunluğu, projenin sonunda yapılan "yamalar" değil, baştan doğru kurulduğunda neredeyse sıfır ek maliyetle önlenebilen kararlardır. Aşağıdaki tablo bu altı alanı, en sık görülen hatayı, etkilediği kullanıcı grubunu ve ilgili WCAG seviyesini özetler; bölümün geri kalanı her satırı tek tek açar.

Renk kontrastı: en sık hata, en kolay düzeltme

Renk kontrastı, metin ile arka planı arasındaki aydınlık farkının ölçülebilir oranıdır ve erişilebilirlikte en sık görülen tek hatadır. WCAG AA kuralı kesindir: gövde metni için kontrast oranı en az 4.5:1, büyük metin (yaklaşık 24px veya 19px kalın üzeri) için en az 3:1 olmalıdır. Bunu "gözüme iyi görünüyor" diyerek geçemezsiniz; oran sayısaldır ve ölçülür. Müşterilerimizde en çok rastladığımız hatalar açık gri üzerine daha açık gri metin, marka renginin beyaz zemin üzerine yetersiz kontrastla kullanılması ve özellikle butonlardaki açık renk metindir. Burada gözden kaçan ikinci bir kural daha vardır: WCAG 2.1'le gelen ve 2.2'de korunan 1.4.11 "Metin Olmayan Kontrast" kriteri, yalnızca yazıyı değil; buton kenarlığı, form alanı çerçevesi, ikon ve grafik öğelerinin de zeminden en az 3:1 ayrışmasını ister. Yani kenarlıksız, çok soluk gri bir input kutusu metni okunaklı olsa bile erişilebilir sayılmaz, çünkü kullanıcı alanın nerede bittiğini göremez.

Pratik yaklaşım şudur: tasarım aşamasında her metin-zemin çiftini bir kontrast denetleyicisinden (tarayıcının yerleşik DevTools denetimi, WebAIM Contrast Checker gibi) geçirin. Somut bir örnek: çok yaygın kullanılan "#777777 gri metin / beyaz zemin" kombinasyonu yaklaşık 4.48:1 oranı verir ve gövde metni için AA eşiğinin (4.5:1) hemen altında kalır; tonu bir adım koyulaştırıp "#767676"ya çekmek metni resmen uyumlu hale getirir. Bu, "neredeyse uyumlu" ile "uyumlu" arasındaki farkın çoğu zaman ne kadar küçük bir renk düzeltmesi olduğunu gösterir. İkinci kritik kural, rengin tek başına bilgi taşımamasıdır; renk körlüğü olan kullanıcılar için "kırmızı alanı doldurun" yetmez, hata mesajına ikon veya metin de eklenmelidir. Form doğrulama hatasını yalnızca alanı kırmızıya boyayarak gösteren tasarımlar erişilebilir değildir. Aynı şey grafik ve durum göstergelerinde de geçerlidir: yalnızca yeşil/kırmızı noktayla "aktif/pasif" anlatan bir gösterge, en yaygın renk körlüğü türü olan kırmızı-yeşil ayrımı bozuk kullanıcılar için anlamsızdır; yanına bir etiket veya farklı bir şekil koymak gerekir.

Aynı ilke link'lerde de geçerlidir: bağlantılar yalnızca renkle değil, altı çizili veya başka bir görsel ipucuyla da ayırt edilebilmelidir; özellikle gövde metni içine gömülü, çevresindeki yazıyla aynı renge yakın görünen "renksiz" linkler erişilebilirlik açısından sorunludur. Kontrast aynı zamanda bir okunabilirlik ve dolayısıyla dönüşüm meselesidir; düşük kontrastlı CTA butonu hem erişilemez hem de tıklanma oranı düşük olur. Mobilde bu daha da kritiktir, çünkü kullanıcı çoğu zaman güneş altında, parlama yapan bir ekranda site geziyordur; masaüstünde "yeterli" görünen kontrast, dışarıda telefonda okunamaz hale gelir. Bu yüzden kontrastı dönüşüm odaklı tasarımın bir parçası olarak ele almanızı öneriyoruz, ayrı bir "uyum görevi" gibi değil; iyi kontrast hem erişilebilirlik hem de iyi web tasarımının ortak paydasıdır.

Alt metin: görseli "okutmak"

Alt metin (alt attribute), bir görseli göremeyenler için onun anlamını metne çeviren açıklamadır; ekran okuyucular bu metni sesli okur, görsel yüklenmezse de gösterilir. Alt-metni olmayan görseller, WebAIM Million'ın en sık raporladığı hatalar arasındadır ve çözümü teknik olarak basit, kavramsal olarak inceliklidir. Kural her görsele otomatik olarak uzun bir açıklama yazmak değildir; doğru karar görselin sayfadaki işlevine bağlıdır. Burada ince ayrım şudur: hiç alt niteliği olmaması (alt hiç yazılmamış) ile boş alt niteliği (alt="") birbirinden çok farklıdır. İlkinde ekran okuyucu çoğu zaman görselin dosya adını ("IMG_4821.jpg") harf harf okur ki bu en kötü deneyimdir; ikincisinde ise görsel bilinçli olarak atlanır. Yani "alt yok" bir eksiklik, "alt boş" bir karardır.

Pratik ayrım şudur: Görsel bilgi taşıyorsa (ürün fotoğrafı, bilgilendirici diyagram, metin içeren afiş), alt metin o bilgiyi aktarmalıdır; örneğin "mavi spor ayakkabı, yandan görünüm" gibi. Görsel tamamen dekoratifse (arka plan deseni, ayraç süsü), alt metni boş bırakılır (alt="") ki ekran okuyucu onu atlasın; bu da bilinçli bir karardır, eksiklik değil. Bağlantı veya buton içindeki görselde alt metin, görseli değil eylemi anlatmalıdır; örneğin logo bir bağlantıysa alt metni "Ana sayfa" olabilir. İçinde metin bulunan görsellerde (kampanya afişi gibi) o metnin alt metinde de yer alması şarttır, aksi halde ekran okuyucu kullanıcısı kampanyayı hiç duymaz; ayrıca "metin görseli" yerine mümkün olduğunca gerçek HTML metni kullanmak hem erişilebilirlik hem de çözünürlük açısından her zaman daha iyidir.

Birkaç pratik tuzak da vardır. "Resim", "fotoğraf", "görsel" gibi kelimelerle başlamak gereksizdir; ekran okuyucu öğeyi zaten "görsel" olarak duyurur, siz tekrar ederseniz kullanıcı "görsel, görsel ayakkabı" duyar. Bilgi taşıyan ama yanında zaten aynı bilgiyi veren bir başlık/açıklama olan görseller dekoratif sayılıp boş alt ile geçilebilir; aksi halde aynı bilgi iki kez okunur. Karmaşık görsellerde (detaylı grafik, infografik) kısa bir alt metin + yakınında uzun metinsel açıklama kombinasyonu en doğru çözümdür. Burada bir SEO kazanımı da vardır: anlamlı alt metin Google'ın görseli anlamasına yardımcı olur, bu yüzden erişilebilirlik ile sayfa içi SEO birbirini besler. E-ticarette ürün görsellerinin alt metinleri hem erişilebilirlik hem de görsel aramada bulunabilirlik için ayrı bir önem taşır; bu da erişilebilirliğin neden bir maliyet değil, aynı anda birden çok hedefe hizmet eden bir yatırım olduğunu gösterir ve bütünüyle teknik SEO denetiminin bir parçası olarak ele alınmalıdır.

Klavye navigasyonu: faresiz tam kullanım

Klavye navigasyonu, sitenin tamamının yalnızca klavyeyle (Tab, Shift+Tab, Enter, Space, ok tuşları) eksiksiz kullanılabilmesidir. Bu yalnızca görme engelliler için değil; motor becerilerini etkileyen durumlar, fare kullanamayan kullanıcılar ve ileri düzey klavye kullanıcıları için de kritiktir. Erişilebilirlikte "fare olmadan her şeyi yapabiliyor muyum?" testi, en hızlı ve en ucuz a11y denetimidir: sitenizi açın, fareyi kenara bırakın ve yalnızca Tab ile menüden form göndermeye kadar tüm yolculuğu deneyin. Bu beş dakikalık testi her teslimat öncesi yapmanızı öneririz; çünkü otomatik tarayıcılar (Lighthouse, axe gibi) hataların ancak bir kısmını yakalar, klavyeyle gezinme deneyimini ölçemez ve bu yüzden insan denetimi şarttır.

Burada üç kural belirleyicidir. Birincisi, tüm etkileşimli öğeler (bağlantı, buton, form alanı, sekme, açılır menü) klavyeyle erişilebilir ve çalıştırılabilir olmalı. Standart HTML öğeleri (<a>, <button>, <input>) bunu zaten sağlar; sorun genelde <div> üzerine tıklama olayı bindirerek yapılmış "sahte butonlar"da çıkar, çünkü onlar Tab sırasına girmez ve Enter/Space ile çalışmaz. İkincisi, görünür odak halkasıdır: kullanıcı o an hangi öğede olduğunu görebilmelidir. WCAG 2.2'nin yeni başarı kriterlerinden biri (2.4.11 Odak Görünürlüğü) tam olarak odağın yeterince görünür olmasını güçlendirir; bu yüzden estetik kaygıyla outline'ı tamamen kaldırmak (outline: none) ciddi bir hatadır, bunun yerine markaya uygun ama net bir odak stili tasarlanmalıdır. İyi bir pratik, görünür odak halkasını koyu zeminde açık, açık zeminde koyu olacak şekilde tasarlamak ve yalnızca klavye kullanıcısında göstermek için :focus-visible kullanmaktır; böylece fareyle tıklayan kullanıcıyı rahatsız etmeden klavye kullanıcısına net geri bildirim verirsiniz.

Üçüncüsü mantıklı odak sırasıdır: Tab ile ilerleyiş, sayfanın görsel okunma sırasıyla uyumlu olmalı, oraya buraya zıplamamalı. Bu davranışın temelinde anlamlı HTML yapısı yatar; öğeleri doğru sırada ve doğru elementlerle yazarsanız klavye davranışı çoğunlukla kendiliğinden doğru olur; CSS ile öğeleri görsel olarak yeniden konumlandırmak (örneğin flex/grid ile sırayı değiştirmek) DOM sırasını değiştirmez ve odak sırası ekrandakiyle çelişerek kullanıcıyı şaşırtabilir. İki ek konu daha önemlidir. Birincisi "atla bağlantısı" (skip link): sayfa başında, görünür hale gelince "İçeriğe geç" diyen ve menüyü atlayan bir bağlantı, her sayfada onlarca menü öğesini Tab'lamak zorunda kalan klavye kullanıcısına büyük zaman kazandırır. İkincisi odak tuzağı (focus trap): bir modal/pop-up açıldığında odak modal içinde kalmalı, Escape ile kapanabilmeli ve kapanınca onu açan butona geri dönmelidir; aksi halde kullanıcı görünmeyen arka plandaki öğeler arasında kaybolur. İyi klavye davranışı aynı zamanda genel UI/UX kalitesinin bir göstergesidir; sürtünmesiz bir akış hem erişilebilir hem de dönüşümü yüksek olur. Mobil tarafta da benzer bir disiplin geçerlidir; dokunmatik hedeflerin yeterli boyutta olması ve tek elle erişilebilirliği mobil uyumlu tasarım ile el ele gider.

Form etiketleri: girdinin ne istediğini söylemek

Form etiketi (label), her girdi alanının ne istediğini hem ekran okuyucuya hem de göze açıkça bildiren metindir. Etiketsiz form alanları, WebAIM'in en sık raporladığı hataların başında gelir ve sonuçları ağırdır: ekran okuyucu kullanıcısı bir kutuya geldiğinde "düzenlenebilir metin" der ama ne yazması gerektiğini söyleyemez. Çözüm her görsel etiketi gerçek bir <label> öğesiyle ilgili alana programatik olarak bağlamaktır (label'ın for niteliği ile alanın id'sini eşleştirerek). Böylece etikete tıklamak alanı seçer (dokunmatik hedefi büyütür, bu da mobilde doğrudan kullanılabilirlik kazancıdır) ve ekran okuyucu doğru ismi okur.

Sık yapılan hata, etiket yerine yalnızca placeholder (kutu içi soluk ipucu metni) kullanmaktır. Placeholder etiket değildir: kullanıcı yazmaya başlayınca kaybolur, böylece kullanıcı ne girdiğini doğrulayamaz; kontrastı genelde düşüktür ve birçok ekran okuyucu onu etiket olarak okumaz. Placeholder örnek vermek için kullanılabilir (örneğin tarih alanında "GG/AA/YYYY") ama gerçek etiketin yerini asla almaz. İki kural daha önemlidir: zorunlu alanları yalnızca yıldız (*) ile değil, metinle de belirtin ve hangi alanların zorunlu olduğunu formun başında açıklayın; hata mesajları net, alana yakın ve çözüm önerili olsun ("E-posta gerekli" yerine "Lütfen geçerli bir e-posta girin, örn. ad@firma.com"). Birden çok alanı tek satırda gruplayan yapılarda (adres, doğum tarihi) ilişkili alanları <fieldset> ve <legend> ile gruplamak, ekran okuyucunun bağlamı doğru aktarması için önemlidir.

WCAG 2.2 ayrıca gereksiz tekrar girişin önlenmesi (3.3.7 Redundant Entry) ve erişilebilir kimlik doğrulama (3.3.8 Accessible Authentication) gibi yeni kriterlerle özellikle form ve giriş akışlarını hedef alır. Pratikte bu şu demektir: uzun bir sipariş akışında kullanıcının fatura adresini girdikten sonra aynı bilgiyi teslimat için tekrar yazmaya zorlanmaması (otomatik doldurma veya "aynısı" seçeneği) artık bir uyum maddesidir; benzer şekilde, kullanıcıyı bir bilmeceyi çözmeye ya da bir kodu ezberden yazmaya zorlayan giriş yöntemleri yerine, tarayıcının/parola yöneticisinin alanı otomatik doldurmasına izin veren (doğru autocomplete nitelikleri verilmiş) akışlar tercih edilmelidir. Form erişilebilirliği aynı zamanda bir güvenlik ve veri kalitesi meselesidir; doğru etiketlenmiş, hatasız doldurulan formlar daha az terk edilir ve bu doğrudan dönüşüm oranını etkiler. Form akışlarının hem erişilebilir hem güvenli olması için sunucu tarafı doğrulama ve girdi temizleme gibi konuları web güvenliği rehberinde ele aldık; iki disiplin formun iki yüzüdür. Türkiye bağlamında ek bir not: KVKK aydınlatma onayı ile ticari ileti (ETK) izni ayrı kutular olmalıdır ve bu kutular da etiketli, klavyeyle işaretlenebilir ve ekran okuyucuyla anlaşılır olmalıdır; "tek kutuda hepsini kabul ediyorum" hem hukuken hem erişilebilirlik açısından sorunludur.

Başlık yapısı: sayfanın iskeletini doğru kurmak

Başlık yapısı, sayfadaki başlıkların (<h1>'den <h6>'ya) mantıklı ve hiyerarşik bir düzende kullanılmasıdır; bu, içeriğin görünmeyen "iç oğlağı" gibidir. Ekran okuyucu kullanıcıları bir sayfayı baştan sona dinlemez; başlıklar arasında zıplayarak (çoğu ekran okuyucuda H tuşuyla) ilgilendikleri bölüme giderler. WebAIM'in kullanıcı anketleri yıllardır tutarlı şekilde, ekran okuyucu kullanıcılarının uzun bir sayfada gezinmek için en sık başvurduğu yöntemin başlıklar olduğunu gösterir; yani başlık yapısı bu kullanıcılar için sitenin içindekiler tablosudur. Başlık yapısı bozuksa bu gezinme çöker. Bu yüzden başlıklar yalnızca "büyük ve kalın görünsün" diye değil, gerçek bir bölüm hiyerarşisi kurmak için kullanılmalıdır.

Kurallar şunlardır: Her sayfada tek bir <h1> bulunur ve bu sayfanın ana konusunu tanımlar. Alt bölümler <h2>, onların altları <h3> ile gider; seviye atlanmaz, yani <h2>'den doğrudan <h4>'e geçilmez (yukarı doğru, örneğin <h3>'ten <h2>'ye dönmek serbesttir, bu yeni bir üst bölümün başladığını gösterir). En sık hata, bir metni yalnızca büyük göstermek için başlık etiketi kullanmak ya da tersine, gerçek bir başlığı stil verilmiş bir <div> ile yapıp hiyerarşiden mahrum bırakmaktır. Görsel boyut CSS'in işidir; başlık etiketi ise anlam (semantik) içindir. İki ek tuzağa daha dikkat edin: birincisi, görsel olarak boş bırakmak istediğiniz başlıkları boş <h2></h2> olarak değil hiç koymadan geçin, çünkü boş başlıklar WebAIM'in saydığı yaygın hatalardandır; ikincisi, her tasarım kartına ya da sidebar kutusuna refleksle başlık etiketi vermek yerine, gerçekten bir bölüm hiyerarşisi mi yoksa sadece bir görsel öğe mi olduğunu sorun.

Doğru başlık yapısı yalnızca erişilebilirlik için değil, SEO için de doğrudan değer üretir; arama motorları da sayfanın yapısını başlıklardan okur, bu yüzden teknik SEO denetiminin sabit bir kalemidir. Başlıklar, erişilebilir bir sayfanın iskeletinin yalnızca bir parçasıdır. Bunun yanına diğer "yer işareti" (landmark) öğeleri eklenir: sayfanın ana içeriği için <main>, gezinme menüsü için <nav>, üst/alt bilgi için <header> ve <footer>. Ekran okuyucu kullanıcıları bu yer işaretleri arasında da hızla geçebilir; örneğin doğrudan "ana içeriğe" atlayabilir. Genel olarak anlamlı HTML (semantic markup) kullanmak; başlıklar, listeler, <nav>, <main>, <button> gibi öğeleri görevine uygun seçmek, erişilebilirliğin temelidir ve birçok sorunu daha doğmadan engeller. Üstelik bu yaklaşım hem dosya boyutunu hem de bakım yükünü azaltır; "div çorbası" yerine doğru etiket seçmek ek bir maliyet değil, daha temiz bir koddur ve bu da altyapı/CMS seçiminizden bağımsız her projede geçerlidir.

ARIA: gerektiğinde, abartmadan

ARIA (Accessible Rich Internet Applications), standart HTML'in tek başına anlatamadığı arayüz durumlarını yardımcı teknolojilere bildiren ek nitelikler bütünüdür; örneğin bir menünün açık mı kapalı mı olduğu, bir sekmenin seçili olup olmadığı, dinamik bir bildirimin yeni geldiği gibi durumları. ARIA güçlü bir araçtır ama en kritik kural şudur: ARIA'yı yalnızca gerektiğinde kullanın. Erişilebilirlik dünyasında bilinen ilke "No ARIA is better than bad ARIA" yani yanlış ARIA, hiç ARIA olmamasından daha kötüdür, çünkü ekran okuyucuya gerçekle uyuşmayan bilgi verir ve kullanıcıyı yanıltır. WebAIM Million raporlarının son yıllardaki çarpıcı bulgularından biri tam da budur: ARIA kullanan sayfaların ortalamada, hiç ARIA kullanmayan sayfalardan daha fazla tespit edilmiş hatası olabiliyor; çünkü ARIA çoğu zaman doğru çözmek yerine soruna eklenen bir yama olarak, yanlış kullanılıyor.

Pratik karar zinciri şudur: Önce doğru HTML öğesini kullanın. Tıklanabilir bir şey gerekiyorsa, üzerine role="button" bindirilmiş bir <div> yerine gerçek bir <button> kullanın; o öğe klavye, odak ve rol davranışını zaten ücretsiz getirir. Native HTML yeterli olduğunda ARIA'ya hiç ihtiyaç duymazsınız ve bu en sağlam yoldur; bu yüzden ARIA'nın "birinci kuralı" sektörde "mümkünse ARIA kullanma, yerine doğru HTML öğesini kullan" diye özetlenir. Sık görülen iki abartı vardır: zaten anlamı olan öğelere gereksiz rol vermek (örneğin bir <button>'a tekrar role="button" yazmak) ve bir öğeyi aria-hidden="true" ile ekran okuyucudan gizlerken o öğenin içinde hâlâ Tab ile odaklanabilen bir buton/bağlantı bırakmak; bu ikincisi, kullanıcının "duyamadığı ama yine de üzerine düştüğü" hayalet bir öğe yaratır ve en kafa karıştırıcı hatalardandır.

ARIA'yı asıl ihtiyaç duyduğunuz yerler, HTML'de doğal karşılığı olmayan dinamik bileşenlerdir: sekme panelleri, akordeon menüler, modal pencereler, otomatik tamamlama, canlı güncellenen bölgeler (aria-live ile yeni gelen bildirimleri, örneğin "sepete eklendi" ya da bir form hatası özetini okutmak gibi). Bu bileşenlerde durum nitelikleri (aria-expanded, aria-selected, aria-hidden) ve erişilebilir isimler (aria-label, aria-labelledby) işin kalbidir; ama bunların değerlerini JavaScript ile gerçek duruma senkron tutmak şarttır, aksi halde "açık" diyen ama kapalı olan bir menü elde edersiniz. Pratik bir örnek: bir "hamburger" menü butonuna aria-expanded verip menü açılıp kapandıkça bu değeri true/false arasında güncellemezseniz, ekran okuyucu kullanıcısı menünün durumunu hiçbir zaman doğru öğrenemez. Özetle ARIA bir kestirme değil, son çaredir: önce anlam taşıyan HTML, sonra klavye ve odak, en son gerçekten gereken yerde ARIA. Bu disiplinli yaklaşım, erişilebilirliği baştan kuran UI/UX tasarım hizmetimizin ve özel yazılım geliştirme sürecimizin ayrılmaz parçasıdır; sonradan eklenen erişilebilirlik her zaman baştan kurulandan daha pahalı ve kırılgan olur. Sitenizin erişilebilirlik, hız ve SEO durumunu birlikte görmek isterseniz ücretsiz analiz üzerinden bir denetim talep edebilir, bulgularımızı önceliklendirilmiş bir yol haritasına dönüştürebiliriz.

Erişilebilirlik, SEO ve UX neden aynı temelden beslenir?

Erişilebilirlik, SEO ve kullanıcı deneyimi (UX) ayrı disiplinler gibi görünse de pratikte aynı temele dayanır: anlamlı yapı, doğru etiketleme ve makinenin de insanın da kolayca yorumlayabildiği bir sayfa. Bir ekran okuyucu için "başlık nedir, bağlantı nereye gider, bu görsel ne anlatır" sorusunu çözen işaretleme; aynı zamanda Google'ın botunun, hızlı tarayan bir mobil kullanıcının ve klavyeyle gezen bir ziyaretçinin de cevabını aradığı sorudur. Bu yüzden müşterilerimizde gördüğümüz en verimli iş, erişilebilirliği "engelli kullanıcılar için ek bir katman" değil, sayfanın doğru kurulmuş iskeleti olarak ele almaktır. Erişilebilir bir sayfa, neredeyse her zaman SEO ve dönüşüm açısından da daha iyi bir sayfadır; çünkü üçü de aynı sinyalleri okur. Bu örtüşmeyi pratik başlıklara dökerek somutlaştıralım.

Bu üçlü ilişkiyi anlamanın en pratik yolu, her birinin sayfayı kimin gözünden okuduğunu görmektir. Aşağıdaki tablo, tek bir doğru uygulamanın aynı anda üç cepheyi nasıl beslediğini özetler:

Semantik HTML hem ekran okuyucuya hem arama motoruna aynı haritayı verir

Erişilebilirliğin temeli anlamlı (semantic) HTML'dir: <header>, <nav>, <main>, <article>, <section>, <footer> gibi etiketlerle sayfanın bölümlerini, başlık hiyerarşisini ise tek bir <h1> ve mantıksal sırada <h2>/<h3> ile kurmak. Bunun erişilebilirlik tarafı nettir: ekran okuyucu kullanıcıları "başlıklara göre gezinme" özelliğiyle sayfayı bir içindekiler tablosu gibi tarar; landmark (header/main/nav) etiketleri sayesinde doğrudan ana içeriğe atlayabilir. Tam olarak aynı yapı, arama motorunun da sayfayı yorumlama biçimidir. Google sayfanın hangi bölümünün ana içerik, hangisinin gezinme olduğunu bu işaretlemeden anlar; başlık hiyerarşisi konunun mantıksal kurgusunu gösterir.

Somut bir örnek faydalıdır. Bir ekran okuyucu kullanıcısı NVDA veya VoiceOver ile "H" tuşuna basarak başlıktan başlığa atlar; iyi kurulmuş bir sayfada bu, basılı bir kitabın içindekiler kısmında gezinmek gibidir. Aynı kullanıcı, <main> landmark'ı tanımlıysa tek komutla menüyü ve tekrar eden üst bilgiyi atlayıp doğrudan asıl içeriğe geçer. WCAG 2.2'nin bu mantığı destekleyen pratik bir kuralı da vardır: tekrar eden gezinme bloklarını atlamak için "ana içeriğe geç" türü bir atlama bağlantısı (skip link) sunmak. Bu bağlantı görsel olarak gizli durabilir, yalnızca klavyeyle odaklandığında belirir; ama hem klavye kullanıcısının her sayfada onlarca sekme tuşundan kurtulmasını sağlar hem de yapının düzgün kurulduğunun işaretidir.

Burada kritik nokta şudur: bir <div> yığınıyla, tıklanabilir hâle getirilmiş kutularla görsel olarak aynı sonuca ulaşabilirsiniz, ama hem ekran okuyucu hem de arama motoru bu yapıyı "anlamsız bir kutular yığını" olarak görür. Müşterilerimizde sık karşılaştığımız hata, görsel olarak başlık gibi duran ama aslında kalın yapılmış bir <div> olan metinlerdir; bunlar başlık hiyerarşisine girmez, ne ekran okuyucu ne Google için başlık sayılır. İkinci sık hata, başlık seviyelerinin görünüm için atlanmasıdır: bir <h2>'den sonra "daha küçük görünsün diye" doğrudan <h4>'e geçmek hiyerarşiyi bozar. Boyut kararı CSS'in işidir; başlık seviyesi anlamın işidir. Anlamlı HTML kullanmak ek maliyet değildir; doğru etiketi seçmek, yanlış etiketi seçmekle aynı eforu gerektirir. Bu yapısal mantığın sayfa içi SEO tarafıyla nasıl bütünleştiğini on-page SEO rehberimizde başlık etiketleri ve içerik kurgusu üzerinden ayrıntılı işliyoruz; teknik tarafta tespit için teknik SEO denetimi yaklaşımımız da aynı yapısal sorunları yakalar. İyi tasarımın bu yapısal yönünü iyi web tasarımı rehberimizde de tamamlayıcı açıdan ele alıyoruz.

Alt metni: erişilebilirlik kuralı, aynı zamanda görsel SEO sinyali

Görsellere anlamlı alt metni (alt attribute) eklemek, hem WCAG'in temel gerekliliklerinden biridir hem de görsel SEO'nun en doğrudan sinyalidir. Ekran okuyucu kullanan biri için alt metni, göremediği görselin yerine geçen tanımdır; "ürün ambalajı yakın çekim, etiket görünür" gibi içeriği aktaran bir cümle, kullanıcının sayfayı anlamasını sağlar. Arama motoru tarafında ise alt metni, görsel aramada o görselin neyle ilgili olduğunu söyleyen ana metindir; aynı zamanda görsel yüklenemediğinde ekranda gösterilecek yedektir. Yani tek bir doğru pratik, üç ayrı problemi birden çözer: erişilebilirlik, görsel SEO ve hata dayanıklılığı.

WebAIM'in her yıl yayımladığı milyon-sayfa taramasında (WebAIM Million), alt-metni olmayan görseller tespit edilen erişilebilirlik hatalarının en büyük kalemlerinden biridir; düşük metin kontrastı, boş bağlantılar ve etiketsiz form alanlarıyla birlikte hataların büyük çoğunluğunu oluşturur. Doğru alt metni yazmanın da bir pratiği vardır ve görselin işlevine göre değişir:

• Bilgilendirici görsel: içeriği özetleyen kısa, doğal bir cümle. Örnek: bir grafik için "2026'da mobil trafiğin masaüstüne göre payını gösteren çubuk grafik" demek, yalnızca "grafik" demekten çok daha değerlidir.
• Dekoratif görsel: hiçbir bilgi taşımayan süs görsellerinde alt'ı boş bırakın (alt=""), böylece ekran okuyucu onu atlar ve kullanıcıyı gereksiz okumayla yormaz. Burada alt'ı tamamen silmek değil, bilinçli olarak boş bırakmak gerekir.
• İşlevsel görsel (bağlantı/buton içindeki): alt metni görseli değil, eylemi tarif etmeli. Logo bir bağlantıysa "Alis Dijital ana sayfa" gibi.
• Metin içeren görsel: üzerindeki yazı önemliyse o yazı alt metninde de yer almalı; mümkünse metni görselin içine gömmek yerine gerçek metin olarak vermek tercih edilir.

Bizim önerimiz şudur: bilgi taşıyan her görselde içeriği özetleyen, anahtar kelimeyi zorlamadan doğal aktaran bir metin yazın. Anahtar kelimeyle doldurmaya çalışmak (keyword stuffing) hem kullanıcı için kötüdür hem de SEO açısından geri teper; üst üste tekrarlanan anahtar kelimeler ekran okuyucu kullanıcısı için işkenceye, arama motoru için spam sinyaline dönüşür. Aynı doğal-dil disiplini, sayfanın başlık ve açıklama etiketleri için de geçerlidir; bunları tutarlı üretmek için meta başlık ve açıklama oluşturucu aracımızdan yararlanabilirsiniz.

Klavye erişimi, odak ve dokunmatik hedef: UX ile birebir örtüşür

Erişilebilirliğin "klavyeyle tam gezilebilirlik" ve "görünür odak halkası" gereklilikleri, doğrudan kullanılabilirlik kazanımıdır. Sayfanızda bağlantılar, butonlar ve form alanları yalnızca fareyle değil Tab tuşuyla da sırayla gezilebiliyor ve o an nerede olduğunuzu gösteren görünür bir odak çerçevesi varsa; bu özellikten yalnızca görme engelli kullanıcılar değil, fare kullanmayan ileri düzey kullanıcılar, geçici el sakatlığı olanlar ve mobil klavye/harici klavye kullananlar da yararlanır. WCAG 2.2'nin 2.1'e göre eklediği 9 yeni başarı kriterinden birçoğu tam da bu alanı güçlendirir: odak görünürlüğü, sürükleme hareketlerine alternatif, tutarlı yardım ve erişilebilir kimlik doğrulama gibi.

Pratikte sık gördüğümüz iki kritik hata vardır. Birincisi, tasarımcının "çirkin duruyor" diye CSS'te odak halkasını tamamen kaldırmasıdır (outline: none). Bu tek satır, klavye kullanıcısını sayfada kör eder; nerede olduğunu göremez. Doğru yaklaşım, halkayı kaldırmak değil markaya uygun, net görünür bir odak stiliyle değiştirmektir. İkincisi, sekme sırasının (tab order) görsel düzenle uyumsuz olmasıdır: CSS ile öğeleri görsel olarak taşırken DOM sırasını bozarsanız, klavye kullanıcısı sayfada zıplayarak gezer. Mantıklı bir okuma sırası hem erişilebilirlik hem de SEO için (içeriğin kaynak sırası) önemlidir. Üçüncü bir nokta, yalnızca fareyle çalışan etkileşimlerdir: hover ile açılan ama klavyeyle ya da dokunmatikle açılamayan menüler, bütün bir kullanıcı grubunu dışarıda bırakır.

Bu örtüşmenin mobildeki en somut örneği dokunmatik hedef boyutudur. WCAG 2.2'nin 2.5.8 (AA) kriteri minimum 24x24 CSS piksel ister; Apple HIG 44x44 pt, Google Material 48x48 dp önerir; WCAG 2.5.5 (AAA) ise 44x44 px. Pratikte en az 44-48px civarı hedef boyutu hem erişilebilirlik kuralını karşılar hem de Fitts Yasası gereği herkes için tıklamayı/dokunmayı kolaylaştırır: yeterince büyük ve yeterli boşlukla ayrılmış butonlar, parmakla yanlışlıkla komşu öğeye basma oranını düşürür ve dönüşümü artırır. Yani küçük, sıkışık butonlar yalnızca erişilebilirlik ihlali değil, doğrudan dönüşüm kaybıdır. Buna bağlı bir başka WCAG 2.2 kriteri, odaklanan öğenin sabit üst bilgi (sticky header) ya da çerez bandı arkasında gizlenmemesidir; mobilde sık karşılaşılan bu sorun da hem klavye hem dokunmatik kullanıcıyı engeller. Bu konuyu ekran boyutlarına göre düzen, breakpoint ve dokunmatik akış açısından mobil-uyumlu responsive web tasarım rehberimizde ayrıntılı ele alıyoruz; mobil-öncelikli indekslemenin SEO boyutu da aynı sayfada işlenir.

Kontrast: WCAG kuralı ile okunabilirlik UX'i tek noktada buluşur

Renk kontrastı, erişilebilirlik ve UX örtüşmesinin belki en görünür örneğidir. WCAG AA, gövde metni için en az 4.5:1, büyük metin için (yaklaşık 18px kalın ya da 24px normal üzeri) 3:1 kontrast oranı ister. Bu sayısal kural aslında bir okunabilirlik kuralıdır: açık gri zemin üzerine açık gri yazı, görme engeli olmayan, parlak güneş altında telefonuna bakan sıradan bir kullanıcı için de okunmaz haldedir. WCAG kontrast eşiğini karşılayan bir tasarım, herkes için daha okunabilir bir tasarımdır. Düşük kontrast, WebAIM Million taramasında yıllardır en sık raporlanan tek erişilebilirlik hatasıdır; bu da sorunun ne kadar yaygın ve ne kadar gözden kaçtığını gösterir.

Buna bağlı ikinci ilke de hem erişilebilirlik hem UX kuralıdır: renk tek başına bilgi taşımamalı. "Kırmızı alanları doldurun" demek, kırmızı-yeşil renk körü kullanıcılar için (erkeklerde görece yaygın bir durum) anlamsızdır; uyarıyı renkle birlikte ikon veya metinle de vermek gerekir. Bir form alanı hatalıysa kenarlığı kırmızı yapmak yetmez; yanına bir uyarı ikonu ve "Bu alan zorunludur" gibi açık bir metin koymak gerekir. Aynı şekilde bir grafikte serileri yalnızca renkle ayırmak yerine desen, etiket veya doğrudan üzerine yazılmış değerlerle de ayırmak gerekir. Bu disiplin, formların ve uyarı durumlarının herkes için daha anlaşılır olmasını sağlar; dönüşüm açısından da, kullanıcının nerede hata yaptığını net görmesi formu terk etme oranını düşürür. Kontrastın yanı sıra okunabilirliği belirleyen tipografi seçimleri (gövde metni ~16px taban, 50-75 karakter satır uzunluğu, 1.4-1.6 satır aralığı) de aynı "herkes için okunur" hedefine hizmet eder ve bunları UI/UX tasarım rehberimizde ayrıntılandırıyoruz.

Form etiketleri, bağlantı metni ve dil tanımı: ortak kalite zemini

WebAIM verilerinin işaret ettiği sık hatalar listesine bakınca, erişilebilirlik açıklarının çoğunun aslında temel UX/içerik hataları olduğunu görürsünüz. Etiketsiz form alanları: bir ekran okuyucu kullanıcısı için "bu kutu ne istiyor" sorusu cevapsız kalır; ama aynı sorun, görsel olarak da placeholder yazısı kaybolunca kafa karıştıran bir formdur. Placeholder bir etiket değildir; kullanıcı yazmaya başlayınca kaybolur, kontrastı düşüktür ve ekran okuyucu onu güvenilir biçimde etiket olarak okumaz. Her input'a görünür, kalıcı bir <label> bağlamak (for/id eşleşmesiyle) hem WCAG gereği hem de form doldurma deneyimini iyileştiren bir karardır; bu da doğrudan dönüşüm konusudur. WCAG 2.2 bu alanı bir adım ileri taşıyıp gereksiz tekrar girişin önlenmesini (örneğin teslimat adresini fatura adresi olarak yeniden istememek) ve erişilebilir kimlik doğrulamayı (kullanıcıya bulmaca/hafıza testi dayatmamak, tarayıcının şifre ve otomatik doldurma yardımını engellememek) da başarı kriteri hâline getirmiştir; bunların hepsi aynı anda dönüşüm dostudur.

Boş ya da "buraya tıklayın" gibi bağlamsız bağlantılar da benzer biçimde üç cepheyi birden zedeler: ekran okuyucu bağlantıları liste hâlinde okuduğunda "tıklayın, tıklayın, tıklayın" işe yaramaz; aynı belirsiz metin, sayfayı tarayan her kullanıcı için ve bağlantı metnini sinyal olarak okuyan arama motoru için de zayıftır. "Web tasarım fiyatlarını inceleyin" gibi açıklayıcı bir bağlantı metni üçünü birden memnun eder. Aynı mantık butonlar için de geçerlidir: yalnızca bir ikondan ibaret, metni olmayan butonlar (örneğin yalnız bir çöp kutusu ikonu) ekran okuyucuda "boş buton" olarak okunur; bu durumda erişilebilir bir ad (aria-label) vermek ya da görünür metin eklemek gerekir.

Türkiye bağlamında kritik bir ayrıntı da dil tanımıdır. Sayfanın <html lang="tr"> ile doğru işaretlenmesi hem WCAG'in "dil tanımı" gerekliliğini karşılar hem de ekran okuyucunun metni doğru Türkçe telaffuzla okumasını sağlar; lang tanımı yanlışsa Türkçe bir metin İngilizce aksanla, anlaşılmaz biçimde seslendirilir. Ayrıca bu tanım, tarayıcının doğru büyük/küçük harf dönüşümünü (özellikle noktalı/noktasız I ayrımını) yapması için gereklidir; CSS text-transform ile büyük harfe çevrilen Türkçe metinlerde lang="tr" olmadan "i" harfi "I" yerine yanlış dönüşebilir. Sitenin UTF-8 kodlamasıyla yayımlanması ve seçilen yazı tipinin ç, ğ, ı, İ, ö, ş, ü karakterlerini eksiksiz desteklemesi de bu zincirin parçasıdır; bazı popüler yazı tiplerinde özellikle noktalı İ ile sorun çıkar, bu yüzden font seçimi mutlaka Türkçe metinle test edilmelidir. Eksik dil tanımı, WebAIM'in sık hatalar listesinde de yer alan, küçük ama yaygın bir kusurdur.

ARIA'yı abartmamak: üç disiplin için de daha temiz kod

Örtüşmenin sıkça atlanan bir yönü, "ne zaman müdahale etmemek gerektiğidir". Genel ilke şudur: anlamlı HTML her zaman ARIA'ya tercih edilmelidir; ARIA yalnızca yerleşik bir HTML öğesinin yetmediği durumlarda kullanılmalıdır. WAI-ARIA topluluğunda yaygınlaşmış bir kural vardır: "kullanmamak, kötü kullanmaktan iyidir". Yanlış veya gereksiz ARIA, doğru görünen ama ekran okuyucuyu yanıltan bir sayfa üretir; doğru <button> yerine role="button" yüklenmiş bir <div> çoğu zaman daha kırılgan, daha az erişilebilir ve daha çok bakım gerektiren bir koddur. Çünkü gerçek bir <button> klavye odağını, Enter/Space ile tetiklenmeyi, devre dışı bırakılma durumunu ve form gönderimini kutudan çıktığı haliyle getirir; div tabanlı taklit ise tüm bu davranışları tek tek JavaScript ile yeniden yazmanızı ister ve bir tanesini unutmak sessiz bir erişilebilirlik açığı bırakır.

Burada erişilebilirlik ilkesi (önce semantik HTML) ile temiz kod/bakım kolaylığı ve performans (daha az JavaScript, daha az gereksiz işaretleme) aynı yöne çalışır. Daha az ama doğru işaretleme; hem ekran okuyucu uyumluluğu hem sürdürülebilir bir kod tabanı demektir. Ayrıca daha az JavaScript, ana iş parçacığını daha az bloke ettiği için INP (Interaction to Next Paint) ve genel etkileşim hızı açısından da kazançtır; yani semantik HTML tercihi dolaylı olarak Core Web Vitals'ı da destekler. Native <dialog>, <details>/<summary> gibi modern HTML öğeleri, eskiden ARIA ve JavaScript ile elle kurulan açılır pencere ve akordeon kalıplarının çoğunu erişilebilir biçimde, daha az kodla karşılar; öncelik bunlarda olmalıdır.

Pratik sonuç: erişilebilirliği baştan kurmak en ucuz yoldur

Bu örtüşmelerin pratik özeti şudur: erişilebilirliği proje sonunda yamanan bir "denetim kalemi" olarak ele alırsanız, genellikle yapısal sorunları (yanlış başlık hiyerarşisi, div tabanlı butonlar, eksik etiketler) sökmek pahalıya patlar. Çünkü bu sorunlar tasarımın iskeletine işlemiştir; sonradan düzeltmek çoğu zaman bileşenleri yeniden yazmak demektir. Oysa anlamlı HTML, alt metni, görünür odak, yeterli kontrast ve doğru form etiketleri en baştan, tasarım ve geliştirme aşamasında kurulduğunda; aynı emekle hem WCAG 2.2 AA hedefine yaklaşır, hem on-page SEO temelini sağlamlaştırır, hem de dönüşüm oranını destekleyen bir UX elde edersiniz.

Pratik bir iş akışı önerimiz şudur: denetimi otomatik araçlarla (tarayıcı tabanlı erişilebilirlik denetleyicileri, Lighthouse benzeri raporlar) başlatın, ama orada bırakmayın. Otomatik araçlar hataların ancak bir kısmını yakalar; kontrast, eksik alt ve etiket gibi makinece ölçülebilen sorunları bulurlar ama "bu alt metni gerçekten görseli anlatıyor mu", "sekme sırası mantıklı mı", "ekran okuyucuyla bu form gerçekten doldurulabiliyor mu" sorularını yanıtlamazlar. Bu yüzden klavyeyle baştan sona gezme ve gerçek bir ekran okuyucuyla (NVDA, VoiceOver) hızlı bir tur, otomatik denetimin tamamlayıcısı olarak şarttır. Yayın öncesi kontrol listenize erişilebilirlik denetimini tıpkı mobil testi, hız (CWV) ve SEO meta kontrolü gibi sabit bir madde olarak ekleyin.

AB'ye ürün veya hizmet satan firmalar için bu zaten 28 Haziran 2025'te yürürlüğe giren Avrupa Erişilebilirlik Yasası (EAA) ile EN 301 549 / WCAG 2.1 AA düzeyinde bir zorunluluktur; e-ticaret, bankacılık, e-kitap ve ulaşım gibi alanlarda AB'deki tüketiciye satış yapan Türkiye merkezli firmalar da kapsama girebilir ve ihlal cezaları ülkeye göre yüksek seviyelere ulaşabilir. Satmayanlar için ise SEO ve dönüşüm faydası tek başına yeterli bir gerekçedir: erişilebilir bir site daha geniş bir kitleye ulaşır, arama motorunda daha iyi yorumlanır ve daha az kullanıcıyı sürtünmeyle kaybeder. Sitenizin bu üç eksende nerede durduğunu görmek isterseniz, ekibimizin yürüttüğü UI/UX tasarım hizmetimiz kapsamında erişilebilirlik, performans ve dönüşüm denetimini birlikte ele alıyoruz; daha karmaşık, özelleştirilmiş projelerde aynı disiplini özel yazılım hizmetimizle baştan koda gömüyoruz. Mevcut sitenizin hızlı bir değerlendirmesi için ücretsiz analiz formumuzu kullanabilirsiniz.

Erişilebilirlik Denetimi Nasıl Yapılır, Hangi Hatalar En Sık Çıkar?

Erişilebilirlik denetimi, bir web sitesinin WCAG (Web Content Accessibility Guidelines) kriterlerine ne kadar uyduğunu hem otomatik araçlarla hem de elle test ederek ölçen, somut bir "uyumsuzluk listesi" üreten süreçtir. Kısa cevap şudur: tek bir araç tek başına yetmez. Otomatik tarayıcılar hataların sadece bir kısmını yakalar; geri kalanı klavye, ekran okuyucu ve gerçek kullanım testiyle ortaya çıkar. Müşterilerimizde gördüğümüz en yaygın yanılgı, "Lighthouse'da 100 aldık, erişilebiliriz" varsayımıdır. Lighthouse yüksek puan verirken sayfa, ekran okuyucu kullanan biri için fiilen kullanılamaz olabilir. Çünkü otomatik denetim makineyle ölçülebilen şeyleri (kontrast oranının sayısal değeri, bir alt niteliğinin var olup olmadığı, bir form alanının etikete bağlı olup olmadığı) ölçer; ama "bu alt metni görseli gerçekten anlatıyor mu?" ya da "bu link 'buraya tıklayın' yerine nereye gittiğini söylüyor mu?" sorularını yanıtlayamaz. Bu yüzden ciddi bir denetim, otomatik tarama + manuel test + yardımcı teknoloji denemesi olmak üzere üç katmanlıdır. Bu mantık, daha geniş çerçevesiyle web erişilebilirliğinin ne olduğunu ve nasıl sağlandığını anlatan ana rehberin pratik uygulama tarafıdır.

Denetimin neden zorunlu bir disiplin haline geldiğinin yasal bir boyutu da var. Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025'te yürürlüğe girdi; EN 301 549 teknik standardı üzerinden WCAG 2.1 AA uyumunu zorunlu kılıyor. AB'ye e-ticaret, bankacılık, e-kitap, ulaşım gibi ürün veya hizmet satan Türkiye merkezli firmalar da kapsama girebiliyor ve ihlal cezaları ülkeye göre 100.000 Euro'ya ya da yıllık cironun %4'üne kadar çıkabiliyor. Yani erişilebilirlik denetimi artık yalnızca "iyi niyet" değil, bazı firmalar için doğrudan bir uyum yükümlülüğüdür. Hedef seviye genellikle WCAG'in AA uygunluk seviyesidir: A asgari, AAA ise her sayfada tam karşılanması beklenmeyen en yüksek seviyedir; yasalar ve sektör pratiği AA'yı standart kabul eder.

Denetim için hangi araçlar ve yöntem kullanılır?

Sağlam bir denetim, kademeli bir yöntem izler. Önce hızlı ve geniş tarama yapan otomatik araçlarla bariz hataları toplarsınız, sonra makinenin asla anlayamayacağı bağlamsal sorunları elle doğrularsınız. Pratikte uyguladığımız sıralama şudur:

1. Otomatik tarayıcı (ilk geçiş): Tarayıcıya gömülü Lighthouse (Chrome DevTools), axe DevTools ve WAVE gibi araçlar sayfayı tarayıp kontrast, eksik alt metin, etiketsiz form alanı, hatalı ARIA gibi makine tarafından tespit edilebilen hataları listeler. Bunlar dakikalar içinde büyük bir hata yığınını ortaya çıkarır. İpucu: bu araçları yalnızca anasayfada değil, en kritik kullanıcı yollarında (ürün sayfası, sepet, ödeme adımları, iletişim formu, giriş ekranı) ayrı ayrı çalıştırın; çünkü çoğu ciddi hata anasayfada değil, etkileşimin yoğun olduğu derin sayfalarda çıkar.
2. Klavye-yalnız test (manuel): Fareyi bir kenara bırakıp yalnızca Tab, Shift+Tab, Enter, boşluk ve ok tuşlarıyla tüm sayfayı gezersiniz. Her etkileşimli öğeye (link, buton, form, menü) ulaşabiliyor musunuz? Odak (focus) nerede olduğu görünür mü? Sekme sırası (tab order) ekranda görsel olarak okunan sırayla aynı mı, yoksa odak sağa sola zıplıyor mu? Bir menüye ya da modal pencereye girip "tuzağa" düşmeden çıkabiliyor musunuz?
3. Ekran okuyucu testi (manuel): NVDA (Windows, ücretsiz), VoiceOver (macOS/iOS) veya TalkBack (Android) ile sayfayı dinlersiniz. Görseller anlamlı okunuyor mu, başlık yapısı (H1-H2-H3 hiyerarşisi) mantıklı mı, form alanları doğru seslendiriliyor mu, bir hata oluştuğunda kullanıcı bunu duyuyor mu? Ekran okuyucuların çoğu, sayfada gezinmek için başlıkları ve "landmark" (ana içerik, gezinme, alt bilgi) bölgelerini liste halinde sunar; bu yüzden başlık atlamaları ve eksik bölge etiketleri gerçek bir gezinme engelidir.
4. Renk ve kontrast doğrulama: WebAIM Contrast Checker gibi araçlarla metin/arka plan oranlarını WCAG eşiklerine göre ölçersiniz. Sadece düz metni değil; buton üstündeki yazıyı, görsel üstüne binen başlıkları ve "placeholder" (yer tutucu) metinlerini de kontrol edin.
5. Yakınlaştırma ve metin boyutu: Sayfayı tarayıcıdan %200 yakınlaştırdığınızda içerik bozuluyor mu, yatay kaydırma çıkıyor mu, butonlar üst üste biniyor mu, metin kutudan taşıyor mu? WCAG, %200'e kadar yakınlaştırmada içerik ve işlevin kaybolmamasını ister.

Burada altını çizmek gerekir: otomatik araçlar WCAG başarı kriterlerinin yalnızca bir bölümünü makineyle ölçebilir. "Bir link açıklayıcı mı?", "alt metni görseli gerçekten anlatıyor mu?", "okuma sırası mantıklı mı?", "hata mesajı çözüm öneriyor mu?" gibi sorular ancak bir insanın değerlendirmesiyle yanıtlanır. Bu yüzden otomatik puanı bir bitiş çizgisi değil, başlangıç noktası olarak görmek gerekir. Pratik bir uyarı daha: farklı araçlar aynı sayfada farklı sayıda hata raporlayabilir; çünkü her birinin kural seti ve yorumu biraz değişir. Doğru yaklaşım tek bir araca tapmak değil, iki otomatik aracı (örneğin axe + WAVE) birlikte kullanıp sonra manuel testle teyit etmektir.

Erişilebilirlik denetimini sayfa hızıyla birlikte ele almak da verimlidir; çünkü ikisi de yayın öncesi kontrol listesinin parçasıdır ve sık sık aynı kök nedenleri paylaşır. Core Web Vitals rehberimizde anlatılan ölçüm disipliniyle erişilebilirlik denetimi birbirini tamamlar; örneğin görsele açık width/height (veya aspect-ratio) verilmesi hem CLS'yi (Cumulative Layout Shift) hem de yakınlaştırmada bozulmayı önler. Aynı şekilde ağır JavaScript'le yapılmış sahte butonlar hem INP'yi (Interaction to Next Paint) yükseltip etkileşimi yavaşlatır hem de klavye erişilebilirliğini bozar. Yani performans iyileştirmesi ile erişilebilirlik düzeltmesi çoğu zaman aynı kodu sadeleştirmekten geçer.

WebAIM Million raporuna göre en sık çıkan hatalar neler?

WebAIM'in her yıl milyonlarca ana sayfayı taradığı "WebAIM Million" raporu, erişilebilirlik hatalarının dağılımının yıldan yıla şaşırtıcı derecede tutarlı olduğunu gösteriyor. Tespit edilen hataların büyük çoğunluğu birkaç temel başlıkta toplanıyor. İyi haber şu: bu hataların neredeyse tamamı bilinen, kolay önlenebilir ve genellikle ucuza düzeltilebilir hatalardır. Daha çarpıcı olanı, bu altı kalıbın taranan sitelerde tespit edilen hataların ezici çoğunluğunu oluşturmasıdır; yani bir sitenin erişilebilirliğini ciddi biçimde iyileştirmek için egzotik tekniklere değil, bu birkaç temel hatayı kapatmaya odaklanmak yeterlidir. Aşağıdaki tabloda en sık karşılaşılanları, kimi etkilediğini ve pratik çözümünü topladık:

Bu liste tesadüfi değildir: hepsi düzeltmesi en kolay, etkisi en büyük hatalardır. Bir başka ortak özellikleri de, hemen hepsinin tasarımın değil, kodlama/içerik disiplininin alanına girmesidir; yani çoğu zaman sitenin görünümünü hiç değiştirmeden, yalnızca HTML'i doğru yazarak çözülürler. Türkçe siteler için lang="tr" tanımı özellikle kritiktir; bu tanım hem ekran okuyucunun doğru telaffuzu için hem de tarayıcının büyük/küçük harf dönüşümünü, özellikle noktalı/noktasız "İ/ı" ayrımını doğru yapması için gereklidir. Sayfa içinde dil değişen bölümler varsa (örneğin İngilizce bir alıntı ya da yabancı bir ürün adı) o öğeye de ayrıca lang verilmesi idealdir. Aynı titizlik, doğru font seçimi ve UTF-8 kodlamasıyla birlikte düşünülmelidir; bazı popüler fontlar Türkçe karakterleri eksik destekler ve bu yalnızca estetik değil okunabilirlik sorunudur. Bu konuları daha geniş ele alan iyi web tasarımının nasıl olması gerektiği yazımız, erişilebilirliği estetikle nasıl birleştireceğinizi gösteriyor.

Tablodaki hataların çoğunun ortak kök nedeni anlamsız işaretlemedir (non-semantic markup). Bir geliştirici gerçek <button> yerine üstüne tıklama olayı eklenmiş bir <div> kullandığında; gerçek <a href> yerine JavaScript'le yönlendiren bir <span> koyduğunda; ya da görsel başlık etkisi için H2 yerine kalın yapılmış bir paragraf kullandığında, tarayıcı ve yardımcı teknolojiler o öğenin ne olduğunu anlayamaz. Erişilebilirliğin en güçlü ve en ucuz "aracı" bu yüzden ARIA değil, doğru semantik HTML'dir. ARIA (Accessible Rich Internet Applications) ancak HTML'in tek başına ifade edemediği karmaşık bileşenlerde (örneğin özel bir sekme bileşeni, açılır liste, canlı bildirim bölgesi) ve doğru kurallarla kullanılmalıdır; yanlış veya gereksiz ARIA, hiç ARIA olmamasından daha zararlıdır.

Üç kritik hata türü: kontrast, alt metin ve "sadece fare"

Pratikte denetimlerimizde en çok zaman alan ve en çok kullanıcıyı dışlayan üç hata kalıbı öne çıkar. Bunları ayrı ayrı açmakta fayda var, çünkü her biri farklı bir kullanıcı grubunu etkiler ve farklı bir çözüm mantığı ister.

1. Renk ve kontrast hatası. Tasarım trendlerinin peşinden gidip açık gri üstüne daha açık gri yazı, ya da pastel arka plana ince beyaz font koyan siteler çoktur. WCAG AA, gövde metni için arka planla en az 4.5:1, büyük metin (yaklaşık 18px kalın veya 24px normal üstü) için en az 3:1 kontrast oranı ister. Bu yalnızca görme engelliler için değil; yaşlı kullanıcılar, ucuz ekran kullananlar ve ekranı güneş altında okuyan herkes için fark yaratır. En sinsi versiyonu, marka renginin üstüne yine markaya yakın bir tonda buton yazısı koymaktır; tasarımcının ekranında "şık" görünür ama oran 3:1'in altındadır. Ek olarak kritik bir ilke: renk tek başına bilgi taşımamalıdır. "Kırmızı alanları doldurun" demek renk körü kullanıcı için anlamsızdır; rengin yanına ikon, metin veya desen eklenmelidir. Bu yüzden hata mesajlarında sadece kırmızı çerçeve değil, "Bu alan zorunludur" gibi açık bir metin de göstermek gerekir. Aynı kural grafikler, durum etiketleri ("aktif/pasif" yalnız yeşil/kırmızı nokta ile gösterilmemeli) ve link ayrımı için de geçerlidir; bir link metin içinde yalnızca renkle ayrılıyorsa, renk körü kullanıcı onu fark etmez, bu yüzden altı çizili veya başka bir görsel ipucuyla desteklenmelidir.

2. Eksik veya yanlış alt metin. Görsellerde alt metni, ekran okuyucunun görseli kullanıcıya anlatmasını sağlar. Burada iki uçtan da kaçınmak gerekir: anlam taşıyan bir görsele (ürün fotoğrafı, bilgi grafiği, açıklayıcı görsel) hiç alt metin vermemek bilgi kaybıdır; buna karşılık tamamen dekoratif bir görsele (köşe süsü, arka plan dokusu) gereksiz alt metin yazmak ekran okuyucu kullanıcısını gürültüye boğar. Doğru yaklaşım: anlamlı görsele görseli gerçekten betimleyen kısa bir alt metin, dekoratif görsele boş alt="" (atlanmasını sağlamak için). İyi bir alt metin "resim" ya da "görsel-12.jpg" değil, bağlamı yansıtan bir betimlemedir; örneğin bir e-ticaret ürün görselinde "mavi pamuklu erkek tişört, önden görünüm" demek "tişört" demekten çok daha kullanışlıdır. Görselin içinde metin varsa (kampanya banner'ı, fiyat etiketi) o metin alt içinde mutlaka tekrarlanmalıdır, aksi halde bilgi yalnızca görene ulaşır. Aynı şekilde ikon-butonlar ve ikon-linkler de "görsel" sayılır; bir çöp kutusu ikonuyla yapılmış "sil" butonu, yanında yazı yoksa, ekran okuyucuda boş buton olarak okunur ve aria-label ile anlam verilmelidir.

3. "Sadece fare" tuzağı (klavye erişilemezliği). Bu, gözle görünmeyen ama en dışlayıcı hatadır. Motor engeli olan, titremesi olan veya ekran okuyucu kullanan birçok kişi fareyi hiç kullanmaz; her şeyi klavyeyle yapar. Eğer açılır menünüz yalnızca fare üzerine gelince (hover) açılıyorsa, özel JavaScript ile yapılmış bir "buton" div'iyse ve Tab ile odaklanamıyorsa, ya da modal pencereniz Esc ile kapanmıyor ve odağı içeride tutmuyorsa, bu kullanıcılar siteyi kullanamaz. Sık karşılaşılan üç alt sorun vardır: birincisi odak tuzağı (bir bileşene girilir ama Tab ile çıkılamaz); ikincisi odak kaybı (modal açılır ama odak hâlâ arkadaki sayfadadır, ya da modal kapanınca odak boşa düşer); üçüncüsü görünmez odak (CSS ile outline:none verilip yerine hiçbir görsel ipucu konmamış olması, böylece klavye kullanıcısı nerede olduğunu göremez). Çözümün temeli anlamlı HTML'dir: gerçek <button> ve <a href> etiketleri klavye erişimini, odaklanmayı ve "Enter ile tetikleme"yi kendiliğinden getirir. WCAG 2.2 ayrıca görünür odak halkasını (focus indicator), sürükleme yerine alternatif yöntem sunmayı (SC 2.5.7) ve dokunmatik hedeflerde minimum boyutu (SC 2.5.8, en az 24x24 CSS piksel; pratikte 44-48px önerilir) da şart koşar. Pratik test çok basittir: faresiz, yalnız klavyeyle sitenizde bir formu baştan sona doldurup gönderebiliyor musunuz, açılan menüleri kullanabiliyor, modalları açıp kapatabiliyor musunuz?

Bu üç hata kalıbı, otomatik araçların yalnızca bir kısmını yakalayabildiği, asıl çözümün manuel test ve doğru kodlama disipliniyle geldiği alanlardır. Erişilebilirliği baştan tasarıma gömmek, sonradan "yamamak"tan hem çok daha ucuz hem çok daha sağlamdır. Burada bir uyarı şart: piyasada "tek satır kod ile siteni erişilebilir yap" diye pazarlanan otomatik erişilebilirlik eklentileri (overlay) vardır; bunlar çoğu zaman yapısal sorunları çözmez, hatta ekran okuyucu kullanıcılarının deneyimini bozabilir ve yasal koruma da sağlamaz. Kalıcı çözüm, hatayı kaynağında (HTML, CSS, içerik) düzeltmektir. Üstelik bu çalışmanın yan faydası büyüktür: anlamlı HTML, açıklayıcı link metinleri ve doğru başlık yapısı aynı zamanda arama motorları için de daha okunabilir bir site demektir. Erişilebilirlik ile teknik SEO bu noktada birleşir; teknik SEO denetimi rehberimiz bu örtüşmeyi ayrıntılandırıyor.

Denetim sonrası bulguları nasıl önceliklendirir, nasıl raporlarsınız?

İyi bir denetimin çıktısı uzun bir hata listesi değil, eyleme dönük bir yol haritasıdır. Onlarca bulguyu aynı anda düzeltmeye çalışmak ekibi felç eder; bunun yerine bulguları etki ve maliyetine göre sıralamak gerekir. Pratikte kullandığımız önceliklendirme mantığı şudur: en çok kullanıcıyı tamamen dışlayan, en kritik yollarda (ödeme, giriş, iletişim) bulunan ve düzeltmesi en ucuz olan hatalar önce gelir. Aşağıdaki çerçeve, bulguları gruplamak için işe yarar:

• Engelleyici (blocker): Bir kullanıcı grubunun temel görevi (satın alma, form gönderme, içeriğe ulaşma) tamamlamasını imkânsız kılan hatalar. Örnek: klavyeyle ulaşılamayan ödeme butonu, ekran okuyucuda boş kalan zorunlu form alanı. Bunlar yayın öncesinde mutlaka çözülmeli.
• Ciddi (major): Görevi zorlaştıran ama tümüyle imkânsız kılmayan hatalar. Örnek: düşük kontrastlı uyarı metni, anlamsız link metinleri, başlık hiyerarşisi atlamaları.
• Küçük (minor): Deneyimi pürüzlü kılan ama işlevi engellemeyen sorunlar. Örnek: dekoratif görsele gereksiz alt metin, fazladan ARIA.

Her bulgu raporlanırken üç şey net olmalı: hangi WCAG kriterini ihlal ettiği, hangi sayfada/öğede olduğu (ekran görüntüsü veya seçici ile) ve somut çözüm önerisi. "Kontrast düşük" demek yetmez; "ürün kartı fiyat metni gri (#999) beyaz üstünde, oran 2.8:1, AA için en az 4.5:1 gerekir, tonu #595959'a koyulaştırın" gibi uygulanabilir bir reçete verilmelidir. Bu disiplin, erişilebilirlik denetimini bir "uyumluluk damgası" olmaktan çıkarıp gerçek bir iyileştirme aracına dönüştürür. Aynı raporlama mantığı, bir sitenin sıfırdan kurulmasında da geçerlidir; nitekim web sitesi yapma adımlarını anlattığımız rehberde erişilebilirlik denetimini, yayın öncesi kontrol listesinin sökülemez bir parçası olarak ele alıyoruz.

Erişilebilirlik denetimini kim, ne sıklıkla yapmalı?

Erişilebilirlik tek seferlik bir "düzelt ve unut" işi değil, süreklilik isteyen bir kalite disiplinidir. Her yeni sayfa, her yeni bileşen, her içerik güncellemesi yeni hata getirebilir; özellikle yeni bir blog yazısında eksik alt metin, yeni bir kampanya banner'ında düşük kontrast ya da yeni bir form alanında eksik etiket çok kolay sızar. Bu yüzden hem yayın öncesi denetimi hem de düzenli aralıklarla (örneğin çeyrek dönemde bir veya büyük güncellemelerde) tekrar denetim önerilir. En sağlıklı yaklaşım, erişilebilirliği sürecin içine gömmektir: tasarım aşamasında kontrast ve hiyerarşi tasarımcının sorumluluğunda, kodlama aşamasında semantik HTML ve klavye erişimi geliştiricinin sorumluluğunda, içerik girişinde alt metin ve anlamlı link içerik editörünün sorumluluğunda olmalıdır. Tek bir kişiye "en sonda erişilebilirlik yapan kişi" rolü vermek, hatanın birikmesine yol açar.

Bunu özellikle AB'ye ürün veya hizmet satan firmalar ciddiye almalı: Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025'te yürürlüğe girdi ve EN 301 549 üzerinden WCAG 2.1 AA uyumunu zorunlu kılıyor; e-ticaret, bankacılık, e-kitap gibi alanlarda AB'ye satış yapan Türkiye merkezli firmalar da kapsama girebiliyor, piyasadaki eski hizmetler için geçiş süresi 28 Haziran 2030'a kadar tanınmış durumda. Türkiye'de özel sektör için henüz aynı sertlikte genel bir yasa olmasa da (kamu siteleri için erişilebilirlik düzenlemeleri mevcut), erişilebilirlik hem SEO hem dönüşüm hem de marka itibarı için somut fayda sağlar. Üstelik erişilebilir bir site, kişisel veri toplayan formlarda KVKK uyumuyla da örtüşür; net etiketli, anlaşılır ve hatasız bir form hem erişilebilirlik hem de açık aydınlatma açısından daha sağlamdır.

Sitenizin mevcut durumunu öğrenmek istiyorsanız, başlangıç için Lighthouse veya axe ile kendiniz hızlı bir tarama yapabilir; ardından klavye ve ekran okuyucu testleriyle bunu derinleştirebilirsiniz. Daha kapsamlı, hem erişilebilirlik hem performans hem de uyum açısından bütünsel bir değerlendirme istiyorsanız, denetim aracımızla hızlı bir başlangıç yapabilir veya ekibimizden ücretsiz site analizi talep edebilirsiniz. Erişilebilir, hızlı ve dönüşüm odaklı bir arayüzü baştan doğru kurmak için web ve mobil UI/UX tasarımı hizmetimiz tüm bu ilkeleri tasarımın merkezine alır; sonradan "erişilebilirlik yaması" yapmak yerine, en başından herkes için kullanılabilir bir site inşa etmek hem daha ekonomik hem daha kalıcıdır.