Senarai semak ringkas dan berpendirian untuk butang web yang boleh diakses

Masalah dengan nasihat kebolehcapaian butang

Kebanyakan panduan kebolehcapaian butang terbahagi kepada dua kelompok: sama ada ia tafsiran WCAG setebal 40 halaman yang tiada siapa baca, atau cadangan kabur untuk "make buttons accessible" tanpa langkah yang boleh diambil tindakan. Kedua-duanya tidak membantu apabila anda perlu menghantar ciri pada hari Khamis.

Senarai semak ini merangkumi lima kegagalan kebolehcapaian butang paling lazim yang kami lihat dalam produksi. Ia tidak akan menjadikan anda pakar WCAG, tetapi ia akan menangkap masalah yang benar-benar memberi kesan kepada pengguna.

1. Gunakan elemen button untuk butang

Jika ia bertindak seperti butang, ia sepatutnya elemen <button>. Bukan <div> dengan onclick, bukan <span> dengan role="button", bukan <a> dengan href="#" dan preventDefault.

Elemen <button> memberi anda navigasi papan kekunci, pengurusan fokus, dan pengumuman pembaca skrin secara percuma. Apabila anda menggunakan <div>, anda membina semula semua itu dari awal — dan anda akan tersilap.

Satu-satunya pengecualian: jika tindakan itu menavigasi ke halaman baharu atau mengubah URL, gunakan elemen <a>. Pautan dan butang berbeza dari segi semantik. Pengguna pembaca skrin menavigasi mengikut jenis elemen, dan mereka menjangkakan butang melakukan tindakan serta pautan menavigasi.

2. Pastikan sasaran klik sekurang-kurangnya 44×44 piksel

WCAG 2.5.5 (Level AAA) menghendaki elemen interaktif mempunyai saiz sasaran minimum 44×44 piksel CSS. Ini bukan tentang saiz visual — ini tentang kawasan yang boleh diklik.

Anda boleh mempunyai butang visual yang kecil dengan padding yang mencukupi, atau anda boleh melanjutkan sasaran klik dengan pseudo-element. Yang penting ialah pengguna tidak perlu membidik dengan tepat.

Pengguna mudah alih, orang dengan ketidakupayaan motor, dan sesiapa yang menggunakan peranti ketika bergerak akan terlepas sasaran kecil. Butang ikon 24×24 piksel mungkin kelihatan kemas, tetapi ia satu kegagalan kebolehgunaan.

3. Sediakan keadaan fokus yang kelihatan dan bukan sekadar lalai pelayar

Gelang fokus lalai pelayar lebih baik daripada tiada apa-apa, tetapi ia tidak konsisten merentas pelayar dan sering tidak kelihatan pada latar tertentu. Anda memerlukan keadaan fokus tersuai yang berfungsi dalam sistem reka bentuk anda.

Penunjuk fokus yang baik mempunyai tiga kualiti:

• Kontras tinggi: sekurang-kurangnya 3:1 berbanding warna bersebelahan
• Ofset yang kelihatan: tidak tersembunyi oleh sempadan atau latar butang itu sendiri
• Bentuk yang konsisten: pengguna patut mengenalinya sebagai penunjuk fokus merentas antara muka anda

Jangan buang outline: none tanpa menggantikannya dengan sesuatu yang lebih baik. Dan jangan jadikan keadaan fokus begitu halus sehingga hanya anda boleh melihatnya dalam keadaan pencahayaan sempurna.

4. Tulis label butang yang masuk akal di luar konteks

Pengguna pembaca skrin sering menavigasi dengan melompat antara butang. Apabila mereka berbuat demikian, mereka mendengar senarai label butang tanpa konteks sekeliling.

Butang berlabel "Learn more" tidak berguna dalam senarai itu. Begitu juga "Click here" atau "Submit". Label perlu menerangkan tindakan: "Muat turun senarai semak kebolehcapaian", "Langgan kemas kini", "Padam komen ini".

Jika reka bentuk anda memerlukan label visual yang pendek, gunakan aria-label untuk menyediakan alternatif deskriptif. Tetapi penyelesaian yang lebih baik ialah menulis label yang berfungsi untuk semua orang.

Untuk butang ikon sahaja, aria-label adalah wajib. Butang dengan hanya ikon kaca pembesar memerlukan aria-label="Search" atau teks yang setara. Ikon tidak boleh diakses oleh pembaca skrin.

5. Pastikan kontras warna mencukupi

WCAG 2.1 menghendaki nisbah kontras sekurang-kurangnya 4.5:1 untuk teks biasa dan 3:1 untuk teks besar (18pt atau 14pt bold). Label butang biasanya teks biasa.

Teks kelabu muda pada butang putih gagal. Biru pucat pada latar biru muda gagal. Gabungan ini mungkin kelihatan sofistikated, tetapi ia mengecualikan pengguna dengan penglihatan rendah, buta warna, atau sesiapa yang melihat skrin di bawah cahaya matahari terang.

Gunakan penyemak kontras semasa reka bentuk, bukan selepas pelancaran. Membetulkan isu kontras dalam produksi mahal kerana ia sering memerlukan perubahan sistem reka bentuk.

Jika anda bekerja dengan alat pemprosesan imej, pemprosesan sisi klien boleh membantu memelihara privasi sambil menjana aset visual yang boleh diakses — khususnya apabila menguji gabungan warna atau menjana keadaan pratonton.

Perkara yang tidak dirangkumi senarai semak ini

Senarai ini sengaja tidak lengkap. Ia tidak merangkumi semantik keadaan dinyahdayakan, keadaan pemuatan, pengendalian ralat, atau corak butang kompleks seperti split buttons atau pencetus dropdown. Corak-corak itu memerlukan panduan tersendiri.

Ia juga tidak merangkumi persoalan yang lebih luas tentang bila untuk menggunakan butang berbanding elemen interaktif lain. Untuk itu, anda perlu memahami HTML semantik dan accessibility tree — topik yang wajar mempunyai artikel tersendiri.

Apa yang dirangkumi ialah perkara mudah yang paling kerap terlepas: kesilapan yang muncul dalam hampir setiap semakan kod, yang memberi kesan kepada paling ramai pengguna, dan yang paling mudah dibetulkan semasa pembangunan.

Cara mengintegrasikan ini ke dalam aliran kerja anda

Senarai semak kebolehcapaian hanya berfungsi jika ia menjadi sebahagian daripada proses pembangunan, bukan ditampal selepas itu. Berikut cara untuk menjadikannya berlaku:

Dalam reka bentuk: tambah keadaan fokus dan anotasi sasaran klik pada fail reka bentuk anda. Jangan biarkan perkara ini untuk diteka oleh pembangun.

Dalam semakan kod: semak elemen <button>, aria-label pada butang ikon, dan CSS keadaan fokus. Ini cepat dikesan.

Dalam ujian: tab melalui antara muka anda dengan papan kekunci. Jika anda tidak dapat mencapai butang atau tidak dapat melihat di mana fokus berada, pengguna anda juga tidak boleh.

Dalam dokumentasi: sertakan keperluan kebolehcapaian butang dalam pustaka komponen anda. Jadikan melakukan perkara yang betul lebih mudah daripada melakukan perkara yang salah.

Jika anda sedang menyahpepijat isu produksi, alat untuk memeriksa HTTP headers dan redirects boleh membantu anda memahami cara teknologi bantuan mentafsir markup anda — khususnya apabila menyelesaikan masalah pengurusan fokus selepas navigasi.

Kos melangkau kerja ini

Butang yang tidak boleh diakses bukan sekadar gagal pematuhan WCAG — ia memutuskan aliran kerja. Pengguna yang tidak boleh mengklik butang hantar tidak dapat melengkapkan borang. Pengguna yang tidak dapat melihat keadaan fokus tidak dapat menavigasi dengan papan kekunci. Pengguna yang tidak dapat membezakan teks butang daripada latar tidak dapat membaca label.

Ini bukan kes pinggiran. Kira-kira 15% populasi global mempunyai sesuatu bentuk ketidakupayaan, dan ketidakupayaan sementara (tetikus rosak, cahaya matahari terang, mendukung bayi) akhirnya memberi kesan kepada semua orang.

Berita baiknya ialah kebolehcapaian butang kebanyakannya terdiri daripada masalah yang sudah diselesaikan. Anda tidak perlu mencipta corak baharu atau menunggu sokongan pelayar. Anda hanya perlu menggunakan platform dengan betul dan menguji kerja anda.

Inti utama

• Gunakan elemen <button> untuk butang dan elemen <a> untuk navigasi — perbezaan semantik penting untuk teknologi bantuan
• Pastikan sasaran klik sekurang-kurangnya 44×44 piksel CSS untuk menampung ketidakupayaan motor dan pengguna mudah alih
• Sediakan keadaan fokus yang kelihatan, berkontras tinggi, dan berfungsi merentas sistem reka bentuk anda
• Tulis label butang yang masuk akal apabila dibaca secara berasingan, dan gunakan aria-label untuk butang ikon sahaja
• Semak kontras warna semasa reka bentuk, bukan selepas pelancaran, untuk mengelakkan baik pulih yang mahal

FAQ

Q: Bolehkah saya menggunakan role="button" pada <div> jika saya menambah pengendali papan kekunci?

A: Boleh, tetapi anda tidak patut. Anda perlu mengendalikan Enter, Space, pengurusan fokus, dan keadaan dinyahdayakan secara manual — dan anda pasti akan terlepas sesuatu. Elemen <button> melakukan semua ini dengan betul secara lalai. Gunakannya.

Q: Bagaimana dengan butang yang menukar keadaan, seperti butang play/pause?

A: Gunakan aria-pressed="true" atau aria-pressed="false" untuk menunjukkan keadaan semasa. Label butang juga perlu mencerminkan tindakan yang akan berlaku apabila diklik ("Pause" ketika sedang bermain, "Play" ketika dijeda), bukan keadaan semasa. Pengguna pembaca skrin perlu tahu apa yang akan dilakukan oleh butang, bukan keadaan sistem ketika itu.

Q: Adakah butang dinyahdayakan perlu memenuhi keperluan kontras?

A: WCAG 2.1 mengecualikan kawalan dinyahdayakan daripada keperluan kontras (1.4.3), tetapi perkara ini diperdebatkan. Butang dinyahdayakan dengan kontras rendah sukar dilihat oleh semua orang. Jika anda mahu memaparkan butang dinyahdayakan, pastikan ia boleh dibaca. Lebih baik lagi, sembunyikan atau terangkan sebab ia dinyahdayakan.

Q: Bagaimana saya menguji kebolehcapaian butang tanpa pembaca skrin?

A: Gunakan papan kekunci anda. Tab melalui antara muka dan sahkan bahawa anda boleh mencapai setiap butang, melihat di mana fokus berada, dan mengaktifkan butang dengan Enter atau Space. Ini menangkap kebanyakan masalah. Untuk ujian yang lebih mendalam, gunakan accessibility inspector dalam Chrome atau Firefox DevTools untuk menyemak role dan label yang dikira.

Q: Apakah perbezaan antara aria-label dan aria-labelledby?

A: aria-label menyediakan rentetan teks secara langsung. aria-labelledby merujuk ID elemen lain yang kandungan teksnya menjadi label. Gunakan aria-labelledby apabila teks label sudah wujud di tempat lain dalam DOM. Gunakan aria-label apabila anda perlu menyediakan label yang tidak kelihatan pada skrin.

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