Smashing Podcast Episode 4 Dengan Heydon Pickering: Apa Itu Komponen Inklusif?

Hari ini, saya berbicara dengan Heydon Pickering tentang buku barunya, Komponen Inklusif . Heydon dikenal karena karya dan tulisannya tentang aksesibilitas — jadi apa sebenarnya arti "Desain Inklusif" dan di mana komponen berperan? Heydon menjelaskan semua ini dan lebih banyak lagi di episode ini. Anda dapat mendengarkan di bawah ini, atau berlangganan di mana pun Anda mendapatkan podcast.

Tampilkan Catatan

• Buku Komponen Inklusif dari Smashing Magazine
• Proyek Heydon Every Layout dengan Andy Bell
• Situs web Heydon Heydonworks
• Haidon di Twitter

Salinan

Drew McLellan: Dia adalah konsultan aksesibilitas web lepas, perancang antarmuka, dan penulis. Karyanya berfokus pada desain pengalaman pengguna yang dapat diakses, serta menulis dan mengedit untuk Majalah Smashing. Dia penulis buku terkenal tentang desain aplikasi web yang dapat diakses, Apps For All, dan baru saja merilis buku baru, Komponen Inklusif, semua tentang bagaimana membangun antarmuka web yang dapat diakses, sekali lagi, dengan Smashing Magazine. Jadi dia jelas ahli dalam bidang desain yang dapat diakses, tetapi tahukah Anda bahwa dia adalah manusia laki-laki pertama yang melompati Sydney Harbour Bridge dengan speedboat? Teman-teman Smashing saya, tolong sambut Heydon Pickering. Hai, Heidon. Apa kabar?

Heydon Pickering: Saya hebat. saya di merek.

Drew: Saya ingin berbicara dengan Anda hari ini tentang topik buku baru Anda, Komponen Inklusif.

Heidon: Ya.

Drew: Jelas hanya judul dua kata, tapi saya merasa masing-masing kata itu sangat berat. Mulai dari akhir, seperti yang jelas logis untuk dilakukan, komponen, apakah ini tentang semacam desain berbasis komponen? Apa itu?

Heydon: Ya, jadi saya rasa sudah lama sejak orang-orang, pengembang front-end, desainer, dan semua orang yang berkolaborasi dalam membuat antarmuka, mulai memikirkan berbagai hal dalam hal komponen dan membaginya menjadi bagian yang dapat dicerna dan digunakan kembali. Dan saya kira jika Anda tidak terbiasa dengan cara kerja itu untuk alasan apa pun, itu benar-benar mirip dengan komponen elektronik. Ayah saya adalah seorang insinyur elektronik. Dia bekerja di dunia analog papan sirkuit dan solder dan semua hal semacam itu.

Heydon: Sebenarnya, dia membuat beberapa komponen, komponen yang sangat kecil, yang digunakan untuk mengatur arus yang masuk ke elektromagnet di CERN. Dan dia sangat percaya pada saya sebagai seorang anak, karena dia membuat saya benar-benar menyolder beberapa bagian untuk mereka. Saya pikir batch itu sekarang telah pensiun, jadi jangan khawatir tentang penyolderan saya yang buruk, penyolderan remaja saya yang malang, terlibat dalam CERN lagi. Tapi ya, saya pikir analog dengan ... Oh, terlalu banyak analog di sana.

Heydon: Ini analog dengan papan sirkuit analog yang idenya adalah Anda memiliki tanggung jawab tunggal untuk masing-masing bagian atau komponen dan, bersama-sama, mereka membuat sirkuit dan, bersama-sama, mereka menambah arus dalam kasus sirkuit atau, saya kira, antarmuka atau hasil dengan cara apa pun, dalam sistem desain atau antarmuka seperti yang dimanifestasikan melalui sistem desain. Jadi, Komponen Inklusif karena saya ingin membahas fakta bahwa, sementara, maksud saya, aksesibilitas cenderung tertinggal secara umum ketika kami memajukan apa yang kami lakukan di arena yang berbeda, dan saya ingin menghadirkan aksesibilitas dan, dalam pengertian yang lebih luas. masuk akal, desain inklusif untuk menanggung cara berpikir baru semacam ini dan membuat sesuatu menggunakan komponen atau modul atau apa pun yang Anda ingin menyebutnya.

Heydon: Jadi idenya adalah untuk membawa aksesibilitas ke sistem desain, tetapi dengan cara yang sama, berpikir secara sistematis ketika mencoba untuk mengatasi aksesibilitas. Pikirkan tentang memecahkan jenis satu masalah di satu tempat dalam hal aksesibilitas dan memastikan bahwa hanya menyebar di sekitar pola [tidak terdengar 00:03:16] sistem desain pada umumnya.

Drew: Secara praktis, seperti apa sebenarnya bekerja dengan cara berbasis komponen? Apa yang mungkin menjadi contoh komponen?

Heydon: Jadi, ada cara berbeda untuk memahami dan mengkodekan komponen. Saya cenderung langsung ke seluk beluknya, melewati hal-hal konseptual dan berpikir tentang bagaimana saya bisa mengatur kode. Saya benar-benar datang untuk banyak fokus pada elemen khusus, atau jika bukan elemen khusus, maka elemen normal tetapi dengan jenis perilaku JavaScript yang melekat padanya dalam semacam cara yang terisolasi dan komponen. Saya sangat menyukai gagasan komponen yang dapat dioperasikan. Dan maksud saya, mereka dapat digunakan di berbagai kerangka kerja dan sistem dan pendekatan dan tumpukan teknis. Dan elemen khusus bagus dalam hal itu karena mereka asli. Anda dapat mendefinisikannya di satu tempat dan kemudian dapat digunakan, katakanlah, dalam aplikasi reaksi atau dapat digunakan dalam aplikasi tampilan atau dapat digunakan dalam aplikasi sudut, atau jenis teknologi manajemen keadaan yang lebih besar apa pun yang Anda gunakan. menggunakan.

Heydon: Jadi bagi saya, biasanya sebuah komponen mungkin akan menjadi elemen kustom. Saya telah mengerjakan proyek baru-baru ini yang tidak terlalu fokus pada aksesibilitas, meskipun saya telah mencoba membuatnya semudah mungkin, yang disebut Every Layout, dan ini semua tentang mencoba mengisolasi jenis algoritme yang sangat spesifik untuk tata letak CSS. Dan mereka didefinisikan sebagai elemen khusus dan semacam itu menyebarkan diri mereka sendiri dan menjalankan CSS mereka sendiri dan bekerja seperti primitif dalam sistem yang lebih besar.

Drew: Maksud saya, dalam istilah praktis yang sebenarnya, kita berbicara bahwa komponen mungkin sesuatu seperti bidang formulir?

Heydon: Ya, jadi itu bisa menjadi sesuatu yang sederhana sebagai masukan. Katakanlah, seperti input teks atau bisa juga sesuatu yang kompleks seperti antarmuka tab. Jadi, ide dengan Komponen Inklusif adalah untuk mengambil konsep satu komponen dengan, semoga, satu tujuan, seperti input teks, dan kemudian memikirkan semua hal berbeda yang dapat menjebak berbagai jenis orang dan mencoba dan menghindari mereka. Bukan menghindari orang, menghindari masalah. Ini bukan tentang memasukkan orang, ini tentang mencoba untuk tidak mengecualikan orang secara sewenang-wenang.

Heydon: Itu tampaknya cara termudah untuk mendekati proses desain inklusif bagi saya, adalah dengan mengidentifikasi elemen eksklusivitas potensial dari sesuatu dan mencoba dan melangkah di sekitarnya. Jadi dengan input teks, dengan label, Anda memiliki sejumlah hal berbeda yang mungkin ingin Anda khawatirkan. Jadi, Anda akan memiliki apakah itu benar-benar diberi label dengan benar untuk memulai. Jadi, apakah Anda menggunakan elemen label dan apakah elemen label itu menunjuk ke bidang teks menggunakan atribut for sehingga kedua hal tersebut terkait secara terprogram sehingga ketika pengguna pembaca layar memfokuskan input, mereka benar-benar mendengar label diumumkan? Jadi itu satu hal yang harus dilakukan dengan benar.

Heydon: Kemudian, pada tingkat visual yang lebih, memastikan bahwa label secara jelas terkait dengan bidang itu dan bukan bidang yang berbeda, dan itu soal ruang putih dan hal-hal semacam itu. Juga, memastikan bahwa labelnya tidak, Anda tidak melakukan sesuatu yang mewah seperti meletakkan label di bawah input formulir mereka karena ketika Anda, misalnya, ketika keyboard virtual muncul, itu mungkin menjadi tidak jelas. Jadi, itu mempertimbangkan hal-hal semacam itu.

Heydon: Memastikan bahwa input itu sendiri memiliki gaya fokus, jadi ketika Anda memfokuskannya dengan keyboard, apakah Anda pengguna keyboard biasa yang menggunakan keyboard untuk menavigasi atau sebaliknya, pastikan jelas dari gaya fokus bahwa itulah masukan yang Anda fokuskan. Memastikan bahwa, maksud saya, hal-hal seperti pelengkapan otomatis, mengkhawatirkan tentang itu, apakah pelengkapan otomatis sesuai dan membantu dalam konteks atau tidak. Dan banyak dari hal-hal ini menangani kecacatan secara langsung, tetapi banyak dari mereka yang lebih luas dalam hal kegunaan dan hanya membuat segala sesuatunya dapat dimengerti.

Heydon: Cukup sering, ada semacam garis tipis atau mungkin garis kabur antara apa yang membahas kegunaan untuk semua orang dan apa yang menangani kecacatan. Dan kemudian, untuk membuatnya lebih sulit untuk dijabarkan, cacat kognitif. Jadi, jika sesuatu tidak terlalu berguna untuk seseorang yang tidak memiliki cacat kognitif, maka itu akan menjadi lebih sulit untuk dikerjakan dan dapat digunakan untuk seseorang yang memiliki tantangan semacam itu.

Heydon: Jadi ini hanya mencoba memikirkan semua hal itu di satu tempat. Dan sungguh, buku ini hanya milik saya, ini adalah proses pemikiran saya saat saya mendekati masing-masingnya. Jadi saya melakukannya sebagai blog untuk memulai. Dan setiap pola atau setiap komponen adalah posting blog dan teksnya hanya saya, “Jadi, sekarang mari kita atasi masalah potensial ini. Bagaimana kita melakukannya? Oke, kami sudah memeriksa yang itu. Saya pikir kami baik-baik saja di sana.” Dan, tidak berarti saya mencoba untuk mengatakan bahwa ini sempurna dan bahwa saya telah memikirkan segalanya, karena itu tidak mungkin.

Drew: Begitu juga dengan pendekatan berbasis komponen tentang cara Anda bekerja pada bagian individual dari sebuah antarmuka, saya kira, ini memungkinkan Anda untuk benar-benar mendalami item tertentu dan memastikan bahwa Anda benar-benar mengoptimalkannya dengan cara terbaik yang Anda lakukan. dapat sehingga dapat diakses oleh semua orang. Apakah ada bahaya dalam melakukan itu dan melakukan itu pada banyak komponen yang berbeda dan kemudian menyatukan semuanya pada satu halaman? Apakah ada bahaya bahwa Anda dapat membuat masalah yang tidak Anda sadari karena Anda mengujinya secara individu dan tidak bersama-sama?

Heydon: Itu poin yang sangat bagus, dan sebenarnya saya akan membahasnya lebih awal. Saya senang Anda mengatakan itu. Jadi, dalam banyak hal, saya pikir kita, secara filosofis, telah memutuskan bahwa kita perlu memisahkan hal-hal ke dalam komponen-komponen individual ini. Dan ada baiknya melakukan itu, karena jika terisolasi maka lebih mudah untuk menguji dan memperlakukan sebagai satu hal. Dan Anda dapat, dalam hal cara kami bekerja, itu membuat segalanya lebih mudah untuk dikelola. Kita juga harus mempertimbangkan fakta bahwa hal-hal ini pada akhirnya harus berbagi ruang yang sama dan bergabung bersama ke dalam sistem yang lebih besar.

Heydon: Dan menurut saya, sebenarnya, upaya dan pemikiran kita tidak cukup untuk itu, cukup lucu. Saya pikir kami membuat komponen lebih banyak untuk membuat hidup kami sebagai insinyur lebih mudah, sehingga kami tahu apa yang sedang kami kerjakan pada jam berapa. Dan, tetapi kemudian, kita sering mengabaikan fakta bahwa hal-hal ini akan hidup dalam sistem yang dinamis dan mereka harus …

Heydon: Maksud saya, proyek Every Layout, meskipun lebih tentang desain visual dan tentang tata letak, adalah tentang mencoba membuat primitif CSS kecil ini, tata letak primitif kecil ini, sedemikian rupa sehingga mereka dapat mengatur sendiri secara algoritme. Ini agar Anda dapat mengeluarkannya dari kolom sempit dan meletakkannya kemudian kolom lebar dan kemudian menjadi, kode itu sendiri akan menentukan berapa banyak item yang harus ada atau apakah itu harus mengkonfigurasi ulang dirinya sendiri dengan cara lain. Karena kita tidak bisa terus-menerus ikut campur, dan itu harus menjadi sistem yang tahu diri dan cerdas, saya pikir.

Heydon: Selalu ada hal yang bisa kamu lupakan. Jadi mungkin Anda membuat antarmuka tab, Anda punya deretan tab, Anda memilih antara tab dan tab yang sesuai dengan panel tab, yang membuka sesuatu. Dan kemudian, seseorang akan datang dan mereka akan berkata, "Bagaimana jika saya ingin menempatkan antarmuka tab di dalam antarmuka tab, atau komponen lain di dalam antarmuka tap?"

Heydon: Dan tentu saja, maksud saya, ini sebagian merupakan masalah teknis apakah itu mungkin, tapi ya, Anda harus membuat pilihan tentang apakah Anda akan membuat segala sesuatunya sefleksibel mungkin sehingga mungkin untuk menyortir hal-hal dengan cara yang kompleks, atau hanya menulis aturan keras yang mengatakan, “Anda tidak dapat memasukkan sesuatu ke dalam sini karena tingkat kerumitan dalam hal kode mungkin akan terlalu tinggi, tetapi juga mungkin dalam hal bagaimana pengguna dapat melihat dan menggunakan benda itu.” Saya setuju untuk menulis aturan yang mengatakan, "Jangan menumpuk banyak fungsi kompleks di dalam dirinya sendiri," karena kemungkinan besar orang tidak akan bisa memahaminya, sungguh.

Drew: Apakah mungkin untuk mengambil pendekatan yang sepenuhnya algoritmik atau otomatis untuk mendesain aksesibilitas?

Heydon: Saya tidak percaya begitu. Tidak. Jadi kami memiliki alat otomatis dan saya tidak ingin meremehkan alat otomatis dengan cara apa pun. Saya pikir mereka sangat berguna, tetapi saya menggunakannya sebagai semacam sistem peringatan dini untuk mencoba dan mendapatkan kesan di mana area masalah berada. Jadi, jika saya melakukan audit untuk organisasi yang menginginkan saran tentang cara membuat produk mereka lebih mudah diakses. Jadi ini adalah cara yang baik dari jenis pendanaan di mana area masalah berada, tapi maksud saya, Anda dapat memiliki antarmuka yang secara teknis dapat diakses 100%, mungkin, menurut beberapa alat, bahkan alat yang bagus untuk menilainya, katakanlah, melawan WCAG , pedoman aksesibilitas konten web, atau spesifikasi penerimaan lainnya. Dan, meskipun ini adalah semacam 100% dari semua kotak yang dicentang, itu masih dapat sepenuhnya tidak dapat digunakan karena berbagai alasan.

Heydon: Misalnya, kembali ke apa yang kami katakan sebelumnya, itu bisa jadi terlalu rumit. Anda bisa membanjiri seseorang dengan tautan dan tidak mungkin mereka bisa melewatinya dan kemudian itu menjadi, itu adalah hal yang sangat diam-diam dan sulit untuk dijabarkan, tetapi itu pasti hanya mengasingkan orang. Tapi ada juga, Anda bisa mendapatkan, sangat mudah untuk mendapatkan positif palsu dan hal-hal seperti itu. Saya punya sesuatu tempo hari, saya katakan tempo hari, itu bulan lain, saya bekerja untuk sebuah organisasi dan tentu saja mereka ingin memiliki sekolah mercusuar aksesibilitas 100% dan ada iframe yang dijatuhkan di sana secara dinamis oleh skrip analitik atau sesuatu. Anda tahu jenis hal di mana itu semacam kode yang agak kotor, yang hanya dibuang di halaman untuk melakukan beberapa tugas seperti itu.

Heydon: Sekarang saya akan merekomendasikan untuk tidak menggunakan analitik sama sekali, dan saya merekomendasikan kepada mereka untuk setidaknya mendukung protokol jangan lacak sehingga orang dapat memilih keluar. Sayangnya, protokol semacam itu, tidak benar-benar berfungsi lagi karena tidak pernah benar-benar didukung dengan benar. Tapi iframe ini, dikatakan tidak memiliki judul di atasnya. Jadi idenya adalah jika Anda memiliki iframe, itu harus memiliki atribut judul karena itulah cara terbaik untuk mengidentifikasi iframe bagi pengguna pembaca layar. Tapi ini adalah iframe yang juga disetel untuk tidak menampilkan apa pun, sehingga bahkan tidak terlihat oleh pembaca layar sejak awal karena tidak menampilkan apa pun, sama seperti menyembunyikan sesuatu secara visual di pembaca layar, pada dasarnya akan menghapusnya dari antarmuka, sehingga tidak akan ditemui atau diumumkan dengan cara apapun.

Heydon: Jadi itu positif palsu. Maksud saya, itu meminta saya untuk mengidentifikasi iframe yang tidak ada untuk dirasakan sejak awal. Jadi, akan selalu ada kesalahan dan masalah seperti itu dalam pengujian otomatis. Tapi pada akhirnya, ini tentang mengetahui, meskipun itu hanya semacam hal yang programmer, saya kira, tidak terlalu suka berpikir bahwa mereka terlibat dan mereka merasa agak menjijikkan, tetapi ini tentang perilaku manusia dan tentang bagaimana orang memahami sesuatu dan itu adalah hal yang sangat sulit untuk hanya memiliki seperangkat aturan biner, atau aturan boolean.

Heydon: Jadi, maksud saya, saya berbicara dengan pengembang ketika saya berkonsultasi beberapa waktu lalu tentang hal ini dan mereka terus berkata, “Yah, selama kami memiliki pengujian otomatis, kami baik-baik saja, bukan? Hanya saja, baru kita bisa maju.” Dan saya berkata, “Anda masih harus menguji secara manual. Tidak ada tes otomatis yang benar-benar dapat memberi tahu Anda jika menggunakan antarmuka dengan keyboard tidak mungkin dalam satu atau lain cara.” Ada beberapa hal terpisah yang dapat Anda cari, tetapi pengalaman keseluruhan masih merupakan sesuatu yang perlu dinilai oleh manusia. Ya.

Drew: Terkadang bahaya dengan alat otomatis adalah mereka melihat item secara terpisah atau mereka melihat satu antarmuka secara terpisah dan tidak melihat konteks yang lebih luas.

Heidon: Ya.

Drew: Tentu saja dengan menggunakan mercusuar untuk audit kinerja, kadang-kadang saya mungkin membuat keputusan sebagai pengembang untuk menyertakan, mungkin ada lebih banyak CSS daripada yang digunakan pada satu halaman itu dan sebenarnya, saya mengunduh terlalu banyak CSS, tetapi sebenarnya , Saya tahu bahwa setelah file tersebut dimuat, pada saat pengguna menelusuri halaman berikutnya, mereka sudah mendapatkan CSS. Jadi ini adalah pengoptimalan yang dilakukan di beberapa halaman, alat ini, melihat satu halaman secara terpisah, dianggap sebagai kesalahan.

Heydon: Ya, tentu saja. Anda berpikir ke depan dan membuat keputusan penilaian, dan sampai kita mencapai AI tingkat lanjut untuk mengantisipasi hal itu, maka ya, Anda benar-benar membutuhkan manusia untuk melihatnya dan melewatinya dan melakukannya ... Maksud saya, jadi pengujian otomatis harus berada di tempat, seperti yang saya katakan, semacam sistem peringatan dini, sistem diagnostik, tetapi juga harus ada, jika Anda tertarik pada organisasi Anda benar-benar peduli dan membuat segalanya lebih inklusif dan lebih mudah diakses, perlu ada pelatihan juga . Harus ada Q&A.

Heydon: Jadi saya akan menulis skrip untuk, "Beginilah cara kerjanya ketika Anda berinteraksi dengan komponen ini dengan keyboard," atau, "Beginilah cara kerjanya ketika Anda berinteraksi dengannya dengan pembaca layar dan tidak benar-benar melangkah. dia. Jadi, ketika Anda melakukan ini, ini harus terjadi. Ketika Anda melakukan ini, ini harus terjadi. Ketika Anda melakukan ini, ini akan muncul, "atau hal semacam itu. Jadi, dan jenis barang perjalanan, seperti yang Anda katakan, alat otomatis tidak menyadarinya. Mereka hanya melihat, "Oh, ini tidak memiliki teks alternatif di sini." Dan sebenarnya, dalam banyak kasus, mungkin seharusnya tidak ada teks alternatif. Dan juga, itu tidak dapat menilai apakah Anda telah menulis teks alternatif dengan baik atau tidak. Jadi saya pikir gambar tanpa semua teks alternatif mungkin lebih baik daripada gambar dengan teks alternatif yang menyesatkan atau hanya buruk. Dan itu panggilan penghakiman lagi, bukan?

Drew: Salah satu hal yang saya perjuangkan, secara historis, dalam membangun sesuatu dengan cara yang dapat diakses adalah menjaga pengetahuan saya tentang praktik terbaik tetap mutakhir karena, setiap kali saya merujuk ke dokumentasi atau rekomendasi apa pun, itu sepertinya apa yang saya lakukan dan berpikir saya melakukan hal yang benar, rekomendasi telah pindah dan sekarang saya harus melakukan sesuatu yang lain. Dan itu adalah kisah yang akrab dengan semua bidang pekerjaan di web. Tapi saya pikir bahayanya, tentu saja, dengan masalah aksesibilitas, adalah, jika Anda tidak mengikuti praktik terbaik, jika Anda meninggalkan sesuatu di antarmuka Anda yang sekarang bukan praktik yang baik, itu dapat memengaruhi pengguna Anda secara negatif. cara. Apakah pendekatan berbasis komponen untuk membangun antarmuka atau situs, apakah itu membantu dengan cara apa pun?

Heydon: Saya pikir murni dalam arti bahwa, karena Anda memiliki satu komponen yang kemudian, idenya tentu saja dalam semua kasus dan bukan hanya dalam hal aksesibilitas, adalah Anda menetapkan komponen ini di satu tempat yang kemudian akan digunakan di tempat yang berbeda. tempat, setidaknya ketika aspek atau dukungan browser atau apa pun itu berubah dan Anda ingin memperbarui komponen, Anda hanya perlu melakukannya di satu tempat dan kemudian di mana pun itu digunakan, peningkatan atau perubahan itu akan terasa. Jadi dari hal itu, saya pikir tentu lebih berguna untuk membagi sesuatu menjadi komponen-komponen.

Heydon: Tapi, ya, seperti yang saya katakan, itu tidak hanya memengaruhi aksesibilitas, itu bisa memengaruhi apa pun yang berubah. Tapi kemudian, saya tidak yakin benar-benar berapa banyak perubahan di dalamnya ... Maksud saya, akan ada beberapa jenis perubahan yang melanggar dalam hal aksesibilitas HTML, yang jelas merupakan area yang sangat sempit. Tetapi dalam hal kualitas kode atau cara kerja kode, hal-hal yang dimasukkan ke dalam spesifikasi HTML, jelas, sangat lambat dan tidak terlalu lambat tetapi juga cukup lambat ke dalam spesifikasi ARIA. Dan kemudian, sebagian besar ARIA hanya mencerminkan apa yang ada di dasar HTML dasar.

Heydon: Saya pikir, lebih dari teknologi, persepsi dan pemahaman tentang hal-hal ini cenderung berubah dari waktu ke waktu. Maksud saya, baru-baru ini, dalam survei WebAIM baru-baru ini, mereka mengidentifikasi situs yang menggunakan ARIA lebih tidak dapat diakses daripada situs yang tidak menggunakannya. Jadi teknologi ini dirancang khusus untuk membantu orang membuat situs web lebih mudah diakses, malah memperburuk keadaan. Jadi sebenarnya, itu hanya kesenjangan pengetahuan, bukan kesenjangan teknologi atau kekurangan teknologi. Sayangnya, orang-orang hanya mengambil teknologinya dan menyalahgunakannya karena mereka tidak benar-benar memahami cara kerjanya. Mudah-mudahan, beberapa tulisan saya mungkin bisa membantu dengan itu. Di beberapa daerah, kok.

Drew: Tetapi semacam sistem berbasis komponen yang terstruktur dengan baik akan memungkinkan Anda, setelah Anda menyadari bahwa ada sesuatu yang ketinggalan zaman atau Anda telah membuat keputusan yang buruk dan sekarang Anda tahu lebih baik, akan memungkinkan Anda untuk lebih mudah masuk dan memperbaikinya di seluruh aplikasi Anda.

Heidon: Ya, persis. Ya, ya, tentu saja. Maksudku, ini semua tentang efisiensi bukan? Dan prinsip kering ini atau apa yang Anda miliki, dan lihat, itulah mengapa saya kira saya awalnya sangat senang dengan kesempatan ini, karena orang selalu mengeluh bahwa membuat sesuatu dapat diakses adalah pekerjaan ekstra dan sulit dan menjengkelkan dan sebagainya. Jadi, ini semacam kesempatan untuk mengatakan, “Nah, tahukah Anda bagaimana Anda benar-benar membuat hal ini, membangun sistem komponen ini secara efisien? Dapatkan aksesibilitas Anda di sana untuk satu komponen yang Anda buat, dan kemudian Anda tidak perlu khawatir tentang aksesibilitas lagi selain dari perubahan atau pembaruan spesifikasi sesekali atau apa pun yang Anda miliki.

Heydon: Atau, maksud saya, mungkin sebagian besar waktu, iterasi hanya akan didasarkan pada umpan balik pengguna dan penelitian berkelanjutan, yang, jelas, Anda harus, sebanyak mungkin, lakukan dengan kelompok orang yang beragam. Jadi, Anda harus mendapatkan orang-orang yang menggunakan perangkat yang berbeda dan memiliki kebiasaan menjelajah yang berbeda dan menggunakan teknologi bantu yang berbeda dan hal semacam itu. Dan Anda tahu, hal-hal pasti akan muncul setiap saat. Saya pikir saya telah benar-benar menentukan sebuah komponen, berpikir itu benar-benar kuat, dan kemudian saya melakukan sedikit riset dan saya menemukan bahwa saya telah membuat beberapa asumsi yang sangat buruk. Tapi ya, dengan sistem komponen Anda hanya perlu memperbaikinya di satu tempat.

Drew: Bisakah suatu komponen sepenuhnya inklusif atau apakah itu spektrum di mana Anda hanya bekerja lebih keras menuju inklusivitas?

Heydon: Ya, mungkin saja sebuah komponen, dalam hal katakanlah WCAC bebas dari kesalahan, ia memenuhi semua kriteria WCAC, tapi seperti yang saya katakan, itu hanya membawa Anda sejauh ini dan masih bisa sepenuhnya tidak dapat digunakan atau mustahil untuk dipahami bahkan dengan kriteria teknis yang terpenuhi. Jadi ya, ini adalah sesuatu yang saya bicarakan banyak. Saya mencoba meyakinkan orang bahwa aksesibilitas seperti area desain lainnya, itu hanya bagian dari proses desain dan tidak ada yang dapat dirancang dengan sempurna seperti tidak ada yang dapat diakses dengan sempurna. Saya pikir, sayangnya, banyak orang memikirkannya hanya untuk memastikan bahwa itu kompatibel dengan pembaca layar, yang jelas merupakan cakupan yang sangat sempit dalam hal aksesibilitas dan inklusi secara umum.

Heydon: Jadi, akan ada orang yang, beberapa orang baik yang pernah bekerja dengan saya seperti di Paciello Group, yang akan berkata, "Sebenarnya, saya ingin dikenal sebagai orang UX yang mudah diakses." Jadi ini bukan hanya tentang latihan mencentang kotak ini, ini lebih tentang benar-benar mencoba membuat pengalaman lebih baik dan lebih berharga bagi lebih banyak orang dan bergerak lebih ke arah semacam prinsip yang lebih luas dan hal-hal yang kurang biner. Tapi pada akhirnya, itu semua, dan WCAC dan kriteria lain seperti itu hanya dapat benar-benar mengidentifikasi hal-hal yang benar-benar keras dan cepat, "Ini salah,", saya kira.

Drew: Jadi jika saya seorang pengembang, apa yang harus saya lakukan secara berbeda ketika saya mendekati cara saya merancang dan merencanakan dan membangun sebuah komponen? Apakah ada sesuatu yang harus saya pertimbangkan dalam pekerjaan saya untuk memastikan bahwa komponen itu akan berakhir se-inklusif mungkin?

Heydon: Jadi, maksud saya, tergantung pada apa yang Anda bangun, akan ada kriteria berbeda yang harus dipenuhi. Jadi, misalnya, tidak setiap komponen akan memiliki citra yang dapat diakses dengan teks alternatif, karena mungkin tidak menggunakan citra sama sekali. Mungkin hanya berbasis teks atau apa pun yang Anda miliki. Beberapa mungkin tidak interaktif. Jadi, dalam hal persyaratan khusus, maka, itu akan berubah di antara komponen, tetapi mudah-mudahan apa yang beberapa tulisan saya dan buku Komponen Inklusif membantu Anda untuk jatuh ke dalam atau semacam mengadopsi disiplin hanya berpikir inklusif.

Heydon: Jadi, ketika Anda mendekati hal ini, tidak hanya berpikir, yah, pada dasarnya hanya keluar dari pola pikir, "Jika itu berhasil untuk saya, itu mungkin berhasil untuk orang lain," karena tidak demikian halnya dengan cara Anda atau saya menelusuri sesuatu, maksud saya, kita mungkin akan melakukan hal-hal yang sama sekali berbeda, hanya kita berdua, bukan?

Drew: Benar.

Heydon: Dan kami orang Barat, kulit putih, Inggris sebagai bahasa pertama. Jadi, ya, jumlah keragaman dalam hal orang-orang yang mengkonsumsi ini, maksud saya orang-orang kinerja selalu membicarakan hal ini juga, orang-orang yang tertarik untuk mengadvokasi kinerja yang lebih baik. Anda terbiasa menggunakan pengaturan spek tinggi di jaringan yang baik dan banyak pengguna Anda atau banyak pengguna potensial Anda pasti tidak, dan sama dengan aksesibilitas. Ini hanya pertanyaan tentang, pada dasarnya, keluar dari pemikiran tentang diri Anda sendiri, sungguh. Secara harfiah hanya itu. Dan mencoba, tentu saja, untuk menjangkau lebih dari sekadar kolega langsung Anda dan orang-orang dalam kelompok sosial Anda yang sama juga.

Heydon: Jadi mudah-mudahan, ini benar-benar hanya, "Inilah yang saya pecahkan untuk hal ini," dan apa yang saya pikirkan saat itu. Anda dapat menggunakan kembali beberapa ide tersebut dan menerapkan dengan tepat apa yang telah saya terapkan, jika itu berguna atau relevan bagi Anda. Semoga buku ini lebih tentang adil, “Ini adalah studi kasus seseorang yang mencoba untuk berpikir secara inklusif. Lihat, jenis hal yang mereka pikirkan, ketika Anda merancang sesuatu yang sama sekali berbeda, mungkin hanya menggunakan jenis pemikiran yang sama dan mencoba dan membuka pikiran Anda terhadap keragaman pengguna dan bagaimana mereka melakukan berbagai hal.”

Drew: Jadi buku itu sendiri, bagaimana Anda memutuskan bagaimana menyusunnya? Tampaknya sangat praktis, yang saya suka dalam sebuah buku, tetapi bagaimana Anda menyusunnya?

Heydon: Sangat mirip dengan buku sebelumnya, sebenarnya adalah Pola Desain Inklusif dan saya memiliki banyak masalah dengan buku itu, untuk memulai, karena saya mencoba mengaturnya dalam bentuk kriteria abstrak. Jadi saya mulai melakukan bab yang semuanya tentang aksesibilitas keyboard, tetapi itu sangat sulit karena kemudian saya harus memikirkannya, setiap kali saya berbicara tentang jenis aksesibilitas keyboard yang berbeda atau hal yang harus Anda pikirkan, maka saya harus menyulap semacam komponen dan kemudian membuang komponen itu dan kemudian pindah ke sesuatu yang lain.

Heydon: Jadi, lebih masuk akal bagi saya untuk mengatur berbagai hal dalam hal komponen itu sendiri. Jadi, Pola Desain Inklusif melakukan ini dan sekarang Komponen Inklusif benar-benar hanya kelanjutan, yang hanya mencakup komponen yang berbeda. Ini berbeda dalam hal fitur, ini sedikit berbeda karena juga menyertakan contoh kode langsung dan hal-hal lain, yang tidak banyak saya lakukan untuk buku-buku sebelumnya. Tapi ya, secara harfiah hanya, "Kami akan melakukan komponen ini," apakah itu antarmuka tap atau bagian yang dapat dilipat atau pengalih tema atau kartu flash notifikasi atau pemanggang roti atau apa pun namanya, dan kemudian semuanya kemudian diatur di sekitar komponen itu.

Heydon: Jadi, "Inilah yang kami lakukan dan ini adalah hal-hal yang harus kami pertimbangkan saat kami melakukannya agar lebih inklusif," karena begitulah cara saya bekerja dan begitulah cara orang lain bekerja. Dan segera setelah saya mulai melakukannya seperti itu, itu benar-benar hanya saya yang bekerja dan menulis catatan sambil bekerja. Jadi, hal semacam itu menulis sendiri, dan kemudian semua upaya benar-benar hanya memastikan bahwa saya melakukan pekerjaan yang layak untuk membuat hal-hal itu tidak dapat diakses, saya kira.

Drew: Ya, maksud saya daftar isi benar-benar membaca hampir seperti dokumentasi atau seperti manual self-help atau sesuatu. Langsung dengan bab satu, tombol sakelar. Jika Anda ingin menerapkan beberapa tombol sakelar, buka bab ini, bacalah dan Anda akan mendapatkan semua yang perlu Anda ketahui tentang cara melakukannya, yang merupakan pendekatan yang sangat saya sukai. Saya melihat hal-hal seperti bagian yang dapat dilipat, antarmuka tab, sakelar tema, tabel data, banyak hal praktis nyata yang kita semua bangun setiap hari dan saya pikir kita semua, mungkin, dapat membangun dengan lebih baik.

Heydon: Ya, itu benar-benar idenya karena ini bukan hanya tentang saya membuat komponen saya, itu adalah kasus, dan Anda telah menyentuhnya di sana, yang saya senang Anda lakukan, yaitu mengidentifikasi umum pola yang kita semua gunakan. Jadi maksud saya, ada antarmuka tab di mana-mana dan semuanya diimplementasikan secara berbeda dan semuanya diimplementasikan, dengan beragam, sangat buruk. Maksud saya, saya telah menerapkan antarmuka tab yang buruk dan saya telah belajar sedikit tentang betapa buruknya mereka bagi orang-orang, dan kemudian saya mencoba membuatnya sedikit lebih baik dan sedikit lebih baik dan sedikit lebih baik. Saya mungkin telah membuat 15 atau 16 versi antarmuka tab yang berbeda di waktu saya, telah melakukan hal semacam ini selama bertahun-tahun sekarang.

Heydon: Dan Anda tahu, mereka menjadi sedikit lebih baik, semoga, setiap saat. Tapi itu hanya hal biasa. Itu adalah hal umum yang akan saya gunakan cukup sering antara situs web yang berbeda, saya menggunakan dan semua orang menggunakan. Jadi, sebagian dari idenya adalah untuk mengatakan, "Sebenarnya, mari kita buat sistem desain, semacam sistem desain yang dapat diakses untuk web." Sekarang, orang-orang akan bercabang dan mereka akan membuat versi mereka sendiri dari hal-hal ini, tetapi untuk mendapatkan hal-hal inti dan aksesibilitas adalah hal inti yang harus ada dalam berbagai hal. Seharusnya tidak menjadi tambahan, tidak boleh salah satu/atau, tidak boleh menjadi fitur. Itu harus menjadi hal inti. Dan jika Anda memasangkan hal-hal inti itu, maka ya, semoga orang-orang akan melihat bab-babnya dan berkata, “Oh, oke, saya sudah membuatnya. Saya telah melihat mereka. Mari kita lihat bagaimana melakukannya se-inklusif mungkin,” dan semoga mereka mendapat nilai dari itu.

Drew: Yah, yang saya sukai adalah, tentu saja saya tahu, di masa lalu, saya memiliki beberapa fitur antarmuka yang perlu saya terapkan dan saya tahu itu akan rumit dari sudut pandang aksesibilitas. , katakanlah semacam menu terbang keluar, menu tarik-turun, sesuatu seperti itu. Saya pikir, “Oke, inilah naga dalam hal aksesibilitas. Saya perlu memastikan bahwa saya melakukan ini dengan benar.” Jadi, saya Google untuk cara melakukannya, saya menemukan sumber yang memiliki reputasi baik yang mengatakan, "Gunakan metode ini," Saya menggunakan metode itu, saya menerapkannya dan saya melanjutkan, tetapi saya sebenarnya belum belajar apa-apa. Saya belum belajar mengapa solusinya seperti itu. Dan yang sangat saya sukai dari cara Anda memasukkannya ke dalam buku ini adalah saya dapat melakukan dua hal sekaligus. Saya dapat mengetahui bagaimana saya harus melakukannya dan saya dapat mengetahui mengapa saya harus melakukannya seperti itu karena semuanya dijelaskan dengan sangat hati-hati. Jadi, saya pikir itu benar-benar sukses dari sudut pandang itu.

Heidon: Oh, bagus. Itulah tujuan saya. Jadi itu bagus. Tapi ya, sepertinya itu urusanku. 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. Ya.

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.