Popover API - Kemungkinan baru untuk tooltip native browser

• Popover API menggantikan event listener JavaScript, manajemen state, dan sinkronisasi manual atribut ARIA yang sebelumnya wajib dalam implementasi tooltip, dengan fitur native browser
• Hanya dengan atribut popover dan popovertarget, buka/tutup, penanganan tombol Esc, dan navigasi keyboard bekerja otomatis
• Prediktabilitas screen reader meningkat, sinkronisasi aria-expanded berjalan otomatis, dan kategori bug aksesibilitas seperti pemulihan fokus praktis hilang
• Pada beberapa area seperti kontrol timing dan deteksi hover intent, JavaScript masih dibutuhkan, tetapi model interaksi inti kini ditangani browser
• Untuk design system berskala besar atau kebutuhan positioning yang kompleks, library masih tetap relevan, tetapi default-nya sedang beralih ke API native

---

Masalah tooltip sebelumnya

• Sebelum Popover API, browser tidak memiliki konsep tooltip native yang bekerja di mouse, keyboard, dan teknologi bantu secara menyeluruh
• Pola yang sama terus berulang: elemen trigger, elemen tooltip tersembunyi, dan JavaScript yang mengoordinasikan keduanya
• Secara permukaan terlihat sederhana, tetapi saat dipakai pengguna nyata, berbagai masalah muncul
  • Pengguna keyboard tidak melihat tooltip meski masuk ke trigger dengan Tab
  • Screen reader membacanya dua kali, atau tidak membacanya sama sekali
  • Saat mouse bergerak cepat, terjadi flicker
  • Konten saling tumpang tindih pada layar kecil
  • Tidak bisa ditutup dengan tombol Esc, fokus pun hilang
• Seiring waktu, kode membesar karena akumulasi event listener, penanganan hover/focus terpisah, kasus khusus klik di luar, dan sinkronisasi manual atribut ARIA

Mengapa memakai library

• Library menangani pekerjaan nyata seperti positioning, flipping di batas viewport, koordinasi event menurut tipe input, dan deteksi scroll dalam layout yang kompleks
• Hanya untuk positioning saja dependensi sering sudah terasa layak, karena penanganan scroll container, transform, dan layout responsif memang rumit
• Masalah sebenarnya muncul pada perilaku aksesibilitas
  • Tooltip muncul terlambat atau tidak muncul sama sekali
  • Tooltip terlewat saat tab berpindah cepat
  • Pelepasan dengan Esc tidak stabil
• Pengguna mouse mengharapkan respon instan, sementara pengguna keyboard mengharapkan prediktabilitas, dan saat keduanya didukung, delay serta edge case pun muncul
• Pada screen reader, tooltip bisa dibaca, tidak dibaca, atau dibaca dua kali, sehingga perilakunya tidak konsisten
• Jika ada satu saja pembaruan atribut ARIA manual yang terlewat, accessibility tree bisa menjadi membingungkan atau berada dalam state tak terlihat

Bukan masalah pada kode, melainkan batasan platform

• Implementasi sudah diuji dan library juga solid, tetapi masalah intinya adalah web platform tidak menyediakan affordance yang tepat
• Browser tidak punya cara untuk mengenali bahwa elemen itu adalah tooltip; semuanya berbasis convention seperti elemen generik, event listener, ARIA manual, dan logika dismiss kustom
• Seiring waktu, perubahan kecil pun membawa risiko, dan perbaikan sepele dapat memicu regresi dalam struktur yang rapuh
• Setiap tooltip baru mewarisi kompleksitas yang sama

Penerapan pertama Popover API

• Bukan karena ingin mencoba eksperimen baru, melainkan karena sudah lelah merawat perilaku tooltip yang sebenarnya seharusnya dipahami browser
• Dicoba dalam bentuk paling kecil: <button popovertarget="tip-1"> + <div id="tip-1" popover="manual" role="tooltip">
• Tanpa event listener, tanpa pelacakan state, tanpa pembaruan ARIA dari JavaScript
• Saat tombol mendapat fokus, tooltip muncul; saat Esc ditekan, tooltip menghilang

Perbedaan yang langsung terasa

• Buka/tutup tanpa JavaScript: browser menangani pemanggilan hanya dengan HTML, dan hubungan antara trigger dengan tooltip menjadi eksplisit
• Tombol Esc bekerja otomatis: tanpa menambah key listener, browser sudah memahami kemungkinan dismiss popover
• Sinkronisasi state ARIA otomatis: atribut aria-expanded diperbarui otomatis saat popover dibuka/ditutup, tanpa perlu dikelola manual, sehingga risiko state usang hilang
• Yang lebih penting daripada berkurangnya kode adalah pergeseran tanggung jawab: sebelumnya JavaScript yang “menghadirkan” tooltip, sekarang browser memahami perannya dari markup dan ikut dalam model fokus, accessibility tree, dan aturan dismiss native

Memahami Invoker Commands

• popovertarget="id" menghubungkan tombol ke elemen popover
• popovertargetaction menentukan perilaku
  • show: hanya membuka
  • hide: hanya menutup
  • toggle (default): menutup jika sedang terbuka, membuka jika sedang tertutup
• Satu tooltip dapat memiliki beberapa trigger, dan JavaScript tidak diperlukan untuk interaksi dasarnya

Keuntungan gratis terkait aksesibilitas

• Keyboard yang "langsung bekerja"

  • Sebelumnya, fokus harus memicu tooltip, blur harus menyembunyikannya, Esc harus dihubungkan manual, dan timing juga harus pas, membentuk struktur berlapis
  • Saat atribut popover (auto atau manual) ditetapkan, browser menangani default-nya: Tab/Shift+Tab bekerja normal, dan Esc menutup dengan andal setiap saat
  • Global keydown handler, logika pembersihan khusus Esc, dan pengecekan state selama navigasi keyboard dapat dihapus dari codebase

• Prediktabilitas screen reader

  • Ini menjadi area peningkatan terbesar; sebelumnya bahkan dengan ARIA yang disusun hati-hati pun perilakunya bisa berubah dan perubahan kecil terasa berisiko
  • Dengan popover="manual" role="tooltip", perilakunya menjadi jauh lebih stabil dan bisa diprediksi
  • Setelah migrasi, Lighthouse tidak lagi menampilkan peringatan state ARIA yang salah — karena memang tidak ada lagi state ARIA kustom yang bisa keliru

• Manajemen fokus

  • Sebelumnya ada aturan rumit: tampilkan saat trigger fokus, jangan tutup saat fokus pindah ke dalam tooltip, tangani blur, dan pulihkan fokus secara manual
  • Dengan Popover API, fokus berpindah secara alami ke popover, dan saat ditutup, fokus otomatis kembali ke trigger
  • Bukan menambahkan kode pemulihan fokus, melainkan menghapusnya

Area yang masih kurang pada Popover API

• Timing tooltip

  • Popover native membuka dan menutup secara instan; jika mouse bergerak sedikit lebih cepat atau hanya menyapu trigger, tooltip bisa berkedip dan terasa tidak stabil
  • Kontrol delay antara hover/focus dan pembukaan masih tetap dibutuhkan
  • Perilaku buka/tutup dasar ditangani browser dan HTML invoker commands, sementara JavaScript hanya dipakai untuk penyempurnaan perilaku yang disengaja, misalnya membatalkan hide saat pointer berpindah ke tooltip
  • Di CSS, area ini juga sedang dieksplorasi; pekerjaan terkait interest/invoker sedang menuju arah di mana delay masuk/keluar bisa diekspresikan langsung lewat CSS

• Hover intent dan Invoker Commands

  • Browser tidak tahu mengapa seseorang melakukan hover di atas elemen — apakah sengaja atau pointer hanya lewat, tidak bisa ditentukan
  • Karena invoker commands menangani buka/tutup inti, JavaScript tidak lagi memiliki model interaksi; ia hanya menambahkan intent di atasnya
  • JavaScript hanya dipakai untuk perilaku yang tidak bisa disimpulkan browser, seperti delay singkat sebelum hide atau membatalkan dismiss saat pointer bergerak ke tooltip

• Manual Popover dan fokus

  • Pada popover="manual", berbeda dari auto popover, browser tidak memulihkan fokus secara otomatis
  • Saat tooltip dibuka lewat fokus dan ditutup lewat blur, fokus harus dikembalikan secara eksplisit ke trigger
  • Ini menunjukkan batas yang jelas antara perilaku platform dan niat pengguna

• Penilaian jujur

  • Popover API memang tidak menyelesaikan tooltip secara ajaib, tetapi ia menghentikan kebutuhan untuk membangun ulang infrastruktur yang rapuh
  • JavaScript dan edge case tetap ada, tetapi kini fokus bisa dialihkan ke menyelesaikan masalah produk, bukan mereproduksi UI primitive

Kapan library tooltip masih dibutuhkan

• Design system besar atau matang

  • Pada design system besar yang dipakai banyak tim, library masuk akal untuk perilaku terpusat, pola terdokumentasi, dan default yang konsisten
  • Mengubah model interaksi dasar bukan hanya keputusan teknis, tetapi juga keputusan organisasi
  • Library memberi guardrail bagi anggota tim yang belum akrab dengan nuansa aksesibilitas

• Kebutuhan positioning yang kompleks

  • Jika diperlukan deteksi benturan di antara nested scroll container, logika flipping kustom, atau kontrol offset/boundary yang rinci, library seperti Floating UI tetap lebih unggul
  • CSS anchor positioning mulai mencakup banyak bagian dari masalah ini — penempatan relatif terhadap trigger, penempatan sadar viewport, dan edge flipping bisa dilakukan dengan CSS murni
  • Ini masih fitur baru dan ada known issue, tetapi sudah masuk Interop sehingga ada prospek dukungan browser yang lengkap dan konsisten
  • Jika saat ini dibutuhkan perilaku lintas-browser yang konsisten, library masih menjadi pilihan praktis

• Tim dengan pengalaman aksesibilitas terbatas

  • Pada tim yang minim pengetahuan aksesibilitas, library yang baik berfungsi sebagai jaring pengaman — bukan jaminan aksesibilitas sempurna, tetapi mampu mencegah kesalahan umum
  • Popover API memberi default yang lebih baik, tetapi tetap perlu tahu kapan harus menambahkan role, label, manajemen fokus, dan pengujian
  • Tanpa pemahaman, alat native pun tetap bisa disalahgunakan

Kesimpulan

• Berkat Popover API, tooltip tidak lagi disimulasikan, melainkan menjadi elemen yang dipahami browser
• Membuka, menutup, perilaku keyboard, penanganan Esc, dan sebagian besar aksesibilitas kini disediakan langsung oleh platform
• Untuk design system yang kompleks, kustomisasi tingkat tinggi, atau constraint legacy, library masih tetap relevan, tetapi default-nya sudah bergeser
• Ini adalah momen pertama ketika tooltip yang paling sederhana juga bisa menjadi tooltip yang paling akurat
• Coba ganti satu tooltip saja di produk dengan Popover API, lalu lihat apa saja yang hilang dari kode