Menentukan apakah situs atau aplikasi Anda dapat diakses mungkin tampak seperti tugas yang berat. Jika Anda baru pertama kali mempelajari aksesibilitas, cakupan topik yang luas dapat membuat Anda bingung harus memulai dari mana. Lagi pula, bekerja untuk mengakomodasi berbagai kemampuan berarti ada berbagai masalah yang harus dipertimbangkan.
Postingan ini menguraikan masalah ini menjadi proses langkah demi langkah yang logis untuk meninjau aksesibilitas situs yang ada.
Mulai dengan keyboard
Bagi pengguna yang tidak dapat atau memilih untuk tidak menggunakan mouse, navigasi keyboard adalah sarana utama untuk menjangkau semua hal di layar. Audiens ini mencakup pengguna dengan gangguan motorik, seperti cedera stres berulang (RSI) atau paralisis, serta pengguna pembaca layar.
Untuk pengalaman keyboard yang baik, usahakan untuk memiliki urutan tab yang logis dan gaya fokus yang jelas.
Mulai dengan menekan tombol tab di situs Anda. Urutan fokus elemen harus mengikuti urutan DOM. Jika Anda tidak yakin elemen mana yang harus menerima fokus, lihat modul dalam kursus Pelajari Aksesibilitas tentang fokus. Praktik terbaik adalah setiap kontrol yang dapat berinteraksi dengan pengguna atau memberikan input harus dapat difokuskan dan menampilkan indikator fokus (seperti cincin fokus).
Kontrol interaktif kustom harus dapat difokuskan. Jika Anda menggunakan JavaScript untuk mengubah
<div>
menjadi drop-down yang menarik,<div>
tidak akan otomatis disisipkan ke dalam urutan tab. Agar kontrol kustom dapat difokuskan, beritabindex="0"
. Nilaitabindex
yang lebih besar dari 0 akan mengubah urutan tab dan dapat membingungkan pengguna pembaca layar.Hanya buat konten interaktif 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 mengumumkannya.Jika Anda menambahkan konten baru ke halaman, arahkan fokus pengguna ke konten tersebut terlebih dahulu agar mereka dapat mengambil tindakan. Lihat Mengelola Fokus di Tingkat Halaman untuk mengetahui contohnya.
Desain situs Anda agar pengguna selalu dapat memfokuskan elemen berikutnya saat mereka ingin. Waspadai widget pelengkapan otomatis dan konteks lain yang dapat menjebak fokus keyboard. Anda dapat menjebak fokus untuk sementara jika ingin pengguna berinteraksi dengan modal, bukan bagian halaman lainnya, tetapi Anda harus selalu menyediakan cara yang dapat diakses keyboard untuk keluar dari modal. Lihat Modal dan Jebakan Keyboard untuk mengetahui contohnya.
Membuat kontrol fokus Anda dapat digunakan
Jika Anda telah membuat kontrol kustom, izinkan pengguna mengakses semua fiturnya hanya menggunakan keyboard. Baca Mengelola Fokus dalam Komponen untuk mengetahui teknik meningkatkan akses keyboard.
Mengelola konten di luar layar
Banyak situs memiliki konten di luar 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 ini di DOM dapat membuat pengalaman mengetik yang membingungkan, terutama untuk pembaca layar, yang mengumumkan konten di luar layar seolah-olah itu adalah bagian dari halaman.
Lihat Menangani konten di luar layar untuk mendapatkan tips menangani elemen ini.
Menguji dengan pembaca layar
Meningkatkan dukungan keyboard umum akan meletakkan beberapa dasar untuk langkah berikutnya, yaitu memeriksa halaman untuk mengetahui pemberian label dan semantik yang tepat serta hambatan apa pun terhadap navigasi pembaca layar.
Jika Anda tidak memahami cara markup semantik ditafsirkan oleh teknologi bantuan, baca Struktur konten.
- Periksa semua gambar untuk mengetahui apakah teks
alt
sudah benar. Pengecualian untuk praktik ini adalah jika gambar terutama ditujukan untuk tujuan presentasi dan bukan bagian konten yang penting. Untuk menunjukkan bahwa pembaca layar harus melewati gambar, tetapkan nilai ke string kosong:alt=""
. - Periksa semua kontrol untuk label. Untuk kontrol kustom, hal ini mungkin memerlukan penggunaan
aria-label
atauaria-labelledby
. Lihat Label dan Hubungan ARIA untuk mengetahui contohnya. - Periksa semua kontrol kustom untuk menemukan
role
yang sesuai dan atribut ARIA yang diperlukan yang menyampaikan statusnya. Misalnya, kotak centang kustom memerlukanrole="checkbox"
danaria-checked="true|false"
untuk menyampaikan statusnya dengan benar. Lihat Pengantar ARIA untuk ringkasan umum tentang cara ARIA dapat memberikan semantik yang hilang untuk kontrol kustom. - Buat alur informasi di halaman Anda masuk akal. Karena pembaca layar menavigasi halaman dalam urutan DOM, pembaca layar akan mengumumkan elemen apa pun yang telah Anda posisikan ulang secara visual menggunakan CSS dalam urutan yang tidak masuk akal. Jika Anda memerlukan sesuatu untuk muncul lebih awal di halaman, pindahkan secara fisik lebih awal di DOM.
- Bertujuan untuk mendukung navigasi pembaca layar untuk semua konten di halaman. Pastikan
tidak ada bagian situs yang disembunyikan atau diblokir secara permanen dari akses
pembaca layar.
- Jika konten harus disembunyikan dari pembaca layar, misalnya, jika konten tersebut
tidak ditampilkan atau hanya bersifat presentasi, tetapkan konten tersebut ke
aria-hidden="true"
. Untuk penjelasan yang lebih mendalam, lihat Menyembunyikan konten.
- Jika konten harus disembunyikan dari pembaca layar, misalnya, jika konten tersebut
tidak ditampilkan atau hanya bersifat presentasi, tetapkan konten tersebut ke
Memahami pembaca layar
Meskipun mungkin terlihat menakutkan untuk mempelajari pembaca layar, alat ini sebenarnya cukup mudah digunakan. Secara umum, sebagian besar developer dapat melakukannya hanya dengan beberapa perintah tombol sederhana.
Jika Anda menggunakan Mac, tonton video tentang VoiceOver, pembaca layar yang disertakan dengan Mac OS. Jika Anda menggunakan PC, lihat video tentang NVDA, pembaca layar open source yang didukung donasi untuk Windows.
aria-hidden
tidak mencegah fokus keyboard
Perlu dipahami bahwa ARIA hanya dapat memengaruhi semantik elemen; tidak memengaruhi perilaku elemen. Anda dapat membuat elemen disembunyikan 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 memastikan konten tersebut benar-benar dihapus dari alur keyboard. Untuk browser lama,
gabungkan aria-hidden="true"
dengan tabindex="-1"
.
Elemen interaktif harus menunjukkan tujuan dan statusnya
Memberikan petunjuk visual, atau affordance, tentang apa yang akan dilakukan kontrol membantu berbagai orang di berbagai perangkat mengoperasikan dan menjelajahi situs Anda.
- Elemen interaktif, seperti link dan tombol, harus dapat dibedakan dari elemen non-interaktif. Pengguna akan kesulitan menavigasi situs atau aplikasi jika mereka tidak dapat mengetahui apakah elemen dapat diklik atau tidak. Ada banyak cara yang valid untuk menunjukkan elemen interaktif. Salah satu praktik umum adalah menggarisbawahi link untuk membedakan link 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 lainnya, elemen tersebut harus dapat dibedakan tanpa statushover
.
Manfaatkan judul dan penanda
Judul dan elemen penanda memberikan struktur semantik halaman, 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 menavigasi berdasarkan judul.
Demikian pula, pembaca layar juga menawarkan kemampuan untuk melompat ke penanda penting
seperti <main>
dan <nav>
. Karena alasan ini, penting untuk mempertimbangkan bagaimana
struktur halaman Anda dapat digunakan untuk memandu pengalaman pengguna.
- Gunakan hierarki
h1-h6
. Anggaplah judul sebagai alat untuk membuat garis besar halaman Anda. Jangan mengandalkan gaya bawaan judul. Sebagai gantinya, perlakukan semuanya seolah-olah memiliki ukuran yang sama dan gunakan tingkat yang sesuai secara semantik untuk konten utama, sekunder, dan tersier. Kemudian, gunakan CSS untuk membuat judul cocok dengan desain Anda. - Gunakan elemen dan peran penanda agar pengguna dapat melewati konten berulang. Banyak teknologi bantuan yang menyediakan pintasan untuk melompat ke bagian halaman tertentu, seperti yang ditentukan oleh elemen
<main>
atau<nav>
. Elemen ini memiliki peran penanda implisit. Anda juga dapat menggunakan atributrole
ARIA untuk menentukan wilayah di halaman secara eksplisit, seperti dalam<div role="search">
. Lihat Semantik dan menavigasi konten untuk mengetahui contoh selengkapnya. - Hindari
role="application"
kecuali jika Anda memiliki pengalaman menggunakannya. Peran penandaapplication
memberi tahu teknologi pendukung untuk menonaktifkan pintasanya dan meneruskan semua penekanan tombol ke halaman. Artinya, tombol yang biasanya digunakan pengguna pembaca layar untuk berpindah di halaman tidak lagi berfungsi, dan Anda harus menerapkan semua penanganan keyboard sendiri.
Meninjau judul dan penanda dengan pembaca layar
Pembaca layar, seperti VoiceOver dan NVDA, menyediakan menu konteks untuk melewati wilayah penting di halaman. Saat menguji aksesibilitas, Anda dapat menggunakan menu ini untuk mendapatkan ringkasan halaman dan menentukan apakah tingkat judul Anda sudah sesuai dan penanda mana yang digunakan.
Untuk mempelajari lebih lanjut, lihat video petunjuk tentang dasar-dasar VoiceOver dan NVDA.
Mengotomatiskan proses
Menguji aksesibilitas situs secara manual dapat membosankan dan rawan error. Sebaiknya otomatiskan pengujian sebanyak mungkin. Anda dapat menggunakan ekstensi browser dan suite 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 proses pengujian manual karena dapat
mendeteksi masalah halus 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.
- Untuk menghindari regresi, terutama di lingkungan integrasi berkelanjutan, sertakan library seperti axe-core ke dalam rangkaian pengujian otomatis Anda. axe-core adalah mesin yang sama dengan yang mendukung ekstensi Chrome aXe, tetapi dalam utilitas command line.
- Jika Anda menggunakan framework atau library, apakah framework atau library tersebut menyediakan alat aksesibilitas sendiri? Misalnya, protractor-accessibility-plugin 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, library ini menggunakan library axe-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.