Toplam Okunma 21
Giriş
Bildiğiniz gibi 21 Haziran 2025 tarihinde yayınlanan bir kararnameyle Tüm kamu ve özel sektördeki web sayfaları ve mobil uygulamaların WCAG2.2 düzey a kriterlerine göre erişilebilir olması artık Türkiye’de de bir zorunluluk. Her Ne kadar Avrupa Birliği, Amerika ve Kanada gibi ülkelerde erişilebilirlik için en az AA düzeyinde bir erişilebilirlik zorunluluğu olsa da başlangıç için ülkemizdeki bu adım da çok Kıymetli. İyi de nedir Bu WCAG derseniz, Aslında W3 konsorsiyumu tarafından yayınlanan ve dünyada kabul gören Web İçerik Erişilebilirlik kılavuzu WCAG. Bu kılavuz Bir web sayfası veya mobil uygulamanın erişilebilir olması için çeşitli başarı kriterleri belirlemiş. Bu kriterleri de 3 kategoride ele almış. Düzey A dediğimiz kriterler bir sayfada olmazsa olmaz olan öğeler. Eğer bu kriterler yerine getirilmezse, sayfanın engelliler gibi tipik bireylerden anlamlı ölçüde farklı gereksinimi olan kişilerce kullanımı ve etkileşimi neredeyse imkânsız hale geliyor. İkinci kategorideki başarı kriterleri Düzey 2 A olarak niteleniyor. Esasında buralardaki kriterlerin de yerine getirilmesi oldukça gerekli Renk kontrastları, sesli betimleme gibi öğeler bu başarı kriterleri içinde yer alıyor ve Avrupa ve ABD’de bu kriterleri yerine getirmek bir zorunluluk. Üçüncü Kategori ise Düzey 3 A olarak tanımlanıyor. Bu grup daha çok bir tavsiye, sayfa ve uygulamalar buradaki kriterleri de yerine getirirse bir En iyi deneyim sürecini yaşatıyor kullanıcılara. Yasal bir zorunluluk olmamakla birlikte, iyi bir kullanıcı deneyimi açısından buradaki kriterleri de göz önünde bulundurmak yararlı olacaktır.
Ben bu yazıda Ülkemizde bir zorunluluk haline gelen düzey A başarı kriterlerini ele alıp bu kriterlerin hangi açıdan önemli olduklarını anlatmaya gayret edeceğim.
Buraya geçmeden önce, WCAG’nin başarı kriterlerinin 4 ana prensip ve 13 ana hat altında toplandığını belirtmek yerinde olacak. İlk prensibimiz Algılanabilirlik. Sayfa ve uygulama içeriğinin tüm kullanıcılar tarafından eşit ve erişilebilir biçimde algılanmasını ele alıyor. Metin dışı tüm içeriklerim metinsel bir karşılığının olması, Süreli medyalarda Altyazı, transkript ve sesli betimleme desteğinin sağlanması, Metin içeriklerinde liste, paragraf ve başlıkların doğru belirtilmesi, yalnızca renk, şekil veya ses kullanımından kaçınılması, renk kontrastının sağlanması bu prensibin başarı kriterleri arasında.
İkinci prensibimiz Operable adını taşıyor. Yani işlem yapılabilirlik. Burada tüm kontrol ve etkileşim gerektiren alanlara klavye veya fiske hareketiyle ulaşılması ve boşluk, enter, çift dokunma gibi yollarla buralara tıklanabilmesi, kullanıcıya işlemleri için yeterli sürenin tanınması, sayfalarda nöbetlere yol açabilecek 1 saniyede 3’ten fazla yanıp sönen flaşlardan kaçınılması, kullanıcının sayfa ve uygulama içinde seri biçimde dolaşabilmesi, işlemlerde yalnızca hareket veya birden fazla parmakla yapılabilen alanların alternatifleri olması gibi başarı kriterleri var.
Üçüncü kriterimiz anlaşılırlık (understandable) adını taşıyor. Sayfa dilinin ve kısmi değişikliklerin kodlarda belirtilmesi, form alanlarında kullanıcıya öngörülebilir ve sürprizlerden uzak bir yapı sunulması, Form alanlarının doğru biçimde etiketlenmesi ve olası hataların kullanıcıya anında ve kolay biçimde gösterilebilmesi gibi kriterler bizi bekliyor.
Robust, sağlamlık adını taşıyan dördüncü prensibimiz ise sayfaların yardımcı teknolojilerle uyumlu olmasını kapsayan bir kriterler bütünü. ccSayfadaki özel arayüz bileşeni olarak eklenen düğme, bağlantı, onay kutusu gibi elementlerin isim, rol ve değerlerinin HTML standartlarında yardımcı teknolojilerin anlayıp kontrol edebileceği biçimde düzenlenmesini kapsıyor.
Aşağıda yukarıda kısa bir özetini paylaştığım ve 4 prensip altında toplanan 31 Düzey A başarı kriterinin detaylı açıklamasını bulacaksınız. Her başarı kriterini ele alırken, taşıdıkları önem, iyi ve kötü örnekler ile yerine getirilmesi için gerekli olabilecek olası teknik çözüm önerilerine de yer vermeye çalıştım.
Metin dışı içerik her türlü resim, simge, ses kaydı, video gibi tüm içerikler metin dışı olarak kabul ediliyor. Tüm bu içeriklerin metinsel bir karşılığı olması gerekli. Neden metin diye sorulabilir elbette. Sebep bir şeyi metin olarak sağladığınızda, bunu farklı formatlara dönüştürmek çok daha kolay. Örneğin bir TTS ile o metni kişi sesli olarak dinleyebilir veya Braille ekranı varsa, onu parmaklarıyla okunabilir. Yani Metin aslında bilgiyi farklı duyu organlarına sunabilmenin bir anahtarı. O nedenle örneğin sayfanızda bir resim varsa ve içerikle ilgili önem taşıyorsa, ona bir alt açıklama eklemeniz gerekiyor. Veya örneğin bir mesaj gönderme düğmesini yalnızca bir zarfla gösterdiyseniz ve buna mesaj gönder şeklinde bir metin etiketi koymadıysanız, bu kriteri ihlal etmiş oluyorsunuz.
Bu kuralın sıkça ihlal edildiği durumlardan birisi de Captcha sistemleri. Resimdeki harfleri girmek veya bir şeyi doğru sırada yerleştirmek gibi insanı robotlardan ayıran bir güvenlik tedbiri. WCAG bunu hiç kullanmayın demiyor ama farklı duyusal alternatifler de sağlayın diyor. Tabi burada da yapmış olmak için yapmamak önemli. Bir Captcha var ancak onu sesli dinlemek için kullanılan sistem İngilizce. Bu durumda İngilizce bilmeyen bir kullanıcı yine işlemine devam edemediği için açık bir kural ihlali söz konusu. Captcha’lar için önerilen bir başka yöntem de eğer kişi bir yere kullanıcı adı ve şifre girdiyse, artık onun bu kısımdan geçebilmesi. Tabi son dönemlerde çıkan ben robot değilim onay kutuları da önemli bir çözüm. Burada şunu anlamamız önemli. Bir kriteri karşılamanın tek bir yöntemi yok. Birden fazla kendinize uygun yöntemle erişilebilirliği sağlayabilirsiniz.
Yukarıda da bahsettiğimiz üzere, bir tek resim ve ikonlar değil, bir konuşma ses içeriği veya video da aslında metin dışı bir içerik ve diğer başarı kriterlerinde de ele alacağımız üzere bunlara da altyazı transkript veya betimleme metni eklemek bir zorunluluk.
Teknik açıdan bu kriteri karşılamanın en kolay yolu bir resme alt =”” olarak bir açıklama eklemek. Bu açıklama ekran okuyucular tarafından okunabiliyor. Eğer dekoratif bir görsel varsa tırnak içinin boş bırakarak onu kullanıcıdan gizlemeniz de mümkün. iOS tarafında AccessibilityLabel ve Android için ContentDescription metin dışı öğe ve kontrollerin ekran okuyucularca anlaşılması için en yaygın kullanılan çözümler arasında.
1.2.1 Yalnız Ses ve Yalnız Video (Önceden Kaydedilmiş)
Diyelim sayfanıza kaydedilen bir konferans kaydını ses olarak koydunuz. Ya da içeriği açıklayan sessiz bir görsel animasyon videosu koydunuz. İşte bunlar yalnız ses ve yalnız video örnekleri. Yapmanız gereken şey, eğer bir ses kaydı koyduysanız buna bir altyazı eklemek ya da Konuşma transkriptini hemen içeriğin altından ayrı bir bağlantı veya bölüm olarak sağlamak. Transkript içinde bir tek konuşmalar değil, varsa ses efektlerinin de açıklamalarının yer alması gerekiyor. Animasyon için gibi, betimlemeyi görseli açıklayan bir sesli betimleme yapacağınız gibi, betimlemeyi tıpkı transkript gibi ayrı bir metin olarak hazırlayıp videonun hemen altına koymanız gerekiyor. Yani bir sayfaya yalnızca podcast koyduğunuzda ve buna bir alternatif sağlamadığınızda yasal bir erişilebilirlik ihlali yapmış oluyorsunuz. Herhangi bir içeriği yalnızca sessiz bir video olarak sağladığınızda da aynı ihlal geçerli.
Teknik açıdan birçok medya oynatıcı içeriğe altyazı eklemenize izin veriyor. Youtube gibi platformlar, içeriğe ayrı bir dosya olarak sesli betimleme eklemenize de izin veriyor. Yukarıda da belirttiğim üzere tek bir çözüme mahkûm değilsiniz, önemli olan başarı kriterin sağlamak için karar vermeniz, kalanını yolda öğreneceksiniz.
1.2.2 Altyazılar (önceden kaydedilmiş)
Önceden kaydedilmiş ve içinde hem ses hem video olan içeriklerde tüm ses içeriği için altyazı sağlanması gerekiyor. Ses içeriğiyle kasıt bir tek konuşmalar değil, videoda yer alabilecek, alkış, kahkaha, kapı zili sesi gibi sesle anlaşılan her şey bu içeriğe dahil.
Özellikle işitme engelli bireyler için önemli olan bu kriter, bulundukları ortamda videonun sesini açma imkânı olmayan kişiler için de oldukça faydalı. Ayrıca yapılan araştırmalar öğrenme güçlüğü olan kişilerin altyazılardan ciddi ölçüde fayda gördüklerini ortaya koyuyor.
Teknik açıdan, kullandığınız medya oynatıcısının altyazı açıp kapamayı desteklediğinden emin olun. Yalnızca otomatik altyazılara dayanmayın.
1.2.3 Sesli Betimleme veya Medya Alternatifi (Önceden Kaydedilmiş)
İşitme engellilerin videolardaki ses içeriklerine erişim ihtiyacı gibi, görme engelli kullanıcıların da videolardaki görüntü içeriğinin betimlenmesine ihtiyacı vardır. Bu amaçla, başarı kriteri, mevcut videoya konuşmaların olmadığı anları betimleyen ek bir ses eklenerek sesli betimleme yapılmasını ya da tüm videonun ayrıntılı olarak betimlendiği bir alternatif betimleme metni oluşturulmasını zorunlu kılmaktadır.
İçinde grafiksel açıklamaların yer aldığı bir sunum videosu olduğunu ve burada birçok yazı olduğunu hayal edelim. Böyle bir videoya sesli betimleme ya da alternatif betimleme metni eklenmediği taktirde, görme engelli kullanıcı görsel bilgiye erişemeyecek ve kural ihlali yaşanmış olacaktır.
Teknik açıdan, Youtube gibi platformlarda sesli betimlemenin ayrı bir ses dosyası olarak videoya eklenmesi mümkün. Ayrıca iOS ve Android için mevcut bir videoda varsa sesli betimlemeyi açıp kapamak da mümkün. Burada yapılması gereken sesli betimleme veya alternatif betimleme metnine mutlaka içerikte yer vermek.
1.3.1 Bilgi ve İlişkiler
Bir içerikte başlıkları yalnızca yazı tipini kalın ve büyük yaparak belirttiniz, listeleri sadece başlarına tire işareti koyarak kurguladınız ve tablolarda Görsel olarak bir satır sütun düzeni oluşturdunuz. Tün bunlar bilgi ve ilişkiler kriterinin ihlali anlamına geliyor. Çünkü bu kriter sayfa yapısının yardımcı teknolojilerin anlayabileceği biçimde kodlanmasını gerektiriyor. Yani sayfadaki başlık, liste, tablo gibi öğelerdeki yapısal ilişkilerin yalnızca görsel sunumla değil HTML semantiğiyle de programlanabilir biçimde gösterilmesi bekleniyor.
Kişi sayfanın sitilini tamamen değiştirebilir, bu durumda da sayfadaki başlık, tablo ve listeleri anlayabilmelidir. Onun için de başlıklar için yalnızca kalın ve büyük punto yapmak yerine <h1” ile <h6> arasındaki etiketler de kullanılmalıdır. Böylece kullanıcı ekran okuyucusu aracılığıyla metnin farklı bölümleri arasında hızla dolaşabilir veya başlıkları listeleyerek istediği bilgiye çok daha kolay erişir.
Aynı şekilde içerikte bir liste ve alt listeler varsa yardımcı teknolojilerin bunu anlayabilmesi için <ul> ve <li> etiketleri kullanılmalıdır.
Tablolarda veri hücreleri için <td> başlık hücreler için de <th> etiketleri olmalıdır. Bu şekilde kullanıcı herhangi bir hücreye geldiğinde o hücrenin hangi satır veya sütuna ait olduğunu anlayacaktır.
Dikkat ederseniz, felsefemiz aynı: kullanıcının içeriği algılaması. Bu ister bir resim ister bir ses veya video olsun veya bir liste veya tablo, bunu her kullanıcının algılaması için yalnızca görsel veya işitsel sunum yetmez. Alt metinler ve semantik programlamada bir karşılığının da olması gerekir ki, yardımcı teknolojiler onu algılasın ve kullanıcıya gösterebilsin.
1.3.2 Anlamlı Sıra
Sayfada iki sütunlu bir metin olduğunu varsayalım. Bu metin içinde yön tuşlarıyla dolaşırken, ekran okuyucu önce ilk sütunun ilk satırını, sonra da ikinci sütunun ilk satırını size okudu. Bir anda alakasız bir metinle karşı karşıya kaldınız. Bir başka örnekte bir form doldururken tab ile ilk soruyu okudunuz ve bir kez daha taba bastığınızda o sorunun değil de bir sonraki sorunun yanıtına ulaştınız. İşte bu örnekler anlamlı sıra ihlalini gösteren durumlar. İçeriğin anlamı sunum sırasına bağlıysa odak ve okuma sırası mantıklı, doğru ve sezgisel olmalıdır.
Bu maddenin önemini anlayabilmeniz için şu noktayı bilmelisiniz. Bir web sayfasında içerik çok sütunda, sağlı sollu görülse bile yardımcı teknoloji kullanan bir kişi bunu lineer bir sırada, yani tek bir sütunda görür. O yüzden görsel sıralama sizin için önemliyse, kişi klavyesinden yön tuşları ve tab ile gezerken de görseldeki aynı sırayı takip edeceğinden emin olmalısınız. Yani kişiden önce ilçe, sonra şehir sonra ülke seçmesini istiyorsanız, taba basıldığında İlçeden ülke seçimine, sonra şehir seçimine geçiliyorsa, bir problem var demektir. Bu problem tablo yapısıyla oluşturulan çeşitli formlarda ortaya çıkma potansiyeline sahip. Sırasıyla birden fazla kişinin ad, soyad, telefon ve adres bilgilerini isteyen bir form olduğunu varsayalım. Tablo olarak bakıldığında her şey düzgün görünebilir ama tab ile gezilirken önce birinci kişinin adı sonra ikinci kişinin adı sonra üçüncü kişinin adı doldurulduktan sonra telefon numaralarına geçiliyorsa, bu, kullanıcının kafasını karıştırır.
Teknik olarak burada dikkat etmeniz gereken en önemli nokta CSS sırasıyla kod sırasının aynı olmasıdır. Yardımcı teknolojiler koddaki sıralamayı esas alacaktır. O nedenle kod sıralamasındaki tutarsızlıklar doğrudan kullanıcıya yansır. Test sırasında mutlaka tab sırasıyla sayfada dolaşıp mantıksız bir sıralama olup olmadığını kontrol etmeniz yararlı olacak.
Mobil uygulamalar için mantıklı sıralamayı düzenlemede Android tarafında android:accessibilityTraversalAfter/before kodları işinize yarayacaktır. iOS için ise UIAccessibilityContainer ile sıralamayı özelleştirmek mümkün olabilir.
1.3.3 Duyusal Özellikler
Kayıt için kırmızı düğmeye basın. Arama yapmak için sağdaki uzun kutuya girin. Devam etmek için sağ alttaki yeşil düğmeye tıklayın. Ding sesi duyunca bırakın. Tüm bu ifadeler önemli bir kuralı yok sayıyor. İçeriği gösterebilmek için tek bir duyusal özelliğe başvurmak. Bir şeyi tarif ederken yalnızca, renk, şekil, konum ya da sesine göre kullanıcıya talimat verdiğinizde, bazen bir görme engelliyi, bazen bir renk körünü, bazen bir işitme engelliyi dışlamış oluyorsunuz.
İşte duyusal özellikler başarı kriterinin amacı talimat verirken yalnızca bir duyusal özelliğe dayanmamak. Yani devam etmek için sağdaki yeşil düğme demek yetmez. Ama devam yazan sağdaki yeşil düğme dediğimizde daha kapsayıcı bir tasarıma kavuşmuş oluyoruz. Burada şu noktayı gözden kaçırmayalım. Kriter hiç renk, şekil, konum veya ses kullanmayın demiyor, yalnızca bunları kullanmayın diyor. Yani kayıt yazan kırmızı düğme, ileri yazılı ok simgesi. Bittiğinde dur yazan ding sesi gibi. Böyle yaptığımızda farklı duyusal özellikleri olan kişileri de içeriğimizi kullanabilir hale getirmiş oluyoruz.
Bu durum form alanları için de geçerli, doldurulması zorunlu alanları yalnızca kırmızı ile belirttiğimizde, yine bir renk körünü dışlamış olabiliriz. Ama hem * işareti hem kırmızıyı kullandığımızda bu sorunu çözmüş oluruz.
Teknik açıdan burada metin etiketleri oldukça önemli olacaktır. İleri düğmesini bir ok simgesiyle belirttiyseniz, ona bir aria etiketi ile ileri de yazmalısınız. Mobil tarafta da bu tür durumlar için Accessibility-label ve ContentDescription kodları önem taşıyacaktır. Ayrıca mobil tarafta bir bildirimi yalnızca sesle yapmak yerine titreşim ve yazıyla da belirtmelisiniz.
1.4.1 Renk Kullanımı
Satışların kırmızı, giderlerin maviyle gösterildiği bir grafik. Zorunlu alanların yalnızca Kırmızıyla gösterildiği bir form alanı. Dolu ve boş koltukların sadece renkle gösterildiği bir biletleme ekranı. Tüm bu örnekler yalnızca renk kullanımından kaynaklı ihlalleri temsil ediyor. Başarı kriterimize göre bir içeriği anlatmak için yalnızca renk kullanımından kaçınılmalı. Elbette renk de bilgiyi iletmek için kullanılmalı, ama yanına ek etiket veya desenlerde eklenmeli.
Grafik örneğimize geri dönersek veri setlerini kırmızı ve mavinin yanında farklı desenlerdeki çizgilerle de belirtebiliriz veya metin etiketleri ekleyebiliriz. Form alanları için daha önce de belirttiğimiz üzere zorunlu alanları kırmızıyla birlikte bir yıldız işareti veya farklı bir desenle gösterebiliriz. Boş ve dolu koltukları ayırt etmek için renklerin yanında dolu koltukların içine bir çarpı işareti de ekleyebilir, bunlara aria etiketleriyle boş dolu diyebiliriz.
Teknik açıdan web sayfalarında renkle vurgulanan her bilgi için görsel veya metinsel ipucu eklenmelidir. Hata mesajlarını yalnızca kırmızı yapmak yerine yanında bir ikon veya ünlem gibi bir şey de bulundurulmalıdır. Seçili bir menü öğesi belirtilirken sadece arka plan rengini değiştirmek yerine css ile ikili gösterge kullanılarak hem renk hem simgenin değişmesi sağlanmalıdır. Mobil kullanıcılar bazen tek renk filtresi kullanabiliyor. O nedenle bir şeyi gösterirken renk harici ipuçlarının halen çalıştığından emin olmalısınız. Yine mobil tarafta etkin bir butonu sadece yeşil renkle göstermenin yanında ona açık tarzı bir etiket veya farklı bir ikon da ekleyebilirsiniz.
1.4.2 Ses Kontrolü
Bir sayfa veya uygulamaya girdiğiniz anda başlayan ani bir reklam ya da tanıtım müziği. Aslında pek çok kişi için istem dışı gelen rahatsız edici bir durum. Ancak ekran okuyucu kullanıcıları için mesele rahatsızlığın da ötesinde. Kullanımı imkânsız hale getirebiliyor. Çünkü gelen üçüncü ses ekran okuyucu sesiyle karışıyor ve işlem yapmak imkânsız hale gelebiliyor. Başarı kriterimize göre bir sayfa açıldığında 3 saniyeden daha uzun süren bir şey çalıyorsa, bu kullanıcı tarafından hızla kapatılabilmelidir.
Hızla kapatılabilmeyi açarsak, mutlaka bir klavye erişimi bulunmalıdır ve bu kapatma kontrolü sayfanın hemen en üstünde yer almalıdır. Mümkünse bu tarz otomatik açılan müzikleri hiç kullanmayın veya ille de kullanacaksanız sessi halde başlatın ve dilerse kullanıcı sesi açsın. Bunu da istemiyorsak o zaman kolayca kapatılabilecek bir mekanizmayı mutlaka sürece dahil edin.
Teknik açıdan açılan sesin kapanacağı kontrolü sayfanın en başında bulunması için tabindex=0 kullanımı öneriliyor. Mobil tarafta ise medya oynatıcıya sesi tamamen kapatabilecek veya ses düzeyini sistem sesinden bağımsız kısıp açabilecek kontrollerin eklenmesi öneriliyor.
2.1.1 Klavye
Bir form doldurdunuz ve sonundaki sözleşmeyi kabul ediyorum bölümüne bir türlü enter ya da boşluk ile tıklayamıyorsunuz. Ya da gönder düğmesine tab ve oklarla bir türlü gelinemiyor. Mobil cihazınızda sonuçları filtreleme düğmesine fiske hareketleriyle gelemiyorsunuz. Evet en temel erişilebilirlik meselesinden söz ediyoruz: klavye erişimi. Bir sayfa veya uygulamadaki her alana klavye veya klavye emülasyonu olarak kullanılan cihazlarla gelinmesi çok temel bir zorunluluktur. Yani bir düğme veya etkileşimli alana yalnızca fare kullanılarak geliniyorsa veya buraya klavyeyle gelinse bile enter, boşluk çubuğu veya dokunmatik ekranlarda çift dokunarak burası etkinleşmiyorsa çok ciddi bir kural ihlalinden söz ediyoruz demektir.
Bu kuralın bir tek istisnası var: Fareyle çizim yapılan uygulamalar. Buralarda bile örneğin L harfiyle çizimi etkinleştirip oklar yardımıyla çizim yapma gibi seçenekler öneriler arasında.
Klavye erişiminde kullanıcıyı en çok zorlayan alanlardan birisi üzerine fare ile gelindiğinde çıkan yeni içerikler. Buralar için bir klavye erişimi konulmazsa, fare kullanamayan kişilerin buraları açabilmeleri mümkün olmuyor. Tüm onay kutularının boşlukla da işaretlenebilmesi, form alanları arasında tab ve Shift+Tab ile gezilebilmesi, form alanlarında çıkan radyo düğmeleri ve seçim kutularındaki öğeler arasında yön tuşlarıyla gezilebilmesi bu alandaki önemli ihtiyaçlar arasında.
Klavye maddemizi mobil uygulamalar açısından fiske hareketi ve çift dokunma olarak da ele alabilirsiniz. Bir mobil uygulamada tüm kontrollere fiske hareketiyle de gelinebilmesi en temel erişilebilirlik özellikleri arasında yer alıyor. Tüm seçeneklerin bir arada okunduğu bir menü kontrolü düşünün. Buradaki imkânsız bir seçeneğe tıklamak imkânsız hale geliyor ekran okuyucu kullanıcıları için. O yüzden bu tür alanlarda her seçeneğe ayrı ayarı Accessibility-label atamak ve onları tek container içinden çıkarmak önem taşıyacaktır. Yine mobil taraf için yalnızca kaydırıldığında ortaya çıkan bir sil butonu varsa, mutlaka fiske ile de ulaşılabilecek bir sil butonu olması önemli olacaktır.
Klavye erişimi bir tek görme engelli ekran okuyucu kullanıcıları için önem taşımıyor. İnce motor becerileri etkilenen kullanıcılar da fare yerine klavye ya da ses kontrolüyle sayfalarda dolaşıyor. Ayrıca anahtarlı denetimle yalnızca başlarını vs hareket ettirerek cihaz kullanan kişiler de var. Tüm bunlar için her kontrole klavye ve klavye gibi hareket eden sistemlerle erişim çok hayati bir erişilebilirlik maddesi.
Teknik açıdan web sayfalarındaki tüm etkileşimli öğeler, bağlantı, düğme, form alanları, medya kontrolleri tab indexine dahil olmalıdır. <button< ve <ahref< gibi etiketler zaten otomatik odak alacaktır. Ama özelleştirilmiş tıklanabilir <div< gibi elementleriniz varsa onlara tabindex=”0” ekleyip keydown olaylarıyla enter, boşluk gibi tuşlara tepki vermelerini sağlayın. JavaScript ile işlemler kurguladıysanız, mutlaka bunlara da enter, boşluk, escape gibi uygun klavye olaylarını eklemeyi unutmayın.
Mobil tarafta Android için focusable özellikleri doğru kullanılmalıdır. iOS için UIAccessibility özellikleriyle her kontrolün odaklanabildiğini ve etkinleştirilebildiğini kontrol edin.
2.1.2 Klavye Tuzaklarından Kaçınma
Bilet alırken tarih seçim için tab ile takvim alanına girdiniz ki, ne göresiniz artık başka hiçbir yere gidemiyorsunuz, tab, Shift+Tab sadece tarihler arasında dolaşıyor. Oraya hapsoldunuz sayfanın geri kalanını göremiyorsunuz. Ya da sayfada bir harita içine geldiniz. O da ne! Oklar tab tuşları yalnızca haritada geziyor. Sizi bir kara delik gibi yutmuş gömülü uygulama çıkmanın hiçbir yolu yok.
Klavye tuzaklarını kapsayan başarı kriterimiz sayfa içinde hareket ederken hiçbir odaklanabilir bileşenin kullanıcıyı içine hapsedecek şekilde davranmamasını düzenliyor. Elbette, takvim, harita veya iFrame gibi gömülü bir sistem sayfalarımızda olabilir. Ancak buraya odaklanıldığında Kullanıcıya çıkış için bir kısayol da belirtilmelidir. Örneğin çıkmak için Escape veya Ctrl+X tuşlarına basmak gibi. Başka bir yöntem tab ile devam edildiğinde son element sonrası sayfaya geri dönüşün garanti altına alınmasıdır. Yine de içinde pek çok kontrol olan bir noktada buradan derhal çıkışı sağlayabilecek Escape tarzı bir kısayol oldukça gerekli olacaktır. Örneğin bir havayolu sitesinde yolcu bilgileri alanına girildiğinde, buradan tek tek yetişkin, bebek, çocuk, engelli gibi yolcu tipleri belirlenebilmektedir. Kişi2 yetişkin olarak uçacaksa, kalan tüm kontrolleri tek tek gezmek zorunda kalmadan escape ile burayı kapatabilmelidir.
Mobil uygulamalarda ise genellikle durumun tam tersi yaşanabilmektedir. Karşımıza bir uyarı ekranı açılabilir ama ekran okuyucu kullanıcısı bu uyarı ekranının yanında kalan tüm uygulamayı da görmeye devam ettiği için esas uyarıyı kaçırma tehlikesiyle karşılaşabilmektedir. Bu tür durumlar için uygulama ekranının gizlenip yalnızca uyarı ve onu kapatacak tamam, kapat gibi düğmelerin yer aldığı ekranın kişiye gösterilmesi sağlanmalıdır. Bunun için iOS tarafında pop-up ekranlarının AccessibilityTrait özellikleri isModal olarak ayarlanarak kalan ekran kullanıcıdan gizlenmelidir. Android’de focusableInTouchMode ve focusTraversalPolicy gibi ayarlarla buraları kontrol edebilirsiniz.
Teknik açıdan web özelinde özel bileşenler (iframe, applet, custom React modal vs.) kullanırken, klavye ile oraya girip çıkmayı deneyin. Odak içeride takılı kalıyorsa buraya tabindex=”0” eklemeniz yararlı olabilir. Ama döngüyü kırmak için escape veya kapat tuşunu da mutlaka eklemelisiniz. Flaş tarzı sistemlerde odak içeriği kaybettiğinde buradan otomatik çıkış için api kullanabilirsiniz.
Mobil tarafta yukarıda anlattıklarımıza ek olarak pop-up kapandığında odağın en son kalınan yere geleceğinden emin olun.
2.1.4 Karakter Kısayol tuşları
Yazı yazmak için bir konuşma tanıma uygulaması kullanıyorsunuz. Yazma alanına selam yazarken birdenbire mevcut iletinin silindiğini fark ettiniz. Çünkü S harfi uygulamada e-postaları silme için tek karakter kısayol tuşu olarak atanmış.
Karakter kısayol tuşları, belirli kullanıcılar için oldukça yararlı gibi görünebilir, ancak ellerini kullanamayan konuşma tanımayla yazı yazan kişiler için bir kabusa dönebilir. O nedenle WCAG bu tarz kısayol tuşları varsa, mutlaka bunları kapatma veya değiştirme seçeneğinin sunulmasını zorunlu kılmaktadır. Bir başka öneri ise, bu tuşların yalnızca ilgili bağlamda aktif olması seçeneğidir. Örneğin bir tweet sayfasında gönderileri beğenmek için L tuşu kullanılabilir. Ancak bu tuş yalnızca bir gönderi seçiliyken aktifse ve herhangi bir yazma alanına müdahale etmiyorsa, başarı kriteri sağlanmış olacaktır.
Teknik açıdan burada yapılması gereken tek harfli karakter tuşlarını kapatma veya değiştirme seçeneğini sunmak olacaktır. Böylece dikte yöntemini kullanan, klavyeyi tek elle yöneten kullanıcıların yaşayacakları mağduriyetin önüne geçilmiş olur.
2,2.2.1 Zamanı Ayarlama
Bir alışveriş sırasında tam her şeyi sepetinize attınız ki, birden sayfa kapandı. Meğerse süreniz dolmuş. Her şeyi baştan yapmanız gerek. Tam bilet almak için tüm adımları tamamladınız i, ödeme yapamadan uygulama kapandı. Üstelik hiçbir uyarı olmaksızın. Benzer durumlar pek çok engelli kullanıcının yaşadığı deneyimler. Nedeni ise zamanı ayarlama kriterinin ihlal ediliyor oluşu. İçerik bir zaman sınırını içeriyorsa, (oturum zaman aşımı, sınav süresi, otomatik ilerleyen slaytlar) gibi, kullanıcıya bu zamanlayıcıyı kapatma, uzatma veya ayarlama imkanlarından en az biri verilmelidir.
WCAG tavsiyelerine göre süreli bir işlem söz konusuysa kullanıcıya mevcut süreyi en az 10 defa uzatabilme ve her pop-up çıktığında 20 saniye tıklama süresi verilmesi öneriliyor. Yeterli süre ekran okuyucu kullanan kimseler açısından çok kritik. Çünkü içeriği bir taraftan dinleyip diğer taraftan işlem yapmak yavaş bir süreç olabiliyor ve siz süre nedenli bir kısıt koyduğunuzda kişi haksız bir rekabet içinde kendini bulabiliyor. Aynı şekilde, bir form doldururken, ince motor becerileri, anahtarlı denetim kullanımı gibi nedenlerle çok daha yavaş yazma nedeniyle de bazı kimseler çok daha fazla süreye ihtiyaç duyuyor. O nedenle süreyi ya tamamen durdurma, duraklatma veya 10 katına kadar artırabilme seçeneğin çok önemli.
Teknik açıdan sabit bir süre söz konusuysa baştan bu sürenin değiştirilmesi seçeneği de yararlı olabiliyor. JavaScript ile settimeout ve modal uyarılarla süre uzatma işlemi yapılabilmekte.
2.2.2 Duraklat, Durdur, Gizle
Bir haber sitesinde bulduğunuz bir haberi okurken kenarda sürekli kayıp güncellenen haber şeridi gözünüze takılıyor. Başka bir sitede maç skorları o kadar hızlı akıyor ki, takip edemiyorsunuz. Girdiğiniz bir alışveriş sitesinde tam slayttaki kampanyayı okurken birden slayt değişiyor ve detayı kaçırıyorsunuz. Özellikle DHEB yaşayan kullanıcılar için sayfadaki hareketli içerikler bazen tam bir baş belası haline gelebilir. Başarı kriterimize göre ekranda hareket eden, yanıp sönen, kayan veya otomatik güncellenen herhangi bir bilgi varsa ve bu hareket/yenileme 5 saniyeden uzun sürüyorsa, kullanıcıya bu hareketli içeriği duraklatma, durdurma ya da tamamen gizleme seçeneği sağlanmalıdır.
Yani kullanıcı isterse sayfadaki hareketli içeriği durdurabilmelidir ki, onun dikkat dağıtıcı etkisinden kurtulabilsin.
Bu kriter DHEB kadar az gören kullanıcılar açısından da ciddi bir sorun oluşturabiliyor. Özellikle sürekli akan bir slayt gösterisinde okuma hızı büyütme ve diğer nedenlerle yavaşlayabileceğinden durdurma veya duraklama seçeneği sağlanmadığında kişi içeriği algılayamaz veya eksik algılar. Ekran okuyucu kullananlar için de bu otomatik güncellemeler sorun yaratma potansiyeline sahip. Tam bir makale okurken dikkatinizin toplandığı bir anda otomatik olarak bir haber güncellemesi duymak en hafif tabiriyle hiç hoş değil. Burada amaç herkese sayfanın sabit bir anında kalarak içeriği okuma şansı vermektir.
Teknik açıdan web sayfanızda hareketli bir içerik (marquee, CSS animasyon, otomatik slider, vs.) buraya mutlaka bir kullanıcı kontrolü eklemelisiniz ve buna klavye erişimi de sağlamalısınız. Böylece kullanıcı isterse animasyonu durdurabilir veya duraklatabilir. JavaScript ile kayan bir metin yaptıysanız, bunu durdurabilecek bir fonksiyon yazıp bir butona bağlamalısınız. Bir otomatik slayt gösterisini sadece kullanıcı istediğinde ilerleyecek şekilde de kurgulayabilirsiniz. Sürekli güncellenen bir canlı skor varsa, en azından kullanıcıya güncelleme süresini ayarlama şansı verebilirsiniz. Her 20 saniyede bir gibi.
Mobil tarafta eğer bir durdurma butonu yerleştirmek çok kolay değilse, en azından hareketi durduracak bir parmak hareketi belirleyip bunu kullanıcıya belirtebilirsiniz. Bir de mobil sistemlerin erişilebilirlik ayarlarında azaltılmış hareket tercihleri bölümü bulunmakta. Hareketli içeriğinizin burayla uyumlu çalıştığından emin olmanız da önerilebilir.
2.3.1 Işıktan az veya eşik altı uyarılar
Tarih 16 Aralık 1997, yer: Japonya. Pokemon’un 38. Bölümü olan Sanal Savaşçı Porygon bölümü yayınlanıyor. Bölümün bir yerinde Pikachu gelen füzelere elektrik şokuyla karşılık verirken bir patlama oluyor ve bu esnada 4 saniye boyunca saniyede 12 kez kırmızı ve mavi flaşlar ekranda beliriyor. Sonrasında beklenmedik bir şey oluyor. Japonya genelinde 700 civarında çocuk ve yetişkin nöbet geçirerek hastanelere kaldırılıyor. Işık altı başarı kriterinin çıkış noktası bu olay. Işığa duyarlı epilepsisi olan kişilerin saniyede 3’ten fazla yanıp sönen ışıklarla karşılaştığında nöbetlerinin tetiklendiği anlaşılıyor. Bu yüzden bir web sayfasında veya uygulamada, hangi amaçla olursa olsun 1 saniyede üçten fazla yanıp sönen flaş içermemesi kuralı getiriliyor. Eğer içeriyorsa da flaşın parlaklık/renk şiddeti belirlenmiş eşiklerin altında bulunması gerektiği ortaya konuluyor.
Yapılan araştırmalar özellikle 3-50 kırmızı flaşların çok tehlikeli olduğunu göstermiştir. Bir flaş varsa bunun ekranın küçük bir bölümünü kaplaması ve süper parlak beyaz yerine daha yumuşak bir renkte yanıp sönmesinin gerektiği vurgulanmaktadır.
Teknik açıdan mümkünse hiç flaş animasyonu kullanmamak en doğru çözüm olacaktır. Uyarı vermek için ikon sallama, renk geçişini yavaşlatma gibi yöntemler de kullanılabilir. Eğer flaş olması gerekiyorsa CSS animasyonunun süresini 0.5 s veya daha uzun tutun. Kırmızı yoğunluklu yanıp sönmelerden özellikle kaçının, parlaklık değişimini sınırlandırarak siyah beyaz yerine gri tonlar kullanın ve kontrastı azaltın. Tüm bu teknik detayları WCAG’nin araçlarıyla kontrol ederek riskli olup olmadığını öğrenmeniz de mümkün.,
Mobil uygulamalarda da aynı risklerden kaçınmak için, iOS için “CAKeyframeAnimation” gibi kullanırken zamanlamaları dikkatli ayarlayın. Android’de AnimationDrawable ile frame animasyonu yapıyorsanız, süreleri >= 200ms yapın ki saniyede 5 defadan fazla bir animasyon gerçekleşmesin. Ayrıca her iki platformun hareketi azalt ayarları açıldığında animasyonların kapandığından emin olun.
2.4.1 Blokları Atla
Bir haber sitesindesiniz ve bağlantıya tıklayıp heyecanla aradığınız habere ulaştınız. Ama haberin başladığı yere klavye ile ulaşmak için 20 menü bağlantısı ve 15 popüler haber bağlantısını geçmek zorundasınız. Ne yapardınız? Çekilir çile değil mi? Sayfada kolay gezine bilirliği ele alan bu başarı kriteri, tam bu tarz sorunları adreslemeyi amaçlıyor. Her sayfada tekrarlanan menü, reklam gibi içerik blokları varsa kullanıcının bunları doğrudan atlayıp asıl içeriğe geçebilmesi için bir mekanizma bulundurma zorunluluğu var.
Bu kriteri karşılamanın en kolay yolu sayfanın en başına bir ana içeriğe atla bağlantısı eklemek. Kişi yeni bir bağlantıya tıkladığında en başta tab yapıp bu bağlantıya geliyor ve enter yaptığında doğrudan okuyacağı asıl içeriğe ulaşıyor. Ekran okuyucu kullanıcılarının yanında, bir Bluetooth klavyeyle işlemlerini klavyeden yapan birisi için de oldukça geçerli ve yararlı bir kısayol ana içeriğe atla.
Bazı durumlarda sayfada birden fazla atlama bağlantıları da bulunabilir. Birisi ana içeriğe, diğeri indirme bağlantılarına, bir başkası iletişim bölümüne gitmemizi sağlayabilir. Burada önemli olan bağlantıların çalışıyor olması. Onun için de doğru yere referans verilmesi önemli.
Burada kişisel bir not düşmek istiyorum. Her ne kadar başarı kriteri bir ana içeriğe atla mekanizmasını zorunlu kılıyor olsa da ve bazı durumlarda bu gerçekten geçerli olsa da birçok kullanıcı bu bağlantılar yerine sayfadaki bölümlere <h1> etiketiyle oluşturulan başlıkları kullanarak ulaşmayı tercih ediyor. O nedenle asıl içeriğin olduğu yerin <h1> ile etiketlenmesi çok kritik bir konu. Ayrıca buraları birer bölge olarak tanımladığınızda, artık yardımcı teknolojiler landmark dolaşımıyla da buralara hızlı erişimi mümkün kılıyor. Yani Ana içeriğe atla bağlantısı olmasa bile doğru <h1 h6> kullanımları ciddi anlamda fayda sağlayacaktır. Diğer taraftan, bazı sayfa tasarımcıları olur olmadık her yere <h> etiketi koyduklarında bu kısayolun bir anlamı kalmadığını da anımsatalım. Burada gerekli olan kullanıcının en seri şekilde farklı bölümlere ulaşabilmesi.
Teknik açıdan Sayfanın en üstüne, örneğin <a class="visually-hidden focusable" href="#content">Ana İçeriğe Atla</a> bağlantısı koyduğunuzda, kullanıcı en başta bu bağlantıyı görüp ana bölüme gidebilecektir. Bu bağlantıyı css ile normalde gizleyip odaklandığında görünür yapabilirsiniz. Burada href değeriyle ana içerik id değerinin aynı olmasına özellikle dikkat etmelisiniz. Çoğu sitede ana içeriğe atla bağlantısı olduğu halde kontrol edilmediği için çalışmamakta. Belki de kullanılabilirliği o nedenle az olabilir. Bu yüzden dikkatle bağlantıyı kontrol edin. Sayfanızda birden fazla tekrarlı blok varsa, bunlara da benzersiz ID atayarak atlama bağlantıları oluşturmanız mümkün.
Mobil tarafta blok atlama olmamakla beraber, fiske hareketiyle öğelerin okuma düzenini ayarlamanız oldukça önemli olacaktır. Örneğin Bir uçuş sonucunda “kalkış, 08:00, İstanbul, varış, 09:10, Ankara” öğelerinin her birinin ayrı ayrı okunduğunda yaşanacak zaman kaybını bir düşünün. Halbuki Android’de ViewGroup.setAccessibilityTraversalBefore/After ile iOS tarafında da UIAccessibilityContainer ile tüm bu öğeleri gruplayarak tek bir seferde okunmasını sağlayabilirsiniz. Böylece birden fazla etkinleştirme olmayan ve birbiriyle ilişkili bir parçayı tek bir seferde anlamak mümkün olur. Önemli olan kullanıcının en hızlı ve anlamlı biçimde içeriği okuması ve bloklar arasında dolaşmasıdır.
2.4.2 Sayfa Başlığı
Bir market sitesinde ayrı sekmelerde elma, portakal, şampuan ve kahvaltılık sayfaları açık. Sekmeler arasında dolaşmaya kalktığınızda başlık olarak tek duyduğunuz X market adı. İyi de burası marketteki hangi ürünün sayfası? Sayfa başlığı (Title) çok temel erişilebilirlik kurallarından birisi. Her sayfanın içeriğinin konusu hakkında anlamlı bir başlığı bulunması gerekiyor.
Özellikle görme engelliler için açık pencere veya sekmeler arasında dolaşırken referans alabilecekleri en önemli bölüm ilgili pencere veya sayfanın başlığı. Burada yalnızca firma adı yazdığında ve bazen hiçbir şey yazmadığında, içine girip burası neresi diye ek bir araştırma yapması gerekecek. Diyelim ki, farklı sitelerde bir ürün karşılaştırması yapıyoruz. Ya da önümüzde farklı gazetelerinin farklı haberleri açık. Alt+Tab ile pencereler, ya da ctrl+tab ile açık sekmeler arasında gezinirken, o an üzerine gelinen sayfanın tam olarak ne olduğunu bilme ihtiyacı var. Bu yüzden de sayfa başlığı mutlaka içeriği de barındıran bir şekilde olmalı. Yalnızca domain adını verdiğinizde, bu, bir tek ana sayfa için anlamlı. Girilen alt sayfaların bilgisini kapsamamış oluyor.
Teknik açıdan her html sayfasının <head> bölümünde uygun bir <title> etiketi olmasına dikkat edin. Buradaki metin sayfa içeriğinin ana başlığı şeklinde kurgulanabilir. Örneğin <title>{{Makale Başlığı}} - {{Site Adı}}</title> formatı yaygın ve iyidir. CMS kullanıyorsanız Title bölümünün boş bırakılmadığından ve dinamik olarak dolu olduğundan emin olun.
Mobil tarafta Title o derece kritik olmasa da örneğin bir uygulamanın farklı sekmeleri varsa, girilen sekme adının en başta geri sonrası belirtilmesi yararlı olacaktır. Ayrıca her ekranda anlamlı bir başlık etiketi gösterin (örn. iOS NavigationBar’ın title’ı, Android AppBar’ın title TextView’i). Bu erişilebilirlik etiketleri açısından da yararlı olabilir.
2.4.3 Odak Sırası
Bir sayfada tab ile ilerlerken birden son menü öğesinden sonra kopya hakkı bağlantısına gittiniz. Sonra devam edince ortadaki arama bölümüne geldiniz. Muhtemelen arama kutusunun Tabindex değeri pozitif bir sayı verildi ve sona gitti. Ya da bir form içinde evet radyo düğmesi sonrası karşınıza birçok bağlantı çıktı ve sonra hayır geldi. Ama bu neyin hayır düğmesiydi acaba? Odak sırası kriteri, klavyeyle sayfanın gezinme sırasını ele alıyor. Eğer sayfanın gezinme sırası anlamı ve işleyişi etkiliyorsa, odaklanabilir bileşenler öyle bir sırada odak almalıdır ki hem içerik anlamı korunsun hem de işlevsellik bozulmasın. Bu noktada sizin nasıl bir sıralama öngördüğünüzün önemi yok. Örneğin önce ana içeriğin, sonra gezinim menüsünün gelmesini isteyebilirsiniz. Bu durum tasarımsal olarak sizin kararınız. Ancak buradaki görsel sırayla DOM sırası farklı olursa, yani kullanıcı içerikten sonra birden sayfanın alt bölümüne, sonra menüye geçiyorsa, bu düzeltilmesi gereken bir sorundur.
Görme engelli ve motor becerileri etkilenen kullanıcılar sayfaları element element gezer. Çoğu zaman bunu klavye ile tab ya da yön tuşlarıyla yapar. Elementler arası gezilirken içeriğin doğru bağlamıyla takibi önem kazanacaktır. Bir formu doldururken, ad, sonra adres, sonra soyad bilgisinin gelmesi mantılı bir bağlam oluşturmaz. Başka bir örnekte bir diyalog açıldı ama siz tamam düğmesi sonrası birden arka plandaki sayfanın bağlantılarını görmeye başladınız. İşte bu içeriği karmaşık hale getirir ve anlamayı zorlaştırır. Yukarıda da belirttiğimiz gibi benzer durum mobil pop-up yapılarında da yaşanabilir. Ortada bir pop-up vardır ama siz arka plandaki öğeleri görmeye devam edersiniz. Bu tarz durumlar kriter ihlalidir.
Teknik açıdan web’de en iyi çözüm HTML kod sırasıyla görsel ve anlamsal sırayı aynı tutmak olacaktır. CSS ile konum değiştirebilirsiniz ama odak sırası DOM’a göre ilerleyecektir. Tabindex kullanımında mümkün olduğunca pozitif değerlerden kaçının. Bu tür zamanlarda manuel testler daha çok önem kazanacaktır. Sayfanızda tab ile gezinin model açıp kapayın ve davranışlara bakın.
Mobil tarafta sıralama genellikle XML’deki mobil sırasına veya iOS view hiyerarşisine göre olmaktadır. Android’de android:focusOrder veya View.setAccessibilityTraversalBefore/After ile özel sıralama yapabilirsiniz. iOS’ta z-index benzeri İOS’ta veya UIAccessibilityContainer protokolü ile sıralamayı özelleştirebilirsiniz. Ama en kolayı: arayüzünüzü storyboard/XML’de mantıklı sırada tanımlamaktır. Örneğin her etiketten sonra o etiketin girdi kutusunun gelmesi gerekecektir. Voice Over veya TalkBack genellikle soldan sağa, yukarıdan aşağı okuyan bir sıra izleyecektir. İki sütunlu bir görsel tasarımda yukarıda belirttiğimiz gruplama yöntemleri işe yarayabilir.
2.4.4 Bağlantı Amacı (bağlamda)
Bir haber sitesinde bağlantıları listelediniz ve pek çok devamı adında link var. Acaba neyin devamı? Derken bir alışveriş sitesine girdiniz orada da bolca sepete ekle düğmeleri karşınızda. Neyi eklesek sepete? İşte bağlantı amacı kriteri tam bu durumlar için düşünülmüş. En kısa haliyle linkler hedef sayfanın içeriğini yansıtacak şekilde adlandırılmalıdır. Yani her bir bağlantının amacı tercihen yalnız link metninden veya etrafındaki bağlamından anlaşılmalıdır.
Görme engelli kullanıcılar sayfadaki bağlantı, düğme ve benzeri elementleri hızlı dolaşım amacıyla listeleyerek de kullanır. Bu listede de bağlantının ve düğmenin adları yer alır. Orada yalnızca, tıklayınız, devamı, detaylar, sepete ekle gibi öğeler bir fikir vermeyecektir. Bu da deneme yanılmalar nedenli ekstra bir zaman kaybı anlamı taşıyacaktır. Ayrıca arama motorları da doğru adlandırılmış bağlantılarda daha kolay hareket eder.
Teknik açıdan en doğru yöntem bağlantı adlarını açıklayıcı yapmaktır. Örneğin makale başlığını makale detayları başlığı yerine bağlantı adı yapmanız en doğru seçenek olacaktır. Tek kelimelik genel ifadelerden kaçınmalısınız. Eğer tasarım gereği “Devamı” gibi bir link kullanmanız kaçınılmazsa, bunu erişilebilir hale getirin: 1) Mesela <a href="...">Devamı<span class="visually-hidden">: [Haber Başlığı]</span></a> şeklinde gizli metin ekleyerek link metnini zenginleştirin. Bir başka yöntem ise Aria-label ile bağlantıya açıklama vermektir: örnek: <a href="..." aria-label="Haber Başlığı hakkında detayları oku">Devamı</
Mobil tarafta da benzer biçimde buton ve ikonları doğru etiketlemelisiniz. Bunun için ContentDescription/accessibilityLabel öğelerini kullanabilirsiniz.
2.5.1 İşaret hareketleri
Bir fotoğraf galerisindesiniz ve fotoğrafları yakınlaştırmanın tek yolu iki parmakla sıkıştırmak. Fotoları yakınlaştırıp uzaklaştıran + ve – butonları yok. Bir çizim uygulaması yalnızca serbest çizim imkânı sunuyor ve çizim araçları bulunmuyor. Bir web sayfasındaki harita içinde yalnızca fareyi sürükleyerek hareket etme ,- var ok tuşları veya +, - tuşları yok. Tüm bu durumlar yalnızca tek elini kullanan, motor becerileri etkilenmiş, ya da anahtarlı denetimle cihazlarını yöneten kişileri dışlıyor. İşaretçilerin doğru kullanımını amaçlayan başarı kriterimiz de benzer durumda olan kişileri korumak için ortaya çıkmış. Bir işlevi çalıştırmak için iki parmakla birden dokunma, döndürme, sürükleyip çizme gibi karmaşık veya yol izlemeye dayalı dokunmatik hareketler gerekiyorsa, bunun yerine tek bir dokunuş veya tıklamayla alternatif bir yol da sunulmalıdır.
Dokunmatik ekranların sayısı arttıkça, farklı işlevleri yerine getirmek için çok parmaklı el hareketleri ya da çizerek yapılacak hareketlerin sayısı da arttı. Ancak, her kullanıcı iki ya da daha fazla parmağını koordineli kullanamayabiliyor. Tek eli olmayanlar, protez kullananlar, motor becerileri etkilenenler, anahtarlı denetimle çalışanların dokunmatik ekranları kullanabilmeleri için tek bir dokunuşla işlem yapabilecekleri kontrollere ihtiyaçları oluyor. Bu yüzden kullanımda çok büyük etkisi olmayacaksa, örneğin bir e-postayı silmek için tek başına sola sürükleme hareketini atarsanız ve alternatif olarak ileti yanına bir çöp kutusu ikonu koymazsanız, başarı kriterini ihlal etmiş oluyorsunuz. Yani karmaşık jestler isteğe bağlı tutulmalıdır kriterimize göre. Elbette bu kriter piyano çalmak gibi birden fazla parmağın kullanımının zorunlu olduğu durumları istisna tutuyor.
Teknik açıdan daha tasarım aşamasında her çoklu dokunuş veya sürükleme işlevi için bir link, buton veya tek dokunuş alternatifi planlamalısınız. Örneğin yakınlaştırmak için + - düğmeleri planlayabilirsiniz. Sürükleyerek sıralama için öğelerin yanına yukarı ve aşağı taşıma düğmeleri de koymalısınız. Çizimlerde bazı şeylerin menüden seçilmesine olanak tanıyabilirsiniz. İki parmakla onaylama gibi hareketler için tek parmak seçeneğini de eklemelisiniz. Java ile touchstart / touchmove kullanıyorsanız, aynı işlevi click olayına da bağlayın.
2.5.2İşaretçi İptali
Bir form doldururken yanlışlıkla göndere dokundunuz ve parmağınızı hemen başka yere kaydırdığınız halde form gitti. Hay Allah, aslında telefon numarasını hatalı girmiştiniz. Dokunmatik ekranlarda başa gelen kazalardan birisidir bu. Filmlerde hep bir mesajı a kişisi yerine bir dokunuşla B kişisine gönderme sahneleri izleriz. Evrensel tasarımın temel ilkelerinden birisi hatalara karşı tolerans ilkesidir. Bunu başarı kriterimize uyguladığımızda şu tanımı göreceğiz: Kullanıcı bir yere fare ile bastığında veya dokunduğunda, oradan fareyi veya parmağını kaldırmadan işlev tetiklenmemelidir. Formu gönder örneğimize uygularsak, parmağınızı göndere dokunduğunuz an yanlış yaptığınızı fark ettiyseniz, parmağınızı başka bir noktaya kaydırdığınızda işlem gerçekleşmemelidir. Ancak basıp parmağı kaldırdıktan sonra gönder düğmesi etkinleşmelidir. Yani sistem size parmağı başka yere kaydırarak işlemi yapmama hakkı tanımalıdır. Tıklama veya dokunuş sonucu gerçekleşecek eylem, basış anında değil basış kalkınca gerçekleşmeli, kullanıcı basış sonrası parmağı kaydırarak işlemi iptal edebilmelidir. Burada da piyano örneği veya tuşa basma emülasyonu gibi durumların istisna tutulduğunu hatırlatalım.
Bu kriterle özellikle ince motor becerileri hedeflenmiş. Bazı kullanıcılar dokunurken titreme sonucu dokundukları alanı kontrol edemeyebilir. Basış anında işlemin gerçekleşmemesi kullanıcıya “gönder düğmesine basıyorsun emin misin” sorusunu düşünme imkânı verecektir. Diğer taraftan, aslında herkes zaman zaman yanlış tıklama ve dokunmalar yapabilmekte olduğundan, bu kural herkesin uygulama ve sayfalarda daha güvenli ve rahat hareket etmesini sağlayacaktır.
Teknik açıdan web’de temel kural down-event’e kritik işlevler atamamaktır. Yukarıda da belirttiğimiz gibi istisna durumlar dışında, asıl işlevi Mouse-up/touchend ya da click olayına koymaktır.
Mobil tarafta Android için zaten varsayılan durum basışta değil basıp bırakıldığında işlevin tetiklenmesi şeklinde gerçekleşir. Burada dokunmatik tıklamalarla ilgili bir işlem yaparken sürecinize ACTION_CANCEL & ACTION_MOVE: işlevlerini de dahil ederek parmak bir yere dokunup hareket ettiğinde işlemin iptal olacağını garanti altına alın.
iOS için de var sayılan olarak işlevlerin tetiklenmesi dokunup çektikten sonra gerçekleşmektedir. Buralarda da kişiselleştirilmiş görünümlerde dikkatli olmak ve basış anında değil basıp çekince işlevin gerçekleşeceğini kontrol etmek gerekecektir. Örnekteki kod parçacığı size bir fikir verebilir.
switch(event.getAction()){
case ACTION_DOWN: highlight = true; break;
case ACTION_MOVE:
highlight = isTouchInsideBounds(...); // if move out, highlight false
break;
case ACTION_UP:
if(isTouchInsideBounds(...)) performClick();
highlight = false;
break;
case ACTION_CANCEL: highlight = false; break;}
2.5.3 Etiket İçinde Ad
Bilgisayar ya da mobil cihazınızı sesle konuşarak kontrol ediyorsunuz. Dragon, siri, Google asistan gibi bir sisteminiz var. Ekranda gönder düğmesini gördünüz ve “Göndere bas” dediniz. İlginç, hiçbir şey olmadı. Tekrar denediniz, değişiklik yok. Sonra “submit” dediniz, birden göndere basıldı. Meğerse görünen etiket ve koddaki etiket farklıymış. Etiket içinde ad kriterimiz cihazlarını sesli komutlarla kontrol edenlerin ihtiyaçlarına kulak veriyor. Altın kural şu: eğer bir arayüz bileşeninin görünen bir metin etiketi varsa, bu bileşenin programatik etiketi de mutlaka bu metin etiketini içermelidir. Tamamen aynı olmak zorunda olmasa da o metin etiketi içinde yer almalıdır. Burada programatik etiketle kasıt ekran okuyucular tarafından okunan “Accessibility label, Aria-label ContentDescription” tarzı etiketlerdir. Cihazları sesle kontrol eden yazılımlar görünen etikete değil, bu programatik etikete göre hareket ettikleri için, eğer bu iki etiket birbirinden farklıysa, kullanıcı işlemi gerçekleştiremeyecektir.
Geçmişten bu yana bilgisayar ve mobil cihazları elleriyle kontrol etmekte güçlük yaşayan kullanıcılar ses komutlarıyla kontrol yöntemine sıkça başvurmaktadır. Günümüzde ise özellikle yapay zekâ ve ses tanıma teknolojilerinin gelişimiyle birlikte bu sürecin daha da hızlanacağı aşikardır. O nedenle de ele aldığımız kriterin önemi daha da artacaktır. Web ve mobilde, bir düğme, yazma alanı, onay kutusu ve benzeri kontrollerin bazen görünen bir metin etiketi bulunmaktadır. Maalesef çoğu kodlayıcı bu etiketi programatik etiket yerine kontrolün bir yerine metin olarak iliştirdiği için, ekran okuyucular bu tarz alanları etiketsiz gibi algılayabilir. Bu amaçla da aria-label veya “name” gibi yöntemlerle etiketler belirlenir. İşte burada programatik olarak belirlenen etiketle kişilerin ekranda gördükleri etiketin aynı olması ya da en azından programatik adda görünen etiketin de geçmesi gerekir. Böylece kullanıcılar tutarlı biçimde gördükleri şeye tıklayabilir. Burada genellikle yapılan hata, düğmenin görünen bir yerinde ara yazdığı halde, özgün düğme adına hiç dokunulmadan “Search” olarak bırakılması durumlarıdır. Böyle olunca da siz ara düğmesine bas dediğinizde iletişim kuramamış olursunuz.
Teknik açıdan web’de mümkünse metni doğrudan element içinde kullanmalısınız: doğru kullanım: <button>Kaydet</button>
Yanlış kullanım: <button aria-label="Confirm action">...</button>
Tasarımcıların istememesi nedeniyle bazı ikonlara görünen bir etiket ekleme şansınız yoksa, görsel ipucu altına gizli bir metin koyabilirsiniz: <button><i class="icon"></i><span class="visually-hidden">Sil</span></button>.
Aria-label veriyorsanız içine mutlaka görünen metni de dahil edin.
Eğer ekranda görünen bir metin varsa aria-labelledby kullanarak bu metni etiket olarak kullanabilirsiniz.
Mobil tarafta ise iOS için AccessibilityLabel, Android için ContentDescription değerleriyle görünen metnin aynı olmasına veya bu etiketlerin görünen metni içermesine dikkat edin.
2.5.4 Hareketle Çalıştırma
Bir uygulamada salla kazan adlı bir özelik var, telefonu sallayınca hediye kazanıyorsunuz. Peki başka bir yolu var mı? Bazen de tam bir yazı yazarken gittiğiniz araba ani bir firen yapar ve bir bakarsınız ki, son yazdığınız şey silinmiş. Neden olabilir dersiniz? Bir müzik uygulamasında telefonu her salladığınızda sonraki parça çalmaya başlıyor. Maalesef bir türlü bir şarkıyı tamamlamak kısmet olmuyor size, her sallandıkça parça değişiyor. Ne yapmalı? Benzer örnekler, cihazı sallama, eğme, döndürme gibi hareketlerle belli işlevlerin tetiklenmesiyle meydana gelir. Başarı kriterimize göre, Cihazın dönme, sallama, eğme gibi hareketleriyle bir işlev tetiklenebiliyorsa, bu işlev için aynı zamanda ekrandan bir kontrol de sunulmalı ve kullanıcı istemezse bu hareket algılamasını kapatabilmelidir.
İlk bakışta cihazı sallayarak bir şeyler yapmak oldukça eğlenceli görünebilir. Zaten WCAG de bunu doğrudan yasaklamıyor. Ama bir şeyi yapmanın tek yolu bu olursa, o zaman problemler yaşanıyor. Çünkü herkes cihazını sallayamaz. Bazen bir telefon doğrudan tekerlekli sandalyeye monteli olabilir. Böyle zamanlar için, cihazı hareket ettirerek bir işlev tetikleniyorsa, bunu yerine getirmek için bir buton da ekranda bulunmalıdır. Bazı zamanlarda ise cihazın kontrolsüz sallanması gibi durumlar meydana gelebilir. O zaman da kullanıcı istemediği halde bazı eylemlerin tetiklenmesine yol açabilir. Bu sebeple de telefonu hareket ettirerek yapılan işlemlerin kapatılabilmesi de sağlanmalıdır. Örneğin iOS içinde varsayılan olarak telefon sallandığında bir işlem geri alınabilmektedir, ancak erişilebilirlik ayarlarından bu işlem devre dışı bırakılabilmektedir.
Teknik açıdan web’de DeviceOrientation ya da DeviceMotion API kullanarak hareket algılı bir işlev yaptıysanız, bu işlevi tetikleyen bir HTML kontrolü de koymalısınız. Ek olarak cihaz kontrolüyle hareketi kapatan bir kontrol de koymalısınız.
Mobil içinde eğer kullanıcı tercihlerinde erişilebilirlik ayarlarında sallayarak geri almayı devre dışı bıraktıysa, kontrollerin bunu algılamasını sağlayın ve hareketle kontrole mutlaka bir alternatif yöntem de belirleyin. Yani buradaki temel ilke kullanıcının cihazı hareket ettirme zorunluluğu olmamasıdır.
3.1.1 Sayfanın Dili
Ekran okuyucunuzla bir sayfaya girdiniz ki ne göresiniz, birden konuşma farklı bir dile dönüştü. Kelimelere bakıyorsunuz aslında Türkçe, ama İngilizce gibi telaffuz ediliyor. Başka bir sayfada video açtınız ama altyazılar Türkçe çıkmadı niye acaba. Bu soruların çok basit bir yanıtı var. sayfanın programatik dilinin belirtilmemiş ya da yanlış belirtilmiş olması.
Sayfa dilini ele alan başarı kriterimiz bir sayfanın temel dilinin mutlaka programatik olarak belirtilmesini şart koşuyor. Bu noktada düzey AA olan kriteri de belirtmeliyiz. Özellikle birden fazla dilde sayfaları olan bir domain varsa farklı dildeki farklı sayfaların veya sayfa bloklarının da dilinin doğru belirtilmesi otomatik dil algılayan ekran okuyucular için çok önemli. Artık birçok işletim sistemi ekran okuyucu kullanmasanız bile sayfaların otomatik seslendirilmesine imkân tanıyor. Bu seslendirmelerin de doğru dilde olması için kodda belirtilen dille görünen dilin aynı olması önemli. Ekran okuyucuların yanında tarayıcıların da o dile uygun karakterleri doğru yükleyebilmesi için dilin doğru belirtilmesi oldukça kritik.
Teknik açıdan bunu yapmak çok kolay. HTML sayfalarında <html lang="..."> özelliğini doğru dil koduyla eklemek temel çözüm (örn. Türkçe için lang="tr”
Farklı metin bloklarının dili farklıysa onu ayarlamak da daha yazım aşamasında mümkün. Örneğin Office programlarında bir noktada farklı bir dilde yazıyorsanız yazdığınız paragrafı seçip gözden geçir sekmesindeki dil grubundan yazım denetleme dilini ayarlamanız çok kişiye fayda sağlayacak. Her ne kadar ElevenLabs gibi yeni nesil TTS çözümleri mevcut dili yazıdan kendi algılasa da halen buradaki doğrulukları oldukça kısıtlı. Bu nedenle sayfa dilinin programatik olarak belirtilmesi kriteri bir süre daha bizim için önemini koruyacak.
Mobil uygulamalarda bu sorun daha az yaşansa da temelde uygulamalardaki tüm metinlerin doğru dil parametresinde ayarlandığından emin olunmalıdır.
3.2.1 Odaklanma Anında
Bir anket doldururken seçenekler arasında oklarla dolaşırken birden odağınız bir yazma alanına geliyor. Ne oldu diye araştırdığınızda bir önceki seçim kutusunda diğer seçeneğini seçtiğinizi anlıyorsunuz. Halbuki istediğiniz seçenek o değildi. Tekrar oraya gelip yeniden seçmeye çalışırken yanlışlıkla yine diğer seçeneğinin üzerine gelirseniz ayıklayın pirincin taşını. Başka bir sayfada gezinirken bir düğme üzerine gelir gelmez bir pop-up açılıyor ve onu kapatmadan işleme devam etmeniz mümkün değil. Halbuki sizin işiniz o düğmeyle değil bir sonraki kontrole geçecekseniz ama nasıl yapsak ki, ortada kuyu var yandan geç.
Odaklanma başarı kriteri kişinin öngörüsü dışında gerçekleşen bu tarz durumların önüne geçmeyi hedefliyor. Bir öğe klavye veya işaretçiyle odak aldığında, yeni bir sayfa açılmamalı, form otomatik gönderilmemeli veya odak başka bir yere atlamamalıdır. Burada klavye ile kasıt bir yerin üzerine Tab, Shift+Tab veya yön tuşlarıyla gelmek. Bir alana bu tuşlardan biriyle gelir gelmez daha enter veya boşluk yaparak bir onay vermeden sayfa değiştiğinde kullanıcı neye uğradığını şaşırıyor. Ciddi anlamda bir öngörülebilirlik ihlali yaşanıyor. Bu durum bir mobil uygulamada çok daha dramatik bir hal alabiliyor. Ülke seçim kutusunda her ülke değiştiğinde kendinizi otomatik olarak o ülkenin şehirleri arasında bulduğunuzu bir düşünün. A Harfinden başlayıp Türkiye’yi bulmak nasıl bir işkence olurdu sizce. Halbuki yapılacak şey çok basit. Böyle durumlarda onay için bir çift dokunma, enter veya boşluk, ya da tab veya bir sonraki fiskeyle hareketin tetiklenmesi herkes için daha sorunsuz bir deneyim için yeterli olacaktı.,
Bu kriter sayfaları klavye veya işaretçiyle kullanan herkesi etkiliyor. Ayrıca WCAG’nin istediklerini anlamanız için de size bir fikir verecektir. 2.5.2 işaretçi iptali kriterini hatırlayın. Orada da fare veya dokunmada işlemin tetiklenmesi için parmağın basıldığı yerden kaldırılmasını veya tıklanmasını şart koşuyordu kriterimiz. Temel felsefe aynı: Lütfen kullanıcıya tuzaklar kurmayın, hata yapabilme ve vazgeçme hakkı tanıyın. Yaşam zaten pek çok öngörülemez kötü sürprizlerle dolu, bir tane daha eklemenin kimseye bir faydası yok.
Teknik açıdan önemli olaylar için onfocus yerine kullanıcı etkileşimini esas alan onclick/onchange tarzı olayların kullanımı öneriliyor. Chat GPT güzel bir söz önerdi aynen kullanayım: odak sadece odak içindir eylem başlatmak için değil.
3.2.2 Girdi Anında
Kullanıcı adı ve şifre girerken şifreyi göster düğmesine dokunduğunuz anda, tüm sayfa yenilendi. Tekrar baştan formu bulmanız ve şifre alanına gelmeniz gerekiyor. Bir ödeme ekranında kredi kartının ilk 4 hanesini girdiğiniz anda odak haberiniz olmadan yeni bir yazma alanına geçti, ama bundan önceden haberiniz yoktu.
Bu başarı kriterimiz de 3.2 öngörülebilirlik ana hattını ve bir önceki odaklanma anında maddesinin bir tamamlayıcısı esasında. Amaç form alanlarında bir onay kutusunu veya radyo düğmesini işaretlediğinizde, metin girişi yaptığınızda haberiniz olmadan sayfa odağının değişmemesi.
Bilişsel farklılıkları olanlar, görme engelliler ve birçok kullanıcı sayfaların tahmin ettikleri biçimde ilerlemesini bekler. Siz haber vermeden sadece bir onay kutusu işareti sonrası sayfayı değiştirdiğinizde, kullanıcı belki de bunu anlamayıp geri yaptığında bambaşka bir yere gidebilir. Eğer bu tarz seçimler sonrası bir değişiklik olması gerekiyorsa, bunun önceden formun başında bir açıklamayla kullanıcıya bildirilmesi gerekiyor. Burada girdi anında ile kasıt bir kullanıcı arayüzü bileşeninin ayarının değişmesi. Yani bir yazım alanına metin girme, onay kutusunu işaretleme veya listeden bir şey seçme sonrası değer değiştiği için bir sayfa navigasyonu tarzı değişikliğe yol açarsa kullanıcı şaşırabilir. Açılan yeni bir sayfa, ya da bir pop-up beklenmedik olduğunda kullanımı zorlaştıracaktır. Bu kriter bir tek görme engelliler için değil, az gören ve dikkat dağınıklığı yaşayan kullanıcılar için de daha güvenli bir liman sunacaktır. Örneğin bir takvim uygulamasında yeni etkinlik oluştururken, Etkinlik türü seçim kutusunda farklı seçimler yapıldığında ilave form alanlarının belirmesi, eğer sayfa yapısı veya odak değişmiyorsa bir sorun yaratmaz. Ama bu değişim her seferinde yeni bir sayfa açılması veya kullanıcı odağının başka bir alana atılması şeklinde gerçekleştiğinde kafa karıştırıcı olur.
Teknik açıdan web’de, ana prensip kişi listeden seçim yapar yapmaz odağın değişmesi yerine bir onay butonuyla süreci kullanıcı kontrolüne bırakmaktır. Böyle bir otomatik değişim olacaksa, o zaman alan etiketine veya form başına bu bilgi eklenmelidir (örn: “bu listeden seçim yaptığınızda sayfa otomatik yenilenecektir”). Ayrıca, otomatik değişimlerde mümkünse kısmi güncelleme tercih edilmeli (Ajax ile sadece ilgili bölüm güncellenip genel sayfa yapısı korunmalı) veya kullanıcı isterse değişikliği tetikleyecek mekanizma sağlanmalıdır.
Mobil tarafta da bir anahtarı açık veya kapalı yapar yapmaz odak başka bir alana atlamamalıdır. Atlayacaksa mutlaka kullanıcı AccessibilityLabel veya ContentDescription ile bilgilendirilmelidir.
3.2.6 Tutarlı Yardım
Bir E-ticaret sitesine girdiniz ana sayfada canlı sohbet bölümünü sayfanın altında görüp gerekirse kullanırım diye düşünerek rahatladınız. Derken bir ürün sayfasına girdiniz ama, Canlı sohbet yok. Nerede ara tara derken, bu sefer de sayfanın üst taraflarında bir yere konulduğunu fark ettiniz.
3.2 ana hattını bir kez daha anımsayalım: öngörülebilirlik. Sayfada ne, nerede, hangi sırada sizin fal açmadan bilmenizi istiyoruz. Eve gelip giden misafir sonrası mutfaktaki değişen bardakları arama çaresizliğini web’de veya mobil uygulamada yaşamamanız amaç. Kısaca bir web sitesinde birden fazla sayfada tekrar eden yardım mekanizması varsa, bu yardım öğesi her sayfada tutarlı bir konumda sunulmalıdır. Ana sayfada üste, ürün sayfalarında altta, ödeme sayfasında ortada olduğunda kullanıcıların kafasını karıştıracaktır.
Özellikle Nöro çeşitliğe sahip pek çok birey için rutinler, düzenli ve akılda kalıcı bir yapı çok önemlidir. O yüzden beklenmedik sürprizler ve yer değişiklikleri hiç arzulanmaz. Sayfalarda ille bir yardım ve iletişim bölümü bulundurulması gibi bir zorunluluk yoktur. Ancak böyle bir mekanizma varsa, hep aynı konumda bulunması, kişilerin ihtiyaç duyduklarında zorlanmadan bu mekanizmayı bulup kullanmaları açısından zaruri bir durumdur. Yardım mekanizmaları karmaşık işlemler gerektiren bir başvuru formunu doldurmak, alışveriş tamamlamak gibi noktalarda oldukça önem kazanabilir. Ancak buralardaki farklı adımlarda yardım mekanizmalarının sürekli yerinin değişmesi kullanıcının zorlanmasına ve belki de formu yarıda bırakmasına neden olabilir. Eğer yardım tutarlı bir yerde olursa, kullanıcı bir sayfada aldığı desteği başka bir sayfada da kolayca yine alır ve işlemini daha güvenli, daha sorunsuz tamamlama şansına erişir.
Teknik açıdan tutarlılık adına ortak bir şablon kullanmanız faydalı olabilir. Mobil tarafta da bir yardım mekanizmanız varsa, bunun hep aynı menü içinde yer alması faydalı olacaktır. Veya bir yardım düğmesi sayfanın örneğin hep sağ üst köşesinde bulunmalıdır. Mobil için cihaz dikey veya yatay tutulduğunda yardımın göreli sırasının her iki durumda göreli olarak aynı sırada olmasına çalışın.
3.3.1 Hata Tanımlama
Uzun bir başvuru formunda veya rezervasyon ekranında zor zahmet tüm alanları doldurup ileri düğmesine bastınız. Aynı sayfa tekrar karşınızda. “Allahım ben nerde yanlış yaptım?” Belli bir alanı doldurmadım ya da hatalı ama neresi acaba? Bu soruyla tüm alanları tek tek kontrol ederken bir de süre bitmesin mi? Maalesef özellikle ekran okuyucu kullanıcılarının en çok stres yaşadıkları ve zorlandıkları bir konudan söz ediyoruz: hataların saptanması. Başarı kriteri çok açık: Otomatik tespit edilen bir form hatasında hangi alanda sorun olduğu ve ne tür bir hata olduğu yazılı biçimde kullanıcıya belirtilmelidir. Burada yazılı kelimesinin altını kalın kalın çizelim. Çünkü yapılan en temel yanlış mevcut hataların yalnızca renkle gösterilmesi şeklinde gerçekleşiyor. Örneğin hatalı form alanı kırmızıyla gösteriliyor. Herhangi bir metin açıklama olmadığı için de kullanıcı samanlıkta iğne arar misali hatalı alanı bulmaya çalışıyor her girdi yaptığı yeri tek tek yeniden kontrol ediyor.
Hataların yalnızca renklerle belirtilmesinden etkilenen bir tek görme engelliler değil. Renk Körleri ve öğrenme farklılığı yaşayan bireyler de sadece renk kullanımından mustarip olabiliyor. Sadece kırmızıyla gösterilen bir alanı bu rengi göremeyen biri de karıştıracaktır. Yine bilişsel farklılıkları olan ve hafıza güçlüğü yaşayan kişiler için bir şeyleri metinden okumak çok daha konforlu bir kullanım sağlama potansiyeline sahip. Bu nedenle hataların metin olarak bildirimi elzem bir konu.
Teknik açıdan web sayfalarında en konforlu çözüm sayfanın üstünde genel bir açıklamayla hangi alanların hatalı olduğunu metin olarak göstermek. Hatalı alanlara CSS ile sınıf ekleyip görsel vurgular yaparken aynı zamanda bu alanlara aria-invalid="true" özelliklerini ekleyerek yardımcı teknolojilere hatayı programatik olarak da iletmek mümkün. G83 tekniği veya HTML5’in required özelliğini kullanmak da gönderim sırasında tarayıcının otomatik uyarı vermesini sağlıyor. En güzel çözümlerden birisi de hata oluştuğunda bir alert diyaloğu çıkmasını ve ekran okuyucunun buraya otomatik odaklanmasını sağlamak. Bu şekilde kullanıcı doğrudan hatanın nereden olduğunu hızla algılayıp kolaylıkla düzeltme yapabilme şansına sahip olur.
Mobil cihazlarda hatalı alanların kullanıcıya otomatik bildirilmesi için Android tarafında setError("...") metodu hem hatanın görsel bildirimini hem de TalkBack tarafından otomatik okunmasını sağlıyor. iOS için de UIAccessibilityPostNotification yöntemi öneriliyor. Hata mesajının ilgili form alanının AccessibilityHind özelliğine koymak da önerilen çözümler arasında. Mobil için hata mesajlarını kullanıcının görüş alanında tutmak ve kaydırınca kaybolmamasını sağlamak da alınması gerekli önemli bir tedbir.
3.3.2 Etiketler veya Talimatlar
Bir iletişim formunda tab ile gezerken, ekran okuyucunuzun size belirttiği şeyler yalnızca şunlar: “yazınız, lütfen seçiniz, seçim düğmesi işaretli”. Ne yazacağız ne seçeceğiz, bu da neyin nesi öğrenmek için ek kullanım becerileri gerekecek. Bu da zaman kaybı, stres ve bıkkınlık demek. erişilebilirlik meselesinde belki de en sık yapılan hatalardan birisi etiketsiz form alanları. Başarı kriterimize göre kullanıcıdan girdi istenen her durumda, alanların ne bilgi beklediği anlaşılır olmalıdır. Yani formlardaki giriş alanları için mutlaka etiket (label) veya kullanım talimatlarının sunulması gerekiyor.
Buradaki temel amaç kullanıcının kolay ve hızlı biçimde form alanlarında ne istendiğini anlayıp doldurabilmesi. Bazı durumlarda form etiketinin yanında ek talimatlar da gerekebiliyor. Örneğin doğum tarihi alanlarında gg/aa/yyyy şeklinde yazılması talimatının da kullanıcıya bildirilmesi isteniyor. Etiketler bir tek yazma alanları için değil radyo düğmeleri ve onay kutuları için de geçerli. Elbette aşırı derecede fazla talimat da yorucu ve anlamsız olabilir. Arzulanan şey kullanıcının yetersiz bilgi alması nedenli form alanını tahmin etmek zorunda kalmaması.,
Form alanlarındaki etiket ve talimatlar bilişsel ve dil öğrenme zorluğu yaşayan kişileri de etkiliyor. Doğru kullanılmadıklarında bu durum dikkat ve hafıza sorunu olanlar için ek bir zihinsel yük getirecektir. Zorunlu alanların baştan belirtilmesinin de ö n önemini tekrar hatırlatalım.
Teknik açıdan Web sayfalarında her form alanının mümkünse görünen bir etiketi olması öneriliyor. Örnek: “E-posta adresi:”). HTML’de <label for="email">E-posta</label><input id="email" ...> Eğer etiket tasarım gereği görünür verilemiyorsa bu durumda ekran okuyucular için aria-label veya aria-labelledby ile alana bir isim verilmesi gerekli. Uzun talimatlar için form alanlarının en başında bir bilgi mesajı olması yararlı olabilir.
Tarih, telefon gibi belirli bir veri formatı ile giriş gerektiren alanlarda G89 tekniği adı verilen yöntemle PlaceHoder metin kullanılarak örnek verilmesi veya etiket altına küçük açıklama metni eklenmesi de öneriler arasında. 3 ayrı kutuda telefon numarası istenmesi tarzı birden fazla alanın tek bir mantıksal değeri temsil ettiği durumlarda <fieldset> ve <legend> ile gruplamak ve her alt alan için ayrı gizli label kullanmak gerektiği belirtiliyor.
Mobil cihazlarda iOS tarafında bir UITextField için yanında bir UILabel varsa, VoiceOver genelde bu etiketi okur; ancak özel bir tasarım varsa accessibilityLabel ile alanın ne olduğunu tanımlamalısınız. Android’de EditText bileşenlerine android:hint verildiğinde bu, kullanıcı yazmaya başladığında kaybolsa bile TalkBack tarafından alanın açıklaması olarak okunabilir. Mümkün olduğunca her form alanının görsel bir etiketi olmasına çalışın; ancak yoksa ve sadece bir ikon varsa, o simgenin ContentDescription kısmını anlamlı biçimde doldurmak önem taşıyacaktır. Kredi kartı numarası gibi ek talimat gereken durumlarda alana odaklanıldığında çıkan kısa metin açıklamaları koymak yararlı olabilir.
3.3.7 Yinelenen Girdi
Alışverişin son adımında ad, soyad, telefon ve adresinizi girdiniz. Tam süreç bitti derken, bir de teslimat için aynı bilgileri tekrar girmeniz istendi. Önceden hangi adresi girmiştiniz acaba unuttuğunuz oldu mu? Başarı kriterimize göre çok adımlı bir süreçte kullanıcıdan aynı bilginin ikinci kez istenmesi mümkün olduğunca engellenmelidir. Tabi bunun çeşitli güvenlik istisnaları da var. Örneğin bazı sistemler yeni şifre belirlerken iki kez girilmesini isteyebilir. Ancak bunun dışındaki durumlar için, eğer girilen bir bilgi tekrar isteniyorsa, bu bilginin sistem tarafından otomatik doldurulması ya da kullanıcıya eski girdiği bilgiyi seçme olanağının tanınması sağlanmalıdır.
Buradaki temel amaç, Mükerrer bilginin tekrar girilmesini önleyerek zihinsel yükü ve yoruculuğu azaltarak form doldurma sürecini kolaylaştırmaktır. Bilişsel farklılıkları olan veya hafızası zayıf kişiler önceden ne girdiklerini tekrar hatırlamakta güçlük yaşayabilir. Ayrıca gereksiz tekrar yorucudur ve hata yapma olasılığını da arttıracaktır. Anahtar denetimi kullanan kişiler için de bu tarz mükerrer girdiler süreci çok daha zaman kaybettirici hale getirecek ve stresi yükseltecektir. O nedenle mümkün olduğunca yinelenen girdilerden kaçınılmalıdır.
Teknik açıdan ilk sayfada girilen bir veriyi sunucuda saklayıp sonradan kullanmak mümkün. Buna ek olarak G221 adı verilen teknikle önceki bilgilerimi kullan onay kutusu yardımıyla kişiler daha önce girdikleri fatura adresini teslimat adresi olarak da kullanabilir. Bu arada bireyin otomatik doldurma kullanması bu kriterce tek başına yeterli değildir. Bilgilerin hatırlanma sorumluluğu WCAG tarafından geliştiriciye verilmiştir.
Mobilde ekranlar arası veri taşımak genellikle değişkenlerle veya yerel depolamayla (SharedPreferences, NSUserDefaults vb.) yapılır. Geliştirici, bir ekranda alınan veriyi bir sonraki ekrana intent veya segue parametresi olarak aktarabilir, böylece kullanıcı girdiğini tekrar girmeden yeni ekranda bu değeri kullanır. Veya kayıt formunun sonundaki bu bilgileri kullan anahtarıyla daha önce girilen bilgilerin korunması sağlanabilir. Aynı verinin tekrar istenmemesi bir tek erişilebilirlik değil kullanıcı deneyimi açısından da önemlidir.
4.1.2 İsim, Rol, Değer
Bir web sitesinde yön tuşlarıyla gezerken şöyle bir ibare gördünüz: “dropdown-icon
Grafik”. Tab ile gezerken zaten hiç rastlamadınız ama yön tuşlarıyla görünce dur bu ne acaba deyip enter tuşuna bastınız. Yine hiçbir şey olmadı ama yön tuşlarıyla aşağı doğru inmeye devam edince mesele anlaşıldı: burası aslında dil ve para birimi seçmenizi sağlayan bir açılır listeymiş. Aynı yere gelip tekrar basınca liste kapandı ama açılıp kapandığını size haber veren bir şey yok. Deneme yanılmayla kendiniz keşfettiniz. Geliştiriciler standart HTML kontrolleri yerine kendi özel arayüz bileşenlerini daha çok kullandıkça isim, rol, değer başarı kriteri ihlallerinin sayısı gitgide artıyor. Hatta etiketleme ve metin dışı içeriklerden sonra en sık karşılaşılan erişilebilirlik ihlali bu kriterde çıkıyor dediğimizde çok abartı olmayabilir. Başarı kriterimizin tam tanımı şu biçimde: Tüm kullanıcı arayüzü bileşenleri, yardımcı teknolojiler tarafından adlandırılabilir ve durumları anlaşılabilir olmalıdır. Bir bileşenin programatik bir adı (isim) ve işlevi (rolü) belirlenebilmeli; kullanıcı etkileşimiyle değişebilen özellikleri de programatik olarak ayarlanabilmeli ve bu değişiklikler kullanıcıya iletilebilmelidir.
Standart HTML kodları doğru kullanıldığında geliştirici ayrıyeten bir şey yapmasa bile bu bilgiler tarayıcı tarafından otomatik olarak sağlanabiliyor. Ama iş özel bileşenlere gelince, Aria (Accessible Rich Internet Application) adı verilen özelliklerle bu bileşenlerin isim, rol ve değerlerinin yardımcı teknolojilerce anlaşılabilecek hale getirilmesi gerekiyor. Yukarıdaki senaryomuzu düşünürsek, her şeyden önce mevcut ikonun adı olmadığından Dropdown İcon şeklinde gösteriliyor. Buraya isim olarak Dil ve Para birimi seç gibi bir şey verilmeliydi. Ayrıca burası sanki düz bir metin gibi görülüyor. İşlevinin açılır liste olarak gösterilmesi için aria ile role="combobox", her seçenek için role="option" özelliklerinin de verilmesi gerekiyordu. Yine bu öğenin o an açık mı yoksa kapalı mı olduğunu belirtmek için aria-expanded="true/false" özelliklerinin de tanımlanması lazımdı. Tüm bunlar uygulanmadığı için 4.1.2 kriteri ihlal edilmiş oldu.
Ekran okuyucu, sesle kontrol gibi yardımcı teknolojilerin web sayfaları ve uygulamalardaki bileşenleri doğru yorumlaması ve kontrol etmesi, kullanıcıyı da doğru yönlendirebilmesi anlamına geliyor. Özel bileşenler arttıkça, maalesef bu durum ihmal ediliyor ve kullanıcı deneyimi ciddi anlamda olumsuz etkileniyor. Beklendik şekilde kullanılan bir HTML butonunun isim, rol ve değeri zaten erişilebilirlik apileri tarafından otomatik olarak saptanır. Ekran okuyucu da bir elementin onay kutusu olduğunu, o an işaretli olup olmadığını kullanıcıya belirtebilir. Ancak geliştirici bir <div> etiketini buton gibi kullanmak isterse, tarayıcı bunu bilemeyecektir. O nedenle de düğmenin rolü WAI-ARIA ile role="button" şeklinde belirtilmek zorundadır. Bu da yetmez, bu butonun Tabindex ile odak alabilmesi, aria-pressed ile tıklanınca durumu değişiyorsa bunu kullanıcıya bildirmesi gerekir. Yani her bir özel arayüz elemanının ismen tanımlanması, rolünün atanması ve durumunun bildirilmesiyle bu başarı kriterimiz karşılanmış olacaktır.
İsim, rol ve değerlerin düzgün belirtilmediği bir sayfada görme engelli kullanıcının sayfa ve uygulamalarla etkileşimi kopacaktır. Bu durum başka kullanıcılar için de benzer sorunları beraberinde getirir. Örneğin bir konuşma tanıma yazılımı gönder düğmesi komutunu ancak o öğenin adı “gönder” ve rolü “düğme” olarak ayarlandığında algılar ve işlem yapabilir. Bugün için yardımcı teknolojiler rol ve değerleri anlamak için doğru kodlamaya ihtiyaç duymaktadır. İleride yapay zekâ araçlarının gelişimiyle durum değişebilir; ancak o güne dek bu kriter erişilebilirliğin en temel taşlarından biridir.
Teknik açıdan eğer yerleşik HTML kontrolleri tercih edilmiyorsa, isim, rol ve değerleri belirtmenin en kolay yolu WAI-Aria belirtenini kullanmak olacaktır. Örneğin Her bileşene bir isim (label) verin: Bu, ya elementin kendi metin içeriğiyle olur ya da aria-label / aria-labelledby kullanın. Her bileşenin rolünü doğru tanımlayın: Örneğin tıklanabilir bir öğeyse role="button" demek, seçim yapılıyorsa role="checkbox" veya role="radio" demek gerekebilir. Ve her bileşenin değer veya durumu kullanıcı eylemleriyle değiştiğinde, bunu da uygun ARIA durumlarıyla yansıtın (örn. seçili ise aria-checked=true, devre dışıysa aria-disabled=true vb. Ek olarak Özel bileşenlerin klavyeyle odak alması ve kullanılması için de gerekli adımları atın ki, klavye kullanımını düzenleyen 2.1.1 kriteriyle uyumluluk yakalayın.
Mobil cihazlarda iOS ve Android platformlarının standart arayüz bileşenleri en güvenli kullanım olacaktır. Kendi özel bileşeninizi kullandığınızda ona rol ve isim vermek önemli olacaktır. Android’de AccessibilityNodeInfo kullanarak setClassName ile rol belirtebilir veya en azından focusable yaparak TalkBack’in “düğme” demesini sağlayabilirsiniz. iOS’ta UIAccessibilityTraits ile bir öğeyi “button” rolüne sahip yapabilirsiniz. İsim (label) ataması için, iOS’ta accessibilityLabel, Android’de ContentDescription kullanılır – böylece ekran okuyucu o öğeyi tanıtırken bu ismi kullanır. Durum ve değer değişimleri için, örneğin özel bir anahtar (toggle) yaptıysanız, Voiceover’ın durum değişikliğini duyurması için accessibilityValue güncelleyin veya UIAccessibilityPostNotification ile uygun mesaj verin. Android’de bir custom view değerini değiştirdiğinizde sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED) gibi bildirimler göndermek de gerekir.
Kısaca mobil tarafta da özel bileşenlerin isim, rol ve değerlerinin doğru belirtilmesi gerekecektir.
Yorumlar
Bu yazı için henüz yorum yok.
Yeni Yorum