5 Langkah Mendesain Aplikasi Dengan Mempertimbangkan Aksesibilitas Keyboard

Saat kita berpikir tentang pengguna “rata-rata”, kita cenderung membayangkan mereka menggunakan mouse atau trackpad saat mereka menggunakan komputer. Namun, bagaimana jika pilihan yang mereka sukai atau satu-satunya adalah menggunakan keyboard? Sudahkah Anda mempertimbangkan untuk merancang aplikasi Anda dengan mempertimbangkan aksesibilitas keyboard?

Ada banyak alasan seseorang mungkin tidak mau, atau tidak dapat mengoperasikan mouse atau trackpad untuk menggunakan komputernya. Mereka mungkin memiliki kondisi permanen, kronis, atau sementara yang membatasi ketangkasan atau kontrol otot mereka, menyebabkan kepekaan pada pergelangan tangan atau tangan mereka, atau menyulitkan untuk mengikuti kursor mouse di layar. Mereka juga bisa menjadi "pengguna canggih" yang mencari lebih banyak pintasan untuk merampingkan alur kerja mereka. Dalam salah satu kasus ini, keyboard mungkin merupakan sarana yang disukai atau diperlukan seseorang untuk berinteraksi dengan teknologi.

Dalam artikel ini, Anda akan mempelajari tentang pedoman aksesibilitas keyboard, serta lima langkah yang harus diperhatikan saat mendesain aplikasi untuk memastikan aplikasi dapat diakses oleh keyboard.

Bagaimana cara kerja aksesibilitas keyboard?

Jika aplikasi dapat diakses dengan papan ketik, itu artinya orang memiliki opsi untuk hanya menggunakan papan ketik untuk mengoperasikan elemen kontrol . Elemen kontrol adalah komponen interaktif apa pun di halaman, seperti tombol, tautan, masukan formulir, video, dan konten interaktif lainnya.

Dasar-dasar navigasi keyboard

Berikut beberapa tombol dasar yang digunakan untuk navigasi keyboard:

• Menavigasi ke elemen kontrol berikutnya: Tab (atau tombol panah kanan atau bawah untuk tombol radio terkait dan pilih opsi)
• Menavigasi ke elemen kontrol sebelumnya: Shift + Tab (atau tombol panah kiri atau atas untuk tombol radio terkait dan pilih opsi)
• Mengklik elemen kontrol: Masukkan dan/atau bilah spasi
• Menavigasi antara tombol radio terkait atau memilih opsi: Tombol panah

Urutan fokus

Urutan di mana elemen kontrol dapat merespons peristiwa keyboard dikenal sebagai urutan fokus . Saat sebuah elemen difokuskan, Anda dapat berinteraksi dengannya menggunakan kontrol keyboard tertentu. Ketika sebuah elemen kehilangan fokus, itu menjadi kabur. Peramban merender status fokus default untuk membantu pengguna melacak elemen mana yang saat ini menjadi fokus.

Anda mungkin juga menyukai: Desain Universal: 11 Tips Praktis untuk Membuat Situs dan Aplikasi Anda Lebih Mudah Diakses.

Aksesibilitas keyboard dan Panduan Aksesibilitas Konten Web (WCAG)

Pedoman Aksesibilitas Konten Web (WCAG) menguraikan tiga tingkat kepatuhan—Level A, Level AA, dan Level AAA—yang telah diadopsi sebagai standar untuk undang-undang aksesibilitas web regional atau nasional di seluruh dunia.

Aksesibilitas keyboard adalah salah satu kriteria keberhasilan untuk kepatuhan Level A. Kriteria Level A menjelaskan fitur yang harus dimiliki untuk semua konten web. Mereka juga dianggap paling mudah untuk diterapkan.

“Aksesibilitas keyboard juga mudah salah jika kita tidak hati-hati.”

Konon, aksesibilitas keyboard juga mudah salah jika kita tidak hati-hati. Berikut adalah contoh masalah aksesibilitas keyboard umum yang ditemukan di web:

• Status fokus yang tidak terlihat
• Urutan fokus salah
• Elemen interaktif yang tidak dapat menerima fokus
• Komponen kompleks yang tidak mengambil interaksi keyboard

Untungnya, ada banyak teknik yang dapat kita gunakan untuk mengingat pengguna keyboard dan menghindari membuat kesalahan ini di aplikasi kita sendiri.

5 langkah untuk membuat aplikasi yang dapat diakses keyboard

1. Rancang interaksi intuitif

Saat kami merender elemen kontrol sederhana tanpa perilaku yang disesuaikan, kami biasanya dapat memanfaatkan fitur aksesibilitas keyboard bawaannya. Namun, jika kami tidak mengetahui perilaku papan ketik standar yang terkait dengan tombol, tautan, atau masukan, kami mungkin secara tidak sengaja membuat pengalaman yang membingungkan bagi pengguna papan ketik.

“Jika kami tidak mengetahui perilaku papan ketik standar yang terkait dengan tombol, tautan, atau masukan, kami mungkin secara tidak sengaja membuat pengalaman yang membingungkan bagi pengguna papan ketik.”

Misalnya, pengembang terkadang menggunakan CSS untuk menyembunyikan tombol radio HTML asli demi visual yang lebih bergaya. Tidak jelas bahwa inputnya adalah tombol radio di belakang layar, sehingga pengguna keyboard mungkin tidak menyadari bahwa mereka harus menggunakan tombol panah—bukan tombol Tab—untuk mengalihkan fokus di antara opsi terkait.

Untuk menghindari masalah ini, kita harus menampilkan sesuatu yang setidaknya menyerupai elemen HTML asli untuk memberikan petunjuk visual bagi siapa saja yang ingin atau perlu berinteraksi dengannya menggunakan keyboard.

2. Buat aplikasi Anda agar keyboard dapat melakukan semua hal yang dapat dilakukan mouse

Waspadai elemen yang tidak disertakan dengan fitur aksesibilitas keyboard bawaan. Elemen layout, daftar, tabel, header, paragraf, dan tag HTML non-semantik tidak mendukung pintasan keyboard secara default. Namun, mereka sering digunakan untuk membangun komponen yang lebih kompleks, seperti tab, daftar drag-and-drop, atau modals.

JavaScript memungkinkan kita menambahkan event listener yang membuat elemen non-kontrol merespons klik atau gerakan mouse. Di React, misalnya, kita bisa menggunakan prop onClick untuk menambahkan interaktivitas ke elemen item daftar.

Setiap kali kita menambahkan interaktivitas ke elemen non-kontrol, kita perlu menyetel atribut tabIndex ke 0 . Ini akan memungkinkan elemen menerima fokus dalam urutan fokus yang benar saat tombol Tab ditekan. Kita juga perlu mengimplementasikan keypress atau keydown event handler untuk mendaftarkan "klik" melalui tombol Enter dan/atau Spacebar (tautan dapat diklik menggunakan keduanya, sedangkan tombol hanya mendukung tombol Enter).

Kita dapat menghindari beberapa pekerjaan tambahan ini dengan menggunakan kontrol seperti tag jangkar atau elemen tombol. Kami selalu dapat menggunakan CSS untuk mengganti gaya tautan dan tombol default, dan membuat elemen interaktif menjangkau seluruh lebar induk non-interaktifnya untuk memaksimalkan area target.

Apakah kita menggunakan elemen kontrol untuk fitur non-native atau tidak, kita mungkin masih perlu menambahkan event listener untuk tombol panah (untuk menavigasi antar tab dalam komponen tab) atau tombol Escape (untuk menutup overlay) untuk membuat komponen kita 100 persen keyboard dapat diakses.

Jika kami menerapkan perilaku keyboard non-standar untuk komponen yang lebih kompleks, akan sangat membantu untuk memberikan instruksi yang terlihat yang menjelaskan kontrol keyboard yang dapat digunakan orang untuk berinteraksi dengan komponen tersebut.

3. Lakukan pekerjaan ekstra saat mengesampingkan urutan fokus default

Urutan fokus adalah persyaratan WCAG lain yang terkait erat dengan aksesibilitas keyboard. Untuk memenuhi kriteria Level A, urutan fokus harus konsisten dengan urutan visual elemen interaktif di halaman. Pengguna keyboard harus dapat menavigasi melalui elemen kontrol di layar dari atas ke bawah dan dalam arah horizontal yang sama dengan konten teks Anda (kiri ke kanan, atau kanan ke kiri).

Cara termudah untuk memenuhi kriteria ini adalah dengan membiarkan urutan fokus default, yang ditentukan oleh urutan di mana elemen disusun dalam markup , apa adanya. Kami berisiko gagal memenuhi kriteria ini saat kami memperkenalkan ketidaksesuaian antara urutan visual elemen kontrol dan cara mereka ditata dalam kode sumber.

Anda mungkin juga menyukai: Membuat Navigasi Breadcrumb yang Dapat Diakses dengan Liquid dan Shopify.

Jika kita menggunakan tangkapan layar di atas sebagai contoh, katakanlah kita ingin kartu "Perbarui tag" untuk bertukar posisi dengan kartu "Perbarui deskripsi" saat ditumpuk untuk area pandang yang lebih sempit. Jika kartu dirender sebagai item fleksibel, kami mungkin mempertimbangkan untuk menggunakan properti order CSS untuk mengubah urutannya pada breakpoint tertentu.

Meskipun properti order memengaruhi urutan visual item fleksibel, properti ini tidak memperbarui pengaturannya di kode sumber. Akibatnya, saat pengguna menekan tombol Tab untuk menavigasi di antara setiap tombol, tombol "Perbarui tag" akan tetap menerima fokus sebelum "Perbarui deskripsi", meskipun ditampilkan dalam urutan terbalik di layar. Ini menyebabkan fokus tiba-tiba bergeser ke atas dan ke bawah halaman, menciptakan pengalaman yang membingungkan bagi pengguna.

Salah satu cara untuk menghindari masalah ini adalah merender dua versi kartu di markup: satu dalam urutan yang diharapkan untuk lebar viewport yang lebih lebar, dan satu lagi dalam urutan yang diinginkan untuk lebar viewport yang lebih sempit. Kita dapat menggunakan properti display untuk beralih di antara keduanya pada breakpoint tertentu.

Jika kita tidak ingin mempertahankan dua versi dalam markup, kita perlu menggunakan JavaScript untuk memperbarui atribut tabIndex dari kartu saat menumpuk di halaman. Bergantung pada jumlah elemen kontrol yang kami render, pendekatan ini mungkin lebih sulit dilakukan dengan benar daripada mempertahankan versi berbeda dari kartu di markup.

4. Saat menyesuaikan status fokus, desain untuk pengguna yang paling membutuhkannya

Peramban menggunakan properti CSS outline untuk membuat semacam indikasi visual bahwa suatu elemen sedang dalam fokus. Status fokus dimaksudkan untuk membantu pengguna mengidentifikasi elemen mana yang akan mendaftarkan aktivitas keyboard saat mereka menavigasi halaman dengan keyboard.

Sangat umum bagi desainer dan pengembang untuk mengganti status fokus default yang dirender oleh browser. Ini mungkin melibatkan pembaruan outline default, atau menghapusnya sepenuhnya dan menggantinya dengan properti CSS lain, seperti background , border , box-shadow , color , atau transform .

Anda mungkin juga menyukai: Membuat Paginasi yang Dapat Diakses dengan Liquid.

Bagaimanapun kita memutuskan untuk merender status fokus khusus di aplikasi kita, kita harus memastikannya memenuhi persyaratan aksesibilitas berikut:

• Kontras warna yang memadai: Harus ada kontras yang cukup antara status fokus kita dan warna di sekitarnya sehingga pengguna tunanetra dapat dengan mudah melacak elemen mana yang sedang dalam fokus.
• Perubahan warna dipasangkan dengan indikator visual lainnya: Mengubah warna batas elemen, font, atau latar belakang mungkin tidak terlihat oleh pengguna buta warna. Itu harus dipasangkan dengan perubahan visual lain yang tidak mengharuskan pengguna untuk dapat membedakan warna. Ini juga berlaku untuk status hover dan error yang melibatkan perubahan warna.
• Terlihat dalam tema kontras tinggi: Beberapa properti CSS, termasuk background dan box-shadow , diabaikan saat mode kontras tinggi diaktifkan di perangkat Windows. Perubahan warna mungkin juga tidak terdaftar, oleh karena itu sangatlah penting untuk mengandalkan indikator tambahan yang dapat dilihat oleh orang-orang yang membutuhkan lebih banyak kontras antara warna latar belakang dan latar depan.

Meskipun dapat diterima untuk mengganti properti outline default, jangan pernah menghapus status fokus default tanpa memberikan penggantinya.

5. Sediakan jalan pintas untuk pengguna keyboard

Jika seseorang menggunakan mouse untuk menavigasi halaman web, mereka dapat menggulir melewati konten header yang asing saat halaman dimuat untuk mencapai informasi yang mereka cari. Prosesnya tidak sesingkat untuk pengguna keyboard, yang mungkin perlu menelusuri beberapa tautan navigasi, atau elemen kontrol lainnya yang ada sebelum konten utama laman.

Sebagai pengembang, kami dapat menyediakan "tautan lewati" di bagian atas setiap halaman di aplikasi kami untuk memungkinkan pengguna keyboard melewati elemen kontrol yang mendahului konten utama halaman. Tautan lewati biasanya disembunyikan dari tampilan hingga menerima fokus. Itu tidak terlihat oleh orang yang menggunakan mouse untuk berinteraksi dengan aplikasi Anda, tetapi itu akan menjadi elemen pertama yang menerima fokus bagi mereka yang menggunakan keyboard.

Saat tautan diklik, fokus beralih ke penampung konten utama, dan pengguna keyboard dapat langsung memulai tab melalui elemen kontrol utama di halaman.

Lewati tautan lebih dari sekadar pintasan yang nyaman. Itu adalah contoh blok bypass, yang diperlukan untuk memenuhi standar WCAG Level A.

Uji aplikasi Anda sesering mungkin dengan menjadi pengguna keyboard sendiri

Menguji aksesibilitas keyboard memiliki kurva belajar yang relatif lebih rendah untuk orang yang tidak terbiasa menggunakan teknologi atau perangkat bantu. Yang Anda butuhkan hanyalah akses ke keyboard, pemahaman tentang perilaku keyboard standar, dan akses ke mode kontras tinggi Windows (baik dengan membeli perangkat Windows atau menginstal mesin virtual).

Berikut adalah beberapa pertanyaan yang perlu diingat saat kami menguji aplikasi kami untuk aksesibilitas keyboard:

• Apakah saya dapat menggunakan keyboard saya untuk berinteraksi dengan apa pun yang merespons klik dan gerakan mouse?
• Adakah yang tahu cara berinteraksi dengan elemen ini saat menerima fokus?
• Apakah urutan fokus cocok dengan urutan visual elemen interaktif di halaman?
• Bisakah saya melacak elemen mana yang sedang dalam fokus, bahkan jika saya memerlukan kontras yang lebih tinggi antar warna?
• Bisakah saya mengakses konten utama halaman dengan mudah?

Menjawab "ya" untuk semua pertanyaan ini tidak memerlukan banyak usaha, dan dapat memberikan efek positif bagi pengguna dalam keadaan apa pun: apakah mereka memiliki cacat fisik, sedang mencari cara untuk menghemat waktu, atau perlu menggunakan komputer mereka dengan satu tangan.

Pengujian aksesibilitas adalah komponen penting dari pengembangan aplikasi. Secara khusus, aksesibilitas keyboard sama pentingnya dengan menyediakan teks alternatif untuk orang yang menggunakan pembaca layar, atau teks untuk orang yang tidak dapat mendengar konten audio. Pada akhirnya, kemampuan untuk menggunakan mouse tidak diperlukan untuk menggunakan aplikasi jika Anda ingin aplikasi Anda dapat diakses sepenuhnya.