ARIA: zehir mi yoksa panzehir mi?

Ekran okuyuculara yalan söyleyerek erişilebilirlik sorununa tuz bulaşmadığında erişilebilirliği nasıl iyileştiriyor?

Aaron Leventhal

ARIA nedir?

ARIA, web yazarlarının yalnızca ekran okuyucular tarafından görülebilen alternatif bir gerçeklik oluşturmasına olanak tanıyor 🤥

Bazen gerçeği açıklamak, hatta ekran okuyuculara web içeriğinde neler olduğu konusunda doğrudan "yalan" söylemek gerekir. Örneğin, "Odak gerçekten burada!" veya "Bu gerçekten bir kaymadır!". Tezgahınızdaki araçların ve widget'ların üzerine sihirli yapışkan notlar eklemeye benzer. Bu sihirli yapışkan notlar, herkesi üzerinde yazılanlara inandırıyor.

Ne zaman sihirli bir yapışkan not varsa araç hakkında bir gerçeği ya da araçların ne olduğuna dair inancımızı geçersiz kılar. Örnek: "Buradaki şey yapışkan tabancası!". Tezgahta duran boş bir mavi kutu olsa da sihirli yapışkan not bunun bir yapışkan tabanca olduğunu görmemizi sağlayacak. Ayrıca "%30 dolu!" da ekleyebiliriz. Ekran okuyucu şimdi orada% 30'luk bir tutkal tabancası olduğunu bildirir.

Bunun web'deki eşdeğeri, içinde bir resim bulunan düz kutu öğesini (bir div) alıp ARIA'yı kullanarak bunun 30/100 değerinde bir kaydırma çubuğu olduğunu belirtmektir.

ARIA nedir?

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

Doğru okudunuz: ARIA, klavye odağı veya sekme sırası üzerinde hiçbir şey yapmaz. Bunların tamamı HTML'de yapılır, bazı durumlarda JavaScript küçükleri kullanılır.

ARIA nasıl çalışır?

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

Neden ARIA?

Neden kullanıcılarımıza yalan söyleyelim ki?

Yerel web mağazasının ihtiyacımız olan tüm widget'ları satmadığını varsayalım. Ama biz MacGyver'ız, kahretsin. Diğer widget'lardan kendi widget'larımızı icat edebiliriz. FWIW, MacGyver'da en çok kullanılan yedi şey İsviçre çakıları, sakızlar, ayakkabı teli, kibrit, ataş, doğum günü mumları ve koli bandı. Bunları, bombalar ve sadece ortada duran başka şeyler yapmak için kullanıyor. Bu, menü çubuğu oluşturması gereken bir web yazarına çok benzer. Menü çubukları HTML'nin parçası olacağını düşünebilirsiniz ama öyle değildir. Tamam o zaman. Yazarların bağlantılar ve düğmelerden memnun kalacağını düşünmemiştiniz, değil mi? Bu nedenle yazar, favori araçlarını (div'ler, resimler, stil, tıklama işleyiciler, tuşa basma işleyicileri, spit ve ARIA) kullanarak bir tanesini derler.

Bazen ARIA'yı maksimum derecede kullanmak yerine sadece geliştirme olarak kullanırız. Temelde çalışan bir HTML'ye biraz ARIA serpmek yararlı olabilir. Örneğin, bir form denetiminin geçersiz bir girişle ilgili bir hata mesajı uyarısını işaret etmesini isteyebiliriz. Veya bir metin kutusunun arama için olduğunu belirtmek isteyebiliriz. Bu küçük ince ayarlar, sıradan web sitelerini bir ekran okuyucuyla daha kullanılabilir hale getirebilir.

Menü çubuğu örneği

Fare tıklayan kullanıcıları destekleme

Birlikte bir menü çubuğu oluşturalım. Div adı verilen genel kutu öğelerinde çok sayıda öğe gösteririz. Kullanıcımız bir div öğesini her tıkladığında ilgili komutu yürütür. Harika, fare tıklayıcı kişilerin işine yarar!

Sonra güzel görünmesini sağlarız. Stilleri, öğeleri güzelce hizalayıp çevresine görsel dış çizgileri yerleştirerek CSS kullanırız. Bu menünün bir menü çubuğu olduğunu ve nasıl kullanılacağını sezgisel olarak gören diğer menü çubukları gibi görünmesini sağlarız. Hatta menü çubuğumuz fareyle üzerine geldiğinizde farklı bir arka plan rengi kullanarak kullanıcıya yararlı bir görsel geri bildirim sağlar.

Bazı menü öğeleri üst öğelerdir. Alt alt menüler oluşturur. Kullanıcı bu sayfalardan birinin üzerine geldiğinde, alt menüyü kaydıran bir animasyon başlatırız.

Web üzerindeki pek çok öğe için geçerli olan bu durum, elbette oldukça erişilemez durumdadır. Bunun en büyük nedeni, HTML standardı sihirbazlarının bir web yazarının ihtiyaç duyduğu her şeyi eklememesidir. Öyle olsa bile, web yazarları her zaman kendi özel sürümlerini icat etmek ister.

Menü çubuğu klavyemizi erişilebilir hale getirme

Erişilebilirliğe yönelik ilk adım olarak klavye erişilebilirliği ekleyelim. Bu bölüm yalnızca HTML kullanır, ARIA kullanmaz. Yardımcı teknolojilere sahip olmayan kullanıcılar için ARIA'nın görünüm, fare veya klavye gibi temel özellikleri etkilemediğini unutmayın.

Bir web sayfasının fareye yanıt verebildiği gibi, klavyeye de yanıt verebilir. JavaScript'imiz tüm tuş vuruşlarını dinler ve tuşa basmanın yararlı olup olmadığına karar verir. Öyle değilse de yiyemeyecek kadar küçük bir balık gibi sayfaya geri dönüyor. Kurallarımız aşağıdaki gibidir:

• Kullanıcı bir ok tuşuna basarsa kendi dahili menü çubuğu şemalarımıza bakalım ve yeni etkin menü öğesinin ne olması gerektiğine karar verelim. Görmekte olan kullanıcının görsel olarak nerede olduğunu bilmesi için, mevcut öne çıkan tüm bilgileri silecek ve yeni menü öğesini vurgulayacağız. Daha sonra web sayfası, tarayıcının olağan işlemi (bu örnekte sayfayı kaydırma) yapmasını engellemek için event.preventDefault() çağrısı yapmalıdır.
• Kullanıcı Enter tuşuna basarsa bunu bir tıklama gibi değerlendirip uygun işlemi gerçekleştirebiliriz (hatta başka bir menü bile açabiliriz).
• Kullanıcı başka bir şey yapması gereken bir tuşa basarsa onu yemeyin! İçeriği doğal olarak sayfaya geri döndürün. Örneğin, menü çubuğumuz Sekme tuşuna ihtiyaç duymaz, bu yüzden geri dönün! Bunun doğru bir şekilde yapılması zordur ve yazarlar genellikle konuyu karıştırır. Örneğin, menü çubuğunda ok tuşları gerekir ancak Alt+Ok veya Command+Ok tuşları kullanılamaz. Bunlar, tarayıcı sekmenizin web geçmişinde önceki/sonraki sayfaya gitmek için kullanılan kısayollardır. Yazar dikkatli olmazsa menü çubuğu bunları yer. Bu tür hatalar çok sık yaşanıyor. Henüz ARIA'yı kullanmaya başlamadık bile!

Ekran okuyucunun menü çubuğumuza erişimi

Menü çubuğumuz koli bandı ve div'lerle oluşturuldu. Sonuç olarak, bir ekran okuyucu bu öğelerin ne olduğunu bilmez. Etkin öğenin arka plan rengi sadece bir renktir. Menü öğesi div öğeleri, özel bir anlamı olmayan düz nesnelerdir. Sonuç olarak, menü çubuğumuzun kullanıcısı hangi tuşlara basacakları veya hangi öğeyi kullandıklarına dair herhangi bir talimat almaz.

Ancak bu hiç adil değil! Menü çubuğu, gören kullanıcılar için sorunsuz bir şekilde çalışır.

ARIA kurtarın. ARIA, odak noktasının bir menü çubuğunda olduğunu ekran okuyucuyla taklit edebilmemizi sağlar. Yazar her şeyi doğru yaparsa özel menü çubuğumuz, tıpkı bir masaüstü uygulamasındaki menü çubuğu gibi ekran okuyucuya bakar.

İlk örneğimiz, ARIA'nın aria-activedescendant özelliğini kullanıp o anda etkin olan menü öğesinin kimliğine ayarlamaktır. Bu özellik değiştiğinde bunu güncellemeye dikkat edin. Örneğin, aria-activedescendant="settings-menuitem". Bu küçük beyaz liste, ekran okuyucunun ARIA etkin öğemizi odak noktası olarak kabul etmesine neden olur. Bu öğe, sesli olarak okunur veya Braille ekranında gösterilir.

ancestor, ancestor ve ancestor açıklaması

Alt öğe terimi, bir öğenin başka bir yerde içinde bulunduğunu ifade eder. Buna karşıt terim ise üst öğedir. Yani bir öğenin üst öğelerde bulunduğunu ifade eder. Bir sonraki üst/alt container için bunlar daha spesifik olan "üst/alt" terimlerini 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 paragraf, ancak aynı zamanda dokümanı üst öğe olarak içeriyor. Diğer taraftan, dokümanda her biri bağlantı içeren birçok paragraf alt öğesi olabilir. Bağlantıların tümü, büyük üst belgenin alt öğeleridir.

aria-activedescendant uygulamasına geri dön. Ekran okuyucu, bunu odaklanılan menü çubuğundan belirli bir menü öğesine işaret etmek için kullandığında artık kullanıcının nereye taşındığını bilir, ancak nesneyle ilgili başka hiçbir şey bilmez. Bu div işi nedir? İşte bu noktada rol özelliği devreye girer. Genel olarak kapsayıcı öğesinde role="menubar" kullanıyoruz, sonra öğe gruplarında role="menu" ve bağımsız menü öğelerinde role="menuitem" kullanıyoruz.

Peki ya menü öğesi bir çocuk menüsüne yönlendirebilirse? Kullanıcının bunu bilmesi gerekiyor, değil mi? Gören bir kullanıcı için menünün sonunda küçük bir üçgen resmi olabilir ancak ekran okuyucu en azından bu noktada resimleri otomatik olarak nasıl okuyacağını bilmez. Her bir genişletilebilir menü öğesine aria-expanded="false" ekleyebiliriz. Böylece, 1) genişletilebilen bir öğe olduğunu ve 2) şu anda genişletilmediğini belirtiriz. Yazar, ek bir dokunuş olarak, yalnızca güzelleştirme amaçlı olduğunu belirtmek için img üçgene role="none" yerleştirmelidir. Bu durum, ekran okuyucunun görüntü hakkında fazladan ve sinir bozucu olabilecek herhangi bir şey söylemesini engeller.

Hatalarla başa çıkma

Klavye hataları (HTML!)

Klavye erişimi çekirdek HTML'nin bir parçası olsa da yazarlar klavyeyle gezinmeyi çok fazla kullanmadıkları veya doğru yapılması gereken çok fazla ayrıntı olduğu için her zaman bunu bozar.

Hata örnekleri:

• Onay kutusu geçiş yapmak için boşluk çubuğunu kullanıyor, ancak yazar preventDefault() adlı kullanıcıya telefon etmeyi unuttu. Şimdi Boşluk tuşu, hem onay kutusunu hem de sayfayı aşağı kaydırır. Bu, boşluk çubuğu için varsayılan tarayıcı davranışıdır.
• Bir ARIA kalıcı iletişim kutusu, sekme gezinmesini bunun içinde engellemek istiyor ve yazar, tarayıcıya özel olarak Control+Sekme tuşlarına izin vermeyi unutuyor. Artık Control+Sekme tuşlarına basarak kendi iletişim kutuları içinde geziniyor ve tarayıcıdaki sekmeler arasında olması gerektiği gibi geçiş yapmıyor. Hay aksi.
• Bir yazar, bir seçim listesi oluşturur ve yukarı/aşağı yöntemini uygular ancak home/end/pageup/pagedown veya ilk harfle gezinmeyi uygulamaz.

Yazarlar bilinen kalıpları takip etmelidir. Daha fazla bilgi için Kaynaklar bölümüne göz atın.

Sadece klavye erişimi sorunları için, bunu bir ekran okuyucu olmadan veya sanal tarayıcı modu kapalıyken denemek de yararlıdır. Ekran okuyucular, klavye hatalarını bulmak için genellikle gerekli değildir ve klavye erişimi aslında ARIA ile değil, HTML ile uygulanır. Sonuçta, ARIA klavye veya fare davranışı gibi temel özellikleri etkilemez. Web sayfasının içeriği, o anda neyin odaklandığı ve benzeri ayrıntılar ekran okuyucuya aittir.

Klavye hataları ARIA'da değil, neredeyse her zaman web içeriğindeki, özellikle HTML ve JavaScript'teki bir hatadır.

ARIA hataları: Neden bu kadar çok hata var?

Yazarların ARIA'yı yanlış anlayabileceği çok sayıda yer vardır ve bunların her biri, tamamen bozulmaya veya küçük farklara yol açar. Yazar, içeriği yayınlamadan önce bunların çoğuna ulaşamayacağından hafif olanlar muhtemelen daha kötüdür.

Sonuçta, yazar deneyimli bir ekran okuyucu kullanıcısı değilse, ARIA'da bir şeyler ters gidebilir. Menü çubuğu örneğimizde yazar, "menuitem" doğru olduğunda "option" rolünün kullanılması gerektiğini düşünmüş olabilir. aria-expanded işlevini kullanmayı, doğru zamanlarda aria-activedescendant öğesini ayarlamayı ve temizlemeyi unutabilir veya diğer menüleri içeren bir menü çubuğu bulundurmayı unutabilirler. Peki menü öğesi sayıları ne olacak? Genellikle menü öğeleri ekran okuyucular tarafından "öğe 3/5" gibi bir şekilde sunulur ve böylece kullanıcı nerede olduğunu bilir. Bu 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ı gerekir.

Bunlar da menü çubukları. Kaç tür widget olduğunu düşünün. İsterseniz ARIA spesifikasyonuna veya yazma uygulamalarına göz atın. Her kalıp için ARIA'nın hatalı kullanımının düzinelerce yolu vardır. ARIA, ne yaptıklarını bilmek yazarlara güvenir. Yazarların çoğunun ekran okuyucu kullanıcısı olmamasına göre ne gibi sorunlar çıkabilir?

Başka bir deyişle, gerçek ekran okuyucu kullanıcılarının gönderilebilir olarak kabul edilmeden önce ARIA widget'larını denemesi yüzde 100'dür. Çok fazla nüans var. İdeal olan, birçok farklı uygulama işleminden ve eksik birkaç uygulamadan dolayı her şeyin birkaç farklı tarayıcı-ekran okuyucu kombinasyonuyla denenmesidir.

Özet

Özetle, ARIA sihri HTML'de belirtilen her şeyi geçersiz kılmak veya bunlara ekleme yapmak için kullanılabilir. Erişilebilirlik sunusunda küçük değişiklikler yapmak veya içeriğin tamamını sunmak için kullanılabilir. Bu nedenle ARIA hem olağanüstü güçlü hem de genel olarak ekran okuyucusu kullanmayan dost canlısı yerel web yazarlarımızın elinde tehlikeli olsa da bu nedenledir.

ARIA, basit bir doğruluk geçersiz kılma işaretleme katmanıdır. Bir ekran okuyucu neler olup bittiğini sorduğunda, ARIA varsa asıl temel bilgi yerine gerçeğin ARIA sürümünü alır.

Ek 1: Ek Kaynaklar

Klavye bilgileri ve kod örnekleriyle karma referans

• W3C'nin ARIA Yazma Uygulamaları: Bu dokümanda, her bir örneğin önemli klavye gezinme özellikleri belgelenir ve çalışan JS/CSS/ARIA kodu sağlanır. Örnekler şu anda işe yarayan yöntemlere odaklanmıştır ve mobil cihazları kapsamaz.

Ek 2: ARIA en çok ne için kullanılır?

ARIA küçük veya büyük doğruları değiştirebilir veya tamamlayabilir. Bu da genellikle ekran okuyucunun önemsediği şeyleri söylemek için kullanışlıdır.

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

• Menü çubuğu, otomatik tamamlama, ağaç veya e-tablo gibi HTML'de var olmayan özel widget'lar
• HTML'de var olan, ancak yazar muhtemelen normal widget'ın çalışma biçimini veya görünümünü değiştirmeleri gerektiği için kendi widget'larını icat etmiştir. Örneğin, HTML <input type="range"> öğesi temelde kaydırma çubuğudur, ancak yazarlar bu öğenin farklı görünmesini ister. Çoğu durumda CSS kullanılabilir ancak input type="range" için CSS tuhaftır. Bir yazar kendi kaydırma çubuğunu oluşturabilir ve mevcut değerin ne olduğunu belirtmek için aria-valuenow kaydırma çubuğuyla kaydırma çubuğunu role="slider" kullanabilir.
• Canlı bölgeler, ekran okuyuculara "sayfanın bu bölümünde, değişiklik yapan her şeyin kullanıcıya anlatılmaya değer olduğunu" bildirir.
• Önemli noktalar (Artık HTML'de eşdeğerleri var). Bunlar, ekran okuyucu kullanıcılarının istediklerini daha hızlı bulmalarına yardımcı olmaları açısından başlıklara benzer. Ancak, ilgili alanın tamamını içermeleri açısından farklıdır. Örneğin, "bu kapsayıcı, sayfanın ana alanıdır" ve "buradaki kapsayıcı bir gezinme panelidir".

Ek 3: Accessibility API nedir?

Accessibility API, ekran okuyucunun veya başka bir AT'nin sayfada neler olduğunu ve o anda neler olduğunu bilmesini sağlar. Örnek olarak MSAA, IA2 ve UIA verilebilir. Ve bu yalnızca Windows! Accessibility API'nin iki bölümü vardır:

• Kapsayıcı hiyerarşisini temsil eden bir nesne "ağacı". Bunlar, yuvalanan Rus bebekler gibi, ancak her birinde başka oyuncak bebekler olabilir. Örneğin, bir belge birçok paragraf içerebilir ve bir paragraf metin, resimler, bağlantılar, kalın yazı tipi vb. içerebilir. Nesne ağacındaki her bir öğenin rol (benim nedir?), ad/etiket, kullanıcı tarafından girilen değer, açıklama ve odaklanılabilir, odaklanmış, gerekli, işaretlenmiş gibi boole durumları olabilir. ARIA bu özelliklerin herhangi birini geçersiz kılabilir. Ekran okuyucu, kullanıcının sanal arabellek modunda gezinmesine (ör. "sonraki başlığa git") yardımcı olmak için ağacı kullanır.
• "Odak artık burada yok!" gibi ağaçtaki değişiklikleri açıklayan bir dizi etkinlik. Ekran okuyucu, kullanıcıya az önce ne olduğunu anlatmak için etkinlikleri kullanır. HTML veya ARIA işaretlemesi önemli düzeyde değiştiğinde, ekran okuyucuya bir şeyin değiştiğini bildirmek için bir etkinlik tetiklenir.

Yazarlar genellikle bu erişilebilirlik API'leriyle iyi eşleşen HTML kullanır. HTML yeterli olmadığında ARIA kullanılır ve tarayıcı, nesne ağacını veya etkinlikleri ekran okuyucuya göndermeden önce HTML anlamını geçersiz kılar.