Web Erişilebilirliği 2026: WCAG 2.2 ve Kapsayıcı Tasarım Rehberi

1. Erişilebilirlik Nedir ve Neden Önemlidir

Web erişilebilirliği, en geniş tanımıyla, görme, işitme, motor veya bilişsel engelleri olan kullanıcılar başta olmak üzere her bireyin bir web sitesini bağımsız ve etkili biçimde kullanabilmesini ifade eder. Dünya Sağlık Örgütü'nün son verileri, küresel nüfusun yaklaşık %16'sının günlük yaşamını etkileyen bir engelle yaşadığını gösteriyor. Türkiye'de bu oran, geçici engelleri ve yaşlı nüfusu da hesaba kattığımızda, hizmet verdiğimiz potansiyel kitlenin yedide birine denk geliyor.

Bu rakam tek başına bile erişilebilirlik yatırımını haklı çıkarır; ancak konuyu yalnızca sayılarla ele almak meselenin özünü kaçırmak demek. Erişilebilirlik aynı zamanda geçici durumlar için de kritik: kolunu kırmış bir kullanıcı, gürültülü bir kafede video izleyen biri, gözlüğünü unutan ziyaretçi veya yaşa bağlı görme keskinliği azalan bir müşteri. Microsoft'un "Inclusive Design Toolkit" çalışması, kalıcı bir engelin yanı sıra geçici ve duruma bağlı engellerin de hesaba katılması gerektiğini vurguluyor. Bu çerçevede erişilebilir bir site, sadece engelli kullanıcılar için değil, herkes için daha kullanılabilir bir deneyim sunar.

Erişilebilirlik bir kurumsal site için neden hayati önemde? Şu açılardan değerlendirelim:

• Yasal koruma: EAA, ADA Title III ve Türkiye'deki Engelliler Kanunu ihlal davalarından kaçınma
• Marka itibarı: ESG raporlamasında yer alan sosyal sorumluluk metrikleri
• SEO performansı: Semantik HTML ve doğru başlık hiyerarşisi Google için doğrudan sinyal
• Dönüşüm oranı: Net kontrast, okunabilir tipografi ve hatasız form akışı herkesin işine yarar
• Geliştirici verimliliği: Erişilebilir kod aynı zamanda test edilebilir ve sürdürülebilir koddur

Fatih Web Tasarım olarak, Antalya'da turizm, sağlık ve perakende sektörlerine hizmet veren müşterilerimizin sitelerinde erişilebilirlik denetimini proje süreçlerimizin standart parçası haline getirdik. Tek bir denetim raporu değil, geliştirme sürecinde her sprint kapanışında otomatik aksiyonlarla işletilen sürekli bir kalite hattı kuruyoruz.

2. WCAG 2.2 AA Standartları

Web Content Accessibility Guidelines (WCAG), W3C tarafından yayımlanan ve dünya genelinde fiili standart olarak kabul edilen erişilebilirlik rehberidir. WCAG 2.2, Ekim 2023'te yayımlandı ve 2.1 sürümüne dokuz yeni başarı kriteri ekledi. 2026 itibarıyla, sektörel beklenti AA seviyesinde uyumdur; AAA seviyesi devlet ve eğitim kurumları gibi hassas alanlar için tercih edilir.

WCAG dört temel ilke (POUR) etrafında örgütlenir:

• Perceivable (Algılanabilir): İçerik kullanıcının duyularıyla algılanabilir olmalı (alt metin, transkript, kontrast)
• Operable (Çalıştırılabilir): Arayüz farklı giriş yöntemleriyle kullanılabilir olmalı (klavye, ses, yardımcı teknoloji)
• Understandable (Anlaşılabilir): İçerik ve işleyiş öngörülebilir ve net olmalı
• Robust (Sağlam): Mevcut ve gelecek yardımcı teknolojilerle uyumlu olmalı

WCAG 2.2'nin AA seviyesi için karşılanması gereken bazı kritik başarı kriterleri şunlardır: 1.4.3 metin kontrast oranı (4.5:1), 1.4.11 görsel olmayan unsurlar için kontrast (3:1), 2.1.1 klavye erişilebilirliği, 2.4.7 odak görünürlüğü, 2.4.11 odak engellenmemesi (2.2 ile yeni gelen), 2.5.7 sürükle bırak alternatifi (yeni), 2.5.8 hedef boyutu (yeni, minimum 24×24 piksel), 3.3.7 yedek kimlik doğrulama (yeni) ve 3.3.8 erişilebilir kimlik doğrulama (yeni).

Özellikle 2.2 sürümü ile gelen hedef boyutu kriteri, mobil arayüzlerde önemli bir kırılma noktası oldu. 24×24 piksel minimum dokunma alanı, modern tasarım dilinde önerilen 44×44 piksel (Apple HIG) ve 48×48 piksel (Material Design) değerlerinin altında kalsa da, sıkışık tablo arayüzlerinde ve yoğun veri ekranlarında kritik bir alt sınır oluşturuyor.

Bir başka önemli yenilik, 2.4.13 odak görünümü kriteridir. AAA seviyesindeki bu kriter, odak göstergesinin etrafının kalınlığını ve kontrastını net şartlara bağlıyor: en az 2 CSS pikseli kalınlık ve 3:1 kontrast oranı. Bu kriter, fokus halkalarını dekoratif amaçla kaldıran modern tasarımlara açık bir uyarıdır.

3. Klavye Gezintisi ve Odak Yönetimi

Klavye gezintisi, motor engelli kullanıcılar başta olmak üzere fareyi kullanamayan veya kullanmak istemeyen herkes için temel etkileşim yöntemidir. WCAG'in 2.1.1 başarı kriteri, tüm işlevlerin sadece klavye ile yapılabilmesini şart koşar. Ne yazık ki bu kriter, kendi sitelerinde test yapan ekiplerin en sık atladığı kontrol noktasıdır.

Doğru klavye desteği sağlamak için karşılanması gereken pratik şartlar:

• Tüm etkileşimli unsurlar (link, buton, form alanı, açılır menü) Tab tuşu ile dolaşılabilmeli
• Odak sırası DOM sırasını ve görsel mantığı takip etmeli
• Açılan modal pencereler odağı içeride tuzaklamalı (focus trap) ve kapatıldığında çağıran öğeye geri vermeli
• Klavye ile açılmış menüler Esc tuşu ile kapanabilmeli
• Tablo ve veri ızgaralarında ok tuşları ile yatay-dikey hareket desteklenmeli
• Görünmez "skip to content" linki ana içeriğe hızlı erişim sağlamalı

Odak göstergesi (focus indicator) tartışmasız en önemli görsel sözleşmedir. Maalesef outline: none ile odak halkasını silmek, tasarımcı ekiplerin en sık yaptığı erişilebilirlik hatası. Bunun yerine, marka kimliğinize uygun özelleştirilmiş bir odak halkası tasarlamak çok daha doğru bir yaklaşımdır. Modern CSS, bu konuda :focus-visible sözde sınıfı ile incelikli bir çözüm sunar: fare ile tıklamada halka gizlenirken klavye odağında belirir.

Skip linkleri, klavye kullanıcılarının her sayfada onlarca menü öğesinden geçmek zorunda kalmaması için hayati öneme sahip. Standart uygulamada sayfanın en başında, normalde görünmeyen ancak Tab'a basıldığında belirginleşen "İçeriğe Atla" linki bulunur. Bu link doğrudan main elementine veya #main-content id'sine atlar.

Pratik bir test: bilgisayarınızın faresini fiziksel olarak prizden çekin ve sitenizi sadece Tab, Shift+Tab, Enter, Space ve ok tuşları ile kullanmayı deneyin. Eğer bir mega menüde sıkıştığınız, bir modalı kapatamadığınız ya da odak göstergesini görmediğiniz an gelirse, gerçek kullanıcılarınızın da aynı sorunu yaşadığından emin olabilirsiniz.

4. Ekran Okuyucu Uyumu

Ekran okuyucular, görme engelli kullanıcıların web içeriğine erişiminin temel aracıdır. Türkiye'de en yaygın kullanılanlar Windows için ücretsiz NVDA ve ücretli JAWS; macOS ve iOS için sistemle gelen VoiceOver; Android için TalkBack. Bu araçlar HTML yapısını dinleyerek kullanıcıya seslendirir; ne kadar doğru kod yazdığınız doğrudan kullanıcı deneyimini belirler.

Ekran okuyucu dostu bir sitenin temel kuralları:

• Her sayfanın benzersiz ve açıklayıcı bir <title> etiketi olmalı
• Görsellerin alt metni içeriği özetlemeli; dekoratif görseller alt="" ile boş bırakılmalı
• Başlık hiyerarşisi (H1, H2, H3) atlamadan ilerlemeli (H1'den H3'e zıplama hatadır)
• Link metinleri "buraya tıklayın" yerine içeriği anlatmalı ("Erişilebilirlik rehberini indirin")
• Tablolarda <th scope="col"> ve <caption> kullanılmalı
• Sayfanın dili <html lang="tr"> ile belirtilmeli

Bir ekran okuyucu kullanıcısı sayfayı doğrudan baştan sona dinlemek zorunda değildir; başlıklar arasında atlayabilir, linkler arasında dolaşabilir, form alanlarına direkt geçebilir. Bunun için sayfa yapısının semantik olarak doğru kodlanması şarttır. Yanlış kullanılan başlıklar, semantiksiz <div> yığınları ve eksik etiketler, ekran okuyucu kullanıcısının site içinde kaybolmasına neden olur.

Dinamik içerik bildirimi de kritik bir başlık. Bir AJAX işlem tamamlandığında, bir form gönderildiğinde ya da bir hata mesajı belirdiğinde, ekran okuyucunun bunu kullanıcıya duyurması gerekir. Bu, ARIA live regions ile sağlanır: aria-live="polite" ile yumuşak bildirim, aria-live="assertive" ile acil duyuru. E-ticaret sitelerinde "Sepete eklendi" mesajı, banka uygulamalarında "İşleminiz başarısız" uyarısı tipik kullanım örnekleridir.

Test pratiği önemli: sitenizi açık bir ekran okuyucu ile kullanmayı bizzat deneyin. NVDA Windows üzerinde ücretsizdir ve 15 dakikalık alıştırmadan sonra temel kullanımı öğrenebilirsiniz. macOS kullanıcıları Cmd+F5 ile VoiceOver'ı anında açabilir. Bu deneyim, sitenizin dinleme açısından nasıl algılandığını görmenizi sağlar.

5. Renk, Kontrast ve Görsel Hiyerarşi

Renk körlüğü ve düşük görme keskinliği, Türkiye nüfusunda yaklaşık her on iki erkekten birini, kadınlarda ise yüzde birden az bir oranı etkiler. Yaşa bağlı görme bozuklukları ise 60 yaş üstü nüfusun büyük çoğunluğunu etkiler. WCAG 1.4.3 başarı kriteri, normal metin için 4.5:1, büyük metin (18 punto veya 14 punto bold) için 3:1 minimum kontrast oranını şart koşar.

Kontrast denetimini geçen bir tasarım için pratik kurallar:

• Açık gri (#999) üstüne beyaz metin asla kullanılmamalı (kontrast oranı 2.85:1)
• Marka renginin metin olarak kullanılması mutlaka denetlenmeli
• Buton arka planı ile buton metni arasında en az 4.5:1 kontrast olmalı
• Hover ve focus durumları kontrast bakımından da değişebilmeli
• Form hata mesajları sadece kırmızı renk ile değil, ikon ve metinle de işaretlenmeli

WebAIM Contrast Checker en yaygın kullanılan ücretsiz denetim aracıdır. Figma ve Sketch tarafında ise Stark, Contrast ve Able gibi eklentiler tasarım aşamasında kontrast hatalarını yakalar; bu kaymanın geliştirme aşamasından önce yapılması maliyeti büyük ölçüde düşürür.

Görsel hiyerarşinin sadece renge dayanmaması gerekir; bu WCAG 1.4.1 başarı kriterinin (renk kullanımı) özüdür. Form alanı zorunlu ise sadece kırmızı yıldız değil, "(zorunlu)" yazısı da eklenmeli; bir tabloda olumlu satırlar yeşille belirtiliyorsa "Başarılı" gibi bir metin etiketi de bulunmalı. Bu yaklaşım sadece renk körü kullanıcılara değil, monokrom ekran kullananlara ve baskıya alanlara da fayda sağlar.

Karanlık mod desteği de görme rahatlığı açısından önemli bir başlık. prefers-color-scheme medya sorgusu ile kullanıcı tercihini yakalamak ve bir karanlık tema sunmak, OLED ekranlarda enerji tasarrufu da sağlar. Ancak karanlık modda kontrast denetimini yeniden yapmak gerekir; aynı renk paleti her iki modda aynı erişilebilirlik seviyesini garanti etmez.

6. Semantik HTML ve Doğru İskelet

Semantik HTML, erişilebilirliğin temelidir. HTML5 ile gelen <header>, <nav>, <main>, <article>, <section>, <aside>, <footer> gibi etiketler, tarayıcıya ve yardımcı teknolojilere içeriğin yapısı hakkında zengin bilgi verir. Bu etiketler doğru kullanıldığında, ARIA rolleri eklemeye çoğunlukla gerek kalmaz.

Yaygın olarak yanlış kullanılan veya eksik bırakılan örnekler:

• Tüm sayfayı <div> yığınları ile oluşturmak (modern Tailwind projelerinde sık görülen problem)
• Buton işlevi gören <span> veya <a> kullanmak (gerçek <button> yerine)
• Birden fazla <main> elementi kullanmak (sayfada sadece bir tane olmalı)
• Liste içeriğini <br> ile ayırmak (<ul> ve <li> yerine)
• Resim yerine arka plan görseli kullanıp alt imkânını kaybetmek

Modern React, Vue veya Svelte projelerinde semantik HTML üretmek için disiplinli olmak gerekir. JSX yazarken <div onClick={...}> şeklinde buton işlevi vermek hızlı bir çözüm gibi görünse de, hem klavye erişilebilirliğini hem ekran okuyucu uyumunu mahveder. MDN HTML Element Reference her zaman başucu kaynağı olmalıdır.

Landmark bölgeleri, ekran okuyucu kullanıcısının sayfada hızlı gezinmesini sağlar. <header> banner rolü, <nav> navigation rolü, <main> main rolü, <footer> contentinfo rolü üstlenir. Birden fazla aynı tip landmark varsa (örneğin iki <nav>), her birine aria-label ile ayırt edici isim vermek gerekir: <nav aria-label="Ana menü"> ve <nav aria-label="Altbilgi linkleri">.

Başlık hiyerarşisi (heading outline) bir sitenin "iskeletidir". Sayfada bir tane H1 olmalı; H2'ler ana bölümleri, H3'ler alt bölümleri belirtmeli. Atlama yapmadan, içerik hiyerarşisini takip ederek ilerlemeli. Bu hem ekran okuyucu kullanıcısının sayfa içinde gezinmesi hem de Google'ın içeriği doğru anlaması için kritik.

7. ARIA Rolleri ve Özellikleri

WAI-ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications), HTML'in semantik olarak ifade edemediği durumları yardımcı teknolojilere bildirmek için W3C tarafından geliştirilmiş bir sözlük. Modern, etkileşimli web uygulamalarında — özellikle React ile yapılmış SPA'larda — ARIA olmadan tam erişilebilirlik mümkün değildir. Ancak ARIA'nın altın kuralı şudur: kötü ARIA hiç ARIA olmamasından kötüdür.

Sık kullanılan ARIA rollerinden bazıları:

• role="button": Buton işlevi gören özel elementler için (gerçek <button> tercih edilir)
• role="dialog": Modal pencereler için
• role="alert": Anında bildirim verilmesi gereken mesajlar
• role="navigation": Navigasyon bölgeleri (HTML5 <nav> tercih edilir)
• role="tablist", role="tab", role="tabpanel": Tab arayüzleri
• role="combobox": Otomatik tamamlamalı arama kutuları

Sık kullanılan ARIA özellikleri ise daha incelikli bir kontrol sağlar: aria-label görünür etiket olmadığında erişilebilir isim verir; aria-labelledby başka bir elementin metnini etiket olarak referans alır; aria-describedby ek açıklama bağlar; aria-expanded bir açılır menünün durumunu bildirir; aria-hidden bir elementi ekran okuyuculardan gizler; aria-current="page" aktif navigasyon öğesini belirtir.

Tipik bir mobil hamburger menü örneği üzerinden gidelim. Doğru ARIA kullanımı şöyle olur:

• Buton: <button aria-label="Ana menüyü aç" aria-expanded="false" aria-controls="main-menu">
• Açıldığında aria-expanded="true" olarak güncellenir
• Menü: <nav id="main-menu" aria-label="Ana menü">
• Aktif sayfa linki: <a href="..." aria-current="page">

ARIA'nın çıktısını test etmek için Chrome DevTools Accessibility panelinde "Accessibility Tree"yi açın. Bu, ekran okuyucunun gördüğü ağaç yapıdır. Eğer beklediğiniz erişilebilir isim ve rolleri burada görmüyorsanız, ARIA implementasyonunuzda eksik vardır.

8. Form Etiketleri ve Hata Yönetimi

Formlar, kurumsal sitelerin dönüşüm kapısıdır; iletişim formundan ürün siparişine, randevu rezervasyonundan müşteri girişine kadar tüm kritik etkileşimler burada gerçekleşir. Erişilebilirlik açısından formlar aynı zamanda en sık hatanın yapıldığı alandır. WCAG, formlarla ilgili birkaç başarı kriteri içerir: 1.3.1 bilgi ve ilişkiler, 2.4.6 başlık ve etiketler, 3.3.1 hata tespiti, 3.3.2 etiket ve talimatlar, 3.3.3 hata önerisi, 3.3.4 hata önleme.

Erişilebilir bir formun temel kuralları:

• Her form alanının görünür bir etiketi olmalı (<label for="..."> ile <input id="..."> bağlantılı)
• Placeholder etiket yerine kullanılmamalı (girdi yapıldığında etiket kaybolur)
• Zorunlu alanlar required attribute ile ve görsel bir işaretle belirtilmeli
• Hata mesajları aria-describedby ile alanla ilişkilendirilmeli
• Hata durumu aria-invalid="true" ile bildirilmeli
• Gönderme sonrası hatalar bir bölge üstte özetlenmeli ve odak buraya verilmeli
• Otomatik tamamlama için autocomplete attribute doğru değerle ayarlanmalı

Şu noktada modern tasarımda sık görülen bir hatadan bahsetmek gerek: floating labels. Tasarım dergilerinde popüler olan bu yaklaşımda etiket, kullanıcı yazmaya başladığında küçülerek alanın üstüne kayar. Doğru uygulanmazsa, etiket küçüldüğünde okunamaz hale gelir ya da kontrast oranı düşer. WCAG 1.4.3'ün gerektirdiği 4.5:1 kontrast, küçük etiket halinde de korunmalıdır.

Otomatik tamamlama (autocomplete) attribute'u, motor engelli kullanıcılar için büyük kolaylık. Bir adres formunda autocomplete="given-name", autocomplete="family-name", autocomplete="email", autocomplete="tel", autocomplete="postal-code" gibi standart değerler kullanmak, tarayıcının kayıtlı bilgileri tek tıkla doldurmasını sağlar. WCAG 1.3.5 başarı kriteri AA seviyesinde bu attribute'u zorunlu tutar.

Hata mesajlarının yönetimi de incelikli bir başlıktır. Hata sadece form gönderildikten sonra mı, yoksa kullanıcı alandan ayrılır ayrılmaz mı gösterilmeli? Genel kabul, ikinci yaklaşımdır (real-time validation), ancak hata mesajı yazarken kullanıcıyı paniğe sevk etmeden ne yapacağını açıkça söylemelidir: "Geçerli bir e-posta giriniz" yerine "E-posta adresi @ işareti içermelidir" gibi spesifik bir yönlendirme her zaman daha iyidir.

9. Otomatik Denetim Araçları

Otomatik denetim araçları, erişilebilirlik sorunlarının yaklaşık %30-40'ını yakalar; kalan %60-70 manuel test gerektirir. Bu sınırlama anlaşıldığında, otomatik araçlar yine de büyük değer üretir: hızlı geri bildirim, sürüm öncesi regresyon yakalama ve takım içi farkındalık yaratma açısından.

2026 itibarıyla en yaygın kullanılan denetim araçları şunlar:

• axe DevTools: Deque'nin Chrome ve Firefox eklentisi; geliştirici dostu, ayrıntılı raporlama ile sektör standardı
• Pa11y: Komut satırı tabanlı denetim aracı; CI/CD süreçlerine entegre edilmesi kolay
• Lighthouse: Chrome DevTools'a entegre, sayfa düzeyinde hızlı denetim, Core Web Vitals ile birlikte erişilebilirlik puanı verir
• WAVE: WebAIM'in tarayıcı eklentisi; görsel olarak sayfayı hata ikonları ile işaretler
• Microsoft Accessibility Insights: Manuel test ile otomatik testi birleştiren rehber
• Storybook a11y addon: Bileşen seviyesinde geliştirme aşamasında erişilebilirlik denetimi

axe-core kütüphanesi, hemen hemen tüm bu araçların altında çalışır. Modern bir projede, axe-core'u doğrudan JavaScript ile entegre etmek ve unit testlerde Jest ya da Playwright ile çalıştırmak en iyi pratiktir. Böylece her pull request'te otomatik denetim yapılır ve regresyonlar engellenir.

Pa11y CI yapılandırmasını GitHub Actions ile birleştirerek her commit'te belirli URL'lerin denetimini otomatik tetiklemek pratik bir yaklaşım. Aşağıdaki gibi bir .pa11yci yapılandırması ile başlangıç projeniz birkaç dakika içinde kurulur:

• Standart: WCAG2AA (varsayılan)
• İgnore: Bilinen ve kabul edilen istisnaları listele
• Threshold: Maksimum kabul edilen hata sayısı (idealde sıfır)
• Reporter: cli, json, csv veya html formatlarında çıktı

Otomatik araçların yakalayamadığı kategoriler de var: alt metnin gerçekten içeriği anlatıp anlatmadığı, link metninin anlamlı olup olmadığı, klavye gezintisinin mantıklı sırada gidip gitmediği, ekran okuyucu deneyiminin akışkan olup olmadığı. Bu nedenle otomatik araç + manuel test + gerçek kullanıcı testi şeklinde üç katmanlı bir kalite stratejisi uygulamak gerekir. Bizler proje takvimimizde her sürüm öncesi NVDA ile bir test seansı planlıyoruz; bu seansın 30 dakikası, sonraki üç ayda yaşayacağımız onlarca sorunu önlüyor.

10. KVKK, EAA ve Yasal Bağlam

2026 itibarıyla web erişilebilirliği artık sadece bir kalite tercihi değil, çoğu sektör için yasal bir zorunluluk. Yasal çerçeve hızlı değişiyor ve uluslararası şirketler için birden fazla yargı yetkisinde uyum sağlanmasını gerektiriyor.

Avrupa Birliği'nde Avrupa Erişilebilirlik Yasası (EAA) 28 Haziran 2025 itibarıyla yürürlüğe girdi. AB üye ülkelerinde tüketicilere sunulan e-ticaret platformları, bankacılık hizmetleri, e-kitap, yolcu taşımacılığı bilet sistemleri, akıllı TV'ler ve çağrı merkezleri kapsama dahil. AB pazarında satış yapan Türk firmaları da bu kapsama girer. WCAG 2.1 AA seviyesi minimum şart, çoğu üye devlet 2.2 AA'yı önerdi.

ABD'de Americans with Disabilities Act (ADA) Title III, web sitelerini kamuya açık yerler kapsamında değerlendirir. Son yıllarda erişilebilirlik temelli davaların sayısı yıllık 4,500'ü aştı; toplu davaların ortalama tazminat değeri 25-75 bin USD bandında. ABD pazarına hizmet veren her Türk firmasının bu riski ciddiye alması gerekir.

Türkiye'de ise yasal çerçeve şu unsurlardan oluşur:

• 5378 sayılı Engelliler Kanunu: Kamu hizmetlerinin erişilebilirliğini düzenler; özel sektör için doğrudan zorunluluk içermese de denetim riski oluşturur
• KVKK: Açık ve anlaşılır aydınlatma metni şartı, erişilebilir form tasarımıyla doğrudan ilintilidir
• TS EN 301 549: Türk Standardları Enstitüsü tarafından kabul edilmiş Avrupa standardı; kamu alımlarında zorunlu tutulmaya başlandı
• e-Devlet uyumluluk şartları: Kamu kurumlarına entegre olan tüm uygulamalar için belirli erişilebilirlik kriterleri

Kapsamlı bir yasal koruma için iki belge öneriyoruz: bir erişilebilirlik beyanı (accessibility statement) sitenizde yayımlanmalı; bu belge mevcut uyum seviyesini, bilinen istisnaları ve geri bildirim kanalını içerir. Ayrıca, ciddi projeler için bağımsız bir VPAT (Voluntary Product Accessibility Template) raporu, kamu ihalelerinde ve büyük kurumsal müşterilerle yapılan sözleşmelerde fark yaratan bir dokümandır.

11. Kapsayıcı Tasarım (Inclusive Design)

Kapsayıcı tasarım (inclusive design), erişilebilirliğin felsefi ve yöntemsel üst kümesidir. Erişilebilirlik bir hedefse, kapsayıcı tasarım bu hedefe ulaşmanın yoludur. Microsoft, Inclusive Design Toolkit ile şu prensipleri öne çıkardı: bir kişinin dışlandığı durumu tanı, farklılıktan dersler çıkar, herkese fayda sağlayan çözümler tasarla.

Kapsayıcı tasarımın somut uygulama alanları:

• Dil sadeliği: B1 seviyesi (CEFR) okuma kolaylığı, jargonu açıklamayla destekleme
• Bilişsel yük yönetimi: Sayfa başına az ana eylem, sıralı bilgi sunumu, mola noktaları
• Nöro-çeşitlilik desteği: Disleksi dostu fontlar, otizm spektrumundaki kullanıcılar için aşırı uyaran azaltma
• Çoklu giriş yöntemleri: Klavye, ses, dokunma, göz takibi (eye tracking)
• Bağlam farkındalığı: Yavaş bağlantıda, küçük ekranda, sesli ortamda kullanım senaryoları

Disleksi spektrumundaki kullanıcılar için yapılan araştırmalar gösteriyor ki satır aralığı (1.5+) ve satır uzunluğu (45-75 karakter) okuma performansını doğrudan etkiler. line-height: 1.6 ve max-width: 70ch gibi basit CSS ayarları milyonlarca kullanıcının okuma deneyimini iyileştirir. Bu örnek tipiktir: kapsayıcı tasarım uygulamaları, çoğu zaman ek geliştirme süresi gerektirmeden mevcut kararları daha bilinçli almakla başarılabilir.

Yapay zekâ destekli erişilebilirlik özellikleri, 2026'nın hızla büyüyen alanı. Otomatik alt metin üretimi (Microsoft Azure Computer Vision, Google Cloud Vision), gerçek zamanlı altyazı (Otter.ai, MS Live Captions), basitleştirilmiş okuma (Reader Mode + AI), sesli açıklama üretimi gibi servisler API olarak kolayca entegre edilebiliyor. Ancak bu otomasyonların hiçbiri editör onayının yerine geçmez; AI tarafından üretilen alt metin, insan denetiminden geçirilmelidir.

Antalya'da turizm sektöründe çalıştığımız bir butik otel projesinde, sitenin tasarımına başlamadan önce farklı engel profillerinden beş ziyaretçi ile yapılan kullanıcı görüşmeleri, mimariyi şekillendirdi: tek tıkla erişilebilir rezervasyon formu, görsel olmadan anlaşılabilen oda açıklamaları, sesli telefon CTA'sı, klavye ile gezilebilir galeri. Bu tasarım kararları sayesinde sitenin dönüşüm oranı, önceki sürüme göre %28 artış gösterdi. Erişilebilirlik bir yatırım; getirisi ise herkesin kazandığı bir deneyim.

Sonuç: Erişilebilirlik Bir Disiplindir

Web erişilebilirliği 2026'da artık bir niş konu değil; yasal, etik ve ticari boyutlarıyla kurumsal web stratejisinin merkezindeki bir disiplin. WCAG 2.2 AA seviyesi uyum minimum şart; gerçek değer ise bu standardın üstüne kapsayıcı tasarım felsefesini eklemekten geliyor.

Fatih Web Tasarım olarak, Antalya merkezli ekibimizle Türkiye'nin her bölgesine kurumsal web tasarım, e-ticaret ve özel yazılım hizmetleri sunuyoruz. Her projemizde erişilebilirlik denetimini sürecin standart parçası olarak kuruyoruz: tasarım aşamasında kontrast ve hiyerarşi kontrolü, geliştirme aşamasında axe ve Pa11y entegrasyonu, yayın öncesi manuel ekran okuyucu testi. Sitenizin WCAG 2.2 AA uyum seviyesini ücretsiz ölçmek ve uyum yol haritası talep etmek için 0543 123 4567 numaralı telefondan ya da iletişim formumuz üzerinden bize ulaşabilirsiniz.