CSS Yeterli Olmadığında: Erişilebilir Bileşenler İçin JavaScript Gereksinimleri

ModernCSS.dev'in yazarı olarak, CSS çözümlerinin büyük bir savunucusuyum. Ve, gerçekten sıra dışı tasarımlar ve etkileşim için insanların CSS'yi nasıl akıllıca kullandıklarını görmeyi seviyorum! Ancak, "onay kutusu hack" gibi yöntemler kullanarak "yalnızca CSS" bileşenlerini tanıtmaya yönelik bir eğilim fark ettim. Ne yazık ki, bunun gibi saldırılar, önemli miktarda kullanıcıyı arayüzünüzü kullanamaz hale getirir.

Bu makaleler, birkaç yaygın bileşeni ve JavaScript gereksinimlerini ayrıntılı olarak açıklayarak CSS'nin erişilebilirliği kapsamak için neden yeterli olmadığını ele almaktadır. Bu gereksinimler, Web İçeriği Erişilebilirlik Yönergeleri'ne (WCAG) ve erişilebilirlik uzmanlarının ek araştırmalarına dayanmaktadır. JavaScript çözümleri veya demo CSS yazmayacağım, bunun yerine her bir bileşeni oluştururken nelere dikkat edilmesi gerektiğini inceleyeceğim. Bir JavaScript çerçevesi kesinlikle kullanılabilir, ancak tartışılan olayları ve özellikleri eklemek için gerekli değildir.

Listelenen gereksinimler genellikle isteğe bağlı değildir - bileşenlerinizin erişilebilirliğini sağlamaya yardımcı olmak için gereklidir.

Bir çerçeve veya bileşen kitaplığı kullanıyorsanız, sağlanan bileşenlerin erişilebilirlik gereksinimlerini karşılayıp karşılamadığını değerlendirmeye yardımcı olması için bu makaleyi kullanabilirsiniz. Belirtilen öğelerin birçoğunun aXe gibi otomatik erişilebilirlik testi araçları tarafından tam olarak kapsanmayacağını ve bu nedenle bazı manuel testlerin yapılması gerektiğini bilmek önemlidir. Veya gerekli işlevsellik için testler oluşturmak için Cypress gibi bir test çerçevesi kullanabilirsiniz.

Bu makalenin, sizi her bir arayüz bileşeni için JavaScript ile ilgili hususlar hakkında bilgilendirmeye odaklandığını unutmayın. Bu, gerekli arya ve hatta işaretleme gibi tamamen erişilebilir bileşenler oluşturmaya yönelik tüm uygulama ayrıntıları için kapsamlı bir kaynak değildir. Her bir bileşen için daha geniş hususlar hakkında daha fazla bilgi edinmenize yardımcı olmak için her tür için kaynaklar dahil edilmiştir.

Yalnızca CSS'nin Uygun Bir Çözüm Olup Olmadığını Belirleme

Yalnızca CSS çözümüne geçmeden önce sormanız gereken birkaç soru. Burada sunulan bazı terimleri, ilgili bileşenleriyle birlikte daha fazla bağlamda ele alacağız.

• Bu senin zevkin için mi?
  O zaman kesinlikle CSS'ye girin, sınırları zorlayın ve dilin neler yapabileceğini öğrenin!
• Bu özellik içeriğin gösterilmesini ve gizlenmesini içeriyor mu?
  Ardından, minimum aria arasında geçiş yapmak ve Esc üzerinde kapatmayı etkinleştirmek için JS'ye ihtiyacınız var. Durumu da değiştiren belirli bileşen türleri için, bir ARIA canlı bölgesinde güncellemeleri tetikleyerek değişiklikleri iletmeniz de gerekebilir.
• Doğal odak düzeni en ideali midir?
  Doğal düzen, bir tetikleyici ile tetiklediği öğe arasındaki ilişkiyi kaybederse veya bir klavye kullanıcısı içeriğe doğal sekme sırası aracılığıyla bile erişemezse, odak yönetimine yardımcı olması için JS'ye ihtiyacınız vardır.
• Stilize edilmiş kontrol, işlevsellik hakkında doğru bilgiyi sunuyor mu?
  Ekran okuyucular gibi yardımcı teknolojilerin kullanıcıları, bir kontrolün ne yaptığını belirlemelerine yardımcı olan semantik ve ARIA'ya dayalı bilgiler alır. Ve konuşma tanıma kullanıcılarının, kontrolleri çalıştırmak için kullanılacak ifadeyi bulmak için bileşenin etiketini veya türünü tanımlayabilmesi gerekir. Örneğin, bileşeninizin stili sekmeler gibiyse ancak sekmeler gibi "çalışmak" için radyo düğmelerini kullanıyorsa, bir ekran okuyucu "radyo düğmesi" duyabilir ve bir konuşma kullanıcısı bunları çalıştırmak için "sekme" kelimesini kullanmayı deneyebilir. Bu durumlarda, istenen işlevselliği elde etmek için uygun kontrolleri ve semantiği kullanmayı etkinleştirmek için JS'ye ihtiyacınız olacaktır.
• Etki, üzerine gelme ve/veya odaklanmaya mı dayanıyor?
  O zaman, özellikle dokunmatik ekran kullanıcıları ve %200+ masaüstü yakınlaştırma veya büyütme yazılımı kullananlar için içeriğe eşit erişim veya kalıcı erişim sağlamak için alternatif bir çözümde yardımcı olması için JS'ye ihtiyacınız olabilir.

Hızlı ipucu : Herhangi bir türde özelleştirilmiş kontrol oluştururken başka bir referans, W3 “ARIA'yı Kullanma” kılavuzundaki Özel Kontrol Erişilebilir Geliştirme Kontrol Listesi'dir. Bu, birkaç ek tasarım ve anlamsal değerlendirme ile birlikte yukarıda birkaç noktadan bahseder.

Araç ipuçları

Bir araç ipucunun tanımını daraltmak biraz zor, ancak bu bölüm için, tetikleyici bir öğenin yanında fareyle üzerine gelindiğinde görünen küçük metin etiketlerinden bahsediyoruz. Diğer içeriği kaplarlar, etkileşim gerektirmezler ve kullanıcı fareyle üzerine gelmeyi veya odağı kaldırdığında kaybolurlar.

Buradaki yalnızca CSS çözümü tamamen iyi görünebilir ve aşağıdaki gibi bir şeyle gerçekleştirilebilir:

 <button class="tooltip-trigger">I have a tooltip</button> <span class="tooltip">Tooltip</span> .tooltip { display: none; } .tooltip-trigger:hover + .tooltip, .tooltip-trigger:focus + .tooltip { display: block; }

Ancak bu, erişilebilirlikle ilgili endişelerin bir listesini yok sayar ve birçok kullanıcının araç ipucu içeriğine erişmesini engeller.

Büyük bir dışlanan kullanıcı grubu, dokunmatik ekranları kullananlardır; burada :hover , dokunmatik ekranlarda bir :hover olayı bir :focus olayı ile senkronize olarak tetiklendiğinden muhtemelen tetiklenmez. Bu, tetikleyici öğeye bağlı herhangi bir ilgili eylemin (bir düğme veya bağlantı gibi) ortaya çıkan araç ipucunun yanı sıra tetikleneceği anlamına gelir. Bu, kullanıcının ipucunu kaçırabileceği veya içeriğini okumak için zaman bulamayacağı anlamına gelir.

Araç ipucunun olay içermeyen etkileşimli bir öğeye eklenmesi durumunda, araç ipucu gösterilebilir ancak başka bir öğe odaklanana kadar kapatılamaz ve bu arada içeriği engelleyebilir ve kullanıcının bir görevi yapmasını engelleyebilir.

Ek olarak, gezinmek için yakınlaştırma veya büyütme yazılımı kullanması gereken kullanıcılar da araç ipuçlarını kullanmanın önünde oldukça büyük bir engel yaşar. Araç ipuçları fareyle üzerine gelindiğinde ortaya çıktığından, bu kullanıcıların araç ipucunu okumak için ekranı kaydırarak görüş alanlarını değiştirmeleri gerekiyorsa, bu, kaybolmasına neden olabilir. Araç ipuçları ayrıca, kullanıcıya bir araç ipucunun önceden görüneceğini söyleyecek hiçbir şey olmadığı için kontrolü kullanıcıdan kaldırır. İçeriğin yer paylaşımı, onların bir görev yapmasını engelleyebilir. Bir form alanına bağlı araç ipucu gibi bazı durumlarda, mobil veya diğer ekran klavyeleri araç ipucu içeriğini gizleyebilir. Ayrıca, tetikleyici öğeye uygun şekilde bağlanmazlarsa, bazı yardımcı teknoloji kullanıcıları bir araç ipucunun göründüğünü bile bilmeyebilir.

Araç ipuçlarının davranışı için rehberlik, WCAG Başarı Ölçütü 1.4.13 — Hover veya Odaklanma Üzerindeki İçerik'ten gelir. Bu kriter, az gören kullanıcılara ve yakınlaştırma ve büyütme yazılımı kullananlara yardımcı olmayı amaçlamaktadır. Araç ipucu (ve üzerine gelindiğinde ve odakta görünen diğer içerik) için yol gösterici ilkeler şunları içerir:

• kapatılabilir
  Araç ipucu, fareyle üzerine gelme veya odak hareket ettirilmeden kapatılabilir
• gezinebilir
  Ortaya çıkan araç ipucu içeriği, kaybolmadan gezdirilebilir
• Kalici
  Ek içerik bir zaman aşımına bağlı olarak kaybolmaz, ancak kullanıcının fareyle üzerine gelmeyi veya odağı kaldırmasını veya başka bir şekilde kapatmasını bekler

Bu yönergeleri tam olarak karşılamak için, özellikle içeriğin kapatılmasına izin vermek için biraz JavaScript yardımı gerekir.

• Yardımcı teknolojinin kullanıcıları, işten çıkarma davranışının bir JavaScript dinleyicisi gerektiren Esc anahtarına bağlı olduğunu varsayacaktır.
• Sarah Higley'nin bir sonraki bölümde açıklanan araştırmasına göre, araç ipucuna görünür bir "kapat" düğmesi eklemek, kapanış olayını işlemek için JavaScript'i de gerektirir.
• JavaScript'in, kullanıcının faresini hareket ettirirken içeriği kapatmadan araç ipucu içeriğinin üzerine gelmesini sağlamak için stil çözümünüzü güçlendirmesi gerekebilir.

Araç İpuçlarına Alternatifler

Araç ipuçları son çare olmalıdır. Araç ipuçlarının kullanımını caydırmak konusunda özel bir tutkusu olan bir erişilebilirlik uzmanı olan Sarah Higley, bu basit testi sunuyor:

"Bu metni neden kullanıcı arayüzüne ekliyorum? Başka nereye gidebilir ki?”

— Sarah Higley, “Araç İpuçları: Dört Parçanın İncelenmesi” sunumundan

Sarah'nın Microsoft'taki rolü nedeniyle dahil olduğu araştırmaya dayalı olarak, alternatif bir çözüm özel bir "geçiş ipucu"dur. Esasen bu, bir kullanıcının ekstra içeriğin gösterilmesini ve gizlenmesini kasıtlı olarak tetiklemesine izin vermek için ek bir öğe sağlamak anlamına gelir. Araç ipuçlarından farklı olarak, geçiş ipuçları, ortaya çıkan içerik içindeki öğelerin anlamlarını koruyabilir. Ayrıca, kullanıcıya bunları değiştirme kontrolünü geri verir ve daha fazla kullanıcı ve özellikle dokunmatik ekran kullanıcıları tarafından keşfedilebilirliği ve çalışabilirliği korur.

title özniteliğinin var olduğunu hatırladıysanız, yalnızca CSS çözümümüzde belirttiğimiz aynı sorunlardan muzdarip olduğunu bilin. Başka bir deyişle - kabul edilebilir bir araç ipucu çözümü olduğu varsayımıyla title kullanmayın.

Daha fazla bilgi için Sarah'nın YouTube'daki sunumuna ve araç ipuçları hakkındaki kapsamlı makalesine göz atın. Araç ipuçları ve geçiş ipuçları hakkında daha fazla bilgi edinmek ve neden title kullanılmaması gerektiği hakkında biraz daha fazla bilgi edinmek için Heydon Pickering'in Inclusive Components: Tooltips and Toggletips başlıklı makalesini inceleyin.

modlar

Modallar - diğer adıyla ışık kutuları veya diyaloglar - bir tetikleme eyleminden sonra görünen sayfa içi pencerelerdir. Diğer sayfa içeriğini kaplarlar, ek eylemler de dahil olmak üzere yapılandırılmış bilgiler içerebilirler ve genellikle kalıcı pencereyi sayfanın geri kalanından ayırt etmeye yardımcı olacak yarı saydam bir arka plana sahiptirler.

Yalnızca CSS modelinin birkaç varyasyonunu gördüm (ve portföyümün daha eski bir sürümü için bir tane yapmaktan suçluyum). “Onay kutusu hackini” kullanabilir, :target davranışını kullanabilir veya onu :focus (muhtemelen gerçekten kılık değiştirmiş çok büyük bir araç ipucu) şeklinden çıkarmaya çalışabilirler.

HTML dialog öğesi ile ilgili olarak, kapsamlı bir şekilde erişilebilir olarak kabul edilmediğini unutmayın. Bu nedenle, insanları özel çözümlerden önce yerel HTML kullanmaya kesinlikle teşvik etsem de, ne yazık ki bu, bu fikri bozuyor. HTML dialog neden erişilemediği hakkında daha fazla bilgi edinebilirsiniz.

Araç ipuçlarından farklı olarak, modların amacı yapılandırılmış içeriğe izin vermektir. Bu, potansiyel olarak bir başlık, bazı paragraf içeriği ve bağlantılar, düğmeler ve hatta formlar gibi etkileşimli öğeler anlamına gelir. Çoğu kullanıcının bu içeriğe erişebilmesi için klavye olaylarını , özellikle sekmeyi kullanabilmeleri gerekir. Daha uzun kalıcı içerik için, ok tuşları kaydırma özelliğini de korumalıdır. Araç ipuçları gibi, Esc tuşuyla kapatılabilir olmalıdırlar ve bunu yalnızca CSS ile etkinleştirmenin bir yolu yoktur.

Kipler içinde odak yönetimi için JavaScript gereklidir. Kipler odağı yakalamalı , yani odak kip içinde olduğunda, bir kullanıcı bunun arkasındaki sayfa içeriğine sekmemelidir. Ancak önce, odak, tamamen erişilebilir bir kalıcı çözüm için JavaScript gerektiren kipin içine girmelidir.

JavaScript ile yönetilmesi gereken modlarla ilgili olayların sırası :

1. Bir düğmedeki olay dinleyicisi modu açar
2. Odak, mod içine yerleştirilir; mod içeriğine göre hangi öğe değişir (karar ağacına bakın)
3. Odak, kapatılana kadar mod içinde tutulur
4. Tercihen, bir kullanıcı, özel bir kapatma düğmesine veya kalıcı içeriğin onaylanması gerekiyorsa "İptal" gibi yıkıcı bir düğme işlemine ek olarak Esc tuşuyla bir modu kapatabilir.
   1. Esc'ye izin veriliyorsa, kalıcı arka plana yapılan tıklamalar da modu kapatmalıdır.
5. Kapatma üzerine, herhangi bir gezinme gerçekleşmediyse, odak yeniden tetikleyici düğme öğesine yerleştirilir

Modal Odak Karar Ağacı

WAI-ARIA Yazma Uygulamaları Modal İletişim Örneğine dayalı olarak, burada bir mod açıldığında odağın nereye yerleştirileceğine ilişkin basitleştirilmiş bir karar ağacı verilmiştir. Buradaki seçimi her zaman bağlam belirleyecektir ve ideal olarak odak, “ilk odaklanılabilir öğe”den daha ileri yönetilir. Aslında bazen odaklanamayan öğelerin seçilmesi gerekir.

• Kipin birincil konusu bir formdur.
  İlk form alanına odaklanın.
• Modal içeriğin uzunluğu önemlidir ve modal eylemleri görüş alanının dışına iter.
  Varsa bir başlığa veya ilk paragrafa odaklanın.
• Modun amacı, birden fazla mevcut eylemle prosedüreldir (örnek: eylemin teyidi).
  Bağlama dayalı olarak “en az yıkıcı” eyleme odaklanın (örnek: “Tamam”).
• Modun amacı, tek bir işlemle prosedüreldir.
  Odaklanabilen ilk öğeye odaklanın

Hızlı ipucu : Başlık veya paragraf gibi odaklanamayan bir öğeye odaklanmanız gerektiğinde, öğenin JS ile programlı olarak odaklanabilmesini sağlayan ancak onu DOM sekme sırasına eklemeyen tabindex="-1" ekleyin .

ARIA'yı kurmak için diğer gereksinimler hakkında daha fazla bilgi için WAI-ARIA modal demosuna ve hangi öğeye odaklanılacağının nasıl seçileceğine ilişkin ek ayrıntılara bakın. Demo ayrıca odak yönetiminin nasıl yapıldığını örneklemek için JavaScript içerir.

Kullanıma hazır bir çözüm için Kitty Giraudel, tartıştığımız özellik gereksinimlerini içeren bir 11y-dialog oluşturdu. Adrian Roseli ayrıca modsal diyalogların yönetim odağını araştırdı ve bir demo oluşturdu ve farklı tarayıcı ve ekran okuyucu kombinasyonlarının odaklanılan öğeyi nasıl ileteceğine dair bilgiler derledi.

Sekmeler

Sekmeli arabirimler, karşılık gelen içerik panellerini birer birer görüntüleyen bir dizi tetikleyici içerir. Bunlar için bulabileceğiniz CSS "hack'leri", her ikisi de aynı anda yalnızca tek bir paneli göstermeye izin veren stilize radyo düğmeleri veya :target kullanmayı içerir.

JavaScript gerektiren sekme özellikleri şunlardır:

1. Geçerli sekme için aria-selected özniteliği true ve seçilmemiş sekmeler için false olarak değiştirme
2. Sekme seçimini odaktan ayırmak için dolaşan bir tabindex oluşturma
3. Ok tuşu olaylarına (ve isteğe bağlı olarak Home ve End ) yanıt vererek odağı sekmeler arasında hareket ettirin

İsteğe bağlı olarak, sekme seçiminin odağı takip etmesini sağlayabilirsiniz - yani bir sekmeye odaklanıldığında, aynı zamanda seçilir ve ilişkili sekme panelini gösterir. WAI-ARIA Yazarlık Uygulamaları, seçimin odağı takip edip etmeyeceği konusunda bir seçim yapmak için bu kılavuzu sunar.

Seçimin odağı takip etmesini seçseniz de seçmeseniz de, odağı sekme öğeleri arasında taşımak için ok tuşu olaylarını dinlemek için JavaScript kullanacaksınız. Bu, sekme seçeneklerinde gezinmeye izin veren alternatif bir modeldir, çünkü gezici bir tabindex (ileride anlatılacaktır) kullanımı doğal klavye sekmesi odak sırasını değiştirir.

Roving tabindex hakkında

Gezici tabindex kavramı, tabindex değerinin değerinin, öğelerin odak sırasını yönetmek için programlı olarak kontrol edilmesidir. Sekmelerle ilgili olarak, bu, tabindex="0" ayarlanarak yalnızca seçilen sekmenin odak sırasının bir parçası olduğu ve seçilmeyen sekmelerin tabindex="-1" olarak ayarlandığı ve bu da onları doğal klavye odak sırasından kaldırdığı anlamına gelir.

Bunun nedeni, bir sekme seçildiğinde, sonraki sekmenin kullanıcının odağını ilgili sekme panelinin içine çekmesidir. Sekme paneli olan öğeyi tabindex="0" atayarak odaklanabilir hale getirmeyi seçebilirsiniz veya sekme panelinde odaklanabilir bir öğe garantisi varsa bu gerekli olmayabilir. Sekme paneli içeriğiniz daha değişken veya karmaşık olacaksa, modlar için incelediğimiz karar ağacına göre odağı yönetmeyi düşünebilirsiniz.

Örnek Sekme Kalıpları

Sekmeler oluşturmak için bazı referans modelleri şunlardır:

• Deque Üniversitesi'nden Tabpanel demosu
• Scott O'Hara'dan sekme aracı testleri (birkaç işlevsel modeli test eder)
• Heydon Pickering'in Inclusive Components'tan Sekmeli Arayüzler

atlıkarıncalar

Slayt gösterileri veya kaydırıcılar olarak da adlandırılan atlıkarıncalar, kontrol mekanizmalarını içeren bir dizi dönen içerik panelini ("slaytlar") içerir. Bunları geniş bir içerik yelpazesine sahip birçok konfigürasyonda bulacaksınız. Bir şekilde kötü bir tasarım modeli olarak kabul edilirler.

Yalnızca CSS karusellerinin zor yanı, kontrol sunmamaları veya atlıkarınca hareketini manipüle etmek için beklenmedik kontroller kullanabilmeleridir. Örneğin, atlıkarıncanın geçiş yapmasına neden olmak için "onay kutusu hackini" tekrar kullanabilirsiniz, ancak onay kutuları yardımcı teknoloji kullanıcılarına etkileşim hakkında yanlış türde bilgiler verir. Ek olarak, onay kutusu etiketlerini görsel olarak ileri ve geri oklar olarak görünecek şekilde biçimlendirirseniz, konuşma tanıma yazılımı kullanıcılarına atlı karıncayı kontrol etmek için ne söylemeleri gerektiği konusunda yanlış bir izlenim vermeniz olasıdır.

Daha yakın zamanlarda, kaydırmalı ek için yerel CSS desteği geldi. İlk başta, bu sadece CSS için mükemmel bir çözüm gibi görünüyor. Ancak, etkileşimli öğeler aracılığıyla gezinmenin bir yolu olmaması durumunda, otomatik erişilebilirlik denetimi bile bunları klavye kullanıcıları tarafından gezilemez olarak işaretleyecektir . Bu özelliğin varsayılan davranışıyla ilgili başka erişilebilirlik ve kullanıcı deneyimi endişeleri de var, bunlardan bazıları SmolCSS'deki hızlı kaydırma demoma dahil edildi.

Karusellerin görünümündeki geniş yelpazeye rağmen, bazı ortak özellikler vardır. Bir seçenek, değiştirilmiş bir görsel sunumla aynı temel arayüz olduğundan, sekme işaretlemesini kullanarak bir atlıkarınca oluşturmaktır. Döngüler, sekmelerle karşılaştırıldığında, önceki ve sonraki için ekstra kontroller sunabilir ve ayrıca dönen döngü otomatik olarak oynatılıyorsa duraklatabilir.

Dönen özelliklerinize bağlı olarak aşağıdakiler JavaScript'te göz önünde bulundurulması gereken noktalardır:

• Sayfalandırılmış Kontrolleri Kullanma
  Numaralandırılmış bir öğeyi seçtikten sonra, ilişkili dönen slayta programlı olarak odaklanın. Bu, geçerli slayda odaklanabilmeniz, ancak ekran dışı slaytlara erişimi önleyebilmeniz için gezici tabindex kullanarak slayt kapsayıcılarının ayarlanmasını içerecektir.
• Otomatik Oynatmayı Kullanma
  Duraklatma denetimi ekleyin ve ayrıca slayt üzerine gelindiğinde veya içindeki etkileşimli bir öğeye odaklanıldığında duraklatmayı etkinleştirin. Ek olarak, kullanıcı tercihlerine saygı göstermek için slayt gösterisini duraklatılmış bir durumda yüklemek için JavaScript'te prefers-reduced-motion kontrol edebilirsiniz.
• Önceki/Sonraki Kontrolleri Kullanma
  aria-live="polite" olarak işaretlenmiş görsel olarak gizlenmiş bir öğe ekleyin ve bu kontroller etkinleştirildiğinde, canlı bölgeyi “Slayt 2 / 4” gibi mevcut konumun bir göstergesiyle doldurun.

Erişilebilir Karusel Oluşturmak İçin Kaynaklar

• Karusellerle ilgili W3C Web Erişilebilirlik eğitiminden eksiksiz bir kod örneğinin yanı sıra kapsamlı uygulama ayrıntıları ve değerlendirmeleri
• Deque University'nin sekme arayüzünü bir atlıkarıncaya dönüştürme örneği
• Otomatik dönen bir görüntü karuselinin WAI-ARIA Yazma Uygulamaları örneği
• Smashing'in erişilebilir bileşenler koleksiyonunda bir dizi atlıkarınca kaynağı

Açılır Menüler

Bu, bir düğmenin, genellikle gezinme menüleri için kullanılan bir bağlantı listesini açmaya geçiş yaptığı bir bileşene atıfta bulunur. Menüyü :hover veya :focus focus'ta göstermeyi bırakan CSS uygulamaları, yalnızca bazı önemli ayrıntıları kaçırır.

Kabul edeceğim, daha yeni :focus-within in özelliğini kullanarak, yalnızca CSS çözümünü güvenle uygulayabileceğimizi bile düşündüm. CSS açılır menüleri hakkındaki makalemin, gerekli JavaScript ile ilgili notlar ve kaynaklar içerecek şekilde değiştirildiğini göreceksiniz (başlığı, bu çözümü arayan diğer kişilerin de JS uygulamasını tamamlamasını umarak sakladım). Spesifik olarak, yalnızca CSS'ye güvenmek, araç ipuçlarıyla öğrendiğimiz WCAG Başarı Ölçütü 1.4.13: Hover veya Focus'ta İçerik'i ihlal etmek anlamına gelir.

Bu noktada tanıdık gelmesi gereken bazı teknikler için JavaScript eklememiz gerekiyor:

• click olaylarını dinleyerek menü düğmesinde aria-expanded true ve false arasında geçiş yapma
• Esc tuşunun kullanılmasıyla açık bir menünün kapatılması ve odağın menü geçiş düğmesine geri döndürülmesi
• Tercihen, odak menünün dışına taşındığında açık menüleri kapatmak
• İsteğe bağlı : Menü geçiş düğmeleri ve açılır menülerdeki bağlantılar arasında klavye gezintisi için ok tuşlarının yanı sıra Home ve End tuşlarını da uygulayın

Hızlı ipucu : Menü ekranını ek bir JS-'nin varlığına dayandırmak yerine menü ekranını .dropdown-toggle[aria-expanded= " true " ] + .dropdown seçicisiyle ilişkilendirerek açılır menünün doğru şekilde uygulandığından emin olun. active gibi sınıf eklendi. Bu, JS çözümünüzden de biraz karmaşıklığı ortadan kaldırır!

Bu aynı zamanda bir “ifşa modeli” olarak da adlandırılır ve WAI-ARIA Yazarlık Uygulamalarının Örnek Açıklama Gezinme Menüsünde daha fazla ayrıntı bulabilirsiniz.

Erişilebilir bileşenler oluşturmaya ilişkin ek kaynaklar

• Smashing'in Erişilebilir Ön Uç Bileşenleri için Eksiksiz Kılavuzu
• Carie Fisher'ın makalesi İyi, Daha İyi, En İyi: Erişilebilir Modellerin Karmaşık Dünyasını Çözmek
• WAI-ARIA Yazma Uygulamaları 1.2'de bulunan ortak tasarım kalıpları ve widget'lar hakkında demolar ve bilgiler
• Deque Üniversitesi'nin Kod Kitaplığı
• Scott O'Hara'nın Erişilebilir Bileşenleri
• Heydon Pickering'in Kapsayıcı Bileşenleri