Cara meninjau aksesibilitas

Rob Dodson

Menentukan apakah situs atau aplikasi Anda dapat diakses bisa tampak seperti tugas yang kewalahan. Jika Anda membahas aksesibilitas untuk pertama kalinya, luasnya topik ini dapat membuat Anda bertanya-tanya dari mana harus memulai. Lagi pula, bekerja untuk mengakomodasi beragam kemampuan berarti ada beragam masalah yang perlu dipertimbangkan.

Postingan ini menguraikan masalah tersebut menjadi proses langkah demi langkah yang logis untuk meninjau situs yang ada terkait aksesibilitas.

Mulai dengan keyboard

Bagi pengguna yang tidak dapat atau memilih untuk tidak menggunakan mouse, navigasi keyboard adalah cara utama untuk menjangkau semua yang ada di layar. Audiens ini mencakup pengguna yang mengalami gangguan motorik, seperti cedera stres atau kelumpuhan berulang (RSI), serta pengguna pembaca layar.

Untuk pengalaman keyboard yang baik, usahakan untuk memiliki urutan tab yang logis dan gaya fokus yang terlihat jelas.

  • Mulai dengan menekan tombol tab di situs Anda. Urutan elemen difokuskan harus mengikuti urutan DOM. Jika Anda tidak yakin elemen mana yang harus difokus, lihat Dasar-Dasar Fokus untuk mengingat kembali. Praktik terbaik adalah kontrol apa pun yang dapat berinteraksi dengan pengguna atau yang diberi input harus dapat difokuskan dan menampilkan indikator fokus (seperti lingkaran fokus).

  • Kontrol interaktif kustom harus dapat difokuskan. Jika Anda menggunakan JavaScript untuk mengubah <div> menjadi menu drop-down yang menarik, kode tersebut tidak akan otomatis dimasukkan ke dalam urutan tab. Agar kontrol kustom dapat difokuskan, berikan tabindex="0". Nilai tabindex yang lebih besar dari 0 akan mengubah urutan tab dan dapat membingungkan bagi pengguna pembaca layar.

  • Buat agar konten interaktif saja yang dapat difokuskan. Menambahkan tabindex ke elemen non-interaktif seperti judul akan memperlambat pengguna keyboard yang dapat melihat layar, dan tidak membantu pengguna pembaca layar karena pembaca layar sudah tahu untuk mengucapkannya.

  • Jika Anda menambahkan konten baru ke halaman, arahkan fokus pengguna ke konten tersebut terlebih dahulu sehingga mereka dapat mengambil tindakan. Lihat Mengelola Fokus di Tingkat Halaman untuk mengetahui contohnya.

  • Rancang situs Anda agar pengguna selalu dapat memfokuskan elemen berikutnya kapan pun mereka ingin. Waspadai widget pelengkapan otomatis dan konteks lain yang dapat menangkap fokus keyboard. Anda dapat menangkap fokus untuk sementara saat ingin pengguna berinteraksi dengan modal dan bukan dengan bagian halaman lainnya, tetapi Anda harus selalu menyediakan cara yang dapat diakses dengan keyboard untuk keluar dari modal. Lihat Modal dan Perangkap Keyboard sebagai contoh.

Jadikan kontrol fokus Anda bermanfaat

Jika Anda telah membuat kontrol kustom, biarkan pengguna menjangkau semua fiturnya hanya dengan menggunakan keyboard. Baca Mengelola Fokus Dalam Komponen untuk mengetahui teknik dalam meningkatkan akses keyboard.

Mengelola konten di luar layar

Banyak situs memiliki konten di balik layar yang ada di DOM tetapi tidak terlihat, seperti link di dalam menu panel samping responsif atau tombol di dalam jendela modal yang belum ditampilkan. Membiarkan elemen-elemen ini dalam DOM dapat menimbulkan pengalaman keyboard yang membingungkan, terutama untuk pembaca layar, yang mengumumkan konten di balik layar seolah-olah konten tersebut merupakan bagian dari halaman.

Lihat Menangani konten di luar layar untuk mengetahui tips dalam menangani elemen ini.

Menguji dengan pembaca layar

Meningkatkan dukungan keyboard umum akan memberikan dasar untuk langkah berikutnya, yaitu memeriksa halaman untuk pelabelan dan semantik yang tepat serta gangguan apa pun pada navigasi pembaca layar.

Jika Anda tidak mengetahui cara markup semantik ditafsirkan oleh teknologi pendukung, baca Struktur konten.

  • Periksa semua gambar untuk teks alt yang benar. Pengecualian untuk praktik ini adalah jika gambar terutama untuk tujuan presentasi dan bukan konten yang penting. Untuk menunjukkan bahwa pembaca layar harus melewati gambar, tetapkan nilai ke string kosong: alt="".
  • Centang semua kontrol untuk label. Untuk kontrol kustom, hal ini mungkin memerlukan penggunaan aria-label atau aria-labelledby. Lihat Label dan Hubungan ARIA untuk mengetahui contohnya.
  • Periksa semua kontrol kustom untuk role yang sesuai dan atribut ARIA yang diperlukan yang menyampaikan statusnya. Misalnya, kotak centang kustom memerlukan role="checkbox" dan aria-checked="true|false" untuk menyampaikan statusnya dengan benar. Lihat Pengantar ARIA untuk ringkasan umum tentang bagaimana ARIA dapat menyediakan semantik yang tidak ada untuk kontrol khusus.
  • Buat aliran informasi melalui halaman Anda masuk akal. Karena pembaca layar menavigasi halaman dalam urutan DOM, pembaca akan mengumumkan elemen apa pun yang telah Anda posisikan secara visual menggunakan CSS dalam urutan yang tidak masuk akal. Jika Anda memerlukan sesuatu untuk muncul di awal halaman, pindahkan secara fisik ke awal di DOM.
  • Upayakan untuk mendukung navigasi pembaca layar untuk semua konten di halaman. Pastikan tidak ada bagian situs yang disembunyikan secara permanen atau diblokir dari akses pembaca layar.
    • Jika konten harus disembunyikan dari pembaca layar, misalnya jika berada di luar layar atau hanya presentasi, tetapkan konten tersebut ke aria-hidden="true". Untuk mendapatkan penjelasan yang lebih mendalam, lihat Menyembunyikan konten.

Membiasakan diri dengan {i>screen reader<i}

Meskipun mungkin terlihat sulit untuk mempelajari pembaca layar, mereka sebenarnya cukup mudah digunakan. Secara umum, sebagian besar developer dapat melewatinya hanya dengan beberapa perintah kunci sederhana.

Jika Anda menggunakan Mac, tonton video tentang VoiceOver, pembaca layar yang disertakan dengan Mac OS. Jika Anda menggunakan PC, tonton video tentang NVDA, pembaca layar open source yang didukung donasi untuk Windows.

aria-hidden tidak mencegah fokus keyboard

Penting untuk dipahami bahwa ARIA hanya dapat memengaruhi semantik elemen; tetapi tidak berpengaruh pada perilaku elemen. Anda dapat membuat elemen tersembunyi dari pembaca layar dengan aria-hidden="true", tetapi hal itu tidak mengubah perilaku fokus untuk elemen tersebut. Untuk konten interaktif di luar layar, Untuk konten interaktif di luar layar, gunakan atribut inert untuk memastikannya benar-benar dihapus dari alur keyboard. Untuk browser lama, gabungkan aria-hidden="true" dengan tabindex="-1".

Elemen interaktif harus menunjukkan tujuan dan status mereka

Memberikan petunjuk visual, atau kemampuan, tentang fungsi kontrol akan membantu berbagai orang di berbagai perangkat untuk mengoperasikan dan menavigasi situs Anda.

  • Elemen interaktif, seperti link dan tombol, harus dapat dibedakan dari elemen non-interaktif. Pengguna akan kesulitan membuka situs atau aplikasi jika mereka tidak dapat mengetahui apakah suatu elemen dapat diklik. Ada banyak cara yang valid untuk menunjukkan elemen interaktif. Salah satu praktik umum adalah menggarisbawahi tautan untuk membedakannya dari teks di sekitarnya.
  • Serupa dengan persyaratan fokus, elemen interaktif seperti link dan tombol memerlukan status hover untuk memberi tahu pengguna mouse saat kursor mereka berada di atas sesuatu yang dapat diklik. Namun, agar elemen ini dapat diakses oleh metode input lain, elemen tersebut harus dapat dibedakan tanpa status hover.

Memanfaatkan {i>heading<i} dan {i>landmark<i}

Judul dan elemen penanda memberi struktur semantik halaman Anda, dan sangat meningkatkan efisiensi navigasi pengguna teknologi pendukung. Banyak pengguna pembaca layar melaporkan bahwa, saat pertama kali membuka halaman yang tidak dikenal, mereka biasanya mencoba membuka berdasarkan judul.

Demikian pula, pembaca layar juga menawarkan kemampuan untuk melompat ke tempat terkenal seperti <main> dan <nav>. Oleh karena itu, penting untuk mempertimbangkan bagaimana struktur halaman dapat digunakan untuk memandu pengalaman pengguna.

  • Gunakan hierarki h1-h6. Anggaplah {i>heading<i} sebagai alat untuk membuat garis besar halaman Anda. Jangan mengandalkan gaya judul bawaan. Sebagai gantinya, perlakukan semuanya seolah-olah semuanya berukuran sama dan gunakan tingkat yang sesuai secara semantik untuk konten primer, sekunder, dan tersier. Kemudian gunakan CSS untuk membuat {i>heading <i}yang sesuai dengan desain Anda.
  • Gunakan elemen dan peran penanda agar pengguna dapat mengabaikan konten berulang. Banyak teknologi pendukung menyediakan pintasan untuk melompat ke bagian tertentu di halaman, seperti yang ditentukan oleh elemen <main> atau <nav>. Elemen-elemen ini memiliki peran penanda yang implisit. Anda juga dapat menggunakan atribut role ARIA untuk menentukan wilayah secara eksplisit di halaman, seperti di <div role="search">. Lihat Semantik dan navigasi konten untuk mengetahui contoh lainnya.
  • Hindari role="application", kecuali jika Anda memiliki pengalaman menggunakannya. Peran penanda application memberi tahu teknologi pendukung untuk menonaktifkan pintasannya dan meneruskan semua penekanan tombol ke halaman. Artinya, tombol pembaca layar yang biasanya digunakan pengguna untuk berpindah-pindah di halaman tidak lagi berfungsi, dan Anda harus menerapkan semua penanganan keyboard sendiri.

Tinjau judul dan tempat terkenal dengan pembaca layar

Pembaca layar, seperti VoiceOver dan NVDA, menyediakan menu konteks untuk melewati area penting di halaman. Saat menguji aksesibilitas, Anda dapat menggunakan menu ini untuk mendapatkan ringkasan halaman dan menentukan apakah tingkat judul sudah sesuai dan penanda mana yang digunakan.

Untuk mempelajari lebih lanjut, tonton video petunjuk ini tentang dasar-dasar VoiceOver dan NVDA.

Mengotomatiskan prosesnya

Menguji aksesibilitas situs secara manual bisa merepotkan dan rentan error. Ada baiknya Anda mengotomatiskan pengujian sebanyak mungkin. Anda dapat menggunakan ekstensi browser dan rangkaian pengujian aksesibilitas command line.

  • Apakah halaman lulus semua pengujian dari ekstensi browser aXe atau WAVE? Ada opsi lain yang tersedia, tetapi ekstensi ini dapat menjadi tambahan yang berguna untuk setiap proses pengujian manual karena dapat menemukan masalah kecil seperti rasio kontras yang gagal dan atribut ARIA yang tidak ada.
    • Jika Anda lebih suka bekerja di command line, axe-cli menyediakan fitur yang sama dengan ekstensi browser aXe, tetapi dapat dijalankan dari terminal Anda.
  • Untuk menghindari regresi, khususnya di lingkungan continuous integration, sertakan library seperti ax-core ke dalam rangkaian pengujian otomatis. axis-core adalah mesin yang sama yang mendukung ekstensi Chrome APX, tetapi dalam utilitas command line.
  • Jika Anda menggunakan framework atau library, apakah framework atau library menyediakan alat aksesibilitasnya sendiri? Misalnya, plugin protractor-accessibility- untuk Angular. Manfaatkan alat yang tersedia jika memungkinkan.

Menggunakan Lighthouse untuk menguji PWA

Lighthouse adalah alat yang mengukur performa progressive web app (PWA) Anda. Selain itu, kode ini menggunakan library axis-core untuk mendukung pengujian aksesibilitasnya.

Jika Anda sudah menggunakan Lighthouse, cari pengujian aksesibilitas yang gagal dalam laporan Anda. Perbaiki error untuk meningkatkan pengalaman pengguna situs Anda secara keseluruhan.

Referensi tambahan