Cara Buat Laman Web Anda Boleh Diakses: Panduan Permulaan WCAG 2.2

Untuk membuat laman web yang boleh diakses, bina supaya orang boleh menggunakannya dengan papan kekunci, pembaca skrin, zum atau peranti suis, bukan hanya tetikus: gunakan elemen HTML sebenar untuk butang, pautan, tajuk dan label borang; beri imej teks alt yang bermakna; kekalkan kontras teks yang tinggi dan pastikan fokus kelihatan. Standard yang perlu disasarkan ialah WCAG 2.2 Tahap AA. Pemeriksa automatik menangkap sebahagian masalah; ujian papan kekunci dan pembaca skrin selama sepuluh minit menangkap banyak masalah yang selebihnya.

Apa maksud "boleh diakses" dalam amalan

Kebolehaksesan adalah tentang orang: seseorang yang buta dan menggunakan pembaca skrin, seseorang yang tangannya menggeletar dan menavigasi dengan papan kekunci, seseorang yang berpenglihatan rendah dan zum hingga 200%, seseorang yang membaca di bawah cahaya matahari yang terik, seseorang yang tangannya patah buat sementara waktu. Kebolehaksesan yang baik cenderung menjadikan laman lebih baik untuk semua orang — struktur yang lebih jelas, teks yang mudah dibaca, borang yang menerangkan ralatnya.

Standard rujukannya ialah Garis Panduan Kebolehaksesan Kandungan Web (WCAG) W3C. Setakat September 2026, versi semasanya ialah WCAG 2.2 (diterbitkan Oktober 2023, dikemas kini Disember 2024); WCAG 3 ialah draf awal. WCAG disusun di sekitar empat prinsip — kandungan mesti boleh dilihat, boleh dikendalikan, boleh difahami dan teguh — dan mempunyai tiga tahap pematuhan:

Tahap	Maksudnya	Siapa yang menyasarkannya
A	Minimum; tanpanya, sesetengah orang langsung tidak dapat menggunakan laman	Semua orang
AA	Sasaran biasa; meliputi kontras, fokus, saiz semula dan pengendalian ralat	Kebanyakan organisasi dan banyak undang-undang
AAA	Paling ketat; tidak boleh dicapai untuk semua kandungan	Perkhidmatan dan khalayak tertentu

Undang-undang di beberapa tempat merujuk WCAG — contohnya Akta Kebolehaksesan Eropah, yang telah terpakai kepada banyak perkhidmatan digital berorientasikan pengguna di EU sejak Jun 2025. Peraturan mana yang terpakai kepada anda bergantung pada tempat anda beroperasi dan apa yang anda jual; semak dengan penasihat jika anda tidak pasti. Panduan ini meliputi kerja praktikalnya.

Pilihan: cara untuk sampai ke sana

Pendekatan	Sesuai untuk	Pertukaran
Bina dari awal	Laman dan aplikasi baharu	Usaha paling sedikit keseluruhannya; perlu dinyatakan dari awal
Audit dan betulkan	Laman sedia ada	Mengesan isu sebenar; memerlukan laluan fokus setiap halaman
Audit profesional	Sektor terkawal selia, laman besar, badan awam	Menyeluruh dan didokumentasikan; memerlukan kos
Widget overlay	Tidak disyorkan	Tidak dapat membetulkan kod asas

Bagi kebanyakan laman kecil, dua yang pertama sudah memadai: beritahu AI untuk membina secara boleh diakses dari awal, kemudian audit sebelum pelancaran.

Pembetulan yang paling penting

Gunakan elemen HTML yang betul

Kebanyakan kebolehaksesan datang percuma dengan HTML yang betul. <button> boleh difokuskan, berfungsi dengan Enter dan Space, dan diumumkan sebagai butang. <div> dengan pengendali klik bukan kesemuanya. Kod yang dijana AI kadangkala menggunakan div bergaya untuk semua perkara; minta elemen semantik:

<button> untuk tindakan, <a href> untuk navigasi
Satu <h1> setiap halaman, kemudian <h2>, <h3> mengikut urutan — pengguna pembaca skrin melompat antara tajuk
Mata tanda: <header>, <nav>, <main>, <footer>
<label> yang disambungkan kepada setiap medan borang
Bahasa halaman dalam <html lang="en">

Gunakan atribut ARIA hanya apabila tiada elemen asli yang sesuai — contohnya untuk set tab atau combobox tersuai. ARIA yang salah lebih teruk daripada tiada langsung.

Akses papan kekunci dan fokus yang kelihatan

Semua yang boleh anda lakukan dengan tetikus mesti berfungsi dengan papan kekunci sahaja (WCAG 2.1.1). Tekan Tab melalui halaman: setiap pautan, butang dan medan patut boleh dicapai mengikut susunan yang logik, dan anda sentiasa boleh melihat di mana fokus berada (2.4.7 Fokus Kelihatan). WCAG 2.2 menambah bahawa elemen yang difokuskan tidak boleh tersembunyi sepenuhnya di belakang pengepala melekat atau sepanduk kuki (2.4.11, Tahap AA).

Kegagalan biasa: menu yang hanya dibuka apabila tetikus dilayangkan, modal yang tidak mengunci fokus atau tidak boleh ditutup dengan Escape, dan outline: none dalam CSS tanpa gantian.

Alternatif teks

Setiap imej bermakna memerlukan teks alt yang menerangkan apa yang ditunjukkannya dalam konteks ("Chef menghidangkan menu degustasi", bukan "image1.jpg"). Imej hiasan mendapat alt="" kosong supaya pembaca skrin melangkaunya. Butang ikon sahaja memerlukan nama yang boleh diakses ("Tutup", "Cari"). Video memerlukan sari kata; audio memerlukan transkrip.

Warna dan kontras

WCAG 2.2 AA memerlukan nisbah kontras sekurang-kurangnya 4.5:1 untuk teks normal dan 3:1 untuk teks besar (1.4.3), dan 3:1 untuk bahagian antara muka seperti sempadan input dan ikon yang bermakna (1.4.11). Teks placeholder kelabu muda dan butang pucat ialah kegagalan biasa. Juga, jangan sekali-kali gunakan warna sahaja untuk menyampaikan makna — sempadan merah pada medan yang tidak sah memerlukan mesej ralat juga.

Saiz semula dan reflow

Teks mesti kekal boleh digunakan apabila di-zum hingga 200% (1.4.4), dan kandungan mesti berfungsi pada lebar 320 piksel CSS tanpa perlu skrol ke sisi (1.4.10). Susun atur responsif yang baik mengendalikan kebanyakan perkara ini.

Saiz sasaran, borang dan ralat

Saiz sasaran: WCAG 2.2 AA memerlukan sasaran penunjuk sekurang-kurangnya 24 × 24 piksel CSS, atau ruang yang mencukupi di sekeliling yang lebih kecil (2.5.8). Lebih besar lebih mesra pada telefon.
Borang: label yang kelihatan (bukan hanya placeholder), arahan yang jelas, dan mesej ralat yang menerangkan apa yang salah dan cara membetulkannya, di sebelah medan.
Log masuk: jangan minta orang menyelesaikan teka-teki atau menyalin kod tanpa alternatif; benarkan pengurus kata laluan dan tampalan (3.3.8 Pengesahan Boleh Diakses).

Prompt yang berfungsi

Bina laman ini untuk memenuhi WCAG 2.2 Tahap AA: mata tanda HTML semantik, satu h1 setiap halaman dengan tajuk mengikut urutan, elemen butang dan pautan yang sebenar, label pada setiap medan borang, gaya fokus yang kelihatan, kontras teks sekurang-kurangnya 4.5:1, teks alt pada imej bermakna dan alt="" pada imej hiasan, serta html lang ditetapkan.

Audit halaman /signup dan /checkout untuk kebolehaksesan. Semak penggunaan dengan papan kekunci sahaja, susunan fokus, fokus yang kelihatan, label, mesej ralat, kontras dan nama pembaca skrin untuk butang ikon. Senaraikan setiap masalah dengan kriteria WCAG, kemudian betulkannya tanpa mengubah reka bentuk visual lebih daripada perlu.

Menu mudah alih tidak boleh digunakan dengan papan kekunci. Jadikannya butang dengan aria-expanded, alihkan fokus ke dalam menu apabila ia dibuka, tutupkannya dengan Escape dan kembalikan fokus ke butang.

Langkah demi langkah

Jalankan pemeriksaan automatik. Bahagian Kebolehaksesan Lighthouse dalam Chrome DevTools, atau sambungan pelayar axe, pada setiap halaman utama. Betulkan semua yang dilaporkannya.
Tanggalkan tetikus. Tekan Tab melalui setiap halaman dan selesaikan setiap tugas utama — daftar masuk, cari, bayar. Catat apa-apa yang tidak boleh dicapai, tidak dapat dilihat fokusnya, atau tidak boleh dilepaskan.
Zum ke 200% dan kecilkan tetingkap kepada lebar telefon. Tiada apa yang sepatutnya terpotong atau memerlukan skrol ke sisi.
Cuba pembaca skrin selama sepuluh minit: VoiceOver pada Mac dan iPhone, TalkBack pada Android, atau NVDA pada Windows (percuma). Dengar tajuk, pautan dan medan borang. "Butang" tanpa nama, atau "pautan, klik sini", bermakna kerja yang perlu dibuat.
Semak kontras untuk teks, butang dan input dengan pemeriksa kontras.
Betulkan, kemudian uji semula tugas yang sama.
Terbitkan penyataan kebolehaksesan yang menyatakan standard yang anda sasarkan dan cara melaporkan masalah — dan jawab laporan tersebut.

Kesilapan biasa

Bergantung pada widget overlay dan bukannya membetulkan kod.
Membuang garis fokus kerana nampak tidak kemas, tanpa gantian.
Teks placeholder sebagai satu-satunya label. Ia hilang apabila seseorang mula menaip dan selalunya berkontras rendah.
Pautan "Klik sini" dan "Baca lagi". Di luar konteks, pengguna pembaca skrin mendengar senarai pautan yang sama berulang kali.
Teks alt yang dipenuhi kata kunci. Teks alt untuk orang; terangkan imejnya.
Menguji sekali sahaja. Setiap ciri baharu boleh merosakkan akses papan kekunci. Tambahkan laluan papan kekunci pada ujian pra-pelancaran anda.

Senarai semak kebolehaksesan

Pemeriksaan automatik (Lighthouse atau axe) bersih pada halaman utama
Setiap tugas boleh diselesaikan dengan papan kekunci sahaja
Fokus sentiasa kelihatan dan tidak pernah tersembunyi di belakang elemen melekat
Tajuk, mata tanda, butang dan pautan semantik; lang ditetapkan
Teks alt yang bermakna; imej hiasan alt=""; sari kata pada video
Kontras teks ≥ 4.5:1 (teks besar ≥ 3:1); bahagian UI ≥ 3:1
Berfungsi pada zum 200% dan lebar 320 px
Setiap medan borang mempunyai label yang kelihatan dan mesej ralat yang jelas
Penyataan kebolehaksesan dengan cara untuk melaporkan masalah

Untuk konsep di sebalik semua ini, baca apa itu kebolehaksesan web. Reka bentuk yang boleh diakses dan reka bentuk yang cantik banyak bertindih; cara mereka bentuk aplikasi yang cantik dengan AI meliputi bahagian visualnya.

Kebolehaksesan di Mythex

Mythex membina dengan standard yang anda minta, jadi letakkan "WCAG 2.2 AA" dalam prompt pertama anda dan dalam susulan. Anda boleh menggunakan bingkai saiz telefon Pratonton untuk menyemak skrin kecil (Pratonton dan Kod), tetapi ujian papan kekunci, zum dan pembaca skrin berfungsi paling baik pada URL yang diterbitkan atau pratonton yang dibuka dalam tab sendiri. Minta ejen mengaudit satu halaman, betulkan apa yang dijumpainya, kemudian uji pembetulan itu sendiri — pemeriksaan automatik ialah permulaan, bukan tanda lulus muktamad.

Soalan lazim

Apakah standard kebolehaksesan semasa untuk laman web?

Setakat September 2026, standard W3C semasa ialah WCAG 2.2, pertama kali diterbitkan pada Oktober 2023. Kebanyakan organisasi dan banyak undang-undang menyasarkan Tahap AA. WCAG 3 masih draf awal.

Bolehkah overlay kebolehaksesan menjadikan laman saya patuh?

Jangan bergantung padanya. Overlay menambah bar alat di atas halaman tetapi tidak dapat membetulkan label yang hilang, akses papan kekunci yang rosak atau struktur yang lemah dalam kod asas. Membetulkan laman itu sendiri yang menjadikannya boleh digunakan.

Adakah pemeriksa automatik menemui setiap masalah?

Tidak. Alat seperti Lighthouse dan axe menangkap perkara seperti teks alt yang hilang, kontras rendah dan medan tanpa label, tetapi banyak isu — seperti susunan fokus yang mengelirukan, teks pautan yang tidak bermakna, teks alt yang wujud tetapi salah — memerlukan manusia menyemaknya dengan papan kekunci dan pembaca skrin.

Apakah nisbah kontras yang diperlukan WCAG?

WCAG 2.2 Tahap AA memerlukan sekurang-kurangnya 4.5:1 untuk teks normal dan 3:1 untuk teks besar, serta 3:1 untuk komponen antara muka seperti sempadan input dan ikon yang menyampaikan makna.