# Checklist WCAG 2.2 AA untuk produk SaaS dan aplikasi web

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

Diperbarui 2026-10-26

Produk SaaS memiliki dua permukaan yang harus aksesibel: situs pemasaran yang menjualnya dan aplikasi yang digunakan orang setiap hari. Situs pemasaran gagal dengan cara yang sama seperti website mana pun, dengan kontras rendah, teks alt yang hilang, dan formulir tanpa label. Aplikasi menambahkan masalahnya sendiri: alur login yang memblokir pengelola kata sandi, dialog yang menjebak fokus keyboard, navigasi single-page app yang tidak disadari pembaca layar, tabel data dan grafik tanpa teks, drag and drop tanpa alternatif, dan sesi yang berakhir tanpa peringatan. Checklist ini membahas WCAG 2.2 Level AA berdasarkan bagian-bagian produk SaaS pada umumnya.

**Poin penting**

- WCAG 2.2 menjadi Rekomendasi W3C pada Oktober 2023 dan menambahkan sembilan kriteria keberhasilan, enam di antaranya pada Level A atau AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) berarti login tidak boleh bergantung pada mengingat atau menyalin ulang kata sandi, kecuali orang dapat menempelkannya atau menggunakan pengelola kata sandi ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Target interaktif harus berukuran minimal 24 × 24 piksel CSS, atau memiliki cukup ruang di sekitarnya (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Pesan seperti “Tersimpan” atau “3 hasil” harus sampai ke pembaca layar tanpa memindahkan fokus (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Pembeli dari kalangan bisnis dan sektor publik sering meminta Accessibility Conformance Report (ACR), yang biasanya ditulis dengan template VPAT dari Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Mengapa aksesibilitas lebih penting bagi SaaS daripada bagi situs brosur?

Orang menggunakan produk SaaS selama berjam-jam, sering kali karena perusahaan tempat mereka bekerja yang memilihnya. Hambatan di halaman pemasaran membuat Anda kehilangan satu pengunjung; hambatan di dalam produk bisa membuat seseorang tidak bisa melakukan pekerjaannya. Itulah sebabnya pelanggan besar, universitas, dan instansi publik semakin sering menanyakan aksesibilitas sebelum membeli, dan mengapa jawabannya harus mencakup aplikasi, bukan hanya website.

Hal ini juga penting karena pengujian otomatis hanya menangkap sebagian masalah. Alat seperti axe-core menemukan kegagalan dalam markup, seperti label yang hilang dan kontras rendah. Alat itu tidak dapat menentukan apakah dialog mengembalikan fokus ke tempat yang benar, apakah data grafik tersedia sebagai teks, atau apakah sebuah alur kerja dapat diselesaikan dengan keyboard. Aplikasi memerlukan pemeriksaan otomatis sekaligus pengujian manual.

## Bagaimana membuat pendaftaran dan login yang aksesibel?

Autentikasi adalah area tempat WCAG 2.2 menambahkan persyaratan baru yang paling penting bagi SaaS.

- **Izinkan fitur tempel dan pengelola kata sandi (3.3.8, AA).** Jangan memblokir fitur tempel di kolom kata sandi atau kode, dan gunakan `autocomplete="username"`, `autocomplete="current-password"`, dan `autocomplete="one-time-code"` agar browser dan pengelola kata sandi dapat mengisinya.
- **Hindari teka-teki sebagai satu-satunya jalan masuk.** CAPTCHA yang meminta orang menyalin teks yang terdistorsi atau memecahkan teka-teki adalah tes fungsi kognitif. Sediakan alternatif, dan utamakan pemeriksaan yang tidak memerlukan tindakan pengguna ([W3C](https://www.w3.org/TR/turingtest/)).
- **Beri label pada setiap kolom (1.3.1 dan 3.3.2, A).** Gunakan `<label>` yang terlihat dan terhubung ke inputnya; teks placeholder hilang saat orang mengetik dan bukan label.
- **Jelaskan error dalam bentuk teks (3.3.1, A) dan sarankan perbaikan (3.3.3, AA).** “Kata sandi harus memiliki minimal 12 karakter” membantu; garis tepi merah saja tidak.
- **Jangan bertanya dua kali (3.3.7, A).** Jika pendaftaran multi-langkah sudah menanyakan nama perusahaan atau alamat, isi otomatis atau biarkan orang memilihnya alih-alih mengetik ulang.
- **Tempatkan bantuan di posisi yang sama (3.2.6, A).** Jika Anda menyediakan chat, link bantuan, atau detail kontak, letakkan di posisi relatif yang sama di setiap halaman dalam alur tersebut.

## Pola formulir dan error mana yang paling banyak menimbulkan kegagalan?

Sebagian besar kegagalan aplikasi ada di formulir. Survei WebAIM 2026 terhadap satu juta halaman beranda menemukan label formulir yang hilang di 51% halaman tersebut ([WebAIM](https://webaim.org/projects/million/)), dan aplikasi memiliki jauh lebih banyak formulir daripada halaman beranda.

- Beri setiap input nama yang terprogram, dan kelompokkan kontrol yang saling terkait, seperti radio button, dengan `<fieldset>` dan `<legend>`.
- Beri tahu orang tentang error di tempat yang akan mereka sadari: pindahkan fokus ke ringkasan error di bagian atas formulir, atau ke kolom pertama yang tidak valid, dan tautkan setiap item ringkasan ke kolomnya.
- Tandai kolom wajib dengan teks, bukan hanya dengan warna (1.4.1, A).
- Jangan mengirim formulir atau mengubah konteks hanya karena seseorang memilih sebuah opsi (3.2.2, A); tunggu tindakan yang eksplisit.

## Bagaimana seharusnya dialog, menu, dan popover berperilaku?

Komponen buatan sendiri adalah tempat dukungan keyboard dan pembaca layar paling sering rusak. WAI-ARIA Authoring Practices Guide menjelaskan perilaku yang diharapkan untuk setiap pola ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialog**: pindahkan fokus ke dalam dialog saat dibuka, jaga Tab tetap di dalamnya selama dialog terbuka, tutup dengan Escape, dan kembalikan fokus ke kontrol yang membukanya. Gunakan elemen `<dialog>` bawaan atau `role="dialog"` dengan `aria-modal="true"` dan sebuah nama.
- **Tanpa jebakan keyboard (2.1.2, A)**: setiap komponen harus bisa ditinggalkan dengan keyboard.
- **Fokus yang terlihat (2.4.7, AA)** yang tidak tersembunyi di balik header sticky, banner cookie, atau widget chat (2.4.11, AA, baru di 2.2).
- **Tooltip dan popover (1.4.13, AA)** yang dapat ditutup dengan Escape, dapat diarahkan kursor tanpa menghilang, dan tetap tampil sampai ditutup.
- **Pintasan satu tombol (2.1.4, A)**: jika menekan tombol huruf memicu sebuah tindakan, izinkan orang menonaktifkan atau memetakan ulang pintasan, atau buat pintasan hanya aktif saat komponen terkait sedang difokus.

## Bagaimana menangani navigasi dalam single-page app?

Dalam single-page app, URL berubah tanpa memuat halaman baru, sehingga pembaca layar mungkin tidak mengumumkan bahwa sesuatu telah terjadi.

- Perbarui judul dokumen setiap kali rute berubah, agar setiap tampilan memiliki judul yang deskriptif (2.4.2, A).
- Pindahkan fokus ke judul utama tampilan baru, atau umumkan perubahan di live region yang sopan (polite); framework seperti Next.js menyertakan route announcer untuk keperluan ini.
- Jaga urutan fokus yang logis (2.4.3, A): setelah sebuah item dihapus, fokus harus berpindah ke item terdekat yang masuk akal, bukan kembali ke bagian atas halaman.
- Sediakan cara untuk melewati navigasi yang berulang (2.4.1, A), seperti skip link atau landmark.

## Bagaimana membuat dasbor, tabel data, dan grafik yang aksesibel?

- **Tabel**: gunakan markup `<table>` yang sebenarnya dengan `<th>` dan `scope` untuk header, serta caption (1.3.1, A). Grid yang dibangun dari elemen `<div>` memerlukan pola grid ARIA lengkap, yang jauh lebih sulit diterapkan dengan benar.
- **Grafik**: beri setiap grafik alternatif teks yang menyatakan poin utamanya, dan sediakan datanya dalam bentuk tabel (1.1.1, A). Jangan hanya mengandalkan warna untuk membedakan seri data (1.4.1, A); tambahkan label atau pola.
- **Kontras**: teks memerlukan 4.5:1 (1.4.3, AA), dan garis grafik, ikon, serta garis tepi input memerlukan 3:1 terhadap latar belakangnya (1.4.11, AA). Cek mode gelap secara terpisah. [Cek kontras warna](/id/color-contrast-checker) kami menguji pasangan warna apa pun.
- **Pesan status (4.1.3, AA)**: “Tersimpan”, “Unggahan selesai”, dan jumlah hasil sebaiknya menggunakan `role="status"` atau live region, agar pengguna pembaca layar mendengarnya tanpa kehilangan posisinya.

## Apa yang diubah kriteria baru WCAG 2.2 untuk aplikasi web?

| Kriteria | Level | Artinya dalam aplikasi |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Toolbar sticky, banner, dan widget chat tidak boleh menutupi sepenuhnya elemen yang sedang difokus |
| 2.5.7 Dragging Movements | AA | Apa pun yang dilakukan dengan menyeret, seperti mengurutkan ulang papan kanban, memerlukan alternatif dengan satu pointer, misalnya menu atau tombol naik dan turun |
| 2.5.8 Target Size (Minimum) | AA | Tombol dan link berukuran minimal 24 × 24 piksel CSS, atau diberi jarak sehingga lingkaran 24 piksel di sekitar masing-masing tidak tumpang tindih dengan yang lain |
| 3.2.6 Consistent Help | A | Link bantuan, chat, dan detail kontak berada di posisi relatif yang sama di setiap halaman |
| 3.3.7 Redundant Entry | A | Informasi yang sudah dimasukkan dalam proses yang sama diisi otomatis atau dapat dipilih |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login tanpa menghafal atau menyalin ulang, kecuali fitur tempel, pengelola kata sandi, atau metode lain diizinkan |

WCAG 2.2 juga menghapus 4.1.1 Parsing, yang tidak lagi berdampak praktis pada aksesibilitas ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## Bagaimana dengan batas waktu, tata letak, dan zoom?

- **Batas waktu sesi (2.2.1, A)**: beri peringatan sebelum sesi berakhir dan izinkan orang memperpanjangnya dengan tindakan sederhana, kecuali batas waktu itu esensial atau lebih dari 20 jam. Menyimpan pekerjaan yang sedang berlangsung mencegah hasil terburuk.
- **Reflow (1.4.10, AA)**: konten harus berfungsi pada lebar 320 piksel CSS (setara dengan zoom 400% di layar 1280 piksel) tanpa perlu menggulir ke dua arah; tabel data dan konten serupa dikecualikan.
- **Spasi teks (1.4.12, AA)**: menambah tinggi baris dan jarak huruf tidak boleh membuat teks terpotong, yang sering terjadi pada container dengan tinggi tetap.
- **Orientasi (1.3.4, AA)**: jangan mengunci aplikasi ke mode potret atau lanskap kecuali hal itu esensial.

## Apa itu ACR, dan apakah Anda membutuhkannya?

Accessibility Conformance Report (ACR) mendokumentasikan bagaimana sebuah produk memenuhi setiap kriteria aksesibilitas: mendukung, mendukung sebagian, atau tidak mendukung, disertai keterangan. Sebagian besar ditulis dengan template VPAT yang diterbitkan Information Technology Industry Council, yang tersedia dalam edisi untuk WCAG, standar Section 508 Amerika Serikat, dan standar Eropa EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

Lembaga federal Amerika Serikat wajib membeli teknologi yang aksesibel berdasarkan Section 508 ([Section508.gov](https://www.section508.gov/)), dan badan publik di Uni Eropa mengacu pada EN 301 549, sehingga produk B2B yang dijual kepada pelanggan tersebut sering diminta menyertakan ACR dalam proses pengadaan. ACR yang jujur, dengan kekurangan yang diketahui dicantumkan, lebih berguna bagi pembeli daripada ACR yang mengklaim dukungan penuh. ACR harus didasarkan pada pengujian produk, termasuk pengujian manual; pemindaian otomatis saja tidak dapat mengisinya.

Jika Anda menjual kepada konsumen di Uni Eropa, European Accessibility Act mungkin juga berlaku untuk cara Anda berjualan online; [panduan EAA](/id/blog/european-accessibility-act-online-stores) kami menjelaskan cakupannya. Ini bukan nasihat hukum.

## Bagaimana tim SaaS sebaiknya menguji aksesibilitas?

1. **Otomatiskan hal-hal dasar.** Jalankan axe-core atau mesin serupa dalam pengujian end-to-end dan di situs pemasaran, lalu gagalkan build jika ada pelanggaran baru. [Cek aksesibilitas gratis](/id/website-accessibility-checker) kami menjalankan mesin yang sama di halaman publik mana pun.
2. **Uji dengan keyboard.** Selesaikan alur kerja utama Anda, seperti pendaftaran, membuat data baru, dan mengubah pengaturan, hanya dengan Tab, Shift+Tab, Enter, Spasi, Escape, dan tombol panah.
3. **Uji dengan pembaca layar.** NVDA di Windows dan VoiceOver di macOS dan iOS tersedia gratis. Pastikan nama, peran, status, dan pesan diumumkan.
4. **Zoom dan ubah ukuran.** Cek zoom teks 200% dan jendela selebar 320 piksel.
5. **Perbaiki di design system.** Sebagian besar kegagalan berasal dari komponen bersama; memperbaiki tombol atau dialog sekali akan memperbaikinya di mana-mana.

## Pertanyaan yang sering diajukan

### Apakah WCAG berlaku untuk bagian aplikasi web yang memerlukan login?

WCAG berlaku untuk semua konten web, termasuk halaman di balik login. Apakah ada undang-undang yang mewajibkan produk tertentu untuk memenuhinya bergantung pada yurisdiksi dan pelanggannya, tetapi pembeli yang menanyakan aksesibilitas biasanya memaksudkan seluruh produk.

### Bisakah overlay membuat produk SaaS menjadi aksesibel?

Tidak. Overlay tidak mengubah kode dasar komponen buatan sendiri, padahal di situlah kegagalan aplikasi berada. Panduan kami tentang [overlay aksesibilitas](/id/blog/accessibility-overlays-ftc-order) membahas tindakan FTC terhadap salah satu vendor overlay terkemuka.

### Seberapa banyak WCAG yang dapat diperiksa alat otomatis?

Hanya sebagian. Aturan otomatis dapat diandalkan untuk menemukan nama yang hilang, label yang hilang, dan kegagalan kontras, tetapi banyak kriteria, seperti urutan fokus yang bermakna, teks alt yang berguna, dan pesan error yang mudah dipahami, memerlukan penilaian manusia.

### Versi WCAG mana yang sebaiknya kami targetkan?

WCAG 2.2 Level AA adalah versi saat ini. Banyak undang-undang dan aturan pengadaan masih mengacu pada WCAG 2.1 AA; memenuhi 2.2 AA juga berarti memenuhi 2.1 AA, kecuali untuk kriteria Parsing yang telah dihapus.

### Apakah kami perlu memenuhi Level AAA?

W3C tidak menyarankan mewajibkan AAA untuk seluruh produk, karena sebagian konten tidak dapat memenuhi setiap kriteria AAA. Level AA adalah target yang umum.

## 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/)