Panduan pembangun untuk label ARIA yang benar-benar membantu

Label ARIA adalah untuk nama, bukan permohonan maaf

ARIA berguna, tetapi ia sering digunakan sebagai tampalan untuk HTML yang tidak jelas. Di situlah pasukan mula menghadapi masalah.

Contoh paling biasa ialah aria-label. Ia nampak tidak berbahaya: tambah rentetan, puaskan linter, teruskan kerja. Tetapi nama boleh akses bukan hiasan. Ia ialah nama yang banyak teknologi bantuan paparkan kepada pengguna apabila mereka menavigasi mengikut butang, pautan, medan borang, tajuk, mercu tanda, dan kawalan.

Jika nama itu kabur, berulang, lapuk, atau berbeza daripada label yang kelihatan, antara muka menjadi lebih sukar digunakan. Kadangkala lebih buruk: aria-label boleh mengatasi teks yang lebih baik yang sudah wujud dalam DOM.

Matlamatnya bukan untuk menambah lebih banyak ARIA. Matlamatnya adalah untuk menjadikan nama, peranan, keadaan, dan tujuan setiap elemen antara muka jelas.

Nama boleh akses, dalam bahasa mudah

Kebanyakan elemen interaktif mempunyai nama boleh akses. Pembaca skrin menggunakan nama itu untuk mengumumkan apakah elemen tersebut.

Contohnya:

<button>Save changes</button>

Pembaca skrin boleh mengumumkan sesuatu seperti: “Save changes, button.” Peranan datang daripada elemen button natif. Nama datang daripada teks di dalamnya.

Itulah kes yang ideal: teks kelihatan dan nama boleh akses sepadan.

Atribut pelabelan ARIA menjadi berguna apabila antara muka yang kelihatan tidak menyediakan nama yang lengkap, atau apabila nama mesti datang daripada elemen lain. Atribut utama ialah:

• aria-label: menyediakan rentetan secara langsung pada elemen.
• aria-labelledby: menunjuk kepada satu atau lebih elemen yang teksnya menjadi nama.
• aria-describedby: menunjuk kepada teks penerangan sokongan, bukan nama utama.

Ketiga-tiganya berkaitan, tetapi tidak boleh ditukar ganti.

Peraturan pertama: utamakan HTML natif dan label yang kelihatan

Jika anda boleh meletakkan teks yang kelihatan pada kawalan, lakukan itu dahulu.

Ini lebih baik:

<button>Delete invoice</button>

Daripada ini:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Corak kedua sah untuk butang ikon sahaja. Tetapi jika reka bentuk boleh menerima teks yang kelihatan, teks yang kelihatan membantu semua orang: pengguna pembaca skrin, pengguna pengecaman pertuturan, orang yang menanggung beban kognitif, orang yang mengimbas dengan cepat, dan orang yang menggunakan alat terjemahan.

Ini ialah tema berulang dalam kerja kebolehcapaian. HTML natif dan affordance yang kelihatan menyelesaikan lebih banyak masalah berbanding metadata tersembunyi. Prinsip yang sama terpakai kepada semantik butang secara lebih luas; jika pasukan anda sedang mengaudit kawalan UI, senarai semak untuk butang web boleh akses kami ialah pendamping yang baik untuk panduan ini.

Bila aria-label ialah alat yang tepat

Gunakan aria-label apabila elemen memerlukan nama boleh akses dan tiada teks kelihatan yang sesuai untuk dirujuk.

Kes klasik ialah butang ikon sahaja:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Ini munasabah. Ikon yang kelihatan mencadangkan carian, tetapi laluan SVG itu sendiri tidak menyediakan nama yang boleh dipercayai. aria-label membekalkan nama tersebut.

Kes baik yang lain termasuk:

• Butang tutup yang diwakili hanya oleh “X”.
• Mercu tanda navigasi yang memerlukan nama yang lebih khusus, seperti aria-label="Product".
• Kawalan berulang yang konteks kelihatannya bukan sebahagian daripada teks butang.

Contohnya:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Kedua-duanya ialah mercu tanda navigasi, tetapi labelnya membantu pengguna membezakannya apabila bergerak mengikut mercu tanda.

Bila aria-label ialah alat yang salah

Jangan tambah aria-label hanya kerana ujian mengatakan sesuatu elemen memerlukan label. Betulkan markup dahulu.

Tidak baik:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Lebih baik:

<button>Submit</button>

Contoh pertama mencipta kerja yang tidak perlu. Kini anda perlu mencipta semula tingkah laku papan kekunci, keadaan dinyahdayakan, tingkah laku borang, dan jangkaan yang sudah disediakan oleh butang natif.

Elakkan juga menggunakan aria-label untuk menamakan semula teks yang kelihatan dengan cara yang mengubah makna.

<button aria-label="Delete invoice">Remove</button>

Ini kelihatan kecil, tetapi ia boleh mengelirukan pengguna yang bergantung pada input pertuturan. Jika butang yang kelihatan menyatakan “Remove,” tetapi nama boleh aksesnya ialah “Delete invoice,” pengguna yang cuba menyebut “click Remove” mungkin tidak mendapat hasil yang dijangka. Keperluan “label dalam nama” WCAG wujud tepat atas sebab ini: teks yang kelihatan secara umumnya harus terkandung dalam nama boleh akses.

Versi yang lebih baik:

<button aria-label="Remove invoice">Remove</button>

Selalunya lebih baik lagi:

<button>Remove invoice</button>

Gunakan aria-labelledby apabila teks kelihatan sudah wujud

Jika teks label sudah ada pada halaman, aria-labelledby biasanya lebih baik daripada aria-label.

Contoh:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Nama boleh akses seksyen itu kini datang daripada tajuk yang kelihatan. Anda mengelakkan penduaan rentetan, yang mengurangkan kesilapan terjemahan dan label lapuk.

Ini amat berguna untuk kumpulan borang:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

Dalam banyak kes, legend natif sudah memadai tanpa ARIA. Perkara utamanya ialah label yang kelihatan harus memimpin. ARIA harus menghubungkan makna sedia ada, bukan mencipta versi peribadi kedua untuknya.

Gunakan aria-describedby untuk teks bantuan, bukan nama

Penerangan bukan label.

Pertimbangkan medan ini:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Nama boleh akses ialah “Password.” Penerangannya ialah “Use at least 12 characters.” Pembaca skrin mungkin mengumumkan kedua-duanya, tetapi kedua-duanya mempunyai tujuan berbeza.

Jangan lakukan ini:

<input type="password" aria-label="Use at least 12 characters">

Itu menamakan medan berdasarkan arahan, bukan konsep. Pengguna yang menavigasi borang mahu tahu dahulu apakah medan itu, kemudian kekangan apa yang terpakai.

Perbezaan ini juga penting dalam keadaan ralat:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Label kekal stabil. Mesej ralat menjadi konteks sokongan.

Kawalan berulang memerlukan nama unik

Senarai dan kad ialah tempat label ARIA sering menjadi perlu.

Tidak baik:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Pengguna pembaca skrin yang menavigasi mengikut butang mungkin mendengar “Delete, button” tiga kali tanpa konteks.

Baik:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Ini ialah penggunaan aria-label yang sah: teks yang kelihatan kekal ringkas, manakala nama boleh akses memasukkan objeknya.

Tetapi gunakan corak ini dengan berhati-hati. Jika nama objek kelihatan berdekatan, aria-labelledby mungkin lebih mudah diselenggara:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Nama boleh akses menjadi “Delete Q4 revenue.” Ini mengelakkan penduaan tajuk laporan dalam atribut.

Jangan labelkan semuanya

Bukan setiap elemen memerlukan label ARIA.

Teks statik biasanya tidak memerlukannya. Ikon hiasan tidak memerlukannya. Bekas tidak memerlukannya, melainkan ia mempunyai mercu tanda atau peranan widget yang bermakna. Pelabelan berlebihan boleh menjadikan halaman bising dan lebih sukar dinavigasi.

Untuk imej, gunakan model khusus imej: imej bermakna memerlukan alt yang berguna; imej hiasan memerlukan alt="" kosong. Jangan gunakan label ARIA sebagai pengganti teks imej yang baik. Jika pasukan anda mencampuradukkan konsep ini, semak semula teks alt imej yang pragmatik dan asingkan alternatif imej daripada nama kawalan.

Kesilapan biasa ialah memberikan aria-label kepada setiap SVG. Jika SVG berada di dalam butang dan butang itu sudah mempunyai nama, ikon biasanya harus disembunyikan daripada teknologi bantuan:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Jika tidak, pengguna mungkin mendengar pengumuman yang berulang atau pelik bergantung pada gabungan pelayar dan teknologi bantuan.

Semak nama yang dikira, bukan hanya kod

Pepijat kebolehcapaian sering terlepas semakan kod kerana markup kelihatan munasabah.

Alat pembangun pelayar moden boleh menunjukkan pepohon kebolehcapaian yang dikira. Dalam Chrome, Edge, Firefox, dan Safari, periksa elemen dan cari maklumat kebolehcapaian seperti peranan, nama, dan penerangan. Anda sedang menyemak tiga perkara:

1. Adakah peranannya seperti yang anda jangkakan?
2. Adakah nama boleh akses jelas dan khusus?
3. Adakah penerangan membantu tanpa menggantikan nama?

Kemudian uji beberapa aliran dengan pembaca skrin sebenar. Anda tidak perlu menjadi pakar teknologi bantuan sepenuh masa untuk menangkap perkara asas. Pada macOS, VoiceOver terbina dalam. Pada Windows, NVDA digunakan secara meluas dan percuma. Pada mudah alih, uji dengan VoiceOver pada iOS dan TalkBack pada Android jika relevan.

Alat automatik berguna, tetapi ia tidak boleh menentukan dengan boleh dipercayai sama ada “Open,” “Read more,” atau “Delete” mempunyai konteks yang mencukupi. Anggap automasi sebagai jaring, bukan hakim. Ini serupa dengan pengauditan prestasi: laporan boleh menunjukkan kawasan yang mencurigakan, tetapi anda masih perlu mentafsir impaknya. Pendekatan tenang yang sama yang kami cadangkan untuk membaca laporan Lighthouse tanpa panik terpakai di sini.

Senarai semak praktikal untuk semakan

Sebelum menghantar label ARIA, tanya:

• Bolehkah ini menjadi HTML natif sebaliknya?
• Adakah terdapat teks yang kelihatan yang harus digunakan sebagai label?
• Jika teks yang kelihatan wujud, adakah nama boleh akses memasukkannya?
• Adakah kawalan berulang unik apabila dinavigasi di luar konteks visual?
• Adakah teks bantuan disambungkan dengan aria-describedby, bukan dipaksa masuk ke dalam label?
• Adakah ikon hiasan disembunyikan daripada teknologi bantuan?
• Sudahkah seseorang menyemak nama kebolehcapaian yang dikira dalam alat pembangun pelayar?
• Sudahkah sekurang-kurangnya satu laluan pembaca skrin sebenar dilakukan untuk aliran kritikal?

Senarai semak ini menangkap kebanyakan masalah label sebelum ia menjadi masalah pengguna.

Disiplin senyap ARIA yang baik

Kerja ARIA yang baik jarang dramatik. Kebanyakannya ialah sikap menahan diri.

Gunakan butang sebenar. Gunakan label sebenar. Pastikan nama yang kelihatan dan nama boleh akses sejajar. Tambah aria-label hanya apabila tiada sumber kelihatan yang lebih baik. Gunakan aria-labelledby apabila halaman sudah mengandungi teks yang betul. Gunakan aria-describedby untuk arahan sokongan dan ralat.

Platform web memberikan banyak perkara secara percuma kepada pembangun apabila kita menggunakannya secara langsung. ARIA wujud untuk jurang. Kemahirannya ialah mengetahui bila jurang itu benar-benar wujud.