İyi, Daha İyi, En İyi: Erişilebilir Kalıpların Karmaşık Dünyasını Çözmek

Marc Benioff, teknoloji endüstrisinde değişmeyen tek şeyin değişim olduğunu unutulmaz bir şekilde belirtti. 15 yılı aşkın bir süredir teknolojide çalışmış biri olarak bunu doğrulayabilirim. Diğer teknoloji dinozorları, ağın ilk günlerde çalışma şeklinin çoğumuzun hayal edebileceğinden çok farklı olduğunu kanıtlayabilirler.

Teknoloji endüstrisindeki bu sürekli değişim, bugün gördüğümüz yenilik ve ilerlemelere yol açarken, aynı zamanda seçim kavramını da beraberinde getirdi. Seçim - yüzeyde - doğası gereği olumlu bir şey gibi görünse de, her zaman gökkuşakları ve güllere eşit değildir. Teknolojik değişimin akışı aynı zamanda kodlama dillerinin parçalanmasını ve programlamanın hiç bitmeyen lezzetlerini “sıcaklığın” da beraberinde getiriyor. Bazen bu seçenek bolluğu, insanların çok fazla seçeneğe sahip oldukları için karar vermekte zorlandıkları, üzerinde iyi çalışılmış bir bilişsel bozukluk olan bir aşırı seçime dönüşür.

Bu makalede, her seferinde bir adım olmak üzere, erişilebilir kalıpların karmaşık dünyasını çözmeye çalışacağız. Mevcut erişilebilir kalıpları ve kitaplıkları gözden geçirerek işe başlayacağız, ardından genel kalıp ihtiyaçlarımızı ve potansiyel kısıtlamalarımızı ele alacağız ve son olarak, erişilebilirlik kalıplarını nasıl daha iyi değerlendirebileceğimizi öğrenmek için bir dizi eleştirel düşünme alıştırması yapacağız.

Ne Karışık Bir Ağ Örüyoruz

Aşırı seçim, dijital tasarımlarımızı oluşturmak için kullandığımız kalıplar ve kitaplıklar da dahil olmak üzere, basit onay kutusundan karmaşık dinamik moda ve aradaki her şeye kadar teknolojinin tüm yönlerine sızdı. Ancak bu kadar çok seçenek varken hangi modelin veya kitaplığın doğru olduğunu nasıl bileceğiz? Kullanıcıların her gün karşılaştığı yerleşik kalıpları/kütüphaneleri kullanmak daha mı iyi? Yoksa daha keyifli bir kullanıcı deneyimi için yepyeni desenler yaratmak mı daha iyi?

Mevcut sayısız seçenekle, seçeneklerin fazlalığı yüzünden çabucak felç olabiliriz. Ancak bir adım geriye gidersek ve dijital ürünlerimizi neden ilk etapta (yani son kullanıcı) oluşturduğumuzu düşünürsek, en fazla sayıda insan için en fazla değeri katabilecek deseni veya kitaplığı seçmek mantıklı değil mi? ?

Bir desen veya kitaplık seçmenin zaten yeterince göz korkutucu bir süreç olduğunu düşünüyorsanız, endişelenmeye başladığınız nokta bu olabilir. Ancak endişelenmenize gerek yok - erişilebilir bir model/kütüphane seçmek roket bilimi değildir. Teknolojideki diğer her şey gibi, bu yolculuk da biraz bilgi, büyük bir deneme yanılma yığını ve her kullanıcıya, duruma veya çerçeveye uyan tek bir mükemmel model/kütüphane olmadığını anlamakla başlar.

Bunu nasıl bilebilirim? Pekala, son beş yılımı Deque'nin ARIA Kalıp Kitaplığı olan A11y Stil Kılavuzu üzerinde çalışırken ve popüler SVG kalıplarını değerlendirirken farklı erişilebilir kalıp türlerini araştırarak, inşa ederek ve test ederek geçirdim. Ancak, akla gelebilecek her çerçeve/platformdaki birçok istemci modelini ve kitaplığı da inceledim. Zamanın bu noktasında, yeterince uzun baktığınızda gelişmeye başlayan, desen erişilebilirliği için doğuştan gelen bir hiyerarşi olduğunu tereddüt etmeden söyleyebilirim. Ve bazen ne pahasına olursa olsun kaçınılması gereken kalıplar olsa da, her zaman bu kadar net değildir. Erişilebilirlik söz konusu olduğunda, çoğu modelin iyi, daha iyi, en iyi derecelerine düştüğünü iddia ediyorum. Zor olan kısım, hangi kalıbın hangi kategoriye ait olduğunu bilmektir.

Kalıplar Hakkında Eleştirel Düşünmek

Peki, erişilebilirlik söz konusu olduğunda hangi modellerin iyi, daha iyi, en iyi olduğunu nasıl bileceğiz? Duruma göre değişir. Dijital erişilebilirlik topluluğundan sıklıkla başvurulan bu ifade bir kaçış değil, "size en iyi yanıtı verebilmemiz için daha fazla bağlama ihtiyacımız var"ın kısaltılmış halidir. Ancak bağlam her zaman net değildir, bu nedenle bir kalıbın erişilebilirliğini oluştururken ve değerlendirirken sorduğum bazı temel sorular şunları içerir:

• Kullanabileceğimiz önceden belirlenmiş bir erişilebilir model var mı?
• Hangi tarayıcıları ve yardımcı teknoloji (AT) cihazlarını destekliyoruz?
• Göz önünde bulundurulması gereken çerçeve sınırlamaları veya diğer entegrasyonlar/faktörler var mı?

Tabii ki, özel sorularınız benimkinden farklı olabilir, ancak mesele şu ki, kalıpları değerlendirirken eleştirel düşünme becerilerinizi kullanmaya başlamanız gerekiyor. Bunu, nihai bir karara geçmeden önce, önce gözlemleyerek, analiz ederek ve ardından erişilebilirlik açısından her bir modeli sıralayarak yapabilirsiniz. Ancak buna geçmeden önce, ilk soruları biraz daha inceleyelim.

Halihazırda Yerleşik Bir Erişilebilir Model Var mı?

Neden her yeni çerçeve ile yepyeni bir kalıp seti elde ediyoruz? Tekerleğin yeni desen seçenekleriyle bu sürekli yeniden icadı, özellikle genellikle gerekli olmadığı için geliştiricilerin kafasını karıştırabilir ve hayal kırıklığına uğratabilir.

Bana inanmıyor musun? Pekala, şu şekilde düşünün: Atomik tasarım sistemine abone olursak, daha büyük bir dijital ürün oluşturmak için birkaç küçük kod "atomunun" bir araya geldiğini anlarız. Ancak bilim dünyasında atomlar yaşamın en küçük bileşeni değildir. Her atom, protonlar, nötronlar ve elektronlar gibi birçok atom altı parçacıktan oluşur.

Aynı mantık kalıplarımıza da uygulanabilir. Var olan çeşitli çerçevelerde bulunan tüm kalıplara daha derinden bakarsak, kullanılan gerçek kodlama dili ne olursa olsun, çekirdek atom altı yapısı esasen aynıdır. Bu nedenle, teknolojik ve tasarım gereksinimlerine dayalı olarak üzerine inşa edebileceğimiz erişilebilir kalıplara sahip, akıcı kodlama kitaplıklarını takdir ediyorum.

Not : Smashing Magazine'in yakın zamanda yayınladığı erişilebilir modellerin listesine ek olarak Inclusive Components, Accessible Components ve Gov.UK Design System gibi bazı büyük saygın kaynaklar (ayrıca makalenin sonunda daha ayrıntılı bir model ve kitaplık listesi) bulunur. .

Hangi Tarayıcıları ve Yardımcı Teknoloji (AT) Cihazlarını Destekliyoruz?

İşe yarayabilecek birkaç temel modeli araştırdıktan sonra, tarayıcı ve yardımcı teknoloji (AT) cihaz desteği sorununa geçebiliriz. Kendi başına, tarayıcı desteği şakaya gelmez. Karışıma AT cihazlarını ve ARIA özelliklerini eklediğinizde, işler zorlaşmaya başlar… imkansız değil, her şeyi çözmek için çok daha fazla zaman, çaba ve düşünce süreci gerekir.

Ama hepsi kötü haber değil. Mevcut tarayıcı + AT cihaz desteğini daha iyi anlamamıza yardımcı olan HTML5 Erişilebilirlik ve Erişilebilirlik Desteği gibi harika kaynaklar var. Bu web siteleri, mevcut farklı HTML ve ARIA kalıp alt öğelerini ana hatlarıyla belirtir, açık kaynak topluluk testleri içerir ve hem masaüstü hem de mobil tarayıcılar/AT cihazları için bazı kalıp örnekleri sunar.

Dikkate Alınması Gereken Çerçeve Sınırlamaları veya Diğer Entegrasyonlar/Faktörler Var mı?

Birkaç erişilebilir temel model seçtikten ve tarayıcı/AT cihazı desteğini hesaba kattıktan sonra, model ve çevresiyle ilgili daha ayrıntılı bağlamsal sorulara geçebiliriz. Örneğin, bir içerik yönetim sisteminde (CMS) bir kalıp kullanıyorsak veya eski kod değerlendirmelerimiz varsa, belirli kalıp sınırlamaları olacaktır. Bu durumda, bir avuç desen seçeneği hızla bir veya ikiye indirilebilir. Diğer taraftan, bazı çerçeveler daha bağışlayıcıdır ve herhangi bir kalıbı kabul etmeye açıktır, bu nedenle çerçeve kısıtlamaları hakkında daha az endişelenebilir ve yapabileceğimiz en erişilebilir kalıp seçimini yapmaya daha fazla odaklanabiliriz.

Şimdiye kadar tartıştıklarımızın yanı sıra, bir model seçerken performans, güvenlik, arama motoru optimizasyonu, dil çevirisi, üçüncü taraf entegrasyonu ve daha fazlası gibi dikkate alınması gereken birçok ek husus vardır. Bu faktörler şüphesiz erişilebilir kalıp seçiminizde rol oynayacaktır, ancak içeriği oluşturan insanları da düşünmelisiniz. Seçtiğiniz erişilebilir model, editör tarafından oluşturulan ve/veya kullanıcı tarafından oluşturulan içerikle ilgili olası sınırlamaları ele alacak kadar sağlam bir şekilde oluşturulmalıdır.

Erişilebilirlik İçin Kalıpları Değerlendirme

Kod genellikle kelimelerden daha yüksek sesle konuşur, ancak tüm bunlara geçmeden önce, aşağıdaki kalıp örneklerinin her durum için mevcut olan tek kalıp olmadığını ve gruptaki "en iyi" olarak kabul edilenin gruptaki en iyi seçenek olmadığını hemen not edelim. erişilebilir kalıpların tüm dünyası.

Aşağıdaki kalıp demoları için, her bir kalıp grubunu kendileriyle karşılaştırdığımız varsayımsal bir durum hayal etmeliyiz. Bu gerçekçi bir durum olmasa da, bu eleştirel düşünme alıştırmalarını gözden geçirmek ve erişilebilirlik için kalıpları değerlendirmek, gerçek dünyada kalıp seçimiyle karşılaştığınızda daha hazırlıklı olmanıza yardımcı olacaktır.

Erişilebilir Düğme Modelleri

Erişilebilirlik için inceleyeceğimiz ilk kalıp grubu, hemen hemen her web sitesinde veya uygulamada her yerde bulunur: düğmeler. Birinci düğme deseni, bir düğmeyi taklit etmek için ARIA düğmesi rolünü kullanırken, ikinci ve üçüncü düğme desenleri HTML <button> öğesini kullanır. Üçüncü model ayrıca, şeyleri görsel olarak gizlemek için aria-describedby ve CSS'yi ekler.

İyi: role="button"

 <a role="button" href="[link]">Sign up</a>

Daha iyi: <button>

 <button type="button">Sign up</button>

En iyi: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

İlk kalıplar ilk bakışta basit görünse de, bazı erişilebilirlik sorularını akla getiriyorlar. Örneğin, ilk düğme modelinde, HTML <button> öğesi yerine “good” modelinde ARIA role="button" kullanıldığını görüyoruz. Erişilebilirlik açısından düşünürsek, HTML <button> öğesinin HTML4'te tanıtıldığını bildiğimiz için, bunun tüm büyük tarayıcıların en son sürümleri tarafından tamamen desteklendiğini ve çoğu AT cihazıyla iyi çalışacağını makul bir şekilde tahmin edebiliriz. Ancak daha derine inersek ve ARIA role=“button” için erişilebilirlik desteğine bakarsak, yardımcı teknoloji açısından küçük bir avantaj görürüz, HTML <button> öğesinde ise tarayıcının + AT kapsamının bazı alanları, özellikle de düşündüğümüzde eksiktir. ses kontrolü desteği.

Öyleyse ARIA modeli neden “daha ​​iyi” kategorisinde değil? ARIA onu daha erişilebilir kılmıyor mu? Hayır. Aslında, bu gibi durumlarda, erişilebilirlik uzmanları genellikle ARIA'nın ilk kuralını söylerler: ARIA kullanmayın. Bu, mümkün olduğunda HTML öğelerini kullan demenin basit bir yoludur. ARIA gerçekten güçlüdür, ancak yanlış ellerde yarardan çok zarar verebilir. Aslında, WebAIM Million raporu, "ARIA içeren sayfaların, olmayan sayfalara göre ortalama %60 daha fazla hata içerdiğini" belirtir. Bu nedenle, ARIA'yı kullanırken ne yaptığınızı bilmelisiniz.

Bu durumda ARIA kullanımına karşı bir başka nokta da, ihtiyaç duyduğumuz düğme işlevinin role="button" modeli için oluşturulması gerekmesidir, oysa bu işlev zaten <button> öğesinde önceden pişirilmiştir. <button> öğesinin ayrıca %100 tarayıcı desteğine sahip olduğu ve uygulanması kolay bir model olduğu göz önüne alındığında, ilk iki modeli değerlendirirken hiyerarşide biraz önde gidiyor. Umarım, bu karşılaştırma ARIA'nın eklenmesinin bir kalıbı daha erişilebilir hale getirdiği efsanesini yıkmaya yardımcı olur - çoğu zaman bunun tersi doğrudur.

Üçüncü düğme kalıbı, CSS ile görsel olarak gizlenmiş bir ID öğesine bağlı aria-describedby ile birleştirilmiş HTML <button> öğesini gösterir. Bu kalıp biraz daha karmaşık olsa da, düğme ile amaç arasında bir ilişki oluşturarak bağlam açısından çok şey katar. Şüpheye düştüğümüzde, duruma daha fazla bağlam ekleyebilirsek, o kadar iyidir, böylece doğru kodlanmışsa, yalnızca bu belirli düğme modellerini karşılaştırırken en iyi model olduğunu varsayabiliriz.

Erişilebilir Bağlamsal Bağlantı Modelleri

İnceleyeceğimiz ikinci grup örüntüler bağlamsal bağlantılardır. Bu modeller, AT kullanıcılarına ekranda görünenden daha fazla bilgi verilmesine yardımcı olur. İlk bağlantı modeli, ek bağlamsal bilgileri görsel olarak gizlemek için CSS'yi kullanır. İkinci ve üçüncü bağlantı kalıpları, karışıma ARIA nitelikleri eklerken, sırasıyla aria-labelledby ve aria-label .

İyi: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Daha iyi: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

En iyi: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Bağlamsal bağlantı modellerinin üçü de aynı görünse de, kodu incelediğimizde veya AT cihazlarıyla test ettiğimizde, bazı bariz farklılıklar vardır. İlk kalıp, içeriği gören kullanıcılar için görsel olarak gizlemek için bir CSS tekniği kullanır, ancak yine de gizli içeriği görmeyen AT kullanıcılarına sunar. Ve bu teknik çoğu durumda işe yarasa da, bağlantı ile ek bilgi arasında gerçek bir ilişki kurulmamıştır, bu nedenle bağlantı en iyi ihtimalle geçicidir. Bu nedenle, ilk bağlantı modeli iyi bir seçimdir, ancak üçünün en sağlam bağlantı modeli değildir.

Sonraki iki bağlantı modelini değerlendirmek biraz daha zor. W3C'nin ARIA özelliklerine göre “Arya etiketinin amacı, aria-label amacı ile aria-labelledby . Kullanıcıya nesnenin tanınabilir bir adını sağlar.” Dolayısıyla teoride her iki nitelik de aynı temel işlevselliğe sahip olmalıdır.

Bununla birlikte, teknik özellikler, kullanıcı aracılarının, kullanıcıya hangi erişilebilir adın iletileceğine karar verirken aria-label aria-labelledby göre öncelik verdiğine de işaret eder. Araştırma ayrıca otomatik çeviri ve arya etiketi özellikleriyle ilgili sorunları da göstermiştir. Bu, aria-labelledby kullanmamız gerektiği anlamına geliyor, değil mi?

O kadar hızlı değil. Aynı ARIA özellikleri, “Arayüz, ekranda görünür bir etiketin olması mümkün olmayacak şekildeyse (veya görünür bir etiket istenen kullanıcı deneyimi değilse) , yazarlar aria-label kullanmalı ve kullanmamalıdır . aria-labelledby kullanın." Kafa karıştırıcı hakkında konuşun - hangi modeli seçmeliyiz?

Büyük ölçekli çeviri ihtiyaçlarımız olsaydı, görsel yönü değiştirmeye ve bağlantıları tam bağlamla birlikte yazmaya karar verebiliriz (örneğin, “ Bu harika şey hakkında daha fazla bilgi edinin ”) veya aria-labelledby kullanmaya karar verebiliriz. Ancak, büyük ölçekli çeviri ihtiyaçlarımız olmadığını veya bu ihtiyaçları makul/erişilebilir bir şekilde karşılayabildiğimizi ve görseli değiştirmek istemediğimizi varsayalım - o zaman ne olacak?

Mevcut ARIA 1.1 tavsiyelerine (ARIA 1.2'de aria-label çevirisi vaadi ile) artı aria-label uygulamasının geliştiriciler için aria-labelledby göre biraz daha kolay olduğu gerçeğine dayanarak, aria-label -label'i ağırlıklandırmaya karar verebiliriz desen değerlendirmemizde aria-labelledby . Bu, erişilebilir model seçimimizde bağlamın ne zaman ağır bastığının açık bir örneğidir.

Erişilebilir <svg> Kalıpları

Son olarak, ama kesinlikle en az değil, erişilebilirlik için bir grup SVG görüntü modelini inceleyelim. SVG'ler kodun görsel bir temsilidir, ancak yine de koddur. Bu, bir AT cihazının, desene role="img" eklenmediği sürece dekoratif olmayan bir SVG görüntüsünü atlayabileceği anlamına gelir.

Aşağıdaki SVG kalıplarının bilgi amaçlı olduğu varsayılarak, her birine bir role="img" eklenmiştir. İlk SVG kalıbı, içeriği gören kullanıcılardan görsel olarak gizlemek için CSS ile birlikte <title> ve <text> kullanır. Sonraki iki SVG modeli, <title> ve <desc> öğelerini içerir, ancak son kalıba bir aria-labelledby özniteliği eklenir.

İyi: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Daha iyi: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

En iyi: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Önce <title> ve <text> ve görsel olarak gizlenmiş CSS kullanarak ilk kalıba bakalım. Desenlerde önceki görünür şekilde gizlenmiş metinlerden farklı olarak, aynı SVG öğesi şemsiyesi altında gruplandıkları için <title> ve <text> öğeleri arasında doğal bir ilişki vardır. Ancak bu ilişki çok güçlü değildir. Aslında, SVG kalıpları üzerine yaptığım araştırmaya geri bakarsanız, 8 tarayıcı/AT kombinasyonundan sadece 3'ünün mesajın tamamını duyduğunu görüyoruz. (Not: Domuz deseni #1, ampul deseni #7'ye eşdeğerdir.)

Çalışan W3C SVG spesifikasyonları <text> öğesini “metinden oluşan bir grafik öğesi…çizilecek karakterler karakter verileri olarak ifade edilir. Sonuç olarak, SVG içeriğindeki metin verilerine görme engelliler kolayca erişebilir.” Bu ilk model tamam, ancak daha iyisini yapabiliriz.

İkinci kalıp, <text> öğesini kaldırır ve onu bir <desc> öğesiyle değiştirir. W3C SVG teknik özellikleri şunları belirtir:

" <title> alt öğesi, öğe için kısa bir metin alternatifini temsil eder... ve <desc> öğesi, öğe için açıklama gibi daha ayrıntılı metin bilgilerini temsil eder."

Anlamı, SVG'lerdeki <title> ve <desc> öğeleri, geleneksel olarak <img> öğelerinde bulunan alternatif resim metinleri ve uzun açıklama seçeneklerine benzer şekilde kullanılabilir. İkinci SVG'ye <desc> öğesini ekledikten sonra, 8 kombinasyondan 3'ünün mesajın tamamını duyduğu benzer tarayıcı/AT desteği görüyoruz. (Not: Domuz deseni #2, ampul deseni #10'a eşdeğerdir.) Bu test sonuçları ilk modeli yansıtıyor gibi görünse de, bu modelin "daha iyi" kategorisine girmesinin nedeni, kodun uygulanmasının biraz daha kolay olmasıdır. JAWS, VoiceOver masaüstü ve VoiceOver mobil üzerinde çalıştığı için daha fazla AT kullanıcısını etkilerken, ilk model daha az popüler tarayıcı/AT kombinasyonlarını destekler.

Üçüncü kalıp yine <title> ve <desc> öğelerini kullanır, ancak şimdi karışıma eklenen bir aria-labelledby plus kimliğine sahiptir. Aynı SVG testlerine göre, bu ek kod parçasının eklenmesi, 8 tarayıcı/AT kombinasyonundan 7'sini tam olarak destekleyebileceğimiz anlamına gelir. (Not: Pig deseni #3, ampul deseni #11'e eşdeğerdir.) Üç SVG deseninden bu üçüncüsü, çoğu AT cihazını desteklediğinden “en iyisidir”. Ancak bu modelin bazı tarayıcı/AT kombinasyonlarını kullanmada sakıncaları vardır; bu model için yinelenen resim başlığı/açıklama içeriği duyacaksınız. Kullanıcılar için potansiyel olarak can sıkıcı olsa da, yinelenen içeriği duymanın genellikle hiç duymamaktan daha iyi olduğunu savunuyorum.

Kapanış Düşünceleri

Hepimiz teknolojide seçime kesinlikle değer versek de, zaman içinde seçeneklerin fazlalığının bizi felç ettiği ve bir sonraki adımda ne yapacağımız konusunda kafamızı karıştırdığı bir noktaya gelip gelmediğimizi merak ediyorum? Erişilebilir kalıpları seçme açısından kalıp/kitaplık seçenekleri, tarayıcı/AT cihazı desteği, çerçeve sınırlamaları ve daha fazlası hakkında doğrudan sorular sorabiliriz.

Eldeki doğru verilerle, bu soruları yanıtlamak yeterince kolaydır. Ancak, kalıpların ötesine geçip onları kullanan insanları gerçekten düşündüğümüzde biraz daha karmaşık hale geliyor. Seçimlerimizin, kullanıcılarımızın başarılı olma yetenekleri üzerindeki etkisini o zaman anlıyoruz. Prof. George Dei'nin belagatli bir şekilde belirttiği gibi:

"Katılım, insanları zaten var olana getirmek değil, yeni bir alan, herkes için daha iyi bir alan yaratmaktır."

Kalıplar hakkında eleştirel düşünmek ve en erişilebilir olanları seçmek için biraz daha zaman ayırarak, şüphesiz daha fazla kullanıcıya ulaşmak için onların şartlarına göre daha kapsayıcı bir alan yaratacağız.

alakalı kaynaklar

Araçlar

• Erişilebilirlik Desteği, Michael Fairchild, a11ysupport.io
• HTML5 Erişilebilirlik, Steve Faulkner

Desen Kitaplıkları

• Erişilebilirlik Projesi
• Erişilebilirlik Stil Kılavuzu
• Erişilebilir Bileşenler, Scott O'Hara
• Erişilebilir drag-and-drop Liste Yeniden Sıralama Eklentisi, Harris Schneiderman
• Deque'nin ARIA Desen Kitaplığı
• Deque'nin Erişilebilir Tepki Kitaplığı
• GOV.UK Tasarım Sistemi
• Kapsayıcı Bileşenler, Heydon Pickering
• ABD Web Tasarım Sistemi (USWDS)
• Web Erişilebilirlik Eğitimleri