ARIA: zehir mi yoksa panzehir mi?

Aaron Leventhal
Aaron Leventhal

ARIA, web yazarlarının yalnızca ekran okuyucuların görebileceği alternatif bir gerçeklik oluşturmasına olanak tanır.

Bazen web içeriğinde neler olduğuyla ilgili gerçekleri, hatta ekran okuyuculara doğrudan "yalanları" anlatmak gerekir. Örneğin, "odak gerçekten burada" veya "bu gerçekten bir kaydırma çubuğu". Bu, çalışma tezgahınızdaki aletlerin ve widget'ların üzerine sihirli yapışkan notlar eklemeye benzer. Bu sihirli notlar, üzerinde yazılanlara herkesi inandırır.

Sihirli bir yapışkan not, aracın ne olduğuna veya işlevine dair inancımızı geçersiz kılar. Örneğin, "Buradaki her şey bir yapıştırıcı tabancası!" ifadesini içeren bir ARIA eklerseniz. Boş bir mavi kutu olmasına rağmen sihirli yapışkan not, bunun bir yapıştırıcı tabancası olduğunu söylüyor. "Ayrıca %30 dolu" ifadesini de ekleyebilirsiniz. Ekran okuyucu artık% 30 dolu bir yapıştırıcı tabancası olduğunu bildirir.

Bunun web eşdeğeri, içinde resim bulunan düz bir div almak ve ARIA'yı kullanarak bunun 100 üzerinden 30 değerinde bir kaydırma çubuğu olduğunu belirtmektir. ARIA, div öğesini kaydırma çubuğu haline getirmez. Yalnızca ekran okuyucuya, kaydırma çubuğu olduğunu söylemesini söyler.

ARIA, bir web sayfasının görünümünü veya fare ya da klavye kullanıcısının davranışını etkilemez. ARIA'nın etkisini yalnızca yardımcı teknolojileri kullanan kullanıcılar fark eder. Web geliştiricileri, yardımcı teknoloji çalıştırmayan kullanıcıları etkilemeden istedikleri ARIA'yı ekleyebilir.

Doğru okudunuz: ARIA aslında klavye odak noktası veya Sekme sırası için hiçbir şey yapmaz. Tüm bunlar HTML ile yapılır ve bazen JavaScript ile küçük düzenlemeler yapılır.

ARIA nasıl çalışır?

Ekran okuyucular veya diğer yardımcı teknolojiler, tarayıcılardan her öğeyle ilgili bilgi ister. Bir öğede ARIA varsa tarayıcı bu bilgileri alır ve ekran okuyucuya öğe hakkında söylediklerini değiştirir.

ARIA'nın bazı yaygın kullanımlarını aşağıda bulabilirsiniz.

  • Otomatik tamamlama, ağaç veya elektronik tablo gibi HTML'de bulunmayan özel bileşenler ekleyin.
  • HTML'de var olan bileşenleri eklese de yazar, muhtemelen standart öğenin davranışını veya görünümünü değiştirmek istediği için yeniden icat etmesi gerektiğine karar vermiştir. Örneğin, HTML <input type="range"> öğesi temelde bir kaydırma çubuğudur ancak yazarlar bu öğeyi farklı göstermek ister.
    • Çoğu durumda bu sorun CSS ile çözülebilir. Ancak range için CSS awARD olur. Yazarlar kendi kaydırma çubuklarını oluşturabilir ve role="slider" ile aria-valuenow kullanarak klavyeye mevcut değerin ne olduğunu söyleyebilir.
  • Ekran okuyuculara sayfanın bir alanındaki ilgili değişiklikleri bildirmek için canlı bölgeler ekleyin.
  • Başlıklar gibi yer işaretleri oluşturun. Belirgin işaretler, ekran okuyucu kullanıcılarının istediklerini daha hızlı bulmalarına yardımcı olur. Yer işaretleri, ilgili alanın tamamını içerebilir. Örneğin, "bu kapsayıcı sayfanın ana alanıdır" ve "bu kapsayıcı bir gezinme panelidir".

Neden ARIA?

Halihazırda çalışan HTML'ye bazı ARIA eklemek faydalı olabilir. Örneğin, bir form denetiminin geçersiz giriş için hata mesajı uyarısına işaret etmesini isteyebiliriz. Dilerseniz bir metin girişinin belirli bir kullanımını da belirtebilirsiniz. Bu küçük düzenlemeler, sıradan web sitelerini ekran okuyucularla daha kullanılabilir hale getirebilir.

Yerel web mağazasında ihtiyacımız olan tüm widget'ların satılmadığını varsayalım. Ancak biz MacGyver gibiyiz. Diğer widget'lardan kendi widget'larımızı oluşturabiliriz. Bu araç, menü çubuğu yapması gereken bir web yazarına çok benziyor.

<nav> öğesi mevcut olsa da menü çubukları genellikle div'ler, resimler, düğmeler, tıklama işleyiciler, tuş basma işleyiciler ve ARIA kullanılarak bir araya getirilir.

Fare kullanıcılarını destekleme

Birlikte bir menü çubuğu oluşturalım. div adlı genel kutu öğelerinde bir grup öğe gösteririz. Kullanıcımız bir div'i her tıkladığında ilgili komut yürütülür. Harika, fare tıklayıcıları için işe yaradı.

Ardından, güzel görünmesini sağlarız. Öğeleri güzel bir şekilde hizalamak ve etraflarına görsel dış çizgiler yerleştirmek için CSS kullanıyoruz. Görme engelli kullanıcıların, bir menü çubuğu olduğunu ve nasıl kullanılacağını sezgisel olarak anlayabileceği kadar diğer menü çubuklarına benzetiyoruz. Hatta menü çubuğumuzda, farenin üzerine geldiği öğelerde farklı bir arka plan rengi kullanılır. Bu sayede kullanıcıya faydalı görsel geri bildirimler sağlanır.

Bazı menü öğeleri üst öğedir. Alt alt menüler oluştururlar. Kullanıcı imleci bunlardan birinin üzerine getirdiğinde alt menüyü dışarı kaydıran bir animasyon başlatır.

Web'deki birçok şeyde olduğu gibi, bunların hiçbirine erişmek oldukça zordur.

Menü çubuğunu klavyeyle erişilebilir hale getirme

Klavye erişilebilirliğini ekleyelim. Bunun için ARIA değil, yalnızca HTML değişiklikleri gerekir. ARIA'nın, yardımcı teknolojileri olmayan kullanıcılar için görünüm, fare veya klavye gibi temel özellikleri etkilemediğini unutmayın.

Bir web sayfasının fareye yanıt verebileceği gibi, klavyeye de yanıt verebilir. JavaScript'imiz tüm tuş vuruşlarını dinleyebilir ve tuşa basmanın işe yarayıp yaramadığına karar verebilir. Aksi takdirde, yenmeyecek kadar küçük bir balık gibi sayfaya geri atar. Kurallarımız şu şekildedir:

  • Kullanıcı bir ok tuşuna basarsa kendi dahili menü çubuğu planlarımıza bakalım ve yeni etkin menü öğesinin ne olması gerektiğine karar verelim. Görme engeli olmayan kullanıcının nerede olduğunu görsel olarak bilmesi için mevcut vurguları temizleyip yeni menü öğesini vurgularız. Ardından web sayfası, tarayıcının normal işlemi (bu durumda sayfayı kaydırma) gerçekleştirmesini önlemek için event.preventDefault() çağrısı yapmalıdır.
  • Kullanıcı Enter tuşuna basarsa bunu bir tıklama gibi değerlendirebilir ve uygun işlemi gerçekleştirebilir (hatta başka bir menü açabilirsiniz).
  • Kullanıcı başka bir işlem yapması gereken bir tuşa basarsa kullanıcıyı sayfaya geri gönderin. Örneğin, menü çubuğunuzda Tab tuşuna gerek yoktur. Bunu doğru şekilde belirlemek zordur. Örneğin, menü çubuğunda ok tuşları kullanılmalıdır ancak Alt+Ok veya Komut+Ok tuşları kullanılamaz. Bunlar, tarayıcı sekmenizin web geçmişinde önceki ve sonraki sayfaya gitmek için kullanılan kısayollardır. Yazar dikkatli olmazsa bu öğeler menü çubuğu tarafından silinir. Bu tür hatalar çok sık görülür. ARIA'yı kullanmaya henüz başlamadık bile.

Ekran okuyucunun menü çubuğunuza erişimi

Menü çubuğımız bant ve div'lerle oluşturuldu. Sonuç olarak, ekran okuyucu bunların ne olduğunu bilemez. Etkin öğenin arka plan rengi yalnızca bir renktir. Menü öğesi div'leri, belirli bir anlamı olmayan basit nesnelerdir. Sonuç olarak, menü çubuğunu kullanan bir kullanıcıya hangi tuşlara basılması gerektiği veya hangi öğenin seçildiğiyle ilgili herhangi bir talimat gönderilmez.

Ama bu adil değil. Menü çubuğu, görme engelli olmayan kullanıcılar için sorunsuz çalışır.

ARIA imdadınıza yetişir. ARIA, ekran okuyucuya odağın bir menü çubuğunda olduğunu göstermemize olanak tanır. Yazar her şeyi doğru yaparsa, özel menü çubuğumuz, bir masaüstü uygulamasındaki menü çubuğuna benzer şekilde ekran okuyucuya bakacaktır.

İlk ARIA yalanımız aria-activedescendant özelliğidir. Özelliği etkin menü öğesinin kimliğine ayarlayın ve her değiştiğinde güncellemeyi unutmayın. Örneğin, aria-activedescendant="settings-menuitem". Bu, ekran okuyucunun ARIA etkin öğemizi odak olarak görmesine neden olur. Bu öğe sesli olarak okunur veya Braille ekranda gösterilir.

Alt öğe terimi, bir öğenin başka bir öğenin içinde yer aldığını ifade eder. Bunun tam tersi terim, bir öğenin üst öğeler tarafından içerildiği anlamına gelen üst öğedir. Bir sonraki kapsayıcı yukarı/aşağı ok için bunlar daha spesifik olan üst/alt terimi kullanabilir. Örneğin, içinde bağlantı bulunan bir paragrafın yer aldığı bir doküman düşünün. Bağlantının üst öğesi bir paragraftır ancak üst öğe olarak doküman da vardır. Öte yandan, dokümanın her biri bağlantı içeren çok sayıda paragraf alt öğesi bulunabilir. Bağlantıların tümü, üst öğe dokümanının alt öğeleridir.

Odaklanmış menü çubuğundan belirli bir menü öğesine işaret etmek için aria-activedescendant tuşunu kullanarak ekran okuyucu, kullanıcının nereye gittiğini bilir ancak nesne hakkında başka hiçbir şey bilmez. Bu div özelliği nedir? Bu noktada rol özelliği devreye girer. İçerdiği öğenin tamamı için role="menubar", öğe grupları için role="menu" ve … davul sesi … tek tek menü öğeleri için role="menuitem" kullanırız.

Menü öğesi alt menüye yönlendiriyorsa ne olur? Kullanıcının bunu bilmesi gerekir. Görme engeli olmayan kullanıcılar için menünün sonunda küçük bir üçgen resmi olabilir ancak ekran okuyucu, en azından şu anda resimleri otomatik olarak nasıl okuyacağını bilmez. Genişletilebilir her menü öğesine aria-expanded="false" ekleyerek genişletilebilecek bir öğenin genişletilmediğini belirtebiliriz. Ayrıca, yazar yalnızca güzellik amaçlı olduğunu belirtmek için img üçgenine role="none" koymalıdır. Bu sayede ekran okuyucu, resimle ilgili gereksiz olan hiçbir şeyi söylemez.

Klavye hatalarını düzeltme

Klavye erişimi, temel HTML'nin bir parçası olsa da üzerine yazmak kolaydır. Örneğin:

  • Onay kutusunda geçiş yapmak için boşluk çubuğu kullanılıyor, ancak yazar preventDefault() yöntemini çağırmayı unuttu. Şimdi boşluk çubuğu hem onay kutusunu açıp kapatabilir hem de boşluk çubuğu için varsayılan tarayıcı davranışı olan sayfayı aşağı taşır.
  • ARIA modal iletişim kutusu, sekme gezinmesini içinde kilitlemek istiyor. Yazar, iletişim kutusundayken yeni sekme açmak için Ctrl+Tab tuşlarına izin vermeyi unutursa bu işlem beklendiği gibi çalışmaz.
  • Bir yazar, seçim listesi oluşturur ve yukarı ve aşağı tuşlarını uygular. Ancak, yazarın yine de home, end, pageup, pagedown, veya first case gezinme eklemesi gerekir.

Yazarlar bilinen kalıplara uymalıdır. Daha fazla bilgi için Kaynaklar bölümüne göz atın.

Klavye erişimi ile ilgili sorunları ekran okuyucu olmadan veya sanal tarayıcı modu kapalıyken de denemeniz faydalı olacaktır. Klavye erişimi ARIA yerine HTML ile uygulandığından, ekran okuyucu olmadan klavye hatalarını keşfedebilirsiniz. Sonuçta ARIA, klavye veya fare davranışını etkilemez. Bunun yerine, web sayfasındaki içerik, şu anda odak noktası olan öğe vb. hakkında ekran okuyucuya yalan söyler.

Klavye hataları neredeyse her zaman web içeriğindeki bir hatadan (özellikle HTML ve JavaScript'te) kaynaklanır, ARIA'da değil.

Neden bu kadar çok veri var?

Yazarların ARIA'yı yanlış kullanmasının birçok yolu vardır. Her hata, tamamen bozulmaya veya küçük farklılıklara neden olur. Yazarın yayınlamadan önce fark etmesi pek olası olmadığından, göze çarpmayan sorunlar daha da kötü olabilir.

Yazar deneyimli bir ekran okuyucu kullanıcısı değilse ARIA'da mutlaka bir sorun yaşanır. Menü çubuğu örneğimizde, yazar "menuitem" rolü doğru olduğunda "option" rolünün kullanılacağını düşünebilir. aria-expanded kullanmayı, aria-activedescendant değerini doğru zamanlarda ayarlayıp temizlemeyi veya diğer menüleri içeren bir menü çubuğu kullanmayı unutabilirler. Menü öğesi sayıları ne olacak? Ekran okuyucular genellikle menü öğelerini "5 öğeden 3. öğe" gibi bir ifadeyle sunar. Böylece kullanıcı nerede olduğunu bilir. Bu değer, genellikle tarayıcı tarafından otomatik olarak sayılır. Ancak, bazı durumlarda ve bazı tarayıcı-ekran okuyucu kombinasyonlarında yanlış sayılar hesaplanabilir ve yazarın bu sayıları aria-posinset ve aria-setsize ile geçersiz kılması gerekebilir.

Bunlar sadece menü çubukları. Kaç tür widget olduğunu düşünün. Dilerseniz ARIA spesifikasyonuna veya içerik oluşturma uygulamalarına göz atın. Her kalıp için ARIA'nın hatalı kullanılabilmelerinin birkaç yolu vardır. ARIA, yazarların ne yaptıklarını bilmelerine güvenir. Çoğu yazar ekran okuyucu kullanıcısı olmadığı için ne gibi sorunlar çıkabilir?

Diğer bir deyişle, gerçek ekran okuyucu kullanıcılarının ARIA widget'larını gönderime hazır olarak kabul edilmeden önce denemesi yüzde 100 gereklidir. Çok fazla nüans var. İdeal olarak, birkaç eksik uygulamanın yanı sıra çok sayıda uygulama özelliği nedeniyle her şey birkaç farklı tarayıcı-ekran okuyucu kombinasyonuyla denenmelidir.

Özet

ARIA, HTML'de belirtilen her şeyi geçersiz kılmak veya bunlara ekleme yapmak için kullanılabilir. Erişilebilirlik sunumunda küçük değişiklikler yapabilir veya tüm bir deneyim oluşturabilir. Bu nedenle, ARIA ekran okuyucu kullanıcısı olmayan geliştiricilerimizin elinde hem son derece güçlü hem de tehlikelidir.

ARIA, diğer seçenekleri geçersiz kılan bir işaretleme katmanıdır. Ekran okuyucu ne olduğunu sorduğunda, ARIA varsa kullanıcıya gerçeğin ARIA sürümü sunulur.

Ek kaynaklar

W3C'nin ARIA Yazma Uygulamaları, her bir örneğin önemli klavye gezinme özelliklerini belgeler ve çalışan JavaScript, CSS ve ARIA sağlar. Örnekler, şu anda geçerli olana odaklanır ve mobil cihazları kapsamaz.

Erişilebilirlik API'si nedir?

Erişilebilirlik API'si, ekran okuyucuların veya diğer yardımcı teknolojilerin sayfada neler olduğunu ve neler olup bittiğini öğrenmesini sağlar. MSAA, IA2 ve UIA bunlara örnek olarak gösterilebilir. Erişilebilirlik API'sinin iki bölümü vardır:

  • Kapsayıcı hiyerarşisini temsil eden bir nesne "ağacı". Örneğin, bir doküman birçok paragraf içerebilir. Bir paragrafta metin, resim, bağlantı ve metin süslemeleri olabilir. Nesne ağacındaki her öğenin rol (ben neyim?), ad veya etiket, kullanıcı tarafından girilen değer, açıklama ve odaklanılabilir, odaklanmış, zorunlu, işaretli gibi boole durumları gibi özellikleri olabilir. ARIA, bu özelliklerin herhangi birini geçersiz kılabilir.
    • Ekran okuyucular, kullanıcıların sanal arabellek modunda gezinmesine yardımcı olmak için ağacı kullanır (ör. "lütfen bir sonraki başlığa gidin").
  • Ağaçtaki değişiklikleri açıklayan bir dizi etkinlik ("odak artık burada" gibi). Ekran okuyucu, kullanıcıya az önce ne olduğunu bildirmek için etkinlikleri kullanır. Önemli HTML veya ARIA işaretlemesi değiştiğinde, ekran okuyucuya bir şeyin değiştiğini bildirmek için bir etkinlik tetiklenir.

HTML, bu erişilebilirlik API'leriyle iyi bir şekilde eşlenir. HTML yeterli olmadığında ARIA eklenebilir. Böylece tarayıcı, nesne ağacını veya etkinlikleri ekran okuyucuya göndermeden önce HTML anlamlarını geçersiz kılar.