Palette yang Aksesibel: Berhenti Menggunakan HSL dalam Sistem Warna

 (wildbit.com)
2 poin oleh GN⁺ 2023-08-30 | 1 komentar | Bagikan ke WhatsApp
  • Palet warna lama Postmark memiliki kecerahan yang dirasakan yang tidak konsisten antarwarna dan sulit memprediksi rasio kontras antar level, sehingga rekomendasi kontras WCAG harus diperiksa manual setiap kali
  • HSL/HSV adalah model hasil transformasi sederhana dari RGB sehingga tidak mencerminkan persepsi manusia terhadap kecerahan dan saturasi; model ini bisa dipakai untuk memilih satu warna, tetapi kurang cocok untuk membangun sistem warna
  • CIELAB dan LCh adalah ruang warna yang seragam secara perseptual yang dirancang agar perubahan angka lebih dekat dengan perubahan yang dirasakan, sehingga dapat membuat skala warna dengan tingkat kecerahan yang sama secara lebih konsisten
  • Accessible Palette adalah aplikasi yang menghasilkan palet yang konsisten berbasis LCh dengan menyesuaikan kecerahan, rasio kontras, koreksi Hue, dan pencerminan warna merek yang sudah ada
  • Rasio kontras WCAG 2.1 dan APCA dari Working Draft WCAG 3 sebaiknya diperiksa bersama agar lebih mudah memenuhi panduan saat ini sekaligus siap menghadapi perubahan algoritme kontras di masa depan

Masalah pada sistem warna Postmark

  • Palet Postmark yang lama memiliki dua masalah
    • Kecerahan yang dirasakan tidak konsisten; misalnya biru dan merah terlihat jauh lebih gelap daripada kuning dan hijau
    • Sulit memprediksi rasio kontras antar variasi warna, sehingga tidak mudah mengetahui apakah pasangan warna memenuhi rekomendasi WCAG
  • Setiap kali memilih pasangan warna, rasio kontras harus diperiksa secara manual, dan dalam praktiknya sering kali pemeriksaan itu tidak dilakukan
  • Penyebabnya adalah keterbatasan model warna HSL itu sendiri, serta belum memadainya dukungan alat desain untuk alternatif yang lebih baik

Mengapa HSL tidak cocok untuk sistem warna

  • RGB adalah model yang mencerminkan cara layar bekerja, dan bukan model intuitif yang memudahkan manusia memilih warna
  • HSL dan HSV/HSB adalah alternatif yang dibuat pada tahun 1970-an untuk merepresentasikan RGB dengan cara yang lebih dekat dengan cara manusia memikirkan warna
    • HSL berarti Hue, Saturation, Lightness
    • HSV/HSB berarti Hue, Saturation, Value atau Brightness
  • Pada masa itu, biaya komputasi untuk model yang lebih canggih masih tinggi, sehingga HSL dan HSV mengorbankan akurasi perseptual demi kecepatan perhitungan
  • Akibatnya, HSL dan HSV pada dasarnya hanya transformasi matematis sederhana dari RGB, dan tidak mampu mencerminkan dengan baik kecerahan atau saturasi yang dirasakan manusia
  • Misalnya, pada HSL, skala warna yang disetel ke Saturation 100 dan Lightness 50 memang memiliki kecerahan yang sama menurut model, tetapi dalam kenyataannya biru #00F terlihat jauh lebih gelap daripada kuning #FF0 atau sian #0FF
  • Dalam HSL, warna dengan saturasi penuh dipetakan ke nilai maksimum RGB dan ditempatkan pada lingkaran Hue dengan Lightness 50, sedangkan Lightness 0 dan 100 masing-masing sesuai dengan hitam dan putih
    • Variasi yang lebih terang atau lebih gelap dibuat dengan cara “mencampurkannya” dengan putih atau hitam
    • Sumbu vertikal di tengah adalah rentang warna netral atau abu-abu dengan Saturation 0

CIELAB dan LCh

  • Saat HSL dan HSV diformalkan, sebenarnya sudah ada alternatif yang lebih baik, yaitu ruang warna CIELAB
  • International Commission on Illumination, yaitu CIE, mendefinisikan ruang warna CIELAB atau L*a* b* pada tahun 1976
  • CIELAB adalah ruang warna yang seragam secara perseptual yang dirancang agar perubahan numerik berkorespondensi dengan perubahan warna yang dirasakan secara serupa
    • Tidak seperti RGB, ruang ini dirancang untuk mencakup seluruh rentang warna yang terlihat
    • Komponen L*, yaitu Lightness, disesuaikan agar mendekati persepsi manusia terhadap kecerahan
  • CIELAB terdiri dari tiga sumbu
    • Nilai L* mendefinisikan 0 sebagai hitam dan 100 sebagai putih
    • Sumbu a* adalah sumbu lawan warna hijau-merah; nilai negatif menuju hijau, nilai positif menuju merah
    • Sumbu b* adalah sumbu lawan warna biru-kuning; nilai negatif menuju biru, nilai positif menuju kuning
  • CIELCh, LCh, atau Lch(ab) adalah representasi silindris dari CIELAB
    • Alih-alih a* dan b*, ruang ini menggunakan Chroma dan sudut Hue
    • Lightness tetap dipertahankan
  • Sudut Hue pada LCh mirip dengan Hue pada HSL, tetapi tidak sama
    • HSL/HSV menempatkan tiga warna primer aditif—merah, hijau, biru—pada H=0, 120, 240°
    • LCh menempatkan merah, kuning, hijau, biru pada h=0, 90, 180, 270°
  • Ada juga ruang warna serupa bernama HCL atau LCh(uv), yang berbeda dari LCh(ab) karena Chroma-nya memiliki skala seragam dari 0 sampai 100

Cara membuat skala warna di LCh

  • Tidak seperti HSL/HSV, LCh memang muat di dalam bentuk silinder, tetapi tidak mengisi silinder itu sepenuhnya
  • Beberapa kombinasi Lightness, Chroma, dan Hue menghasilkan warna yang tidak mungkin ada
    • Misalnya, kuning yang gelap dan sangat jenuh tidak ada
  • Semakin dekat ke hitam dan putih dalam skala Lightness, semakin sedikit jumlah warna yang dapat dibedakan manusia
  • Layar nyata juga tidak dapat menampilkan seluruh rentang warna yang terlihat
    • Gamut sRGB mewakili layar pada umumnya dan hanya mencakup sekitar ⅓ dari ruang warna LCh
    • Di CSS pun, setidaknya untuk saat ini, masih dibatasi pada rentang tersebut
  • Jika skala warna HSL dengan Saturation 100 dan Lightness 50 dilihat berdasarkan LCh, kuning adalah yang paling terang dan biru yang paling gelap
    • Hijau hampir tiga kali lebih terang daripada biru, dan sekitar dua kali lebih terang daripada merah
  • Jika skala dibuat ulang di LCh dengan tingkat Lightness yang sama, kecerahan antarwarna akan terlihat konsisten secara visual
    • Karena Chroma berbeda, beberapa warna bisa memiliki saturasi lebih tinggi daripada warna lain
    • Untuk warna notifikasi dan peringatan, saturasi yang lebih tinggi daripada warna teks dasar bisa jadi diinginkan, sehingga perbedaan seperti ini berguna dalam sistem warna
  • Jika Chroma juga diselaraskan dengan lebih konsisten, skala yang halus dapat dibuat bahkan dalam ruang warna sRGB yang terbatas

Keterbatasan alat desain dan Accessible Palette

  • Saat ini Figma, Sketch, dan Adobe XD belum mendukung CIELAB maupun LCh
  • Di Figma ada plugin LCH color picker dan Chromatic, tetapi keduanya belum cukup untuk membangun sistem warna yang fleksibel
  • Alat yang dibutuhkan harus memenuhi tiga syarat
    • Menjaga konsistensi kecerahan saat membuat variasi warna
    • Dapat mengontrol rasio kontras antar level
    • Cukup fleksibel untuk mengakomodasi warna merek yang sudah ada
  • Setelah menemukan library Chroma.js yang mendukung LCh dengan baik, dibuatlah alat sederhana untuk menghasilkan palet baru lewat kode
  • Setelah dipakai secara internal dan dibagikan ke beberapa kenalan, alat ini kemudian dirilis sebagai aplikasi Accessible Palette
  • Accessible Palette adalah aplikasi untuk membuat sistem warna dengan kecerahan yang konsisten dan rasio kontras yang dapat diprediksi di seluruh level warna

Cara kerja Accessible Palette

  • Saat menyesuaikan warna awal atau menempelkan warna dari desain yang sudah ada, alat ini menggunakan Chroma dan Hue dari warna tersebut untuk menghitung skala dengan beberapa level Lightness
  • Lightness sepenuhnya dapat dikustomisasi dan bisa dipakai baik untuk palet terang maupun gelap
    • Dapat disetel dengan rinci agar mencakup warna merek yang sudah ada
    • Di Postmark, tujuannya adalah mempertahankan kuning #FFDE00, biru #007DCC, dan hijau #4FC47F yang paling sering digunakan pada palet lama
    • Nilai Lightness warna-warna itu—88.6, 75.2, dan 50.6—digunakan masing-masing sebagai tingkat kecerahan untuk level 200, 400, dan 600
  • Rasio kontras berubah sesuai Lightness, dan untuk setiap level dihitung dengan metode rekomendasi WCAG 2.1 serta algoritme baru dari Working Draft WCAG 3.0
    • Secara default, kontras semua warna diukur terhadap latar belakang putih
    • Anda dapat memilih swatch warna yang diinginkan untuk mengukur rasio kontras terhadap warna tersebut
  • Level dapat dibuat menggunakan ruang warna RGB atau CIELAB
    • Dalam beberapa kasus hasilnya bisa berbeda, sehingga layak untuk dicoba
    • Dalam sistem warna Postmark, penggunaan CIELAB mengurangi nuansa ungu pada merah terang, tetapi menambah nuansa ungu pada biru
  • Beberapa warna mungkin memerlukan koreksi Hue di seluruh rentangnya
    • Kuning terang cenderung mendapat nuansa hijau saat menjadi lebih gelap
    • Untuk membuatnya sedikit lebih dekat ke oranye, digunakan koreksi Hue negatif
  • Aplikasi memperbarui URL saat digunakan sehingga perubahan tersimpan
    • URL itu bisa dibagikan ke tim atau ditambahkan ke library Figma dan file variabel warna CSS untuk referensi berikutnya
  • Contoh palet mencakup palet warna baru Postmark, palet berbasis Google’s Material Design, dan palet berbasis TailwindCSS
    • Contoh-contoh ini bukan reproduksi persis dari versi asli, melainkan alternatif yang terinspirasi oleh warna asal dan level kecerahannya

Perhitungan rasio kontras dan WCAG

  • Alasan Accessible Palette menampilkan dua jenis rasio kontras adalah karena metode WCAG 2.1 memiliki keterbatasan
  • WCAG 2.1 menghitung rasio kontras dengan membagi luminans warna depan dengan luminans warna latar belakang
  • Rumus ini memberikan respons linear, tetapi manusia merasakan kontras antawarna terang lebih tinggi daripada kontras antawarna gelap
  • Dalam contoh nyata, sampel yang memenuhi rekomendasi WCAG 2.1 bisa justru lebih sulit dibaca daripada sampel yang ditandai memiliki rasio kontras “tidak memadai”
  • W3C menyadari masalah ini, dan Andrew Somers memulai diskusi publik pada tahun 2019
  • Algoritme kerja baru yang diusulkan Andrew Somers kemudian menjadi bagian dari WCAG 3 Working Draft, dan ia juga membuat APCA Contrast Calculator
  • APCA adalah singkatan dari Advanced Perceptual Contrast Algorithm, lebih akurat secara perseptual, dan juga mempertimbangkan ukuran serta ketebalan font
  • Accessible Palette menggunakan APCA dan memakai skor 60 sebagai tingkat rekomendasi minimum untuk teks yang dapat dibaca
    • Ini adalah patokan yang kurang lebih setara dengan rekomendasi rasio kontras 4.5:1 pada WCAG 2.1
  • Ini bukan berarti rasio kontras WCAG 2.1 sama sekali tidak berguna
    • Pada warna-warna rentang tengah, hasilnya masih cukup akurat
    • Namun secara keseluruhan, algoritme baru merupakan peningkatan besar
  • Metode WCAG 3 masih berstatus Working Draft sehingga bisa berubah seiring waktu
  • Untuk memenuhi panduan saat ini sekaligus siap menghadapi perubahan di masa depan, sebaiknya sistem warna dibuat dengan mempertimbangkan kedua panduan tersebut bersama-sama

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-30
Komentar Hacker News

  • Pada sistem tampilan dan cetak umum, merah dan biru yang tersaturasi sebenarnya harus dianggap lebih gelap daripada hijau
    Rumus persisnya berbeda tergantung ruang warna, tetapi Grayscale = 0.299R + 0.587G + 0.114B sering dikutip, dan dalam kasus ini merah murni paling terang memiliki kecerahan sekitar 30%, biru murni 11%, sehingga dalam kebanyakan kasus merah terang hampir seperti kontradiksi
    Warna seperti ini tetap bisa dipakai, tetapi pasti selalu terlihat gelap; jika hanya menerapkan aturan kontras sederhana, aksesibilitas bisa terpenuhi, tetapi jika menginginkan hasil yang juga enak dilihat, teknik yang dibahas dalam tulisan ini jauh lebih menguntungkan
    Saat membuat foto stereoskopik merah-sian seperti https://en.wikipedia.org/wiki/Anaglyph_3D pun, pohon dan rumput memang hijau, tetapi sebenarnya memiliki banyak komponen merah sehingga keseimbangan kanalnya baik dan kedalaman maupun warnanya sama-sama bagus
    Referensi: https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • Ini mengingatkan pada masa batas aman siaran NTSC dan klien-klien yang terlalu menyukai warna merah
      Selalu sulit menjelaskan bahwa artwork merah yang indah tidak akan terlihat indah sama sekali di TV, apalagi jika untuk siaran
      Bahkan jika bukan untuk siaran, merah di luar spesifikasi bisa tampak tertinggal sampai beberapa frame kemudian, dan terlihat melebar seperti leher yang tersayat
    • Ada beberapa hal yang keliru di sini
      Jika sudah membaca balasan-balasan, saya bisa menjawab dan mencoba menjelaskan beberapa hal dengan lebih jelas

  • Sejak lama saya terganggu oleh fakta bahwa sampel yang benar-benar memenuhi kriteria rekomendasi WCAG 2.1 lebih sulit dibaca daripada sampel dengan rasio kontras yang “tidak memadai”
    Saya penasaran mengapa rumus “pedoman aksesibilitas” yang justru menghasilkan efek sebaliknya bisa distandardisasi

    • Agak disayangkan bahwa algoritma dan pedoman yang paling luas dipakai untuk aksesibilitas kontras tidak memiliki dasar yang ditinjau sejawat
      Begitu juga 2.1 dan standar berikutnya; untuk area sebesar pengaruh ini, saya berharap industri mensponsori riset yang lebih ketat
    • Saya ingat ada gerakan di dalam W3C/WCAG untuk mengubah rumus penilaian kontras
      Mungkin saja itu hanya berupa permintaan seperti itu dan belum diadopsi secara resmi

  • Tulisan terbaik yang pernah saya lihat tentang topik ini adalah https://www.handprint.com/HP/WCL/color1.html
    Tulisannya sangat panjang, jadi perlu siap menghabiskan satu hari
    Mungkin mengejutkan, tetapi saat memberi warna log dengan cantik di ClickHouse pun kami memakai beberapa ide dari tulisan ini: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • Sulit menemukan cara spesifik untuk mengonversi warna ANSI ini ke RGB; sebenarnya tampaknya itu hanya permintaan warna dan bergantung pada pengaturan terminal
      Saya penasaran apakah Anda bisa membagikan nilai RGB yang diharapkan untuk tiap jenis pesan yang disetel di kode

  • Saya bertemu Eugene di konferensi Config Figma; ia memberi banyak tip praktis serupa kepada para desainer, sangat ramah, dan benar-benar serius soal desain serta aksesibilitas
    Hal yang terutama ingin saya puji dari tulisan ini adalah APCA, yang kemungkinan besar akan mewarisi algoritma kontras warna WCAG 2
    Dalam perombakan aksesibilitas internal Figma pun kami menggunakan APCA, dan berkat itu hasil akhirnya menjadi jauh lebih baik
    Eugene menunjukkan dengan baik kasus-kasus ketika WCAG 2 gagal, dan dalam praktiknya kami juga terus menemui kasus-kasus seperti itu
    Nasihat intinya adalah bahwa mencocokkan warna dengan benar itu benar-benar sulit
    Alat memang membantu, tetapi pada titik tertentu Anda harus memercayai mata Anda
    Pada akhirnya alat-alat ini hanya memperkirakan secara matematis cara mata melihat warna, dan standar akhirnya bukan algoritma, melainkan mata manusia
    Pada titik ketika alat atau algoritma menghasilkan hasil yang tidak tepat, lebih baik menyesuaikannya atau kembali ke dasar

    • Saya penasaran apakah Anda bisa menjelaskan lebih detail bagian bahwa APCA dipakai dalam perombakan aksesibilitas internal Figma
      Saya ingin tahu apakah maksudnya hanya menggunakan APCA dan mengabaikan konten yang ditandai kurang kontras oleh algoritma kontras warna WCAG 2
    • Saya buta warna merah-hijau, dan aksesibilitas bawaan Figma sudah cukup baik sehingga saya tidak pernah berpikir untuk melakukan penyesuaian aksesibilitas secara terpisah
      Dibuat dengan baik

  • Saya juga ingin memperkenalkan HCT
    Ini adalah ruang warna yang dibuat untuk memungkinkan Material You, yang menggabungkan metrik kecerahan yang disebutkan di sini dengan ruang warna berbasis ilmu warna modern
    LAB/LCH berasal dari tahun 1976
    Ini membuat desain lebih intuitif; yang perlu diketahui hanyalah bahwa selisih T sebesar 40 memenuhi kriteria WCAG untuk tombol, dan 50 memenuhi kriteria untuk teks

    • Menarik
      Saya penasaran bagaimana HCT dibandingkan dengan https://www.hsluv.org/comparison/
      Mirip dengan HCT, di sini selisih L memudahkan pemilihan warna kontras
      Dalam konteks yang sama, saya juga penasaran dengan pandangan tentang https://www.myndex.com/APCA/ dan pendekatan saat ini menjadi standar
      Karena nilai kontras antara dua warna bergantung pada warna mana yang menjadi foreground dan mana yang menjadi background, rasanya sekarang membandingkan selisih T saja tidak lagi cukup
    • Saya penasaran apakah ada materi yang bagus untuk mempelajari HCT
      Misalnya, anggap sebuah aplikasi membutuhkan warna merah, kuning, biru, oranye, hijau, dan ungu, yaitu 6 warna yang sesuai dengan 3 warna primer dan 3 warna komplementer
      Warna persisnya tidak terlalu penting, tetapi jika ingin keenam warna itu cukup dapat dibedakan serta memiliki kecerahan, dan mungkin saturasi, yang kurang lebih serupa, bagaimana caranya?
      Karena kuning sangat terang dan biru sangat gelap, sepertinya tidak ada jawaban yang benar-benar tepat dan kita harus mencapai perkiraan
      Saya penasaran apakah ada alat atau tutorial untuk mempelajari hal seperti ini
    • Saya penasaran apakah ada spesifikasi publik di suatu tempat
      Yang saya temukan hanya kode material-color-utilities di GitHub
      Melihat kodenya, perhitungannya tampak jauh lebih rumit daripada OkLab, terutama arah dari HCT ke RGB

  • Selain melewatkan oklab/oklch dalam tulisan, klaim bahwa web/CSS hanya mendukung sRGB juga salah
    Fungsi CSS color() mendukung banyak ruang warna

    • Saya penulisnya
      Tulisan ini diterbitkan 2 tahun lalu, dan saat saya mulai mengerjakan alatnya, spesifikasi OkLCH pun belum keluar
      Kalau sekarang, saya akan memilih OkLCH alih-alih LCH, karena ia menyelesaikan beberapa masalah LCH
    • CSS Color Module Level 4 masih berada pada tahap draf rekomendasi
      Di sini, “dukungan” lebih tepatnya mendekati “didukung kecuali oleh Microsoft Edge(chromium) dan Pale Moon(goanna)”
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • Saya pernah langsung memakai oklab dan beberapa ruang warna keluarga LAB, dan Oklab sangat bagus untuk dipotong dan digunakan dengan perhitungan sederhana
    • Ada juga model warna yang dibuat di atas Oklch
      Namun, alih-alih kecerahan, ia menggunakan rasio kontras APCA, yaitu WCAG 3: https://github.com/antiflasher/apcach

  • oklab mungkin merupakan alternatif yang lebih baik daripada LCh
    https://bottosson.github.io/posts/oklab/

    • Ada sisi yang cukup jauh menyimpang dari premis awal
      Kanal kecerahannya terbalik dibanding semua ruang warna lain, dan L sama sekali tidak ada hubungannya dengan L pada LCH atau LAB
      Keberhasilannya justru dalam beberapa hal membawa lebih banyak kemiskinan intelektual
      Ada sangat banyak hal pada tulisan blog awal yang perlu dikoreksi, dan logikanya mulai sangat melenceng sejak titik ketika ia mulai mengklaim akurasi dengan gradien yang menggunakan CAM16 UCS
    • Playground ini memvisualisasikan 16 ruang warna, termasuk LCh dan OKLAB, dengan sangat mengesankan: https://color-playground.ardov.me/spaces-3d
    • Memang tidak sempurna, tetapi dalam beberapa situasi saya telah menggunakan oklab dan oklch untuk interpolasi warna, dan hasilnya secara visual jauh lebih memuaskan daripada interpolasi di RGB atau HSL
    • Saya menggunakan OkLab di situs saya dengan memuaskan; rasanya jauh lebih nyaman di mata dibanding palet warna yang sebelumnya menggunakan CIELAB

  • Jika nilai CIELAB didasarkan pada perubahan perseptual, saya penasaran bagaimana itu berinteraksi dengan aksesibilitas
    Apakah kita perlu khawatir bahwa rumus perseptual semacam ini mungkin dibuat berdasarkan penglihatan standar?
    Saya juga penasaran apakah ini bisa berbeda tergantung jenis gangguan penglihatan warna, atau justru bukan masalah seperti itu
    Saya berusaha membuat chart seaksesibel mungkin, tetapi saya sama sekali tidak pernah belajar tentang warna, jadi saya hanya mengikuti saran dan tidak bisa menurunkannya sendiri
    Jadi sangat mungkin ini pertanyaan yang bodoh

    • Saya pernah mengerjakan hal ini
      Kontras berubah secara nonlinier
      Simulasi cukup mudah diterapkan, dan simulasi oleh Machado dkk. hanyalah transformasi matriks

  • Tulisan ini menaruh penjelasannya di bagian bawah, tetapi APCA Contrast, uji kontras yang mudah dibaca dalam draf standar WCAG 3, jauh lebih adil untuk sebagian warna dibanding rasio kontras WCAG 2.1
    Tulisan yang bagus dibaca tentang teori warna di balik kontras perseptual: https://www.smashingmagazine.com/2022/09/realities-myths-con...
    Tulisan yang menjelaskan APCA secara ringkas: https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCA bekerja dengan baik, tetapi lisensinya sangat aneh dan membatasi
      Sebaiknya periksa bagian itu secara mendetail sebelum menggunakannya untuk apa pun dan tentukan apakah benar-benar bisa digunakan

  • Di mana kodenya?
    Yang dibutuhkan adalah algoritma yang bisa dipakai bukan hanya di form web, tetapi di perangkat lunak apa pun