Erişilebilirlik söz konusu olduğunda, tasarımcılar renklere (yani kontrast) ve UX kopyasına (yani ifade) odaklanma eğilimindeyken, geliştiriciler ARIA özelliklerine (yani web sitelerini daha erişilebilir kılan kod) odaklanma eğilimindedir. Bunun nedeni, "kimin neyi yaptığı" arasına genellikle yeterince kalın çizgiler çizilmesidir.

Ayrıca, erişilebilir uygulamalar ve web siteleri oluşturmak heyecan verici görülmediğinden, bu satır neredeyse hiç sorgulanmaz.

Erişilebilirlik, 2020'de bile hala bir kara koyundur.

So, UX kopyası tasarımcının sorumluluğunda olduğundan ve ARIA öznitelikleri geliştiricinin sorumluluğunda olduğundan, ekran okuyucularının ihtiyaçlarını karşılamak tam olarak kimin sorumluluğundadır? Dan beri:

1. Ekran okuyucu UX kopyası Braille veya dikte olarak ifade edilir (öyleyse, UI araçlarımız görsel olduğunda bunu nasıl ileteceğiz?)
2. Uygulama, geliştiricilerin bölgesidir (öyleyse, kullanıcı deneyimi kopyası yazma sorumluluğunu gerçekten geliştiricilere kaydırabilir miyiz?)

Gördüğünüz gibi, bu bir iki kişilik iş - ve yine de, bunu kolaylaştıracak araçlar mevcut değil. Demek istediğim, hata yapmayın, erişilebilirlik tasarımının bazı yönleri tek taraflıdır (örneğin, UI tasarımcıları kendi başlarına çok kolay bir şekilde renk kontrastını halledebilirler). Bununla birlikte, ekran okuyucular için tasarım yapmak gibi diğer yönler, tasarımcılar ve geliştiriciler arasında işbirliğini gerektirir.

Adobe XD CC'nin tasarım devri ve ses prototipleme özellikler kullanışlıdır. Bu makalede, ekran okuyucular için tasarım yaparken nelere dikkat edilmesi gerektiğini tartışacağız ve ayrıca yukarıda bahsedilen özellikleri nasıl kullanacağımızı da inceleyeceğiz.

Ekran Okuyucular Nelerdir?

Ekran okuyucu, ekranda neler olup bittiğini ileten bir yardımcı teknoloji türüdür (görme engelli kişiler için). Ekran okuyucu yazılımı klavye ile birlikte kullanılabilir (örneğin, kullanıcılar çıkıntı ve girmek fareyi kullanmaktan farklı olarak), ancak daha verimli gezinmeye olanak tanıyan ve ayrıca Braille kullanan kullanıcılara hitap eden ekran okuyucu donanımıyla birlikte de kullanılabilir.

Örneğin bir Apple kullanıcısıysanız, bir şekilde farkında olacaksınız elma seslendirme, ekran okuyucu görevi gören yerel Apple dikte yazılımıdır. Windows kullanıcıları, ancak, genellikle ikisinden birini kullanır JAWS or NVDAWindows işletim sisteminde herhangi bir yerel ekran okuyucu aracı olmadığından.

Haydi içeri girelim.

1. Başlıkları Kullanın

Ekran okuyucular genellikle bir web sitesinin yapısını deşifre etmenin bir yolu olarak başlıkları kullanır ve çok görsel olarak düşünürsek, bu başlıkları dışarıda bırakma riskiyle karşı karşıya kalırız. Aşağıdaki örnekte, "Bölümler" başlığının çıkarılması, ekran okuyucularının bölüm listesinin sol taraftaki içeriğin bir devamı olduğunu varsaymasına neden olur, ki bu kesinlikle öyle değildir.

Sonuç olarak, ekran okuyucu kullanıcıları "Bölümler" e atlayamayacak ve içindeki bilgileri bulamayabilir.

Kullanılabilir kod geçici çözümleri varken (örneğin, aria-label öznitelik) sahip olmak gözle görülür başlık, kapsayıcı olarak daha net bir deneyim sunar herkesengelli olsun ya da olmasın.

Elbette, bağlamdan (yani içerikten) çıkarım yapabileceğimiz gibi, bölüm çok açık bir şekilde bölümlerin bir listesidir. Ancak ekran okuyucu kullananlar çok nadiren bağlam lüksüne sahip. Depodaki kutuların hiçbirinin etiketlenmediği bir nesneyi bulmaya çalışmak gibidir. Tasarımlarımızın bu etiketlere ve başlıklara ihtiyacı var.

Teknik açıdan, kural, her bölümün (bir <section> or <article> etiketi) yalnızca bir başlığa değil, başka hiçbir başlık ile çakışmayan açık bir başlığa sahip olmalıdır. Örnek olarak, bir bölümdeki en üst düzey başlık bir <h2>o zaman başka olmamalı <h2> o bölüm içinde başlık. Aksi takdirde, ekran okuyucular hangi başlığın bölümün etiketi olduğu konusunda bilgisizdir.

2. Etiketleri Kullanın

Simgeler daha iyidir - için herkes - metin etiketleri olduğunda. Bu yaklaşım karmaşık görünüyorsa, kullanmayı düşünün bir tek bir metin etiketi. Simgeyi mi tercih ediyorsunuz? Pekala, bu durumda, en azından geliştiricilere yalnızca ekran okuyuculara görünecek bir "görünmez etiket" beyan edin (evet, bahsediyorum aria-label). Aynısı, görünür bir metin etiketinin her zaman daha iyi olduğu giriş alanları için de geçerlidir. aria-label son çare olmalı.

Açıklayıcı metinlerinin alt etiket. Bununla birlikte, bir görüntü dekoratif olduğunda iletişim kurduğunuzdan emin olun, çünkü geliştiricilerin bunu kullanarak ekran okuyuculardan gizlemesi gerekecek. aria-hidden="true".

Ekran Okuyucu Metnini İletmek İçin Tasarım Atlatmayı Kullanma

İster alternatif metin, ister görünür metni olmayan öğeler için ARIA etiketleri, görünür metnin "üzerine yazılması" (ek bağlam için) için ARIA etiketleri veya hatta bir görüntünün ekran tarafından ne zaman tamamen yok sayılması gerektiğini belirten ARIA etiketleri Okuyucular, Adobe XD CC'nin tasarım aktarım aracı bunun için kullanılacak doğru araçtır.

İş akışı şunun gibi küçük bir şeye benzeyecektir:

1. "Paylaş" çalışma alanına tıklayın.
2. Ayarları yapılandırın (sağ tarafta).
3. "Bağlantı Oluştur" u ve ardından bağlantının kendisine tıklayın.
4. Tasarım aktarımı penceresinde, tasarımdaki belirli unsurlar hakkında yorum yapmak için "Pin Yerleştir" ikon düğmesini tıklayın.
5. Yorum bırakın. Örneğin:
   • Her para biriminin kısaltılmamış versiyonunu dikte edin
   • Bu görselin çevirisi "Yazar avatarı: Daniel Schwarz"
   • Bu resim dekoratif - ekran okuyucuları onu görmezden gelmelidir

3. Gerektiğinde Ayrıntılara Girin

İki düğmeden oluşan sekmeli bir bileşen varsayalım. Biri "Yenilik" ve diğeri "Sıralı" olarak etiketlenmiştir.

Herhangi bir görsel bağlam olmadan insan merak etmeye bırakılır… yenilik nedir? Sırayla ne var? Bunlar düğmeler mi? Bir şey yapmam mı gerekiyor? Çevreleyen içerikle eşleştirildiğinde, görme bozukluğu olmayan kullanıcılar kolayca neler olduğunu anlayabilir: bölümlerin sırasını sıralama fırsatı bize veriliyor.

Ancak, bunlar ile görme bozuklukları bazı detaylandırmalarla yapabilirdi. Özellikle, kopyanın daha fazla işlem yapılabilir olması gerekir.

Aşağıdaki UX kopyası, ekran okuyucu kullananlar için daha iyidir:

• "Bölümleri yeniliğe göre sırala"
• "Bölümleri sırayla sıralayın"

Ve bir düğmeye tıklandığında:

• "Bölümler artık yeniliğe göre sıralanmıştır"
• "Bölümler artık sıralı olarak sıralanmıştır"

Dinamik Değişiklikleri İletmek İçin Sesli Prototiplemeyi Kullanma

Tasarım aktarımı, ekran okuyan bir kullanıcı bir öğeye odaklandığında ne olması gerektiğini iletmenin harika bir yolu olsa da (yukarıda belirtildiği gibi, aria-label ek içerik sağlamak için görünür herhangi bir metnin üzerine yazar), ses prototipleme bir etkileşim sonucunda ne olması gerektiğini iletmek için kullanılabilir.

Adobe XD CC iş akışı şuna benzer:

1. "Prototip" çalışma alanına tıklayın.
2. Bir etkileşim oluşturunnormalde yaptığınız gibi.
3. “Eylem” → “Ses Çalma” (sağ tarafta) öğesini seçin.
4. Ekran okuyucular tarafından söylenecek metni “Konuşma” altına yazın.

Ekranda bir şey değiştiğinde, bu değişiklikler ekran okuyan kullanıcılara açıkça iletilmelidir - özellikle söz konusu değişiklikler kullanıcıların yanıt vermesini gerektiriyorsa. İşte birkaç örnek daha:

• "(X) size bir mesaj gönderdi"
• "Oturumunuz (x) saniye içinde zaman aşımına uğrayacak"
• İptal etmek istediğinizden emin misiniz? [Evet Hayır]"

Sonuç

Bir web sitesi sadece yukarıdan aşağıya okunacak bir belge değildir - en azından görevler ve etkileşimler söz konusu olduğunda değil.

Okuma akışları ve kullanıcı akışları nadiren doğrusaldır, bu nedenle ekran okuyucular için tasarım yapmak, görselleri metne çevirmekten biraz daha karmaşıktır. Kullanıcının halihazırda hangi bağlama sahip olduğunu, farklı derecelerde engelliliğe hitap ettiğini ve daha da önemlisi, erişilebilirliğin sonradan düşünülmemesi için tasarımcıların ve geliştiricilerin birlikte çalışması gerektiğini düşünmeliyiz.

Adobe XD CC'nin tasarım devri ve ses prototipleme özelliklerinden kendi avantajınıza yararlanın ve her zaman, her zaman, her zaman az gören kullanıcıların görünüm alanından uygulamanızı ve web tasarımlarınızı düşünün. Herkes görsel bağlam lüksüne sahip değildir.

Bonus: UI Tasarım Araçlarında Renk Kontrastı Özellikleri

UXPin renk kontrastını kontrol etmek için yerel bir özellik ve ayrıca bir renk körlüğü simülatörü sunar. Küçük fasulyeler, ama yine de bu bir ilk. UXPin kullanmıyorsanız, seçenekler web tabanlı araçlardır. WebAIIMGibi UI aracı uzantıları Stark Eklentisi, MacOS için kontrastya da Windows için Color Contrast Analyzer. Ne yazık ki, bazı nedenlerden dolayı, kullanıcı arayüzü tasarım araçlarında renk kontrastı hiçbir zaman en önemli konu olmamıştır.

İşte 2020 için umut!

Bonus: Adobe XD, Ses Kontrolünü Etkinleştirir

Adobe XD kısa süre önce Ses Kontrolünü desteklemeye başladıBu, artık Adobe XD ile etkileşim kurmanın ve buna bağlı olarak tasarımcı olmanın daha fazla yolu olduğu anlamına geliyor. Bu, erişilebilirlikle ilgili endişeleri olanlar için harika bir haber ve araç, devre dışı bırakılmayanlara bile fayda sağlıyor. Kapsayıcı tasarım için bu nasıl?

"XD'yi açın!"

Erişilebilirlik hakkında daha fazla bilgi edinin Herkes için Erişilebilirlik SitePoint Premium'da Ayrı Bir Listeden.

Kaynak: https://www.sitepoint.com/how-to-design-for-screen-readers-with-adobe-xd-cc/?utm_source=rss