Panduan developer untuk label ARIA yang benar-benar membantu

Label ARIA adalah untuk nama, bukan permintaan maaf

ARIA berguna, tetapi sering digunakan sebagai tambalan untuk HTML yang tidak jelas. Di situlah tim mulai mendapat masalah.

Contoh paling umum adalah aria-label. Kelihatannya tidak berbahaya: tambahkan string, penuhi linter, lalu lanjut. Namun nama yang aksesibel bukan dekorasi. Itu adalah nama yang diekspos banyak teknologi asistif kepada pengguna saat mereka menavigasi tombol, tautan, field formulir, heading, landmark, dan kontrol.

Jika nama itu kabur, duplikatif, kedaluwarsa, atau berbeda dari label yang terlihat, antarmuka menjadi lebih sulit digunakan. Kadang lebih buruk: aria-label dapat menimpa teks yang lebih baik yang sudah ada di DOM.

Tujuannya bukan menambahkan lebih banyak ARIA. Tujuannya adalah membuat nama, peran, status, dan tujuan setiap elemen antarmuka menjadi jelas.

Nama yang aksesibel, dalam bahasa sederhana

Sebagian besar elemen interaktif memiliki nama yang aksesibel. Screen reader menggunakan nama itu untuk mengumumkan apa elemen tersebut.

Contoh:

<button>Save changes</button>

Screen reader dapat mengumumkan sesuatu seperti: “Save changes, tombol.” Perannya berasal dari elemen native button. Namanya berasal dari teks di dalamnya.

Itulah kasus ideal: teks yang terlihat dan nama yang aksesibel cocok.

Atribut pelabelan ARIA menjadi berguna ketika antarmuka yang terlihat tidak menyediakan nama yang lengkap, atau ketika nama harus berasal dari elemen lain. Atribut utamanya adalah:

• aria-label: menyediakan string langsung pada elemen.
• aria-labelledby: menunjuk ke satu atau beberapa elemen yang teksnya menjadi nama.
• aria-describedby: menunjuk ke teks deskripsi pendukung, bukan nama utama.

Ketiganya saling berkaitan, tetapi tidak dapat dipertukarkan.

Aturan pertama: utamakan HTML native dan label yang terlihat

Jika Anda bisa menaruh teks yang terlihat pada kontrol, lakukan itu terlebih dahulu.

Ini lebih baik:

<button>Delete invoice</button>

Daripada ini:

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

Pola kedua valid untuk tombol yang hanya berisi ikon. Namun jika desain dapat menerima teks yang terlihat, teks yang terlihat membantu semua orang: pengguna screen reader, pengguna pengenalan suara, orang dengan beban kognitif, orang yang memindai dengan cepat, dan orang yang menggunakan alat penerjemah.

Ini adalah tema berulang dalam pekerjaan aksesibilitas. HTML native dan affordance yang terlihat menyelesaikan lebih banyak masalah daripada metadata tersembunyi. Prinsip yang sama berlaku untuk semantik tombol secara lebih luas; jika tim Anda sedang mengaudit kontrol UI, checklist untuk tombol web yang aksesibel kami adalah pendamping yang baik untuk panduan ini.

Kapan aria-label adalah alat yang tepat

Gunakan aria-label ketika sebuah elemen membutuhkan nama yang aksesibel dan tidak ada teks terlihat yang cocok untuk dirujuk.

Kasus klasiknya adalah tombol yang hanya berisi ikon:

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

Ini masuk akal. Ikon yang terlihat menyiratkan pencarian, tetapi path SVG itu sendiri tidak menyediakan nama yang andal. aria-label menyediakannya.

Kasus baik lainnya meliputi:

• Tombol tutup yang hanya direpresentasikan oleh “X”.
• Landmark navigasi yang membutuhkan nama lebih spesifik, seperti aria-label="Product".
• Kontrol berulang ketika konteks yang terlihat bukan bagian dari teks tombol.

Contoh:

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

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

Keduanya adalah landmark navigasi, tetapi labelnya membantu pengguna membedakannya saat berpindah berdasarkan landmark.

Kapan aria-label adalah alat yang salah

Jangan menambahkan aria-label hanya karena sebuah pengujian mengatakan elemen membutuhkan label. Perbaiki markup terlebih dahulu.

Buruk:

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

Lebih baik:

<button>Submit</button>

Contoh pertama menciptakan pekerjaan yang tidak perlu. Anda sekarang harus menciptakan ulang perilaku keyboard, status disabled, perilaku formulir, dan ekspektasi yang sudah disediakan tombol native.

Hindari juga penggunaan aria-label untuk menamai ulang teks yang terlihat dengan cara yang mengubah makna.

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

Ini terlihat kecil, tetapi dapat membingungkan pengguna yang mengandalkan input suara. Jika tombol yang terlihat bertuliskan “Remove,” tetapi nama aksesibelnya adalah “Delete invoice,” pengguna yang mencoba mengatakan “click Remove” mungkin tidak mendapatkan hasil yang diharapkan. Persyaratan “label in name” dari WCAG ada persis untuk alasan ini: teks yang terlihat umumnya harus terkandung dalam nama yang aksesibel.

Versi yang lebih baik:

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

Sering kali lebih baik lagi:

<button>Remove invoice</button>

Gunakan aria-labelledby ketika teks yang terlihat sudah ada

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

Contoh:

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

Nama aksesibel section sekarang berasal dari heading yang terlihat. Anda menghindari duplikasi string, yang mengurangi kesalahan terjemahan dan label yang kedaluwarsa.

Ini sangat berguna untuk grup formulir:

<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 kasus, legend native sudah cukup tanpa ARIA. Intinya adalah label yang terlihat harus memimpin. ARIA seharusnya menghubungkan makna yang sudah ada, bukan membuat versi privat kedua dari makna tersebut.

Gunakan aria-describedby untuk teks bantuan, bukan nama

Deskripsi bukan label.

Pertimbangkan field 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 aksesibelnya adalah “Password.” Deskripsinya adalah “Use at least 12 characters.” Screen reader mungkin mengumumkan keduanya, tetapi keduanya memiliki tujuan yang berbeda.

Jangan lakukan ini:

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

Itu menamai field berdasarkan instruksi, bukan konsepnya. Pengguna yang menavigasi formulir ingin mengetahui apa field itu terlebih dahulu, lalu batasan apa yang berlaku.

Perbedaan ini juga penting pada status error:

<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 tetap stabil. Pesan error menjadi konteks pendukung.

Kontrol berulang membutuhkan nama yang unik

Daftar dan card adalah tempat label ARIA sering menjadi perlu.

Buruk:

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

Pengguna screen reader yang menavigasi berdasarkan tombol mungkin mendengar “Delete, tombol” 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 adalah penggunaan aria-label yang sah: teks yang terlihat tetap ringkas, sementara nama yang aksesibel mencakup objeknya.

Namun gunakan pola ini dengan hati-hati. Jika nama objek terlihat di dekatnya, aria-labelledby mungkin lebih mudah dipelihara:

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

Nama aksesibel menjadi “Delete Q4 revenue.” Ini menghindari duplikasi judul laporan dalam atribut.

Jangan memberi label pada semuanya

Tidak setiap elemen membutuhkan label ARIA.

Teks statis biasanya tidak. Ikon dekoratif tidak. Container tidak, kecuali memiliki peran landmark atau widget yang bermakna. Pelabelan berlebihan dapat membuat halaman terasa berisik dan lebih sulit dinavigasi.

Untuk gambar, gunakan model khusus gambar: gambar bermakna membutuhkan alt yang berguna; gambar dekoratif membutuhkan alt="" kosong. Jangan gunakan label ARIA sebagai pengganti teks gambar yang baik. Jika tim Anda mencampur konsep-konsep tersebut, tinjau kembali teks alt gambar yang pragmatis dan pisahkan alternatif gambar dari nama kontrol.

Kesalahan umum adalah memberi setiap SVG sebuah aria-label. Jika SVG berada di dalam tombol dan tombol tersebut sudah memiliki nama, ikon biasanya harus disembunyikan dari teknologi asistif:

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

Jika tidak, pengguna mungkin mendengar pengumuman yang redundan atau aneh, tergantung kombinasi browser dan teknologi asistif.

Periksa nama yang dihitung, bukan hanya kode

Bug aksesibilitas sering lolos dari code review karena markup terlihat masuk akal.

Developer tools browser modern dapat menampilkan accessibility tree yang dihitung. Di Chrome, Edge, Firefox, dan Safari, inspeksi elemen dan cari informasi aksesibilitas seperti role, name, dan description. Anda memeriksa tiga hal:

1. Apakah perannya seperti yang Anda harapkan?
2. Apakah nama aksesibelnya jelas dan spesifik?
3. Apakah deskripsinya membantu tanpa menggantikan nama?

Lalu uji beberapa flow dengan screen reader sungguhan. Anda tidak perlu menjadi pakar teknologi asistif penuh waktu untuk menangkap hal-hal dasar. Di macOS, VoiceOver sudah tersedia. Di Windows, NVDA banyak digunakan dan gratis. Di mobile, uji dengan VoiceOver di iOS dan TalkBack di Android jika relevan.

Alat otomatis berguna, tetapi tidak dapat dengan andal mengatakan apakah “Open,” “Read more,” atau “Delete” sudah cukup kontekstual. Perlakukan otomasi sebagai jaring, bukan hakim. Ini mirip dengan audit performa: laporan dapat menunjukkan area yang mencurigakan, tetapi Anda tetap perlu menafsirkan dampaknya. Pendekatan tenang yang sama seperti yang kami rekomendasikan untuk membaca laporan Lighthouse tanpa panik juga berlaku di sini.

Checklist review praktis

Sebelum merilis label ARIA, tanyakan:

• Bisakah ini menjadi HTML native saja?
• Apakah ada teks yang terlihat yang seharusnya digunakan sebagai label?
• Jika teks yang terlihat ada, apakah nama aksesibel mencakupnya?
• Apakah kontrol berulang tetap unik saat dinavigasi di luar konteks visual?
• Apakah teks bantuan terhubung dengan aria-describedby, bukan dipaksakan ke dalam label?
• Apakah ikon dekoratif disembunyikan dari teknologi asistif?
• Apakah seseorang sudah memeriksa nama aksesibilitas yang dihitung di browser dev tools?
• Apakah setidaknya satu pengujian dengan screen reader sungguhan sudah dilakukan untuk flow kritis?

Checklist ini menangkap sebagian besar masalah label sebelum menjadi masalah pengguna.

Disiplin tenang dari ARIA yang baik

Pekerjaan ARIA yang baik jarang dramatis. Sebagian besar adalah menahan diri.

Gunakan tombol sungguhan. Gunakan label sungguhan. Jaga agar nama yang terlihat dan nama yang aksesibel tetap selaras. Tambahkan aria-label hanya ketika tidak ada sumber terlihat yang lebih baik. Gunakan aria-labelledby ketika halaman sudah berisi teks yang tepat. Gunakan aria-describedby untuk instruksi pendukung dan error.

Platform web memberi developer banyak hal secara gratis ketika kita menggunakannya secara langsung. ARIA ada untuk mengisi celah. Keterampilannya adalah mengetahui kapan benar-benar ada celah.