Panduan Aksesibilitas untuk Manajer Proyek (PM)

Panduan Aksesibilitas untuk Manajer Proyek (PM): Mengelola Risiko dan Anggaran

Bagi seorang Project Manager (PM) atau Scrum Master, aksesibilitas digital sering kali dipandang sebagai "ancaman" terhadap tiga pilar utama manajemen proyek: Anggaran, Waktu, dan Ruang Lingkup (Scope).

Kenyataannya, aksesibilitas hanya menjadi mahal dan memperlambat proyek ketika ia dikerjakan secara reaktif—yaitu ketika audit dilakukan dua minggu sebelum peluncuran (launch). Berdasarkan wawasan dari Web Accessibility: WCAG 2.2 made easy oleh Olga Revilla (Bagian: Implementing Web Accessibility Policies), artikel ini membedah bagaimana seorang PM harus mengorkestrasi aksesibilitas sejak hari pertama.

Insight Terkait

Pengadaan IT dan Dokumen VPAT

1. Mencegah Eskalasi Biaya dengan Shift-Left

Aturan emas dalam manajemen risiko perangkat lunak adalah: Biaya untuk memperbaiki sebuah bug meningkat secara eksponensial seiring dengan berjalannya waktu.

Fase Desain (Biaya: $10): Desainer UI/UX memperbaiki rasio kontras warna tombol dari 3.0:1 menjadi 4.5:1 di Figma. Hanya butuh 2 menit.
Fase Pengembangan (Biaya: $100): Developer menyadari warna tidak sesuai, harus berkonsultasi kembali dengan desainer, menulis ulang variabel CSS, dan me-rebuild komponen. Butuh 2 jam.
Fase Pasca-Rilis (Biaya: $10.000+): Produk diaudit oleh pihak ketiga, ditemukan kegagalan kontras secara global. Tim harus menghentikan pengerjaan fitur baru, merombak Design System utama, menguji ulang ratusan halaman, hingga menghadapi ancaman gugatan hukum (seperti UU EAA atau ADA).

Sebagai PM, tugas Anda adalah memastikan validasi terjadi di Fase Desain. Anda adalah penjaga gawang yang menolak desain masuk ke Sprint Backlog jika belum divalidasi aksesibilitasnya.

2. Menyusun Acceptance Criteria (AC) yang Aksesibel

Sebuah User Story di Jira atau Trello tidak boleh dianggap selesai jika belum memenuhi standar inklusi.

Insight Terkait

Bahasa Remediasi: Berkomunikasi Efektif dengan Developer

Alih-alih membuat satu tiket besar bernama "Buat Situs Menjadi Aksesibel" (yang mustahil diselesaikan dalam satu Sprint), PM harus memecahnya ke dalam Acceptance Criteria (Kriteria Penerimaan) untuk setiap tiket individual.

Contoh User Story: Fitur Modal Login

Sebagai pengguna, saya ingin bisa masuk ke akun saya melalui popup modal.

Acceptance Criteria Biasa:

Insight Terkait

Membangun Design System Aksesibel

UI sesuai dengan desain Figma.
Terhubung ke API otentikasi.

Acceptance Criteria yang Ditambah Aksesibilitas:

Saat modal terbuka, fokus keyboard langsung berpindah ke input "Email".
Fokus keyboard terperangkap (ter-trap) di dalam modal dan tidak bisa "bocor" ke halaman belakang selama modal terbuka.
Modal dapat ditutup dengan menekan tombol Escape pada keyboard.
Tombol 'X' (Tutup) memiliki aria-label="Tutup jendela login".

3. Alokasi Waktu dan Velocity Sprint

PM sering bertanya: "Berapa banyak ekstra waktu (Story Points) yang harus saya tambahkan untuk aksesibilitas?"

Olga Revilla menekankan bahwa pada bulan-bulan pertama (masa transisi), velocity (kecepatan pengerjaan) tim Anda pasti akan menurun sekitar 15-20%. Developer butuh waktu untuk membaca dokumentasi WAI-ARIA, dan desainer butuh waktu untuk mengecek kontras. PM harus menyerap penurunan ini dengan lapang dada dan mengomunikasikannya ke pihak Stakeholder sebagai "Investasi Pembelajaran".

Namun, setelah 3 hingga 4 Sprint, saat tim sudah mulai membangun Komponen Aksesibel yang dapat digunakan ulang (Reusable Accessible Components), velocity akan kembali normal. Menggunakan komponen <AccessibleButton> yang sama berulang kali tidak membutuhkan waktu tambahan sama sekali.

4. Kapan Harus Menggunakan Auditor Eksternal?

Sebagai PM, Anda harus realistis dengan kapasitas tim Anda. Alat otomatis internal (seperti Lighthouse atau Axe) hanya menangkap 20-30% error. Sisanya membutuhkan pengujian manual oleh pakar.

Anggarkan untuk menyewa Konsultan Aksesibilitas Pihak Ketiga pada titik-titik krusial berikut:

Audit Wireframe/Desain Awal: Sebelum satu baris kode pun ditulis.
Audit Komponen Inti: Saat Design System atau kerangka UI utama selesai dibangun.
Audit Pra-Peluncuran (Pre-Launch): Untuk mengeluarkan sertifikat kepatuhan atau VPAT resmi.

5. Kesimpulan

Manajemen proyek aksesibilitas bukanlah tentang menjadi pakar HTML atau menguasai regulasi hukum secara mendalam. Ini tentang mengintegrasikan ceklis kualitas ke dalam rutinitas kerja harian (Agile/Scrum), melindungi waktu developer untuk belajar, dan menetapkan standar bahwa "Selesai" (Done) berarti "Dapat digunakan oleh semua orang".

Referensi

Strategi manajemen risiko, konsep Shift-Left, dan integrasi aksesibilitas ke dalam metodologi Agile diadaptasi dari bab Implementing Web Accessibility Policies dalam literatur Web Accessibility: WCAG 2.2 made easy oleh Olga Revilla. Struktur Acceptance Criteria spesifik merujuk pada standar industri manajerial yang ditekankan dalam buku tersebut.