Windows'ta web erişilebilirliği 18 yaşında mı?

Spread the love

Daha önce, ekran okuyucuların nesnelerin etiketlerinden bir düz metin çıktısı elde ederek, kullanıcıların paneli kullanabilmesini sağladığını anlatmıştım. Dileyenler gene bu blog üzerinden bulup okuyabilirler.

 

Peki, bu günlerde web erişilebilirliğini yeniden düşünmek zorunda kalırsak, aklınıza ne gelirdi?

Marco Bu konu ile alakalı öncelikle genel olarak web erişilebilirliğinin 18 yıllık geçmişini ve mevcut teknoloji ışığında bunun daha iyi nasıl yapılabileceğini buradaki Blog gönderisinde anlatmış. Kendisine teşekkür ederim. Ben ise, bir bakıma İngilizce olan yazının Türkçe yorumlanışını size sunmaya gayret edeceğim. Olduğu gibi deklare etmektense, yorumlayarak fikirlerimi eklemenin daha doğru olacağını düşündüm. Zaten isteyen Google translate ile bu yazıyı çoğunlukla doğru çevrilmiş olarak okuyabilir. Hatta zahmet etmeyin, Bu link çalıştığı sürece tıklayarak okuyabilirsiniz.

Marco İlk olarak 1999’da jaws ve Window-eyes’in web elementlerini, Word belgelerindeki elementler gibi yorumlayarak, sanal bir düz belge formunda sunan sürümlerini duyurduğunu hatırlatıyor. O benden daha açıklayıcı yazmış. Bazen kıskanıyorum 🙂 Bu Yapı, İExplorer ile iletişim kuran bir arabirim üzerinden çalıştırılıyordu. Halen daha kullanılan bu yöntem, ekran okuyucuların programları okuyabilmek için, kendi kaynak APİ’lerini uygulamanın kaynak koduna enjekte etmesi sayesinde geliştirildi.

Tarayıcılardan alınan html verilerini, ekran okuyucuların tarayıcıdan aldığı sıralama ile yeniden yorumlaması ile, sanal bir ön bellek üzerinde bir belge oluşturulması, yeni duyurulan web gezinti yöntemi idi. Bu yöntem o zaman için olağanüstü idi; çünkü, öncelikle gerçek belgeye yakın bir gezinti sağlanabilecek belge oluşturulabiliyor; algılanan bağlantı, form alanı gibi elementler tek seferde listelenebiliyor ve son olarak sonradan duyurulan hızlı gezinme tuşları “h” gibi bir harfe bastıktan sonra bir sonraki başlığa ulaşmanıza izin veriyordu.

2000’li yılların ortasına geldiğimizde, JavaScript ve buna benzer yöntemler, daha dinamik bir web deneyimi ortaya koymaya başladı ve artık sanal tampon teknolojisi, sarsılmaya başladı. Sürekli değişen web içeriğini, kullanıcının deneyimini bozmadan tarayıcı ile daha fazla iletişim kurarak, odak kaybetmeden güncellemek gerekiyordu. Yapısı itibarıyla bu teknoloji buna uyumlu değildi. Üstelik bunun için gereken işlemci gücü ve o zamanın teknolojisini düşünürseniz, çoğunluk kitlenin “internette gezinmek mi?” Sorusuna “kabus” gibi bir cevap verdiğini tahmin edebilirsiniz. Bu yüzdendir ki, Jaws ile zaman içinde optimize edilen web de gezinti deneyimine alışmış kullanıcıların, kendilerini yeni ekran okuyucularda psikolojik olarak rahatsız hissettiğini gözlemleyeniniz mutlaka oldu.

Marco, daha sonra Yeni tarayıcıları ve api’leri anlatmaya başlıyor. Marco’nun dikkat çektiği nokta Firefox ile başlayan evre. Mozille firması Firefox tarayıcısını geliştirmeye başladığında, bunun Linux üzerinde de çalışacağı öğrenildi. Bu süper bir haber. Peki, Windows’un o kadar karmaşıklaşmış erişilebilirlik apileri gelişen teknolojinin hangi evresinde Linux’a aktarılacaktı? Üstelik çapraz programlamanın olmadığını düşünün. Sadece Popüler olarak java ve c++ ile birçok birden fazla platformda çalışan kitler yazılabiliyordu. Var olanın çaprazlanması mümkün değil.

Kimin kafasından çıktıysa, yeniden html kodlarını yorumlamak yerine, zaten tarayıcının bildiği bilgileri erişilebilirlik api’sine söylemesinin daha mantıklı olacağına karar verildi. Hemen düşünelim, bir gün yeni bir html elementi üretildiğinde, bunu tarayıcı zaten ekran okuyucuya söyleyecekti. Bu iş böyle yapılacak denildikten sonra, NVDA projesi geliştirilmeye başlamıştı ve benzeri bir işlem artık Windows için gerekiyordu. Microsoft Yerleşik erişilebilirlik api’si olan MSA’nın eksik bileşenlerini geliştirmeye karar verdi. Üstelik web içerikleri ile beraber. İşte buradan sonra, birçok Windows uygulaması tarafından da kullanılabilen IAccessible modülünün yeni sürümü olan IAccessible 2.0 ortya çıktı. Bu paralelde, MacOsx web kit için erişilebilirlik geliştirmeleri almaya başladı. Voice over’da mevcut durum ise, voice over nesne tanıma kullanmak yerine, arayüz seti tarafından gönderilen bilgileri söylüyordu. Linux dağıtımlarında benimsenen yöntem en teknolojik hali ile, voiceover’a aktarılmış. “Hey microsoft, peki sen bunu kendi ekran okuyucunda kullanmak yerine, neden diğer sağlayıcıların kullanacağı modül haline getirdin?” diye sorarlar adama? Gerçi bu sonra microsoft’un titreyip kendine gelmesine de sebep oldu ya neyse.

Microsoft edge geliştirilmeye başlanıldığında ise, marco ekran okuyucuların bir anda ham html verisine ulaşamadığını söylüyor. Baktığımızda, ekran okuyucu geliştiricileri 2 duvara çarptı. Biri, tanımadıkları bir yazılım sistemi olan uwp ile karşılaştılar; diğeri ise bu yeni mimarinin detalarına tam hakim olmadıkları ve ekran okyucuların çekirdek bölümünde olmayan bu program geliştirme mimarisi yüzünden tersine mühendislik ile sorunu çözemediler. Sonra microsoft uia otomasyonu adı verdiği, IAccessible’nin devamı olan modül üzerinden ekran okuyucuların veri almaları gerektiğini söyledi. Şimdi ise, ekran okuyucuların birden bire edge desteği sunabilmesinin sebebini gördük. Bu ticari ekran okuyucu geliştiricilerinin pek hoşuna gitmedi belliki. Kendi modüllerini üretip lisans satarken, bir anda çoğunlukla lisans hakları başkasına ait modülleri çekirdeklerine entegre etmek zorunda kaldılar.

Marco, aynı zamanda mimari hakkında da bilgi sağlamış. Buna göre ekran okuyucuların 2 farklı yönteminden bahsedilmiş. Biri süreç içi (İnProcess), biri süreç dışı (OutProcess). Süreç için yöntem uygulamanın kaynak kodunu programa enjekte etmesidir. Ekran okuyucunun tarayıcıdaki html verisine ulaşmak için tarayıcıya girmesi örnek verilebilir.

Bu yöntem artık başarısız oluyor. Öncelikle antivürisler ve yeni tarayıcılar güvenlik için bunu red ediyor.

İkincisi performans. Makineye bağlı olarak bu işlem Süreç dışı yönteme göre 2 ve 50 kat arası yavaşlığa sebep olur. Ha unutmadan, yazılımda veya ekran okuyucuda bir sorun olursa, ikisi birden devrilir.

Süreç dışı yöntem ise, Bir erişilebilirlik api’si yada arayüz seti tarafından ekran okuyucuya verilerin sağlanmasıdır. Burada sadece 1 ekstra işlem uygulandığından, uygun ortamda SüreçDışı yönteme göre daha hızlı yol alınmasını sağlıyor. Bu Linux dağıtımlarındaki baskın ekran okuyucu olan Orca’da veVoiceOver’da uygulanıyor.

Son olarak Marco Birkaç öneri sunmuş. Kendisine katılıyorum. Nesne motoru teknolojisi yardımcı olarak geliştirilirken bu yöntemlerin ana çözüm olarak uygulanabileceğini düşünüyorum. Marco, ticari geliştiriciler ile beraber çalışarak, öncelikle UIA otomasyonunu tamamen destekleyecek modüller üzerinde çalışmayı teklif ediyor. Birde tarayıcı geliştiricilerine önerilerimiz var tabi.

Marco’nun mesajına aynen katıldığımı ifade ederken önerilerimiz şunlar:

1.      Ekran okuyucu geliştiricileri, tarayıcının web içeriği hakkında daha fazla şey bildiğini kabul ettiklerinde, tarayıcı geliştiricileri daha fazla sorumlulk almalı.

2.      Ekran okuyucu tarafından istenildiğinde, uygulamalar tüm nesneleri ekran okuyucuya sunabilmeli. (düğme, bağlantı, başlık, metin, form alanı vs)

3.      Ekran okuyucu talep ettiğinde, uygulama aynı türdeki nesneleri ekran okuyucuyu vermeli. (bağlantıların oluşturduğu liste, düğmelerin oluşturduğu liste gibi)

4.      Ekran okuyucular talep ettiğinde, arayüz seti yada uygulama önceki ve bir sonraki nesneyi sağlamalı.

 

Bunun mevcut sisteme göre avantajları da olabilir. Sanal bir arayüz sözkonusu olduğunda, asla ekrandaki içerik ve odaklanılan içerik aynı değildir. Bir sonraki başlığa, önceki bağlantıya taşındığınızda ekrandaki içerik çoğu zaman sabit kalır. 199 tweet2lik bir tweet buferinde, siz 50. Öğe üzerindeyseniz, ekranda tek seferde 30 tweet gösterildiğini var sayarsanız, 50 ve 80. Tweetler topluca gösterilir. İmleç 50. Öğe üzerinde olduğunu bilmez. Ola ki bir şekilde buffer yenilenirse, asla o 50. Öğeyi değil, yeniden yüklendiğinde oraya denk gelen öğeyi görürsünüz.

Arayüz seti, ekran okuyucu ile yumlu çalıştığında imleç ve ekran okuyucu aynı anda hareket eder ve böylece imleç ekranda eş zamanlı kayar. Libre Office ile elde edilen Office performansının, desteklenen ekran okuyucular ile, microsoft office’den daha performanslı olmasını tamda bu sağlar. Libre Office ekran okuyucu ile java accessbrich üzerinden iletişim kurar.

 

Şimdi sizin yorumlarınızı alalım.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir