Cara Memilih Kombinasi Warna yang Aksesibel

Pilihan warna terlihat seperti keputusan estetis dan bertindak seperti keputusan hukum. Kira-kira 4.000 gugatan aksesibilitas web per tahun menghantam tergugat AS sejak 2021, dan kontras warna yang tidak memadai adalah salah satu dari tiga isu yang paling sering dikutip dalam pengajuan berbasis WCAG (bersama dengan teks alt yang hilang dan bidang formulir tanpa label). Kabar baiknya adalah kontras paling sederhana dari ketiganya untuk diperbaiki: rasio kontras adalah angka, ambang WCAG adalah angka, dan Anda dapat menghitung satu terhadap yang lain dalam hitungan detik. Kabar buruknya adalah "aksesibel" melampaui rasio utama: buta warna, indikator fokus, mode gelap, dan tokenisasi semuanya penting, dan palet yang mendapat skor 4,5:1 di setiap gaya teks masih dapat gagal pada pengguna nyata.

Sejarah singkat aksesibilitas warna digital

Kontras warna sebagai standar tertulis berasal dari pekerjaan Web Accessibility Initiative pertama W3C pada 1997. Web Content Accessibility Guidelines 1.0 asli (Mei 1999) merekomendasikan kontras yang cukup dalam istilah kualitatif tanpa angka pasti. WCAG 2.0 (Desember 2008) memperkenalkan rumus luminansi relatif yang sekarang familiar dan rasio 4,5:1 di Level AA, diambil dari penelitian Lighthouse International tentang apa yang dapat dibaca dengan nyaman oleh pengguna lansia berkacamata baca pada layar.

Bobot hukum datang kemudian. Section 508 dari U.S. Rehabilitation Act merujuk WCAG 2.0 pada 2018; Americans with Disabilities Act, setelah putusan Sirkuit ke-9 Robles v. Domino's pada 15 Januari 2019 (Mahkamah Agung menolak mendengarkan banding pada Oktober 2019), sekarang dibaca oleh pengadilan AS sebagai mencakup aksesibilitas digital di bawah Title III. European Accessibility Act mulai berlaku 28 Juni 2025, mensyaratkan WCAG 2.1 AA pada layanan digital yang menghadap konsumen untuk sektor publik dan banyak perusahaan swasta. Dalam praktiknya, 4,5:1 teks normal + 3:1 teks besar + 3:1 komponen UI adalah lantai de facto untuk situs web publik yang sedang dibangun hari ini.

Ilmu pengetahuan terus berkembang. WCAG 2.1 (2018) menambahkan aturan kontras non-teks 3:1. Algoritma APCA, yang dikembangkan oleh Andrew Somers untuk WCAG 3, memodelkan persepsi kecerahan dengan lebih akurat dan memberikan angka yang berbeda untuk kombinasi yang sangat gelap dan sangat terang; ini adalah Editor's Draft per 2026, belum standar, jadi sebagian besar regulasi masih mengutip WCAG 2.x. OKLAB dan OKLCH dari Bjorn Ottosson (2020) memberi desainer ruang warna yang seragam secara perseptual yang membuat menghasilkan skala warna yang dapat diakses jauh lebih mudah daripada bekerja di HSL atau RGB.

Apa yang sebenarnya berarti "warna aksesibel"

Empat hal yang penting, bukan hanya satu rasio:

1. Kontras latar depan vs latar belakang. Angka utama. Teks badan membutuhkan 4,5:1, teks besar 3:1, kontrol UI dan indikator fokus 3:1 terhadap warna yang berdekatan. Hitung rasio dengan rumus WCAG 2 di pemeriksa kontras mana pun.
2. Buta warna. Kira-kira 8% pria dan 0,5% wanita melihat lebih sedikit warna daripada yang diasumsikan desain. Tiga jenis utama adalah protanopia dan deuteranopia (merah-hijau, paling umum), dan tritanopia (biru-kuning). Label kesalahan merah pada label sukses hijau dapat tidak terlihat oleh penampil protanopik.
3. Warna tidak pernah menjadi satu-satunya sinyal. WCAG 1.4.1 melarang mengandalkan warna saja untuk menyampaikan makna. Batas "kesalahan" merah juga membutuhkan ikon atau label. Toast "sukses" hijau membutuhkan tanda centang.
4. Indikator fokus. Pengguna keyboard perlu melihat di mana fokus berada. Aturan WCAG 2.4.7 mensyaratkan indikator fokus yang terlihat, dan pembaruan 2.4.11 (WCAG 2.2) mensyaratkan setidaknya 2 piksel CSS tebal dan kontras 3:1 terhadap warna yang berdekatan.

Palet yang menyusun rasionya benar tetapi mengabaikan tiga lainnya tetap gagal pada pengguna nyata.

Cara memilih warna yang aksesibel, langkah demi langkah

1. Mulai dengan token semantik, bukan warna mentah. Definisikan text-primary, text-secondary, surface-default, surface-elevated, border-default, accent-primary, accent-danger, dll. Petakan setiap token ke warna tertentu, dan biarkan token tersebut membawa makna semantik di mana saja dalam design system.
2. Pilih skala kecerahan. Gunakan nilai kecerahan OKLCH untuk membangun skala 5-9 langkah (50, 100, 200, ..., 900) di mana setiap langkah memiliki perbedaan perseptual yang konstan dari langkah berikutnya. Angka akan terlihat tidak biasa di OKLCH (sekitar L = 0,97, 0,93, 0,88...) tetapi langkah yang dirasakan akan merata, sesuatu yang tidak mungkin di HSL.
3. Pilih corak pada setiap langkah kecerahan. Pilih corak merek, lalu pilih corak komplementer atau aksen yang mempertahankan chroma serupa. Gunakan OKLCH sehingga "biru saturasi 100" dan "oranye saturasi 100" terlihat sama cerahnya.
4. Hitung rasio kontras. Setiap pasangan token yang bersentuhan membutuhkan rasio yang tepat. Teks badan pada permukaan default: 4,5:1. Teks yang dinonaktifkan pada permukaan default: tetap 3:1 jika perlu dapat dibaca. Indikator fokus pada permukaan yang berdekatan: 3:1.
5. Jalankan simulator buta warna. Ambil layar kunci dan render ulang melalui simulator protanopia, deuteranopia, dan tritanopia. Konfirmasi bahwa informasi yang disampaikan oleh warna tetap dapat dibedakan.
6. Uji dengan teknologi bantu nyata. Mac VoiceOver, NVDA, JAWS, dan TalkBack semuanya harus dapat dinavigasi tanpa bergantung pada isyarat warna.
7. Tambahkan sinyal non-warna di mana saja warna membawa makna. Ikon untuk kesalahan/sukses/peringatan, garis bawah untuk tautan di teks badan, pola untuk seri grafik.
8. Dokumentasikan token. Pustaka Figma, halaman Storybook, atau situs design-system statis. Auditor dan desainer baru harus dapat memilih token yang tepat dalam hitungan detik.

Referensi rasio kontras

Pengecualian untuk kontrol yang dinonaktifkan adalah celah hukum, bukan restu kegunaan; kontrol yang dinonaktifkan yang tidak dapat dibaca siapa pun mungkin secara teknis lolos WCAG tetapi tetap akan membingungkan pengguna.

Jenis buta warna dan cara memeriksanya

Selalu jalankan desain setidaknya melalui simulator protanopia dan deuteranopia; mereka menangkap sebagian besar pengguna buta warna.

Jebakan umum

• Mendesain di HSL atau RGB. Langkah numerik yang sama di HSL menghasilkan langkah yang dirasakan tidak sama. Lonjakan kecerahan 10% pada kuning pucat terlihat jauh lebih besar daripada lonjakan yang sama di biru tua. OKLCH memperbaikinya.
• Mengandalkan warna saja untuk menyampaikan keadaan. Merah dan hijau untuk kesalahan dan sukses: 8% pengguna tidak dapat membedakannya. Tambahkan ikon atau label.
• Hitam murni pada putih murni. #000 pada #FFF mendapat skor rasio 21:1 yang sempurna tetapi keras di mata untuk membaca lama. Turunkan ke hitam-dekat (#1a1a1a) dan putih-dekat (#f8f8f8) untuk teks badan.
• Tirani warna merek. Memperlakukan merah merek sebagai sakral dan menggunakannya pada putih merek pada kontras 2,1:1 hanya karena "itu adalah merek." Segarkan palet merek menjadi yang memenuhi WCAG.
• Indikator fokus yang hilang pada latar gelap. Cincin biru 2 piksel terhadap tombol biru tua mungkin tidak terlihat. Uji cincin fokus terhadap setiap permukaan tempatnya mungkin muncul.
• Teks placeholder yang gagal kontras. Teks placeholder= di dalam input dirender oleh browser pada opasitas ~40%. Pada input putih, itu mudah turun di bawah 4,5:1.
• Garis batas bidang formulir yang terlalu samar. Batas 1px abu-abu-pada-putih pada kontras 1,2:1 gagal WCAG 1.4.11 (kontras non-teks). Tingkatkan ke 3:1 atau lebih tebal.
• Status hover yang hanya berubah warna. Beberapa perangkat input penunjuk (stylus Bluetooth, pelacakan mata) tidak menghasilkan hover; perubahan warna hanya-hover tidak terlihat bagi mereka. Gabungkan dengan bayangan halus atau transformasi.
• Mode gelap dengan inversi sederhana. Membalikkan palet terang menghasilkan warna gelap jenuh yang terlihat keras. Palet mode gelap membutuhkan tahap desain sendiri dengan aksen yang dijenuhkan.
• Teks yang dihasilkan otomatis dari gambar. Teks yang dirender di atas gambar yang diunggah pengguna tidak dapat menjamin kontras. Tambahkan latar belakang tembus pandang atau text-shadow yang mengembalikan kontras lokal.

Algoritma dan standar alternatif

Untuk pekerjaan yang diatur hari ini, WCAG 2.1 AA adalah lantai. APCA layak dipantau saat WCAG 3 matang; banyak tim design system sudah melaporkan kedua angka.

Alat untuk memilih warna yang aksesibel

Untuk proyek baru, mulailah dari palet yang teruji (Radix Colors dan Open Props adalah default yang baik), pilih token merek, dan verifikasi setiap pasangan teks-pada-permukaan dengan pemeriksa kontras. Untuk proyek yang ada, lakukan audit sekali untuk setiap pasangan teks/latar belakang di stylesheet Anda, perbaiki kegagalannya, dan tambahkan langkah Stark atau axe ke CI Anda sehingga kegagalan berikutnya ditangkap pada waktu PR.

Privasi dan alat

Pemeriksa kontras warna, generator palet aksesibel, dan simulator buta warna semuanya berjalan sepenuhnya di browser Anda. Warna yang Anda pilih atau tempel diproses oleh JavaScript di perangkat Anda, hasilnya dirender ke halaman, dan tidak ada yang dikirim ke server. Tidak ada telemetri, tidak ada analitik pada input, tidak ada skrip pihak ketiga. Untuk warna merek yang belum publik, palet produk internal, atau desain di bawah embargo, alur khusus-lokal itu adalah perbedaan antara mempercayai alat desain orang asing dengan aset merek Anda yang belum dirilis dan tidak. Alat dapat berjalan offline setelah halaman dimuat, yang dapat Anda verifikasi dengan mematikan jaringan dan memeriksa ulang pasangan kontras.