Roger Johansson tarafından kaleme alınan ve web erişilebilirliğinin nasıl değerlendirilip uygulanabileceği konusunda oldukça faydalı bilgiler içeren makalenin Türkçe çevirisi.

Web sitesi erişilebilirliğinin nasıl kontrol edilebileceğini dile getiren yazı dizisinin ikinci bölümüne hoş geldiniz. Biraz altyapısal bilgiye ve bahsettiğim faydalı araçlara sahip olduğunuzdan emin olmanız için Site erişilebilirliğinin derecesinin tespiti Bölüm 1, Altyapı ve hazırlık başlıklı makaleyi okumanızı tavsiye ediyorum.
Bu makalede dile getirilen kontroller, otomatik araçlar ile ve dolayısıyla el yordamıyla kolayca test edilebilecek muhtemel erişilebilirlik bakış açılarını kapsamaktadır.
Tam erişilebilirlik için daha fazla kontrol gerekmekte ve bunların bir kısmı serinin üçüncü bölümünde yer almaktadır. Diğer taraftan bu temel kontroller de iyi bir başlangıç sayılacaktır.
HTML ve CSS geçerleme kontrolleri için W3C geçerleme motorunu kullanabilirsiniz. Bunun için Web Developer eklentisi araç çubuğundaki Tools - Validate CSS ve Tools - Validate HTML araçlarını kullanmak oldukça faydalı olacaktır. Bu araçları çok kullanacağınızdan birer kısayol tuşu atamanızı tavsiye ediyorum.
Elbette W3C geçerleme sayfalarını da kullanabilirsiniz
Kötü inşa edilmiş DOCTYPE veya karakter kodlama bilgisi olmayan sayfaların geçerlenmelerinin çok zor olduğu dikkatinizi çekecektir. Böyle siteler için geçerleme motorunun ara yüzünde bulunan bilgileri kullanabilirsiniz.
Durumu daha vahim olanlar ise geçerleme motorunun sayfaya erişimini engelleyebilmektedir. Evet, böyle siteler de var. Bir site neden geçerleme motorundan gizlenmek istenir onu da anlamış değilim. Her neyse böyle durumlarda Web Developer eklentisi araç çubuğunda yer alan Tools - Validate local CSS ve Tools - Validate local HTML araçlarını kullanabilirsiniz. Geçersizliğin durumuna göre, CSS geçerleme motorunun işini yapmasını engelleyecek hataları olan sayfalarda da Tools - Validate local CSS aracını kullanabilirsiniz.
Aynı şekilde HTML Validator eklentisi de W3C sözdizimi geçerleme motorunu engelleyen sayfaların kontrolleri için kullanılabilir. Bu araç aynı zamanda sitenizi sunucuya göndermeden kendi bilgisayarınızda, sitedeki üye girişi gerektiren bu nedenle geçerleme motorunun erişemediği bölümleri kolayca geçerlemenize olanak tanıyacaktır.
HTML Validator eklentisi; tarayıcıda görüntülediğiniz her sayfa için otomatik olarak herhangi bir erişilebilirlik sorununa yol açabilecek hataları kontrol edip sizi uyaracaktır. "Options" bölümünden erişilebilirliğin derecesini belirleyebilirsiniz. HTML Validator eklentisinin Tidy tabanlı olduğunu ve bu nedenle W3C geçerleme motoru tarafından yakalanabilen bazı uyarıları bildiremeyebileceğini de unutmayın.
Diğer taraftan geçerliliğin erişilebilirliğe eşit olmadığını da bilmeniz gerekmektedir. Şahsen geçerli söz dizimine sahip olmasına rağmen geçerli olmaktan uzak birçok site görmekteyim. Bu senaryo özellikle, web standartları ve erişilebilirlik konusunda ciddi yanlış anlaşılmalara sahip geliştiriciler tarafından inşa edilen malum içerik yönetim sistemleri üzerine kurulu sitelerde karşımıza çıkmaktadır.
Neden? Çünkü geçerli sözdizimi web'in temel yapı taşlarından olan aygıt bağımsızlığı için oldukça önemli bir yere sahiptir. Geçerli sözdizimi, içeriğin birçok tarayıcı ve cihaz tarafından olabildiğince doğru yorumlanma garantisini de beraberinde getirecektir.
Firefox içerisinde eğer görüntülenen sayfa frame ihtiva ediyorsa sağ tık menüsüne "This frame / Geçerli pencere" adında bir seçenek eklenir. Iframe'lerin nerede bitip nerede başladığını kestirmek biraz daha zordur. Neyse ki Web Developer eklentisinin Outline - Outline Frames komutu sayfadaki bütün iframe'lerin sınırlarını görmemize yardımcı olabilmektedir.
Neden? Frame'ler (ve iframe'ler) gerekli olmadıkları sürece tamamen erişilebilir olmaktan uzaktırlar, genelde siteyi daha az erişilebilir ve daha az kullanışlı yaparlar ve mümkün olduğunca kullanılmamalıdırlar. Aynı zamanda frame kullanımı; sayfanın erişilebilirlik ve kullanışlılık konusunda yeterli bilgiye sahip olmayan bir web geliştiricisi tarafından inşa edildiğini de gösterir. Webi kim çerçeveletiyor: frame'ler ve kullanılabilirlik başlıklı yazımı okuyarak frame'lerin kullanışlılığı ne ölçüde etkilediği hakkında daha fazla bilgi alabilirsiniz.
Otomatikleştirilmiş erişilebilirlik araçları daha çok erişilebilirlik konusunda acemi olanlar tarafından kullanılmaktadırlar. Gerçekten anlamak zor, neden sitenin erişilebilirliğini de geçerleme kontrolünü yaptığımız gibi yapamayalım. Bu aşamada karşımıza çıkan sorun günümüz otomatikleştirilmiş erişilebilirlik tespit araçları mükemmellikten oldukça uzak olmaları ve daha iyi olmaları gerektiğidir.
Bu araçlar bazı sorunları açığa çıkaracak ve sitenin erişilebilirliği hakkında oldukça hızlı ve genel bir fikir sahibi olunmasını sağlayacaktır. Bu nedenle onların site ile ilgili görüşlerini dikkate değer buluyorum. Bunu dışında sadece bu araçların bulamayacağı birçok erişilebilirlik probleminin var olduğunu ve bazen sorun olmayacak bir şeyi sorun gibi algılayabildiklerini de aklınızdan çıkarmayın. Her zaman el yordamı ile müdahale gerekecektir.
Bu nedenle aşağıdaki otomatik araçlar tamamıyla güvenilir değildirler fakat en azından sitenin erişilebilir olup olmadığı hakkında bir fikir sahibi olmanızı ve hangi bölümlerin daha sorunlu olduğunu görmenizi sağlayabilirler.
Şunu açıklığa kavuşturalım: bir sitenin bütün erişilebilirlik araçlarından geçebilmesi tamamen erişilebilir olduğunu göstermez.
Neden? Otomatik erişilebilirlik araçları el yordamı ile sözdizimi içerisinden bulmanızın daha uzun sürdüğü sorunlara daha hızlı bir biçimde ışık tutmanızı sağlayacaktır. Otomatik üretilen raporlar ile ve el yordamı ile problemli bölümleri tespit edebileceğinizden şüpheniz olmasın.
HTML geçerleyicileri ve erişilebilirlik kontrol araçları alt parametresi eksik olan resimler ve resim haritaları (image map) için alternatif metnin şart olduğunu belirtirler. Eğer geçerleyici herhangi bir eksik alt parametresi uyarısı vermezse, dokümandaki her resmin alternatif metni olduğu sonucuna varabilirsiniz. Fakat alt parametresinin nasıl kullanıldığı hakkında yeterince bilgi sahibi değilseniz sayfada bazı sorunlar olması kuvvetle muhtemeldir.
Web Developer eklentisindeki Images - Replace Images With Alt Attributes komutu ile resimlerin alternatif metinlerini görebilirsiniz. Şimdi siteyi anlamaya çalışın. Genelde alternatif metinler resimler kapalı oldukları zaman görüntülenirler ve birçok tarayıcı alternatif metinler için sayfanın metin rengini veya üst elemente uygulanmış stilin metin rengini kullanarak görüntüleme yaparlar. Eğer resim yokken görünen bu metnin rengi arka fon rengine çok yakınsa okunması çok zor hatta imkansız olacaktır. Bu çok sayıda resimler için arka fon rengi kullanan sitelerde ortaya çıkan bir sorundur.
Birçok kişi alt parametresi hakkında yanlış bir anlaşılma içerisindedir. Alternatif metinler anlaşılabilirliği pekiştirmek için kullanılırlar ve açıklayıcı resim veya diğer grafik nesneleri görüntülenemediği zamanlarda bir alternatif olarak kullanılmalıdırlar. İpucu olarak görüntülenme amacı taşımazlar. alt metinlerinin img ve area elementleri için kullanılması şarttır.
Açıklayıcı resimler, resmin kısa bir tanımlamasına sahip olmalıdırlar. Dekoratif resimler boş bir alternatif metin içermelidirler. Her dekoratif resim ve ayrıntılardaki boşluk doldurucu resimlere (spacer GIFs) yardımcı olması amacıyla tanımlama metinleri yazmak için çaba harcayan birçok site gördüm. Böyle bir siteyi bir ekran okuyucusu ya da metin tabanlı bir tarayıcıyla bir kez bile ziyaret ettiğinizde ne kadar sinir bozucu olabileceğini göreceksiniz.
alt parametresi hakkında daha derinlemesine bilgi ve onunla ilintili olan title parametresi ile ilgili yazdığım alt ve title parametreleri başlıklı makaleyi okuyabilirsiniz. Bir resmin açıklayıcı mı yoksa dekoratif mi olduğuna karar vermenizde yardımcı olması açısından Dimitri Glazkov tarafından yazılan "Gösterişi" içerikten uzak tutmak isimli makaleyi inceleyebilirsiniz.
Neden? Eğer alternatif metin tanımlanmazsa veya hatalı tanımlanırsa, resimleri göremeyen bir kişi yeterince bilgi sahibi olamayacak ya da gereksiz bilgiler ile boğuşacaktır.
Tekrar Web Developer eklentisini kullanıma sokmanın vakti geldi. JavaScript'i devre dışı bırakın (Disable - Disable JavaScript), ardından siteyi kullanmaya çalışın. Bazı siteleri JavaScript olmadan kullanmak neredeyse imkansızdır. Kurumsal siteler arasında gördüğüm en büyük sorun site navigasyonunun (ana menü erişimi) JavaScript gerektiriyor olmasıdır. Birçoğu da bazı tarayıcı tespitlerinden sonra tarayıcaya göre harici stil dosyalarını yüklemek için JavaScript kullanmaktadır (20. yy tarzı) ki bu JavaScript devre dışı olduğunda stilsiz bir doküman ile karşılaşacağınız anlamına gelir.
Ben ayrıca, JavaScript olmadan sitelerin kullanılıp kullanılamayacağını test etmek için JavaScript desteği olmayan bir tarayıcı olan Lynx kullanırım.
Neden? Hatırı sayılır miktardaki bir kullanıcı topluluğu JavaScript destekleri kapalı olarak ya da JavaScript desteği olmayan cihazları kullanarak web gezmektedir. Sitemiz böyle durumlarda dahi kullanılabilmelidir.
Bu hiç JavaScript kullanamayacağınız anlamına gelmiyor. Kesinlikle kullanabilirsiniz. Kullanırsınız fakat duyarlı ve abartılı olmayan bir biçimde kullandığınızdan ve JavaScript kapalı olduğunda göze batmayacak bozulmalara sebep olduğundan emin olmalısınız.
Em ya da yüzde gibi rölatif (göreceli) birimlerle belirtilen metin boyutu kullanıldığında metin büyüklüğü ayarlaması her tarayıcı da çalışacaktır. Eğer metin boyutu piksel olarak belirtilirse Windows için Internet Explorer kullanan oldukça fazla sayıdaki kullanıcılar, ilgili ayarlarını yapmadan metin boyutu değiştiremeyeceklerdir.
r metin boyutlandırmayı denemek istiyorsanız IE/Win ile sayfayı açın ve metin boyutunu değiştirin (CTRL tuşuna basılı iken farenin orta yuvarlağını döndürün ya da Görünüm - Metin Boyutu - En büyük). Eğer hiçbir şey olmazsa ilgili site muhtemelen metin boyutu belirtimi için piksel kullanmış demektir.
Eğer IE/Win kullanamıyorsanız; CSS'yi gözden geçirin. Tekrar Web Developer eklentisi kullanma zamanı. CSS - Edit CSS ile font-size deklarasyonları için kullanılan birime dikkat edin. Eğer bütün gördüğünüz px ise bu site rölatif birim kullanmıyor demektir (teknik olarak kullanıyor olabilir fakat bu doküman için değil). Görmeniz gereken em ya da % olmalıydı.
Tarayıcıların piksel olarak tanımlanmış metinleri yeniden boyutlandırıp boyutlandıramayacağı apayrı bir sorundur ve yıllardır tartışılmaktadır. Benzer bir tartışmayı Metin boyutunu piksel olarak ayarlamak başlıklı makalemde de bulabilirsiniz.
Metin boyutunun rölatif birimler ile tanımlandığı durumlarda dahi metin boyutlandırma sorun yaratabilmektedir. Sayfa ara yüzü, kullanıcının metin boyutunu birkaç kademe yukarı çekmiş olabileceği hesaba katılarak tasarlanmalıdır. Birçok tasarım metin boyutu arttırılmaya başlandığı anda kullanışsız bir hal almaktadır. En nihayetinde de tasarım resmen birbirine girmektedir. İyi bir tasarım metin boyutu yüzde birkaç yüz arttırıldığında dahi makul bir şekilde kullanışlı kalabilmelidir. Normal metin boyutunda olduğu kadar güzel görünmeyebilir fakat hiçbir içerik kaybedilmemeli ve okunamaz hale gelmemelidir.
Eğer siteye metin boyutunu değiştiren küçük bir uygulama (widget) koymaya karar verdiyseniz (ki tasvip etmediğim bir şeydir); en büyük olarak belirlenen boyutun gerçekten de yeterince büyük olduğundan emin olun. Normal metin boyutundan biraz değil oldukça büyük olmalı. Eğer normal boyuttan çok da farklı bir büyüklük elde edilemeyecekse böyle bir uygulamayı yapmak için harcanan zamandaki asıl amaç nedir öyle değil mi?
Neden? Çünkü çok sayıda kişi daha rahat okuyabilmek için daha büyük metin boyutu istemekte ya da buna ihtiyaç duymaktadır. Bu kullanıcılar görme bozukluğu olanlar, 40 yaşını aşmış olanlar ya da web gezerken sandalyelerinde geriye yaslanmış olabilirler.
Bir sitenin semantik kodlara sahip olup olmadığını anlamak için kaynağı görüntüleyip başlıklara (<h1>-<h6>), listelere (<ul>, <ol>, <dl>), alıntılara (<blockquote>, <q>) ve vurgulara (<strong>, <em>) dikkat etmelisiniz. Dokümanın kaynak kodlarında <h1>Başlık</h1> şeklinde olması gereken bölümlerin <span class="buyukkalinmakalebasligi">Başlık</span> ifadesine benzer bir şekilde olduğunu gördüğünüzde ilgili dokümanın semantik bir yapıya sahip olmadığını kolayca anlayabilirsiniz. Semantik dokümanlarda; HTML elementleri ile ifade edilebilecek bölümler için ekstra stiller tanımlamak yani bu örnekte de olduğu gibi bir başlık için özel bir seçici yaratmaktan uzak durmak gerekmektedir.
Neden? Semantik sözdizimleri değişik tarayıcı ortamları ve türleri ile görüntülenme sırasında doküman ve yapının anlamını korumaya devam etmesi açısından önem taşımaktadır. Diğer bir faydası ise; arama motorlarının daha çok semantik yapılı dokümanları tercih etmesidir.
Başlıkların uygun bir biçimde kullanılması, ekran okuyucuları gibi yardımcı cihazlar kullanan kişiler için oldukça kullanışlı bir ara yüz yaratılmasını sağlayacaktır.
Yardımcı cihazlar tamamen semantik yapılara ihtiyaç duymasa da, semantik yapı kullanmayan sayfalarda düz metinden anlamlı bir şeyler üretmek oldukça zor olacaktır.
Çevirenin notu: Yazı boyunca "semantic" kelimesi "semantik" olarak çevrilmiştir. Tam karşılığı "anlam bilimsel"dir, ancak bu yazıda "doğru, mantıklı ve olması gerektiği gibi, anlamına uygun biçimde" anlamında kullanılmaktadır.
Tekrar Web Developer eklentisini kullanarak Disable - Disable Styles - All Styles komutu ile stilleri devre dışı bırakın. Böylece dokümanınızın altında yatan HTML yapısını tarayıcınızın varsayılan biçimlendirmesi ile görme şansınız olacaktır.
Eğer CSS'yi devre dışı bıraktığınızda az bir değişiklik oluyorsa; muhtemelen ara yüz yapılandırması için tablo ve buna benzer çok sayıda sunum odaklı yapıları kullanarak yapılandırılmış bir dokümana bakıyorsunuz demektir. Öte yandan bu kadar çok erişilebilirlik problemine sahip olan bir doküman olmadan büyük ihtimalle bu kontrolün ne anlama geldiğini anlayamayacaksınız.
Neden? Erişilebilir bir doküman CSS olmadan da iyi yapılandırılmış, anlamlı ve kolay okunabilir olmalıdır.
Eğer bir ekran okuyucu uygulaması kullanacak imkanınız yoksa sayfanızın ekran okuyucu kullanan birisi için nasıl yorumlandığını anlayabilmenin makul bir yolu olarak Fangs'ı kullanabilirsiniz. Fangs (yazı dizimizin ilk makalesinde indirip kurmanızı tavsiye ettiğimiz); en yaygın kullanılan ekran okuyucularını ses yerine metin tabanlı olarak taklit eden bir Firefox eklentisidir.
Neden? Ekran okuyucuları yardımcı teknolojiler için oldukça önemlidir. Bir ekran okuyucusunun test ettiğiniz sayfayı nasıl yorumladığını bilirseniz, bağlantı ve başlıkları doğru yapılandırıp, alternatif metinleri amacına uygun bir biçimde kullanarak içeriği nasıl daha anlamlı bir şekilde düzenleyeceğinizi kavrayabilirsiniz.
Bu listeyi tamamladığınızda gerçekten oldukça ciddi sorunlara yol açabilecek erişilebilirlik problemlerini bulabileceksiniz. Eğer bir web geliştirici iseniz bu problemleri aşmak için bulabildiğiniz her şeyi yaparak listeyi tekrar gözden geçiriniz. Eğer geliştirici değilseniz, sitenin geliştirilmesi ve yapımı ile kim ya da kimler sorumluysa onlar ile iletişim kurarak sitede düzeltilmesi gereken hatalar bulduğunuz konusunda kendisilerini bilgilendiriniz.
Daha aşılması gereken çok sayıda erişilebilirlik problemi bulunmakta. Yazı dizimizin son makalesi olan Site erişilebilirliğinin derecesinin tespiti Bölüm 3, Dibini kazımak içerisinde, erişilebilirlik konusu tartışılırken sık sık dile getirilen, otomatik araçlar ile değerlendirilmesi zor olan ve daha fazla zaman/deneyim gerektiren şeylerin el yordamı ile değerlendirilmesi hakkında bazı önemli noktaların altını çizmeye çalışacağım.
Orijinal makale: Evaluating website accessibility part 2, Basic Checkpoints Roger Johansson - 456bereastreet.com
Çeviri / Trasnlation: Orhan Veli Firik - Mart 2007

Sitemizden indirdiğiniz eklentileri nasıl yükleyeceğinizi ve kullanacağınızı bilmiyorsanız bu makaleden başlayabilirsiniz. Genel olarak Dreamweaver eklentileri üzerine kısa bir yazı buyrun...
Yorumlar
Henüz hiç yorum eklenmemiş
Yorum ekleyebilmek için öncelikle üye girişi yapmanız gerekmektedir