Cara Membuat Website Anda Dapat Diakses: Panduan Dasar WCAG 2.2

Untuk membuat website yang dapat diakses, bangun agar orang bisa memakainya dengan keyboard, pembaca layar, zoom, atau perangkat sakelar, selain dengan mouse: gunakan elemen HTML yang tepat untuk tombol, tautan, judul, dan label formulir; beri gambar alt text yang bermakna; jaga kontras teks tetap tinggi; dan pastikan fokus terlihat. Standar yang perlu dituju adalah WCAG 2.2 Level AA. Pemeriksa otomatis menangkap sebagian masalah; tes keyboard dan pembaca layar selama sepuluh menit menangkap sebagian besar sisanya.

Apa arti "dapat diakses" dalam praktik

Aksesibilitas menyangkut orang: seseorang yang tunanetra dan memakai pembaca layar, seseorang dengan tremor yang bernavigasi lewat keyboard, seseorang dengan penglihatan rendah yang memperbesar tampilan hingga 200%, seseorang yang membaca di bawah sinar matahari terik, seseorang dengan pergelangan tangan patah sementara. Aksesibilitas yang baik cenderung membuat situs lebih baik bagi semua orang: struktur yang jelas, teks yang mudah dibaca, dan formulir yang menjelaskan kesalahannya.

Standar acuan adalah Web Content Accessibility Guidelines (WCAG) dari W3C. Per September 2026, versi saat ini adalah WCAG 2.2 (dipublikasikan Oktober 2023, diperbarui Desember 2024); WCAG 3 masih berupa draf awal. WCAG disusun di sekitar empat prinsip — konten harus dapat dipersepsi, dapat dioperasikan, dapat dimengerti, dan kokoh — dan memiliki tiga tingkat kepatuhan:

Level	Artinya	Siapa yang menargetkannya
A	Minimum; tanpanya, sebagian orang tidak bisa memakai situs sama sekali	Semua orang
AA	Target umum; mencakup kontras, fokus, perubahan ukuran, dan penanganan kesalahan	Sebagian besar organisasi dan banyak regulasi
AAA	Yang paling ketat; tidak selalu bisa dicapai untuk semua konten	Layanan dan audiens tertentu

Beberapa regulasi di berbagai tempat merujuk pada WCAG — misalnya European Accessibility Act, yang berlaku bagi banyak layanan digital konsumen di UE sejak Juni 2025. Aturan mana yang berlaku bagi Anda bergantung pada tempat Anda beroperasi dan apa yang Anda jual; konsultasikan dengan penasihat jika Anda tidak yakin. Panduan ini membahas pekerjaan praktisnya.

Pilihan: bagaimana mencapainya

Pendekatan	Cocok untuk	Konsekuensi
Bangun sejak awal	Situs dan aplikasi baru	Usaha paling sedikit secara keseluruhan; perlu disepakati di awal
Audit dan perbaiki	Situs yang sudah ada	Menemukan masalah nyata; butuh pemeriksaan terfokus per halaman
Audit profesional	Sektor yang diatur, situs besar, lembaga publik	Menyeluruh dan terdokumentasi; butuh biaya
Widget overlay	Tidak direkomendasikan	Tidak bisa memperbaiki kode yang mendasarinya

Untuk sebagian besar situs kecil, dua pendekatan pertama sudah cukup: minta AI membangun secara aksesibel sejak awal, lalu audit sebelum peluncuran.

Perbaikan yang paling penting

Gunakan elemen HTML yang tepat

Sebagian besar aksesibilitas datang gratis dengan HTML yang benar. <button> bisa difokus, bekerja dengan Enter dan Spasi, dan diumumkan sebagai tombol. <div> dengan handler klik tidak punya satu pun dari itu. Kode yang dihasilkan AI kadang memakai div bergaya untuk segalanya; mintalah elemen semantik:

<button> untuk aksi, <a href> untuk navigasi
Satu <h1> per halaman, lalu <h2>, <h3> secara berurutan — pengguna pembaca layar melompat di antara judul
Landmark: <header>, <nav>, <main>, <footer>
<label> yang terhubung ke setiap kolom formulir
Bahasa halaman di <html lang="id">

Gunakan atribut ARIA hanya jika tidak ada elemen asli yang cocok — misalnya untuk kumpulan tab kustom atau combobox. ARIA yang keliru lebih buruk daripada tidak sama sekali.

Akses keyboard dan fokus yang terlihat

Semua yang bisa dilakukan dengan mouse harus bisa dilakukan dengan keyboard saja (WCAG 2.1.1). Tekan Tab di seluruh halaman: setiap tautan, tombol, dan kolom harus bisa dijangkau dengan urutan yang logis, dan Anda selalu harus melihat di mana fokus berada (2.4.7 Focus Visible). WCAG 2.2 menambahkan bahwa elemen yang difokus tidak boleh tersembunyi sepenuhnya di balik header lengket atau banner cookie (2.4.11, Level AA).

Kegagalan yang umum: menu yang hanya terbuka saat hover, modal yang tidak mengunci fokus atau tidak bisa ditutup dengan Escape, dan outline: none di CSS tanpa pengganti.

Alternatif teks

Setiap gambar yang bermakna membutuhkan alt text yang menjelaskan apa yang ditampilkan dalam konteksnya ("Koki menata menu tasting", bukan "image1.jpg"). Gambar dekoratif diberi alt="" kosong agar pembaca layar melewatinya. Tombol yang hanya berisi ikon perlu nama yang bisa diakses ("Tutup", "Cari"). Video butuh keterangan (caption); audio butuh transkrip.

Warna dan kontras

WCAG 2.2 AA mewajibkan rasio kontras minimal 4,5:1 untuk teks normal dan 3:1 untuk teks besar (1.4.3), serta 3:1 untuk bagian antarmuka seperti border input dan ikon yang bermakna (1.4.11). Teks placeholder abu-abu terang dan tombol pucat adalah kegagalan yang paling umum. Selain itu, jangan pernah hanya memakai warna untuk menyampaikan makna — border merah pada kolom yang tidak valid juga memerlukan pesan kesalahan.

Ukuran ulang dan reflow

Teks harus tetap bisa dipakai saat diperbesar hingga 200% (1.4.4), dan konten harus berfungsi pada lebar 320 piksel CSS tanpa perlu digulir ke samping (1.4.10). Tata letak responsif yang baik menangani sebagian besar hal ini.

Target, formulir, dan kesalahan

Ukuran target: WCAG 2.2 AA meminta target pointer minimal 24 kali 24 piksel CSS, atau jarak yang cukup di sekitar target yang lebih kecil (2.5.8). Lebih besar lebih ramah di ponsel.
Formulir: label yang terlihat (bukan hanya placeholder), instruksi yang jelas, dan pesan kesalahan yang menjelaskan apa yang salah dan cara memperbaikinya, di dekat kolom tersebut.
Login: jangan minta orang memecahkan teka-teki atau menyalin kode tanpa alternatif; izinkan pengelola kata sandi dan menempel (3.3.8 Accessible Authentication).

Prompt yang berhasil

Bangun situs ini agar memenuhi WCAG 2.2 Level AA: landmark HTML semantik, satu h1 per halaman dengan judul berurutan, elemen tombol dan tautan yang asli, label pada setiap kolom formulir, gaya fokus yang terlihat, kontras teks minimal 4,5:1, alt text pada gambar bermakna dan alt="" pada gambar dekoratif, serta html lang diatur.

Audit halaman /signup dan /checkout untuk aksesibilitas. Periksa penggunaan hanya dengan keyboard, urutan fokus, fokus yang terlihat, label, pesan kesalahan, kontras, dan nama pembaca layar untuk tombol berisi ikon. Daftar setiap masalah beserta kriteria WCAG-nya, lalu perbaiki tanpa mengubah desain visual lebih dari yang diperlukan.

Menu seluler tidak bisa dipakai dengan keyboard. Jadikan sebagai tombol dengan aria-expanded, pindahkan fokus ke dalam menu saat terbuka, tutup dengan Escape, dan kembalikan fokus ke tombol.

Langkah demi langkah

Jalankan pemeriksaan otomatis. Bagian Accessibility dari Lighthouse di Chrome DevTools, atau ekstensi browser axe, di setiap halaman utama. Perbaiki semua yang dilaporkan.
Lepas mouse. Tekan Tab melalui setiap halaman dan selesaikan setiap tugas utama — daftar, cari, checkout. Catat apa pun yang tidak bisa dijangkau, fokusnya tidak terlihat, atau tidak bisa ditinggalkan.
Perbesar hingga 200% dan persempit jendela ke lebar ponsel. Tidak boleh ada yang terpotong atau perlu digulir ke samping.
Coba pembaca layar selama sepuluh menit: VoiceOver di Mac dan iPhone, TalkBack di Android, atau NVDA di Windows (gratis). Dengarkan judul, tautan, dan kolom formulir. "Tombol" tanpa nama, atau "tautan, klik di sini", berarti masih ada pekerjaan.
Periksa kontras untuk teks, tombol, dan input dengan pemeriksa kontras.
Perbaiki, lalu uji ulang tugas yang sama.
Terbitkan pernyataan aksesibilitas yang menyebutkan standar yang Anda tuju dan cara melaporkan masalah — lalu tanggapi laporan tersebut.

Kesalahan yang umum

Mengandalkan widget overlay alih-alih memperbaiki kode.
Menghapus garis fokus karena terlihat berantakan, tanpa pengganti.
Teks placeholder sebagai satu-satunya label. Teks itu hilang begitu seseorang mulai mengetik dan sering kali kontrasnya rendah.
Tautan "Klik di sini" dan "Baca selengkapnya". Di luar konteksnya, pengguna pembaca layar hanya mendengar daftar tautan yang sama.
Alt text yang dijejali kata kunci. Alt text untuk orang; deskripsikan gambarnya.
Hanya menguji sekali. Setiap fitur baru bisa merusak akses keyboard. Tambahkan pengecekan keyboard ke pengujian pra-peluncuran Anda.

Daftar periksa aksesibilitas

Pemeriksaan otomatis (Lighthouse atau axe) bersih di halaman utama
Setiap tugas bisa diselesaikan hanya dengan keyboard
Fokus selalu terlihat dan tidak pernah tersembunyi di balik elemen lengket
Judul, landmark, tombol, dan tautan semantik; lang diatur
Alt text yang bermakna; gambar dekoratif alt=""; keterangan pada video
Kontras teks ≥ 4,5:1 (teks besar ≥ 3:1); bagian UI ≥ 3:1
Berfungsi pada zoom 200% dan lebar 320 px
Setiap kolom formulir memiliki label yang terlihat dan pesan kesalahan yang jelas
Pernyataan aksesibilitas dengan cara untuk melaporkan masalah

Untuk konsep di balik ini, baca apa itu aksesibilitas web. Desain yang aksesibel dan desain yang bagus banyak tumpang tindih; cara mendesain aplikasi yang bagus dengan AI membahas sisi visualnya.

Aksesibilitas di Mythex

Mythex membangun dengan standar apa pun yang Anda minta, jadi tulis "WCAG 2.2 AA" di prompt pertama Anda dan di tindak lanjut. Anda bisa memakai bingkai ukuran ponsel di Preview untuk memeriksa layar kecil (Preview dan Code), tetapi tes keyboard, zoom, dan pembaca layar paling baik dilakukan di URL yang sudah dipublikasikan atau pratinjau yang dibuka di tab tersendiri. Minta agen mengaudit sebuah halaman, memperbaiki yang ditemukan, lalu uji perbaikannya sendiri — pemeriksaan otomatis hanyalah permulaan, bukan tanda persetujuan akhir.

Pertanyaan

Apa standar aksesibilitas website yang berlaku saat ini?

Per September 2026, standar W3C yang berlaku adalah WCAG 2.2, yang pertama kali dipublikasikan pada Oktober 2023. Sebagian besar organisasi dan banyak regulasi menargetkan Level AA. WCAG 3 masih berupa draf awal.

Bisakah overlay aksesibilitas membuat situs saya patuh?

Jangan mengandalkannya. Overlay menambahkan bilah alat di atas halaman, tetapi tidak bisa memperbaiki label yang hilang, akses keyboard yang rusak, atau struktur yang buruk di dalam kode dasarnya. Memperbaiki situs itu sendiri yang membuatnya bisa digunakan.

Apakah pemeriksa otomatis menemukan semua masalah?

Tidak. Alat seperti Lighthouse dan axe menangkap hal-hal seperti alt text yang hilang, kontras rendah, dan kolom tanpa label, tetapi banyak masalah, seperti urutan fokus yang membingungkan, teks tautan yang tidak bermakna, atau alt text yang ada tetapi keliru, perlu diperiksa orang dengan keyboard dan pembaca layar.

Berapa rasio kontras yang diwajibkan WCAG?

WCAG 2.2 Level AA meminta minimal 4,5:1 untuk teks normal dan 3:1 untuk teks besar, serta 3:1 untuk komponen antarmuka seperti border input dan ikon yang menyampaikan makna.