Cara Menguji Aksesibilitas Form Web dengan Keyboard dan Screen Reader

Form yang terlihat benar belum tentu bisa dipakai semua orang

Bayangkan sebuah form pendaftaran yang tampak rapi di layar. Setiap input memiliki teks di dekatnya, tombol kirim terlihat jelas, dan validasi menampilkan pesan merah setelah data yang wajib dikosongkan. Namun, ketika seseorang hanya memakai keyboard, urutan Tab melompat dari nama ke tombol tanpa melewati email. Saat pengguna mengirim data yang salah, pesan error muncul di layar tetapi tidak dibacakan oleh screen reader. Pengguna harus menebak field mana yang perlu diperbaiki.

Masalah seperti ini tidak selalu terlihat dari pemeriksaan visual. Menguji aksesibilitas form berarti mencoba form melalui cara yang berbeda: memeriksa struktur dan hubungan antar-elemen, mengoperasikannya dengan keyboard, mengikuti perubahan fokus dan error, lalu melengkapinya dengan screen reader, zoom, dan pemeriksaan otomatis. Urutan tersebut membantu menemukan masalah yang benar-benar menghambat pengisian, bukan sekadar mengumpulkan peringatan dari sebuah alat.

Mulai dari struktur yang diterima browser

Sebelum menekan tombol apa pun, periksa struktur form melalui HTML dan accessibility tree browser. Tujuannya sederhana: setiap kontrol harus memiliki nama, jenis, hubungan, dan instruksi yang dapat dikenali oleh teknologi bantu.

Periksa hal-hal berikut:

• Gunakan elemen yang sesuai dengan fungsinya: input untuk masukan, button untuk aksi, dan select atau kontrol lain ketika memang itu pilihannya. Jangan mengubah elemen biasa menjadi tombol hanya dengan menambahkan event JavaScript.
• Pastikan setiap input memiliki label yang terhubung secara programatik. Teks placeholder bukan pengganti label karena dapat hilang ketika pengguna mulai mengetik.
• Kelompokkan pilihan yang berkaitan, seperti radio button atau checkbox untuk satu pertanyaan, dengan nama kelompok yang jelas.
• Pastikan instruksi, satuan, format, dan contoh tidak hanya disampaikan lewat warna atau posisi visual.
• Periksa apakah nama yang dibaca teknologi bantu sesuai dengan maksud kontrol. Label “Masukkan data” terlalu umum jika form meminta alamat email.
• Pastikan tombol mengungkapkan aksinya, misalnya “Kirim pendaftaran”, bukan hanya ikon tanpa nama yang dapat dibaca.

Accessibility tree berguna karena menunjukkan informasi yang biasanya dipakai screen reader: nama, role, nilai, dan status kontrol. Pemeriksaan ini belum membuktikan bahwa seluruh alur dapat digunakan. Ia hanya memberi dasar untuk pengujian interaksi berikutnya.

Contoh hubungan label, instruksi, dan error yang ringkas:

<label for="email">Alamat email</label>
<p id="email-help">Gunakan alamat yang masih aktif.</p>
<input id="email" name="email" type="email"
       aria-describedby="email-help email-error"
       aria-invalid="true">
<p id="email-error">Masukkan alamat email yang valid.</p>

Contoh itu baru bermakna jika elemen-elemen tersebut benar-benar ada ketika diperlukan, pesannya akurat, dan perubahan statusnya dapat diketahui pengguna. Atribut ARIA tidak memperbaiki struktur yang salah secara otomatis.

Jalankan alur keyboard dari awal sampai selesai

Lepaskan mouse dan ulangi seluruh tugas dengan keyboard. Mulai dari halaman sebelum form, bukan dari field pertama, agar urutan masuk ke form ikut teruji.

1. Tekan Tab dan Shift+Tab untuk memeriksa urutan fokus. Urutannya harus mengikuti alur membaca dan tugas pengguna, bukan urutan acak karena posisi visual.
2. Amati apakah setiap kontrol interaktif bisa dicapai. Jangan berhenti pada input teks; uji checkbox, radio button, select, tombol bantuan, date picker, dan kontrol yang muncul setelah pilihan tertentu.
3. Gunakan tombol yang lazim untuk kontrol tersebut. Enter atau Space dapat memiliki perilaku berbeda, dan kontrol kustom perlu diuji tanpa mengandalkan klik mouse.
4. Isi data yang valid, kosongkan field wajib, gunakan format yang salah, lalu perbaiki kembali. Aksesibilitas form juga mencakup kemampuan memulihkan kesalahan.
5. Cari keyboard trap: fokus masuk ke dialog, menu, atau widget tetapi tidak dapat keluar dengan keyboard. Pastikan Esc, Tab, atau aksi yang relevan mengembalikan pengguna ke alur yang masuk akal.

Catat nama kontrol yang dilewati, urutan yang membingungkan, dan aksi yang tidak bisa dilakukan. Jangan hanya menulis “keyboard bermasalah”; tulis langkah untuk mengulanginya, misalnya “dari field nomor telepon, tekan Tab; fokus berpindah ke teks statis dan tidak pernah mencapai tombol Kirim”.

Periksa fokus, bukan hanya urutannya

Fokus adalah penanda posisi pengguna saat bernavigasi tanpa mouse. Fokus yang berpindah tetapi tidak terlihat sama sulitnya dengan fokus yang tidak berpindah.

Pada setiap langkah keyboard, tanyakan:

• Apakah fokus terlihat jelas di latar dan di sekitar kontrol?
• Apakah fokus tidak tertutup oleh header tetap, dialog, atau elemen yang menempel di layar?
• Setelah validasi gagal, fokus tetap berada di tempat yang membantu pengguna memahami masalah atau dipindahkan ke ringkasan error yang jelas?
• Ketika konten baru muncul, apakah pengguna diberi konteks tanpa tiba-tiba dipindahkan ke lokasi yang tidak diperkirakan?
• Setelah dialog ditutup, apakah fokus kembali ke tombol atau kontrol yang membukanya?

Hapus outline bawaan tanpa menyediakan indikator pengganti adalah sinyal untuk diperiksa lebih lanjut. Warna fokus juga perlu diuji pada kondisi nyata, termasuk di atas latar gambar atau komponen dengan kontras rendah. Yang dicari bukan gaya tertentu, melainkan penanda yang konsisten dan mudah ditemukan.

Uji error sebagai bagian dari tugas, bukan keadaan khusus

Form sering diuji hanya dengan data sukses. Padahal pengguna yang membutuhkan bantuan paling banyak biasanya bertemu form ketika ada data yang tidak lengkap atau salah format. Buat skenario error secara sengaja:

• kosongkan semua field wajib;
• masukkan format email, tanggal, atau nomor yang tidak valid;
• masukkan nilai yang terlalu pendek atau di luar batas yang dijelaskan;
• kirim form lalu perbaiki satu error pada satu waktu;
• periksa apakah nilai yang sudah benar tetap tersimpan saat error ditampilkan.

Setiap error sebaiknya menjawab tiga pertanyaan: field mana yang bermasalah, apa yang salah, dan bagaimana memperbaikinya. Pesan “Input tidak valid” biasanya tidak cukup. Hubungkan pesan dengan field yang bersangkutan, tandai status invalid ketika memang ada error, dan sediakan ringkasan error jika alurnya panjang. Pastikan pengguna keyboard dan screen reader dapat menemukan ringkasan, field bermasalah, serta instruksinya.

Perhatikan juga waktu kemunculan pesan. Error yang hanya terlihat setelah kehilangan fokus dapat terlewat, sedangkan pesan yang muncul saat setiap karakter diketik dapat mengganggu. Uji perilaku yang dipilih dengan alur pengguna sebenarnya: kapan informasi dibutuhkan dan apakah perubahan status diumumkan secukupnya.

Dengarkan alur dengan screen reader

Pilih satu kombinasi browser, sistem operasi, dan screen reader yang tersedia, lalu isi form tanpa melihat layar sesekali. Dengarkan apakah setiap kontrol memiliki nama dan konteks yang cukup. Navigasikan berdasarkan heading, landmark, dan kontrol form bila fitur tersebut tersedia pada screen reader yang dipakai.

Periksa khususnya:

• apakah label dibacakan saat fokus masuk ke input;
• apakah tipe dan status kontrol terdengar masuk akal;
• apakah instruksi tambahan dibaca pada waktu yang tepat;
• apakah pilihan radio atau checkbox menyebutkan kelompoknya;
• apakah error dibacakan setelah submit dan saat fokus kembali ke field;
• apakah perubahan dinamis, seperti field tambahan atau hasil pencarian, memiliki konteks yang dapat ditemukan;
• apakah tombol dan tautan dibedakan dengan jelas.

Satu kombinasi perangkat hanya menunjukkan satu pengalaman. Browser, sistem operasi, screen reader, bahasa, dan cara navigasi dapat mengubah hasil. Karena itu, catat pasangan yang digunakan dan jangan menyimpulkan bahwa form dapat dipakai oleh semua orang hanya karena satu sesi screen reader berhasil. Jika form penting bagi produk, tambahkan kombinasi lain dan, bila memungkinkan, minta orang yang menggunakan teknologi bantu dalam aktivitas sehari-hari untuk mencoba tugas tersebut.

Uji zoom dan ruang yang menyempit

Perbesar halaman hingga setidaknya 200 persen sebagai pemeriksaan praktis yang umum untuk form, lalu ulangi tugas utama. Amati apakah label dan input masih berpasangan, tombol tetap dapat dijangkau, dialog tidak memotong isinya, dan pesan error tidak tertutup.

Uji juga lebar viewport yang lebih sempit. Konten boleh tersusun ulang, tetapi pengguna tidak seharusnya kehilangan field, tombol, atau instruksi penting karena komponen meluber. Scroll horizontal yang diperlukan untuk membaca satu baris panjang, kontrol yang keluar dari layar, dan teks yang tertindih adalah temuan yang perlu dicatat. Jangan menganggap tampilan responsif pada ukuran ponsel sebagai bukti bahwa form aman pada semua tingkat pembesaran; keduanya adalah kondisi yang berbeda.

Gunakan otomatisasi sebagai pemeriksaan tambahan

Setelah pemeriksaan manual, jalankan alat otomatis yang tersedia, misalnya pemindai aksesibilitas di browser atau layanan seperti axe, WAVE, atau Lighthouse. Alat tersebut dapat membantu menemukan pola tertentu seperti label yang hilang, atribut yang salah, atau kontras yang perlu diperiksa. Hasilnya berguna untuk mempercepat penyaringan dan mencegah masalah yang berulang.

Namun, hasil bersih bukan bukti bahwa alur form dapat digunakan. Pemindai tidak memahami semua maksud label, tidak selalu menilai apakah urutan fokus masuk akal, dan tidak menggantikan keyboard, screen reader, zoom, atau pengujian tugas. Sebaliknya, peringatan otomatis juga perlu dibaca konteksnya sebelum langsung dianggap sebagai bug. Simpan nama alat, versi atau tanggal pemeriksaan jika tersedia, halaman yang diuji, dan temuan yang sudah diverifikasi secara manual.

Triage: perbaiki hambatan tugas terlebih dahulu

Buat issue log sederhana dengan kolom: langkah reproduksi, kontrol atau halaman, pengalaman yang gagal, pengguna yang terdampak, bukti, tingkat dampak, dan verifikasi ulang. Prioritaskan dengan pertanyaan berikut:

1. Apakah pengguna tidak dapat mencapai atau mengoperasikan kontrol sama sekali?
2. Apakah pengguna dapat mengisi form tetapi tidak dapat mengetahui fokus, status, atau error?
3. Apakah ada jalan keluar yang jelas tanpa mengulang seluruh tugas?
4. Apakah masalah hanya visual atau juga memutus alur keyboard, screen reader, zoom, atau pemulihan error?

Hambatan operasional dan masalah pemulihan error biasanya perlu ditangani sebelum perapian minor. Setelah perbaikan, jalankan lagi skenario yang sama dengan kombinasi pengujian yang sama, lalu tambahkan regresi untuk komponen yang dipakai ulang. Jangan menutup issue hanya karena satu alat otomatis tidak lagi memberi peringatan.

Kerangka ini membantu memisahkan tiga hal: struktur yang bisa diperiksa dari kode dan accessibility tree, perilaku yang harus dicoba manusia, dan pemeriksaan otomatis yang hanya melengkapi keduanya. Catatan hasilnya membuat keputusan perbaikan dapat ditelusuri tanpa mengubah satu checklist menjadi klaim bahwa form sudah sempurna.