Aksesibilitas sebagai Proses, Bukan Proyek: Membantu Klien Membuat IT Accessibility Plan

Banyak klien yang memperlakukan audit aksesibilitas seperti proyek biasa: ada awal, ada akhir, ada laporan yang diserahkan, selesai. Namun para profesional di bidang ini tahu bahwa ini adalah kesalahan fundamental yang menjamin kegagalan jangka panjang.

Aksesibilitas bukan kondisi statis yang dicapai sekali lalu selesai. Website diperbarui, fitur baru ditambahkan, konten berubah — dan setiap perubahan bisa memperkenalkan hambatan baru bagi pengguna disabilitas. Penelitian Jonathan Lazar dalam Ensuring Digital Accessibility Through Process and Policy menegaskan: aksesibilitas adalah proses berkelanjutan, bukan proyek satu kali.

Seorang anggota Access Squad yang mampu membantu kliennya memahami dan mengimplementasikan proses ini — bukan hanya menyerahkan laporan dan pergi — adalah yang akan menjadi konsultan paling dicari dan paling bernilai.

---

Mengapa "Lulus Audit Sekali" Tidak Cukup

Bayangkan sebuah perusahaan e-commerce berhasil memperoleh laporan audit aksesibilitas yang bersih. Enam bulan kemudian, mereka:

• Mengganti framework frontend mereka.
• Menambahkan fitur live chat baru dari vendor pihak ketiga.
• Merilis aplikasi mobile baru.
• Memperbarui halaman checkout dengan desain baru.

Setiap perubahan di atas berpotensi memperkenalkan hambatan aksesibilitas baru yang tidak ada dalam laporan lama. Tanpa proses yang berkelanjutan, "lulus audit" kemarin tidak berarti apa-apa hari ini.

Ini bukan argumen untuk membuat klien takut — ini adalah argumen untuk menjual mereka pada konsep yang jauh lebih berharga: Aksesibilitas yang Berkelanjutan (Sustainable Accessibility).

---

Komponen 1: Accessibility Statement (Pernyataan Aksesibilitas)

Ini adalah dokumen publik yang wajib ada di setiap website atau aplikasi yang serius. Sejak European Accessibility Act (EAA) 2025 mulai berlaku, Accessibility Statement bukan hanya praktik baik — ini adalah persyaratan hukum bagi produk digital yang beroperasi di pasar Eropa.

Apa Isi Accessibility Statement?

Sebuah Accessibility Statement yang baik berisi:

1. Pernyataan Komitmen: "Kami berkomitmen untuk memastikan [nama produk] dapat diakses oleh semua orang, termasuk penyandang disabilitas."
2. Standar yang Digunakan: "Kami berupaya memenuhi WCAG 2.2 Level AA."
3. Status Kepatuhan Saat Ini: Apakah produk fully conformant, partially conformant, atau non-conformant? Jika partially, apa saja yang belum terpenuhi?
4. Keterbatasan yang Diketahui: Daftar jujur isu aksesibilitas yang diketahui namun belum diperbaiki, lengkap dengan target waktu perbaikan.
5. Alternatif Aksesibel: Jika ada bagian produk yang tidak aksesibel, apa alternatif yang tersedia bagi pengguna? (Misal: "Hubungi kami di nomor X untuk mendapatkan bantuan.")
6. Mekanisme Umpan Balik: Bagaimana pengguna dapat melaporkan hambatan aksesibilitas yang mereka temukan?
7. Tanggal Terakhir Diperbarui: Kapan pernyataan ini terakhir ditinjau?

Contoh Paragraf Pernyataan Status

PARTIALLY CONFORMANT

[Nama Produk] sebagian sesuai dengan WCAG 2.2 Level AA. 
Ketidaksesuaian yang diketahui meliputi:

1. Beberapa komponen galeri gambar tidak memiliki teks alternatif 
   yang memadai (gagal SC 1.1.1). Target perbaikan: Q3 2026.
2. Komponen live chat dari penyedia pihak ketiga belum dapat 
   diakses via keyboard (gagal SC 2.1.1). Kami sedang bernegosiasi 
   dengan vendor untuk perbaikan. Target: Q4 2026.

Sebagai auditor, Anda memiliki keahlian unik untuk membantu klien menulis dokumen ini dengan akurat dan jujur — berdasarkan temuan laporan audit yang Anda hasilkan.

---

Komponen 2: IT Accessibility Roadmap (Peta Jalan Perbaikan)

Klien yang menerima laporan audit dengan 47 isu aksesibilitas seringkali merasa kewalahan dan tidak tahu harus mulai dari mana. Inilah peran konsultan: mengubah daftar isu yang mengintimidasi menjadi rencana perbaikan yang terstruktur dan realistis.

Framework Prioritas: Severity × Reach

Untuk memprioritaskan isu dalam Roadmap, gunakan dua dimensi:

• Severity (Tingkat Keparahan): Blocker, Critical, Major, Minor — seperti yang dijelaskan di artikel Laporan Audit.
• Reach (Jangkauan): Seberapa banyak pengguna dan halaman yang terpengaruh oleh isu ini?

Prioritas	Kriteria	Target Perbaikan
Sprint 1	Semua Blocker di halaman/alur kritis (login, checkout)	Segera (dalam 2 minggu)
Sprint 2	Semua Critical di seluruh sampel audit	Bulan 1
Sprint 3	Semua Major dengan Reach tinggi (homepage, navbar)	Bulan 2-3
Sprint 4	Major dengan Reach rendah + semua Minor	Bulan 3-6
Ongoing	Pembaruan Accessibility Statement + re-audit parsial	Setiap 6 bulan

Menyertakan Estimasi Upaya (Effort Estimation)

Untuk setiap isu dalam Roadmap, sertakan estimasi kasar waktu pengerjaan bagi tim developer:

• Quick Win (< 1 jam): Menambahkan atribut alt pada gambar, memperbaiki teks link.
• Medium Fix (1-4 jam): Memperbaiki manajemen fokus pada komponen modal, menambahkan ARIA pada widget kustom.
• Complex Fix (> 1 hari): Merombak alur keyboard pada halaman checkout yang kompleks, mengganti library UI pihak ketiga.

Estimasi ini membantu manajer proyek klien mengalokasikan sprint capacity dengan realistis.

---

Komponen 3: Monitoring Cycle (Siklus Pemantauan Berkelanjutan)

Setelah Roadmap dieksekusi, bagaimana memastikan aksesibilitas tetap terjaga seiring waktu? Lazar mengidentifikasi tiga trigger umum yang memicu kebutuhan evaluasi ulang:

1. Pembaruan Konten Besar: Setiap kali ada penambahan template halaman baru, fitur baru, atau pergantian vendor teknologi.
2. Pembaruan Periodik: Minimal setiap 12 bulan, lakukan audit parsial untuk memverifikasi tidak ada regresi.
3. Pembaruan Versi Produk: Setiap rilis versi mayor dari aplikasi mobile atau web harus diikuti pengujian aksesibilitas.

Membangun Tim Internal

Sebagai konsultan aksesibilitas jangka panjang, salah satu kontribusi terbesar Anda adalah membantu klien membangun kapasitas internal sehingga mereka tidak harus bergantung sepenuhnya pada auditor eksternal selamanya. Ini bisa berupa:

• Melatih 1-2 orang developer internal sebagai "Accessibility Champion".
• Mengintegrasikan pemeriksaan aksesibilitas otomatis (misal: plugin Axe) ke dalam CI/CD pipeline mereka.
• Membuat panduan pembuatan konten (Content Creation Guide) untuk tim pemasaran agar gambar dan video yang mereka publikasikan sudah aksesibel.

---

Mengapa Ini Peluang Bisnis yang Besar bagi Access Squad

Layanan "Audit + Accessibility Plan" jauh lebih bernilai daripada sekadar "Audit" saja. Dari perspektif bisnis:

• Recurring Revenue: Klien yang memiliki monitoring contract akan membayar Anda secara reguler (bulanan atau tahunan), bukan hanya sekali.
• Diferensiasi: Sangat sedikit konsultan aksesibilitas — apalagi yang tunanetra — yang menawarkan layanan strategis seperti ini. Anda berada di pasar yang nyaris tanpa pesaing.
• Dampak Nyata: Anda tidak hanya menemukan masalah — Anda membantu organisasi membangun sistem yang lebih adil secara berkelanjutan.

---

Kesimpulan

Menyerahkan laporan audit dan pulang adalah pekerjaan seorang tester. Membantu klien memahami bahwa aksesibilitas adalah proses, membantu mereka menulis Accessibility Statement yang jujur, menyusun Roadmap yang realistis, dan membangun siklus pemantauan yang berkelanjutan — itulah pekerjaan seorang konsultan aksesibilitas strategis.

Dan itulah visi akhir dari setiap anggota Access Squad: bukan hanya menjadi penguji, tetapi menjadi mitra pembangunan digital Indonesia yang inklusif.

Referensi

- Lazar, J. dkk. Ensuring Digital Accessibility Through Process and Policy. (Khususnya Bab 9: Compliance Monitoring dan Bab 10: Case Studies of Success). - W3C WAI. Developing an Accessibility Statement. https://www.w3.org/WAI/planning/statements/ - European Accessibility Act (EAA) 2025. Directive (EU) 2019/882.