Bahasa Remediasi: Berkomunikasi Efektif dengan Developer

Sebuah laporan audit aksesibilitas yang sempurna sekalipun bisa berakhir sia-sia jika developer yang menerimanya tidak memahami apa yang harus mereka lakukan. Dan dari sudut pandang developer, menerima laporan yang hanya berisi daftar masalah tanpa solusi terasa seperti keluhan, bukan kolaborasi.

Inilah mengapa kemampuan berbahasa remediasi — yaitu, menulis rekomendasi perbaikan teknis yang presisi, praktis, dan empatik — adalah mahkota dari keahlian seorang auditor Access Squad. Artikel ini mengajarkan Anda cara mengubah temuan audit menjadi instruksi yang bisa langsung dikerjakan oleh developer dalam hitungan menit.

---

Prinsip Dasar: Auditor Bukan Programmer, Namun Harus Paham Kode

Kesalahpahaman umum adalah bahwa seorang auditor aksesibilitas harus mampu menulis ulang kode yang bermasalah. Ini tidak benar. Tugas auditor bukan memprogram — tugas auditor adalah mendefinisikan dengan tepat apa yang dibutuhkan secara teknis agar sebuah komponen menjadi aksesibel.

Bayangkan seorang inspektur bangunan. Mereka tidak perlu bisa memasang pipa sendiri untuk mengatakan, "Sistem saluran air di lantai tiga tidak memenuhi standar keselamatan X. Saluran pembuangan perlu dilebarkan minimal 5 cm." Mereka tahu apa yang salah dan apa yang benar berdasarkan standar, dan tugas kontraktor adalah bagaimana cara memperbaikinya.

Demikian pula, seorang auditor aksesibilitas harus tahu:

• Nama (accessible name): Apa yang akan diumumkan screen reader?
• Peran (role): Komponen ini seharusnya berperilaku seperti apa (tombol, tautan, dialog)?
• Nilai (value): Apa status atau nilai saat ini dari komponen ini?
• Relasi (relationships): Apakah elemen ini terhubung secara programatik ke deskripsi atau labelnya?

---

Tiga Jenis Rekomendasi Remediasi

1. Remediasi Semantik: Gunakan Elemen HTML yang Tepat

Rekomendasi paling kuat dan paling mudah diimplementasikan adalah menyarankan penggantian elemen HTML yang salah dengan elemen yang benar.

Isu: "Tombol 'Tambah ke Keranjang' tidak dapat difokus atau diaktifkan via keyboard."

Temuan Teknis: Elemen yang digunakan adalah <div> dengan onClick handler JavaScript.

Rekomendasi Remediasi:

Ganti elemen <div class="add-to-cart"> dengan elemen <button type="button">. Elemen <button> secara bawaan mendukung fokus keyboard (Tab), aktivasi (Enter/Space), dan memiliki role="button" implisit yang dikenali semua screen reader. Tidak ada perubahan JavaScript yang diperlukan — cukup ganti tag HTML-nya.

Ini adalah contoh terbaik dari remediasi. Solusinya satu baris, dampaknya besar.

2. Remediasi WAI-ARIA: Tambahkan Atribut untuk Komponen Kustom

Ketika komponen kustom (yang tidak dapat diganti dengan elemen HTML semantik tanpa merombak total desain visual) harus dipertahankan, WAI-ARIA adalah solusinya.

Isu: "Komponen tab navigasi kustom tidak mengomunikasikan tab mana yang sedang aktif."

Rekomendasi Remediasi:

Pada elemen yang berfungsi sebagai tab, tambahkan:

• role="tab" pada setiap tombol tab.
• aria-selected="true" pada tab yang aktif, dan aria-selected="false" pada tab lainnya. Perbarui nilai ini via JavaScript saat tab berganti.
• Pada panel konten yang terkait, tambahkan role="tabpanel" dan aria-labelledby="[id-tab-terkait]".

Pengguna screen reader akan mendengar: "Tab Deskripsi Produk, dipilih, 1 dari 3."

3. Remediasi Relasi: Hubungkan Elemen yang Saling Berkaitan

Banyak isu aksesibilitas terjadi bukan karena elemen tidak ada, tetapi karena elemen-elemen yang seharusnya terhubung tidak terhubung secara programatik.

Isu: "Ketika pengguna salah mengisi formulir, pesan error muncul namun screen reader tidak tahu bahwa pesan itu terkait dengan kolom input yang bermasalah."

Rekomendasi Remediasi:

1. Tambahkan atribut aria-describedby="[id-pesan-error]" pada elemen <input> yang bermasalah.
2. Berikan ID unik pada elemen pesan error, misalnya id="email-error-msg".
3. Tambahkan aria-invalid="true" pada elemen <input> ketika dalam kondisi error.
4. Pastikan fokus keyboard secara otomatis berpindah ke kolom pertama yang error setelah pengguna menekan tombol Submit.

---

Cara Menulis Rekomendasi yang Membangun Kepercayaan

Kualitas relasi antara auditor dan tim developer sangat menentukan apakah perbaikan akan dilaksanakan dengan sungguh-sungguh atau sekadar "tambal lubang agar lulus audit".

Gunakan Bahasa yang Solutif, Bukan Kritis

• ❌ Hindari: "Kalian mengabaikan kebutuhan pengguna tunanetra di seluruh halaman checkout ini."
• ✅ Gunakan: "Alur checkout saat ini memiliki tiga hambatan yang dapat kami perbaiki secara bertahap. Prioritas tertinggi adalah memastikan tombol 'Lanjutkan ke Pembayaran' dapat diakses via keyboard."

Sertakan Contoh Kode (Snippet) Bila Memungkinkan

Developer sangat menghargai contoh konkret. Jika Anda sudah tahu solusinya, sertakan potongan kode kecil:

<!-- SEBELUM (bermasalah) -->
<div class="btn-primary" onclick="addToCart()">Tambah ke Keranjang</div>

<!-- SESUDAH (diperbaiki) -->
<button type="button" onclick="addToCart()">Tambah ke Keranjang</button>

Ini menghilangkan ambiguitas dan sangat mempercepat pekerjaan developer.

Tunjukkan Dampak Nyata terhadap Pengguna

Rekomendasi yang menjelaskan "mengapa ini penting bagi pengguna nyata" lebih mudah mendapat prioritas daripada yang hanya menyebut nomor kriteria WCAG.

"Tanpa perbaikan ini, pengguna yang hanya menggunakan keyboard atau screen reader tidak akan bisa menyelesaikan pembelian sama sekali. Ini bukan hanya masalah aksesibilitas, ini adalah blocker konversi untuk sekitar 15% populasi."

---

Membangun Hubungan Jangka Panjang dengan Tim Developer

Auditor terbaik bukan yang datang sekali, menyerahkan laporan, lalu pergi. Mereka membangun hubungan konsultatif yang berkelanjutan.

Praktik Terbaik:

• Sesi Triage Bersama: Tawarkan satu sesi singkat (30 menit) setelah laporan diserahkan untuk membahas temuan bersama tim developer, menjawab pertanyaan, dan mengklarifikasi prioritas.
• Retesting: Setelah developer mengklaim telah memperbaiki sebuah isu, auditor melakukan pengujian ulang (retesting) untuk memverifikasi. Ini adalah siklus yang sehat.
• Edukasi Berkelanjutan: Sesekali berbagi artikel, panduan, atau demonstrasi singkat tentang "bagaimana rasanya menggunakan produk ini dengan screen reader" kepada tim developer. Empati yang tumbuh secara organik menghasilkan produk yang jauh lebih baik daripada sekadar kepatuhan terhadap regulasi.

---

Kesimpulan

Bahasa remediasi adalah jembatan antara dunia pengalaman pengguna tunanetra dan dunia kode teknis developer. Seorang anggota Access Squad yang menguasai ketiga pilarnya — remediasi semantik, remediasi WAI-ARIA, dan remediasi relasi — serta mampu menyampaikannya dengan empati dan kejernihan, adalah aset yang tidak ternilai bagi industri teknologi Indonesia.

Anda bukan hanya menemukan masalah. Anda mendefinisikan solusinya. Dan itulah kekuatan sesungguhnya dari seorang auditor aksesibilitas profesional.

Referensi

- W3C. WAI-ARIA Authoring Practices 1.2. https://www.w3.org/WAI/ARIA/apg/ - Firth, A. Practical Web Accessibility: A Book Apart. - Mancilla, R. Guide to Digital Accessibility. - Revilla Munoz, O. & Carrera, O. Web Accessibility: WCAG 2.2 made easy.