Heydon Pickering ile Çarpıcı Podcast 4. Bölüm: Kapsayıcı Bileşenler Nelerdir?

Bugün Heydon Pickering ile yeni kitabı Inclusive Components hakkında konuşuyorum. Heydon, erişilebilirlik konusundaki çalışmaları ve yazılarıyla tanınır - peki "Kapsayıcı Tasarım" aslında ne anlama geliyor ve bileşenler nerede devreye giriyor? Heydon bu bölümde tüm bunları ve daha fazlasını açıklıyor. Aşağıdan dinleyebilir veya podcast'lerinizi aldığınız her yerden abone olabilirsiniz.

Notları göster

• Smashing Magazine'den Kapsayıcı Bileşenler kitabı
• Heydon'un projesi Her Düzen Andy Bell ile
• Heydon'un web sitesi Heydonworks
• Twitter'da Heydon

Transcript

Drew McLellan: Serbest çalışan bir web erişilebilirlik danışmanı, arayüz tasarımcısı ve yazar. Çalışmaları, erişilebilir kullanıcı deneyimi tasarımının yanı sıra Smashing Magazine için yazı ve düzenleme üzerine odaklanmaktadır. Erişilebilir web uygulaması tasarımı hakkında beğenilen herkes için Apps kitabının yazarıdır ve Smashing Magazine ile yeniden erişilebilir web arayüzlerinin nasıl oluşturulacağını anlatan Inclusive Components adlı yeni bir kitap yayınladı. Yani erişilebilir tasarım konusunda açık bir şekilde uzman, ancak onun Sidney Liman Köprüsü'nden bir sürat teknesiyle atlayan ilk erkek insan olduğunu biliyor muydunuz? Smashing dostlarım, lütfen Heydon Pickering'e hoş geldiniz. Merhaba, Heydon. Nasılsınız?

Heydon Pickering: Eziyorum. ben markayım.

Drew: Bugün sizinle yeni kitabınız Kapsayıcı Bileşenler hakkında konuşmak istedim.

Heydon: Evet.

Drew: Açıkçası sadece iki kelimelik bir başlık, ama bu kelimelerin her birinin çok fazla yük kaldırdığını hissediyorum. Sondan başlayarak, açıkça mantıklı olduğu gibi, bileşenler, bu bir tür bileşen tabanlı tasarımla mı ilgili? Bu nedir?

Heydon: Evet, sanırım insanlar, ön uç geliştiriciler, tasarımcılar ve arayüzler yapmak için işbirliği yapan herkes, şeyleri bileşenler ve sindirilebilir ve yeniden kullanılabilir parçalara bölme açısından düşünmeye başlayalı epey oldu. Ve sanırım bu çalışma şekline herhangi bir nedenle aşina değilseniz, bu gerçekten biraz elektronik bileşenlere benziyor. Babam elektronik mühendisi. Devre kartları, lehim ve benzeri şeylerin analog dünyasında çalışıyor.

Heydon: Aslında, CERN'de elektromıknatıslara giden akımı düzenlemek için kullanılan çok küçük bileşenler yaptı. Ve çocukken bana çok inanmıştı çünkü onlar için bazı parçaları lehimlememi sağladı. Sanırım o parti artık emekli oldu, bu yüzden benim zavallı lehimlemem, zavallı genç lehimlemem, CERN'e dahil olmaktan artık endişelenme. Ama evet, sanırım şuna benziyor… Oh, orada çok fazla analog var.

Heydon: Tek tek parçalar veya bileşenler için tek sorumluluğunuz olduğu ve birlikte devreyi oluşturduğu ve birlikte bir devre durumunda akımı artırdığı fikri, analog devre kartlarına benzer. arayüz veya sonuç, herhangi bir şekilde, bir tasarım sisteminde veya bir tasarım sistemi aracılığıyla ortaya konan bir arayüzde. Ve böylece, Kapsayıcı Bileşenler, çünkü, demek istediğim, farklı alanlarda yaptığımız şeyi ilerlettiğimizde erişilebilirliğin genel olarak geride kalma eğiliminde olduğu gerçeğine değinmek istedim ve erişilebilirlik getirmek istedim ve daha geniş anlamda Bileşenleri veya modülleri veya bunlara ne ad vermek istersen kullanarak bir şeyler yapmanın ve bu tür yeni düşünme biçimine dayanacak mantıklı, kapsayıcı tasarım.

Heydon: Yani fikir, hem tasarım sistemlerine erişilebilirlik getirmek hem de aynı şekilde, erişilebilirliği ele almaya çalışırken sistematik olarak düşünmekti. Erişilebilirlik açısından tek bir yerde bir tür sorunu çözmeyi ve bunun genel olarak tasarım sistemini [duyulmuyor 00:03:16] örüntü etrafında yayıldığından emin olmayı düşünün.

Drew: Bir tür pratik anlamda, bileşen tabanlı bir şekilde çalışmak gerçekte nasıl görünüyor? Bir bileşen örneği ne olabilir?

Heydon: Yani bileşenleri tasarlamanın ve kodlamanın farklı yolları var. Kavramsal şeyleri geçip, kodu nasıl düzenleyebileceğimi düşünerek, doğrudan işin özüne girme eğilimindeyim. Aslında özel öğelere veya özel öğeler değilse de normal öğelere odaklanmaya başladım, ancak bunlara bir tür yalıtılmış, bileşenli şekilde eklenmiş bir tür JavaScript davranışıyla. Birlikte çalışabilir bileşenler fikrini gerçekten seviyorum. Ve bununla, farklı çerçeveler, sistemler, yaklaşımlar ve teknik yığınlar arasında kullanılabileceklerini kastediyorum. Ve özel öğeler, yerel oldukları için bu konuda iyidir. Bunları tek bir yerde tanımlayabilirsiniz ve daha sonra örneğin bir tepki uygulamasında kullanılabilirler veya bir görünüm uygulamasında kullanılabilirler veya açısal bir uygulamada kullanılabilirler veya ne tür daha büyük durum yönetimi teknolojisi olursanız olun. kullanarak.

Heydon: Yani benim için genellikle bir bileşen muhtemelen özel bir öğe olacaktır. Son zamanlarda erişilebilirliğe çok fazla odaklanmayan bir proje üzerinde çalıştım, her ne kadar mümkün olduğunca erişilebilir hale getirmeye çalıştım, Her Yerleşim adı verildi ve hepsi çok özel türde algoritmaları izole etmeye çalışmakla ilgili. CSS düzeni. Ve özel öğeler olarak tanımlanırlar ve bir nevi kendilerini yerleştirirler ve kendi CSS'lerini çalıştırırlar ve daha büyük sistem içinde bir tür ilkel gibi çalışırlar.

Drew: Demek istediğim, pratik anlamda, bir bileşenin form alanı gibi bir şey olabileceğinden mi bahsediyoruz?

Heydon: Evet, yani bir girdi kadar basit bir şey olabilir. Diyelim ki bir metin girişi gibi veya sekme arayüzü gibi karmaşık bir şey olabilir. Ve böylece, Inclusive Components ile fikir, bir metin girişi gibi, umarız, tek amacı olan bir bileşen kavramını almak ve sonra farklı türden insanları tetikleyebilecek ve deneyip kaçınmaya çalışabilecek tüm farklı şeyleri düşünmekti. onlara. İnsanlardan kaçmayın, sorunlardan kaçının. İnsanları dahil etmekle ilgili değil, insanları keyfi olarak dışlamamaya çalışmakla ilgili.

Heydon: Bu benim için kapsayıcı bir tasarım sürecine yaklaşmanın en kolay yolu gibi görünüyor, bir şeyin potansiyel dışlayıcı unsurlarını bir şekilde belirlemek ve onların etrafından dolaşmaya çalışmak. Yani bir metin girişiyle, bir etiketle, orada endişelenmek isteyebileceğiniz bir dizi farklı şey var. Yani, bir başlangıç ​​için gerçekten doğru etiketlenip etiketlenmediğine sahip olacaksınız. Yani bir etiket öğesi mi kullanıyorsunuz ve bu etiket öğesi, bir ekran okuyucu kullanıcısı girdiye odaklandığında, etiketin duyurulduğunu gerçekten duyması için iki şeyin programlı olarak ilişkilendirilmesi için bir for özniteliği kullanarak metin alanına mı işaret ediyor? Yani bu doğru olması gereken bir şey.

Heydon: O zaman, bir çeşit daha görsel düzeyde, etiketin farklı bir alanla değil, açıkça o alanla ilişkili olduğundan emin olmak ve bu bir beyaz boşluk ve bu tür şeyler meselesidir. Ayrıca, etiketin olmadığından emin olarak, etiketi form girdilerinin altına koymak gibi süslü bir şey yapmıyorsunuz çünkü o zaman, örneğin bir sanal klavye geldiğinde, bu gizlenebilir. Yani bu tür şeyleri dikkate alıyor.

Heydon: Girdinin kendisinin bir odak stiline sahip olduğundan emin olun, bu nedenle bir klavyeyle odakladığınızda, gezinmek için klavye kullanan alışılmış bir klavye kullanıcısı olun ya da başka türlü, odak stilinden bunun net olduğundan emin olun. odaklandığınız giriş. Demek istediğim, otomatik tamamlama gibi şeylerden emin olmak, bunun hakkında endişelenmek, otomatik tamamlamanın bağlamda uygun ve yararlı olup olmadığı ya da değil. Ve bunların birçoğu doğrudan engelliliği ele alıyor, ancak birçoğu kullanılabilirlik açısından daha geniş ve sadece işleri olabildiğince anlaşılır hale getiriyor.

Heydon: Sıklıkla, herkes için kullanılabilirliği ve engelliliği ele alan şeyler arasında çok ince bir çizgi veya belki de bulanık bir çizgi vardır. Ve sonra, tespit etmeyi daha da zorlaştırmak için bilişsel engeller. Dolayısıyla, bilişsel engeli olmayan biri için bir şey pek kullanışlı değilse, o zaman bu tür zorluklara sahip biri için çalışmak ve kullanabilmek daha da zor olacaktır.

Heydon: Yani tüm bunları tek bir yerde düşünmeye çalışıyor. Ve gerçekten, kitap sadece benim, her birine yaklaşırken benim düşünce sürecim. Bu yüzden başlamak için bir blog olarak yaptım. Ve her kalıp veya her bileşen bir blog yazısıdır ve metin sadece ben gidiyorum, “Öyleyse, şimdi bu potansiyel sorunu ele alalım. Bu konuda nasıl gideceğiz? Tamam, bunu kontrol ettik. Bence orada iyiyiz." Ve hiçbir şekilde bunların mükemmel olduğunu ve her şeyi düşündüğümü söylemeye çalışmıyorum çünkü bu mümkün değil.

Drew: Bir arayüzün tek tek parçaları üzerinde nasıl çalıştığınıza dair bileşen tabanlı bir yaklaşım benimsemek de öyle, sanırım, o belirli öğe üzerinde gerçekten derine inmenize ve onu en iyi şekilde gerçekten yoğun bir şekilde optimize ettiğinizden emin olmanıza olanak tanır. herkesin erişebilmesi için olabilir. Bunu yapmanın ve bunu birçok farklı bileşende yapmanın ve ardından hepsini bir sayfada bir araya getirmenin bir tehlikesi var mı? Bunları birlikte değil de ayrı ayrı test ettiğiniz için farkında olmadığınız sorunlar yaratma tehlikesi var mı?

Heydon: Bu gerçekten iyi bir nokta ve aslında bunu daha önce gündeme getirecektim. Bunu söylediğine sevindim. Bu yüzden, birçok yönden, felsefi olarak, şeyleri bu bireysel bileşenlere ayırmamız gerektiğine karar verdik. Ve bunu yapmanın erdemi var, çünkü eğer izole edilmişse, o zaman bir tür test etmek ve tek bir şey gibi davranmak daha kolay. Ve bir nevi, çalışma şeklimiz açısından, işleri yönetmeyi kolaylaştırıyor. Ayrıca, bu şeylerin nihayetinde aynı alanı paylaşması ve daha büyük bir sistemde bir araya gelmesi gerektiği gerçeğini de dikkate almalıyız.

Heydon: Ve aslında, yeterince çaba ve düşüncemizin buna harcandığını düşünmüyorum, yeterince komik. Sanırım mühendisler olarak hayatımızı kolaylaştırmak için işleri daha fazla bileşenleştiriyoruz, böylece ne zaman ne üzerinde çalıştığımızı biliyoruz. Ve sonra, bu şeylerin dinamik sistemlerde yaşayacağı ve olması gerektiği gerçeğini sıklıkla ihmal ediyoruz…

Heydon: Demek istediğim, Her Yerleşim projesi, daha çok görsel tasarım ve yerleşimle ilgili olsa da, tamamen bu küçük CSS ilkellerini, bu küçük yerleşim düzenini, algoritmik olarak kendi kendilerini yönetebilecekleri şekilde yapmaya çalışmakla ilgilidir. Bu, onları dar bir sütundan alıp geniş bir sütuna koyabilmeniz için ve sonra olacak, kodun kendisi yan yana kaç öğe olması gerektiğini veya kendisini başka bir şekilde yeniden yapılandırması gerekip gerekmediğini belirleyecektir. Çünkü sürekli müdahale etmeyi göze alamayız ve bence bir nevi kendini bilen ve akıllı bir sistem olmalı.

Heydon: Her zaman unutabileceğin şeyler vardır. Belki bir sekme arayüzü yaparsınız, bir dizi sekmeniz olur, sekme arasında seçim yaparsınız ve sekme bir sekme paneline karşılık gelir, bu bir şeyler açar. Ve sonra, biri gelecek ve diyecekler ki, "Peki, ya bir sekme arayüzünün içine bir sekme arayüzü koymak istersem ya da bir dokunma arayüzünün içine başka bir bileşen koymak istersem?"

Heydon: Ve tabii ki, demek istediğim, bunun mümkün olup olmayacağı kısmen teknik bir endişe, ama evet, işleri olabildiğince esnek hale getirip getirmeme konusunda bir seçim yapmalısın, böylece öyle olsun. şeyleri karmaşık bir şekilde üst üste bindirmek veya basitçe, “Buraya bir şey koyamazsınız çünkü kod açısından karmaşıklık seviyesi muhtemelen çok yüksek olacaktır, ama aynı zamanda muhtemelen kullanıcının bir şeyi nasıl algılayıp kullanabileceğidir.” “Bir sürü karmaşık işlevi kendi içine yerleştirmeyin” diyen kurallar yazmaktan yanayım çünkü insanların bu konuyu gerçekten anlamaları pek olası değil.

Drew: Erişilebilirlik için tasarım yaparken tamamen algoritmik veya otomatik bir yaklaşım benimsemek mümkün mü?

Heydon: İnanmıyorum. Hayır. Yani otomatik araçlarımız var ve otomatik araçları hiçbir şekilde kötülemek istemiyorum. Çok faydalı olduklarını düşünüyorum, ancak onları sorunlu alanların nerede olduğuna dair bir izlenim edinmeye çalışmak için bir tür erken uyarı sistemi gibi kullanıyorum. Yani, ürünlerini nasıl daha erişilebilir hale getirecekleri konusunda tavsiye isteyen bir kuruluş için bir denetim yapıyor olsaydım. Bu, sorunlu alanların olduğu yerlerde fon sağlamanın iyi bir yolu, ama demek istediğim, teknik olarak %100 erişilebilir bir arayüze sahip olabilirsiniz, belki bazı araçlara göre, hatta WCAG'a karşı onu yargılamak için iyi bir araç bile olabilir. , web içeriği erişilebilirlik yönergeleri veya başka bir kabul belirtimi. Ve, işaretlenen tüm kutuların %100'ü olmasına rağmen, çeşitli nedenlerle tamamen kullanılamaz hale gelebilir.

Heydon: Örneğin, daha önce söylediklerimize geri dönersek, tamamen karmaşık olabilir. Birini bağlantılarla boğabilirsiniz ve bunun üstesinden gelmelerinin hiçbir yolu yoktur ve sonra bu, çok zımni bir şey ve sabitlenmesi zor bir şey olur, ancak insanları yabancılaştırmaya mahkumdur. Ama aynı zamanda, alabilirsiniz, yanlış pozitifler ve bunun gibi şeyler almak çok kolaydır. Geçen gün bir şey vardı, geçen ay dedim, bir organizasyon için çalışıyordum ve tabii ki %100 erişilebilirlik bir deniz feneri okulu olsun istiyorlardı ve oraya dinamik olarak bırakılan bir iframe vardı. analitik bir komut dosyası veya başka bir şey tarafından. Bir tür biraz brüt kodun olduğu, bunun gibi bir görevi yapmak için sayfaya takılan bir tür şeyi bilirsiniz.

Heydon: Şimdi, analitiği hiç kullanmamanızı tavsiye ederim ve onlara en azından izleme protokolünü desteklemelerini tavsiye ettim, böylece insanlar vazgeçebilsin. Ne yazık ki, bu protokol bir tür, artık gerçekten çalışmıyor çünkü hiçbir zaman doğru şekilde desteklenmedi. Ama bu iframe, üzerinde başlık olmadığını söylüyordu. Yani fikir şu ki, bir iframe'iniz varsa, bunun bir başlık niteliğine sahip olması gerekir çünkü bu, bir ekran okuyucu kullanıcı için iframe'in ne için olduğunu belirlemenin uzun süredir devam eden en iyi yolu budur. Ancak bu, hiçbirini göstermeyecek şekilde ayarlanmış bir iframe'di, bu nedenle ilk etapta bir ekran okuyucu tarafından algılanamadı bile çünkü hiçbirini gösterme, tıpkı bir ekran okuyucudaki şeyleri görsel olarak gizlediği gibi, esasen onu ekran okuyucusundan kaldıracaktır. arayüzü, bu nedenle hiçbir şekilde karşılaşılmaz veya duyurulmaz.

Heydon: Yani yanlış bir pozitifti. Yani, en başta algılanmak için orada olmayan bir iframe'i tanımlamamı istiyordu. Bu nedenle, otomatik testlerde her zaman bu tür hatalar ve sorunlar olacaktır. Ama sonuçta, bilmekle ilgili, her ne kadar programcıların dahil olduklarını düşünmekten gerçekten hoşlanmadıkları ve biraz sıkıcı buldukları bir şey olsa da, bu insan davranışı ve hakkında insanların bir şeyleri nasıl anladıkları ve bununla ilgili bir dizi ikili tür veya boole türü kurallara sahip olmak çok zor bir şey.

Heydon: Yani, bir süre önce bu konuda danışmanlık yaparken bir geliştiriciyle konuştum ve bana şöyle dediler, "Eh, otomatik testimiz olduğu sürece iyiyiz, değil mi? Sadece, o zaman ilerleyebiliriz." Ve dedim ki, “Hala manuel olarak test etmeniz gerekiyor. Arayüzü klavyeyle kullanmanın bir şekilde imkansız olup olmadığını size gerçekten söyleyebilecek otomatik bir test yok.” Arayabileceğiniz farklı şeyler var, ancak genel deneyim hala insan tarafından değerlendirilmesi gereken bir şey. Evet.

Drew: Bazen otomatik araçlarla ilgili tehlike, öğelere ayrı ayrı bakmaları veya tek bir arayüze ayrı ayrı bakmaları ve daha geniş bağlamı görmemeleridir.

Heydon: Evet.

Drew: Elbette, performans denetimleri için deniz feneri kullanmakla, bazen bir geliştirici olarak dahil etme kararı verebilirim, o sayfada kullanılandan çok daha fazla CSS olabilir ve açıkçası, çok fazla CSS indiriyorum, ama aslında , bu dosya yüklendikten sonra, kullanıcı bir sonraki sayfaya göz attığında, CSS'ye zaten sahip olduklarını biliyorum. Yani bu, birden çok sayfada yapılan bir optimizasyon, araç tek bir sayfaya ayrı ayrı bakarak bir hata olarak görüyor.

Heydon: Evet, kesinlikle. İleriyi düşünüyorsunuz ve bir yargı kararı veriyorsunuz ve biz bunu tahmin etmek için gelişmiş yapay zekaya ulaşana kadar, o zaman evet, gerçekten insanların ona bakmasına, üzerinden geçmesine ve gitmesine ihtiyacınız var… Yani, otomatik testlerin yapılması gerekir. Dediğim gibi, bir tür erken uyarı sistemi, teşhis sistemi mevcut olmalı, ancak aynı zamanda, kuruluşunuzun gerçekten önemsemesi ve işleri daha kapsayıcı ve daha erişilebilir hale getirmesiyle ilgileniyorsanız, eğitimin de olması gerekir. . Soru-Cevap olması gerekiyor.

Heydon: Bu yüzden, "Bu bileşenle bir klavyeyle etkileşim kurduğunuzda böyle çalışması gerekir" veya "Bu bileşenle bir ekran okuyucuyla etkileşim kurduğunuzda ve aslında adım atmadığınızda böyle çalışması gerekir" için komut dosyaları yazardım. o. Yani, bunu yaptığınızda, bu olmalı. Bunu yaptığınızda, bu olmalı. Bunu yaptığınızda, bu görünmelidir” veya bu tür şeyler. Yani, sizin de söylediğiniz gibi, yolculuk türü şeyler, otomatik araçlar bunun farkında değil. Yalnızca, "Ah, bunun burada alternatif metni yok" ifadesini görürler. Ve aslında, birçok durumda, belki de alt metni olmamalıdır. Ayrıca, alternatif metni iyi yazıp yazmadığınızı da yargılayamaz. Bu nedenle, alternatif metni olmayan bir görüntünün, yanıltıcı veya yalnızca kötü alternatif metin içeren bir görüntüden muhtemelen daha iyi olduğunu düşünüyorum. Ve bu yine bir yargılama çağrısı, değil mi?

Drew: Tarihsel olarak, bir şeyleri erişilebilir bir şekilde inşa ederken uğraştığım şeylerden biri, en iyi uygulama hakkındaki bilgilerimi güncel tutmaktır, çünkü bu, herhangi bir belgeye veya herhangi bir öneriye atıfta bulunduğumda, Yaptığım ve doğru şeyi yaptığımı düşündüğüm gibi görünüyor, tavsiyeler devam etti ve şimdi başka bir şey yapmalıydım. Ve bu, web üzerinde çalışmanın tüm alanlarıyla ilgili tanıdık bir hikaye. Ancak bence erişilebilirlik sorunlarıyla ilgili tehlike şu ki, en iyi uygulamayı izlemiyorsanız, arayüzünüzde şu anda iyi bir uygulama olmayan bir şey bırakırsanız, bu kullanıcılarınızı olumsuz yönde etkileyebilir. yol. Bir arayüz veya site oluşturmak için bileşen tabanlı bir yaklaşım var mı, buna herhangi bir şekilde yardımcı oluyor mu?

Heydon: Tamamen, tek bir bileşeniniz olduğu için, o zaman, elbette ki fikir, sadece erişilebilirlik açısından değil, her durumda, bu bileşenin tek bir yerde tanımlanmış olması ve daha sonra farklı olarak kullanılacak olması anlamında düşünüyorum. en azından özellikler veya tarayıcı desteği veya her ne olursa olsun değiştiğinde ve bileşeni güncellemek istediğinizde, bunu yalnızca tek bir yerde yapmanız gerekir ve ardından nerede kullanılırsa kullanılsın, o geliştirme veya değişiklik hissedilecektir. Dolayısıyla bu açıdan, her şeyi bileşenlere ayırmanın kesinlikle daha faydalı olduğunu düşünüyorum.

Heydon: Ama o zaman, evet, dediğim gibi, bu sadece erişilebilirliği değil, değişen her şeyi etkileyebilir. Ama sonra, gerçekten ne kadar değişiklik olduğundan emin değilim… Demek istediğim, HTML erişilebilirliği açısından çok az değişiklik olacak, ki bu açıkçası çok dar bir alan. Ancak kod kalitesi veya kodun nasıl çalıştığı ile ilgili olarak, HTML spesifikasyonuna, açıkçası, çok yavaş ve oldukça yavaş değil ama oldukça yavaş bir şekilde ARIA spesifikasyonuna bazı şeyler dahil edilir. Ve sonra, ARIA'nın çoğu, zaten temeldeki temel HTML'de olanı yansıtır.

Heydon: Bence teknolojiden çok, bu şeylerin algılanması ve anlaşılması zamanla değişme eğiliminde. Demek istediğim, son zamanlarda WebAIM anketinde ARIA kullanan sitelerin, kullanmayan sitelerden daha erişilemez olduğunu belirlediler. Dolayısıyla, insanların web sitelerini daha erişilebilir hale getirmelerine yardımcı olmak için özel olarak tasarlanan bu teknoloji, durumu daha da kötüleştiriyordu. Yani gerçekten, bu sadece bir bilgi boşluğu, bir teknoloji boşluğu veya bir teknoloji eksikliği değil. İnsanlar sadece teknolojiyi alıp kötüye kullanıyor çünkü ne yazık ki nasıl çalışması gerektiğini gerçekten anlamadılar. Umarım, bazı yazılarım bu konuda yardımcı olabilir. Hele bazı bölgelerde.

Drew: Ama bir tür iyi yapılandırılmış bileşen tabanlı sistem, bir şeyin güncel olmadığını fark ettiğinizde veya kötü bir karar verdiğinizde ve şimdi daha iyisini bildiğinizde, daha kolay girip düzeltmenizi sağlayacaktır. uygulamanız genelinde.

Heydon: Evet, aynen. Evet, evet, kesinlikle. Demek istediğim, her şey verimlilikle ilgili, değil mi? Ve bu kuru ilke ya da ne var, işte bu yüzden, sanırım bu fırsat için başlangıçta çok heyecanlıydım, çünkü insanlar her zaman bir şeyleri erişilebilir hale getirmenin ekstra iş olduğundan ve bunun zor olduğundan ve üzücü olduğundan şikayet ederler. Ve böylece, demek için bir tür fırsattı, "Peki, bu şeyleri gerçekten, verimli bir şekilde bu bileşen sistemlerini nasıl inşa ettiğinizi biliyor musunuz? Yaptığınız tek bileşen için erişilebilirliğinizi oraya getirin ve ardından ara sıra yapılan teknik özellik değişikliği veya güncellemesi veya neye sahip olduğunuz dışında artık erişilebilirlik konusunda endişelenmenize gerek kalmadı.”

Heydon: Ya da sadece, demek istediğim, muhtemelen çoğu zaman, yineleme basitçe kullanıcı geri bildirimlerine ve devam eden araştırmalara dayanacaktır, ki bu açıkça, mümkün olduğunca farklı bir grup insanla çalışmanız gerekir. Bu nedenle, farklı cihazlar kullanan ve farklı tarama alışkanlıklarına sahip olan ve farklı yardımcı teknolojiler ve bu tür şeyler kullanan kişiler edinmelisiniz. Ve biliyorsun, işler her zaman ortaya çıkmak zorunda. Sanırım bir bileşeni gerçekten sabitledim, gerçekten çok sağlam olduğunu düşünüyorum ve sonra biraz araştırma yapıyorum ve oldukça kötü varsayımlar yaptığımı görüyorum. Ama evet, bir bileşen sistemiyle onu yalnızca tek bir yerde düzeltmeniz gerekir.

Drew: Bir bileşen tamamen kapsayıcı olabilir mi yoksa kapsayıcılık için her zamankinden daha fazla çalıştığınız bir spektrum mu?

Heydon: Evet, bir bileşenin, diyelim ki WCAC hatasız olması, tüm WCAC kriterlerini karşılaması mümkün olabilir, ancak dediğim gibi, bu sizi yalnızca bir yere kadar götürür ve yine de tamamen kullanılamaz olabilir veya Bu teknik kriterler karşılansa bile anlamak imkansız. Yani evet, bu çok konuştuğum bir şey. İnsanları, erişilebilirliğin tasarımın diğer herhangi bir alanı gibi olduğuna, bunun tasarım sürecinin bir parçası olduğuna ve hiçbir şeyin mükemmel şekilde erişilemeyeceği gibi hiçbir şeyin mükemmel şekilde tasarlanamayacağına ikna etmeye çalışıyorum. Ne yazık ki, pek çok insan bunu sadece ekran okuyucularla uyumlu olduğundan emin olmak için düşünüyor, ki bu açıkça erişilebilirlik ve genel olarak dahil etme açısından çok dar bir kapsam.

Heydon: Öyleyse, Paciello Group'ta birlikte çalıştığım bazı iyi insanlar, "Aslında, erişilebilir bir UX kişisi olarak bilinmek istiyorum" diyecek insanlar olacak. Yani bu sadece bu kutuyu işaretleme alıştırmasıyla ilgili değil, aslında deneyimi daha fazla sayıda insan için daha iyi ve daha değerli hale getirmeye çalışmak ve daha geniş ilkelere ve daha az ikili olan şeylere doğru daha fazla ilerlemekle ilgili. Ama sonuçta, hepsi bu kadar ve WCAC ve diğer bu tür kriterler sadece gerçekten zor ve hızlı olan "Bu yanlış" şeylerini gerçekten tanımlayabilir, sanırım.

Drew: Öyleyse bir geliştiriciysem, bir bileşeni nasıl tasarladığım, planladığım ve oluşturduğuma yaklaşırken neyi farklı yapmalıyım? Bu bileşenin mümkün olduğunca kapsayıcı olmasını sağlamak için çalışmamda dikkate almam gereken herhangi bir şey var mı?

Heydon: Yani, ne inşa ettiğinize bağlı olarak, karşılanması gereken farklı kriterler olacak. Bu nedenle, örneğin, her bileşen, alternatif metin içeren erişilebilir görüntülere sahip olmayacak çünkü görüntüleri hiç kullanmayabilir. Sadece metin tabanlı olabilir veya sizde ne var. Bazıları etkileşimli olmayabilir. Dolayısıyla, özel gereksinimler açısından, bileşen arasında değişecektir, ancak umarım bazı yazılarım ve Kapsayıcı Bileşenler kitabının yapmanıza yardımcı olduğu şey, yalnızca kapsayıcı düşünme disiplinine girmek veya bir tür benimsemektir.

Heydon: Yani, bu konuya yaklaşırken, sadece düşünmekle kalmayıp, temelde sadece "Benim için işe yararsa, muhtemelen herkes için de işe yarar" zihniyetinden çıkmakla kalmaz, çünkü durum böyle değildir. sen veya ben bir şeylere göz atma şeklimiz, yani, muhtemelen işleri tamamen farklı yapacağız, sadece ikimiz, değil mi?

Duru: Doğru.

Heydon: Ve biz Batılı, beyaz ve İngilizce'yi birinci dil olarak konuşan insanlarız. Ve böylece, evet, bunu tüketen insanlar açısından çeşitlilik miktarı, yani performans insanları her zaman bundan bahsediyor, daha iyi performansı savunmakla ilgilenen insanlar. İyi bir ağda yüksek özellikli bir kurulum kullanmaya alışkınsınız ve birçok kullanıcınız veya potansiyel kullanıcılarınızın çoğu kesinlikle olmayacak ve erişilebilirlik ile aynı. Bu sadece bir soru, temelde, sadece kendini düşünmekten gerçekten kurtulmak. Kelimenin tam anlamıyla bu. Ve açıkçası, sadece yakın meslektaşlarınızın ve aynı sosyal grubunuzdaki insanların ötesine ulaşmaya çalışmak.

Heydon: Umarım, gerçekten sadece "İşte bu şey için çözdüğüm şey" ve o sırada düşündüğüm şey. Bu fikirlerden bazılarını yeniden kullanabilir ve sizin için yararlı veya alakalıysa, tam olarak uyguladıklarımı uygulayabilirsiniz. Umarım, kitap daha çok, “İşte kapsayıcı düşünmeye çalışan bir kişinin vaka çalışması. Bakın, onların ne tür şeyler düşündüklerini, tamamen farklı bir şey tasarlarken, belki de sadece aynı tür düşünmeyi kullanın ve zihninizi kullanıcıların çeşitliliğine ve nasıl gittiklerine açmaya çalışın."

Drew: Yani kitabın kendisi, onu nasıl yapılandıracağınıza nasıl karar verdiniz? Bir kitapta hoşuma giden, son derece pratik görünüyor, ama onu nasıl yapılandırdınız?

Heydon: Bir önceki kitaba çok benziyor, aslında Inclusive Design Patterns'dı ve başlangıçta o kitapta çok zorlandım çünkü onu bir tür soyut kriterlere göre düzenlemeye çalıştım. Bu yüzden tamamen klavye erişilebilirliği ile ilgili bir bölüm yazmaya başladım, ancak bu çok zordu çünkü o zaman yapmak zorunda kaldım, ne zaman farklı bir klavye erişilebilirliği türünden ya da düşünmeniz gereken şeyden bahsetsem, o zaman ben bir tür bileşen oluşturmak ve sonra bu bileşeni atmak ve sonra başka bir şeye geçmek zorunda kaldı.

Heydon: Bu yüzden, şeyleri bileşenlerin kendileri açısından organize etmek benim için daha mantıklı geldi. Yani, Inclusive Design Patterns bunu yapıyor ve şimdi Inclusive Components gerçekten sadece farklı bileşenleri kapsayan bir devam niteliğinde. Bu, özellikler açısından biraz farklı, çünkü önceki kitaplarda pek yapmadığım canlı kod örnekleri ve şeyler de içeriyor. Ama evet, kelimenin tam anlamıyla, "Bu bileşeni yapacağız", bir dokunma arayüzü veya daraltılabilir bir bölüm veya bir tema değiştirici veya bir bildirim flash kartı veya ekmek kızartma makinesi veya her ne denirse, ve sonra her şey daha sonra bu bileşen etrafında düzenlenir.

Heydon: Yani, “Yaptığımız şey bu ve daha kapsayıcı olmak için bunu yaparken göz önünde bulundurmamız gereken şeyler” çünkü ben böyle çalışıyorum ve diğer insanlar da böyle çalışıyor. Ve böyle yapmaya başlar başlamaz, gerçekten sadece ben çalışıyordum ve çalıştığım gibi notlar yazıyordum. Ve böylece, şey kendi kendine yazdı ve sonra tüm çaba gerçekten de aslında sadece bu şeyleri erişilemez hale getirmek için iyi bir iş çıkardığımdan emin olmaktı, sanırım.

Drew: Evet, demek istediğim, içindekiler gerçekten neredeyse dokümantasyon veya kendi kendine yardım kılavuzu gibi bir şey okuyor. Doğrudan birinci bölüm, geçiş düğmeleriyle. Bazı geçiş düğmeleri uygulamak istiyorsanız, bu bölüme gidin, okuyun ve bunun nasıl yapılacağı hakkında bilmeniz gereken her şeyi alacaksınız, bu gerçekten sevdiğim bir yaklaşım. Daraltılabilir bölümler, sekmeli arayüz, tema anahtarları, veri tabloları, her gün inşa ettiğimiz bir sürü gerçek, gerçek pratik şeyler gibi şeyler görüyorum ve sanırım hepimiz, muhtemelen, daha iyi inşa ediyor olabiliriz.

Heydon: Evet, tamamen fikir buydu çünkü bu sadece bileşenlerimi yapmakla ilgili değildi, bu bir vakaydı ve orada buna değindiniz, ki yaptığınıza sevindim, ki bu ortak noktaları belirlemekti. hepimizin kullandığı kalıplar. Demek istediğim, her yerde sekme arayüzleri var ve hepsi farklı şekilde uygulanıyor ve hepsi çeşitli, çok kötü şekilde uygulanıyor. Demek istediğim, korkunç sekme arayüzleri uyguladım ve insanlar için ne kadar kötü olduklarını biraz öğrendim ve sonra onları biraz daha iyi, biraz daha iyi ve biraz daha iyi yapmaya çalıştım. Yıllardır bu tür şeyler yaptığım için muhtemelen benim zamanımda 15 veya 16 farklı sekme arabirimi sürümü yaptım.

Heydon: Ve biliyorsun, umarım her seferinde biraz daha iyiye gidiyorlar. Ama bu sadece yaygın bir şey. Farklı web siteleri arasında oldukça sık kullandığım, kullandığım ve herkesin kullandığı yaygın bir şeydi. Yani fikrin bir kısmı, "Aslında, hadi bir tasarım sistemi yapalım, web için bir tür erişilebilir tasarım sistemi yapalım" demekti. Şimdi, insanlar dallara ayrılacaklar ve bu şeylerin kendi versiyonlarını yapacaklar, ama bir nevi temel şeyleri aşağı çekmek ve erişilebilirlik şeylerde olması gereken temel bir şey. Eklenti olmamalı, ya/veya olmamalı, özellik olmamalı. Temel bir şey olmalı. Ve eğer bu temel şeyleri eşleştirirseniz, o zaman evet, umarım insanlar bölümlere bakar ve "Ah, tamam, onları yaptım. Ben bunları gördüm. Bunu mümkün olduğunca kapsayıcı bir şekilde nasıl yapacağımızı görelim” ve umarım bundan bir miktar değer alırlar.

Drew: Bu konuda hoşuma giden şey, kesinlikle biliyorum ki geçmişte uygulamam gereken bazı arayüz özelliklerim oldu ve erişilebilirlik açısından bunun zor olacağını biliyorum. , bir tür açılır menü, açılır menü, bunun gibi bir şey söyleyin. Bence, “Tamam, erişilebilirlik açısından burada ejderhalar var. Bunu doğru yaptığımdan emin olmalıyım.” O yüzden Google'da nasıl yapıldığını araştırıyorum, "Bu yöntemi kullanın" diyen saygın bir kaynak buluyorum, bu yöntemi kullanıyorum, uyguluyorum ve devam ediyorum ama aslında hiçbir şey öğrenemedim. Çözümün neden böyle olduğunu öğrenemedim. Ve kitapta konuya girme şeklin hakkında gerçekten sevdiğim şey, aynı anda iki şeyi yapabiliyor olmam. Bunu nasıl yapmam gerektiğini çözebilirim ve neden böyle yapmam gerektiğini anlayabilirim çünkü hepsi çok dikkatli bir şekilde açıklanmıştır. Dolayısıyla bu açıdan gerçekten başarılı olduğunu düşünüyorum.

Heydon: Oh, harika. Ben de bunun için gidiyordum. Bu iyi. But yeah, that seems to be my thing. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Evet.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.