# Senarai semak WCAG 2.2 AA untuk produk SaaS dan aplikasi web

<https://www.fixreports.com/ms/blog/wcag-2-2-checklist-saas-web-apps>

Dikemas kini 2026-10-26

Produk SaaS mempunyai dua permukaan kebolehcapaian: laman pemasaran yang menjualnya dan aplikasi yang digunakan orang setiap hari. Laman pemasaran gagal dengan cara yang sama seperti mana-mana laman web, dengan kontras rendah, teks alt yang tiada dan borang tanpa label. Aplikasi pula menambah masalahnya sendiri: aliran log masuk yang menyekat pengurus kata laluan, dialog yang memerangkap fokus papan kekunci, navigasi halaman tunggal yang tidak disedari oleh pembaca skrin, jadual data dan carta tanpa teks, seret dan lepas tanpa alternatif, dan sesi yang tamat tanpa amaran. Senarai semak ini meneliti WCAG 2.2 Tahap AA mengikut bahagian produk SaaS yang biasa.

**Perkara utama**

- WCAG 2.2 menjadi Syor W3C (W3C Recommendation) pada Oktober 2023 dan menambah sembilan kriteria kejayaan, enam daripadanya pada Tahap A atau AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) bermaksud log masuk tidak boleh bergantung pada mengingat atau menyalin semula kata laluan melainkan pengguna boleh menampalnya atau menggunakan pengurus kata laluan ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Sasaran interaktif mestilah sekurang-kurangnya 24 × 24 piksel CSS, atau mempunyai ruang yang mencukupi di sekelilingnya (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Mesej seperti “Disimpan” atau “3 hasil” mesti sampai kepada pembaca skrin tanpa mengalihkan fokus (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Pembeli perniagaan dan sektor awam sering meminta Accessibility Conformance Report (ACR), yang biasanya ditulis menggunakan templat VPAT daripada Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Mengapakah kebolehcapaian lebih penting bagi SaaS berbanding laman brosur?

Orang menggunakan produk SaaS berjam-jam lamanya, selalunya kerana majikan mereka yang memilihnya. Halangan pada halaman pemasaran menyebabkan anda kehilangan seorang pelawat; halangan dalam produk boleh menghalang seseorang daripada melakukan kerjanya. Itulah sebabnya pelanggan yang lebih besar, universiti dan badan awam semakin kerap bertanya tentang kebolehcapaian sebelum membeli, dan sebabnya jawapan anda perlu meliputi aplikasi, bukan laman web sahaja.

Ia juga penting kerana ujian automatik hanya menangkap sebahagian daripada masalah. Alat seperti axe-core menemui kegagalan dalam markup, seperti label yang tiada dan kontras rendah. Alat ini tidak dapat menentukan sama ada dialog mengembalikan fokus ke tempat yang betul, sama ada data carta tersedia sebagai teks, atau sama ada sesuatu aliran kerja boleh diselesaikan dengan papan kekunci. Aplikasi memerlukan kedua-dua semakan automatik dan ujian manual.

## Bagaimanakah cara menjadikan pendaftaran dan log masuk boleh diakses?

Pengesahan identiti ialah bahagian di mana WCAG 2.2 menambah keperluan baharu yang paling penting bagi SaaS.

- **Benarkan tampal dan pengurus kata laluan (3.3.8, AA).** Jangan sekat penampalan ke dalam medan kata laluan atau kod, dan gunakan `autocomplete="username"`, `autocomplete="current-password"` dan `autocomplete="one-time-code"` supaya pelayar dan pengurus kata laluan boleh mengisinya.
- **Elakkan teka-teki sebagai satu-satunya cara untuk masuk.** CAPTCHA yang meminta orang menyalin teks yang diherotkan atau menyelesaikan teka-teki ialah ujian fungsi kognitif. Sediakan alternatif, dan utamakan semakan yang tidak memerlukan tindakan pengguna ([W3C](https://www.w3.org/TR/turingtest/)).
- **Labelkan setiap medan (1.3.1 dan 3.3.2, A).** Gunakan `<label>` yang kelihatan dan disambungkan kepada inputnya; teks pemegang tempat hilang apabila seseorang menaip dan bukan label.
- **Kenal pasti ralat dalam teks (3.3.1, A) dan cadangkan pembetulan (3.3.3, AA).** “Kata laluan mesti mempunyai sekurang-kurangnya 12 aksara” membantu; sempadan merah sahaja tidak.
- **Jangan minta dua kali (3.3.7, A).** Jika pendaftaran berbilang langkah sudah meminta nama syarikat atau alamat, isikannya atau benarkan orang memilihnya dan bukannya menaip semula.
- **Kekalkan bantuan di tempat yang sama (3.2.6, A).** Jika anda menawarkan sembang, pautan bantuan atau butiran hubungan, letakkannya pada kedudukan relatif yang sama pada setiap halaman dalam aliran itu.

## Corak borang dan ralat manakah yang paling banyak menyebabkan kegagalan?

Borang ialah tempat kebanyakan kegagalan aplikasi berlaku. Tinjauan WebAIM 2026 terhadap sejuta halaman utama menemui label borang yang tiada pada 51% daripadanya ([WebAIM](https://webaim.org/projects/million/)), dan aplikasi mempunyai jauh lebih banyak borang berbanding halaman utama.

- Berikan setiap input nama secara atur cara (programmatic name), dan kumpulkan kawalan yang berkaitan, seperti butang radio, dengan `<fieldset>` dan `<legend>`.
- Maklumkan ralat di tempat yang akan disedari: alihkan fokus ke ringkasan ralat di bahagian atas borang, atau ke medan pertama yang tidak sah, dan pautkan setiap item ringkasan kepada medannya.
- Tandakan medan wajib dalam teks, bukan dengan warna sahaja (1.4.1, A).
- Jangan hantar borang atau tukar konteks apabila seseorang hanya memilih satu pilihan (3.2.2, A); tunggu tindakan yang jelas.

## Bagaimanakah dialog, menu dan popover sepatutnya berfungsi?

Komponen tersuai ialah tempat sokongan papan kekunci dan pembaca skrin paling kerap rosak. WAI-ARIA Authoring Practices Guide menerangkan tingkah laku yang dijangka bagi setiap corak ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialog**: alihkan fokus ke dalam dialog apabila ia dibuka, kekalkan Tab di dalamnya semasa ia terbuka, tutupnya dengan Escape, dan kembalikan fokus kepada kawalan yang membukanya. Gunakan elemen asli `<dialog>` atau `role="dialog"` dengan `aria-modal="true"` dan nama.
- **Tiada perangkap papan kekunci (2.1.2, A)**: setiap komponen mesti boleh ditinggalkan dengan papan kekunci.
- **Fokus yang kelihatan (2.4.7, AA)** yang tidak tersembunyi di belakang pengepala melekit, sepanduk kuki atau widget sembang (2.4.11, AA, baharu dalam 2.2).
- **Tooltip dan popover (1.4.13, AA)** yang boleh ditutup dengan Escape, boleh dihalakan tetikus ke atasnya tanpa hilang, dan kekal sehingga ditutup.
- **Pintasan satu kekunci (2.1.4, A)**: jika menekan kekunci huruf mencetuskan tindakan, benarkan orang mematikan pintasan atau memetakannya semula, atau jadikannya aktif hanya apabila komponen berkaitan mempunyai fokus.

## Bagaimanakah cara mengendalikan navigasi dalam aplikasi halaman tunggal?

Dalam aplikasi halaman tunggal (single-page app), URL berubah tanpa pemuatan halaman, jadi pembaca skrin mungkin tidak mengumumkan bahawa sesuatu telah berlaku.

- Kemas kini tajuk dokumen pada setiap perubahan laluan, supaya setiap paparan mempunyai tajuk yang deskriptif (2.4.2, A).
- Alihkan fokus ke tajuk utama paparan baharu, atau umumkan perubahan itu dalam kawasan langsung (live region) yang sopan; rangka kerja seperti Next.js menyertakan pengumum laluan (route announcer) untuk tujuan ini.
- Kekalkan susunan fokus yang logik (2.4.3, A): selepas sesuatu item dipadam, fokus sepatutnya beralih ke item jiran yang munasabah, bukan kembali ke bahagian atas halaman.
- Sediakan cara untuk melangkau navigasi berulang (2.4.1, A), seperti pautan langkau atau landmark.

## Bagaimanakah cara menjadikan papan pemuka, jadual data dan carta boleh diakses?

- **Jadual**: gunakan markup `<table>` sebenar dengan `<th>` dan `scope` untuk pengepala, serta kapsyen (1.3.1, A). Grid yang dibina daripada elemen `<div>` memerlukan corak grid ARIA penuh, yang jauh lebih sukar untuk dilakukan dengan betul.
- **Carta**: berikan setiap carta alternatif teks yang menyatakan perkara utamanya, dan tawarkan data sebagai jadual (1.1.1, A). Jangan bergantung pada warna sahaja untuk membezakan siri (1.4.1, A); tambah label atau corak.
- **Kontras**: teks memerlukan 4.5:1 (1.4.3, AA), dan garisan carta, ikon serta sempadan input memerlukan 3:1 berbanding latar belakangnya (1.4.11, AA). Semak mod gelap secara berasingan. [Penyemak kontras warna](/ms/color-contrast-checker) kami menguji mana-mana pasangan warna.
- **Mesej status (4.1.3, AA)**: “Disimpan”, “Muat naik selesai” dan kiraan hasil sepatutnya menggunakan `role="status"` atau kawasan langsung, supaya pembaca skrin mendengarnya tanpa kehilangan kedudukan.

## Apakah perubahan yang dibawa oleh kriteria baharu WCAG 2.2 bagi aplikasi web?

| Kriteria | Tahap | Maksudnya dalam aplikasi |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Bar alat melekit, sepanduk dan widget sembang tidak boleh menutup sepenuhnya elemen yang difokuskan |
| 2.5.7 Dragging Movements | AA | Apa-apa yang dilakukan dengan menyeret, seperti menyusun semula papan kanban, memerlukan alternatif penuding tunggal, contohnya menu atau butang naik dan turun |
| 2.5.8 Target Size (Minimum) | AA | Butang dan pautan sekurang-kurangnya 24 × 24 piksel CSS, atau dijarakkan supaya bulatan 24 piksel di sekeliling setiap satu tidak bertindih dengan yang lain |
| 3.2.6 Consistent Help | A | Pautan bantuan, sembang dan butiran hubungan di tempat relatif yang sama pada setiap halaman |
| 3.3.7 Redundant Entry | A | Maklumat yang sudah dimasukkan dalam proses yang sama diisi secara automatik atau boleh dipilih |
| 3.3.8 Accessible Authentication (Minimum) | AA | Log masuk tanpa menghafal atau menyalin semula, melainkan tampal, pengurus kata laluan atau kaedah lain dibenarkan |

WCAG 2.2 juga membuang 4.1.1 Parsing, yang tidak lagi mempunyai kesan praktikal terhadap kebolehcapaian ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Bagaimana pula dengan tamat masa, susun atur dan zum?

- **Tamat masa sesi (2.2.1, A)**: beri amaran kepada orang sebelum sesi tamat dan benarkan mereka melanjutkannya dengan tindakan mudah, melainkan had masa itu penting atau melebihi 20 jam. Menyimpan kerja yang sedang dijalankan mengelakkan akibat yang paling buruk.
- **Aliran semula (1.4.10, AA)**: kandungan mesti berfungsi pada lebar 320 piksel CSS (bersamaan zum 400% pada skrin 1280 piksel) tanpa perlu menatal dalam dua arah; jadual data dan kandungan seumpamanya dikecualikan.
- **Jarak teks (1.4.12, AA)**: menambah ketinggian baris dan jarak huruf tidak sepatutnya memotong teks, sesuatu yang kerap berlaku pada bekas berketinggian tetap.
- **Orientasi (1.3.4, AA)**: jangan kuncikan aplikasi pada mod potret atau landskap melainkan ia penting.

## Apakah ACR, dan adakah anda memerlukannya?

Accessibility Conformance Report (ACR) mendokumentasikan cara sesuatu produk memenuhi setiap kriteria kebolehcapaian: menyokong, menyokong sebahagian atau tidak menyokong, berserta catatan. Kebanyakannya ditulis menggunakan templat VPAT yang diterbitkan oleh Information Technology Industry Council, yang mempunyai edisi untuk WCAG, piawaian Section 508 AS dan piawaian Eropah EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Agensi persekutuan AS mesti membeli teknologi yang boleh diakses di bawah Section 508 ([Section508.gov](https://www.section508.gov/)), dan badan awam EU merujuk kepada EN 301 549, jadi produk B2B yang menjual kepada pelanggan ini sering diminta ACR semasa perolehan. ACR yang jujur, dengan jurang yang diketahui disenaraikan, lebih berguna kepada pembeli berbanding ACR yang mendakwa sokongan penuh. Ia sepatutnya berdasarkan ujian terhadap produk, termasuk ujian manual; imbasan automatik sahaja tidak dapat mengisinya.

Jika anda menjual kepada pengguna di EU, European Accessibility Act juga mungkin terpakai kepada cara anda menjual dalam talian; [panduan EAA](/ms/blog/european-accessibility-act-online-stores) kami menerangkan skopnya. Ini bukan nasihat undang-undang.

## Bagaimanakah pasukan SaaS sepatutnya menguji kebolehcapaian?

1. **Automasikan perkara asas.** Jalankan axe-core atau enjin yang serupa dalam ujian hujung ke hujung anda dan pada laman pemasaran, dan gagalkan binaan apabila terdapat pelanggaran baharu. [Penyemak kebolehcapaian percuma](/ms/website-accessibility-checker) kami menjalankan enjin yang sama pada mana-mana halaman awam.
2. **Uji dengan papan kekunci.** Selesaikan aliran kerja utama anda, seperti mendaftar, mencipta rekod dan menukar tetapan, menggunakan Tab, Shift+Tab, Enter, Space, Escape dan kekunci anak panah sahaja.
3. **Uji dengan pembaca skrin.** NVDA pada Windows dan VoiceOver pada macOS dan iOS adalah percuma. Semak bahawa nama, peranan, keadaan dan mesej diumumkan.
4. **Zum dan ubah saiz.** Semak zum teks 200% dan tetingkap selebar 320 piksel.
5. **Baiki dalam sistem reka bentuk.** Kebanyakan kegagalan datang daripada komponen yang dikongsi; membaiki butang atau dialog sekali akan membaikinya di mana-mana.

## Soalan lazim

### Adakah WCAG terpakai pada bahagian aplikasi web yang memerlukan log masuk?

WCAG terpakai pada sebarang kandungan web, termasuk halaman di sebalik log masuk. Sama ada undang-undang mewajibkan produk tertentu memenuhinya bergantung pada bidang kuasa dan pelanggan, tetapi pembeli yang bertanya tentang kebolehcapaian biasanya bermaksud keseluruhan produk.

### Bolehkah overlay menjadikan produk SaaS boleh diakses?

Tidak. Overlay tidak mengubah kod asas komponen tersuai, iaitu tempat kegagalan aplikasi berlaku. Panduan kami tentang [overlay kebolehcapaian](/ms/blog/accessibility-overlays-ftc-order) merangkumi tindakan FTC terhadap vendor overlay terkemuka.

### Berapa banyak daripada WCAG yang boleh disemak oleh alat automatik?

Hanya sebahagian. Peraturan automatik boleh diharap untuk menemui nama dan label yang tiada serta kegagalan kontras, tetapi banyak kriteria, seperti susunan fokus yang bermakna, teks alt yang berguna dan mesej ralat yang mudah difahami, memerlukan manusia untuk menilainya.

### Versi WCAG manakah yang patut kami sasarkan?

WCAG 2.2 Tahap AA ialah versi semasa. Banyak undang-undang dan peraturan perolehan masih merujuk kepada WCAG 2.1 AA; memenuhi 2.2 AA juga memenuhi 2.1 AA, kecuali kriteria Parsing yang telah dibuang.

### Adakah kami perlu memenuhi Tahap AAA?

W3C tidak mengesyorkan agar AAA diwajibkan untuk keseluruhan produk, kerana sesetengah kandungan tidak dapat memenuhi setiap kriteria AAA. Tahap AA ialah sasaran yang biasa.

## Sumber

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)