Karyawan AI untuk Uji Navigasi Keyboard Website: Temukan Hambatan Sebelum Pelanggan Menyerah

Ditulis oleh Nugraha Labib Mujaddid, pembuat AgentBuff.

Website yang bisa diklik belum tentu bisa dipakai tanpa mouse. Untuk usaha kecil, pemeriksaan paling berguna adalah mencoba satu perjalanan pelanggan dengan keyboard, mencatat titik macet, lalu memberi pengelola web bukti yang bisa diulang. Karyawan AI membantu menyusun skenario dan merapikan temuan. Ia tidak boleh menyatakan website aksesibel hanya dari screenshot atau skor otomatis.

Bayangkan calon peserta kursus membuka halaman kelas, memilih jadwal, lalu terjebak dalam pop-up promo karena tombol tutup tidak bisa dijangkau. Materi kelasnya bagus dan formulirnya menyimpan data dengan benar, tetapi perjalanan pelanggan tetap putus. Contoh ini ilustrasi, bukan temuan pengujian situs tertentu. Artikel ini membahas akses keyboard dan pengelolaan fokus, bukan audit seluruh persyaratan aksesibilitas.

Apa yang sebenarnya diperiksa

W3C menjelaskan bahwa fungsionalitas konten perlu dapat dioperasikan melalui antarmuka keyboard, dengan pengecualian tertentu untuk fungsi yang bergantung pada lintasan gerakan, seperti menggambar bebas.[3] Jadi, tujuan tes bukan membuat setiap piksel bisa ditekan Tab. Tujuannya memastikan pengguna dapat menyelesaikan tindakan yang setara tanpa harus memakai penunjuk.

Ada tiga pertanyaan operasional. Bisakah pengguna mencapai dan mengaktifkan fungsi yang dibutuhkan? Apakah mereka mengetahui posisi fokus sekarang? Bisakah mereka keluar dari komponen dan melanjutkan tugas? Standar Keyboard, Focus Visible, serta No Keyboard Trap memberi dasar untuk memisahkan ketiga masalah ini.[3][10][4]

Pemeriksaan awal tetap terbatas. W3C menyatakan Easy Checks bukan evaluasi aksesibilitas lengkap dan penilaian profesional tambahan diperlukan untuk evaluasi menyeluruh.[13] Jangan menempelkan klaim “lulus WCAG” pada laporan yang hanya memeriksa satu alur di satu browser.

Mulai dari perjalanan, bukan daftar tombol

Pilih perjalanan yang bernilai bagi usaha: mencari paket jasa dan membuka kontak, memilih varian produk hingga meninjau keranjang, atau menemukan jadwal kelas dan membaca persyaratan pendaftaran. Untuk mahasiswa atau kreator, perjalanan bisa berupa membuka portofolio, memilih proyek, lalu mengunduh contoh karya.

Tuliskan titik mulai, hasil akhir, halaman yang dilalui, serta batas tindakan. Contohnya: mulai dari halaman kursus, buka informasi jadwal, pilih kelas percobaan, isi data sintetis di staging, dan berhenti sebelum pengiriman. Jangan mengaktifkan pembelian, mengirim pesan pelanggan, membuat akun, atau memesan kapasitas tanpa izin yang sesuai.

Catat browser, sistem operasi, ukuran viewport, versi halaman, status login, serta pengaturan navigasi keyboard yang relevan. Perbedaan pengaturan browser atau sistem dapat memengaruhi elemen yang masuk lintasan fokus. Jika agen tidak tahu konfigurasi pengujinya, ia perlu mencatat ketidakpastian, bukan langsung menyimpulkan tombol situs rusak.

Siapkan kartu uji dan batas akses agen

Satu kartu cukup memuat ID kasus, URL, kondisi awal, tombol yang ditekan, hasil yang diharapkan, hasil aktual, bukti, dan status. Gunakan lulus, gagal, terhalang, atau belum diuji. Tidak ada akses browser berarti agen belum melakukan pengujian langsung, meski rencana ujinya sudah rapi.

Beri agen akses baca ke daftar halaman dan spesifikasi komponen. Jika tersedia browser yang diizinkan, tentukan tindakan aman secara eksplisit. Agen boleh membuka menu informasi, tetapi tidak otomatis boleh mengirim formulir. Jangan berikan akses administrasi situs hanya untuk mencatat masalah navigasi publik.

Simpan hasil harapan sebelum eksekusi. Misalnya, dialog jadwal bisa dibuka lewat keyboard, fokus masuk ke dialog, pengguna dapat menutupnya, lalu melanjutkan dari posisi yang logis. Jika harapan berubah setelah pengembang menjelaskan desain, tandai sebagai revisi kriteria dan ulangi tes. Jangan menulis ulang sejarah agar semua tampak lulus.

Lintasan pertama: jangkau fungsi tanpa bantuan mouse

Mulai dari pemuatan halaman yang bersih. Gunakan Tab dan Shift+Tab untuk bergerak di antara kontrol sesuai perilaku browser. Coba aktivasi yang sesuai dengan jenis kontrol. W3C menyebut Enter dan Space sebagai konvensi umum untuk tombol, tetapi juga menjelaskan bahwa penyimpangan dari konvensi itu tidak otomatis melanggar persyaratan Keyboard apabila fungsinya tetap dapat dioperasikan.[3]

Jangan mengharapkan semua pilihan di widget kompleks menjadi perhentian Tab terpisah. Catat petunjuk yang tersedia dan minta pengelola menjelaskan pola komponen bila perilakunya tidak jelas. Tugas penguji adalah memeriksa penyelesaian fungsi, bukan memaksakan satu urutan tombol untuk seluruh jenis widget.

Perhatikan menu yang hanya muncul saat hover, pemilih varian yang hanya merespons klik, dan tautan gambar yang tidak memberi petunjuk tujuan. Jika satu jalur gagal, cari apakah ada cara setara yang dapat ditemukan dan digunakan dengan keyboard. Jangan menandai seluruh fungsi gagal hanya karena satu kontrol visual bukan satu-satunya jalur yang disediakan.

Contoh untuk toko kerajinan: kartu warna bisa tidak masuk lintasan Tab, tetapi tersedia pilihan varian berbentuk kontrol lain yang jelas dan setara. Laporkan cara yang benar-benar tersedia. Jika tidak ada alternatif, dokumentasikan bagaimana pelanggan terhalang memilih varian sebelum menilai dampaknya.

Lintasan kedua: ikuti fokus, bukan hanya hasil akhir

Indikator fokus memberi tahu kontrol yang akan menerima tindakan berikutnya. W3C menjelaskan bahwa antarmuka yang dapat dioperasikan lewat keyboard harus memiliki mode operasi dengan indikator fokus terlihat.[10] Penguji perlu melihat perpindahan ini saat menekan tombol, bukan hanya memeriksa bahwa halaman akhirnya berubah.

Ambil bukti pada saat masalah terjadi. Screenshot halaman yang tidak sedang difokuskan tidak membuktikan indikator hilang. Rekaman pendek yang memperlihatkan urutan tombol dan perubahan tampilan biasanya lebih mudah ditinjau daripada satu gambar tanpa konteks. Samarkan nama, alamat, dan informasi akun sebelum membagikan bukti.

Periksa header lengket, banner cookie, widget chat, serta footer promosi. WCAG 2.2 Focus Not Obscured (Minimum) membahas komponen yang menerima fokus agar tidak seluruhnya tersembunyi oleh konten buatan pembuat halaman.[11] Bedakan komponen tertutup total dari komponen tertutup sebagian; jangan mengubah persyaratan minimum menjadi aturan yang tidak dinyatakan sumber.

Sebagai rekomendasi desain, usahakan kontrol terlihat penuh agar pengguna tidak harus menebak. Namun tuliskan rekomendasi itu terpisah dari kesimpulan terhadap kriteria tertentu. Agen harus bisa mengatakan “perlu perbaikan kenyamanan” tanpa menyulapnya menjadi vonis kegagalan standar.

Lintasan ketiga: masuk dan keluar dari dialog

Pop-up diskon, pemilih tanggal, pratinjau gambar, dan dialog konfirmasi memerlukan perhatian khusus. Fokus yang berputar di dalam dialog modal tidak otomatis merupakan keyboard trap. W3C menjelaskan pembatasan fokus dapat sesuai selama pengguna tahu cara keluar dengan keyboard.[4]

Pola dialog modal WAI-ARIA APG menyarankan fokus berpindah ke dalam dialog saat dibuka, Tab dan Shift+Tab tetap di dalamnya, serta Escape menutup dialog. Saat ditutup, fokus umumnya kembali ke pemicu, dengan pengecualian yang masuk akal untuk alur kerja.[12] Gunakan pola ini sebagai acuan implementasi dan pengujian, bukan anggapan bahwa setiap overlay adalah modal.

Catat apakah kontrol tutup dapat digunakan, apakah tindakan pembatalan jelas, dan ke mana fokus berpindah setelah dialog selesai. Jangan menekan tombol persetujuan transaksi hanya demi membuktikan bisa keluar. Tombol batal atau tutup yang aman merupakan jalur uji yang lebih tepat jika tersedia.

Contoh jasa fotografi: dialog galeri boleh menahan fokus ketika terbuka. Masalah muncul jika pengguna tidak dapat menutupnya dengan keyboard dan tidak mendapat petunjuk keluar. Laporan yang baik menyertakan langkah membuka, tombol yang dicoba, kontrol yang tersedia, dan keadaan setelahnya. Kalimat “popup error” tidak cukup membantu pengembang.

Ubah pengamatan menjadi tiket yang bisa diperbaiki

Gunakan satu tiket untuk satu perilaku yang dapat direproduksi. Format ringkasnya: kondisi awal, langkah, harapan, pengamatan, dampak tugas, bukti, lingkungan, dan pemilik tindak lanjut. Cantumkan versi situs atau waktu uji agar hasil tidak tertukar setelah rilis baru.

Contoh tiket ilustratif: “Pada halaman jadwal versi uji, buka dialog dari tombol Jadwal dengan keyboard. Fokus berpindah ke kolom pencarian. Setelah tombol Tutup diaktifkan, fokus kembali ke awal halaman, bukan pemicu atau posisi lanjutan yang logis. Pengguna harus menelusuri menu lagi.” Tim teknis kemudian memeriksa penyebab dan pilihan perbaikan; agen tidak perlu mengarang nama fungsi kode.

Prioritaskan berdasarkan hambatan tugas. Tidak bisa memilih layanan atau keluar dari overlay lebih mendesak daripada urutan yang sedikit berputar tetapi masih jelas. Jika klasifikasi terhadap WCAG belum pasti, tandai “perlu tinjauan aksesibilitas”. Kepastian palsu hanya menambah pekerjaan saat tiket diperdebatkan.

Jangan memakai jumlah temuan sebagai ukuran kualitas tunggal. Laporan dengan sedikit temuan tetapi langkah reproduksinya jelas lebih berguna daripada puluhan dugaan dari screenshot. Catat pula halaman dan keadaan yang belum diuji agar pemilik usaha mengetahui batas keputusan.

Bagi pekerjaan AI dan manusia dengan jujur

Karyawan AI cocok menyusun matriks kasus dari daftar komponen, merapikan catatan, mengelompokkan temuan berulang, serta menyiapkan daftar pengujian ulang. Jika tools mendukung interaksi keyboard nyata, agen dapat membantu menjalankan kasus yang diizinkan dan menyimpan jejaknya. Jika tidak, pekerjaan eksekusi tetap dilakukan penguji manusia.

Klik melalui koordinat atau menjalankan fungsi JavaScript langsung tidak membuktikan jalur keyboard bekerja. Screenshot dan pembacaan struktur halaman dapat membantu diagnosis, tetapi tidak menggantikan percobaan interaksi. Instruksikan agen untuk menyebut metode yang dipakai pada setiap temuan, termasuk ketika bukti hanya berasal dari catatan penguji.

Pengembang memutuskan dan menerapkan perubahan kode. Penguji menilai ulang perilaku setelah perbaikan. Pemilik proses menentukan apakah hambatan yang masih terbuka menghalangi rilis. Untuk kebutuhan evaluasi menyeluruh, libatkan orang yang kompeten dan pengguna teknologi bantu yang relevan, tanpa menganggap pemeriksaan keyboard saja mewakili seluruh pengalaman mereka.

Instruksi kerja yang bisa dipakai ulang

Susun uji navigasi keyboard untuk perjalanan pelanggan dan URL yang saya berikan. Pisahkan hasil harapan dari pengamatan. Catat konfigurasi browser, kondisi awal, urutan tombol, posisi fokus, bukti, serta status lulus, gagal, terhalang, atau belum diuji. Jangan memakai klik mouse atau pemanggilan JavaScript sebagai bukti akses keyboard. Jangan mengirim formulir, membeli, mengubah kode, atau membuat akun tanpa izin khusus. Bedakan kriteria WCAG, pola implementasi APG, dan rekomendasi kenyamanan. Jangan menyatakan kepatuhan menyeluruh. Keluarkan tiket yang dapat diulang dan daftar pengujian ulang.

Sebelum menjalankan rutin, uji instruksi dengan contoh kontrol yang bisa digunakan, indikator fokus hilang, komponen tertutup banner, dialog yang dapat ditutup, serta kasus terhalang oleh konfigurasi penguji. Agen harus mempertahankan ketidakpastian, bukan menaikkan semua kasus menjadi temuan pasti.

Selesaikan putaran dengan pengujian ulang

Setelah perbaikan, ulangi langkah awal dengan konfigurasi yang dicatat. Verifikasi kasus gagal, jalur normal, navigasi mundur, dan komponen bersama yang ikut berubah. Simpan bukti baru, bukan hanya komentar “sudah diperbaiki” dari pengembang. Jika masalah tidak muncul lagi tetapi versi pengujian berbeda, sebutkan perbedaannya.

Catat jumlah perjalanan yang selesai tanpa mouse di dalam cakupan, penghalang yang belum ditutup, kasus terhalang, dan temuan yang muncul lagi. Hindari mengubahnya menjadi persentase aksesibilitas seluruh situs. Jadwalkan pemeriksaan setelah perubahan navigasi, template, banner, atau widget, bukan hanya sekali ketika website diluncurkan.

Panduan alt text dan subtitle melengkapi sisi konten, sedangkan uji formulir website menelusuri kiriman sampai tujuan operasional. Keduanya tidak menggantikan pemeriksaan interaksi keyboard yang menjadi fokus artikel ini.

Memulai melalui AgentBuff

Situs resmi AgentBuff menjelaskan karyawan AI lewat chat, sambungan alat kerja, serta tugas terjadwal.[1] Untuk workflow ini, mulailah dari agen perapih rencana dan bukti dengan akses minimum. Pastikan kemampuan tools di lingkungan Anda sebelum meminta eksekusi browser; artikel ini bukan janji bahwa semua sambungan otomatis menyediakan pengujian aksesibilitas.

Jika pendekatan ini cocok, ajukan akses AgentBuff. Halaman pendaftaran saat diperiksa menyatakan akun baru dibuka bertahap melalui pengajuan, sehingga jangan mengasumsikan aktivasi langsung.[2] Mulai dari satu perjalanan pelanggan dan satu laporan yang dapat dipakai pengelola web untuk memperbaiki hambatan nyata.

Tentang penulis

Nugraha Labib Mujaddid adalah pembuat AgentBuff.

Sources

[1] https://agentbuff.id [2] https://agentbuff.id/register [3] https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html [4] https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html [10] https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html [11] https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html [12] https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal [13] https://www.w3.org/WAI/test-evaluate/preliminary