ARIA untuk AI Agent: Kenapa Accessibility Mendadak Jadi Infrastruktur

Ada ironi menarik di web 2026. Sesuatu yang bertahun-tahun dianggap “urusan accessibility” sekarang mulai dibicarakan tim AI, browser, automation, dan product infrastructure.

Namanya ARIA.

Buat developer front-end, WAI-ARIA bukan barang baru. ARIA adalah bagian dari ekosistem accessibility web yang membantu menyampaikan roles, states, dan properties pada interface ketika semantics native belum cukup. Tujuan utamanya jelas: membuat aplikasi web lebih interoperable dengan assistive technology dan lebih bisa digunakan oleh penyandang disabilitas.

Lalu datang browser agent.

Saat OpenAI memperkenalkan ChatGPT Atlas, perusahaan itu secara eksplisit menyebut bahwa pemilik website dapat menambahkan ARIA tags untuk membantu ChatGPT agent bekerja lebih baik di website. Tiba-tiba istilah yang biasanya hidup di audit WCAG masuk deck product strategy.

Reaksi paling berbahaya adalah langsung menyimpulkan, “Berarti ARIA sekarang ranking factor AI.”

Tidak ada dasar untuk klaim itu.

Yang lebih tepat adalah memahami kenapa semantics accessibility menjadi relevan ketika software mulai berinteraksi dengan interface seperti user.

ARIA bukan bahasa rahasia untuk AI

Pertama, kita luruskan fungsi dasarnya.

WAI-ARIA menyediakan vocabulary yang menggambarkan role suatu elemen, state yang sedang aktif, dan property yang membantu menjelaskan hubungan atau perilaku sebuah komponen. Contohnya termasuk button, dialog, tab, expanded, selected, checked, required, labelledby, describedby, dan berbagai semantics lain.

Teknologi ini dibuat untuk accessibility, bukan sebagai API browser agent.

W3C menegaskan bahwa ARIA dimaksudkan sebagai supplement untuk native semantics, bukan replacement. Kalau HTML sudah punya elemen dengan meaning yang tepat, gunakan elemen native. Button sebaiknya button. Heading sebaiknya heading. Checkbox sebaiknya memakai control yang memang membawa semantics checkbox kecuali ada alasan kuat membangun custom widget.

Kenapa prinsip ini penting?

Karena internet sudah cukup penuh dengan div yang cosplay jadi button.

Secara visual kelihatan seperti tombol. Mouse bisa klik. JavaScript jalan. Tetapi keyboard behavior tidak lengkap, focus tidak jelas, accessible name kosong, dan state tidak terekspos dengan benar.

Manusia tertentu langsung kena dampaknya.

Agent yang mencoba memahami control juga mendapat interface yang lebih ambiguous.

Accessibility tree menjadi menarik lagi

Browser tidak cuma punya visual rendering. Ia juga membangun representasi informasi yang dapat digunakan assistive technology melalui accessibility APIs. Nama, role, state, hubungan, dan struktur yang berasal dari HTML serta ARIA dapat diekspos melalui layer tersebut.

Tidak berarti semua AI agent pasti menggunakan accessibility tree dengan cara yang sama. Sebagian agent menggunakan screenshot, vision, DOM, browser controls, accessibility information, atau kombinasi beberapa sinyal. Implementasi bisa berubah dan berbeda antarproduk.

Namun secara arsitektural, ide dasarnya powerful: interface yang memiliki semantics programatik memberi mesin lebih dari sekadar pixel.

Bayangkan dua tombol berbentuk ikon hati.

Yang pertama hanya SVG yang diberi click handler.

Yang kedua adalah button native dengan accessible name “Simpan ke favorit” dan state yang menunjukkan apakah item sudah tersimpan.

Bagi mata manusia, keduanya mungkin identik.

Bagi software, versi kedua menjelaskan lebih banyak hal: ini control interaktif, tujuannya menyimpan favorit, dan state-nya bisa berubah.

Di sinilah accessibility terasa seperti infrastructure.

Accessible name bukan dekorasi

Salah satu konsep yang paling mudah dipahami adalah accessible name.

Sebuah button perlu mempunyai nama yang menjelaskan fungsinya. Pada button native, text di dalamnya sering menjadi accessible name secara otomatis. Bila desain memang tidak memiliki visible text, aria-label atau aria-labelledby dapat digunakan sesuai kebutuhan.

Masalah muncul ketika icon-only design menjadi default tetapi semantics dianggap bonus.

Ada tombol bergambar trash can tanpa nama.

Ada tiga tombol identical berupa titik tiga pada card yang berbeda.

Ada menu hamburger yang sebenarnya membuka account switcher, bukan navigation.

Ada tombol “X” yang kadang berarti close dialog, kadang cancel transaction.

Manusia mengandalkan posisi dan visual convention. Agent harus menggabungkan berbagai sinyal untuk menebak.

Accessible name yang tepat mengurangi ambiguity.

Namun jangan kebalikannya. ARIA label yang terlalu panjang, misleading, atau tidak sinkron dengan visible text juga problem. WCAG punya konsep Label in Name untuk memastikan label programatik tetap berhubungan dengan kata yang dilihat user. Ini penting untuk pengguna speech input dan konsistensi interface secara umum.

Buat agentic UX, alignment itu masuk akal. Satu control sebaiknya tidak punya dua cerita berbeda.

State lebih penting daripada sekadar role

Mengetahui suatu elemen adalah button belum cukup.

Apakah menu sedang terbuka?

Apakah tab sedang selected?

Apakah checkbox aktif?

Apakah combobox expanded?

Apakah form field invalid?

Apakah item disabled?

Apakah proses masih loading?

Interactive website adalah rangkaian state transition. Kalau state hanya terlihat melalui warna atau animation, software perlu menafsirkan lebih banyak hal secara visual.

ARIA menyediakan sejumlah state dan property untuk pola tertentu. Native HTML juga sudah membawa banyak state secara bawaan. Keduanya harus diimplementasikan sesuai semantics dan selalu sinkron dengan real behavior.

Ini bagian yang sering gagal.

Developer menambahkan aria-expanded="false", lalu JavaScript membuka menu tetapi atributnya tidak pernah berubah. Secara visual menu terbuka. Secara programatik masih tertulis false.

Buat accessibility, itu bug.

Buat agent, itu conflicting evidence.

Jadi “pakai ARIA” tidak otomatis lebih baik. ARIA yang salah dapat membuat interface lebih membingungkan daripada tidak menambah atribut palsu sama sekali.

Native HTML tetap first choice

Ketika topik ARIA masuk AI, ada risiko tim mulai menempel role pada semuanya.

W3C justru punya prinsip yang berulang: kalau native host language menyediakan elemen yang benar, gunakan itu.

Kenapa?

Karena native element membawa behavior yang sudah dipahami browser. Button punya keyboard interaction. Input punya form semantics. Select punya pola bawaan. Heading membawa struktur. Nav merepresentasikan navigation section.

Custom widget memang kadang diperlukan. Aplikasi kompleks tidak selalu bisa hidup dari control native sepenuhnya. Tetapi custom berarti tim mengambil tanggung jawab lebih besar untuk keyboard behavior, focus management, naming, state, validation, dan interoperability.

Kalau tujuan kita membuat interface yang mudah dioperasikan manusia dan agent, mengurangi custom complexity sering lebih valuable daripada menambah patch ARIA setelah design selesai.

Accessibility tidak boleh dibajak oleh narasi AI

Ada satu hal yang harus dijaga.

Jangan sampai organisasi baru peduli accessibility karena “AI butuh ARIA”.

Itu membalik prioritas.

ARIA dibuat untuk membantu manusia dengan kebutuhan accessibility. Manfaat untuk agent adalah additional incentive, bukan pengganti alasan utama. Kalau tim hanya mengoptimalkan atribut yang kebetulan membantu automation tetapi masih membuat experience buruk bagi screen reader user, keyboard user, atau orang dengan kebutuhan kognitif tertentu, implementasinya gagal secara fundamental.

Cara yang lebih sehat adalah berkata: accessibility menghasilkan interface semantics yang lebih eksplisit. Semantics ini penting bagi manusia, assistive technology, testing tools, browser, dan potentially agentic systems. Jadi investasi accessibility ternyata punya surface area manfaat yang lebih luas daripada yang selama ini dihitung perusahaan.

Itu framing yang fair.

Form adalah tempat ARIA sering disalahgunakan

Form punya banyak kebutuhan semantics, tetapi tidak semuanya perlu ARIA.

Label HTML yang terhubung dengan input sering lebih baik daripada sekadar menambahkan aria-label.

Required field dapat memakai mekanisme native yang sesuai dan diperjelas kepada user.

Error message perlu dihubungkan dengan field secara benar jika ingin dibaca assistive technology.

Status setelah submit perlu dapat diumumkan tanpa memaksa user mencari perubahan visual.

ARIA bisa membantu pada bagian tertentu, tetapi jangan menjadikannya plester untuk markup yang berantakan.

Misalnya placeholder bukan label. Kalau field hanya berisi placeholder “Email kantor”, lalu text itu hilang ketika user mengetik, context menjadi lebih lemah. Agent mungkin masih bisa mengisi, tetapi design tersebut tetap kurang robust.

Form yang sehat menjawab tiga hal dengan jelas:

Apa yang diminta?

Format apa yang diterima?

Apa yang salah jika validasi gagal?

Itu bagus untuk semua actor.

Dialog dan modal adalah ujian berikutnya

Custom modal sering jadi sumber chaos.

User menekan “Hapus akun”. Modal terlihat. Focus tetap berada di belakang. Escape tidak bekerja. Screen reader tidak mendapat title dialog. Background masih tabbable. Tombol “Ya” dan “Tidak” tidak menjelaskan konsekuensi.

Sekarang tambahkan AI agent ke situasi itu.

Agent melihat dua button generik “Ya” dan “Tidak”. Kalau konteks visual atau state tracking hilang, risiko interpretasi meningkat.

Pola dialog yang baik punya heading yang jelas, relationship semantics yang sesuai, focus management, action label yang spesifik, dan exit path yang dapat diprediksi.

Untuk destructive action, “Hapus akun permanen” lebih aman daripada “Ya”.

ARIA dapat membantu mengekspresikan dialog semantics, tetapi behavior tetap harus dibangun. Role tidak otomatis membuat focus trap, keyboard handling, atau confirmation logic muncul sendiri.

Inilah pelajaran penting dari accessibility engineering: semantics dan behavior harus cocok.

Testing statis tidak cukup

W3C sendiri mengingatkan bahwa accessibility interactive content tidak dapat dikonfirmasi hanya lewat static checks. Automated scanner bisa menemukan missing labels, invalid roles, atau beberapa kesalahan umum. Tetapi ia tidak selalu tahu apakah interaction benar-benar masuk akal ketika user menjalankan flow.

Hal yang sama berlaku pada agent-readiness.

Linting bagus.

Accessibility audit bagus.

Unit test bagus.

Tetapi workflow nyata tetap harus dijalankan.

Coba keyboard-only.

Coba screen reader bila tim mempunyai kompetensi atau tester yang tepat.

Coba browser automation.

Coba agent pada lingkungan staging dengan permission aman.

Perhatikan apakah interface dapat dipahami ketika layout visual tidak menjadi satu-satunya sumber informasi.

Dan jangan testing hanya happy path. Uji field kosong, invalid input, session timeout, duplicate submission, sold out, rate limit, dan user membatalkan di tengah proses.

ARIA bukan obat security

Karena ARIA membantu memberi meaning pada action, ada temptation untuk menganggap interface yang semantically jelas otomatis aman untuk agent.

Tidak.

Security boundary hidup di layer lain.

OpenAI sudah berulang kali memperingatkan tentang prompt injection pada browser agent, termasuk instruksi berbahaya yang disisipkan ke webpage. Sebuah tombol bisa sangat jelas bernama “Kirim data pelanggan ke endpoint eksternal” dan justru karena jelas, agent seharusnya tahu action itu sensitif.

ARIA menjelaskan. Authorization memutuskan.

Agent boleh membaca role dan name. Server tetap harus memeriksa permission.

Agent boleh mengisi form. Backend tetap memvalidasi.

Agent boleh menavigasi. Sensitive action tetap perlu policy dan confirmation.

Jangan pernah menjadikan client-side semantics sebagai trust boundary.

Apa yang perlu dilakukan tim website

Mulai dari component inventory, bukan dari plugin ajaib.

Audit button, link, menu, tabs, accordion, dialog, form, autocomplete, date picker, carousel, table interaktif, toast, dan custom widgets.

Untuk setiap komponen, periksa:

Apakah ada native element yang lebih tepat?

Apakah name-nya jelas?

Apakah role sesuai behavior?

Apakah state selalu sinkron?

Apakah keyboard interaction bekerja?

Apakah focus order masuk akal?

Apakah perubahan status dapat diketahui tanpa hanya mengandalkan warna atau motion?

Apakah visible wording sesuai consequence?

Apakah destructive action punya confirmation yang layak?

Setelah itu, baru uji dengan agent.

Bukan sebaliknya.

Accessibility sebagai infrastructure berarti organisasi berhenti melihatnya sebagai checklist kosmetik menjelang launch. Ia menjadi bagian design system, coding standard, QA, procurement, analytics, dan governance.

AI agent hanya membuat konsekuensinya makin kelihatan.

Pada akhirnya, ARIA tidak mendadak berubah fungsi pada 2026. Yang berubah adalah siapa saja yang mulai menghargai semantics yang selama ini sudah tersedia.

Ketika web cuma dianggap layar, banyak tim merasa cukup jika semuanya terlihat benar.

Ketika web menjadi permukaan yang dibaca assistive technology, diotomasi testing tools, dipahami search systems, dan dijalankan AI agent, “terlihat benar” tidak cukup.

Interface perlu mempunyai meaning yang bisa diproses.

Dan ternyata, praktik accessibility sudah membangun fondasi itu jauh sebelum istilah Agentic Web terdengar keren di ruang meeting.