Aksesibilitas bukan keadaan yang sekali dicapai — ia adalah hasil pemeriksaan yang berulang setiap kali komponen baru ditambahkan. Kabar baiknya, sebagian besar pemeriksaan berkaitan dengan CSS dapat dijalankan cepat: satu sesi keyboard, satu sesi zoom, dan panel DevTools yang tepat menutup fondasinya. Alat otomatis membantu menangkap yang terukur, tetapi penilaian “apakah halaman ini nyaman dipakai” tetap membutuhkan mata dan tangan. Chapter ini menyusun alur pemeriksaan yang bisa kita jadwalkan per halaman, lalu meringkasnya menjadi checklist.
Alur Pemeriksaan Manual #
Empat pemeriksaan manual berikut menutupi sebagian besar klaim pada Section ini:
- Keyboard saja. Taruh tetikus di samping. Telusuri seluruh halaman dengan Tab dan Shift+Tab: setiap elemen interaktif harus menampilkan indikator fokus yang kontras (lihat Visible Focus ), urutannya mengikuti alur visual, dan tidak ada jebakan yang membuat fokus tidak bisa keluar dari satu komponen.
- Zoom 200%. Perbesar halaman tiga langkah (
Ctrl++); pastikan tidak ada teks terpotong, kolom yang bertumpuk, dan seluruh fungsi tetap terjangkau — standar dari kriteria Resize Text . - Emulasi preferensi. Buka panel Rendering di DevTools (More tools > Rendering), aktifkan Emulate CSS media feature prefers-reduced-motion dan forced-colors, lalu muat ulang halaman pada tiap keadaan. Halaman yang menghormati preferensi berubah perilakunya — animasi berhenti, palet berganti — tanpa kehilangan isi. Alur DevTools lainnya dibahas pada Chapter Browser DevTools .
- Pemeriksaan kontras dan sasaran. Dengan inspector elemen, periksa rasio kontras pasangan warna yang dipakai teks (ambang 4.5:1) serta ukuran sasaran kontrol penting (24px minimum, 44px praktik baik). Panel Styles DevTools menampilkan rasio langsung di samping swatch warna.
Alat Otomatis dan Batasnya #
Lighthouse yang tersedia di DevTools (tab Lighthouse, kategori Accessibility) menjalankan serangkaian audit terukur dalam satu klik: rasio kontras, ukuran sasaran, label pada kontrol, dan atribut ARIA yang bermakna. Anggap hasilnya sebagai penyaring pertama yang murah — jalankan setiap kali halaman berubah besar, dan tangani temuan berprioritas tinggi lebih dulu.
Batas alat otomatis perlu dipegang: audit tidak bisa memutuskan apakah urutan fokus terasa wajar, apakah animasi yang tersisa masih menimbulkan ketidaknyamanan, atau apakah alternatif statis pada prefers-reduced-motion tetap informatif — ketiganya membutuhkan pemeriksaan manual dari alur di atas. Kombinasi yang sehat: otomatis menyaring yang terukur, manusia menilai yang berguna.
Checklist Per Halaman #
Tabel berikut merangkum alur menjadi checklist yang dapat ditempel di definition of done tim:
| Pemeriksaan | Alat | Ambang / kriteria |
|---|---|---|
| Indikator fokus tampil dan berkontras | keyboard + inspector | non-teks 3:1 |
| Kontras teks utama dan sekunder | DevTools swatch / Lighthouse | 4.5:1 teks normal, 3:1 teks besar |
| Ukuran sasaran kontrol penting | inspector | min 24×24px, praktik 44×44px |
| Zoom 200% tanpa isi hilang | zoom browser manual | kriteria Resize Text |
prefers-reduced-motion dihormati | panel Rendering DevTools | gerak berulang dapat berhenti |
| Mode forced colors tetap terbaca | panel Rendering DevTools | makna tidak bergantung warna |
| Ukuran teks berbasis rem | grep / code review | tidak ada font-size kritis dalam px |
Hasil di Browser:
Halaman demo menampilkan empat sampel yang merepresentasikan checklist:
kartu kontras mencatat color rgb(15, 23, 42) di atas background
rgb(255, 255, 255) — rasio 10.35:1, lulus AA dan AAA; tautan sampel
mencatat cincin statis outline-style "solid", outline-width "2px",
outline-color "rgb(13, 148, 136)" (±3.7:1 terhadap putih); tombol
sampel mencatat min-height "44px"; paragraf sampel mencatat
font-size "16px" hasil hitung 1rem.Demo chapter ini (checklist-audit.html) membawa empat sampel dengan tujuh pemeriksaan data-expected yang merepresentasikan tiap baris checklist — nilai computed di atas diverifikasi langsung oleh harness, sementara empat langkah manual tetap perlu dijalankan dengan tangan.