Engelliler İçin Karmaşık Tasarımlar Nasıl Tanımlanır?
Siz sadece karmaşık bir tasarım spesifikasyonu verilen bir geliştiricisiniz. Tasarımların erişilebilirliği desteklediğini biliyorsunuz çünkü UX ekibiniz birkaç ay önce erişilebilir tasarım hakkında bir Orta posta okudu. Erişilebilir bir deneyim oluşturmak artık sizin elinizde, ama nereden başlamalısınız?
Uluslararası erişilebilirlik standartlarıyla ilgili olarak yaygın olarak “gerçek” olarak kabul edilen WCAG 2.0 vardır. Erişilebilirlik odaklı bir geliştiricinin araç setinin önemli bir parçası olan WAI-ARIA spesifikasyonu da vardır. Zaman içinde geriye dönersek, ABD Federal Hükümeti’nin standardı Rehabilitasyon Yasası’nın 508.
Alaka düzeyinin uzun sürdüğü bilinmemekle birlikte, Bölüm 508'deki teknik erişilebilirlik standartları çok adaletli bir öneri içermektedir. Şu hususları belirtmektedir,
“… Yardımcı teknoloji için elemanın kimliği, işleyişi ve durumu dahil olmak üzere bir kullanıcı arayüzü elemanı hakkında yeterli bilgi mevcut olacaktır.”
Orijinal olarak yazılım için yazılmış olan bu kelimeler, web tabanlı uygulamaların yaygınlığı göz önüne alındığında, bugün daha da ilgilidir. Bir görevi başarıyla tamamlamak için engelli kullanıcıların ihtiyaç duydukları bilgi türünü tanımlar. Bu, ekran okuyucusu olan bir kör kullanıcı, fiziksel engeli olan bir ses girişi kullanıcısı veya çeşitli yardımcı teknolojilere sahip herhangi bir sayıda başka kullanıcı olabilir.
Herhangi bir etkileşimi hem klavyeyle hem de ekran okuyucu kullanıcıları için erişilebilir kılmanın temel temelleri, üç temel bilgi parçasını sağlamaya gelir: kimlik, işlem ve durum.
Bir öğe ile onay kutusu kadar temel veya sürükleyip bırakma deneyimi kadar karmaşık olan kullanıcıların bu üç soruyu göz önünde bulundurmaları gerekir:
- Kimlik: Neyle etkileşime giriyorum?
- İşlem: Bu şeyi nasıl kullanırım?
- Devlet: Bu şeyin şu anki durumu nedir?
Onay Kutularına Yakından Bir Bakış
Görüş alan bir kullanıcıya kimlik, operasyon ve durumla ilgili birçok görsel ipucu verilir. Örnek olarak basit bir onay kutusuna göz atalım.
“Bu şart ve koşulları kabul ediyorum” kelimelerinin yanında bir kare gördüğümde, bir onay kutusu belirledim.
Kareyi tıklayarak onay kutusunun nasıl çalıştırılacağını biliyorum. Bunu yapmak, kontrol edildikten sonra işaretlenmemiş duruma geçirilecektir.
Bu karenin içinde bir onay işareti görürsem, durumunun “kontrol edildiğini” biliyorum.
Görme engelli bir kullanıcı bu bilgiyi nasıl elde eder?
“Bu şartlar ve koşulları kabul ediyorum. Onay kutusu, işaretlenmemiş. Kontrol etmek için boşluk çubuğuna basın.
Bir ekran okuyucu bunu kör bir kullanıcıya okursa, onlara üç önemli bilgi verilir.
- Nesnenin kimliği: Kabul edip etmeyeceğimi bildiren bir onay kutusu
- Devlet: denetlenmedi
- İşlem: Boşluk çubuğuna basmak durumu değiştirecek
Bunu göz önünde bulundurarak, en çok tercih edilenden en az tercih edilene kadar, yardımcı teknolojiye kimlik, operasyon ve durum sağlamak için üç yöntem düşünelim: yerel kontrolleri kullanmak, ARIA'yı kullanmak ve son çare olarak, gizli metin ve canlı bölgelere zeki olmak.
Yerel Kontroller
Form kontrolleri ve düğmeler gibi yerel kontroller her zaman en iyi seçenek olacaktır. Yukarıdaki örnekte, gerçek bir onay kutusu idealdir, çünkü tüm işi sizin için yapar. İşlemi JavaScript kullanarak oluşturmak zorunda değilsiniz, onay kutusu zaten kendisini ve durumunu tanımlar ve ayrıca insanlar bunları nasıl kullanacaklarını bilir.
Sürükle ve bırak gibi daha karmaşık etkileşimler için, sahnelerin arkasında yerel bir öğenin kullanılıp kullanılamayacağını düşünün. Bir tablodaki sütun genişliğini yeniden boyutlandırmayı düşünün:
Bir kaydırıcı veya aralık girişi, bu davranış için mükemmel yerel eşdeğerdir ve kendi kimliğini, çalışmasını ve durumunu sağlar.
Bu, CSS kullanılarak görsel olarak gizlenebilirken, ekran okuyucu kullanıcıları için hala kullanılabilir durumdadır. Değerini sütun genişliğine eşitleyin ve kör bir kullanıcı tanıdık bir form denetimiyle etkileşime girer. Görüşlü bir kullanıcı hala beklendiği gibi sürükleyip bırakacaktır.
WEG-ARIA
Yerel bir kontrol kullanmanın mümkün olmadığı yerlerde, menüler, iletişim kutuları ve otomatik tamamlamalar gibi genel tasarım desenleri için ARIA (Erişilebilir Zengin İnternet Uygulamaları) en iyi uygulamalarını izleyin.
Bu kurallar, HTML'de yerel olarak bulunmayan UI desenlerinin, yardımcı teknoloji kullanıcılarına yönelik olarak kendilerini düzgün bir şekilde tanımlamaları için yazılmıştır.
Örneğin, standart bir seçim öğesi alalım:
Bu, yerel olarak erişilebilir bir unsurdur. Bir listeden bir seçenek seçmek için formlarda kullanmak için idealdir. Menüler olarak bile iki katına çıkarlar. Ne yazık ki, birçok tasarım ekibinin gözünde “çirkin” ve tarayıcılar arasında stil vermek ve tutarlı olmak çok zor. Bu nedenle, modern web uygulamalarında kullanımları yaygın olarak reddedilir. Bunun yerine, insanlar kendi açılır menülerini oluşturur.
Kendi etkileşimli kullanıcı arayüzünüzü sıfırdan oluşturuyorsanız, uygun işaretlemeyi kullanmak, uygun klavye davranışlarını sağlamak ve ARIA özniteliklerini güncellemenin yanı sıra çok önemlidir. Yardımcı teknoloji kullanıcılarına uygun kimlik, işlem ve durum sağlamanın tek yolu budur.
Canlı Bölgeler ve Gizli Metin
Ne inşa ettiğinize eşdeğer bir yerel unsur yoksa ve hiçbir ARIA kılavuzu bulunmuyorsa, bir teknikler kombinasyonu kullanarak kasıtlı olarak bilgi vermeniz gerekir.
- CSS kullanılarak görsel olarak gizlenen, ancak ekran okuyucu kullanıcıları tarafından okunabilen bir
- Bir “aria-live” bölgesi
- Bu bölgenin metin içeriğini güncellemek için bir JavaScript yöntemi
Canlı bir bölgeye metin eklendiğinde, doğrudan bir ekran okuyucusunun sırasına yerleştirilir ve kullanıcılarına söylenir. Bu bölgeyi görsel olarak gizleyerek, ekran okuyucu kullanıcıları ile doğrudan iletişim kurmak için bir yöntem yaratıyoruz.
Sürükle ve bırak kullanan sıralanabilir bir liste gibi karmaşık bir UI oluşturuyorsanız, bu yöntemler bir zorunluluktur.
Sürükle ve bırak işlevini tanımlamak için, gizli metni “Bu öğeyi almak için boşluk çubuğuna basın” yazan her bir liste öğesine ilişkilendirmek için aria-tanımlıla kullanın. Bu kimlik sağlayacaktır. Kullanıcılar öğeyi aldığında, canlı bölgeye metin yerleştirerek işlem ve durum belirtin:
“{Öğe adı} yakalandı, yeniden sıralamak için ok tuşlarını, bırakmak için boşluk çubuğunu kullanın. İptal etmek için kaçış. Listedeki geçerli konum, 7/1 ”.
Bir öğe düştükten sonra son durumu da sağlayabilirsiniz:
“{Öğe adı} düştü. Listedeki son konum, 7/4 ”.
Yinelemek için, bu yöntem yalnızca yerel öğeler reddedildikten ve ARIA tarafından belirtilen bileşenler mevcut olmadığında veya çalışmadığında kullanılmalıdır. Kendi başınıza kimlik, işlem ve durum sağlarken, bu bilgiyi kullanıcılarınıza en iyi şekilde iletmenin yolunu belirlemek için kullanıcı testi gerekecektir.
Şimdi bu erişilebilir tasarımları alın ve engelli olanlar da dahil olmak üzere tüm kullanıcılar için zevk alabileceğiniz bir deneyim oluşturun. Bu yöntemler sayesinde, etkileşimin ne kadar basit veya karmaşık olduğuna bakılmaksızın tüm kullanıcılarınıza kimlik, işlem ve durum bilgisi sağlayabileceksiniz.
Jesse, Salesforce'un Ana Erişilebilirlik Uzmanıdır. Ona bir tweet gönderin @jessehausler, telefonu yalnız.
@SalesforceUX'de bizi takip edin.
Bizimle çalışmak ister misiniz? İletişim email@example.com
Salesforce Lightning Tasarım Sistemine göz atın