Rasio Kontras Warna WCAG: AA, AAA & APCA — Panduan Lengkap 2026

Anda merilis sebuah tombol. Oranye merek, teks putih, terlihat tajam di monitor 4K Anda. Lalu hasil audit aksesibilitas kembali merah: rasio kontras WCAG-nya 1.97:1, jauh dari ambang 4.5:1 AA untuk teks isi. Tombol yang menurut Anda baik-baik saja itu tidak terbaca oleh sekitar 220 juta orang dengan penglihatan rendah di seluruh dunia. Panduan ini membahas setiap angka yang Anda butuhkan untuk memperbaikinya: rasio WCAG 2, tingkat AAA, algoritma APCA Lc terbaru, delapan kategori defisiensi penglihatan warna (color vision deficiency), dan implementasi JavaScript siap pakai yang bisa Anda tempelkan ke build.

Referensi cepat: ambang WCAG dan APCA sekilas

Standar	Teks normal	Teks besar	UI / ikon	Catatan
WCAG AA	≥ 4.5:1	≥ 3:1	≥ 3:1	Garis dasar hukum
WCAG AAA	≥ 7:1	≥ 4.5:1	≥ 3:1	Target lebih ketat
APCA body	Lc 75+	Lc 60+	Lc 45+ (ikon)	Draf, perseptual

“Teks besar” berarti ≥ 18pt regular atau ≥ 14pt bold (≈ 24px dan ≈ 18.66px di CSS). “UI” mencakup batas formulir, focus ring, dan objek grafis apa pun yang harus dapat dipersepsi pengguna agar bisa mengoperasikan halaman. Logo dan grafis murni dekoratif dikecualikan dari persyaratan kontras.

Apa itu kontras warna WCAG?

Rasio kontras WCAG adalah ukuran numerik dari 1:1 (tanpa kontras) hingga 21:1 (maksimum) yang membandingkan luminansi relatif (relative luminance) teks terhadap latar belakangnya. Web Content Accessibility Guidelines mewajibkan ≥ 4.5:1 (AA) untuk teks isi atau ≥ 7:1 (AAA) untuk kepatuhan yang lebih tinggi.

Satu rasio inilah yang menggerakkan sebagian besar audit aksesibilitas di seluruh dunia. W3C menerbitkannya di WCAG 2.0 pada 2008, menyempurnakannya di 2.1 (2018) dan 2.2 (2023), dan setiap regulator besar kini merujuk padanya. ADA di Amerika Serikat, European Accessibility Act (yang mulai berlaku Juni 2025), Section 508 untuk lembaga federal AS, dan AODA Kanada semuanya menggunakan WCAG 2.x AA sebagai standar minimum de facto.

Mengapa hal ini penting di luar sisi hukum? Sekitar 220 juta orang di seluruh dunia memiliki penglihatan rendah tetapi tidak buta; mereka membaca layar, namun hanya jika kontras teks/latar belakang cukup tinggi. Sekitar 8% pria dan 0.5% wanita memiliki defisiensi penglihatan warna. Pembaca yang lebih tua mengalami penguningan lensa mata dan penurunan diafragma pupil, yang secara fungsional menurunkan persepsi kontras sebesar 20–30% setelah usia 60 tahun. Penggunaan ponsel di luar ruangan kehilangan tambahan 20–40% akibat silau. Halaman yang mencetak 4.5:1 di meja kerja Anda adalah batas minimum di mana semua pengguna tersebut masih bisa membacanya.

Orang yang paling perlu memperhatikan ini adalah front-end engineer yang merilis UI produksi, desainer yang memilih palet merek, spesialis aksesibilitas yang menjalankan audit, dan tim kepatuhan yang bertanggung jawab atas risiko hukum. Matematikanya pendek, tetapi keputusan yang dipaksakannya tidak.

Rasio kontras WCAG 2.x: matematika dan ambangnya

W3C mendefinisikan kontras dalam tiga langkah singkat. Untuk menghitung rasio kontras WCAG: (1) konversi setiap warna dari sRGB yang dikode-gamma ke nilai linear-light, (2) hitung luminansi relatif menggunakan koefisien tetap berdasarkan sensitivitas mata manusia terhadap merah, hijau, dan biru, dan (3) bagi kedua luminansi tersebut dengan offset konstan kecil untuk menangani nilai mendekati hitam.

Rumus luminansi relatif dari WCAG 2.1 §1.4.3 adalah:

L = 0.2126 × R_lin + 0.7152 × G_lin + 0.0722 × B_lin

R_lin, G_lin, B_lin adalah nilai kanal linear-light setelah membatalkan kurva gamma sRGB. Bobot 0.7152 pada hijau mencerminkan sensitivitas mata manusia yang kuat terhadap hijau; hijau kira-kira 7× lebih “nyaring secara visual” daripada biru per unit energi cahaya.

Rumus rasionya adalah:

ratio = (L_lighter + 0.05) / (L_darker + 0.05)

Tambahan +0.05 mencegah pembagian dengan nol untuk hitam murni (L = 0) dan memberikan maksimum (1 + 0.05) / (0 + 0.05) = 21:1 untuk putih murni di atas hitam murni. Minimumnya adalah 1:1 (warna yang identik).

Berikut implementasi lengkapnya dalam sekitar tiga puluh baris vanilla JavaScript. Tanpa dependensi, berjalan di mana pun:

// sRGB hex → kanal linear-light
function srgbToLinear(channel8bit) {
  const v = channel8bit / 255;
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

// "#RRGGBB" → luminansi relatif [0, 1]
function relativeLuminance(hex) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return (
    0.2126 * srgbToLinear(r) +
    0.7152 * srgbToLinear(g) +
    0.0722 * srgbToLinear(b)
  );
}

// Rasio kontras WCAG 2.x antara dua warna hex
function contrastRatio(hexA, hexB) {
  const lA = relativeLuminance(hexA);
  const lB = relativeLuminance(hexB);
  const [lighter, darker] = lA > lB ? [lA, lB] : [lB, lA];
  return (lighter + 0.05) / (darker + 0.05);
}

// Contoh: teks isi slate gelap di atas putih
console.log(contrastRatio("#475569", "#ffffff").toFixed(2));
// → "7.58", nyaman di atas AA 4.5:1 dan baru saja melewati AAA 7:1

Tempelkan dua kode hex ke Konverter Warna dan angka yang sama akan keluar, ditampilkan bersama nilai APCA Lc, klasifikasi gamut, dan pratinjau CVD delapan kanal. Ambangnya sendiri konkret:

Elemen	AA min	AAA min	Catatan
Teks isi normal	4.5:1	7:1	Di bawah 18pt regular / 14pt bold
Teks besar	3:1	4.5:1	≥ 18pt regular ATAU ≥ 14pt bold
Komponen UI / ikon	3:1	—	WCAG 2.1 §1.4.11 ditambahkan 2018
Logo & dekoratif	bebas	bebas	Tanpa persyaratan kontras

Konversi unit CSS sering bikin orang tergelincir. 18pt = 24px di default browser, 14pt = 18.66px. Font isi 16px (default modern) berada di bawah ambang “teks besar”, sehingga jatuh di bawah aturan AA 4.5:1 yang lebih ketat. Heading 20px dengan font-weight: 700 memenuhi syarat sebagai teks besar dan mendapatkan 3:1 yang lebih longgar.

Satu kehalusan yang sering menjebak tim: pengecualian “teks besar” WCAG adalah tentang keterbacaan pengguna pada skala, bukan tentang semantik heading. Sebuah <h2> 14px bukanlah teks besar; masih perlu 4.5:1. Paragraf 24px dari salinan pemasaran adalah teks besar dan mendapat batas 3:1. Aturannya berdasarkan ukuran piksel ter-render dan bobot, tidak pernah pada nama tag. Auditor akan menandai ketidaksesuaian; CSS Anda adalah sumber kebenaran, bukan semantik HTML.

Konstanta +0.05 di rumus rasio berasal dari suku flare, cahaya ambien yang terpantul dari permukaan layar yang menaikkan luminansi tampak hitam murni hingga batas minimum. Tanpanya, piksel OLED yang merender hitam sejati melawan putih murni akan menghasilkan pembagian dengan nol. Dengannya, rasio maksimum yang bisa dicapai adalah 21:1, angka yang Anda akan lihat dikutip di setiap alat aksesibilitas. Tidak ada layar fisik yang dapat memberikan lebih dari 21:1 setelah flare diperhitungkan, itulah sebabnya skala WCAG berakhir di sana.

AA vs AAA: mana yang harus Anda targetkan?

AA adalah batas hukum; AAA adalah tingkat aspirasional. Sebagian besar situs komersial menargetkan AA karena AAA memaksa warna merek bergeser ke arah skala abu-abu agar lulus, sesuatu yang biasanya ditolak tim pemasaran. Keputusannya bukan “semakin tinggi semakin baik”, melainkan trade-off antara jangkauan pengguna dan ekspresi merek.

Konteks	Tingkat disarankan	Alasan
Situs komersial umum	AA	Garis dasar kepatuhan ADA / EAA; pengadilan rujuk WCAG 2 AA
Pemerintah / layanan publik	AAA	Section 508 dan undang-undang Eropa setara sarankan AAA
Kesehatan / pendidikan	AAA	Basis pengguna condong ke kebutuhan aksesibilitas tinggi
Dasbor internal	AA	Audiens diketahui, ROI trade-off bisa diterima
Halaman pemasaran (landing page)	AA + pengecualian merek	Warna merek boleh di hero/CTA, isi tetap AA

Biaya tersembunyi AAA muncul pertama kali ketika Anda mencoba membuat oranye merek yang jenuh lulus 7:1 di atas putih. Tidak bisa. Anda harus menggelapkan oranye sampai ia berhenti menjadi merek Anda, atau menerima AA dan menggunakan oranye di latar belakang gelap di mana ia bisa mencapai AAA dengan mudah. Banyak perusahaan (termasuk beberapa yang lebih peduli aksesibilitas) secara eksplisit menargetkan AA pada konten isi dan hanya mendorong AAA pada teks kritis seperti pesan error atau pengungkapan legal.

Regulator tidak menunggu AAA tersebar. Regulasi aksesibilitas web ADA 2024 mengutip WCAG 2.1 AA. European Accessibility Act, dapat ditegakkan sejak Juni 2025, mewajibkan WCAG 2.1 AA di seluruh layanan digital yang tercakup. Section 508 di pemerintah federal AS menggunakan WCAG 2.0 AA sebagai garis dasarnya (dengan AAA direkomendasikan bila memungkinkan). AODA Kanada, undang-undang aksesibilitas Ontario, menunjuk ke WCAG 2.0 AA. Polanya konsisten: AA adalah batasnya, AAA adalah tujuannya.

APCA: algoritma perseptual baru

APCA (Advanced Perceptual Contrast Algorithm, dirancang oleh Andrew Somers di bawah bendera Myndex) adalah algoritma kandidat untuk WCAG 3. Ia menggantikan rasio simetris WCAG 2 dengan skor Lc bertanda polaritas dari -108 hingga +108, di mana tanda menunjukkan arah kontras (teks gelap di latar terang vs teks terang di latar gelap) dan besarannya mencerminkan kontras yang dipersepsi pada layar emisif sesungguhnya.

APCA penting karena rumus simetris WCAG 2 mengabaikan dua efek dunia nyata:

Asimetri polaritas. Teks terang di latar gelap terbaca berbeda dari teks gelap di latar terang, bahkan pada rasio WCAG yang sama. WCAG 2 mengembalikan angka yang sama untuk kedua arah; APCA tidak.
Pemodelan layar. Rumus WCAG 2 diturunkan dari model luminansi kertas cetak. APCA disetel terhadap layar sRGB dalam pencahayaan kantor tipikal, yang lebih dekat dengan apa yang sebenarnya dilihat pengguna Anda.

Trade-off-nya: APCA lebih kompleks (melibatkan eksponen sadar-polaritas dan penyesuaian bobot font) dan belum menjadi standar regulasi. Analisis Adrian Roselli April 2026 masih menjadi ringkasan paling jelas tentang posisi APCA: secara teknis menjanjikan, tetapi WCAG 3 sendiri masih dalam pengembangan draf awal jalur Silver, dan APCA belum diratifikasi sebagai algoritma resmi.

Ambang APCA tingkat Bronze (batas praktis yang ditargetkan kebanyakan tim) tampak seperti ini:

Use case	Lc disarankan	Lc minimum
Teks isi (16px, bobot 400)	90+	75
Teks besar (24px, bobot 400)	75+	60
Elemen UI & ikon non-teks	60+	45
Spot text / placeholder	30+	30

Alasan APCA menarik (dan alasan Konverter Warna menampilkan kedua metrik berdampingan) adalah kasus-kasus di mana ia tidak sepakat dengan WCAG 2:

#FFA500 (oranye) di atas #FFFFFF: WCAG 2 mengembalikan 1.97:1, gagal jelas di AA. APCA setuju, memberi skor sekitar Lc 38, juga gagal. Sejauh ini kedua algoritma mengatakan tidak, tetapi sebagian besar desainer yang saya amati tetap merilis kombinasi ini karena “kelihatannya oke.”
#767676 (abu-abu medium) di atas #FFFFFF: WCAG 2 mengembalikan 4.54:1, sedikit di atas AA 4.5:1, secara teknis lulus. APCA memberi skor sekitar Lc 60 untuk pasangan ini, yang di bawah ambang APCA Bronze 75 untuk teks isi. WCAG lulus; APCA gagal. Pengalaman pengguna lebih dekat ke putusan APCA: abu-abu di putih lebih sulit dibaca pada ukuran isi daripada yang disiratkan rasionya.
#3b82f6 (Tailwind blue-500) di atas #000000: WCAG 2 mengembalikan 5.71:1, lulus AA dengan nyaman. APCA memberi skor sekitar Lc 65, di bawah minimum teks isi Lc 75. Teks biru terang di latar gelap, pola dark-mode kesayangan, adalah kasus kanonik “WCAG lulus, APCA menandai.”

Anda tidak perlu memilih satu sisi. Sikap pragmatis yang dianut sebagian besar tim produksi: jaga WCAG 2 AA sebagai garis dasar regulasi karena itulah yang diperiksa audit kepatuhan, dan jalankan APCA secara paralel sebagai pemeriksaan naluri “apakah ini benar-benar terbaca?”, terutama untuk desain dark-mode dan warna merek jenuh. Konverter Warna menampilkan kedua angka dalam satu baris sehingga Anda tidak perlu beralih konteks antar pemeriksa.

Buta warna dan di luar kontras

Rasio kontras hanyalah separuh dari aksesibilitas warna. Sekitar 8% pria dan 0.5% wanita melihat warna berbeda dari trikromatic baku, dan varian paling umum, deuteranomaly, berada di tengah pasangan merah/hijau yang kita gunakan di mana-mana untuk status sukses/error. WCAG 1.4.1 (“Use of Color”) secara eksplisit melarang warna sebagai satu-satunya pembawa informasi; ini adalah aturan untuk menegakkan hal tersebut.

Taksonomi lengkap perbedaan penglihatan warna terbagi menjadi tiga kelompok: dichromacy (satu cone hilang), anomalous trichromacy (satu cone bergeser), dan monochromacy yang langka.

Jenis	Nama umum	Kanal terdampak	Prevalensi (P / W)
Protanopia	Buta merah	Cone L tidak ada	1.0% / 0.01%
Deuteranopia	Buta hijau	Cone M tidak ada	1.1% / 0.01%
Tritanopia	Buta biru	Cone S tidak ada	0.003% / 0.003%
Protanomaly	Lemah merah	Cone L bergeser	1.3% / 0.02%
Deuteranomaly	Lemah hijau	Cone M bergeser	5.0% / 0.4%
Tritanomaly	Lemah biru	Cone S bergeser	0.01% / 0.01%
Achromatopsia	Tanpa warna	Semua cone tidak ada	0.003% (sangat langka)
Cone monochromacy	Sebagian abu-abu	Hanya satu cone	0.001%

Deuteranomaly sendiri 5% pria, satu dari dua puluh. Itulah populasi yang melihat indikator error merah dan indikator sukses hijau sebagai warna olive-coklat yang hampir sama. Perbaikannya bukan mendesain ulang sistem warna Anda; melainkan menambahkan saluran kedua. Ikon error merah yang dipasangkan dengan bentuk ”×” dan kata “Error” bertahan di setiap varian dalam tabel. Sekadar titik merah tidak.

Mensimulasikan CVD di kode menggunakan dua set matriks standar: Brettel–Viénot–Mollon (1997) untuk dichromacy dan Machado–Oliveira–Fernandes (2009) untuk anomalous trichromacy. Pendekatan Brettel memproyeksikan warna input pengguna ke bidang yang dibentangi dua respons cone yang tersisa; Machado memparameterkan pergeseran cone berdasarkan severitas. Keduanya dapat diimplementasikan sebagai filter SVG atau matriks CSS. Konverter Warna menyediakan kedelapan varian sebagai pratinjau satu klik, sehingga Anda dapat memindai warna merek di seluruh spektrum tanpa meninggalkan halaman.

Filter SVG singkat (tempelkan ke halaman Anda dan referensikan berdasarkan ID) memberi Anda simulasi protanopia dalam browser untuk pengujian ad hoc:

<svg style="display: none">
  <filter id="protanopia">
    <feColorMatrix type="matrix" values="
      0.567 0.433 0.000 0 0
      0.558 0.442 0.000 0 0
      0.000 0.242 0.758 0 0
      0.000 0.000 0.000 1 0"/>
  </filter>
</svg>

<style>
  .preview-protanopia { filter: url(#protanopia); }
</style>

Terapkan .preview-protanopia ke wrapper halaman Anda untuk melihat apa yang dilihat penderita protanopia. Ulangi dengan matriks deuteranopia dan tritanopia (koefisiennya didokumentasikan dalam makalah Brettel dan dipaket di sebagian besar library simulator CVD). Panel Rendering Chrome DevTools memiliki simulator yang sama di bawah “Emulate vision deficiencies”: berguna untuk pemeriksaan cepat, kurang berguna untuk menangkap screenshot di CI.

Aturan yang lebih dalam, di luar simulasi: jangan pernah biarkan warna menjadi satu-satunya perbedaan antara dua status. Ikon harus berbeda bentuk (× vs ✓), status dalam label teks (“Error” vs “Success”), kategori dalam pola (solid vs berarsir). Warna adalah pengganda atas sinyal lain itu, bukan substitusi.

Ada kelas kegagalan yang tidak terdeteksi pemeriksa kontras tetapi terdeteksi simulator CVD. Segmen pie chart yang dibedakan hanya oleh hue, legenda peta yang mengkode-warna negara, status pill yang bergantung pada gradien hijau/kuning/merah: semuanya dapat lulus kontras WCAG 2 terhadap latar belakang sambil tidak terbaca oleh penderita deuteranopia yang membacanya satu sama lain. Aturannya adalah memeriksa keterbacaan antara warna-warna bersebelahan dalam desain, bukan hanya terhadap kanvas di sekitarnya. Dua segmen slate-500 bersebelahan pada tingkat terang yang sama tidak dapat dibedakan terlepas dari rotasi hue. Tambahkan langkah luminansi antara wilayah bersebelahan dan grafik bertahan di setiap varian CVD.

Achromatopsia dan cone monochromacy memang langka tetapi layak dirancang secara eksplisit karena keduanya meruntuhkan semua distinksi hue. Pengguna dengan achromatopsia hanya mempersepsi luminansi; UI berkode-warna Anda terlihat seperti foto skala abu-abu baginya. Jika desain Anda bertahan saat Anda menerapkan filter: grayscale(1) ke seluruh halaman (coba di DevTools), Anda lulus versi paling ketat dari aturan “warna bukan satu-satunya sinyal.” Itu adalah uji aksesibilitas termurah yang dapat Anda jalankan, dan ia memunculkan banyak kegagalan begitu Anda menyalakannya.

Mengaudit palet Tailwind dan Material

Sebagian besar pekerjaan front-end menggunakan palet siap pakai: Tailwind v4, Material 3, Radix, atau shadcn. Pertanyaan aksesibilitasnya menjadi “pada stop mana di tangga ini teks menjadi terbaca?”, dan jawabannya lebih bersifat rule-of-thumb daripada yang diakui dokumentasi.

Untuk tangga slate Tailwind v4 di atas putih murni, angka WCAG dan APCA jatuh seperti ini:

Kelas Tailwind	Approx hex	WCAG vs putih	AA body	AAA body	APCA Lc (approx)
slate-400	`#94a3b8`	2.56:1	✗	✗	~38 ✗
slate-500	`#64748b`	4.76:1	✓	✗	~60 ✗ body
slate-600	`#475569`	7.58:1	✓	✓	~78 ✓ body
slate-700	`#334155`	10.35:1	✓	✓	~90 ✓ body

Aturan praktis yang muncul:

Teks isi perlu slate-600 atau lebih gelap. Slate-500 lulus WCAG AA tetapi gagal di ambang teks isi APCA, jadi patuh tetapi tidak nyaman. Slate-600 adalah batas aman.
Label UI dan teks sekunder dapat menggunakan slate-500. Komponen UI hanya perlu 3:1; 4.76:1 dari slate-500 nyaman, dan teksnya biasanya membawa konteks visual pendukung.
Placeholder harus menggunakan slate-400 atau lebih pudar. Teks placeholder dikecualikan WCAG 1.4.3 sebagai dekoratif hanya jika Anda mempertahankan label visible di atas field. Pola label-sebagai-placeholder inline harus memenuhi ambang teks isi.
Hitam murni di slate-100 / slate-200 adalah pemborosan tinta. Anda berada di 17:1+; pertimbangkan slate-700 atau slate-800 sebagai warna teks untuk nuansa yang lebih lembut tanpa kehilangan keterbacaan.

Material 3 menggunakan struktur palet tonal yang serupa. surface-container-high-nya berada di sekitar tone 92 (sangat terang); on-surface-nya berada di sekitar tone 10 (mendekati hitam). Kontras antara on-surface apa pun dan token surface-* apa pun di keluarga yang sama dijamin oleh spesifikasi Material untuk lulus AA. Jangan pasangkan on-surface-variant (tone 30) dengan surface-container (tone 94) tanpa pengecekan; itu kegagalan dunia nyata yang pernah saya lihat lolos.

Jika Anda memiliki palet eksisting yang gagal kontras, OKLCH memberi Anda jalur perbaikan paling bersih. Alih-alih menggoyang kode hex secara membabi buta, konversi warna Anda ke OKLCH, tahan C (chroma) dan H (hue) tetap, dan kurangi L (lightness) sampai kontras lulus. Karena kanal L OKLCH benar-benar perseptual, pengenalan merek tetap utuh sementara kontras menguat. Alat HEX ke OKLCH melakukan konversi ini dalam satu langkah; tulisan saudara OKLCH dijelaskan membahas matematikanya secara mendalam.

Dark mode pantas mendapatkan paragraf tersendiri. Rasio simetris WCAG 2 menurut definisi melewatkan kombinasi yang sama di mode terang dan gelap. APCA, yang sadar-polaritas, sering menandai teks isi dark-mode sebagai lebih sulit dibaca daripada pasangan hex yang sama dalam mode terang. Teks terang di latar gelap selalu kehilangan sebagian kontras yang dipersepsi relatif terhadap teks gelap di latar terang pada rasio numerik yang sama; ini efek yang diketahui dari cara mata beradaptasi. Jalankan ulang APCA pada setiap pasangan dark-mode sebelum dirilis.

Pemeriksa kontras dan alur kerja CI

Desainer dan engineer masing-masing punya pemeriksa favorit; pertanyaan praktisnya adalah kombinasi alat mana yang Anda rajut menjadi alur kerja nyata. Berikut lapangannya per 2026:

Alat	WCAG 2	APCA	Simulasi CVD	Audit palet
WebAIM Contrast Checker	✓	✗	✗	✗
Adobe Color	✓	✗	✓	✓
Stark (plugin Figma)	✓	✓	✓	✓
Polypane (browser)	✓	✓	✓	✓
Chrome DevTools color picker	✓	✓ (exp.)	✗	✗
axe DevTools	✓	✗	✗	✓ (level halaman)
Go Tools Color Converter	✓	✓	✓ (8 jenis)	✓ (Tints/Shades)

Alur kerja yang bertahan di bawah tekanan produk nyata terlihat seperti ini:

Di Figma, desainer menjalankan Stark pada setiap frame untuk memunculkan pasangan yang gagal sejak dini. Stark menangkap pelanggar yang jelas sebelum kode hex apa pun mencapai codebase.
Saat handoff kode hex, engineer menempelkan nilai ke Konverter Warna untuk mendapatkan rasio WCAG + APCA Lc + klasifikasi gamut + pratinjau CVD dalam satu baris. Jika pasangannya dark-mode atau warna merek jenuh, metrik ganda menangkap kasus WCAG-lulus-APCA-gagal yang mungkin terlewatkan Stark.
Di waktu PR, axe-core/playwright memindai halaman yang sudah dibangun untuk pelanggaran kontras apa pun pada DOM yang ter-render, termasuk status dinamis. Ini menangkap focus ring, status hover, dan affordance disabled yang luput dari file desain statis.
Di QA, tab Rendering Chrome DevTools mensimulasikan protanopia/deuteranopia/tritanopia untuk pengecekan langsung pada alur kritis. Color Picker di DevTools juga menampilkan rasio WCAG inline saat Anda hover elemen apa pun.

Pa11y, Lighthouse CI, dan @axe-core/playwright semuanya menampilkan assertion kontras sebagai bagian dari audit aksesibilitas yang lebih luas. Tidak ada yang memeriksa APCA hari ini; semuanya memeriksa WCAG 2. Kompromi realistisnya adalah “tegakkan WCAG 2 AA di CI, lakukan sanity-check APCA Lc secara manual untuk warna merek dan dark mode.”

Pola yang layak diadopsi dari tim design-system yang lebih besar: panggang pengecekan kontras ke dalam langkah validasi token Anda, bukan hanya di QA level halaman. Jika token desain Anda dikompilasi dari source file (JSON, YAML, atau modul TypeScript), tambahkan skrip yang mengenumerasi setiap pasangan --text-* × --surface-* yang diizinkan sistem dan menegaskan rasio WCAG minimum. Skrip berjalan dalam milidetik, menangkap regresi ketika seseorang mengubah nilai token, dan menghasilkan matriks kontras yang sekaligus berfungsi sebagai dokumentasi bagi tim desain. Pengecekan ini independen dari halaman ter-render mana pun; ia beroperasi murni di tingkat token, sehingga menangkap kegagalan sebelum UI apa pun dirilis.

Untuk konversi ad hoc selama alur kerja ini (mengkonversi antara hex, RGB, HSL, dan OKLCH saat Anda men-debug), spoke HEX ke RGB, HEX ke HSL, HEX ke OKLCH, dan RGB ke HEX menutupi perjalanan bolak-balik ke dan dari format warna apa pun yang diharapkan toolchain Anda.

Kesalahan umum dan cara memperbaikinya

Setelah bertahun-tahun audit aksesibilitas, enam kegagalan yang sama terus muncul. Masing-masing memiliki perbaikan yang rapi:

Teks placeholder dengan abu-abu terang. #999999 di atas putih adalah 2.85:1, gagal AA. Entah perdalam ke #666666 (5.74:1, lulus AA) atau, lebih baik, ganti pola placeholder-sebagai-label dengan label visible permanen di atas field. Placeholder seharusnya tidak membawa informasi.
Tombol oranye merek dengan teks putih. #FFA500 di atas putih adalah 1.97:1, gagal AA dengan buruk. Perbaikan yang menjaga merek adalah membalik arah kontras: teks gelap (misalnya #451a03) di atas latar oranye, atau pertahankan teks putih tetapi gelapkan tombol menjadi coklat-oranye yang dalam dan jenuh. Verifikasi di Konverter Warna sebelum rilis.
Tautan biru terang di dark mode. #3b82f6 di atas #000000 adalah 5.71:1 (lulus WCAG AA) tetapi APCA Lc ~65, di bawah ambang isi Lc 75. Beralih ke OKLCH dan naikkan L dari ≈ 0.63 ke 0.75, pertahankan C dan H tetap; Anda akan mendarat di sekitar #7aa5f8 dengan APCA Lc 80+ yang nyaman dan hue yang sama.
Teks disabled di #CCCCCC. 1.61:1 terhadap putih. WCAG 1.4.3 mengecualikan teks murni dekoratif dari aturan rasio, tetapi kontrol UI disabled tidak dekoratif; mereka mengomunikasikan “ini saat ini tidak tersedia.” Pasangkan warna yang teredam dengan isyarat non-warna (strikethrough, ikon gembok, tooltip “Disabled”) agar pengguna CVD atau low-vision tetap memahami statusnya.
Ikon status yang berbeda hanya di hue. × merah dan ✓ hijau sudah cukup karena bentuknya sudah membedakannya. Titik merah vs titik hijau tidak. Gunakan bentuk dan warna bersama; pratinjau CVD di Konverter Warna membuat kasus kegagalan terlihat dalam sedetik.
Teks di atas latar gradien. Gradien yang berjalan dari #3b82f6 ke #a78bfa melawan teks putih lulus kontras di tengah dan gagal di dekat ujung lavender. Perbaikannya adalah menegakkan kontras terhadap titik terburuk di gradien, atau menempatkan scrim gelap semi-transparan di atasnya sehingga luminansi latar belakang efektif selalu di bawah ambang yang diketahui.

Setiap perbaikan butuh menit. Siklus audit yang dihindarinya butuh minggu.

FAQ

Apa itu rasio kontras WCAG AA?

WCAG AA mewajibkan ≥ 4.5:1 antara teks isi dan latar belakang, atau ≥ 3:1 untuk teks besar (≥ 18pt regular atau ≥ 14pt bold) dan komponen UI seperti batas formulir. AA adalah garis dasar hukum di bawah ADA, EAA, dan Section 508; sebagian besar situs komersial menargetkan AA karena mencakup batas regulasi tanpa memaksa warna merek bergeser ke skala abu-abu.

Berapa rasio kontras yang saya butuhkan untuk AAA?

WCAG AAA mewajibkan ≥ 7:1 untuk teks isi normal dan ≥ 4.5:1 untuk teks besar. AAA direkomendasikan untuk situs medis, pendidikan, dan pemerintah di mana basis penggunanya condong ke kebutuhan aksesibilitas yang lebih tinggi. Warna merek sering perlu diratakan ke nilai yang dekat dengan skala abu-abu untuk lulus AAA, itulah sebabnya banyak produk komersial berhenti di AA.

Apa itu APCA dan apakah ini WCAG 3.0?

APCA (Advanced Perceptual Contrast Algorithm), dirancang oleh Andrew Somers / Myndex, adalah algoritma kandidat di bawah proyek WCAG 3 Silver. Ia menggunakan skor Lc sensitif-polaritas dari -108 hingga +108 alih-alih rasio simetris. Per 2026, WCAG 3 masih dalam draf awal dan APCA belum diratifikasi secara formal; WCAG 2.1 / 2.2 AA tetap menjadi standar regulasi yang harus Anda capai hari ini.

Apakah dark mode membantu aksesibilitas kontras?

Kadang, tetapi tidak otomatis. Rasio simetris WCAG 2 melewatkan kombinasi yang sama di mode terang dan gelap, tetapi APCA (yang sensitif-polaritas) sering menandai teks isi dark-mode sebagai lebih sulit dibaca dibanding pasangan hex yang sama di mode terang. Selalu uji ulang dark mode terhadap WCAG dan APCA sebelum rilis; teks terang di latar gelap kehilangan kontras yang dipersepsi dengan cara yang tidak bisa dilihat rasio simetris.

Mengapa warna merek saya gagal WCAG AA?

Warna jenuh dengan luminansi medium (sebagian besar oranye, kuning, hijau lime, biru muda) memiliki nilai luminansi relatif yang terlalu dekat dengan putih untuk mencapai 4.5:1. Perbaikannya: pertahankan hue merek untuk aksen dan headline besar, tetapi pasangkan teks isi dengan nada lebih gelap dari keluarga hue yang sama. Gunakan OKLCH untuk menurunkan kanal L tanpa menggeser hue; Konverter Warna menemukan shade terdekat yang lulus dalam satu langkah.

Apakah rasio WCAG 2 dan skor APCA kompatibel?

Tidak. WCAG 2 mengembalikan rasio simetris (1–21); APCA mengembalikan skor Lc bertanda polaritas (-108 hingga +108). Relasinya non-linear: pasangan yang 4.5:1 di WCAG mungkin mencetak Lc 60 atau Lc 75 di APCA tergantung warna mana yang di atas. Perlakukan keduanya sebagai dua pengecekan independen, bukan terjemahan satu sama lain.

Bisakah saya menggunakan kontras warna untuk ikon UI kecil?

Bisa, dengan catatan. WCAG 2.1 §1.4.11 mewajibkan ≥ 3:1 untuk komponen UI dan objek grafis. Untuk ikon dekoratif yang dipasangkan dengan label teks visible, persyaratan kontras melonggar; labelnya yang membawa makna. Untuk ikon mandiri (misalnya kaca pembesar pencarian tanpa label), tegakkan 3:1 penuh terhadap latar belakang sekitarnya.

Bagaimana saya menguji buta warna tanpa mensimulasikan?

Gunakan Chrome DevTools → Rendering → “Emulate vision deficiencies” untuk protanopia, deuteranopia, tritanopia, dan achromatopsia. Kombinasikan dengan pratinjau CVD 8-jenis di Konverter Warna untuk varian anomalous trichromacy (deuteranomaly yang paling umum di 5% pria). Untuk pelaporan audit, tangkap screenshot di bawah setiap simulasi agar reviewer dapat melihat mode kegagalan secara inline.

Kesimpulan

Lima poin yang perlu dibawa pulang:

AA 4.5:1 adalah batas hukum. Capai untuk semua teks isi atau bersiaplah menghadapi keluhan kepatuhan.
AAA 7:1 berlaku untuk kesehatan, pendidikan, dan pemerintah. Sebagian besar merek komersial berhenti di AA dengan sengaja.
APCA Lc adalah sanity check keterbacaan nyata. Jalankan paralel dengan WCAG 2, terutama untuk dark mode dan warna merek jenuh.
Warna tidak pernah menjadi satu-satunya sinyal. Pasangkan setiap isyarat warna dengan bentuk, teks, atau pola; deuteranomaly sendiri 5% pengguna pria.
L pada OKLCH adalah tombol yang tepat. Ketika warna gagal kontras, kurangi L (bukan S, bukan B) untuk memperbaikinya tanpa menggeser hue.

Tempelkan dua kode hex apa pun ke Konverter Warna untuk melihat rasio WCAG, APCA Lc, klasifikasi gamut, dan pratinjau CVD 8-jenis berdampingan. Tampilan tunggal itu menggantikan enam alat terpisah dan merupakan cara tercepat untuk menutup audit yang dijelaskan panduan ini.

Panduan Rasio Kontras WCAG: AA, AAA, dan Algoritma APCA