Aksesibilitas website dan aplikasi: mulai dari alur pengguna

Apa yang dimaksud website yang aksesibel?

Website yang tetap dapat dipakai ketika pengguna tidak mengandalkan penglihatan, mouse, pendengaran, atau cara interaksi yang sama. Pertanyaan utamanya: dapatkah orang menyelesaikan pekerjaan, seperti mendaftar, membaca tagihan, dan meminta bantuan?

WCAG (Web Content Accessibility Guidelines) dari W3C menyediakan kriteria untuk menilai aksesibilitas konten web. Tentukan versi dan tingkat yang dituju, misalnya WCAG 2.2 tingkat AA, dalam lingkup pekerjaan. Tingkat AA mencakup kriteria A dan AA. Menulis target itu dalam kontrak berbeda dari membuktikan bahwa hasilnya sudah memenuhi target.

Halaman ini membahas persiapan pemeriksaan web, termasuk aplikasi berbasis web. Ini tidak menetapkan satu kewajiban WCAG yang berlaku otomatis pada semua usaha di Indonesia. Periksa aturan sektor dan persyaratan pengadaan yang benar-benar berlaku pada layanan Anda.

Apakah skor aksesibilitas 100 sudah cukup?

Belum. W3C menjelaskan bahwa alat otomatis saja tidak dapat menentukan kesesuaian aksesibilitas; pemeriksaan manusia tetap diperlukan. Sebuah alat dapat mendeteksi label kosong, tetapi belum tentu mengetahui apakah label tersebut menjelaskan pertanyaan dengan benar.

Dalam WCAG, kesesuaian juga memperhatikan halaman secara utuh dan proses lengkap. Menguji halaman masuk saja tidak cukup untuk menyimpulkan bahwa seluruh proses pemesanan aksesibel. Catat versi aplikasi, halaman, keadaan kesalahan, perangkat, cara pemeriksaan, dan bagian yang belum diperiksa.

Pilih alur yang benar-benar dipakai

Contoh rencana pemeriksaan Kompli untuk portal pelanggan fiktif:

Alur	Situasi yang dicoba	Hasil yang dicatat
Masuk dan pemulihan akun	Pengguna memakai keyboard dan pengelola kata sandi	Hambatan yang membuat pengguna tidak bisa melanjutkan
Mengisi alamat	Ada kolom kosong dan format keliru	Apakah pengguna tahu bagian mana yang perlu diperbaiki
Memilih paket	Tampilan diperbesar dan layar sempit	Informasi harga atau tombol yang hilang/bertumpuk
Membayar	Dialog konfirmasi dibuka lalu ditutup	Perpindahan fokus dan jalan kembali ke transaksi
Membaca tagihan	Dokumen diunduh dan dibaca dengan teknologi bantu	Struktur bacaan, judul tabel, serta informasi yang hilang

Tabel ini adalah rancangan uji, bukan laporan bahwa portal tersebut telah diuji. Pilih kombinasi peramban dan teknologi bantu sesuai pengguna layanan. Aplikasi native memerlukan pemeriksaan platformnya sendiri.

Apa yang perlu dibahas dengan pengembang?

WCAG memuat kriteria tentang alternatif teks, penggunaan keyboard, fokus yang terlihat, label, pesan kesalahan, dan autentikasi yang aksesibel. Gunakan kriteria terkait untuk menjelaskan masalah secara spesifik, bukan sekadar meminta “lebih ramah pengguna”.

Contoh temuan fiktif: setelah pesan alamat gagal muncul, fokus pindah ke bagian atas halaman. Catatan perbaikannya mencakup langkah yang memicu masalah, dampak pada pengguna, hasil yang diharapkan, serta cara menguji ulang. Jika perubahan komponen formulir dipakai di banyak halaman, periksa alur lain yang ikut terpengaruh.

Bagaimana menerima laporan vendor?

Minta lingkup, versi standar, metode, halaman/keadaan yang diperiksa, bukti masalah, dampak, perbaikan, dan hasil pemeriksaan ulang. Pisahkan hasil otomatis, pemeriksaan manual, serta pengujian bersama pengguna dengan disabilitas. Ketiganya memberi bukti yang berbeda.

Hindari klaim “semua pengguna pasti bisa mengakses” dari sampel kecil. Jika membuat pernyataan aksesibilitas, tulis lingkup yang dinilai, keterbatasan yang diketahui, tanggal, dan saluran bantuan yang benar-benar tersedia. Jangan memasang logo atau pernyataan kesesuaian yang belum didukung pemeriksaan.

Gunakan checklist pemeriksaan aksesibilitas untuk membagi tugas. Masukkan pemeriksaan ke persiapan peluncuran website, lalu ulangi saat alur atau komponen penting berubah.