Anatomi Laporan Audit Aksesibilitas (Bug Report & ACR/VPAT)

Menemukan masalah aksesibilitas hanyalah setengah dari pekerjaan seorang auditor. Setengah lainnya — yang sering kali lebih menentukan profesionalisme — adalah kemampuan mendokumentasikan dan mengomunikasikan temuan tersebut dengan cara yang langsung dapat ditindaklanjuti oleh tim teknis yang menerimanya.

"Tombol ini tidak berfungsi dengan screen reader" adalah keluhan pengguna. "Elemen div dengan event listener onClick tidak memiliki role=\"button\", tabindex=\"0\", atau penanganan event onKeyPress, menyebabkan kegagalan pada WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A)" adalah laporan auditor profesional.

Artikel ini mengajarkan Anda cara menulis yang kedua.

---

Dua Jenis Dokumen Output Auditor

Seorang auditor aksesibilitas menghasilkan dua jenis dokumen utama:

1. Bug Report (Laporan Bug): Dokumen internal atau laporan proyek yang berisi daftar spesifik isu yang ditemukan, beserta langkah reproduksi dan rekomendasi perbaikan. Ini adalah alat komunikasi sehari-hari dengan tim developer.
2. ACR (Accessibility Conformance Report) / VPAT: Dokumen formal yang merangkum tingkat kepatuhan (conformance) sebuah produk terhadap standar aksesibilitas (biasanya WCAG 2.1/2.2 dan Section 508). Ini dibutuhkan dalam konteks pengadaan pemerintah, enterprise, atau sebagai bukti legal.

Seorang anggota Access Squad harus mampu menghasilkan keduanya.

---

Anatomi Sebuah Bug Report yang Baik

Setiap entri dalam laporan bug aksesibilitas harus terdiri dari komponen-komponen berikut:

1. Judul Isu (Issue Title)

Judul yang baik langsung menggambarkan masalah dan komponen yang terpengaruh.

• ❌ Buruk: "Gambar tidak aksesibel"
• ✅ Baik: "Gambar produk di halaman PDP tidak memiliki alt text deskriptif"

2. Lokasi (Location)

URL spesifik, nama layar (untuk mobile), atau jalur navigasi (breadcrumb) untuk menemukan isu tersebut.

• Contoh: https://example.com/produk/sepatu-lari atau App → Beranda → Kartu Produk → Gambar Utama

3. Langkah Reproduksi (Steps to Reproduce)

Instruksi yang dapat diikuti oleh developer (yang tidak buta) untuk mereplikasi isu yang sama.

Contoh:

1. Buka halaman https://example.com/produk/sepatu-lari menggunakan NVDA + Chrome.
2. Tekan G untuk melompat ke elemen gambar pertama.
3. Dengarkan apa yang diumumkan oleh NVDA.
4. Hasil yang Diharapkan: NVDA mengumumkan deskripsi gambar, misalnya "Foto sepatu lari merah model XR-200 dari sudut samping".
5. Hasil Aktual: NVDA mengumumkan nama file, misalnya "img_prod_12345_final_v2.jpg" — tidak bermakna bagi pengguna.

4. Pemetaan WCAG (WCAG Mapping)

Setiap isu harus dipetakan ke Kriteria Sukses WCAG yang spesifik. Ini adalah yang membedakan auditor profesional dari pengguna biasa.

Kriteria Sukses yang Paling Sering Muncul:

Kriteria Sukses	Level	Deskripsi Singkat
1.1.1 Non-text Content	A	Semua konten non-teks (gambar) memerlukan alternatif teks.
1.3.1 Info and Relationships	A	Struktur informasi (heading, list, table) harus diekspresikan lewat markup.
2.1.1 Keyboard	A	Semua fungsionalitas harus dapat dicapai via keyboard.
2.4.3 Focus Order	A	Urutan navigasi fokus harus logis dan bermakna.
2.4.6 Headings and Labels	AA	Heading dan label harus deskriptif.
4.1.2 Name, Role, Value	A	Semua komponen UI harus memiliki nama, peran, dan nilai yang dapat ditentukan secara programatik.
4.1.3 Status Messages	AA	Pesan status harus dapat diprogram agar dapat ditentukan oleh teknologi asistif tanpa perpindahan fokus.

5. Penilaian Severity (Tingkat Keparahan)

Setiap isu memiliki dampak yang berbeda. Auditor harus menilai severity agar developer dapat memprioritaskan perbaikan.

Level	Deskripsi	Contoh
🔴 Blocker	Pengguna tunanetra tidak dapat sama sekali menyelesaikan tugas kritis.	Tombol "Bayar Sekarang" tidak dapat difokus dengan keyboard.
🟠 Critical	Pengguna tunanetra menghadapi hambatan besar yang memaksa alur kerja alternatif yang jauh lebih sulit.	Formulir checkout tidak mengumumkan pesan error, memaksa pengguna memeriksa manual.
🟡 Major	Pengalaman terdampak signifikan, namun tugas masih bisa diselesaikan.	Gambar produk tidak punya alt text — pengguna masih bisa membeli, namun kehilangan konteks produk.
🟢 Minor	Penyimpangan dari praktik terbaik yang mengurangi kualitas pengalaman.	Beberapa link menggunakan teks "Klik di Sini" — dapat diidentifikasi dari konteks, namun tidak ideal.

---

Anatomi ACR/VPAT yang Profesional

VPAT (Voluntary Product Accessibility Template) adalah template standar yang dikembangkan oleh ITI (Information Technology Industry Council). Ketika sebuah perusahaan ingin menjual produknya ke pemerintah AS atau organisasi enterprise besar, mereka wajib menyediakan VPAT yang sudah diisi.

Seorang auditor mengisi VPAT untuk kliennya. Setiap baris berisi:

• Kriteria: Referensi Kriteria Sukses WCAG.
• Level Konformitas: Salah satu dari: Supports (memenuhi), Partially Supports (memenuhi sebagian), Does Not Support (tidak memenuhi), Not Applicable (tidak relevan).
• Keterangan: Deskripsi konkret tentang bagaimana kriteria ini dipenuhi atau tidak, disertai contoh.

Contoh pengisian baris VPAT:

Kriteria	Level Konformitas	Keterangan
1.1.1 Non-text Content	Partially Supports	Gambar produk pada halaman PDP dan kategori tidak memiliki alt text. Gambar ikon navigasi sudah memiliki alt text yang sesuai.
2.1.1 Keyboard	Does Not Support	Komponen "Image Zoom" yang muncul saat hover tidak dapat diakses atau dinonaktifkan via keyboard.

---

Tips Penting untuk Anggota Access Squad

1. Selalu catat versi. Tuliskan versi aplikasi/OS dan screen reader yang digunakan. Bug bisa berperilaku berbeda di versi yang berbeda.
2. Sertakan tangkapan layar (untuk rekan tim). Meskipun Anda sendiri tidak melihatnya, rekan tim sighted Anda dapat mengambil screenshot untuk dokumentasi visual yang mempercepat triage oleh developer.
3. Hindari bahasa emosional. Laporan yang baik bersifat faktual dan netral: "Komponen ini gagal memenuhi SC 4.1.2", bukan "Tombol ini menyebalkan dan tidak berguna".
4. Rekomendasikan, jangan hanya melaporkan. Laporan yang dilengkapi dengan saran perbaikan sederhana akan jauh lebih dihargai klien dan developer.

---

Kesimpulan

Kemampuan menulis Bug Report dan ACR/VPAT yang akurat dan profesional adalah keterampilan yang mengangkat seorang anggota Access Squad dari "penguji biasa" menjadi konsultan aksesibilitas yang dapat dipercaya. Ini adalah bahasa yang dipahami oleh dunia korporasi, hukum, dan teknologi — dan menguasainya membuka pintu untuk peluang karir yang jauh lebih luas.

Referensi

- W3C. Understanding WCAG 2.1/2.2 Success Criteria. https://www.w3.org/WAI/WCAG21/Understanding/ - ITI. VPAT 2.x Template. https://www.itic.org/policy/accessibility/vpat - Lazar, J. dkk. Ensuring Digital Accessibility Through Process and Policy.