Checklist singkat dan beropini untuk tombol web yang aksesibel

Masalah dengan saran aksesibilitas tombol

Sebagian besar panduan aksesibilitas tombol terbagi menjadi dua kubu: entah itu interpretasi WCAG setebal 40 halaman yang tidak dibaca siapa pun, atau saran samar untuk "membuat tombol aksesibel" tanpa langkah yang dapat ditindaklanjuti. Keduanya tidak membantu saat Anda harus merilis fitur pada hari Kamis.

Checklist ini mencakup lima kegagalan aksesibilitas tombol yang paling sering kami lihat di produksi. Ini tidak akan menjadikan Anda ahli WCAG, tetapi akan menangkap masalah yang benar-benar memengaruhi pengguna.

1. Gunakan elemen button untuk tombol

Jika berperilaku seperti tombol, seharusnya itu adalah elemen <button>. Bukan <div> dengan onclick, bukan <span> dengan role="button", bukan <a> dengan href="#" dan preventDefault.

Elemen <button> memberi Anda navigasi keyboard, manajemen fokus, dan pengumuman pembaca layar secara gratis. Saat Anda menggunakan <div>, Anda membangun ulang semua itu dari nol — dan Anda akan keliru.

Satu-satunya pengecualian: jika tindakan tersebut menavigasi ke halaman baru atau mengubah URL, gunakan elemen <a>. Tautan dan tombol berbeda secara semantik. Pengguna pembaca layar bernavigasi berdasarkan jenis elemen, dan mereka mengharapkan tombol untuk melakukan tindakan serta tautan untuk bernavigasi.

2. Buat target tekan setidaknya 44×44 piksel

WCAG 2.5.5 (Level AAA) mewajibkan elemen interaktif memiliki ukuran target minimum 44×44 piksel CSS. Ini bukan soal ukuran visual — ini soal area yang dapat diklik.

Anda dapat memiliki tombol visual yang kecil dengan padding yang memadai, atau Anda dapat memperluas target tekan dengan pseudo-element. Yang penting adalah pengguna tidak perlu membidik dengan sangat presisi.

Pengguna mobile, orang dengan gangguan motorik, dan siapa pun yang menggunakan perangkat saat bergerak akan meleset dari target kecil. Tombol ikon 24×24 piksel mungkin terlihat rapi, tetapi itu adalah kegagalan kegunaan.

3. Sediakan status fokus yang terlihat dan bukan sekadar default browser

Cincin fokus default browser lebih baik daripada tidak ada, tetapi tidak konsisten di berbagai browser dan sering kali tidak terlihat pada latar tertentu. Anda memerlukan status fokus kustom yang bekerja dalam design system Anda.

Indikator fokus yang baik memiliki tiga kualitas:

• Kontras tinggi: setidaknya 3:1 terhadap warna yang berdekatan
• Offset terlihat: tidak tersembunyi oleh border atau latar tombol itu sendiri
• Bentuk konsisten: pengguna harus mengenalinya sebagai indikator fokus di seluruh antarmuka Anda

Jangan menghapus outline: none tanpa menggantinya dengan sesuatu yang lebih baik. Dan jangan membuat status fokus begitu halus sehingga hanya Anda yang dapat melihatnya dalam kondisi pencahayaan sempurna.

4. Tulis label tombol yang tetap masuk akal di luar konteks

Pengguna pembaca layar sering bernavigasi dengan melompat dari satu tombol ke tombol lain. Saat melakukannya, mereka mendengar daftar label tombol tanpa konteks di sekitarnya.

Tombol berlabel "Pelajari selengkapnya" tidak berguna dalam daftar itu. Begitu juga "Klik di sini" atau "Kirim". Label harus mendeskripsikan tindakannya: "Unduh checklist aksesibilitas", "Berlangganan pembaruan", "Hapus komentar ini".

Jika desain Anda memerlukan label visual yang singkat, gunakan aria-label untuk menyediakan alternatif yang deskriptif. Namun solusi yang lebih baik adalah menulis label yang bekerja untuk semua orang.

Untuk tombol yang hanya berupa ikon, aria-label wajib. Tombol yang hanya berisi ikon kaca pembesar memerlukan aria-label="Search" atau teks yang setara. Ikon tidak aksesibel bagi pembaca layar.

5. Pastikan kontras warna mencukupi

WCAG 2.1 mewajibkan rasio kontras setidaknya 4.5:1 untuk teks normal dan 3:1 untuk teks besar (18pt atau 14pt bold). Label tombol biasanya berupa teks normal.

Teks abu-abu muda pada tombol putih gagal. Biru pucat pada latar biru muda gagal. Kombinasi ini mungkin terlihat canggih, tetapi mengecualikan pengguna dengan penglihatan rendah, buta warna, atau siapa pun yang melihat layar di bawah sinar matahari terang.

Gunakan contrast checker selama desain, bukan setelah peluncuran. Memperbaiki masalah kontras di produksi itu mahal karena sering kali memerlukan perubahan design system.

Jika Anda bekerja dengan alat pemrosesan gambar, pemrosesan sisi klien dapat membantu menjaga privasi saat menghasilkan aset visual yang aksesibel — terutama saat menguji kombinasi warna atau membuat status pratinjau.

Apa yang tidak dicakup checklist ini

Daftar ini sengaja tidak lengkap. Ini tidak mencakup semantik status nonaktif, status loading, penanganan error, atau pola tombol kompleks seperti split buttons atau dropdown triggers. Pola-pola tersebut memerlukan panduan tersendiri.

Ini juga tidak mencakup pertanyaan yang lebih luas tentang kapan menggunakan tombol dibanding elemen interaktif lain. Untuk itu, Anda perlu memahami HTML semantik dan accessibility tree — topik yang layak mendapatkan artikelnya sendiri.

Yang dicakup adalah hal-hal yang paling mudah diperbaiki: kesalahan yang muncul di hampir setiap code review, yang memengaruhi paling banyak pengguna, dan yang paling mudah diperbaiki selama pengembangan.

Cara mengintegrasikan ini ke dalam workflow Anda

Checklist aksesibilitas hanya bekerja jika menjadi bagian dari proses pengembangan, bukan ditempelkan setelahnya. Berikut cara mewujudkannya:

Dalam desain: tambahkan status fokus dan anotasi target tekan ke file desain Anda. Jangan biarkan developer menebaknya.

Dalam code review: periksa elemen <button>, aria-label pada tombol ikon, dan CSS status fokus. Ini cepat ditemukan.

Dalam pengujian: tab melalui antarmuka Anda dengan keyboard. Jika Anda tidak dapat mencapai tombol atau tidak dapat melihat di mana fokus berada, pengguna Anda juga tidak bisa.

Dalam dokumentasi: sertakan persyaratan aksesibilitas tombol di component library Anda. Buat tindakan yang benar lebih mudah dilakukan daripada tindakan yang salah.

Jika Anda sedang men-debug masalah produksi, alat untuk memeriksa HTTP headers dan redirects dapat membantu Anda memahami bagaimana assistive technologies menafsirkan markup Anda — terutama saat menelusuri masalah manajemen fokus setelah navigasi.

Biaya jika melewatkan pekerjaan ini

Tombol yang tidak aksesibel bukan hanya gagal memenuhi kepatuhan WCAG — tombol tersebut merusak workflow. Pengguna yang tidak dapat mengklik tombol submit tidak dapat menyelesaikan formulir. Pengguna yang tidak dapat melihat status fokus tidak dapat bernavigasi dengan keyboard. Pengguna yang tidak dapat membedakan teks tombol dari latarnya tidak dapat membaca label.

Ini bukan kasus pinggiran. Sekitar 15% populasi global memiliki suatu bentuk disabilitas, dan gangguan sementara (mouse rusak, sinar matahari terang, menggendong bayi) pada akhirnya memengaruhi semua orang.

Kabar baiknya, aksesibilitas tombol sebagian besar adalah masalah yang sudah terpecahkan. Anda tidak perlu menciptakan pola baru atau menunggu dukungan browser. Anda hanya perlu menggunakan platform dengan benar dan menguji pekerjaan Anda.

Poin utama

• Gunakan elemen <button> untuk tombol dan elemen <a> untuk navigasi — perbedaan semantik penting bagi assistive technology
• Pastikan target tekan setidaknya 44×44 piksel CSS untuk mengakomodasi gangguan motorik dan pengguna mobile
• Sediakan status fokus yang terlihat dan berkontras tinggi, yang bekerja di seluruh design system Anda
• Tulis label tombol yang masuk akal saat dibaca secara terpisah, dan gunakan aria-label untuk tombol yang hanya berupa ikon
• Periksa kontras warna selama desain, bukan setelah peluncuran, untuk menghindari retrofit yang mahal

FAQ

Q: Bisakah saya menggunakan role="button" pada <div> jika saya menambahkan keyboard handlers?

A: Bisa, tetapi sebaiknya jangan. Anda harus menangani Enter, Space, manajemen fokus, dan status nonaktif secara manual — dan Anda pasti akan melewatkan sesuatu. Elemen <button> melakukan semua ini dengan benar secara default. Gunakan itu.

Q: Bagaimana dengan tombol yang mengubah status, seperti tombol play/pause?

A: Gunakan aria-pressed="true" atau aria-pressed="false" untuk menunjukkan status saat ini. Label tombol juga harus mencerminkan tindakan yang akan terjadi saat diklik ("Jeda" saat sedang diputar, "Putar" saat dijeda), bukan status saat ini. Pengguna pembaca layar perlu mengetahui apa yang akan dilakukan tombol, bukan status sistem saat ini.

Q: Apakah tombol nonaktif harus memenuhi persyaratan kontras?

A: WCAG 2.1 mengecualikan kontrol nonaktif dari persyaratan kontras (1.4.3), tetapi ini kontroversial. Tombol nonaktif dengan kontras buruk sulit dikenali oleh semua orang. Jika Anda akan menampilkan tombol nonaktif, buatlah tetap terbaca. Lebih baik lagi, sembunyikan atau jelaskan mengapa tombol tersebut nonaktif.

Q: Bagaimana saya menguji aksesibilitas tombol tanpa pembaca layar?

A: Gunakan keyboard Anda. Tab melalui antarmuka dan verifikasi bahwa Anda dapat mencapai setiap tombol, melihat di mana fokus berada, dan mengaktifkan tombol dengan Enter atau Space. Ini menangkap sebagian besar masalah. Untuk pengujian yang lebih mendalam, gunakan accessibility inspector di Chrome atau Firefox DevTools untuk memeriksa role dan label yang dihitung.

Q: Apa perbedaan antara aria-label dan aria-labelledby?

A: aria-label menyediakan string teks secara langsung. aria-labelledby merujuk ke ID elemen lain yang konten teksnya menjadi label. Gunakan aria-labelledby ketika teks label sudah ada di tempat lain dalam DOM. Gunakan aria-label ketika Anda perlu menyediakan label yang tidak terlihat di layar.

Sumber

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM