Membuat butang kurang upaya lebih inklusif

Mari bercakap mengenai butang kurang upaya. Khususnya, mari kita masuk ke dalam mengapa kita menggunakannya dan bagaimana kita boleh melakukan lebih baik daripada atribut kurang upaya tradisional dalam HTML (contohnya ) untuk menandakan butang sebagai dilumpuhkan.

Terdapat banyak kes penggunaan di mana butang kurang upaya membuat banyak akal, dan kami akan mendapat alasan tersebut dalam seketika. Tetapi sepanjang artikel ini, kami akan melihat bentuk yang membolehkan kami menambah beberapa tiket ke keranjang belanja.

Ini adalah contoh asas yang baik kerana terdapat situasi yang jelas untuk melumpuhkan butang "Tambah ke Cart": apabila tidak ada tiket untuk ditambah ke kereta.

Tetapi pertama, mengapa butang kurang upaya?

Mencegah orang daripada melakukan tindakan yang tidak sah atau tidak tersedia adalah sebab yang paling biasa kita dapat mencapai butang kurang upaya. Dalam demo di bawah, kita hanya boleh menambah tiket jika bilangan tiket yang ditambah ke kereta lebih besar daripada sifar. Cubalah:

Izinkan saya melangkau penjelasan kod dalam demo ini dan tumpukan perhatian kami pada apa yang penting: butang "Tambah ke Troli".

 <button type="Hantar" dilumpuhkan="Dilumpuhkan">
  Tambah ke kereta
</button>

Butang ini dilumpuhkan oleh atribut kurang upaya. (Perhatikan bahawa ini adalah atribut Boolean, yang bermaksud bahawa ia boleh ditulis sebagai dilumpuhkan atau dilumpuhkan = "dilumpuhkan".)

Semuanya kelihatan baik ... jadi apa yang salah dengannya?

Nah, jujur, saya boleh mengakhiri artikel di sini meminta anda untuk tidak menggunakan butang kurang upaya kerana mereka menghisap, dan sebaliknya menggunakan corak yang lebih baik. Tetapi mari kita realistik: kadang -kadang melumpuhkan butang adalah penyelesaian yang paling masuk akal.

Dengan itu dikatakan, untuk tujuan demo ini, kami akan berpura -pura melumpuhkan butang "Tambah ke Troli" adalah penyelesaian terbaik ( Spoiler Alert: tidak). Kita masih boleh menggunakannya untuk mengetahui bagaimana ia berfungsi dan meningkatkan kebolehgunaannya di sepanjang jalan.

Jenis interaksi

Saya ingin menjelaskan apa yang saya maksudkan dengan butang kurang upaya yang boleh digunakan. Anda mungkin berfikir, jika butang dilumpuhkan, ia tidak boleh digunakan, jadi ... apa tangkapan? Beruang dengan saya.

Di web, terdapat pelbagai cara untuk berinteraksi dengan halaman. Menggunakan tetikus adalah salah satu yang paling biasa, tetapi ada yang lain, seperti orang yang melihat keyboard untuk menavigasi kerana gangguan motor.

Cuba untuk menavigasi demo di atas menggunakan hanya kekunci tab untuk maju dan pergeseran tab untuk pergi ke belakang. Anda akan melihat bagaimana butang kurang upaya dilangkau. Fokus berjalan terus dari input tiket ke pautan "Dummy Syarat".

Mari kita berhenti sejenak dan merakam sebab yang membawa kita untuk melumpuhkan butang di tempat pertama berbanding apa yang telah kita lakukan.

Adalah biasa untuk mengaitkan "berinteraksi" dengan "mengklik" tetapi mereka adalah dua konsep yang berbeza. Ya, C Lick adalah sejenis interaksi, tetapi ia hanya satu antara lain, seperti hover dan fokus.

Dengan kata lain ...

Semua klik adalah interaksi, tetapi tidak semua interaksi adalah klik.

Matlamat kami adalah untuk mengelakkan klik, tetapi dengan menggunakan orang kurang upaya, kami menghalang bukan sahaja klik, tetapi juga fokus, yang bermaksud kami mungkin melakukan banyak bahaya yang baik. Pasti, tingkah laku ini mungkin kelihatan tidak berbahaya, tetapi ia menyebabkan kekeliruan. Orang yang mempunyai kecacatan kognitif mungkin berjuang untuk memahami mengapa mereka tidak dapat memfokuskan butang tersebut.

Dalam demo berikut, kami tweak susun atur sedikit. Jika anda menggunakan tetikus, dan hover ke atas butang hantar, petua alat ditunjukkan menjelaskan mengapa butang dilumpuhkan. Itu hebat!

Tetapi jika anda hanya menggunakan papan kekunci, tidak ada cara untuk melihat petua alat itu kerana butang tidak dapat difokuskan dengan orang kurang upaya. Perkara yang sama berlaku dalam peranti sentuhan juga. Aduh!

Izinkan saya sekali lagi melangkaui penjelasan kod. Saya sangat mengesyorkan membaca "Tooltips Inclusive" oleh Haydon Pickering dan "Tooltips pada Masa WCAG 2.1" oleh Sarah Higley untuk memahami sepenuhnya corak tooltip.

Aria untuk menyelamatkan

Atribut yang kurang upaya dalam melakukan lebih daripada yang diperlukan. Ini adalah salah satu daripada beberapa kes yang saya tahu di mana atribut HTML asli boleh melakukan lebih banyak kemudaratan daripada yang baik. Menggunakan atribut ARIA boleh melakukan pekerjaan yang lebih baik, membolehkan kami mengarahkan pembaca skrin bagaimana untuk mentafsirkan butang, tetapi berbuat demikian secara konsisten untuk mencipta pengalaman inklusif untuk lebih ramai orang dan menggunakan kes -kes.

Atribut yang dilumpuhkan berkorelasi kepada aria-disabled = "true". Berikan demo berikut, cuba, sekali lagi, hanya menggunakan papan kekunci. Perhatikan bagaimana butang, walaupun ditandakan dilumpuhkan, masih boleh diakses oleh fokus dan mencetuskan tooltip!

Sejuk, ya? Tweak kecil seperti itu untuk peningkatan yang besar!

Tetapi kita belum selesai. Kaveat di sini adalah bahawa kita masih perlu menghalang klik secara programatik, menggunakan JavaScript.

 elform.addeventListener ('hantar', fungsi (acara) {
  event.PreventDefault (); / * Mencegah borang asli mengemukakan */

  const isDisabled = elButtonSubmit.getAttribute ('aria-disabled') === 'true';

  jika (isDisabled || issubmitting) {
    // kembali lebih awal untuk mengelakkan tiket daripada ditambah
    kembali;
  }

  issubmitting = true;
  // ... kod untuk menambah kereta ...
  issubMitting = false;
})

Anda mungkin akrab dengan corak ini sebagai cara untuk mengelakkan klik dua kali dari menyerahkan borang dua kali. Jika anda menggunakan atribut yang kurang upaya untuk sebab itu, saya lebih suka tidak melakukannya kerana menyebabkan kehilangan sementara fokus papan kekunci semasa borang diserahkan.

Perbezaan antara orang kurang upaya dan disatukan aria

Anda mungkin bertanya: Jika Aria-disabled tidak menghalang klik secara lalai, apakah gunanya menggunakannya? Untuk menjawabnya, kita perlu memahami perbezaan antara kedua -dua atribut:

Satu -satunya pertindihan antara kedua -duanya adalah semantik. Kedua -dua atribut akan mengumumkan bahawa butang itu memang dilumpuhkan, dan itu satu perkara yang baik.

Bertentangan dengan atribut yang kurang upaya, Aria-disabled adalah semua tentang semantik. Atribut ARIA tidak pernah mengubah tingkah laku aplikasi atau gaya secara lalai. Tujuan satu -satunya adalah untuk membantu teknologi bantuan (contohnya pembaca skrin) untuk mengumumkan kandungan halaman dengan cara yang lebih bermakna dan teguh.

Setakat ini, kami telah bercakap tentang dua jenis orang, mereka yang mengklik dan mereka yang tab. Sekarang mari kita bercakap tentang jenis lain: mereka yang mengalami masalah visual (contohnya kebutaan, penglihatan rendah) yang menggunakan pembaca skrin untuk menavigasi web.

Orang yang menggunakan pembaca skrin, sering lebih suka menavigasi medan borang menggunakan kekunci Tab . Sekarang lihat bagaimana suara pada macOS melangkau butang kurang upaya.

Sekali lagi, ini adalah bentuk yang sangat minimum. Dalam yang lebih lama, mencari butang hantar yang tidak ada di sana boleh menjengkelkan. Bayangkan borang di mana butang hantar tersembunyi dan hanya dapat dilihat apabila anda mengisi borang sepenuhnya. Itulah yang dirasakan oleh sesetengah orang ketika atribut kurang upaya digunakan.

Nasib baik, butang dengan orang kurang upaya tidak dapat dicapai sepenuhnya oleh pembaca skrin. Anda masih boleh menavigasi setiap elemen secara individu, satu demi satu, dan akhirnya anda akan menemui butang tersebut.

Walaupun mungkin, ini adalah pengalaman yang menjengkelkan. Sebaliknya, dengan Aria-Disabled, pembaca skrin akan memfokuskan butang secara normal dan betul mengumumkan statusnya. Perhatikan bahawa pengumuman itu sedikit berbeza antara pembaca skrin. Sebagai contoh, NVDA dan JWAS mengatakan "butang, tidak tersedia" tetapi Voiceover mengatakan "butang, redup."

Saya telah memetakan bagaimana kedua -dua atribut mencipta pengalaman pengguna yang berbeza berdasarkan alat yang kami gunakan:

Jadi, perbezaan utama antara kedua -dua atribut adalah:

• Dilumpuhkan mungkin melangkau butang apabila menggunakan kekunci Tab, yang membawa kepada kekeliruan.
• Aria-disabled masih akan memfokuskan butang dan mengumumkan bahawa ia wujud, tetapi ia belum diaktifkan; Dengan cara yang sama, anda mungkin melihatnya secara visual.

Ini adalah kes di mana penting untuk mengakui perbezaan halus antara kebolehcapaian dan kebolehgunaan. Kebolehcapaian adalah ukuran seseorang yang dapat menggunakan sesuatu. Kebolehgunaan adalah ukuran betapa mudahnya sesuatu yang digunakan.

Memandangkan itu, dilumpuhkan boleh diakses? Ya . Adakah ia mempunyai kebolehgunaan yang baik? Saya tidak fikir begitu .

Bolehkah kita melakukan yang lebih baik?

Saya tidak akan berasa baik dengan diri saya jika saya selesai artikel ini tanpa menunjukkan penyelesaian inklusif sebenar untuk contoh borang tiket kami. Sekiranya mungkin, jangan gunakan butang kurang upaya . Biarkan orang mengklik pada bila -bila masa dan, jika perlu, tunjukkan mesej ralat sebagai maklum balas. Pendekatan ini juga menyelesaikan masalah lain:

• Kurang geseran kognitif: Benarkan orang mengemukakan borang pada bila -bila masa. Ini menghilangkan ketidakpastian sama ada butang itu dilumpuhkan di tempat pertama.
• Kontras warna: Walaupun butang kurang upaya tidak perlu memenuhi kontras warna WCAG 1.4.3, saya percaya kita harus menjamin bahawa elemen sentiasa kelihatan dengan baik tanpa mengira keadaannya. Tetapi itu sesuatu yang kita tidak perlu risau sekarang kerana butang itu tidak dilumpuhkan lagi.

Pemikiran terakhir

Atribut yang kurang upaya dalam adalah kes aneh di mana, walaupun sangat dikenali oleh masyarakat, ia mungkin bukan pendekatan terbaik untuk menyelesaikan masalah tertentu. Jangan salahkan saya kerana saya tidak mengatakan orang kurang upaya selalu buruk. Masih terdapat beberapa kes di mana ia masih masuk akal untuk menggunakannya (contohnya penomboran).

Sejujurnya, saya tidak melihat atribut kurang upaya tepat sebagai isu aksesibiliti. Apa yang membimbangkan saya adalah lebih banyak isu kebolehgunaan. Dengan menukar atribut kurang upaya dengan Aria-disabled, kita boleh membuat pengalaman seseorang lebih menyeronokkan.

Ini adalah satu lagi langkah ke dalam perjalanan saya di akses web. Selama bertahun -tahun, saya dapati bahawa kebolehcapaian lebih daripada mematuhi piawaian web. Berurusan dengan pengalaman pengguna adalah rumit dan kebanyakan situasi memerlukan membuat perdagangan dan kompromi dalam cara kita mendekati penyelesaian. Tidak ada peluru perak untuk akses yang sempurna.

Kewajipan kami sebagai pencipta web adalah untuk mencari dan memahami penyelesaian yang berbeza yang tersedia. Hanya dengan itu kita boleh membuat pilihan terbaik. Tidak masuk akal dalam berpura -pura masalah tidak wujud.

Pada penghujung hari, ingatlah bahawa tidak ada yang menghalang anda daripada membuat web tempat yang lebih inklusif.

Bonus

Masih ada? Izinkan saya menyebut dua perkara terakhir mengenai demo ini yang saya rasa layak:

1. Kawasan hidup akan mengumumkan kandungan dinamik

Dalam demo, dua bahagian kandungan berubah secara dinamik: butang hantar borang dan pengesahan kejayaan ("tambah [x] tiket!").

Perubahan ini secara visual dirasakan, bagaimanapun, bagi orang yang mengalami masalah penglihatan menggunakan pembaca skrin, yang bukan realiti. Untuk menyelesaikannya, kita perlu mengubah mesej tersebut ke kawasan hidup. Mereka membenarkan teknologi bantuan untuk mendengar perubahan dan mengumumkan mesej yang dikemas kini apabila ia berlaku.

Terdapat kelas .SR sahaja dalam demo yang menyembunyikan yang mengandungi mesej pemuatan, tetapi membolehkannya diumumkan oleh pembaca skrin. Dalam kes ini, aria-live = "tegas" digunakan untuk dan ia memegang mesej yang bermakna selepas borang diserahkan dan sedang dalam proses pemuatan. Dengan cara ini, kita boleh mengumumkan kepada pengguna bahawa borang itu berfungsi dan bersabar kerana ia memuatkan. Di samping itu, kami melakukan perkara yang sama dengan elemen maklum balas bentuk.

 <button type="Hantar" aria-disabled="true">
  Tambah ke kereta
  <span aria-live="assertve">
     
  </span>


<p aria-live="assertve">
  
</p></button>

Perhatikan bahawa atribut Aria-Live mesti hadir di dalam DOM dari awal, walaupun elemen itu tidak memegang sebarang mesej, jika tidak, teknologi bantuan mungkin tidak berfungsi dengan baik.

Lebih banyak lagi untuk memberitahu anda tentang atribut Aria-Live kecil ini dan perkara-perkara besar yang dilakukannya. Terdapat juga gotchas. Sebagai contoh, jika ia digunakan secara tidak betul, atribut itu boleh melakukan lebih banyak kemudaratan daripada yang baik. Ia patut dibaca "Menggunakan Aria-Live" oleh Ire Aderinokun dan "Skeleton Memuatkan" Adrian Roselli untuk lebih memahami bagaimana ia berfungsi dan cara menggunakannya.

2. Jangan gunakan peristiwa penunjuk untuk mengelakkan klik

Ini adalah pelaksanaan alternatif (dan tidak betul) yang saya lihat di seluruh web. Ini menggunakan penunjuk-acara: Tiada; Dalam CSS untuk mengelakkan klik (tanpa sebarang atribut HTML). Tolong, jangan buat ini. Inilah pen hodoh yang diharapkan akan menunjukkan mengapa. Saya ulangi, jangan buat ini.

Walaupun CSS memang menghalang klik tetikus, ingatlah bahawa ia tidak akan menghalang fokus dan navigasi papan kekunci, yang boleh menyebabkan hasil yang tidak dijangka atau, lebih buruk lagi, pepijat.

Dalam erti kata lain, menggunakan peraturan CSS ini sebagai strategi untuk mengelakkan satu klik, tidak ada gunanya (mendapatkannya?). ;)

Atas ialah kandungan terperinci Membuat butang kurang upaya lebih inklusif. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!