Kenapa Tombol Tanpa Label Bisa Jadi Masalah untuk AI Agent

Coba buka website modern mana pun dan cari tombol yang cuma berupa ikon.

Tiga titik.

Panah.

Hati.

Keranjang.

Pensil.

Tempat sampah.

Sparkles.

Secara visual, banyak dari kita langsung paham. Ikon hati mungkin untuk wishlist. Tempat sampah mungkin delete. Pensil mungkin edit. Panah mungkin next.

Masalahnya, “mungkin” adalah kata yang kurang nyaman ketika tombol itu dijalankan AI agent atas nama pengguna.

Dalam Agentic Web, control tanpa label bukan hanya isu accessibility. Ia juga bisa menjadi masalah interpretasi, reliability, dan safety.

Kalau sebuah agent diminta “hapus item terakhir dari cart”, tetapi halaman punya tiga icon button identik tanpa accessible name yang jelas, agent harus mengandalkan posisi visual, konteks DOM, atau inferensi lain untuk menentukan tombol yang benar.

Kadang berhasil.

Kadang tidak.

Dan jika tombolnya sekadar membuka tooltip, dampaknya kecil. Kalau tombolnya menghapus data atau membuat transaksi, tingkat risikonya berbeda.

Accessible name itu apa, sebenarnya?

Dalam accessibility, sebuah elemen interaktif perlu memiliki nama yang dapat dipahami assistive technology. W3C menyebut ini accessible name.

Untuk tombol HTML biasa, teks di dalam tombol dapat menjadi sumber nama.

`Simpan` jelas.

`Kirim` jelas.

`Tambah ke Keranjang` lebih jelas lagi.

Untuk icon-only button, tidak ada teks visual yang dapat dipakai sebagai nama. Di situlah mekanisme seperti `aria-label` atau `aria-labelledby` dapat digunakan bila sesuai.

W3C bahkan memiliki rule yang secara eksplisit memeriksa bahwa button memiliki accessible name yang tidak kosong.

Tujuan utamanya adalah accessibility. Screen reader user perlu tahu tombol itu melakukan apa.

Tetapi sekarang bayangkan browser agent sedang membaca interface yang sama.

Elemen yang punya role dan nama “Hapus produk” memberikan sinyal yang lebih eksplisit daripada sebuah `div` clickable dengan SVG tempat sampah tanpa nama.

Bukan jaminan agent pasti bertindak benar, tetapi ambiguity-nya jauh lebih rendah.

Label visual dan accessible name bukan hal yang sama

Ada nuance penting.

Tombol bisa kelihatan punya arti bagi manusia tanpa memiliki accessible name yang baik.

Contohnya ikon kaca pembesar.

Designer melihatnya dan berkata, “Semua orang tahu ini search.”

Screen reader tidak melihat ikon itu seperti manusia.

Agent juga tidak selalu memproses interface dengan cara yang sama seperti mata manusia.

Accessible name memberi representasi tekstual yang lebih stabil.

Sebaliknya, accessible name juga tidak boleh bertentangan dengan label visual.

Kalau tombol terlihat bertuliskan “Simpan” tetapi accessible name-nya “Hapus dokumen”, itu jauh lebih berbahaya daripada tidak ada label sama sekali karena dua layer interface memberikan makna berbeda.

Karena itu, konsistensi penting.

Tombol yang terlihat sederhana perlu punya nama yang merepresentasikan fungsi sebenarnya.

Masalah pertama: icon yang ambigu

Satu simbol bisa punya banyak arti.

Tiga titik bisa berarti more options.

Bisa juga open menu.

Bisa juga detail.

Ikon bintang bisa berarti favorite, rating, featured, atau premium.

Sparkles lebih parah. Pada website 2026, sparkles bisa berarti generate with AI, improve text, smart recommendation, magic action, atau sekadar dekorasi.

Kalau agent hanya mendapatkan icon tanpa nama, sistem harus menginferensi fungsi dari konteks.

Untuk action yang rendah risiko, mungkin masih acceptable.

Untuk action penting, sebaiknya tidak.

Tombol “Generate dengan AI” lebih aman jika memang itu fungsinya.

Tombol “Tambahkan ke Favorit” lebih informatif daripada icon hati tanpa identitas.

Tombol “Buka Menu Akun” lebih jelas daripada avatar kecil yang clickable tetapi secara struktur bukan button.

Masalah kedua: tombol dengan nama generik

Ada juga tombol yang punya label, tapi labelnya terlalu generic.

“OK.”

“Go.”

“Next.”

“Continue.”

“Done.”

Secara teknis, button punya accessible name. Secara task, maknanya masih bisa kabur.

Bayangkan flow pembayaran tiga langkah.

Halaman pertama punya tombol “Continue”.

Halaman kedua “Continue”.

Halaman ketiga “Continue”.

Yang terakhir ternyata langsung membuat pesanan.

Untuk manusia, desain mungkin memberi konteks visual bahwa ini final step. Untuk agent, explicit action label akan lebih aman.

“Lanjut ke Pembayaran.”

“Review Pesanan.”

“Buat Pesanan.”

Tiga nama itu menjelaskan progres dan konsekuensi.

Agentic design bukan sekadar memberi nama apa pun. Yang dicari adalah nama yang membantu menentukan intent dan outcome.

Masalah ketiga: satu halaman punya banyak tombol bernama sama

Ini kejadian umum di dashboard.

Setiap row punya tombol “Edit”.

Setiap card punya tombol “Delete”.

Setiap item punya tombol “More”.

Secara visual user tahu tombol mana yang terkait item mana karena posisinya.

Agent perlu menghubungkan control dengan konteks item secara benar.

Kalau ada sepuluh tombol “Delete”, agent harus menentukan tombol yang terasosiasi dengan record yang dimaksud.

Hubungan struktural yang jelas membantu, tetapi label yang lebih deskriptif juga dapat mengurangi ambiguity.

Misalnya accessible name “Hapus invoice INV-1045” meskipun secara visual tombolnya tetap hanya icon tempat sampah.

Atau “Edit profil PT Contoh Digital”.

Desain visual tidak perlu dipenuhi teks panjang. Accessible name dapat membawa detail yang dibutuhkan tanpa merusak layout.

Masalah keempat: custom button yang sebenarnya bukan button

Web modern penuh dengan elemen seperti ini:

`<div>` dikasih `onclick`.

`<span>` dibuat clickable.

Card seluruhnya merespons click, tapi tidak punya semantics link atau button.

Bagi mouse user, semuanya terasa bekerja.

Bagi keyboard user, belum tentu.

Bagi agent yang mencari interactive controls, struktur seperti ini lebih sulit daripada native element yang sesuai.

Ini alasan klasik kenapa semantic HTML penting.

Gunakan button untuk action.

Gunakan link untuk navigation.

Jangan membuat semuanya `div` lalu berharap semua user agent memahami niat developer.

Native semantics juga memberi behavior yang lebih predictable untuk keyboard, accessibility tree, focus, dan browser.

Agentic Web membuat keuntungan itu makin relevan.

Masalah kelima: state tombol tidak jelas

Tombol bukan hanya punya nama. Ia juga punya state.

Disabled.

Pressed.

Expanded.

Selected.

Loading.

Bayangkan tombol “Tambahkan ke Favorit”. Setelah ditekan, statusnya berubah menjadi sudah favorit.

Kalau visual hanya mengubah warna hati dari outline menjadi merah tanpa state yang bisa dikenali, agent mungkin tidak yakin apakah aksi berhasil.

Begitu pula toggle menu.

Tombol “Buka Filter” perlu memberi sinyal apakah panel sedang terbuka atau tertutup jika interaction-nya memang toggle.

Di sini ARIA punya berbagai state dan property yang bisa digunakan sesuai pola widget. Tapi implementasinya harus benar. ARIA bukan stiker ajaib yang ditempel ke markup yang salah.

Prinsip yang lebih penting adalah state visual, semantic, dan behavior harus sinkron.

Kalau tombol terlihat disabled tetapi masih bisa diklik, problem.

Kalau `aria-disabled=true` tetapi action tetap jalan, problem.

Kalau tulisan “Saved” muncul tetapi backend gagal, problem yang lebih besar lagi.

Agent membutuhkan truth yang konsisten.

Masalah keenam: tooltip dijadikan satu-satunya penjelasan

Designer kadang mengandalkan tooltip untuk icon button.

Hover icon, lalu muncul “Archive”.

Bagi mouse user, cukup.

Tetapi tooltip tidak selalu menjadi accessible name. Implementasinya bisa berbeda-beda. Pada mobile, hover juga bukan pola utama.

Karena itu, tooltip sebaiknya dianggap tambahan, bukan pengganti nama control yang benar.

AI agent juga tidak ideal jika harus melakukan hover pada semua ikon untuk mencari tahu fungsinya.

Bayangkan dashboard punya 30 icon button. Kalau setiap fungsi baru diketahui setelah hover, navigation cost meningkat tanpa alasan kuat.

Tombol sensitif perlu label yang ekstra jelas

Tidak semua button memiliki risiko sama.

“Buka Detail” berbeda dengan “Hapus Akun”.

“Preview” berbeda dengan “Publish”.

“Tambah ke Cart” berbeda dengan “Bayar Sekarang”.

Untuk destructive atau irreversible action, clarity harus naik.

Button label perlu menjelaskan tindakan.

Confirmation dialog perlu menjelaskan konsekuensi.

Jika ada pilihan cancel, itu harus mudah dibedakan.

Agent sebaiknya memiliki kesempatan berhenti sebelum action dengan dampak besar.

Website tidak bisa mengatur semua policy agent, tetapi interface dapat menyediakan boundary yang lebih jelas.

Misalnya button “Delete” membuka dialog:

“Hapus project Alpha secara permanen?”

Itu lebih baik daripada dialog “Are you sure?” tanpa menyebut objek dan konsekuensi.

Jika agent salah memilih record, confirmation step memberi kesempatan kedua untuk mendeteksi mismatch.

Copy yang lebih jelas adalah guardrail murah.

Bagaimana dengan tombol yang dinamis karena AI?

Website semakin banyak memiliki fitur AI sendiri.

Rewrite.

Summarize.

Generate.

Ask AI.

Auto-fill.

Enhance.

Button untuk fitur semacam ini perlu perhatian ekstra karena pengguna harus tahu apakah action hanya mengubah draft lokal atau mengirim data ke service lain.

Label “Improve” bisa berarti memperbaiki grammar.

Bisa juga berarti mengirim seluruh dokumen ke model eksternal.

Dari perspektif agent, action boundary harus jelas.

Jika button memicu side effect yang berkaitan dengan data, processing, atau biaya, interface sebaiknya memberikan konteks yang cukup sebelum eksekusi.

Agent mengklik agent lain? Kedengarannya meta, tapi sangat mungkin terjadi.

Satu AI agent dapat menggunakan website yang di dalamnya ada AI action. Tanpa label dan state yang jelas, nested automation seperti ini mudah menciptakan kebingungan.

Testing tombol harus lebih dari “bisa diklik”

QA tradisional sering memastikan click handler bekerja.

Agentic QA perlu lebih luas.

Untuk setiap critical button, cek:

Apakah element-nya punya role yang benar?

Apakah accessible name tidak kosong?

Apakah nama merepresentasikan fungsi?

Apakah ada beberapa tombol dengan nama sama yang sulit dibedakan?

Apakah state button terbaca?

Apakah disabled benar-benar disabled?

Apakah action menghasilkan feedback?

Apakah destructive action punya confirmation?

Apakah button menyebabkan navigation atau melakukan action? Kalau navigation, mungkin link lebih tepat.

Apakah tombol bisa digunakan tanpa mouse?

Apakah label berubah setelah state berubah?

Lalu jangan berhenti di audit static.

Buat task.

“Hapus file draft bernama Proposal-Mei, jangan hapus file lain.”

“Tambahkan produk ukuran M ke wishlist.”

“Buka menu akun, lalu ke security settings.”

“Publish artikel ini, tetapi berhenti sebelum konfirmasi final.”

Lihat apakah agent dapat memilih control dengan benar dan konsisten.

Kalau agent sering salah, jangan langsung menyimpulkan model-nya buruk. Audit interface juga.

ARIA bukan jalan pintas untuk markup buruk

Begitu tim mendengar isu accessible name, godaannya adalah menambahkan `aria-label` ke semua hal.

Itu bukan strategi yang sehat.

W3C sendiri menekankan pentingnya menggunakan semantics dan naming dengan benar. Native HTML biasanya harus menjadi pilihan pertama ketika elemen native memang sesuai.

Button dengan teks sudah punya mekanisme naming alami.

Link dengan teks juga.

ARIA paling berguna ketika dibutuhkan untuk melengkapi semantics yang tidak tersedia secara langsung, terutama pada custom interface.

Kalau kita memakai ARIA secara salah, accessibility tree bisa berbeda dari apa yang sebenarnya terjadi di layar.

Itu buruk untuk screen reader.

Dan bisa membingungkan software lain yang bergantung pada struktur tersebut.

Prinsipnya sederhana: jangan membuat semantic fiction.

Jika sesuatu bukan button, jangan pura-pura button hanya agar audit hijau.

Jika state tidak benar, jangan beri property yang seolah benar.

Agentic Web membutuhkan representasi yang akurat, bukan dekorasi metadata.

Button label adalah bagian dari bahasa operasional website

Ini mungkin cara paling menarik melihatnya.

Headline adalah bahasa persuasi.

Body copy adalah bahasa penjelasan.

Navigation adalah bahasa orientasi.

Button adalah bahasa tindakan.

Saat user memberi tugas kepada agent, button menjadi verb pada interface.

Search.

Save.

Delete.

Buy.

Upload.

Approve.

Send.

Publish.

Kalau verb-nya tidak ada atau ambigu, tindakan menjadi lebih sulit dipahami.

Itu sebabnya button label bukan detail kecil yang bisa selalu dikorbankan demi estetika minimalis.

Untuk beberapa kasus, icon-only design tetap masuk akal. Tapi icon-only tidak harus berarti nameless.

Kita bisa menjaga visual tetap bersih sambil membuat semantics lebih kaya.

Dan jangan lupa manusia

Menariknya, banyak perbaikan yang membantu agent juga membantu pengguna manusia.

Label yang lebih jelas mengurangi salah klik.

Confirmation yang spesifik mengurangi accidental deletion.

State yang konsisten mengurangi kebingungan.

Native button membantu keyboard user.

Accessible name membantu screen reader.

Copy action yang eksplisit membantu semua orang memahami apa yang akan terjadi.

Jadi, optimasi ini bukan proyek “untuk robot” yang mengorbankan manusia.

Kalau dilakukan benar, justru ia memperbaiki kontrak antara interface dan pengguna.

Website mengatakan: tombol ini melakukan X.

Pengguna atau agent memahami: kalau saya aktifkan, X akan terjadi.

Sistem kemudian benar-benar melakukan X.

Kontrak sederhana itu adalah fondasi reliability.

Di era sebelum agent, tombol ambigu mungkin hanya menghasilkan UX yang sedikit annoying.

Di era agent, ambiguity bisa ikut terbawa ke tindakan otomatis.

Karena itu, ketika designer berkata, “Teksnya kita hilangkan saja biar clean,” pertanyaan berikutnya seharusnya bukan cuma “Masih kelihatan bagus nggak?”

Pertanyaannya juga:

“Kalau tombol ini dibaca tanpa melihat ikon, apakah fungsinya masih jelas?”

Kalau jawabannya tidak, label bukan detail tambahan.

Label adalah bagian dari infrastruktur tindakan.