Cara mengaudit kontras warna tanpa memasang apa pun

Audit kontras warna sering diperlakukan sebagai tugas aksesibilitas khusus: membuka file desain, memasang plugin, mengekspor tangkapan layar, menjalankan laporan, lalu berdebat tentang warna brand. Itu bisa berguna, tetapi bukan titik awal yang tepat bagi kebanyakan tim.

Untuk situs web produksi, audit paling cepat dan andal biasanya dilakukan di browser yang sudah Anda buka. DevTools browser modern dapat memeriksa warna hasil komputasi, menampilkan rasio kontras, mengungkap gaya status, dan membantu Anda menguji kasus-kasus canggung yang sering terlewat oleh laporan otomatis.

Panduan ini mengasumsikan Anda tidak memasang apa pun. Tidak ada ekstensi browser. Tidak ada plugin desain. Tidak ada rangkaian audit berbayar. Hanya halaman, browser, dan metode sederhana.

Aturan kontras yang benar-benar Anda perlukan

Untuk sebagian besar pekerjaan web, kontras WCAG bermuara pada beberapa ambang berikut:

• Teks normal: setidaknya kontras 4.5:1 terhadap latar belakangnya.
• Teks besar: setidaknya 3:1. WCAG mendefinisikannya kira-kira sebagai 24 piksel CSS, atau sekitar 18,66 piksel CSS jika tebal.
• Komponen UI dan objek grafis: setidaknya 3:1 untuk batas, ikon, status, dan bagian bagan yang bermakna dan diperlukan untuk memahami antarmuka.
• Kontras yang ditingkatkan: 7:1 untuk teks normal dan 4.5:1 untuk teks besar jika Anda menargetkan lebih dari baseline.

Ada pengecualian, seperti kontrol tidak aktif, elemen dekoratif, dan logo. Gunakan pengecualian itu seperlunya saja. “Itu bagian dari brand” bukan pengecualian; itu adalah batasan desain.

Ingat juga bahwa kontras hanyalah satu bagian dari penggunaan warna yang aksesibel. Jika status error merah memiliki kontras yang cukup tetapi tidak memiliki teks, label ikon, atau indikasi programatis, status itu tetap dapat gagal bagi pengguna yang tidak dapat membedakan merah dari warna di sekitarnya.

Mulai dari halaman yang dirender, bukan file desain

File desain berguna, tetapi tidak mencakup setiap variabel dunia nyata: override CSS, opacity, status hover, rendering font oleh browser, zoom pengguna, mode gelap, gaya yang diwariskan, konten CMS, dan embed pemasaran.

Audit halaman sebagaimana diterima pengguna.

Buka halaman di browser desktop terbaru. Chrome, Edge, Firefox, dan Safari semuanya memiliki alat inspeksi yang berguna. Label persisnya berbeda, tetapi alur kerjanya sama:

1. Klik kanan teks atau elemen UI.
2. Pilih Inspect.
3. Temukan color dan background-color hasil komputasi.
4. Gunakan color swatch atau panel aksesibilitas browser untuk membaca rasio kontras.
5. Catat lulus, gagal, dan ketidakpastian.

Di browser berbasis Chromium, color picker sering menampilkan rasio kontras dan panduan lulus/gagal WCAG untuk teks. Firefox DevTools juga menyediakan informasi aksesibilitas dan alat warna. Safari Web Inspector dapat menampilkan computed styles dan informasi aksesibilitas, meskipun alur kerjanya sedikit berbeda.

Kuncinya bukan browser tertentu. Kuncinya adalah membaca hasil komputasi, bukan nilai yang diasumsikan digunakan oleh komponen.

Susun daftar audit kecil terlebih dahulu

Jangan memeriksa teks secara acak sampai Anda lelah. Buat inventaris singkat pola-pola berikut:

• Teks isi pada latar belakang halaman utama.
• Teks redup, caption, metadata, dan placeholder.
• Tautan dalam status normal, hover, visited, dan focus.
• Tombol primer, sekunder, dan destruktif.
• Label formulir, teks bantuan, error, dan pesan sukses.
• Item navigasi, breadcrumbs, dan tab.
• Card, badge, pill, dan tag.
• Ikon yang menyampaikan makna.
• Bagan, peta, progress bar, dan warna status.
• Teks di atas gambar, video, gradien, atau overlay transparan.

Ini cukup untuk menemukan sebagian besar kegagalan pada situs tipikal. Ini juga menjaga audit tetap terkait dengan komponen, bukan piksel sekali pakai.

Jika audit Anda mencakup tombol, pasangkan pemeriksaan kontras dengan hal-hal dasar dalam daftar periksa tombol web aksesibel kami. Masalah kontras tombol sering berdekatan dengan status fokus yang hilang, label yang tidak jelas, atau perilaku keyboard yang rusak.

Periksa kontras teks di DevTools

Untuk teks biasa pada latar belakang solid, browser biasanya dapat menghitung kontras untuk Anda.

Inspect elemen tersebut dan cari properti color. Buka color picker dari swatch. Jika browser dapat menentukan latar belakang, ia akan menampilkan rasio kontras. Beberapa alat juga menggambar garis di color picker yang menunjukkan di mana warna akan lulus 3:1, 4.5:1, atau 7:1.

Saat browser melaporkan kegagalan, percayai sampai Anda dapat membuktikan sebaliknya. Saat melaporkan lulus, tetap gunakan penilaian. Huruf kecil dan tipis, layar berkualitas rendah, anti-aliasing berat, dan latar belakang yang ramai dapat membuat teks yang secara teknis lulus tetap terasa lemah.

Aturan praktis: jika teks isi hanya nyaris lulus pada 4.55:1, jangan merayakannya. Beri ruang lebih. Persyaratan kontras adalah minimum, bukan target ideal.

Tipografi juga penting. Sistem huruf yang lebih besar dan lebih jelas mengurangi beban baca bahkan sebelum Anda mengutak-atik warna. Jika halaman terasa sulit dibaca meskipun kontrasnya lulus, tinjau kembali panjang baris, ukuran, bobot, dan spasi dengan lensa keterbacaan yang lebih luas seperti panduan praktis untuk tipografi yang mudah dibaca ini.

Periksa latar belakang sebenarnya, termasuk opacity

Banyak kesalahan kontras terjadi karena latar belakang yang terlihat bukan latar belakang yang dideklarasikan.

Perangkap umum meliputi:

• Teks di dalam card semi-transparan.
• Teks pada parent dengan opacity diterapkan.
• Overlay yang menggunakan rgba() atau color-mix().
• Gradien di belakang heading.
• Gambar latar belakang yang bervariasi di area teks.
• Variabel tema yang berubah dalam mode gelap.

Jika DevTools tidak dapat menghitung kontras dengan yakin, identifikasi warna foreground dan background yang dirender secara manual. Gunakan panel computed styles, nonaktifkan layer sementara, atau sampel warna yang terlihat dengan color picker bawaan jika browser Anda mendukungnya.

Untuk teks di atas gambar, jangan mengambil sampel dari bagian gambar yang paling bagus. Ambil sampel dari area terburuk yang masih masuk akal di belakang teks. Jika gambar berubah melalui unggahan CMS, carousel, atau crop responsif, ini bukan sistem kontras yang stabil. Tambahkan overlay yang andal, text shadow, container solid, atau perlakuan gradien yang melindungi teks terlepas dari gambarnya.

Sistem overlay gambar yang baik itu membosankan: kekuatan overlay yang sama, area crop yang dapat diprediksi, kontras yang cukup bahkan dengan foto terang. Membosankan tidak apa-apa. Pengguna sedang mencoba membaca.

Jangan lupakan status

Tangkapan layar statis melewatkan banyak kegagalan kontras. Audit status interaksi langsung di browser.

Di DevTools, paksa pseudo-class seperti:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Lalu periksa lagi warna hasil komputasi.

Indikator fokus layak mendapat perhatian khusus. WCAG 2.2 memperkuat ekspektasi terkait tampilan fokus, dan outline biru pucat pada card abu-abu muda masih merupakan kegagalan yang umum. Indikator fokus perlu memiliki kontras yang cukup terhadap warna yang berdekatan dan area yang cukup agar terlihat.

Untuk kontrol disabled, aturan kontras WCAG memiliki pengecualian untuk komponen tidak aktif. Itu tidak berarti kontrol disabled seharusnya tidak terbaca secara default. Jika status disabled membawa informasi yang berguna, buat tetap terbaca. Jika tidak, pertimbangkan apakah ia perlu ada sama sekali.

Gunakan Lighthouse, tetapi jangan serahkan penilaian kepadanya

Audit browser seperti Lighthouse dapat menangkap beberapa kegagalan kontras dengan cepat. Jalankan audit bawaan jika browser Anda menyediakannya, lalu perlakukan hasilnya sebagai titik awal.

Pemeriksaan otomatis bagus untuk menemukan node teks dengan kegagalan kontras komputasi yang jelas. Pemeriksaan tersebut lebih lemah pada:

• Teks yang tertanam dalam gambar.
• Label yang dirender dengan canvas.
• Kasus tepi SVG.
• Kegagalan yang hanya muncul saat hover.
• Kualitas indikator fokus.
• Bagan ketika hubungan warna membawa makna.
• Komponen yang tersembunyi di balik autentikasi, menu, atau langkah formulir.

Jika laporan kembali hijau, Anda tetap perlu memeriksa komponen representatif. Jika laporan kembali merah, hindari panik dan lakukan triase kegagalan berdasarkan dampaknya pada pengguna. Prinsip yang sama berlaku untuk laporan performa dan aksesibilitas secara umum: baca keluaran alat sebagai bukti, bukan vonis. Kami menggunakan pola pikir itu dalam panduan kami untuk membaca laporan Lighthouse tanpa panik, dan ini berlaku dengan rapi di sini.

Audit juga kontras non-teks

Teks mendapat sebagian besar perhatian, tetapi WCAG juga mencakup konten non-teks yang diperlukan untuk memahami atau mengoperasikan antarmuka.

Periksa setidaknya kasus-kasus ini:

• Border input terhadap latar belakang halaman.
• Outline checkbox dan radio.
• Status toggle.
• Tombol hanya ikon.
• Ikon error dan simbol peringatan.
• Garis, batang, dan label bagan.
• Indikator progres.
• Indikator tab terpilih atau navigasi aktif.

Targetnya biasanya 3:1 terhadap warna yang berdekatan. Misalnya, border input abu-abu muda pada latar putih mungkin hampir tidak terlihat. Bagan dengan lima garis pastel mungkin tampak elegan tetapi tetap tidak dapat digunakan.

Untuk bagan, kontras saja tidak cukup. Gunakan label, pola, gaya garis, anotasi langsung, atau spasi agar informasi tidak hanya bergantung pada warna. Ini membantu pengguna buta warna, pengguna low vision, orang yang melihat di bawah silau, dan siapa pun yang membaca tangkapan layar dalam dokumen.

Catat temuan dalam format yang bisa digunakan developer

Audit kontras yang berguna tidak mengatakan “beberapa abu-abu gagal.” Audit itu mengidentifikasi komponen, status, nilai saat ini, ambang yang diharapkan, dan saran perbaikan.

Format ringkas bekerja dengan baik:

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | Metadata card | Default | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Gagal | Gunakan --color-text-muted-strong | | Tombol primer | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Lulus | Pertahankan | | Border input | Default | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Gagal | Gelapkan token border |

Kaitkan perbaikan dengan design token jika situs memilikinya. Jangan menambal dua puluh komponen individual jika satu token yang lemah adalah masalah sebenarnya.

Buat perbaikan sedikit lebih kuat dari minimum

Kegagalan kontras sering mudah diperbaiki dengan cara yang buruk. Tim menggeser warna sampai checker mengatakan 4.51:1, lalu lanjut. Itu tidak menyisakan margin untuk rendering font, transparansi, perbedaan browser, tema, variasi gambar, atau edit brand di masa depan.

Lebih baik gunakan target yang nyaman:

• Teks isi: mendekati 7:1 jika praktis.
• Teks redup: tetap di atas 4.5:1 jika itu konten sungguhan.
• Border dan ikon UI: cukup nyaman di atas 3:1.
• Teks di atas gambar: gunakan overlay terkontrol alih-alih menebak per gambar.

Web dilihat di laptop murah, ponsel redup, trotoar terang, monitor berwarna, dan layar yang menua. Kepatuhan minimum tidak sama dengan membaca yang nyaman.

<!-- tool-cta:start -->

💡 Coba ini: Saat memeriksa pasangan kontras yang Anda ambil dari DevTools, Color Converter membantu mengonversi antara hex, RGB, dan HSL agar nilainya selaras dengan catatan audit Anda.

<!-- tool-cta:end -->

Daftar periksa audit kontras tanpa instalasi

Gunakan urutan ini saat Anda membutuhkan audit cepat tetapi kredibel:

1. Buka halaman produksi di browser modern.
2. Daftar pola utama teks, UI, dan status.
3. Periksa warna foreground dan background hasil komputasi di DevTools.
4. Gunakan color picker bawaan atau panel aksesibilitas untuk membaca kontras.
5. Paksa status hover, focus, active, visited, dan invalid.
6. Periksa teks di atas gambar dan gradien terhadap latar belakang terburuk yang masih masuk akal.
7. Periksa bagian UI non-teks terhadap persyaratan 3:1.
8. Jalankan audit otomatis bawaan sebagai jaring pengaman, bukan sebagai seluruh audit.
9. Catat kegagalan berdasarkan komponen dan token.
10. Perbaiki dengan margin, bukan dengan sekadar melewati ambang.

Itu cukup untuk menangkap mayoritas masalah kontras tanpa menambahkan alat lain ke stack Anda. Audit yang lebih maju tetap punya tempat, terutama untuk design system besar, produk teregulasi, atau visualisasi data yang kompleks. Namun untuk banyak situs web, browser sudah memberi Anda bukti yang diperlukan. Bagian tersulit adalah cukup sistematis untuk menggunakannya.