Lompat ke Konten Utama
Teknis & Pemrograman07 Juli 2026

WAI-ARIA: Penyelamat atau Penghancur Aksesibilitas?

Penulis

Redaksi Disabilitas.com

3 Menit Baca4 Kali Dibaca

WAI-ARIA: Penyelamat atau Penghancur Aksesibilitas?

WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) adalah sebuah spesifikasi teknis yang diciptakan oleh W3C untuk menjembatani kesenjangan aksesibilitas pada aplikasi web dinamis. ARIA memberikan kemampuan untuk menyuntikkan semantik buatan ke dalam elemen HTML yang tidak memiliki makna bawaan (seperti <div> atau <span>).

Banyak pengembang Front-End pemula percaya bahwa semakin banyak atribut aria-<em> yang mereka taburkan ke dalam kode, semakin aksesibel pula situs web mereka. Sayangnya, realitasnya bertolak belakang. Berdasarkan analisis kritis dari Inclusive Design for Accessibility* oleh Dale Cruse dan Denis Boudreau, artikel ini akan membedah mengapa ARIA sering kali menjadi "penghancur" aksesibilitas terbesar.


1. Hukum Pertama ARIA (The First Rule of ARIA)

Aturan pertama dan paling absolut dalam dokumentasi resmi W3C WAI-ARIA adalah: "Tidak menggunakan ARIA jauh lebih baik daripada menggunakan ARIA dengan buruk." (Atau: "No ARIA is better than bad ARIA.")

Jika Anda bisa menggunakan elemen HTML5 native (asli) yang sudah memiliki semantik dan fungsionalitas bawaan, Anda wajib menggunakannya daripada membuat ulang elemen tersebut dengan ARIA.

Contoh Klasik: Tombol Palsu

Berapa kali Anda melihat kode ini di sebuah kerangka kerja modern? ```html
Kirim
``` Elemen ini tidak bisa dijangkau dengan tombol `Tab`, tidak bisa ditekan dengan `Enter`, dan Screen Reader hanya akan membacanya sebagai teks biasa ("Kirim").

Lalu, seorang pengembang mencoba "memperbaikinya" dengan ARIA:

<!-- LEBIH BURUK: Tombol palsu dengan ARIA -->
<div class="btn-primary" role="button" tabindex="0" onclick="submitForm()">Kirim</div>

Sekarang elemen ini bisa dijangkau oleh Tab dan dibacakan sebagai "Tombol, Kirim". Tetapi, karena ini bukan <button> asli, menekan Enter atau Space tidak akan memicu fungsi submitForm() kecuali Anda menulis kode JavaScript tambahan (Event Listener untuk Keyboard). Anda telah menjebak pengguna keyboard.

Solusi Aksesibel Murni:

<!-- SEMPURNA: HTML Asli -->
<button class="btn-primary" type="button" onclick="submitForm()">Kirim</button>

2. ARIA Tidak Mengubah Perilaku Visual atau Fungsional

Ini adalah miskonsepsi terbesar: Atribut ARIA sama sekali tidak memengaruhi DOM secara visual, dan tidak memberikan fungsionalitas interaktif.

Menambahkan role="tab" pada sebuah <li> tidak akan secara ajaib membuat elemen tersebut berperilaku seperti sistem Tab yang bisa berpindah konten. Ia HANYA berbohong kepada Screen Reader bahwa elemen tersebut adalah sebuah Tab. Anda tetap harus menulis JavaScript yang rumit untuk mengatur fokus tabindex dan menyembunyikan/menampilkan panel konten.


3. Bahaya Redundansi ARIA

Banyak developer mengalami sindrom "Takut Kurang Aksesibel" sehingga mereka menumpuk ARIA di atas elemen yang sudah memiliki semantik bawaan.

<!-- SANGAT BURUK: Redundansi yang membingungkan -->
<nav role="navigation">
  <ul role="list">
    <li role="listitem">
      <a href="/home" role="link">Beranda</a>
    </li>
  </ul>
</nav>

Semua atribut role di atas sama sekali tidak berguna, karena tag <nav>, <ul>, <li>, dan <a> sudah memiliki semantik tersebut. Redundansi semacam ini tidak hanya membuat kode Anda kotor, tetapi terkadang dapat menyebabkan perilaku tak terduga (bug) pada versi Screen Reader tertentu.


4. Kapan Kita BENAR-BENAR Membutuhkan ARIA?

ARIA diciptakan untuk widget dan kontrol antarmuka kompleks yang tidak ada padanannya di dalam standar HTML5.

Anda wajib menggunakan ARIA ketika membangun:

  1. Pola Desain Khusus: Seperti Accordion, Tabs, Tree View, atau Carousel.
  2. Status Dinamis: Menggunakan aria-expanded="true/false" untuk memberi tahu Screen Reader apakah menu dropdown sedang terbuka atau tertutup.
  3. Pesan Langsung (Live Regions): Menggunakan aria-live="polite" untuk membacakan pesan error toast atau notifikasi sukses yang muncul tiba-tiba tanpa me-refresh halaman.
  4. Deskripsi Tambahan: Menggunakan aria-label atau aria-describedby untuk memberikan konteks pada tombol tanpa teks (seperti tombol ikon 'X' untuk menutup modal).

5. Kesimpulan

WAI-ARIA adalah pisau bedah medis. Di tangan seorang ahli, ia bisa menyelamatkan nyawa aplikasi web modern Anda yang rumit (seperti Single Page Application). Namun, di tangan seorang amatir yang menggunakannya untuk memotong sayuran, ia akan menyebabkan pertumpahan darah (menghancurkan Accessibility Tree).

Ingatlah selalu: HTML5 adalah fondasi Anda. ARIA adalah bumbu penyedap. Jangan pernah mencoba membangun rumah hanya dengan menggunakan bumbu penyedap.


Referensi

Analisis mendalam mengenai First Rule of ARIA, miskonsepsi perilaku elemen, dan bahaya redundansi peran ini diekstrak dari argumen teknis dalam Inclusive Design for Accessibility oleh Dale Cruse dan Denis Boudreau. Solusi praktis mengenai tombol palsu (Div Buttons) dan penggunaan Live Regions merujuk sepenuhnya pada studi kasus yang dipaparkan dalam buku tersebut.

Bagaimana menurut Anda?

Berikan reaksi Anda pada artikel ini