Anti-Patterns Aksesibilitas: Bahaya Tooltip, Carousel, dan Custom Select

Pendahuluan

Saat membangun design system yang dapat diakses (accessible), tolok ukur kesuksesan yang sebenarnya bukan hanya tentang komponen apa yang kita sertakan dan buat, tetapi seringkali tentang komponen dan pola apa yang secara aktif kita putuskan untuk dihilangkan. Aksesibilitas dalam design system tidak sekadar berarti membuat segalanya "dapat diakses" melalui pemaksaan atribut ARIA; ini membutuhkan evaluasi kritis terhadap komponen UI sehari-hari dan pengambilan keputusan tentang komponen mana yang secara bawaan menciptakan hambatan yang tidak dapat diatasi dan pengalaman pengguna yang buruk bagi penyandang disabilitas. Design system yang matang bertindak sebagai panduan yang beropini, secara aktif mendorong tim produk untuk mencari alternatif yang lebih baik dan inklusif daripada menggunakan standar bawaan yang cacat.

Di antara pelanggar paling umum yang ditemukan dalam antarmuka web modern adalah tooltip, custom-styled select (sering dikenal sebagai dropdown, listbox, atau combobox), dan carousel. Ketiga komponen ini sering kali mewakili anti-pattern aksesibilitas. Meskipun mereka mungkin memuaskan keinginan estetika atau tuntutan pemangku kepentingan internal, komponen-komponen ini secara konsisten memperkenalkan hambatan kognitif dan teknis yang signifikan bagi orang-orang yang bergantung pada pembaca layar (screen reader), menavigasi menggunakan keyboard atau perangkat switch, atau mereka yang mengalami disabilitas kognitif.

Artikel ini membahas secara mendalam alasan teknis mengapa komponen UI populer ini gagal, bagaimana mereka menciptakan hambatan besar, dan mengapa design system harus secara sistematis mengecualikannya atau sangat membatasi penggunaannya berdasarkan prinsip "Foundations of Accessible Design System Patterns."

---

Masalah dengan Tooltips

Menyembunyikan Informasi Penting

Pada intinya, tooltip pada dasarnya cacat karena mereka menyembunyikan informasi. Jika suatu konten cukup penting sehingga pengguna membutuhkannya untuk memahami UI, konten tersebut harus ditampilkan secara jelas bagi semua orang, tanpa disembunyikan di balik status hover (layang) atau focus. Tooltip sering kali merupakan indikasi dari desain UX yang buruk, bertindak sebagai penopang untuk antarmuka yang tidak intuitif atau tidak dapat menjelaskan dirinya sendiri.

Dengan meminta pengguna untuk melakukan tugas fisik dan kognitif tambahan hanya untuk memahami tujuan suatu kontrol atau persyaratan input, kita menghukum semua orang. Hal ini sangat merugikan bagi mereka yang memiliki disabilitas kognitif yang mungkin kesulitan dengan memori kerja atau membutuhkan antarmuka yang bebas gangguan. Informasi yang disembunyikan di balik tooltip tidak akan semudah dikonsumsi dibandingkan informasi berguna yang ditempatkan dalam jarak visual yang dekat dengan fitur UI yang menentukan.

Hambatan bagi Navigasi Keyboard dan Screen Reader

Dari sudut pandang teknis, tooltip menghadirkan hambatan yang sangat umum dan persisten bagi pengguna screen reader dan pengguna yang hanya mengandalkan keyboard. Masalah mendasarnya terletak pada kurangnya elemen HTML asli yang terstandarisasi untuk tooltip, yang berarti tidak ada konvensi umum yang didukung secara universal untuk mendefinisikan nama aksesibel, peran (role), status, atau aksi keyboard-nya.

Ketika pengembang mencoba membangun tooltip kustom, mereka sering kali mengandalkan kejadian mouse hover (mouseenter / mouseleave), yang sepenuhnya mengecualikan pengguna yang bernavigasi dengan keyboard, perangkat switch, atau layar sentuh. Bahkan ketika fokus keyboard (focus / blur) diimplementasikan, screen reader mungkin tidak mengumumkan konten tooltip jika atribut ARIA (seperti aria-describedby atau aria-labelledby) tidak dihubungkan dengan sempurna ke elemen pemicunya.

Selain itu, tooltip sering gagal memenuhi Kriteria Kesuksesan WCAG 2.1 1.4.13: Content on Hover or Focus. Kriteria ini menuntut bahwa tooltip harus:

• Dismissable (Dapat dihilangkan): Pengguna harus dapat menghilangkan tooltip tanpa menggerakkan pointer atau fokus keyboard mereka (biasanya melalui tombol Escape). Tooltip kustom jarang mengimplementasikan hal ini dengan benar.
• Hoverable (Dapat disorot): Jika pengguna menggerakkan pointer mereka ke atas tooltip itu sendiri (mungkin untuk membacanya dengan kaca pembesar layar), tooltip tersebut tidak boleh menghilang.
• Persistent (Bertahan): Tooltip harus tetap terlihat sampai hover atau fokus dihilangkan, pengguna menghilangkannya, atau informasinya tidak lagi valid.

Daripada melawan pertempuran teknis ini dan berisiko gagal, pendekatan yang paling aksesibel adalah menghilangkan tooltip sepenuhnya dari design system. Dorong tim produk untuk menulis teks UI yang intuitif dan jelas, menempatkan instruksi atau deskripsi yang diperlukan dalam teks biasa tepat di sebelah kontrol yang relevan.

---

Bahaya Custom-Styled Selects (Dropdowns/Comboboxes)

Ilusi Kontrol

Desainer dan pengembang sering memendam ketidaksukaan yang mendalam terhadap elemen HTML <select> bawaan karena permukaan dropdown-nya (daftar opsi) tidak dapat sepenuhnya diberi gaya menggunakan CSS di semua browser dan sistem operasi. Frustrasi estetika ini mendorong tim untuk membangun custom-styled select menggunakan elemen <div>, <span>, dan <ul>, yang dihias tebal dengan CSS dan digerakkan oleh kerangka kerja JavaScript yang kompleks (misalnya, dropdown kustom Angular Material).

Namun, sama sekali tidak ada alasan yang baik untuk mengganti elemen HTML <select> bawaan dalam formulir standar. Elemen bawaan ini secara inheren dapat diakses dan menyediakan semua fitur bawaan yang diperlukan untuk menyajikan daftar opsi yang muncul dengan andal.

Kompleksitas Mereplikasi Perilaku Bawaan

Dropdown kustom tidak dapat mereplikasi fungsionalitas elemen select bawaan yang kuat dan bernuansa di setiap platform (macOS, Windows, iOS, Android, dan ChromeOS). Setiap kombinasi sistem operasi dan browser memiliki tindakan keyboard, gerakan layar sentuh, dan ekspektasi semantik yang sedikit berbeda.

Saat membangun custom select, pengembang harus secara manual menciptakan kembali teknik rekayasa browser yang telah dikembangkan bertahun-tahun, termasuk:

• Navigasi Keyboard: Tombol panah untuk menavigasi opsi, Enter atau Spasi untuk memilih, Escape untuk menutup, dan fungsi type-ahead (mengetik beberapa huruf pertama dari sebuah opsi untuk langsung melompat ke opsi tersebut).
• Manajemen Fokus: Mengelola aria-activedescendant atau memindahkan tabindex secara manual saat pengguna menavigasi daftar kustom, serta memastikan fokus kembali ke tombol pemicu saat ditutup.
• Semantik Screen Reader: Menerapkan peran ARIA yang kompleks seperti combobox, listbox, dan option, bersama dengan status dinamis seperti aria-expanded dan aria-selected.
• Pengalaman Mobile: Select bawaan secara otomatis memicu UI tingkat OS (seperti wheel picker di iOS atau daftar modal di Android), yang sangat dioptimalkan untuk sentuhan dan pembaca layar seluler. Select kustom memaksa pengguna ke dalam dropdown palsu yang sering rusak pada layar kecil, membutuhkan pengguliran yang canggung, atau melakukan zoom yang tidak terduga.

Sangat mahal untuk membangun custom select dengan benar. Bahkan jika dibangun dengan sempurna pada hari pertama, tanpa pemeliharaan yang konsisten dan ketat terhadap standar browser dan teknologi pendukung yang terus berkembang, komponen ini pasti akan mengalami degradasi. Komponen ini akan dengan cepat menjadi tidak dapat diakses oleh penderita disabilitas motorik yang menggunakan keyboard atau perangkat switch, dan bagi orang-orang yang menggunakan pembaca layar yang bergantung pada struktur semantik standar.

Elemen HTML <select> bawaan dapat sepenuhnya diberi gaya dalam keadaan tertutup (tombol pemicu itu sendiri). Permukaan opsi gaya disediakan oleh sistem operasi dan tidak memerlukan desain ulang. Merangkul elemen bawaan adalah kemenangan besar bagi aksesibilitas, kinerja, dan pemeliharaan jangka panjang.

---

Permusuhan Carousels

Beban Konten dan Beban Kognitif

Slideshow carousel hampir secara universal merupakan kompromi antara pemangku kepentingan yang bersaing yang tidak dapat memutuskan konten mana yang paling penting, dan karena itu memilih untuk menampilkan semuanya di ruang yang berputar. Hal ini menghasilkan pengalaman pengguna yang bermusuhan yang jarang menerima keterlibatan (engagement) lebih dari slide pertama.

Bahkan carousel yang "dapat diakses" pun memberikan beban kognitif tambahan yang sangat besar bagi semua orang, yang pertama-tama harus mempelajari cara menavigasi UI gabungannya yang spesifik dan seringkali unik sebelum mereka bahkan dapat mengkonsumsi konten tersebut. Pengguna dipaksa untuk mencari tahu: Apakah ini dapat digeser (swipeable)? Apakah tombol panah keyboard mengoperasikannya? Berapa banyak slide yang ada? Metadata ini harus disampaikan dan dipahami dengan cepat, dan pengguna harus cukup termotivasi untuk terlibat melebihi tampilan awal.

Hambatan Vestibular dan Kognitif

Mungkin pelanggaran aksesibilitas yang paling mengerikan yang ditemukan dalam carousel adalah penggunaan fitur auto-advance (slide yang berputar otomatis). Konten yang berputar otomatis menciptakan hambatan parah bagi orang-orang dengan disabilitas kognitif, kesulitan membaca, dan gangguan pemusatan perhatian, yang mungkin tidak memiliki cukup waktu untuk membaca konten sebelum konten tersebut menghilang.

Selain itu, gerakan tak terduga dapat memicu mabuk perjalanan, pusing, atau disorientasi bagi orang dengan gangguan vestibular. Jika carousel harus menampilkan auto-advance, fitur tersebut harus dimatikan secara default, atau menyediakan mekanisme yang sangat terlihat dan dapat dikontrol pengguna untuk menjeda atau menghentikan gerakan dengan segera.

Mimpi Buruk Navigasi Keyboard dan Screen Reader

Dari sudut pandang teknologi pendukung, carousel terkenal sulit diimplementasikan agar dapat diakses.

• Perangkap Fokus dan Navigasi: Pengguna keyboard dan screen reader harus dapat melewati carousel sepenuhnya tanpa dipaksa untuk berinteraksi dengan setiap slide tunggal atau kontrol tersembunyi.
• Konten Tersembunyi: Slide yang disembunyikan secara visual juga harus disembunyikan dari pembaca layar (misalnya, menggunakan aria-hidden="true" atau inert), dan fokus keyboard tidak boleh mendarat di tautan atau tombol di dalam slide yang tersembunyi.
• Pengumuman: Pengembang harus secara hati-hati mempertimbangkan apa yang diumumkan oleh screen reader ketika pengguna berinteraksi dengan carousel. Misalnya, menggunakan live region ARIA (aria-live="polite") berguna untuk mengumumkan apa yang telah berubah (misalnya, "Slide 2 dari 5: Diskon Musim Panas"), tetapi hal ini menjadi luar biasa mengganggu jika mengumumkan seluruh isi slide yang panjang pada setiap rotasi.
• Aktivasi Titik Tunggal (Single Point Activation): Penderita disabilitas motorik mungkin tidak dapat melakukan gerakan kompleks seperti menggeser (swipe) atau menyeret (drag) dengan presisi. Carousel harus menyediakan metode operasi titik tunggal (tombol ketuk atau klik sederhana) untuk bernavigasi.

Panduan untuk Carousel yang Tidak Dapat Dihindari

Jika carousel adalah komponen yang sama sekali tidak dapat dihindari yang diamanatkan oleh persyaratan bisnis, design system harus membantu tim menggunakan pola yang dapat diakses untuk mengurangi kerusakan:

1. Jangan Pernah Auto-Advance secara Default: Nonaktifkan auto-play sepenuhnya untuk menghormati beban kognitif dan sensitivitas vestibular. Jika harus disertakan, pastikan dapat dikontrol oleh pengguna.
2. Prediktabilitas: Utamakan informasi yang dapat diprediksi dan terkait di seluruh slide (misalnya, variasi warna sepatu dan produk) daripada konten yang terputus-putus dan mengejutkan.
3. Tetapkan Ekspektasi: Tampilkan dengan jelas jumlah total slide, posisi interval saat ini, dan kontrol navigasi yang terlihat bagi orang-orang dengan penglihatan rendah dan pengguna screen reader.
4. Sediakan Metode Operasi Titik Tunggal: Pastikan carousel dapat dinavigasi dengan ketukan atau klik tunggal, tanpa bergantung pada gerakan seret-dan-geser (drag-and-swipe) yang kompleks.
5. Optimalkan Pengumuman: Pastikan pengumuman screen reader ringkas, hanya mengumumkan perubahan status (seperti judul slide dan posisi) daripada membaca seluruh konten slide secara otomatis.

---

Kesimpulan

Membangun design system yang dapat diakses membutuhkan keberanian untuk mengatakan "tidak" pada pola-pola yang secara inheren mengecualikan pengguna. Dengan menghilangkan tooltip, custom-styled select, dan carousel yang berputar otomatis, kita memaksa diri kita sendiri untuk menemukan cara yang lebih jelas dan lebih tangguh dalam menyajikan informasi.

Merancang dengan mempertimbangkan interseksionalitas—mengantisipasi kebutuhan yang tumpang tindih seperti penglihatan rendah yang dikombinasikan dengan gangguan motorik, atau gangguan pendengaran yang dipadukan dengan tantangan kognitif—memastikan bahwa platform digital kita berfungsi secara mulus bagi semua orang, terlepas dari kombinasi kebutuhan unik yang mereka bawa. Perlakukan design system Anda seperti produk yang intuitif bagi tim pengonsumsi, dan inklusi bagi penyandang disabilitas sebagai persyaratan mutlak, bukan fitur bonus.

---

Referensi

Cruse, Dale, dan Denis Boudreau. Inclusive Design for Accessibility*. Bab 10: "Foundations of Accessible Design System Patterns."