Aksesibilitas Modal, Dialog, dan Dropdown
Penulis
Redaksi Disabilitas.com
Aksesibilitas Modal, Dialog, dan Dropdown: Menjinakkan Komponen Kompleks
Dalam pengembangan Front-End modern, jendela Modal (atau Dialog) dan menu Dropdown adalah komponen antarmuka yang sangat lazim digunakan. Namun, secara statistik, mereka juga merupakan sumber pelanggaran aksesibilitas terbesar setelah rasio kontras warna.
Membuat Modal yang muncul di tengah layar secara visual itu mudah. Membuat Modal yang tidak mengunci pengguna keyboard atau tidak membingungkan pengguna Screen Reader membutuhkan orkestrasi DOM yang rumit. Mengambil pedoman teknis dari Inclusive Design for Accessibility (Dale Cruse & Denis Boudreau), artikel ini akan membongkar anatomi pembuatan Modal dan Dropdown yang sempurna sesuai standar WCAG.
1. Anatomi HTML dan ARIA pada Modal
Saat sebuah Modal terbuka, Screen Reader harus segera dihentikan dari membaca konten halaman utama di belakangnya, dan difokuskan secara eksklusif ke dalam jendela Modal tersebut.
Atribut Wajib (The Holy Trinity of Modals)
1. `role="dialog"` atau `role="alertdialog"`: Memberi tahu Screen Reader bahwa ini adalah jendela dialog yang terpisah dari konten halaman. Gunakan `alertdialog` HANYA jika pesan tersebut bersifat darurat dan membutuhkan tindakan segera (seperti "Sesi Anda akan segera berakhir"). 2. `aria-modal="true"`: Ini adalah peluru perak. Atribut ini menginstruksikan Screen Reader modern untuk mengabaikan sepenuhnya elemen HTML lain yang berada di luar Modal (menggantikan teknik usang `aria-hidden="true"` pada elemen ``). 3. `aria-labelledby` dan `aria-describedby`: Modal harus memiliki nama. Hubungkan `aria-labelledby` ke ID dari tag `` (Judul Modal), dan `aria-describedby` ke ID dari paragraf deskripsinya.<div
role="dialog"
aria-modal="true"
aria-labelledby="modal-title"
aria-describedby="modal-desc"
tabindex="-1"
id="myModal">
<h2 id="modal-title">Konfirmasi Hapus Data</h2>
<p id="modal-desc">Tindakan ini tidak dapat dibatalkan. Apakah Anda yakin?</p>
<button id="btn-cancel">Batal</button>
<button id="btn-delete">Hapus</button>
</div>
2. Pengelolaan Fokus (Focus Management)
<div
role="dialog"
aria-modal="true"
aria-labelledby="modal-title"
aria-describedby="modal-desc"
tabindex="-1"
id="myModal">
<h2 id="modal-title">Konfirmasi Hapus Data</h2>
<p id="modal-desc">Tindakan ini tidak dapat dibatalkan. Apakah Anda yakin?</p>
<button id="btn-cancel">Batal</button>
<button id="btn-delete">Hapus</button>
</div>
HTML dan ARIA saja tidak cukup. Anda membutuhkan JavaScript untuk mengelola siklus hidup kursor (fokus) pengguna.
Langkah 1: Memindahkan Fokus Masuk
Segera setelah Modal dipicu untuk terbuka, JavaScript harus secara eksplisit memindahkan fokus ke elemen interaktif pertama di dalam Modal, atau ke bungkus Modal itu sendiri (itulah mengapa kita menambahkan `tabindex="-1"` pada elemen pembungkus).Langkah 2: Focus Trapping (Memerangkap Fokus)
Jika pengguna berada di tombol "Hapus" (elemen interaktif terakhir di Modal) dan mereka menekan tombol `Tab`, fokus tidak boleh keluar dari Modal dan jatuh ke tautan di halaman belakang yang sekarang sedang gelap/blur.JavaScript Anda harus mendengarkan peristiwa keydown (Tab). Jika ditekan di elemen terakhir, pindahkan fokus kembali ke elemen interaktif pertama di dalam Modal (membuat perputaran/siklus yang tidak terbatas). Ini adalah implementasi langsung dari Kriteria WCAG 2.1.2 (No Keyboard Trap) dan 2.4.3 (Focus Order).
Langkah 3: Mengembalikan Fokus Keluar
Ketika Modal ditutup, kursor pengguna wajib dikembalikan tepat ke tombol awal yang mereka tekan untuk membuka Modal tersebut. Jika Modal ditutup dan kursor di-reset ke bagian paling atas halaman, pengguna harus menekan tombol `Tab` ratusan kali untuk kembali ke posisi mereka sebelumnya.3. Penanganan Tombol Escape (`Esc`)
Sama halnya dengan mengklik tombol "X" atau mengklik area redup (backdrop) di luar Modal, menekan tombol Escape pada keyboard harus menutup Modal dan Dropdown. Ini adalah harapan universal dari pengguna power user maupun pengguna teknologi asistif.
Jika Dropdown navigasi Anda dibiarkan terbuka saat pengguna mencoba keluar menggunakan Esc, dropdown tersebut akan menghalangi visibilitas elemen di bawahnya, melanggar kriteria Focus Not Obscured (WCAG 2.2).
4. Alternatif Modern: Elemen `
Kabar baik bagi developer masa depan: Anda tidak perlu lagi menulis skrip Focus Trapping JavaScript yang kompleks dari nol.
Browser modern (Chrome, Safari, Firefox, Edge) kini telah mendukung penuh elemen HTML5 <dialog>.
Ketika Anda memanggil metode JavaScript dialogElement.showModal(), browser akan secara otomatis:
- Merender jendela di lapisan paling atas (Top-layer).
- Memerangkap fokus keyboard di dalamnya tanpa script kustom.
- Menutup dialog saat tombol
Escapeditekan. - Memberikan semantik
aria-modalsecara bawaan (native).
Gunakanlah elemen <dialog> kapan pun tumpukan teknologi Anda mengizinkannya. Itu adalah hukum pertama aksesibilitas: Gunakan HTML asli.
5. Kesimpulan
Komponen interaktif yang kompleks seperti Modal dan Dropdown adalah ujian sesungguhnya dari keterampilan aksesibilitas seorang Front-End Developer. Dengan memahami manajemen fokus, menjebak siklus Tab, dan memanfaatkan semantik ARIA (atau tag <dialog> modern), Anda tidak hanya menghindarkan pengguna dari kebingungan yang membuat frustrasi, tetapi Anda menciptakan pengalaman navigasi yang terasa fluid dan elegan bagi siapa pun.
Referensi
Desain dan arsitektur aksesibilitas dalam pembuatan Modal dan Dropdown, termasuk teknik Focus Trapping dan implementasi `aria-modal="true"`, diekstrak dari kerangka pedoman teknis Inclusive Design for Accessibility oleh Dale Cruse dan Denis Boudreau. Solusi Native HTML5 merujuk pada standar pengembangan Front-End modern berbasis pedoman inklusif.Bagaimana menurut Anda?
Berikan reaksi Anda pada artikel ini