Aksesibilitas Website WCAG: Wajib Hukum bagi Bisnis 2026

Pada awal Februari 2026, tim customer service Kirana Living — sebuah platform e-commerce dekorasi rumah asal Bandung dengan sekitar 38.000 pengunjung per bulan — menerima surel dari seorang pengacara yang mewakili Ibu Ratna Kusumawati, pelanggan tunanetra yang mengandalkan pembaca layar (screen reader) untuk berbelanja daring. Selama tiga kali percobaan dalam dua minggu, Ibu Ratna tidak bisa menyelesaikan proses checkout karena formulir alamat pengiriman tidak memiliki label yang bisa dibaca screen reader, dan tombol "Bayar Sekarang" hanya berupa ikon tanpa teks alternatif sehingga terbaca sebagai "tombol tanpa nama" oleh NVDA. Surat somasi itu mengutip Undang-Undang Nomor 8 Tahun 2016 tentang Penyandang Disabilitas dan mengancam laporan resmi ke Komisi Nasional Disabilitas jika masalah tidak diperbaiki dalam 30 hari kerja.

Kasus Kirana Living bukan insiden terisolasi, dan bukan pula sekadar masalah hukum. Tim legal internal memperkirakan biaya penyelesaian, audit darurat oleh konsultan eksternal, dan perbaikan mendesak pada delapan alur transaksi kritis mencapai Rp 340 juta — jauh lebih mahal dibanding jika aksesibilitas dirancang sejak fase awal pengembangan. Yang lebih mengkhawatirkan, saat proses audit berjalan, tim data menemukan bahwa 16% pengunjung yang meninggalkan halaman checkout tanpa menyelesaikan transaksi kemungkinan besar adalah pengguna dengan keterbatasan penglihatan, motorik, atau kognitif — sebuah segmen pasar bernilai miliaran rupiah per tahun yang selama ini terabaikan begitu saja karena satu formulir yang tidak bisa dinavigasi dengan keyboard dan tombol yang tidak terbaca oleh teknologi bantu.

Apa itu aksesibilitas web dan kepatuhan WCAG?

Aksesibilitas web adalah praktik merancang dan membangun situs, aplikasi, serta produk digital agar dapat digunakan oleh semua orang — termasuk mereka yang memiliki keterbatasan penglihatan, pendengaran, motorik, atau kognitif. Standar internasional yang menjadi acuan utama adalah Web Content Accessibility Guidelines (WCAG) 2.2 level AA, yang diterbitkan oleh World Wide Web Consortium (W3C) dan menjadi rujukan teknis di hampir semua kerangka hukum, termasuk basis dari Undang-Undang Penyandang Disabilitas di Indonesia dan Americans with Disabilities Act (ADA) di Amerika Serikat.

WCAG 2.2 dibangun di atas empat prinsip yang dikenal sebagai POUR: Perceivable (dapat dipersepsikan — konten harus bisa "dilihat" lewat indra apa pun, termasuk oleh pembaca layar dan perangkat braille), Operable (dapat dioperasikan — semua fungsi bisa diakses lewat keyboard, bukan hanya mouse atau layar sentuh), Understandable (dapat dipahami — navigasi dan bahasa konsisten, instruksi jelas, tidak membingungkan), dan Robust (kuat — kompatibel dengan berbagai teknologi bantu, dari pembaca layar JAWS dan NVDA hingga switch device dan software pengenal suara).

Bandingkan dengan website "normal" yang dibangun tanpa memperhatikan aksesibilitas: gambar produk tanpa teks alternatif, teks abu-abu muda di atas latar putih yang sulit dibaca di bawah sinar matahari, formulir yang hanya bisa diisi dengan mouse, video tutorial tanpa keterangan (caption), dan pop-up promosi yang tidak bisa ditutup dengan tombol Escape atau tombol keyboard apa pun. Bagi sebagian besar pengguna, ini sekadar tidak nyaman dan sedikit menjengkelkan. Bagi jutaan pengguna dengan disabilitas, ini berarti situs tersebut sama sekali tidak bisa digunakan — setara dengan toko fisik yang menutup pintu tepat di depan hidung mereka.

Biaya nyata dari website yang tidak aksesibel

• Risiko hukum yang terus meningkat: Di Amerika Serikat, gugatan berbasis ADA Title III terhadap website mencapai lebih dari 4.500 kasus per tahun dalam beberapa tahun terakhir, dan tren litigasi ini mulai merembet ke pasar lain. Uni Eropa menegakkan European Accessibility Act (EAA) secara penuh sejak 28 Juni 2025, mewajibkan e-commerce, perbankan, dan layanan digital lain yang beroperasi di 27 negara anggota untuk memenuhi standar EN 301 549 (setara WCAG 2.1 AA), dengan sanksi administratif yang bervariasi antarnegara. Perusahaan Indonesia yang menjual ke pasar Eropa atau Amerika kini terpapar risiko hukum yang sama seperti perusahaan lokal di sana.
• Kehilangan pelanggan dalam skala besar: Menurut data yang dipublikasikan World Health Organization, sekitar 15-16% populasi dunia — lebih dari 1,3 miliar orang — hidup dengan suatu bentuk disabilitas. Ini bukan pasar ceruk kecil; angka ini setara dengan populasi gabungan beberapa negara besar sekaligus. Website yang tidak aksesibel otomatis menutup pintu bagi segmen ini, termasuk keluarga dan pendamping mereka yang turut memengaruhi keputusan belanja rumah tangga.
• Penalti SEO dan visibilitas di mesin pencari berbasis AI: HTML semantik yang mendukung aksesibilitas — heading yang terstruktur rapi, teks alternatif pada gambar, label formulir yang eksplisit — adalah sinyal yang sama persis yang dipakai crawler Google dan mesin pencari berbasis AI seperti ChatGPT Search atau Perplexity untuk memahami dan meringkas konten. Website yang berantakan secara struktural cenderung sulit di-crawl dan sulit diringkas oleh AI, sehingga kehilangan visibilitas organik dari dua arah sekaligus: mesin pencari tradisional dan mesin pencari generatif.
• Kerusakan reputasi merek yang sulit dipulihkan: Kasus penolakan akses yang viral di media sosial — tangkapan layar keluhan pengguna disabilitas yang tidak bisa checkout, disertai tagar dan tag ke akun resmi brand — dapat menyebar jauh lebih cepat daripada kampanye pemasaran resmi mana pun, dan butuh waktu bertahun-tahun bagi tim humas untuk memulihkan citra merek yang sudah telanjur dicap tidak inklusif.
• Retrofit jauh lebih mahal daripada membangun aksesibel sejak awal: Berbagai riset industri software menunjukkan bahwa memperbaiki cacat aksesibilitas setelah produk diluncurkan bisa memakan biaya 6 hingga 10 kali lipat dibanding merancangnya sejak fase desain dan development awal, karena tim harus membongkar ulang struktur komponen, sistem desain, dan alur pengujian yang sudah telanjur dibangun tanpa mempertimbangkan aksesibilitas sama sekali.

Fitur inti yang wajib dimiliki website atau aplikasi yang benar-benar aksesibel

• HTML semantik dan landmark ARIA yang benar: Penggunaan tag seperti <nav>, <main>, <header>, serta atribut ARIA landmark memungkinkan pembaca layar memahami struktur halaman secara utuh dan memungkinkan pengguna melompat langsung ke bagian yang relevan tanpa harus mendengarkan seluruh halaman dari atas ke bawah.
• Navigasi keyboard penuh tanpa jebakan fokus: Setiap elemen interaktif — tombol, tautan, formulir, menu dropdown, jendela modal — harus bisa dijangkau dan dioperasikan hanya dengan tombol Tab, Enter, Spasi, dan tombol panah, disertai indikator fokus yang terlihat jelas, tanpa membuat pengguna "terjebak" di satu elemen tanpa jalan keluar.
• Kontras warna minimal 4.5:1: Teks normal terhadap latar belakangnya harus memenuhi rasio kontras minimal 4.5:1 (3:1 untuk teks berukuran besar) sesuai standar WCAG 2.2 AA, agar tetap terbaca oleh pengguna low vision, penderita buta warna, maupun siapa pun yang mengakses situs di bawah sinar matahari terik lewat ponsel.
• Formulir dan teks alternatif yang kompatibel dengan pembaca layar: Setiap input formulir memerlukan label eksplisit yang terasosiasi secara programatik, pesan bantuan yang diumumkan otomatis oleh screen reader, dan setiap gambar informatif memerlukan teks alternatif (alt text) yang deskriptif dan bermakna, bukan sekadar nama file seperti "IMG_2044.jpg".
• Caption dan transkrip untuk konten video dan audio: Semua video harus memiliki caption tersinkronisasi dan idealnya transkrip teks lengkap, sangat penting bagi pengguna tuli atau lemah dengar, dan bermanfaat pula bagi pengguna yang menonton di ruang publik tanpa suara.
• Teks dapat diperbesar hingga 200% tanpa merusak tata letak: Pengguna low vision sering memperbesar ukuran teks browser hingga 200%; desain responsif yang baik harus tetap terbaca rapi dan tidak memotong konten atau menumpuk elemen ketika ukuran teks membesar secara signifikan.
• Pesan kesalahan yang jelas dan manajemen fokus yang tepat: Saat terjadi kesalahan input pada formulir, sistem harus mengarahkan fokus langsung ke pesan kesalahan tersebut, menjelaskan masalah secara spesifik (bukan sekadar "Terjadi kesalahan"), dan memberi instruksi perbaikan yang jelas serta dapat dibacakan oleh screen reader.

Retrofit website lama vs membangun aksesibel sejak awal

Banyak pemilik bisnis tergoda oleh solusi instan berupa overlay atau widget aksesibilitas yang tinggal dipasang dengan satu baris kode JavaScript, menjanjikan "kepatuhan WCAG otomatis" hanya dalam hitungan menit. Kenyataannya, alat semacam ini umumnya hanya menambal gejala di permukaan tanpa memperbaiki struktur HTML yang mendasarinya, dan dalam beberapa tahun terakhir overlay semacam ini justru menjadi objek gugatan tersendiri di Amerika Serikat — advokat disabilitas berargumen bahwa overlay dapat mengganggu teknologi bantu yang sudah dikonfigurasi pengguna sebelumnya, sehingga memperburuk pengalaman alih-alih memperbaikinya. Sejumlah perusahaan bahkan digugat justru setelah memasang overlay, karena dianggap sebagai bentuk kepatuhan palsu (fake compliance) yang tidak menyelesaikan akar masalah.

Retrofit menyeluruh — audit manual oleh auditor bersertifikasi, perbaikan kode di level komponen, pengujian dengan pengguna disabilitas sungguhan — tetap masuk akal untuk website yang fondasinya secara umum sehat namun perlu penyesuaian pada beberapa alur kritis saja, seperti checkout atau formulir pendaftaran akun. Namun untuk website lama yang dibangun di atas framework usang, tanpa sistem desain yang konsisten, atau dengan utang teknis yang sudah menumpuk bertahun-tahun, membangun ulang dari nol dengan aksesibilitas sebagai prinsip desain sejak hari pertama biasanya jauh lebih hemat biaya dan waktu dalam jangka panjang, sekaligus menjadi momentum yang tepat untuk modernisasi teknologi secara keseluruhan, termasuk migrasi ke framework yang lebih terkini dan performa yang lebih baik.

Kisaran biaya dan waktu pengerjaan

Untuk pasar Indonesia, proyek audit dan remediasi aksesibilitas pada website bisnis skala menengah — misalnya toko daring dengan katalog produk, sistem checkout, dan portal akun pelanggan — umumnya berkisar Rp 40 juta hingga Rp 90 juta untuk audit menyeluruh plus perbaikan pada komponen inti, dengan waktu pengerjaan sekitar 2 hingga 3 bulan. Untuk pembangunan ulang penuh (rebuild) sebuah aplikasi web atau portal dengan kompleksitas tinggi — dashboard multi-role, integrasi sistem pembayaran, dukungan multibahasa, dan modul pelaporan — kisaran biaya naik menjadi Rp 120 juta hingga Rp 250 juta dengan waktu pengerjaan 3 hingga 5 bulan, tergantung jumlah halaman, kompleksitas alur transaksi, dan tingkat kepatuhan yang ditargetkan (AA standar untuk kebanyakan sektor, atau AAA untuk sektor sensitif seperti perbankan dan layanan kesehatan).

Studi kasus: Warna Dapur Indonesia

Warna Dapur Indonesia, peritel daring peralatan dapur dengan basis pelanggan tersebar di 12 kota besar, memulai proyek remediasi aksesibilitas penuh setelah menerima dua keluhan formal dalam satu tahun berjalan. Setelah proyek selama 4 bulan yang mencakup audit WCAG 2.2 AA menyeluruh, perombakan komponen formulir dan navigasi, penambahan dukungan keyboard penuh di seluruh situs, serta pelatihan tim konten untuk menulis alt text yang layak, hasilnya cukup signifikan: tingkat pentalan (bounce rate) pada halaman checkout turun 22%, tiket dukungan pelanggan terkait kesulitan navigasi turun 61% dalam tiga bulan pertama pascapeluncuran, kedua keluhan formal diselesaikan secara damai tanpa eskalasi hukum lebih lanjut, dan tingkat konversi keseluruhan naik 9% — sebagian besar berasal dari segmen pengguna lanjut usia dan pengguna dengan keterbatasan penglihatan yang sebelumnya kesulitan menyelesaikan pembelian sama sekali.

Metrik kunci yang perlu dipantau setelah implementasi

• Skor audit otomatis WCAG, menggunakan alat seperti axe DevTools atau Lighthouse Accessibility, sebagai baseline kuantitatif yang dipantau pada setiap rilis fitur baru.
• Tingkat penyelesaian tugas dengan keyboard saja, diukur lewat pengujian pengguna berkala untuk memastikan alur kritis seperti checkout dan pendaftaran tetap bisa dituntaskan tanpa mouse sama sekali.
• Durasi sesi pengguna pembaca layar, dibandingkan dengan pengguna umum — durasi yang jauh lebih lama atau tingkat keluar (exit rate) yang tinggi menandakan ada hambatan navigasi yang belum teratasi.
• Jumlah tiket dukungan terkait aksesibilitas, sebagai indikator langsung dan paling jujur dari masalah nyata yang dialami pengguna di lapangan setiap bulan.
• Perubahan visibilitas pencarian organik, karena perbaikan struktur HTML semantik sering berkorelasi langsung dengan peningkatan peringkat pencarian dan kemunculan di ringkasan hasil AI search.

Tantangan implementasi dan cara mengatasinya

Tantangan pertama yang paling umum dijumpai adalah sistem desain lama yang dibangun tanpa mempertimbangkan kontras warna yang memadai atau ukuran target sentuh yang cukup besar untuk jari maupun perangkat bantu. Solusinya bukan mengganti seluruh identitas visual merek dari nol, melainkan mengaudit palet warna dan komponen inti yang ada, lalu menyesuaikan variabel desain (design token) secara terpusat sehingga perubahan konsisten di seluruh produk digital tanpa perlu menyentuh setiap halaman satu per satu secara manual.

Tantangan kedua datang dari widget pihak ketiga — fitur live chat, formulir survei tertanam, embed peta lokasi toko, atau pemutar video eksternal — yang sering kali dibangun tanpa memperhatikan aksesibilitas sama sekali dan berada di luar kendali langsung tim developer internal. Solusi praktisnya adalah mengevaluasi vendor pihak ketiga secara eksplisit dari sisi kepatuhan aksesibilitas sebelum memutuskan untuk mengintegrasikannya, dan menyediakan jalur alternatif yang setara — misalnya nomor telepon atau alamat email — bagi fitur yang belum sepenuhnya aksesibel.

Tantangan ketiga adalah keberlanjutan jangka panjang: aksesibilitas bukan proyek sekali jadi yang selesai setelah peluncuran, melainkan kebiasaan kerja yang harus terus dipelihara oleh tim konten, desain, dan development secara berkelanjutan. Setiap artikel blog baru, banner promosi musiman, atau fitur produk baru berpotensi memperkenalkan kembali masalah aksesibilitas jika tim tidak dilatih secara memadai dan tidak ada proses quality assurance yang menyertakan pengecekan aksesibilitas sebagai bagian standar sebelum setiap rilis, bukan sebagai renungan di akhir proses.

Website Anda mungkin terlihat baik-baik saja di layar Anda sendiri — tetapi pertanyaan sebenarnya adalah apakah ia benar-benar bisa digunakan oleh 1,3 miliar orang dengan disabilitas di seluruh dunia, termasuk pelanggan potensial Anda sendiri yang mungkin sudah diam-diam berpaling ke kompetitor. Daripada menunggu surat somasi pertama datang ke meja legal Anda, mulailah dengan audit aksesibilitas menyeluruh terhadap website atau aplikasi Anda saat ini. Tim AFSS siap membantu merancang dan membangun produk digital yang benar-benar inklusif sejak fondasinya — cek harga paket audit dan remediasi aksesibilitas kami, atau langsung ajukan-proyek untuk konsultasi awal bersama tim kami.