Blind Code: 7 Kesalahan Aksesibilitas (A11y) Kritis yang Selalu Dilakukan Asisten AI

Konteks Stack: Contoh-contoh dalam artikel ini berlaku untuk proyek React, Next.js (App Router), dan Vite. Namun, prinsip-prinsip aksesibilitas berlaku untuk kerangka kerja apa pun (Vue, Svelte, Angular).

Anda baru saja melakukan “vibe-coding” halaman landing baru yang menakjubkan dalam hitungan detik menggunakan asisten AI favorit Anda. Cursor atau Copilot menghasilkan seluruh UI dari satu perintah (prompt). Tampilan di monitor Anda sudah bagus, animasinya mulus, dan peluncuran (deployment) berjalan tanpa hambatan. Namun, di balik layar, Anda mungkin baru saja memblokir pengguna yang mengandalkan pembaca layar (screen readers) atau navigasi keyboard untuk mengakses situs Anda.

Ketika model AI menghasilkan kode, mereka memprioritaskan estetika visual dan fungsionalitas langsung. Mereka kekurangan nuansa kontekstual untuk memahami struktur semantik, yang berarti mereka sering melanggar standar pengujian aksesibilitas. Jika Anda tidak memeriksa hasil kerja mereka, Anda merilis produk yang tidak terlihat oleh pembaca layar dan mustahil untuk dinavigasi dengan keyboard.

Berikut adalah 7 kesalahan aksesibilitas kritis yang sering muncul dalam kode buatan AI, dan cara mengenalinya sebelum peluncuran berikutnya.

1. “Div Soup” dan Tombol Palsu

🔴 Kritis · Tidak Terjangkau oleh Pembaca Layar · WCAG 4.1.2 (Name, Role, Value)

Jika Anda meminta asisten AI untuk “membuat menu dropdown khusus,” solusi favoritnya adalah membangun tumpukan elemen <div> yang besar dan menempelkan acara onClick padanya. Kami menyebutnya “Div Soup.”

Pendekatan AI (Sebelum):

// ❌ Kode Buatan AI: Berfungsi secara visual, tetapi sama sekali tidak dapat diakses
<div onClick={() => setIsOpen(true)}>Buka Menu</div>

Mengapa ini rusak: Sebuah <div> secara inheren tidak interaktif. Ketika pembaca layar menemukannya, ia hanya membaca “Buka Menu” tanpa memberitahukan bahwa itu adalah tindakan yang bisa diklik. Selain itu, pengguna yang menavigasi melalui tombol Tab akan melewati elemen ini sepenuhnya, membuat situs Anda tidak dapat digunakan oleh siapa pun yang tidak dapat menggunakan mouse.

Perbaikan (Sesudah):

// ✅ Kode yang Benar: Tombol asli menyediakan aksesibilitas bawaan
<button onClick={() => setIsOpen(true)}>Buka Menu</button>

Elemen asli seperti <button> dan <a> dilengkapi dengan manajemen status fokus bawaan, pengikatan keyboard (Enter dan Space), dan peran aksesibilitas. Jika Anda harus menggunakan <div> kustom, Anda harus menambahkan role="button" dan tabIndex={0} secara manual, tetapi hampir selalu lebih baik untuk memaksa AI menggunakan HTML semantik.

Kesulitan melacak semua div yang bermasalah di komponen buatan Anda? Lihat panduan kami tentang Markdown-Driven QA untuk melihat bagaimana Anda dapat menyederhanakan pemeriksaan ini secara otomatis.

2. Input Form Tanpa Label (Unlabeled input)

🟡 Tinggi · Pengabaian Formulir · WCAG 1.3.1 (Info and Relationships)

Formulir adalah jantung dari produk SaaS apa pun. Saat membuat formulir pendaftaran, AI biasanya akan membuat tata letak yang indah menggunakan teks placeholder sebagai satu-satunya bentuk label.

Pendekatan AI (Sebelum):

// ❌ Kode Buatan AI: Tidak ada hubungan terencana
<div>
  <span>Alamat Email</span>
  <input
    type="email"
    placeholder="Masukkan email Anda"
  />
</div>

Mengapa ini rusak: Pengelompokan visual saja tidak cukup. Pembaca layar memerlukan tautan terencana langsung antara label dan inputnya. Tanpa itu, saat pengguna pindah ke bidang input, pembaca layar hanya mengumumkan “Edit teks, kosong.” Mereka tidak tahu data apa yang seharusnya mereka masukkan.

Perbaikan (Sesudah):

// ✅ Kode yang Benar: Label yang tertaut secara terencana
<div>
  <label htmlFor="email-input">Alamat Email</label>
  <input
    id="email-input"
    type="email"
    placeholder="john@example.com"
  />
</div>

Selalu instruksikan AI Anda untuk “menggunakan tag <label> yang tertaut dengan benar menggunakan properti htmlFor untuk semua input.”

3. Jebakan Keyboard pada Modal

🔴 Kritis · Pengguna Terjebak · WCAG 2.1.2 (No Keyboard Trap)

Modal dan dialog sangat sulit untuk dibuat dengan benar. Ketika AI menghasilkan modal dari nol, ia hampir tidak pernah menerapkan manajemen fokus yang tepat.

Ketika modal terbuka, fokus keyboard harus terjebak di dalam modal agar pengguna tidak sengaja masuk ke konten latar belakang yang tersembunyi. Namun, AI sering lupa menyediakan jalan keluar. Jika tidak ada pemetaan tombol tutup ke kunci Esc, pengguna yang hanya menggunakan keyboard secara resmi “terjebak” di halaman Anda dan harus menyegarkan browser untuk keluar.

Perbaikan: Berhentilah membiarkan AI menulis logika modal yang rumit dari nol. Instruksikan untuk menggunakan elemen <dialog> HTML asli, yang sudah didukung oleh browser modern. Elemen ini menangani jebakan fokus dan kunci Esc secara otomatis.

// ✅ Kode yang Benar: Menggunakan elemen dialog asli
const dialogRef = useRef<HTMLDialogElement>(null);

return (
  <dialog ref={dialogRef}>
    <h2>Berlangganan Newsletter</h2>
    {/* Konten */}
    <button onClick={() => dialogRef.current?.close()}>Tutup</button>
  </dialog>
);

4. Indikator Fokus Tak Terlihat

🟡 Tinggi · Kebingungan Navigasi · WCAG 2.4.13 (Focus Appearance)

Asisten AI sangat suka membuat desain yang ultra-minimalis. Fitur umum dari CSS buatan AI adalah menghapus lingkaran fokus (focus rings) bawaan browser karena “terlihat kurang menarik.”

// ❌ Kode Buatan AI: Menghapus lingkaran fokus
<button style={{ outline: "none" }}>Kirim</button>

Mengapa ini rusak: Jika Anda menghapus outline, pengguna keyboard tidak memiliki indikator visual tentang di mana posisi mereka di halaman. Standar WCAG 2.2 mewajibkan indikator fokus dengan kontras tinggi (setidaknya rasio kontras 3:1) yang terlihat jelas. Jika AI Anda menghapus outline default, perintahkan untuk menggantinya dengan gaya menggunakan pseudo-class :focus-visible.

Jika gaya yang dihasilkan menyebabkan masalah performa selain masalah aksesibilitas, baca ulasan kami tentang 5 Kesalahan CSS dari AI.

5. Alt-Text Kosong atau Halusinasi

🟠 Sedang · Konteks Rusak · WCAG 1.1.1 (Non-text Content)

AI tidak memiliki konteks bisnis dari aplikasi Anda. Saat membuat tag <img>, ia akan membiarkan teks alt kosong, atau berhalusinasi berdasarkan nama variabel.

// ❌ Kode Buatan AI: Konteks yang tidak berguna atau hilang
<img src="/assets/hero-bg.jpg" alt="image" />
<img src="/icons/checkmark.svg" alt="Checkmark icon vector graphic" />

Mengapa ini rusak: Jika gambar murni dekoratif (seperti pola latar belakang), gambar tersebut harus memiliki atribut alt kosong (alt=""). Ini memberi tahu pembaca layar untuk mengabaikannya dengan aman. Jika informatif (seperti bagan), ia memerlukan deskripsi yang tepat. AI tidak dapat membuat perbedaan ini untuk Anda. Anda harus mengaudit tag alt secara manual untuk memastikan nilai yang sebenarnya.

6. Penempatan DOM Ilegal (Pembobol Pohon Aksesibilitas)

🔴 Kritis · Pemrosesan Rusak · Kesalahan Sintaks HTML5

Saat Anda meminta AI untuk “membuat tombol yang mengarah ke pembayaran (checkout),” ia sering kali menghasilkan HTML yang salah—seperti menempatkan tag <button> di dalam tag <a>.

Pendekatan AI (Sebelum):

// ❌ Kode Buatan AI: Penempatan ilegal merusak parser HTML
<a href="/checkout">
  <button onClick={trackEvent}>Beli Sekarang</button>
</a>

Mengapa ini rusak: Browser modern mencoba memperbaiki sintaks ilegal secara otomatis, yang sepenuhnya merusak Pohon Aksesibilitas (Accessibility Tree). Saat pembaca layar menemukan blok ini, ia menjadi bingung oleh elemen interaktif yang bertumpuk. Ia mungkin mengumumkannya dua kali, melewatinya sepenuhnya, atau menjebak fokus keyboard dalam pengulangan (loop).

Perbaikan (Sesudah):

// ✅ Kode yang Benar: Tautan semantik (Link) dengan gaya tombol
import Link from "next/link";

<Link
  href="/checkout"
  className="btn-primary"
  onClick={() => {
    trackEvent("checkout_clicked");
  }}
>
  Beli Sekarang
</Link>;

Untuk mendeteksi kesalahan ini lebih dini, gunakan pemindai Sintaks HTML untuk menganalisis secara statis struktur DOM yang dihasilkan untuk aturan penumpukan yang tidak valid.

7. Bom Nuklir “Aria-Hidden”

🔴 Kritis · Konten Tidak Terlihat · WCAG 1.3.1 (Info and Relationships)

Pemindai Axe-core sering kali menemukan kesalahan AI: koreksi yang berlebihan. Jika Anda meminta AI untuk “memperbaiki masalah pembaca layar pada elemen latar belakang,” ia akan sering memasang aria-hidden="true" pada kontainer pembungkus utama.

Pendekatan AI (Sebelum):

// ❌ Kode Buatan AI: Membungkam seluruh aplikasi
<main aria-hidden="true">
  <div className="decorative-background" />
  <form>
    <label htmlFor="email">Email</label>
    <input
      id="email"
      type="email"
    />
    <button>Kirim</button>
  </form>
</main>

Mengapa ini rusak: Ketika aria-hidden="true" diterapkan pada induk, setiap elemen anak di dalamnya akan dihapus dari Pohon Aksesibilitas. Seluruh formulir menjadi benar-benar tidak terlihat bagi pengguna tunanetra, bahkan jika inputnya sendiri sudah diberi label dengan sempurna. Tampilan UI visual tidak berubah, membuat bug ini hampir mustahil dideteksi tanpa audit Axe-Core.

Perbaikan (Sesudah):

// ✅ Kode yang Benar: Menyembunyikan hanya elemen dekoratif
<main>
  <div
    aria-hidden="true"
    className="decorative-background"
  />
  <form>
    <label htmlFor="email">Email</label>
    <input
      id="email"
      type="email"
    />
    <button>Kirim</button>
  </form>
</main>

Fakta: Krisis Utang Aksesibilitas

Untuk memahami mengapa mengandalkan AI saja berbahaya, kita harus melihat keadaan web saat ini. Laporan WebAIM Million 2024 menganalisis 1 juta halaman utama teratas dan menemukan bahwa 95,9% di antaranya memiliki kegagalan WCAG 2 yang terdeteksi.

Kegagalan yang paling umum sangat cocok dengan kode yang cenderung dihasilkan oleh AI:

1. Teks dengan kontras rendah (81%)
2. Kehilangan teks alternatif untuk gambar (54%)
3. Kehilangan label input formulir (48%)

Saat Anda melakukan “vibe-code” tanpa audit, Anda bukan sekadar membuat kesalahan—Anda secara langsung berkontribusi pada kesenjangan aksesibilitas terbesar di industri ini.

Kemampuan Audit WebValid

Model AI sangat luar biasa dalam menulis kode, tetapi mereka buruk dalam melihat hasil akhir DOM. Anda tidak bisa hanya menempelkan kode ke ChatGPT dan bertanya “Apakah ini dapat diakses?” karena satu komponen React tidak menunjukkan cara kerjanya di browser.

WebValid menjembatani kesenjangan ini dengan memindai HTML yang dihasilkan sepenuhnya dan bertindak sebagai penerjemah teknis untuk asisten AI Anda.

WebValid menggunakan pengujian browser canggih untuk meniru bagaimana pembaca layar asli memproses DOM Anda, menemukan kesalahan yang ditinggalkan oleh asisten AI Anda.

Checklist Pengujian Aksesibilitas Anda

Sebelum meluncurkan kode buatan AI, jalankan daftar periksa cepat ini:

1. Tes Tab: Lepaskan mouse Anda dan coba navigasikan situs Anda hanya menggunakan Tab, Shift + Tab, dan Enter.
2. Tes Modal: Buka setiap modal/dropdown dan tekan Esc. Apakah tertutup?
3. Tes Pembaca Layar: Nyalakan VoiceOver (Mac) atau NVDA (Windows) dan tutup mata Anda. Bisakah Anda mengisi formulir utama Anda?

Asisten AI Anda dapat menulis kode yang luar biasa—hanya saja ia tidak tahu di mana letak kesalahannya. Jika Anda memberinya peta kesalahan, ia dapat memperbaikinya sendiri. Jangan menebak apakah situs Anda sudah patuh atau belum. Dapatkan audit deterministik dari DOM Anda, ubah menjadi perintah perbaikan AI, dan selesaikan masalah ini dalam hitungan menit.

Mulai audit gratis