Hepinizin bu konuda sakin kalacağınıza dair bana söz vermenizi istiyorum. Size uzun zamandır beklenen bir web platformu özelliğinden bahsetmek için buradayım; Daha iyi bir çözüm için fazlasıyla gecikmiş bir kullanım senaryosunu yerine getirmekle kalmayıp, bunu hem hemen anlaşılabilen hem de aldatıcı derecede güçlü bir sözdizimi yoluyla yapan bir özellik. Doğru, bu şey geliştirici kedi nanesi ve bunu denemek için gerçekten heyecanlandığımı söylemekten çekinmiyorum - bu noktadan sonra onu bir çekmeceye koyup aklımdan çıkarmaya karar verdim. Bu, yalnızca başka hiçbir şekilde çözülemeyen bir sorunu çözmenin kesinlikle yüzde yüz gerekli olduğu durumlarda kullanılacak bir araçtır, buna "ilk etapta bir özellik oluşturmaya karşı geri adım atmak" da dahildir. O yüzden bu konuda sakin ol, tamam mı? Tamam aşkım.
Erişilebilir Zengin İnternet Uygulamaları (WAI-ARIA) 1.3 Spesifikasyonu tarafından tanımlanan, size bir ekran okuyucuda anlatımı programlı olarak tetiklemenin bir yolunu sağlayan yepyeni bir ariaNotify() yöntemi var. İlk argümanı olarak bir dizeyi ve ikinci argümanı olarak isteğe bağlı bir yapılandırma nesnesini kabul eder:
document.ariaNotify("Merhaba Dünya."); // Ekran okuyucu çağrıldığında "Merhaba Dünya" diyecektir.
Nasıl Önlem Alınmalı?
Bu, basılı olarak aynı derecede basit bir kullanım durumu için basit bir çözüm gibi görünebilir, ancak tarihsel olarak bunun, yalnızca ARIA'nın canlı bölgelerinin biraz etiket dışı kullanımıyla çözülebilecek zorlu bir sorunu vardır. Bu, canlı bölgeleri ve onların eksikliklerini anlamanın, ariaNotify'ın bizim için neler yaptığını anlamanın anahtarı olduğu anlamına gelir. Daha önce canlı bölgelerle çalıştıysanız, muhtemelen bu sekmeyi bu kod parçacığından hemen sonra kapattınız ve şu anda kollarınız zaferle havada tutularak odanın etrafında üçüncü veya dördüncü turunuzdasınız. Daha önce canlı bölgelerle çalışmadıysanız, mümkün olan en katı teknik terimlerle ifade edersek: vay be ne kadar karışıklık.
Destekli tarama bağlamında, sayfanın bir kısmı kullanıcı etkileşimine yanıt olarak değişirse veya sayfaya eşzamansız olarak bir şey yüklenip eklenirse, kullanıcı odağını değişen içeriğe taşıyana kadar bu değişiklikler keşfedilemez; kullanıcının bırakın ne olduğunu, bir şeyin değiştiğini bile bilmesinin hiçbir yolu yoktur. Canlı bölgeler, en azından tasarım gereği şunu ele alır: aria-live niteliğine sahip bir öğe, o öğenin içerdiği işaretlemede yapılan değişiklikler için anlatımı teşvik eder; işaretleme değiştirildiğinde, değişen işaretleme yüksek sesle anlatılır. Eğer aria-live iddialı bir değere sahipse, yardımcı teknolojiye "bunun acil olduğunu ve hemen anlatılması gerektiğini" bildirir. Eğer aria-live'ın kibar bir değeri varsa, "bunun bir sonraki doğal fırsatta anlatılması gerekir" der. Bir öğe üzerinde role="alert" veya role="status" kullanmak, işlevsel olarak sırasıyla aria-live="assertive" ve aria-live="polite" ile eşdeğerdir. Kağıt üzerinde oldukça makul görünüyor, değil mi?
Önemli Gelişmeler
Doğal olarak, tam olarak hangi bilginin nasıl anlatılacağına ince ayar yapmak için bir yola ihtiyacımız vardı; dolayısıyla canlı bir bölgenin davranışını belirleyen birkaç başka özellik daha var:
true : Canlı bölgenin tüm içeriğini, içinde bir şey değiştiğinde anlat
Uzmanların Görüşleri
içindeki bir şey değiştiğinde canlı bölgenin tüm içeriğini anlat yanlış (varsayılan): yalnızca öğe içinde değişen metni duyurun
metin : içeriğin ifade edilmesi (metin, tıpkı kutunun üzerinde söylendiği gibi) canlı bölge içinde değiştiğinde kullanıcıya bilgi verin
Sonuç ve Değerlendirme
içeriği ifade ederken kullanıcıyı bilgilendir (tıpkı kutunun üzerinde yazdığı gibi metin) canlı bölge içindeki değişiklikler eklemeler : canlı bölgeye bir düğüm eklendiğinde kullanıcıya bilgi ver
canlı bölgeye bir düğüm eklendiğinde kullanıcıya bilgi ver kaldırma işlemleri : canlı bölgeden bir düğüm kaldırıldığında kullanıcıya bilgi ver
canlı bölgeden bir düğüm kaldırıldığında kullanıcıya bilgi ver all : metin değiştirilirse ve/veya DOM'a öğe eklenirse veya DOM'dan öğe kaldırılırsa kullanıcıya bilgi ver
Yine teoride yeterince sağlam! Canlı bölgeleri hemen hemen her şey için kullanmaya çalıştığınız noktaya kadar sorun çözüldü. Uygulamada, tarayıcılar ve yardımcı teknolojiler, özellikle canlı bir bölge içindeki iç içe işaretlemeyle ilgili olduğu için, uygulama konusunda son derece tutarsızdır; eğer aria-live'ın beklendiği gibi çalışmasını istiyorsanız, genellikle kullanmanız gereken diğer anlamsal olarak anlamlı işaretlemeleri çıkarmanız gerekir. Destekli tarama bağlamlarında güvenilir bir şekilde çalışabilmek için, anlatımın tetiklendiği anda DOM'da canlı bir bölgenin zaten anlamlı bir şekilde mevcut olması gerekir. A canlı bölge görüntüden değiştirilemez: yok veya anlatılacak içerikle birlikte sayfaya enjekte edilemez veya içeriğin anlatılmasını engelleyen zamanlama sorunlarıyla karşılaşırsınız - tarayıcı canlı bölgeyi ilk "gördüğünde" kilitlenir "tamam, bu kapsayıcıda değişen her şeyi anlat", bu da başlangıçtaki içeriği mutlaka içermeyebilir. "İddialı" ve "kibar" değerlerin çalışma şekli, spesifikasyonda özellikle iyi tanımlanmamıştır veya ekran okuyucular ve tarayıcı kombinasyonlarında da gerçekleştirilmemiştir. Tekrar ediyorum: tam bir karmaşa.
Gelecekte Ne Bekleniyor?
Durum böyle olmasa bile canlı bölgelerin amacı ile modern web'in oluşturulma şekli arasında temel bir uyumsuzluk var. Söylediğim gibi, canlı bölgeler yalnızca söz konusu öğeye işaretleme eklendiğinde/çıkarıldığında çalışır ve bu, bir sayfanın görünür içeriğinde değişiklikle sonuçlanan çoğu etkileşimin gerçeği değildir. Halihazırda belgede bulunan, ancak aksi takdirde hareketsiz olan işaretlemeyi ortaya çıkardığınızda, canlı bölgelerin hiçbir faydası olmaz (örneğin, görünür bir görüntü özelliği ile display: none arasında geçiş yapmak). Bu kullanım durumu, mevcut belgede anında yapılan yapısal değişiklikler kadar yaygındır, hatta daha fazlasıdır.
Tüm bu sınırlamalar, canlı bölgelerin neredeyse yalnızca geçici bildirim API'leri olarak kullanılmasına yol açmıştır: sayfada gömülü, görsel olarak gizlenmiş (ancak display: none aracılığıyla erişilebilirlik ağacından kaldırılmamış), anlatılmasını istediğiniz metinle gerektiği gibi güncelleyebileceğiniz bir veya daha fazla aria-live öğesi bulunur. Ben orada bulundum ve bunu yaptım ve özellikle canlı bölgelerin özünde ne kadar tutarsız olduğu nedeniyle bu hantal. Bu enjekte edilen içerik, yardımcı teknoloji aracılığıyla sayfada gezinen bir kullanıcı için de zorunlu olarak mevcuttur, yalnızca orijinal anlamından farklı olarak belgede yüzer - daha sonra temizlik konusunda titiz değilseniz, sayfaya potansiyel olarak kafa karıştırıcı, bağlamsal olarak alakasız bir anlatım kaynağı eklemiş olursunuz. Ama hepsinden önemlisi, yeni ve görünmez bir endişeyi eklediniz; özel test ve bakım gerektiren bir özellik ve kelimenin tam anlamıyla görülmemiş şekillerde bozulabilen ve bunu sinir bozucu, yanıltıcı, kafa karıştırıcı veya yukarıdakilerin hepsine yol açma potansiyeline sahip şekillerde gerçekleştirebilen bir özellik. Erişilebilirlik çalışmasıyla sizi ilgilendiren şey de budur: Tek başına alınan hızlı ve kolay kararlar, genel deneyim bağlamında öngörülemeyen sonuçlara yol açabilir ve bu varsayımlar çok dikkatli bir şekilde (erken ve sık sık) test edilmediği sürece, bu sonuçların ne olabileceğini bilemeyiz.
Sistem Güvenliği
AriaNotify yöntemi, bu tür Rube Goldberg erişilebilirlik düzeneğinin yerini alarak size gerçek bir ekran okuyucu bildirim API'si sağlar; karmaşık (ve düzensiz) işaretlemeye gerek yoktur:
Detaylar ve Etkileri
document.ariaNotify("Merhaba Dünya.");
Teknik Analiz
ariaNotify, Element arayüzünde veya Document arayüzünde bir yöntem olarak mevcuttur - burada göreceğiniz örnekler için ikisi arasında anlamlı bir fark yoktur, ancak document.ariaNotify() öğesinin çağrılmasının, özellikle html öğesinde belirtilen lang niteliğinin, bildirimin dilini çıkarmak için kullanılacağı anlamına geldiğini bilmekte fayda var:
const btn = document.querySelector( "button.announce"); btn.addEventListener("tıklayın", function( e ) { document.ariaNotify( "Merhaba, Dünya." ); }); /* * Düğmeye tıklamak, `` öğesinde belirtilen `lang` özelliğini kullanan "kibar" zamanlı "merhaba dünya" * duyurusuna neden olur. * biri yoksa tarayıcının varsayılan dili kullanılır. /*
Bir öğeden ariaNotify() çağrılırken, bildirimin dilini belirlemek için öğenin en yakın atasının lang özelliğinin kullanılacağı anlamına gelir:
const btn = document.querySelector( "button.announce"); btn.addEventListener("tıklayın", function( e ) { this.ariaNotify( "Merhaba, Dünya." ); }); /* * Düğmeye tıklamak, telaffuzu belirlemek için "düğmenin" (veya * "lang" ile en yakın ana öğenin) "lang" özelliğini kullanan "kibar" zamanlı "merhaba, dünya" duyurusuna neden olur. Belgede böyle bir dil yoksa ('' dahil olmak üzere tüm *'ler) tarayıcının varsayılan dili kullanılır. /*
ariaNotify, açık bir öncelik düzeyi belirlemenize olanak tanıyan ikinci bir parametreyi kabul eder:
const btn = document.querySelector( "button.announce"); btn.addEventListener("tıklayın", function( e ){ this.ariaNotify( "Merhaba dünya.", { öncelik: "yüksek" }); });
Bu bildirimlerin varsayılan önceliği, aria-live='po gibi davranan önceliktir: "normal" lite" (veya role="status" ). Açık bir öncelik ayarlamak: "high", aria-live="assertive" (veya role="alert" ) gibi mevcut anlatımı önceliklendirecek ve potansiyel olarak kesintiye uğratacaktır.
Şu ana kadar API'nin tamamı bu kadar. İşaretlemeyle uğraşmak yok, zamanlamalarda ustalık kazanmak yok; Anlatılacak bir şeye ihtiyacınız varsa ariaNotify'ı çağırırsınız ve o da aynen bu şekilde anlatılır. Şu anda konuştuğumuz gibi bunu Firefox'ta deneyebilirsiniz, ancak henüz dil özellikleri dikkate alınmış gibi görünmüyor:
CodePen Yerleştirme Geri Dönüşü
Kibar, düğme. Etkinleştirmek için boşluk çubuğuna basın. [boşluk çubuğuna basıldı] Boşluk. Merhaba Dünya. İddialı, düğme. Etkinleştirmek için boşluk çubuğuna basın. [boşluk çubuğuna basıldı] Boşluk. Merhaba Dünya. Educado [doğru telaffuz edilir], düğme. Etkinleştirmek için boşluk çubuğuna basın. Uzay. Hola, Mundo [yanlış telaffuz edildi].
Kibar, düğme. [boşluk çubuğuna basıldı] Merhaba Dünya. İddialı, düğme. [boşluk çubuğuna basıldı] Merhaba Dünya. Educado [doğru telaffuz edilir], düğme. [boşluk çubuğuna basıldı] Hola, Mundo [yanlış telaffuz edildi].
Kibar, düğme. Şu anda bir çerçevenin içindeki bir düğmenin [boşluk çubuğuna basılmış] üzerindesiniz. Bu düğmeye tıklamak için Control – Option – Space tuşlarına basın. Bu web alanından çıkmak için Control – Option – Shift-Up Arrow tuşlarına basın. Merhaba Dünya. İddialı, düğme. Şu anda bir düğmenin üzerindesiniz [boşluk çubuğuna basıldı] Merhaba Dünya. Educado [doğru telaffuz edilir], düğme. Şu anda bir çerçevenin içindeki bir düğmenin [boşluk çubuğuna basılmış] üzerindesiniz. Bu düğmeye tıklamak için Control – Option – Space tuşlarına basın. Bu web alanından çıkmak için Control – Option – Shift-Up Arrow tuşlarına basın. Hola, Mundo [yanlış telaffuz edildi].
Oldukça sağlam, değil mi? Hepimizin canlı bölgeleri kullanmak zorunda kaldığımıza dair büyük gelişme. Ben, örneğin, ariaNotify'ı neredeyse kullanmak için sabırsızlanıyorum, sonra - yine - hemen kendimi bundan vazgeçiriyorum!
Bu isteksizlik neden? Erişilebilirlik çevrelerinde bazen ARIA'yı kullanmayı öğrenmenin üç aşaması olduğu söylenir:
ARIA'yı kullanmıyorsunuz. ARIA'yı kullanıyorsunuz. ARIA'yı kullanmıyorsunuz.
W3C, uzmanlık alanları gibi bunu daha resmi terimlerle ifade ediyor:
Bir öğeyi yeniden amaçlandırmak ve onu erişilebilir kılmak için bir ARIA rolü, durumu veya özelliği eklemek yerine, zaten yerleşik olarak ihtiyaç duyduğunuz semantik ve davranışa sahip yerel bir HTML öğesi [HTML] veya öznitelik kullanabiliyorsanız, bunu yapın. —ARIA Kullanımı: ARIA Kullanımının İlk Kuralı
ARIA ustalığının bu ikinci aşaması başımızın belaya girdiği yerdir. Web kaotik bir yer, ancak bununla birlikte yardımcı teknolojiler de gelişti ve bir kullanıcının karşılaşabileceği daha yaygın sorunların bazılarını ele almayı öğrendiler. Örneğin, tıklandığında kendisini takip eden görsel olarak gizli bazı içeriği ortaya çıkaran bir h2'niz olduğunu varsayalım; bu öğe, bu etkileşimi görsel olarak netleştirecek bir şekilde sunulabilir, ancak bizim müdahalemiz olmadan, ekran okuyucu aracılığıyla gezinen kullanıcıya aksi takdirde sinyal verilmeyebilir. Bu soruna geçici bir çözüm bulmak için yardımcı teknolojiler, kullanıcının o başlığa bağlı bir tıklama olayı dinleyicisini bulmasına odaklandığında bu başlık öğesini "tıklanabilir" olarak anlatabilir. Kabul ediyorum, bu, kullanıcıya bu öğenin amacını açıkça belirtmek kadar iyi değildir, ancak bu etkileşimi açıkça belirtmemiş olsak bile işe yarayabilir.
İşin püf noktası, bu etkileşimi nasıl açık hale getirdiğimizdir. ARIA'ya biraz aşina iseniz, kendinizi şöyle düşünürken bulabilirsiniz: "Bu öğe bir düğme gibi davranıyor, bu yüzden kullanıcıya bunun bir şey yaptığını bildirmek için üzerine role="button" koymalıyım." Bu dürtü kesinlikle yanlış değil, ancak bu nitelikle birlikte muhtemelen istenmeyen bir sonuç da geliyor: Öğenin rolü hakkında açık davranarak, onun örtülü anlamını ortadan kaldırıyoruz. Tarayıcıya ve yardımcı teknolojiye, kesin bir ifadeyle, bunun bir başlık olmadığını söylüyorsunuz; yani kullanıcı belge taslağı yoluyla geziniyorsa, bu öğe artık o gezinmenin bir parçası olmayacak ve basit, yararlı bir hızlı düzeltme gibi görünen şey, sonunda istenmeyen sonuçlara yol açacaktır. ARIA yoruma yer bırakmıyor; söylediklerimiz geçerli, nokta. “Bunu anlat” diyoruz, anlatılıyor. Pazarlık edilemez.
Yani, tartışmasız bir şekilde "bunu anlatmanı söylediğimde, sen anlatacaksın" diyen, kullanımı çok kolay bir özellik göz önüne alındığında, lütfen burada yüksek sesle "alert()" dediğimde sert, gözünü kırpmadan göz teması kurduğumu varsayalım - hayali bir senaryo, bunu bir şekilde tek aralıklı bir yazı tipiyle söylemeyi başardığım gerçeğiyle daha da rahatsız edici hale geldi.
window.alert("Merhaba dünya, beğen ya da beğenme.");
Alert()'ı çok eski zamanlardan hatırlıyorsunuz, değil mi? kadar meşhur bir yöntem iğrenç bir şey. Sektörde daha yeniyseniz, bir lütuf olarak, buna ilk elden aşina olmayabilirsiniz. ariaNotify gibi, teknik olarak kullanıcıya bilgileri anında sunmaya yönelik hızlı ve kolay bir API'dir:
alarm() basit, etkili, tutarlı ve - yaygın olarak kullanıldığı zamanlarda - inanılmaz derecede sinir bozucu. ariaNotify() size aynı gücü emanet ediyor, bu sefer ARIA'nın görünmez, boyun eğmez otoritesi tarafından destekleniyor. ariaNotify() cebinizdeyken, "bu kafa karıştırıcı olabilir, bu yüzden tam olarak neler olup bittiğini anlatacağım" hızlı ve kolay bir karar olacaktır ve bu, tüm kaosuna ve tutarsızlığına rağmen web'de gezinme konusunda zaten yetenekli olan bilgili bir kullanıcının, zaten anladığı bir etkileşimle ilgili bir ders nedeniyle gezinmesinin kesintiye uğradığı anlamına gelebilir.
Kalbi tamamen doğru yerde olan bir geliştiricinin, içeriğin sayfadaki bir etkileşim yoluyla ortaya çıktığı konusunda kullanıcıyı bilgilendirmek için ariaNotify'ı kullandığını hayal etmek zor değil. Bununla birlikte, bağlamda, içeriğin ortaya çıkarılması, muhtemelen ilişkili bir olay dinleyicisinin varlığı, öğenin doğasında bulunan semantik veya aria-expanded='false' özelliğinin varlığı sayesinde zaten "tıklanabilir" olarak anlatılan bir öğeyle etkileşimde bulunmak anlamına geliyordu (bir öğeyle etkileşime geçmenin ilişkili içeriği ortaya çıkaracağının sinyalini vermek için doğru yaklaşım). Bu durumda yaptığımız tek şey kullanıcının sayfa deneyimine gürültü eklemektir ve kimsenin buna ihtiyacı yoktur. Demek istediğim, alarm( "Bu makale hakkında yeni bir yorum var!" ) üçüncü kez sözünüzü kestiğinde bu cümleyi okurken yarı yolda olduğunuzu veya atlanamayan bir video oyunu eğitimi gibi 'un üzerine gelip yalnızca alarm( "Navigasyonu açmak için buraya tıklayın." ) ile karşılaştığınızı hayal edin. Ah. Sekmeyi kapatırdım.
Daha da kötüsü, anlatılan bir talimat, etkileşimin gerçekliğiyle senkronize olmazsa (özel ekran okuyucu testi olmayan bir QA süreci tarafından yakalanamayacak görünmez bir tutarsızlık), kullanıcının, sadece işlerini halletmeye ve gününe devam etmeye çalışırken, temel sayfa ile kendi ekran okuyucusu arasında bir tartışmaya girmesine neden olabiliriz.
ARIA güçlü bir şeydir. Bize bir sayfadaki öğeler arasındaki anlamları, durumları ve ilişkileri mutlak, kesin bir gerçek olarak tanımlama yeteneği verir; web'i oluşturan bizler ile onu kullananlar arasında bir iletişim hattı sağlar. Bu iletişim hattı hiçbir yerde, tarayıcının sesini ve onların bildiği ve güvendiği yardımcı teknolojiyi kullanarak son kullanıcıyla etkili bir şekilde doğrudan konuşmamıza olanak tanıyan ariaNotify() özelliğinden daha doğrudan olamaz. Bu, tek bir yönteme bağlı çok fazla sorumluluktur. Çok gerçek bir sorunu çözüyor, ancak pek çok teknoloji gibi: Dikkatli kullanılmazsa bir o kadar da soruna yol açabilir.
ariaNotify() konusunda ölçülü ve temkinli bir şekilde heyecanlıyım. Sonunda bize, yıllardır web'i ve kişisel olarak beni rahatsız eden bir kullanım durumunu şaşırtıcı derecede kolay bir şekilde ele almanın bir yolunu sunuyor. Aslında o kadar kolay ki, ariaNotify()'ı biraz tehlikeli kılıyor.
Yani bizim için değil, değil mi? Çünkü hepimiz bu konuda sakin olacağız, değil mi?
