Bagus, Lebih Baik, Terbaik: Mengurai Dunia Kompleks Pola yang Dapat Diakses

Marc Benioff dengan penuh kenangan menyatakan bahwa satu-satunya yang konstan dalam industri teknologi adalah perubahan. Setelah bekerja di bidang teknologi selama lebih dari 15 tahun, saya dapat mengkonfirmasi ini. Rekan dinosaurus teknologi dapat membuktikan bahwa cara kerja web di masa-masa awal sangat berbeda dari yang bisa kita bayangkan.

Sementara perubahan konstan dalam industri teknologi telah menyebabkan inovasi dan kemajuan yang kita lihat sekarang, ia juga memperkenalkan konsep pilihan. Sementara pilihan - di permukaan - mungkin tampak seperti hal yang positif, itu tidak selalu sama dengan pelangi dan mawar. Masuknya perubahan teknologi juga membawa perpecahan bahasa pengkodean dan rasa "panas" pemrograman yang tidak pernah berakhir. Terkadang banyak pilihan ini berubah menjadi overchoice — gangguan kognitif yang dipelajari dengan baik di mana orang mengalami kesulitan membuat keputusan karena memiliki terlalu banyak pilihan.

Dalam artikel ini, kami akan mencoba menguraikan dunia kompleks pola yang dapat diakses — selangkah demi selangkah. Kami akan memulai dengan meninjau pola dan perpustakaan yang dapat diakses saat ini, kemudian kami akan mempertimbangkan kebutuhan pola umum dan batasan potensial kami, dan terakhir, kami akan menjalani serangkaian latihan berpikir kritis untuk mempelajari cara mengevaluasi pola aksesibilitas dengan lebih baik.

Alangkah kusutnya jaring yang kami rajut

Overchoice telah merayap ke semua aspek teknologi, termasuk pola dan perpustakaan yang kami gunakan untuk membangun kreasi digital kami — dari kotak centang sederhana hingga modal dinamis yang kompleks dan semua yang ada di antaranya. Tetapi bagaimana kita tahu pola atau perpustakaan mana yang tepat ketika ada begitu banyak pilihan? Apakah lebih baik menggunakan pola/perpustakaan mapan yang ditemui pengguna setiap hari? Atau lebih baik membuat pola baru untuk pengalaman pengguna yang lebih menyenangkan?

Dengan segudang pilihan yang tersedia, kita dapat dengan cepat menjadi lumpuh oleh terlalu banyak pilihan. Tetapi jika kita mengambil langkah mundur dan mempertimbangkan mengapa kami membangun produk digital kami di tempat pertama (yaitu pengguna akhir) tidak masuk akal untuk memilih pola atau perpustakaan yang dapat menambah nilai paling banyak untuk jumlah orang terbanyak ?

Jika Anda berpikir memilih pola atau perpustakaan adalah proses yang sudah cukup menakutkan, ini mungkin titik di mana Anda mulai khawatir. Tetapi tidak perlu khawatir — memilih pola/perpustakaan yang mudah diakses bukanlah ilmu roket. Seperti semua hal lain dalam teknologi, perjalanan ini dimulai dengan sedikit pengetahuan, banyak coba-coba, dan pemahaman bahwa tidak hanya satu pola/perpustakaan sempurna yang cocok untuk setiap pengguna, situasi, atau kerangka kerja.

Bagaimana saya tahu ini? Yah, saya telah menghabiskan lima tahun terakhir untuk meneliti, membangun, dan menguji berbagai jenis pola yang dapat diakses saat mengerjakan Panduan Gaya A11y, Pustaka Pola ARIA Deque, dan mengevaluasi pola SVG populer. Tetapi saya juga telah meninjau banyak pola dan pustaka klien di setiap kerangka kerja/platform yang bisa dibayangkan. Pada saat ini, saya dapat mengatakan tanpa keraguan bahwa ada hierarki bawaan untuk aksesibilitas pola yang mulai berkembang ketika Anda melihat cukup lama. Dan meskipun terkadang ada pola yang harus dihindari dengan cara apa pun, itu tidak selalu begitu jelas. Ketika datang ke aksesibilitas, saya berpendapat sebagian besar pola jatuh ke dalam gradien baik, lebih baik, terbaik. Bagian yang sulit adalah mengetahui pola mana yang termasuk dalam kategori apa.

Berpikir Kritis Tentang Pola

Jadi, bagaimana kita mengetahui pola mana yang baik, lebih baik, dan terbaik dalam hal aksesibilitas? Tergantung. Frasa yang sering dipanggil dari komunitas aksesibilitas digital ini bukanlah jawaban, tetapi merupakan singkatan dari “kami membutuhkan lebih banyak konteks untuk dapat memberikan jawaban terbaik kepada Anda.” Namun, konteksnya tidak selalu jelas, jadi ketika membangun dan mengevaluasi aksesibilitas suatu pola, beberapa pertanyaan mendasar yang saya ajukan meliputi:

• Apakah sudah ada pola yang dapat diakses yang dapat kita gunakan?
• Browser dan perangkat teknologi bantu (AT) apa yang kami dukung?
• Apakah ada batasan kerangka kerja atau integrasi/faktor lain yang perlu dipertimbangkan?

Tentu saja, pertanyaan spesifik Anda mungkin berbeda dari pertanyaan saya, tetapi intinya adalah Anda harus mulai menggunakan keterampilan berpikir kritis Anda saat mengevaluasi pola. Anda dapat melakukan ini dengan terlebih dahulu mengamati, menganalisis, dan kemudian memberi peringkat pada setiap pola untuk aksesibilitas sebelum Anda melompat ke keputusan akhir. Tetapi sebelum kita sampai pada itu, mari kita menyelidiki lebih dalam pertanyaan-pertanyaan awal.

Apakah Pola Aksesibel Sudah Ada?

Mengapa tampaknya dengan setiap kerangka kerja baru, kita mendapatkan serangkaian pola yang sama sekali baru? Penemuan kembali roda yang konstan dengan pilihan pola baru ini dapat membingungkan dan membuat frustrasi pengembang, terutama karena biasanya tidak perlu melakukannya.

Tidak percaya padaku? Nah, pikirkan seperti ini: Jika kita berlangganan sistem desain atom, kita memahami bahwa beberapa "atom" kecil dari kode berkumpul untuk menciptakan produk digital yang lebih besar. Namun dalam dunia ilmiah, atom bukanlah komponen terkecil dari kehidupan. Setiap atom terbuat dari banyak partikel subatomik seperti proton, neutron, dan elektron.

Logika yang sama dapat diterapkan pada pola kita. Jika kita melihat lebih dalam semua pola yang tersedia dalam berbagai kerangka kerja yang ada, struktur subatom inti pada dasarnya sama, terlepas dari bahasa pengkodean yang sebenarnya digunakan. Inilah mengapa saya menghargai perpustakaan pengkodean yang disederhanakan dengan pola yang dapat diakses yang dapat kita bangun berdasarkan kebutuhan teknologi dan desain.

Catatan : Beberapa sumber terkemuka yang bagus termasuk Komponen Inklusif, Komponen yang Dapat Diakses, dan Sistem Desain Pemerintah Inggris Raya, selain daftar pola yang dapat diakses Smashing Magazine yang baru-baru ini diterbitkan (ditambah daftar pola dan pustaka yang lebih rinci di akhir artikel) .

Peramban Dan Perangkat Teknologi Pendukung (AT) Apa yang Kami Dukung?

Setelah meneliti beberapa pola dasar yang mungkin berhasil, kita dapat beralih ke pertanyaan tentang dukungan perangkat browser dan teknologi bantu (AT). Dengan sendirinya, dukungan browser bukanlah lelucon. Ketika Anda menambahkan perangkat AT dan spesifikasi ARIA ke dalam campuran, segalanya mulai menjadi rumit ... bukan tidak mungkin, hanya lebih banyak waktu, tenaga, dan proses pemikiran yang terlibat untuk mencari tahu semuanya.

Tapi itu tidak semua berita buruk. Ada beberapa sumber daya yang luar biasa seperti Dukungan Aksesibilitas dan Aksesibilitas HTML5 yang membantu kami membangun pemahaman yang lebih baik tentang dukungan perangkat browser + AT saat ini. Situs web ini menguraikan berbagai sub-elemen pola HTML dan ARIA yang tersedia, menyertakan pengujian komunitas sumber terbuka, dan memberikan beberapa contoh pola — untuk browser desktop dan seluler/perangkat AT.

Apakah Ada Batasan Kerangka Kerja Atau Integrasi/Faktor Lain yang Perlu Dipertimbangkan?

Setelah kita memilih beberapa pola dasar yang dapat diakses dan mempertimbangkan dukungan perangkat browser/AT, kita dapat beralih ke pertanyaan kontekstual yang lebih mendetail seputar pola dan lingkungannya. Misalnya, jika kita menggunakan pola dalam sistem manajemen konten (CMS) atau memiliki pertimbangan kode lama, akan ada batasan pola tertentu. Dalam hal ini, beberapa pilihan pola dapat dengan cepat dipotong menjadi satu atau dua. Di sisi lain, beberapa kerangka kerja lebih pemaaf dan terbuka untuk menerima pola apa pun, jadi kita tidak perlu terlalu khawatir tentang batasan kerangka kerja dan lebih fokus untuk membuat pilihan pola yang paling mudah diakses yang bisa kita buat.

Selain semua yang telah kita bahas sejauh ini, ada banyak pertimbangan tambahan untuk dipertimbangkan saat memilih pola, seperti kinerja, keamanan, optimisasi mesin telusur, terjemahan bahasa, integrasi pihak ketiga, dan banyak lagi. Faktor-faktor ini pasti akan berperan dalam pilihan pola Anda yang dapat diakses, tetapi Anda juga harus memikirkan orang-orang yang membuat konten. Pola yang dapat diakses yang Anda pilih harus dibuat dengan cara yang cukup kuat untuk menangani segala potensi keterbatasan seputar konten yang dibuat oleh editor dan/atau yang dibuat pengguna.

Mengevaluasi Pola Untuk Aksesibilitas

Kode seringkali berbicara lebih keras daripada kata-kata, tetapi sebelum kita masuk ke semua itu, catatan singkat bahwa contoh pola berikut bukan satu-satunya pola yang tersedia untuk setiap situasi, juga bukan yang dianggap "terbaik" dalam grup sebagai pilihan terbaik di seluruh dunia pola yang dapat diakses.

Untuk demo pola di bawah ini, kita harus membayangkan situasi hipotetis di mana kita membandingkan setiap kelompok pola dengan dirinya sendiri. Meskipun ini bukan situasi yang realistis, menjalankan latihan berpikir kritis ini dan mengevaluasi pola aksesibilitas akan membantu Anda lebih siap saat menghadapi pilihan pola di dunia nyata.

Pola Tombol yang Dapat Diakses

Kelompok pola pertama yang akan kami tinjau untuk aksesibilitas ada di mana-mana di hampir setiap situs web atau aplikasi: tombol. Pola tombol pertama menggunakan peran tombol ARIA untuk meniru tombol, sedangkan pola tombol kedua dan ketiga menggunakan elemen <button> HTML. Pola ketiga juga menambahkan aria-describedby dan CSS untuk menyembunyikan sesuatu secara visual.

Baik: role="button"

 <a role="button" href="[link]">Sign up</a>

Lebih baik: <button>

 <button type="button">Sign up</button>

Terbaik: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Sementara pola pertama tampak sederhana pada pandangan pertama, mereka membangkitkan beberapa pertanyaan aksesibilitas. Misalnya, pada pola tombol pertama, kita melihat ARIA role="button" digunakan pada pola "baik" alih-alih elemen <button> HTML. Berpikir dalam hal aksesibilitas, karena kita tahu elemen HTML <button> diperkenalkan di HTML4, kita dapat berspekulasi bahwa itu sepenuhnya didukung oleh versi terbaru dari semua browser utama dan akan bermain baik dengan sebagian besar perangkat AT. Tetapi jika kita menggali lebih dalam dan melihat dukungan aksesibilitas untuk ARIA role=“button”, kita melihat sedikit keuntungan dari perspektif teknologi bantu, sementara elemen <button> HTML tidak memiliki beberapa area cakupan browser + AT, terutama ketika kita mempertimbangkan dukungan kontrol suara.

Lalu mengapa pola ARIA tidak termasuk dalam kategori “lebih baik”? Bukankah ARIA membuatnya lebih mudah diakses? Tidak. Faktanya, dalam kasus seperti ini, para profesional aksesibilitas sering melafalkan aturan pertama ARIA — jangan gunakan ARIA. Ini adalah cara lidah-di-pipi untuk mengatakan menggunakan elemen HTML bila memungkinkan. ARIA memang kuat, tetapi di tangan yang salah, itu bisa lebih berbahaya daripada kebaikan. Faktanya, laporan WebAIM Million menyatakan bahwa “halaman dengan ARIA menyajikan rata-rata 60% lebih banyak kesalahan daripada yang tidak.” Karena itu, Anda harus tahu apa yang Anda lakukan saat menggunakan ARIA.

Pemogokan lain terhadap penggunaan ARIA dalam situasi ini adalah bahwa fungsionalitas tombol yang kita perlukan perlu dibuat untuk pola role="button" , sementara fungsionalitas itu sudah dimasukkan sebelumnya ke dalam elemen <button> . Mengingat elemen <button> juga memiliki dukungan browser 100% dan merupakan pola yang mudah untuk diterapkan, elemen ini sedikit lebih maju dalam hierarki saat mengevaluasi dua pola pertama. Mudah-mudahan, perbandingan ini membantu mematahkan mitos bahwa menambahkan ARIA membuat pola lebih mudah diakses — seringkali yang terjadi adalah kebalikannya.

Pola tombol ketiga menunjukkan elemen <button> HTML yang digabungkan dengan aria-describedby ditautkan ke elemen ID yang disembunyikan secara visual dengan CSS. Meskipun pola ini sedikit lebih kompleks, pola ini menambahkan banyak konteks dengan menciptakan hubungan antara tombol dan tujuannya. Jika ragu, kapan pun kami dapat menambahkan lebih banyak konteks ke situasi, semakin baik, sehingga kami dapat berasumsi jika dikodekan dengan benar, itu adalah pola terbaik saat membandingkan hanya pola tombol khusus ini.

Pola Tautan Kontekstual yang Dapat Diakses

Kelompok pola kedua yang akan kita ulas adalah tautan kontekstual. Pola-pola ini membantu memberikan lebih banyak informasi kepada pengguna AT daripada yang terlihat di layar. Pola tautan pertama menggunakan CSS untuk menyembunyikan informasi kontekstual tambahan secara visual. Sementara pola tautan kedua dan ketiga menambahkan atribut ARIA ke dalam campuran: aria-labelledby dan aria-label , masing-masing.

Bagus: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Lebih baik: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Terbaik: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Sementara ketiga pola tautan kontekstual terlihat sama, ketika kami memeriksa kode atau mengujinya dengan perangkat AT, ada beberapa perbedaan yang jelas. Pola pertama menggunakan teknik CSS untuk menyembunyikan konten secara visual untuk pengguna yang dapat melihat tetapi masih membuat konten yang tersembunyi untuk pengguna AT yang tidak dapat melihat. Dan sementara teknik ini harus bekerja dalam banyak kasus, tidak ada hubungan nyata yang terbentuk antara tautan dan informasi tambahan, jadi koneksi paling baik bersifat tentatif. Dengan demikian, pola tautan pertama adalah pilihan yang baik tetapi bukan pola tautan yang paling kuat dari ketiganya.

Dua pola tautan berikutnya sedikit lebih sulit untuk dievaluasi. Menurut spesifikasi ARIA dari W3C “Tujuan aria-label sama dengan aria-labelledby . Ini memberi pengguna nama objek yang dapat dikenali. ” Jadi, secara teori, kedua atribut harus memiliki fungsi dasar yang sama.

Namun, spesifikasi juga menunjukkan bahwa agen pengguna lebih aria-labelledby daripada aria-label ketika memutuskan nama yang dapat diakses untuk disampaikan kepada pengguna. Penelitian juga menunjukkan masalah seputar terjemahan otomatis dan atribut label-aria. Jadi itu berarti kita harus menggunakan aria-labelledby , kan?

Yah, tidak begitu cepat. Spesifikasi ARIA yang sama selanjutnya mengatakan “Jika antarmuka sedemikian rupa sehingga tidak mungkin untuk memiliki label yang terlihat di layar (atau jika label yang terlihat bukan pengalaman pengguna yang diinginkan), penulis harus menggunakan aria-label dan tidak boleh gunakan aria-labelledby .” Bicara tentang membingungkan — jadi pola mana yang harus kita pilih?

Jika kami memiliki kebutuhan terjemahan skala besar, kami mungkin memutuskan untuk mengubah aspek visual dan menulis tautan dengan konteks lengkap yang ditampilkan (misalnya “ Baca lebih lanjut tentang hal yang luar biasa ini ”) atau memutuskan untuk menggunakan aria-labelledby . Namun, mari kita asumsikan kita tidak memiliki kebutuhan terjemahan skala besar atau dapat memenuhi kebutuhan tersebut dengan cara yang masuk akal/dapat diakses, dan kita tidak ingin mengubah visual — lalu apa?

Berdasarkan rekomendasi ARIA 1.1 saat ini (dengan janji terjemahan aria-label di ARIA 1.2) ditambah fakta bahwa aria-label sedikit lebih mudah untuk diterapkan oleh pengembang dibandingkan aria-labelledby , kami dapat memutuskan untuk menimbang aria-label di atas aria-labelledby dalam evaluasi pola kami. Ini adalah contoh yang jelas ketika konteks sangat membebani pilihan pola kami yang dapat diakses.

Pola <svg> dapat diakses

Terakhir, namun tentu tidak kalah pentingnya, mari kita selidiki sekelompok pola gambar SVG untuk aksesibilitas. SVG adalah representasi visual dari kode, tetapi kode tetap. Ini berarti perangkat AT mungkin melewatkan gambar SVG non-dekoratif kecuali jika role="img" ditambahkan ke pola.

Dengan asumsi pola SVG berikut bersifat informasional, role="img" telah disertakan di masing-masing. Pola SVG pertama menggunakan <title> dan <text> bersama dengan CSS untuk menyembunyikan konten secara visual dari pengguna yang dapat melihat. Dua pola SVG berikutnya melibatkan elemen <title> dan <desc> , tetapi dengan atribut aria-labelledby ditambahkan ke pola terakhir.

Bagus: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Lebih baik: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Terbaik: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Mari kita lihat pola pertama menggunakan <title> dan <text> dan CSS yang tersembunyi secara visual. Tidak seperti teks tersembunyi sebelumnya dalam pola, ada hubungan yang melekat antara elemen <title> dan <text> karena mereka dikelompokkan di bawah payung elemen SVG yang sama. Namun, hubungan ini tidak terlalu kuat. Faktanya, jika Anda melihat kembali penelitian saya tentang pola SVG, kami melihat bahwa hanya 3 dari 8 kombinasi browser/AT yang mendengar pesan lengkapnya. (Catatan: Pola babi #1 setara dengan pola bola lampu #7.)

Ini benar meskipun spesifikasi W3C SVG yang berfungsi mendefinisikan elemen <text> sebagai “elemen grafis yang terdiri dari teks… karakter yang akan digambar dinyatakan sebagai data karakter. Akibatnya, data teks dalam konten SVG mudah diakses oleh tunanetra.” Pola pertama ini OK, tapi kita bisa melakukan yang lebih baik.

Pola kedua menghapus elemen <text> dan menggantinya dengan elemen <desc> . Spesifikasi W3C SVG menyatakan:

"Elemen anak <title> mewakili alternatif teks pendek untuk elemen... dan elemen <desc> mewakili informasi tekstual yang lebih detail untuk elemen seperti deskripsi."

Artinya elemen <title> dan <desc> di SVG dapat digunakan mirip dengan teks alternatif gambar dan opsi deskripsi panjang yang ditemukan secara tradisional di elemen <img> . Setelah menambahkan elemen <desc> ke SVG kedua, kami melihat dukungan browser/AT serupa dengan 3 dari 8 kombinasi mendengar pesan lengkap. (Catatan: Pola babi #2 setara dengan pola bola lampu #1.) Meskipun hasil pengujian ini tampaknya mencerminkan pola pertama, alasan mengapa pola ini masuk ke kategori "lebih baik" adalah karena sedikit lebih mudah untuk menerapkan kode- bijaksana dan berdampak pada lebih banyak pengguna AT, karena bekerja pada JAWS, desktop VoiceOver, dan VoiceOver seluler, sedangkan pola pertama mendukung kombinasi browser/AT yang kurang populer.

Pola ketiga kembali menggunakan elemen <title> dan <desc> tetapi sekarang memiliki aria-labelledby plus ID yang ditambahkan ke dalam campuran. Menurut tes SVG yang sama, menambahkan potongan kode tambahan ini berarti kami dapat sepenuhnya mendukung 7 dari 8 kombinasi browser/AT. (Catatan: Pola babi #3 setara dengan pola bola lampu #11) Dari tiga pola SVG, pola ketiga ini adalah yang "terbaik" karena mendukung sebagian besar perangkat AT. Tetapi pola ini memiliki kelemahan dalam menggunakan beberapa kombinasi browser/AT; Anda akan mendengar duplikat konten judul/deskripsi gambar untuk pola ini. Meskipun berpotensi mengganggu pengguna, saya berpendapat umumnya lebih baik mendengar konten duplikat daripada tidak sama sekali.

Pikiran Penutup

Sementara kita semua pasti menghargai pilihan dalam teknologi, saya bertanya-tanya apakah kita telah sampai pada titik di mana pilihan yang melimpah membuat kita lumpuh dan bingung tentang apa yang harus dilakukan selanjutnya? Dalam hal memilih pola yang dapat diakses, kami dapat mengajukan pertanyaan langsung seputar opsi pola/pustaka, dukungan perangkat browser/AT, batasan kerangka kerja, dan banyak lagi.

Dengan data yang tepat di tangan, pertanyaan-pertanyaan ini cukup mudah untuk dijawab. Namun, menjadi sedikit lebih rumit ketika kita melampaui pola dan benar-benar mempertimbangkan orang yang menggunakannya. Saat itulah kami menyadari dampak pilihan kami terhadap kemampuan pengguna kami untuk berhasil. Seperti yang dinyatakan dengan fasih oleh Prof. George Dei:

“Inklusi tidak membawa orang ke dalam apa yang sudah ada — itu membuat ruang baru, ruang yang lebih baik untuk semua orang.”

Dengan meluangkan sedikit lebih banyak waktu untuk berpikir kritis tentang pola dan memilih pola yang paling mudah diakses, kami pasti akan menciptakan ruang yang lebih inklusif untuk menjangkau lebih banyak pengguna — dengan persyaratan mereka.

Sumber Daya Terkait

Peralatan

• Dukungan Aksesibilitas, Michael Fairchild, a11ysupport.io
• Aksesibilitas HTML5, Steve Faulkner

Perpustakaan Pola

• Proyek Aksesibilitas
• Panduan Gaya Aksesibilitas
• Komponen yang Dapat Diakses, Scott O'Hara
• Plugin Pengurutan Ulang Daftar drag-and-drop dapat diakses, Harris Schneiderman
• Pustaka Pola ARIA Deque
• Pustaka React yang Dapat Diakses Deque
• Sistem Desain GOV.UK
• Komponen Inklusif, Heydon Pickering
• Sistem Desain Web AS (USWDS)
• Tutorial Aksesibilitas Web