
Jacob Thornton memiliki tayangan slide inspiratif tentang aksesibilitas yang menyoroti beberapa kekhawatiran pengembang web tentang penerapan fitur aksesibilitas.
Sejak lama, pengembang telah diminta untuk membuat situs web “dapat diakses”. Ibarat keran yang harus dihidupkan atau dimatikan. Hingga Victor Tsaran mendemonstrasikan cara menggunakan pembaca layar (ini terjadi pada tahun 2007—jauh sebelum aksesibilitas mulai menyebar)—hanya sedikit pengembang Web yang mengetahui dampak langsung sebenarnya dari penerapan fitur aksesibilitas.
Beberapa tahun lalu, dalam percakapan antara Nicholas Zakas dan Victor Tsaran, saya akhirnya menemukan aturan paling sederhana untuk mengambil langkah pertama menuju aksesibilitas. Sudah terlalu lama kita menggabungkan fungsionalitas dengan JavaScript yang dinonaktifkan dengan “aksesibilitas”. Butuh waktu bertahun-tahun bagi saya untuk memahami hal ini Jadikan keyboard dapat dinavigasi Ini adalah prioritas utama.
apa yang kita butuhkan
orang suka Jason Keith Dan Steve Faulkner Mereka merinci perilaku dan dukungan browser dan pembaca layar, memberikan komunitas pengembang pengetahuan berharga yang lebih berharga daripada menerbitkan daftar “hal-hal yang harus Anda lakukan”. (Lihat juga daftar sumber daya saya di postingan Semantik saya).
Sebagian besar pengembang tidak tahu apa dampak penambahan markup ARIA ke file kami terhadap orang yang menggunakan pembaca layar. Kami membutuhkan itu. Konten video sebelum dan sesudah yang sebenarnya menjadikan pokok bahasannya nyata. Lihat postingan terbaru Zomigi: Video Pembaca Layar Menggunakan ARIA untuk contoh yang bagus.
Kebanyakan pengembang tidak tahu cara mengimplementasikan ARIA. Apa yang tampak sebagai W3C Primer kanonik sebenarnya tidak cocok untuk audiens pengembang Web.
Sama seperti menyaksikan sesi kegunaan setiap tahun di mana Anda dapat melihat bagaimana penyandang disabilitas menggunakan situs Anda, saya rasa bermanfaat bagi komunitas aksesibilitas untuk melihat bagaimana pengembang membangun karena sejauh ini, ada banyak pekerjaan yang harus dilakukan. dalam komunikasi. Saya rasa kita belum memerlukan lebih banyak penginjilan di lapangan. Saat ini terdapat kelangkaan sumber daya online, dan pengembang perlu memahami cara-cara praktis berikut untuk menggunakan dan memungkinkan pengguna mendapatkan manfaat dari teknologi pendukung:
- Fitur mana yang harus saya gunakan, dan fitur mana yang harus saya hindari (fitur mana yang sangat berbahaya karena pembaca layar yang buruk/dukungan teknis a11y lainnya?)
- Apa prioritas utama yang harus diterapkan oleh pengembang?
- Video menggunakan pembaca layar
- Sebagai pengembang web, satu hal apa yang dapat saya lakukan agar situs web dan aplikasi saya dapat meningkatkan pengalaman pengguna secara signifikan bagi pengguna penyandang disabilitas?
- Bagaimana cara kerja beberapa fitur ini? Untuk apa mereka digunakan? Akan sangat membantu jika mendemonstrasikan bagaimana setiap fungsi memengaruhi atau digunakan oleh pengguna (misalnya, bagaimana cara kerja cincin fokus?).
Pembaca layar dan browser
Selain itu, saya tidak yakin bagaimana perasaan orang lain, tapi mulai saat ini rasanya seperti berteriak pada dinding bata dengan Rahang dan Mata Jendela. Kami hanya berharap dan berdoa atas dukungan mereka dan keadaan akan membaik. Sebagai pendekatan pragmatis, saya memberi tahu pengembang bahwa jika ini berfungsi di NVDA, itu sudah cukup. Kita sudah perlu mendukung sejumlah besar browser, dan menangani AT yang tertinggal beberapa tahun adalah hal yang tidak mungkin dilakukan.
Banyak pengembang yang tidak memahami bahwa aksesibilitas pertama-tama berasal dari browser yang mengimplementasikan API aksesibilitas platform sehingga pembaca layar dapat memanfaatkan rendering. Sebagian besar sistem operasi mengekspos API yang memungkinkan browser memetakan konten yang disajikan di layar ke salah satu antarmuka yang diekspos oleh API aksesibilitas sistem operasi.
Sayangnya, tidak ada spesifikasinya, sehingga setiap browser dapat melakukan apa pun yang diinginkannya dalam mendefinisikan hubungan antara elemen HTML dan antarmuka aksesibilitas. Mudah-mudahan hal ini akan berubah dengan perubahan panduan implementasi HTML ke Platform Accessibility API dan memastikan bahwa setiap browser mengekspos setiap elemen ke Platform Accessibility API secara konsisten.
Hal ini menimbulkan kekhawatiran yang lebih besar: Aksesibilitas yang lebih baik dimulai dari browser (dan platform). Browser harus mampu menangani konten yang dimuat secara dinamis, daripada mengharapkan pengembang melakukannya untuk mereka. Jika konten pada halaman yang ditampilkan berubah, hal ini perlu dicatat secara transparan ke API aksesibilitas, daripada meminta pengembang menambahkan markup tambahan untuk melakukan hal ini.
Aksesibilitas tidak seharusnya menjadi sebuah pilihan untuk ikut serta, namun sebuah pilihan untuk tidak ikut serta.
Posting ini adalah versi yang lebih panjang dari ulasan saya tentang Hambatan Karl Grove dalam Meningkatkan Rencana Permainan Aksesibilitas. Ini mungkin postingan terbaik di a11y yang pernah saya baca. SAYA nyata Saya menyukai pendekatannya dalam mengembangkan strategi a11y dan meninggalkan pemikiran saya sendiri.
Terima kasih kepada Divya Manian atas pemikiran dan komentarnya pada artikel ini. Terima kasih kepada Jason Kiss yang telah meninjau drafnya.
06.06.2013: Ini telah diterjemahkan ke dalam bahasa Ceko: [Dostupnost a Vývojáři](http://led24.de/blog/dostupnost-a-vyvojari).