Erişilebilir Palet: Renk sistemlerinde HSL kullanmayı bırakın

 (wildbit.com)
2 puan yazan GN⁺ 2023-08-30 | 1 yorum | WhatsApp'ta paylaş
  • Postmark’ın mevcut renk paletinde renklere göre algılanan parlaklık düzensizdi ve kademeler arasındaki kontrast oranını öngörmek zordu; bu yüzden WCAG’in önerdiği kontrastı her seferinde elle kontrol etmek gerekiyordu
  • HSL/HSV, RGB’nin basit dönüşümlerine dayanan modeller olduğundan insanın parlaklık ve doygunluk algısını yansıtmaz; tek bir renk seçmekte işe yarasalar da bir renk sistemi kurmak için uygun değildirler
  • CIELAB ve LCh, sayısal değişimlerin algılanan değişime daha yakın olması için tasarlanmış algısal olarak eşitlikçi renk uzaylarıdır; bu sayede aynı parlaklık düzeyine sahip renk ölçekleri daha tutarlı üretilebilir
  • Accessible Palette, LCh tabanlı olarak parlaklık, kontrast oranı, Hue düzeltmesi ve mevcut marka renklerini yansıtmayı ayarlayıp tutarlı bir palet üreten bir uygulamadır
  • WCAG 2.1 kontrast oranı ile WCAG 3 Working Draft’taki APCA’yı birlikte kontrol etmek, hem mevcut yönergelere uymayı hem de gelecekteki kontrast algoritması değişimlerine uyum sağlamayı kolaylaştırır

Postmark renk sisteminin sorunu

  • Mevcut Postmark paletinde iki sorun vardı
    • Mavi ve kırmızı, sarı ve yeşilden çok daha koyu görünüyordu; yani algılanan parlaklık tutarlı değildi
    • Renk varyasyonları arasındaki kontrast oranını öngörmek zordu; bu nedenle renk çiftlerinin WCAG önerilerini karşılayıp karşılamadığını kolayca anlamak mümkün değildi
  • Her renk çifti seçildiğinde kontrast oranını elle kontrol etmek gerekiyordu ve pratikte bunun hiç kontrol edilmemesi de oldukça olasıydı
  • Bunun nedeni hem HSL renk modelinin kendi sınırlamaları hem de tasarım araçlarının daha iyi alternatifleri yeterince desteklememesi idi

HSL neden renk sistemleri için uygun değil?

  • RGB, ekranların nasıl çalıştığını yansıtan bir modeldir; insanların kolayca renk seçebileceği sezgisel bir model değildir
  • HSL ile HSV/HSB, 1970’lerde RGB’yi insanların düşündüğü renk biçimine daha yakın ifade etmek için oluşturulmuş alternatiflerdir
    • HSL, Hue, Saturation, Lightness anlamına gelir
    • HSV/HSB ise Hue, Saturation, Value veya Brightness anlamına gelir
  • O dönemde daha gelişmiş modellerin hesaplama maliyeti yüksek olduğundan, HSL ve HSV hesaplama hızı uğruna algısal doğruluktan ödün verdi
  • Sonuç olarak HSL ve HSV, RGB’nin sadece kolay matematiksel dönüşümleridir ve insanların algıladığı parlaklık ya da doygunluğu doğru biçimde yansıtmaz
  • Örneğin HSL’de Saturation 100 ve Lightness 50 olarak ayarlanmış bir renk ölçeği model açısından aynı parlaklığa sahip görünse de, gerçekte mavi #00F, sarı #FF0 veya cyan #0FF’den çok daha koyu görünür
  • HSL’de tam doygun renkler RGB’nin maksimum değerlerine eşlenir ve Lightness 50’nin Hue çemberi üzerinde yer alır; Lightness 0 ve 100 ise sırasıyla siyah ve beyaza karşılık gelir
    • Daha açık ya da koyu varyasyonlar, beyaz veya siyahla “karıştırılarak” oluşturulur
    • Ortadaki dikey eksen, Saturation 0 olan nötr renkler veya gri aralığıdır

CIELAB ve LCh

  • HSL ve HSV’nin biçimlendirildiği dönemde bile daha iyi bir alternatif olan CIELAB renk uzayı zaten vardı
  • International Commission on Illumination yani CIE, 1976’da CIELAB veya L*a* b* renk uzayını tanımladı
  • CIELAB, sayısal değişimlerin benzer algısal renk değişimlerine karşılık gelmesi için tasarlanmış algısal olarak eşitlikçi bir renk uzayıdır
    • RGB’den farklı olarak, görülebilen renklerin tamamını kapsayacak şekilde tasarlanmıştır
    • Lightness olan L* bileşeni, insanın parlaklık algısına yakın olacak biçimde ayarlanmıştır
  • CIELAB üç eksenden oluşur
    • L* değeri 0’da siyahı, 100’de beyazı tanımlar
    • a* ekseni yeşil-kırmızı karşıt eksenidir; negatif değerler yeşile, pozitif değerler kırmızıya gider
    • b* ekseni mavi-sarı karşıt eksenidir; negatif değerler maviye, pozitif değerler sarıya gider
  • CIELCh, LCh veya Lch(ab), CIELAB’in silindirik gösterimidir
    • a* ve b* yerine Chroma ve Hue açısını kullanır
    • Lightness aynı kalır
  • LCh’nin Hue açısı HSL’deki Hue’ya benzer ama aynı değildir
    • HSL/HSV, üç toplamsal ana renk olan kırmızı, yeşil ve maviyi H=0, 120, 240° noktalarına yerleştirir
    • LCh ise kırmızı, sarı, yeşil ve maviyi h=0, 90, 180, 270° noktalarına yerleştirir
  • HCL veya LCh(uv) adlı benzer bir renk uzayı da vardır; bu uzayda Chroma, LCh(ab)’den farklı olarak 0 ile 100 arasında daha eşit bir ölçeğe sahiptir

LCh’de renk ölçekleri nasıl oluşturulur?

  • LCh, HSL/HSV’nin aksine bir silindire sığsa da silindiri tamamen doldurmaz
  • Lightness, Chroma ve Hue’nun bazı kombinasyonları var olamayacak renkler üretir
    • Örneğin koyu ve yüksek doygunluklu sarı diye bir renk yoktur
  • Lightness ölçeğinde siyah ve beyaza yaklaştıkça insanların ayırt edebileceği renk sayısı azalır
  • Gerçek ekranlar da görülebilen tüm renkleri gösteremez
    • sRGB renk gamı tipik ekranları temsil eder ve LCh renk uzayının yalnızca yaklaşık ⅓’ünü kapsar
    • CSS de en azından şu an için bu aralıkla sınırlıdır
  • HSL’de Saturation 100 ve Lightness 50 olan renk ölçeğine LCh açısından bakıldığında, sarı en parlak, mavi ise en koyu görünür
    • Yeşil, maviden neredeyse üç kat daha parlak ve kırmızıdan da yaklaşık iki kat daha parlaktır
  • Aynı ölçek LCh’de aynı Lightness düzeylerinde yeniden kurulduğunda, renklerin parlaklığı görsel olarak daha tutarlı olur
    • Chroma değişebildiği için bazı renkler diğerlerinden daha doygun olabilir
    • Bildirim ve uyarı renklerinin temel metin renginden daha doygun olması istenebilir; bu nedenle bu fark, renk sistemlerinde yararlı olabilir
  • Chroma da daha tutarlı ayarlandığında, sınırlı sRGB renk uzayı içinde bile daha yumuşak bir ölçek oluşturulabilir

Tasarım araçlarının sınırlamaları ve Accessible Palette

  • Şu anda Figma, Sketch ve Adobe XD, CIELAB veya LCh desteklemiyor
  • Figma için LCH color picker ve Chromatic eklentileri var, ancak esnek bir renk sistemi kurmak için yeterli olmadılar
  • Gereken araç üç koşulu karşılamalıydı
    • Renk varyasyonları oluştururken parlaklık tutarlılığını korumalı
    • Kademeler arasındaki kontrast oranını kontrol edebilmeli
    • Mevcut marka renklerini kabul edecek kadar esnek olmalı
  • LCh desteği güçlü olan Chroma.js kütüphanesi keşfedildikten sonra, kodla yeni paletler üreten basit bir araç geliştirildi
  • İç kullanım ve bazı tanıdıklarla paylaşımın ardından bu araç Accessible Palette uygulaması olarak yayınlandı
  • Accessible Palette, renk seviyeleri boyunca tutarlı parlaklık ve öngörülebilir kontrast oranları olan renk sistemleri oluşturmaya yarayan bir uygulamadır

Accessible Palette nasıl çalışır?

  • Başlangıç rengini ayarladığınızda veya mevcut tasarımdaki bir rengi yapıştırdığınızda, araç o rengin Chroma ve Hue değerlerini kullanarak farklı Lightness kademelerinden oluşan bir ölçek hesaplar
  • Lightness tamamen özelleştirilebilir ve hem açık hem koyu paletlerde kullanılabilir
    • Mevcut marka renklerini kapsayacak şekilde ince ayar yapılabilir
    • Postmark, eski palette en sık kullanılan sarı #FFDE00, mavi #007DCC ve yeşil #4FC47F renklerini korumak istedi
    • Bu renklerin Lightness değerleri olan 88.6, 75.2 ve 50.6 sırasıyla 200, 400 ve 600 seviyelerinin parlaklığı olarak kullanıldı
  • Kontrast oranı, Lightness’a göre değişir ve her seviye için hem WCAG 2.1’in önerdiği yöntemle hem de WCAG 3.0 Working Draft’taki yeni algoritmayla hesaplanır
    • Varsayılan olarak tüm renklerin kontrastı beyaz arka plana göre ölçülür
    • İstenilen renk örneği seçilerek kontrast oranı o renge göre ölçülebilir
  • Seviyeler RGB veya CIELAB renk uzayı kullanılarak üretilebilir
    • Bazı durumlarda sonuçlar değişebilir; bu yüzden denemeye değerdir
    • Postmark renk sisteminde CIELAB kullanımı, açık kırmızılardaki morumsu tonu azalttı ama mavilerde bu tonu artırdı
  • Bazı renkler, tüm aralık boyunca Hue düzeltmesi gerektirebilir
    • Açık sarı, koyulaştıkça yeşilimsi bir tona kayar
    • Bunu biraz daha turuncuya yaklaştırmak için negatif Hue düzeltmesi kullanılır
  • Uygulama, kullanım sırasında URL’yi güncelleyerek değişiklikleri kaydeder
    • Böylece ekiple paylaşılabilir veya daha sonra başvurmak üzere Figma kütüphanesine ve CSS renk değişkenleri dosyasına eklenebilir
  • Örnek paletler arasında yeni Postmark color palette, Google’s Material Design, TailwindCSS tabanlı paletler bulunur
    • Bu örnekler, orijinallerin birebir kopyası değil; özgün renklerden ve parlaklık kademelerinden ilham alan alternatiflerdir

Kontrast oranı hesaplama ve WCAG

  • Accessible Palette’in iki farklı kontrast oranı göstermesinin nedeni, WCAG 2.1 yönteminin sınırlamaları olmasıdır
  • WCAG 2.1, kontrast oranını ön plan renginin parlaklığını arka plan renginin parlaklığına bölerek hesaplar
  • Bu formül doğrusal bir tepki verir, ancak insanlar açık renkler arasındaki kontrastı koyu renkler arasındaki kontrasttan daha yüksek algılar
  • Gerçek örneklerde, WCAG 2.1 önerilerini karşılayan bir örneğin, “yetersiz” kontrast oranına sahip olarak işaretlenen bir örnekten daha zor okunabildiği durumlar olabilir
  • W3C bu sorunun farkındadır ve Andrew Somers 2019’da açık bir tartışma başlattı
  • Andrew Somers’ın önerdiği yeni çalışma algoritması, WCAG 3 Working Draft’ın bir parçası haline geldi; ayrıca APCA Contrast Calculator da geliştirildi
  • APCA, Advanced Perceptual Contrast Algorithm kısaltmasıdır; algısal olarak daha doğrudur ve yazı tipi boyutu ile kalınlığını da dikkate alır
  • Accessible Palette, APCA kullanır ve okunabilir metin için önerilen minimum seviye olarak 60 puanı benimser
    • Bu, WCAG 2.1’in mevcut 4.5:1 kontrast önerisine benzer bir eşiğe karşılık gelir
  • WCAG 2.1 kontrast oranı tamamen işe yaramaz değildir
    • Orta aralıktaki renklerde hâlâ oldukça doğru sonuçlar verir
    • Ancak genel olarak yeni algoritma büyük bir iyileştirmedir
  • WCAG 3 yöntemi henüz bir Working Draft olduğu için zamanla değişebilir
  • Hem mevcut yönergelere uymayı hem de gelecekteki değişimlere hazırlıklı olmayı istiyorsanız, renk sistemlerini oluştururken her iki kılavuzu da birlikte göz önünde bulundurmak en iyisidir

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-30
Hacker News yorumları

  • Tipik ekran ve baskı sistemlerinde doygun kırmızı ve mavinin aslında yeşilden daha koyu kabul edilmesi gerekir.
    Renk uzayına göre kesin formül değişse de Grayscale = 0.299R + 0.587G + 0.114B sıkça alıntılanır; bu durumda en parlak saf kırmızı yaklaşık %30, saf mavi ise %11 parlaklıktadır, bu yüzden çoğu durumda parlak kırmızı neredeyse bir çelişkidir.
    Bu tür renkleri kullanabilirsiniz, ama her zaman koyu görünmek zorundadırlar; yalnızca kontrast kurallarını uygulamak erişilebilirliği sağlayabilir, ancak iyi görünen sonuçlar da istiyorsanız yazıda ele alınan teknik çok daha avantajlıdır.
    https://en.wikipedia.org/wiki/Anaglyph_3D gibi kırmızı-camgöbeği stereoskopik fotoğraflar oluştururken de ağaçlar ve çimenler yeşil olsa da aslında kırmızı bileşenleri fazla olduğu için kanal dengesi iyidir; bu sayede hem derinlik hissi hem de renk iyi çıkar.
    Referans: https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • NTSC yayın güvenli aralığı günlerini ve kırmızıyı fazla seven müşterileri hatırlatıyor.
      Güzel bir kırmızı artwork'ün TV'de hiç de güzel görünmeyeceğini açıklamak her zaman zordu; yayın içinse özellikle daha da zordu.
      Yayın için olmasa bile spesifikasyon dışı kırmızılar birkaç kare sonrasına kadar iz bırakır, boğazı kesilmiş gibi yayılmış görünebilirdi.
    • Burada yanlış olan birkaç şey var.
      Yanıtları okuduysan cevap verirsen birkaç noktayı daha net açıklamaya çalışırım.

  • Gerçekten de WCAG 2.1 önerilen kriterlerini karşılayan örneğin, “yetersiz” kontrast oranına sahip örnekten daha zor okunması uzun zamandır gözüme batıyordu.
    “Erişilebilirlik yönergeleri” formülünün tam ters etki üretmesine rağmen neden standartlaştırıldığını merak ediyorum.

    • Kontrast erişilebilirliğinde en yaygın kullanılan algoritma ve yönergelerin hakemli bir dayanağının olmaması biraz üzücü.
      2.1 için de böyle, gelecek standart için de aynı; bu kadar etkili bir alansa sektörün daha titiz araştırmaları desteklemesini isterdim.
    • W3C/WCAG içinde kontrast değerlendirme formülünü değiştirmeye yönelik bir hareket olduğunu hatırlıyorum.
      Belki de sadece böyle bir talep vardı ve henüz resmen benimsenmemiş olabilir.

  • Bu konuda gördüğüm en iyi yazı https://www.handprint.com/HP/WCL/color1.html.
    Aşırı uzun bir yazı, bir gününüzü ayırmaya hazır olmanız gerekir.
    Şaşırabilirsiniz ama ClickHouse'ta logları güzel renklendirirken de bu yazıdaki bazı fikirleri kullanıyoruz: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • Bu ANSI renklerini RGB'ye dönüştürmenin somut yolunu bulmak zordu; aslında bunlar sadece renk isteği gibi görünüyor ve terminal ayarlarına bağlı.
      Kodda ayarlanan her mesaj türü için beklenen RGB değerlerinin ne olduğunu paylaşabilir misiniz, merak ediyorum.

  • Figma'nın Config konferansında Eugene ile tanıştım; tasarımcılara buna benzer pek çok pratik ipucu verdi, gerçekten nazik ve tasarım ile erişilebilirliğe gönülden bağlı biriydi.
    Bu yazıda özellikle övmek istediğim şey APCA; WCAG 2'nin renk kontrast algoritmasının yerini alma olasılığı yüksek.
    Figma içindeki erişilebilirlik yenilemesinde de APCA kullandık ve bu sayede nihai sonuç çok daha iyi oldu.
    Eugene, WCAG 2'nin başarısız olduğu örnekleri iyi gösteriyor; biz de pratikte bu tür durumlarla sürekli karşılaştık.
    Temel tavsiye, renkleri doğru ayarlamanın gerçekten zor olduğudur.
    Araçlar yardımcı olur, ama bir noktada gözlerinize güvenmeniz gerekir.
    Sonuçta bu araçlar gözün rengi görme biçimini matematiksel olarak yaklaşıklar; nihai ölçüt algoritma değil, insan gözüdür.
    Araçların veya algoritmaların doğru olmayan sonuçlar verdiği noktalarda ayarlama yapmak ya da temele dönmek daha iyidir.

    • Figma içindeki erişilebilirlik yenilemesinde APCA kullandığınız kısmı biraz daha ayrıntılı anlatabilir misiniz?
      Sadece APCA kullanıp WCAG 2 renk kontrast algoritmasının kontrast yetersiz diye işaretlediği şeyleri yok saydığınız anlamına mı geliyor, öğrenmek istiyorum.
    • Kırmızı-yeşil renk körüyüm; Figma'nın varsayılan erişilebilirliği yeterince iyi olduğu için ayrıca erişilebilirlik ayarı yapmayı hiç düşünmedim.
      İyi iş çıkarmışsınız.

  • HCT'yi de tanıtmak isterim
    Material You'yu mümkün kılmak için yapılmış bir renk uzayı; burada bahsedilen parlaklık ölçümünü modern renk bilimi renk uzaylarıyla birleştiriyor
    LAB/LCH 1976'da ortaya çıkmıştı
    Tasarımı daha sezgisel hâle getiriyor; bilmeniz gereken tek şey, T farkı 40 olduğunda düğmeler için WCAG kriterini, 50 olduğunda metin kriterini karşıladığı

    • İlginç
      HCT'nin https://www.hsluv.org/comparison/ ile nasıl karşılaştırıldığını merak ediyorum
      HCT'ye benzer şekilde burada da L farkı, kontrast renk seçmeyi kolaylaştırıyor
      Aynı bağlamda https://www.myndex.com/APCA/ ve bunun standart hâline geldiğinde yaklaşımın nasıl olacağı hakkında da düşüncelerinizi merak ediyorum
      İki renk arasındaki kontrast değeri, hangi rengin ön plan hangisinin arka plan olduğuna göre değiştiği için, artık yalnızca T farkını karşılaştırmanın yeterli olmayacağını düşünüyorum
    • HCT'yi öğrenmek için iyi kaynaklar olup olmadığını merak ediyorum
      Örneğin bir uygulamada kırmızı, sarı, mavi, turuncu, yeşil, mor; yani 3 ana renk ve 3 tamamlayıcı renge karşılık gelen 6 renk gerektiğini varsayalım
      Tam olarak hangi renkler oldukları çok önemli değil ama bu 6 rengin bir ölçüde ayırt edilebilir olmasını, parlaklıklarının ve belki doygunluklarının da benzer şekilde ayarlanmasını istiyorsak ne yapmalıyız
      Sarı çok parlak, mavi ise çok koyu olduğundan kesin bir yanıt yok gibi; bir yaklaşık değere ulaşmak gerekecek
      Böyle bir şeyi öğrenmek için araç veya eğitim olup olmadığını merak ediyorum
    • Açık bir spesifikasyonun bir yerde olup olmadığını merak ediyorum
      Bulabildiğim tek şey GitHub'daki material-color-utilities koduydu
      Koda bakınca hesaplamalar OkLab'den çok daha karmaşık görünüyor; özellikle de HCT'den RGB'ye giden yön böyle görünüyor

  • Yazıda oklab/oklch'nin atlanmış olmasının yanı sıra, web/CSS'in yalnızca sRGB desteklediği iddiası da yanlış
    CSS color() fonksiyonu birden fazla renk uzayını destekliyor

    • Yazarım
      Bu yazı 2 yıl önce yayımlandı ve araç üzerinde çalışmaya başladığımda OkLCH spesifikasyonu henüz çıkmamıştı
      Şimdi olsa LCH yerine OkLCH'yi seçerdim, çünkü LCH'nin bazı sorunlarını çözüyor
    • CSS Color Module Level 4 hâlâ öneri taslağı aşamasında
      Burada “destek” daha doğru ifadeyle “Microsoft Edge(chromium) ve Pale Moon(goanna) hariç destek”e yakın
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • oklab ve çeşitli LAB türevi renk uzaylarını doğrudan kullandım; Oklab basit hesaplamalarla kesip kullanmak için harika
    • Oklch üzerine kurulmuş bir renk modeli de var
      Ancak parlaklık yerine APCA'nın, yani WCAG 3'ün kontrast oranını kullanıyor: https://github.com/antiflasher/apcach

  • oklab, LCh'den daha iyi bir alternatif olabilir
    https://bottosson.github.io/posts/oklab/

    • Başlangıçtaki varsayımdan epey uzaklaşan yönleri var
      Parlaklık kanalı diğer tüm renk uzaylarının tersine çevrilmiş durumda ve L'nin LCH ya da LAB'deki L ile hiçbir ilgisi yok
      Başarısı, bir bakıma düşünsel yoksullaşmayı da artırdı
      İlk blog yazısında düzeltilmesi gereken çok şey var; CAM16 UCS kullanılmış gradyanlarla doğruluk iddia etmeye başladığı noktadan itibaren mantık ciddi biçimde sapıyor
    • Bu playground, LCh ve OKLAB dâhil 16 renk uzayını şaşırtıcı derecede iyi görselleştiriyor: https://color-playground.ardov.me/spaces-3d
    • Kusursuz değil ama bazı durumlarda renk enterpolasyonu için oklab ve oklch kullanıyorum; sonuçlar RGB veya HSL'de enterpolasyon yapmaktan görsel olarak çok daha tatmin edici oldu
    • Kendi sitemde OkLab'i memnuniyetle kullanıyorum; daha önce kullandığım CIELAB tabanlı renk paletine göre gözü çok daha az yoruyor

  • CIELAB sayıları algısal değişime dayanıyorsa erişilebilirlikle nasıl etkileşiyor, merak ediyorum
    Bu tür algı formüllerinin standart görme yetisi temel alınarak yapılmış olma ihtimalinden endişe etmeli miyiz
    Renk görme bozukluğu türüne göre değişebilir mi, yoksa bu öyle bir mesele değil mi, onu da merak ediyorum
    Grafikleri olabildiğince erişilebilir hâle getirmeye çalışıyorum ama renk konusunda hiç eğitim almadım; bu yüzden yalnızca tavsiyeleri uyguluyorum, kendim türetemiyorum
    Dolayısıyla bunun aptalca bir soru olma ihtimali de gayet var

    • Bu alanda çalıştım
      Kontrast doğrusal olmayan biçimde değişir
      Simülasyonlar oldukça kolay uygulanabilir; Machado ve diğer yazarların simülasyonu yalnızca bir matris dönüşümüdür

  • Bu yazı açıklamayı daha aşağıda veriyor, ancak WCAG 3 taslak standardının okunabilir kontrast testi olan APCA Contrast, bazı renklerde WCAG 2.1 kontrast oranından çok daha adil
    Algısal kontrastın arkasındaki renk teorisini okunaklı anlatan yazı: https://www.smashingmagazine.com/2022/09/realities-myths-con...
    APCA'yı kısa ve öz açıklayan yazı: https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCA iyi çalışıyor, ancak lisansı çok tuhaf ve kısıtlayıcı
      Bir şeyde kullanmadan önce o kısmı ayrıntılı inceleyip gerçekten kullanıp kullanamayacağınıza karar vermek iyi olur

  • Kod nerede?
    Bir web formu değil, herhangi bir yazılımda kullanılabilecek bir algoritmaya ihtiyaç var