Ekran Okuyucular Açıklanıyor: Görme Engelli Kullanıcılar Webde Nasıl Gezinir?

Dünya genelinde tahminen 36 milyon kör insan var ve yaklaşık 217 milyon kişi daha orta ila ileri düzey görme bozukluğu ile yaşıyor. Yine de 2025’te web sitelerinin %96’sından fazlasında hâlâ en az bir tespit edilebilir erişilebilirlik hatası bulunuyor. Ekran okuyucuya güvenen kör bir kullanıcı için tek bir eksik etiket, bozuk bir başlık hiyerarşisi veya erişilemez bir CAPTCHA, bir görevi bağımsız olarak tamamlamakla sitenizi tamamen terk etmek arasındaki farkı yaratabilir. Ekran okuyucuların gerçekte nasıl çalıştığını — sadece teoride değil, pratikte — anlamak, erişilebilir bir web inşa etmenin temelidir.

Ekran Okuyucu Nedir ve Kimler Kullanır?

Ekran okuyucu, ekrandaki içeriği yapay konuşmaya veya yenilenebilir braille çıktısına dönüştüren yardımcı teknoloji yazılımıdır. Sadece metni sesli okumak yerine, ekran okuyucular arayüz öğelerinin yapısını, rollerini, durumlarını ve ilişkilerini yorumlayarak kullanıcılara bir web sayfasını görsel sunuma güvenmeden kapsamlı biçimde anlamalarını sağlar. Bunu bir anlatıcıdan çok, tüm görsel arayüzünüzü sesli veya dokunsal bir bilgi akışına çeviren akıllı bir tercüman gibi düşünün.

Ekran okuyucular ağırlıklı olarak kör veya az gören kişiler tarafından kullanılır, ancak belirli bilişsel veya okuma engelleri olan kullanıcıları da destekler. WebAIM’in 2023 sonlarında gerçekleştirilen ve Şubat 2024’te yayımlanan 10. Ekran Okuyucu Kullanıcı Anketi’ne göre ekran okuyucu kullanıcılarının neredeyse %77’si kör kişilerden oluşuyor; bunu neredeyse %20 ile az gören veya diğer görme bozuklukları olan kişiler izliyor. İşitme kaybı, bilişsel engeller ve motor engeller geri kalan kısmı oluşturuyor. Bu, niş bir kitle değil: ABD’li yetişkinlerin %4,9’unda körlük veya ciddi görme zorluğu içeren bir görme engeli var ve küresel ölçekte görme engelli kullanıcı sayısı yüz milyonlarla ifade ediliyor.

Şunu da belirtmek gerekir ki ekran okuyucu kullanıcıları tek tip bir grup değildir. Araştırmalar, beceriler, tercihler, gezinme stratejileri ve sorun giderme yaklaşımlarında geniş bir çeşitlilik olduğunu sürekli gösteriyor. Doğuştan kör olan ve yirmi yıldır JAWS kullanan bir kullanıcı, yakın zamanda görme yetisini kaybetmiş ve hâlâ yardımcı teknolojiyi öğrenmekte olan birinden çok farklı şekilde gezinir. Teknik olarak erişilebilir web siteleri bile, gerektirdikleri zihinsel modeller kullanıcı beklentileriyle uyuşmadığında ciddi zorluklar yaratabilir. Tasarımcılar ve geliştiriciler, tek bir arketipsel ekran okuyucu kullanıcısı hayal etme dürtüsüne karşı koymalıdır.

Ekran Okuyucular Gerçekte Nasıl Çalışır: Erişilebilirlik Ağacı

Ekran okuyucuları gerçekten anlamak için, neyi okuduklarını anlamanız gerekir — ve bu, görsel yerleşiminiz değildir. Ekran okuyucular, tarayıcının HTML DOM’dan oluşturduğu sayfanın yapılandırılmış bir temsili olan erişilebilirlik ağacına erişerek çalışır. Tarayıcı bu ağacı platforma özgü erişilebilirlik API’leri aracılığıyla sunar: Windows’ta UI Automation, macOS’ta NSAccessibility ve Android’de AccessibilityService. Ekran okuyucu bu API’yi sorgular, her öğe hakkında anlamsal bilgi alır ve bunu konuşma veya braille çıktısına dönüştürür.

Bu durumun kritik bir sonucu vardır: ekranda gördüğünüz şey ile ekran okuyucunun algıladığı şey radikal biçimde farklı olabilir. Görsel tasarımınız bir <div> öğesini düğme gibi görünecek şekilde stillendiriyorsa, ekran okuyucu bunu düğme olarak anons etmez — çünkü erişilebilirlik ağacında düğme rolü yoktur. Ekran okuyucu, piksellerin gösterdiğini değil, kodun söylediğini anons eder. <button>, <nav>, <h1> ve <form> gibi anlamsal HTML öğeleri, erişilebilirlik ağacına otomatik olarak yansıtılan yerleşik rollere sahiptir. Geliştiriciler bunları atlayıp ARIA rolleriyle yamalanmış genel öğeleri tercih ettiklerinde gereksiz karmaşıklık yaratır ve sıklıkla yeni hatalar eklerler.

Ekran okuyucular ayrıca ekranda görünmeyen bağlam da sağlar. Kullanıcı bir listeyle karşılaştığında, ekran okuyucu listenin kaç öğe içerdiğini anons eder. Bir tabloya gelindiğinde, satır ve sütun sayısını bildirir. Odak bir form alanına geçtiğinde, alanın etiketini, türünü ve mevcut durumunu okur. Bu bağlamsal meta veriler bütünüyle iyi yapılandırılmış, anlamsal HTML’ye bağlıdır. Bunu ortadan kaldırırsanız, kullanıcının neyle karşı karşıya olduğunu anlama yetisini de ortadan kaldırırsınız.

Başlıca Ekran Okuyucular: JAWS, NVDA, VoiceOver ve TalkBack

Ekran okuyucu pazarına, her biri kendine özgü özelliklere sahip birkaç araç hakimdir. Kullanıcılarınızın hangi araçlara güvenme olasılığının yüksek olduğunu anlamak, sitenizi nasıl test etmeniz gerektiğini doğrudan belirler.

JAWS (Job Access With Speech), Freedom Scientific tarafından geliştirilmiş ve ilk kez 1995’te yayımlanmış olup özellikle kurumsal kullanımda uzun süredir sektör standardı olarak kabul edilir. WebAIM 2024 anketinde JAWS, katılımcıların yaklaşık %41’i için birincil ekran okuyucuydu. Yıllık lisans maliyeti 90 $ ile 1.400 $’ın üzerinde değişen ticari bir üründür. JAWS, kapsamlı özelleştirme seçenekleri, Microsoft Office ve profesyonel uygulamalardaki karmaşık iş akışlarıyla güçlü uyumluluk ve kullanıcıların sezgisel tuş vuruşlarıyla başlıklar, işaret bölgeleri ve form alanları arasında atlamasına olanak tanıyan, sayfayı gezilebilir, doğrusal bir ortama dönüştüren “Browse Mode” sunar.

NVDA (NonVisual Desktop Access), NV Access tarafından geliştirilmiş ve 2006’da tanıtılmış, Windows için ücretsiz ve açık kaynaklı bir ekran okuyucudur. 2024 WebAIM anketinde katılımcıların yaklaşık %38’i için birincil ekran okuyucuydu — JAWS ile neredeyse aynı. NVDA, ücretsiz modeli, sık güncellemeleri ve güçlü performansı sayesinde önemli ölçüde popülerlik kazanmıştır. 2025’te NVDA, tek sayfa uygulamalarda odak yönetimiyle ilgili geliştirilmiş bir işleyiş sunarak kullanıcıların içeriğin ne zaman değiştiğini ve odağın nereye taşındığını anlamasına yardımcı oldu. Önerilen tarayıcı eşleştirmesi Firefox’tur, ancak Chrome desteği de güçlüdür.

VoiceOver, Apple’ın macOS, iOS ve iPadOS’te yerleşik olarak sunduğu ekran okuyucudur — kurulum gerektirmez. Masaüstünde VO değiştiricisi (Control + Option) ile klavye kısayolları kullanırken, iOS’ta kaydırma, çift dokunma ve rotor gibi dokunma hareketlerine dayanır. Mobil cihazlarda VoiceOver en yaygın kullanılan ekran okuyucudur; mobil ekran okuyucu kullanıcılarının %70,6’sı ona güvenmektedir. VoiceOver, macOS/iOS erişilebilirlik API’lerini tam olarak VoiceOver’a sunan tek tarayıcı olan Safari ile eşleştirildiğinde en iyi şekilde çalışır.

TalkBack, Android’in yerleşik ekran okuyucusudur ve kullanıcıların cihazlarında gezinmesine yardımcı olmak için sesli geri bildirim ve titreşimler sunar. Android mobil testleri için standart araçtır ve Chrome ile en iyi şekilde eşleşir. Windows ayrıca, yıllar içinde istikrarlı biçimde gelişmiş ancak hâlâ JAWS ve NVDA’nın bazı özelliklerinden yoksun olan yerleşik bir ekran okuyucu olan Narrator ile birlikte gelir. Bu araçların her biri biraz farklı davranır — NVDA’da doğru çalışan bir desen JAWS’ta başarısız olabilir — bu nedenle ciddi bir erişilebilirlik programı için birden fazla ekran okuyucuda test yapmak zorunludur.

Kör Kullanıcılar Gerçekte Nasıl Gezinir: Her Şeyi Değiştiren Zihinsel Model

Geliştiricilerin çalışmalarını düşünme biçimini en temelden değiştiren içgörü şudur: ekran okuyucu kullanıcıları sayfaları yukarıdan aşağıya doğrusal olarak okumaz. Tıpkı gören bir kullanıcının görsel olarak göz gezdirmesi gibi, içeriği verimli biçimde taramak ve atlamak için sofistike bir gezinme stratejileri seti kullanırlar. Bu stratejileri desteklemezseniz, teknik olarak erişilebilir bir sayfa bile yorucu ve kullanılamaz bir deneyime dönüşür.

En yaygın gezinme stratejisi başlıklarla gezinmedir. Bilgi bulmak için başlık kullanımının zaman içinde arttığı ve baskın yöntem olmaya devam ettiği görülüyor — katılımcıların %88,8’i başlık seviyelerini çok veya bir ölçüde faydalı buluyor. İleri düzey kullanıcılar, başlangıç seviyesindekilere kıyasla başlıklarla gezinmeye çok daha yatkındır. Pratikte bu, kullanıcının JAWS veya NVDA’da sayfadaki bir sonraki başlığa atlamak için H tuşuna basması, yapıyı hızla taraması anlamına gelir. 1’den 6’ya kadar olan tuşlara basmak, doğrudan o seviyedeki bir başlığa atlar. Sayfanızda hiç başlık yoksa veya başlıkları belge yapısı yerine görsel boyuta göre seçtiyseniz, kör kullanıcıların atlayabileceği hiçbir işaret noktası yoktur — sayfanın tamamını baştan sona dinlemek zorunda kalırlar.

İkinci büyük strateji işaret bölgeleriyle gezinmedir. HTML5 işaret bölgesi öğeleri — <main>, <nav>, <header>, <footer>, <aside> ve etikete sahip <section> — ekran okuyucu kullanıcılarının rotorlarını veya işaret bölgesi kısayol tuşlarını kullanarak aralarında atlayabildiği adlandırılmış bölgeler oluşturur. 2025’te, yerel <main> öğesinin artık sayfaların %47’sinde bulunmasıyla, ARIA işaret bölgelerinin benimsenmesi biraz artmıştır. Katılımcıların %31,7’si işaret bölgeleri mevcut olduğunda bunları her zaman veya sık sık kullandığını belirtirken, yalnızca %3,7’si işaret bölgelerini birincil gezinme yöntemi olarak kullanıyor — bu da işaret bölgelerinin ikincil bir araç olduğunu, ancak yönelim için önemli olduğunu gösteriyor.

Kullanıcılar ayrıca tek tuş kısayollarıyla bağlantılar, form alanları ve düğmeler arasında gezinir ve sıklıkla sayfadaki tüm başlıkları, tüm bağlantıları veya tüm form alanlarını bir arada gösteren öğe listelerini açarak tarama yapar ve ihtiyaç duydukları yere doğrudan atlarlar. Bu davranış, bağlantı metni için büyük sonuçlar doğurur. “Daha fazla oku, Daha fazla oku, Daha fazla oku” şeklinde bir bağlantı listesi hiçbir gezinme değeri sunmaz. Her bağlantı ve düğmenin, bağlamdan bağımsız olarak anlamlı olan açıklayıcı, benzersiz bir erişilebilir ada sahip olması gerekir.

Mobilde paradigma dokunma hareketlerine kayar. VoiceOver ve TalkBack kullanıcıları bir sonraki öğeye geçmek için sağa kaydırır, etkinleştirmek için çift dokunur ve gezinme modları arasında geçiş yapmak için rotor hareketlerini kullanır. Mobil uygulama kullanımına yönelik tercih, 2021’de %51,8 iken 2024’te %58’e yükselmiştir. Bu, duyarlı tasarımınızın ve mobil erişilebilirliğinizin isteğe bağlı eklentiler değil — ekran okuyucu kullanıcılarının büyük bir bölümü için birincil kullanım senaryoları olduğu anlamına gelir.

Bugün Web’deki En Sorunlu Engeller

WebAIM’in anketi, katılımcılardan karşılaştıkları en sorunlu öğeleri belirtmelerini istedi. Sonuçlar, on yılı aşkın süredir yapılan anketler boyunca dikkat çekici biçimde tutarlı — ve sitenizde doğru yapmanız gerekenlerin doğrudan bir kontrol listesini sunuyor.

• CAPTCHA açık ara en büyük şikayet konusudur. Ekran okuyucu kullanıcıları, CAPTCHA’nın üst üste on dört yıldan uzun süredir en sorunlu öğe olduğu konusunda hemfikir. Geleneksel CAPTCHA kullanımı, kör kişiler için bariz biçimde sorunludur; çünkü güvendikleri ekran okuyucular görüntüyü işleyemez ve formun gerektirdiği bilgiyi ortaya çıkarmalarını engeller. Sesli CAPTCHA’lar bile birçok kullanıcı için başarısız olur — kasıtlı bozulma, bunları anlaşılmaz hale getirir. Pratik öneri: mümkün olduğunda reCAPTCHA v3 veya honeypot teknikleri gibi görünmez, davranış temelli doğrulama kullanın.
• Beklenmedik davranışa sahip etkileşimli öğeler — yerleşik klavye etkileşim kalıplarını takip etmeyen menüler, sekmeler, iletişim pencereleri ve özel bileşenler — CAPTCHA’nın hemen arkasından gelir. Bu öğeler genellikle aşırı ARIA öznitelikleriyle inşa edilir ve düzensiz etkileşim davranışına ve tarayıcılar ile ekran okuyucular arasında uyumluluk sorunlarına sahiptir.
• Belirsiz bağlantılar ve düğmeler kullanıcıları sürekli hayal kırıklığına uğratır. “Buraya tıklayın”, “daha fazla bilgi edinin” veya “daha fazla oku” gibi ifadeler, bağlantı listesinde bağlamdan kopuk şekilde duyulduğunda hedef veya eylem hakkında hiçbir ipucu vermez.
• Beklenmedik ekran değişiklikleri — uyarı olmadan gerçekleşen dinamik içerik güncellemeleri — görsel olarak bir şeyin değiştiğine dair ipucu olmayan kör kullanıcıları dezoryante eder. Bu durum, içeriğin sayfa yeniden yüklenmeden değişebildiği React, Vue veya Angular ile oluşturulmuş tek sayfa uygulamalarda özellikle belirgindir.
• Bozuk başlık hiyerarşileri, çoğu ileri düzey kullanıcının birincil gezinme stratejisini baltalar. Web sitelerinin yaklaşık %39’unda bozuk başlık hiyerarşileri bulunur ve bu da ekran okuyucu kullanıcılarının içerikte düzgün biçimde gezinmesini zorlaştırır.
• Görsellerde eksik veya yetersiz alt metin. Alt metin olmadığında ekran okuyucu yalnızca bir görselin varlığını belirtip içeriğini tanımlamayabilir veya — daha da kötüsü — “IMG_4823.jpg” gibi anlamsız bir dosya adını okuyabilir.

Kullanıcıların çoğunluğu — %67 — ekran okuyucu kullanıcıları, engeller hakkında web sitesi sahipleriyle asla veya nadiren iletişime geçer. Sadece ayrılırlar. Bir şikayet almazsınız. Sadece bir kullanıcı kaybedersiniz.

Ekran Okuyucuların Gerçekten Yorumlayabileceği Kod Yazmak

Kullanıcıların gezinme kalıplarını anlamak, teknik gereksinimleri çok daha somut hale getirir. İşaretleme ve JavaScript’te verdiğiniz her karar, kör kullanıcılar için doğrudan işitilebilir bir sonuca sahiptir. En önemli ilkeler şunlardır.

Anlamsal HTML, ilk ve en güçlü aracınızdır. ARIA’nın ilk kuralı şunu söyler: “Gerekli anlam ve davranış zaten yerleşik olan yerel bir HTML öğesini veya özniteliğini kullanabiliyorsanız, bir öğeyi yeniden amaçlandırıp erişilebilir kılmak için ARIA rolü, durumu veya özelliği eklemek yerine bunu yapın.” <button>, <nav>, <header> ve <form> gibi öğeler, yerleşik erişilebilirlikle birlikte gelir. Yerel denetimleri kullanmak, ek kod gerektirmeden tarayıcılar ve yardımcı teknolojilerle kutudan çıktığı gibi uyumluluk sağlar.

ARIA bir takviyedir, ikame değil. ARIA (Accessible Rich Internet Applications), HTML’nin tek başına gerekli anlamı ifade edemediği durumlarda erişilebilirlik boşluklarını kapatmak için tasarlanmış bir HTML öznitelikleri setidir — örneğin özel olarak oluşturulmuş bir kaydırıcıyı erişilebilir kılmak, dinamik içerik değişikliklerini anons etmek veya katlanabilir bir menünün şu anda genişletilmiş olduğunu belirtmek için. Tehlike, yanlış kullanımda yatar. ARIA içeren ana sayfalar, ortalama olarak ARIA içermeyen sayfalara göre iki katından fazla erişilebilirlik hatasına sahiptir. Daha fazla ARIA, daha erişilebilir anlamına gelmez — çoğu zaman daha fazla hata anlamına gelir. ARIA’yı yanlış kullanan sayfalar, kullanmayanlara göre %70 daha fazla tespit edilebilir hata göstermiştir. ARIA’yı, hiçbir yerel öğenin işi yapamadığı yerlerde cerrahi hassasiyetle kullanın.

Aşağıdaki kod örneği, erişilemez bir özel düğme ile düzgün biçimde erişilebilir bir düğme arasındaki farkı gösterir:

<!-- Erişilemez: rolü olmayan, klavye desteği olmayan tıklama işleyicili bir div -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Erişilebilir: yerleşik rol, klavye desteği ve odakla gelen yerel düğme -->
<button type='submit'>Submit</button>

<!-- Düğme olmayan bir öğe kullanmak zorundaysanız rol, tabindex ve klavye olayı ekleyin -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

ARIA canlı bölgeleri, dinamik içerik değişikliklerini anons etmenin doğru mekanizmasıdır. Sayfanız tam bir sayfa yeniden yüklemesi olmadan içerik güncellediğinde — bir form doğrulama mesajı, sepet toplamı, bir bildirim — bu değişiklik, canlı bölge kullanmadığınız sürece ekran okuyucu kullanıcısı için sessiz kalır. aria-live='polite' özniteliği, ekran okuyucuya değişikliği kullanıcının mevcut etkinliği tamamlandıktan sonra anons etmesini söylerken, aria-live='assertive' hemen kesintiye uğratır — ikincisini yalnızca acil uyarılar için, seyrek kullanın. 2025’te sitelerin yaklaşık %33’ü aria-live özniteliğini kullanıyor; bu, 2024’e göre %4’lük bir artış, ancak dağıtılan dinamik arayüz sayısı göz önüne alındığında hâlâ çok düşük.

Odak yönetimi, etkileşimli bileşenlerde — modal iletişim kutuları, açılır menüler, akordeonlar — açıkça ele alınmalıdır. Bir modal açıldığında odak onun içine taşınmalıdır. Kapatıldığında odak, onu tetikleyen öğeye geri dönmelidir. Bir modal açıp odağın hâlâ arkasındaki düğme üzerinde olduğunu bulan ekran okuyucu kullanıcısı, fiilen iletişim kutusunun içeriğinden mahrum kalır.

Sitenizi Bir Ekran Okuyucuyla Test Etmek

Otomatik erişilebilirlik tarayıcıları değerlidir ancak sınırlıdır. Otomatik araçlar WCAG ihlallerinin %30–40’ını yakalar, ancak gerçek yardımcı teknoloji testleri, kullanıcıların sitenizi gerçekte nasıl deneyimlediğini — eksik bağlamı, kafa karıştırıcı gezinmeyi ve hiç çalışmayan etkileşimleri — ortaya çıkarır. Hiçbir tarayıcı, modalinizin başlığının etrafındaki görsel bağlam olmadan anlam ifade etmediğini ya da özel açılır listenizin durumunu bir tarayıcı-ekran okuyucu kombinasyonunda yanlış, diğerinde doğru anons ettiğini size söylemez.

Çoğu ekip için pratik başlangıç noktası Firefox ile NVDA’dır — ücretsizdir, yaygın olarak kullanılır ve en yaygın sorunların büyük çoğunluğunu yakalamada etkilidir. macOS ve iOS kullanıcılarını kapsamak için Safari ile VoiceOver ekleyin. Kurumsal bağlamlarda veya yüksek uyumluluk gereksinimleri olan müşteriler için Chrome veya Edge ile JAWS’ı dahil edin. Her ekran okuyucu belirli bir tarayıcı eşleştirmesiyle en iyi şekilde çalışır; yanlış kombinasyonu kullanmak yanıltıcı test sonuçları üretebilir.

Test yaparken, gerçek kullanıcıların benimsediği gezinme kalıplarını benimseyin. Fare kullanmayın. H tuşunu kullanarak başlıklarla gezin. Bağlantı listesini açın ve her bağlantının bağlamdan bağımsız olarak anlamlı olduğundan emin olun. Form alanları arasında sekmeyle ilerleyin ve her etiketin doğru anons edildiğini kontrol edin. Modal iletişim kutularını açın ve odağın içlerine taşındığını doğrulayın. Formları doldurun ve gönderin, her doğrulama mesajını dinleyin. Monitörünüzü kapatın ve temsilî bir kullanıcı görevini baştan sona tamamlamaya çalışın — gören bir testçi için ne kadar rahatsız edici olursa olsun, bu deneyim kör kullanıcılarınızın günlük gerçekliğidir.

Ayrıca tarayıcı öykünücüleri veya simülatörleri yerine gerçek yardımcı teknolojiyle test yapmak da önemlidir. Tarayıcı geliştirici aracı erişilebilirlik panelleri, hata ayıklama için faydalı olan erişilebilirlik ağacını gösterir, ancak işitsel deneyimi kopyalamaz veya yalnızca gerçek ekran okuyucu yazılımlarla ortaya çıkan etkileşim tuhaflıklarını açığa çıkarmaz.

Göz Ardı Edemeyeceğiniz Ticari ve Hukuki Gerekçe

Erişilebilirlik için ahlaki gerekçenin ticari gerçeklikle pekiştirilmesi gerekiyorsa, rakamlar çarpıcıdır. Yalnızca Amerika Birleşik Devletleri’nde yaklaşık 7 milyon görme bozukluğu olan birey vardır ve bu önemli bir tüketici tabanını temsil eder. Küresel ölçekte, ABD’li yetişkinlerin %26’sında engel bulunmakta ve bu, tahmini 13 trilyon $’lık bir pazar fırsatına karşılık gelmektedir. Erişilemez tasarım kör kullanıcıları sitenizin dışında bıraktığında, yalnızca ahlaki bir yükümlülüğü yerine getirmemekle kalmıyor — müşterileri geri çeviriyor ve kuruluşunuzu hukuki risklere maruz bırakıyorsunuz.

WCAG 2.2, artık binlerce ADA davasında atıf yapılan hukuki standarttır ve Haziran 2025’te özel sektör işletmeleri için tam olarak yürürlüğe giren Avrupa Erişilebilirlik Yasası, AB genelinde uyumluluk gerekliliklerini genişletmektedir. Ekran okuyucu kullanıcılarının çoğu, engeller hakkında web sitesi sahipleriyle asla iletişime geçmez — sadece ayrılır ve işlerini başka yere götürürler. Sorunları asla bildirmeyen %67’lik kesim memnun değildir; yenilgiye uğramıştır. Ekran okuyucu uyumluluğunu en baştan geliştirme sürecinize dahil etmek, maliyetli düzeltmeleri önler, hukuki riski azaltır ve ürünlerinizi gerçekten kullanabilecekleri dijital deneyimler arayan bir kitleye açar.

Temel Çıkarımlar

• Ekran okuyucular görselleri değil, yapıyı temel alarak gezinir. Tarayıcının erişilebilirlik ağacını platform erişilebilirlik API’leri aracılığıyla sorgularlar. Anlamsal HTML — doğru başlıklar, işaret bölgeleri, yerel denetimler — ekran okuyucu uyumluluğuna yapabileceğiniz en yüksek getirili yatırımdır.
• Kör kullanıcılar satır satır değil, başlıklar, işaret bölgeleri ve öğe listeleriyle gezinir. Ekran okuyucu kullanıcılarının %88’inden fazlası, başlık seviyelerini gezinme için çok veya bir ölçüde faydalı buluyor. Bozuk veya eksik bir başlık hiyerarşisi, web’deki en yaygın ve en yıkıcı erişilebilirlik hatalarından biridir.
• ARIA, hem iyi hem kötü işaretlemeyi büyütür. ARIA içeren sayfalar, ARIA içermeyen sayfalara göre ortalama iki katından fazla erişilebilirlik hatasına sahiptir. ARIA’yı yalnızca yerel HTML’nin gerekli anlamı ifade edemediği durumlarda kullanın ve uyguladıktan sonra her zaman gerçek yardımcı teknolojiyle test edin.
• CAPTCHA, belirsiz bağlantılar ve anons edilmeyen dinamik içerik değişiklikleri, gerçek dünyadaki en büyük engellerdir. Görsel CAPTCHA’yı davranış temelli doğrulamayla değiştirmek, açıklayıcı bağlantı ve düğme metni yazmak ve dinamik güncellemeler için ARIA canlı bölgeleri uygulamak, kör kullanıcılar için kullanılabilirlik üzerinde anında ve ölçülebilir bir etki yaratacaktır.
• Gerçek ekran okuyucularla, birden fazla tarayıcı eşleştirmesi üzerinden test yapın. Otomatik tarayıcılar WCAG ihlallerinin yalnızca %30–40’ını yakalar. Firefox ile NVDA ve Safari ile VoiceOver, kullanıcı tabanınızın çoğunu sıfır maliyetle kapsar ve sitenizde fare olmadan gezinme deneyimi, hiçbir otomatik aracın ortaya çıkaramayacağı sorunları açığa çıkarır.