CSS'te tarayıcının zıt renkleri otomatik seçme yöntemi

 (webkit.org)
2 puan yazan GN⁺ 2025-05-19 | 1 yorum | WhatsApp'ta paylaş
  • contrast-color() işlevi kullanıldığında, düğmeler gibi farklı arka plan renklerine göre tarayıcı siyah veya beyaz yazı rengini otomatik olarak seçer
  • Büyük ölçekli projelerde bile metin okunabilirliğini korumak kolaylaşır ve bakım verimliliği artar
  • Şu anda Safari Technology Preview, resmi WCAG 2 algoritmasını kullanıyor; ancak bu, gerçek insan algısıyla örtüşmeyebilir
  • Yeni nesil APCA algoritmasının benimsenmesi, WCAG 3 geliştirme sürecinde tartışılıyor ve daha iyi bir parlaklık kontrastı değerlendirmesi vadediyor
  • Basit siyah-beyaz kontrastın ötesinde, gelecekte çeşitli renk seçenekleri ve erişilebilirlik iyileştirmeleri eklenmesi bekleniyor

Genel bakış ve contrast-color()'ın ortaya çıkış nedeni

  • Birçok düğme veya arayüz bileşeninde çeşitli arka plan renklerinin kullanıldığı tasarımlarda yazı rengi (metin rengi) okunabilirliği önemlidir
  • Daha önce geliştiricilerin arka plan rengi ile metin rengini tek tek doğru biçimde eşleştirmesi gerekiyordu; ancak büyük projelerde yönetim karmaşıklığı ve hata riski yüksektir
  • contrast-color() CSS işlevi ile geliştirici yalnızca arka plan rengini belirtir ve tarayıcı siyah veya beyaz yazı renginden daha yüksek kontrasta sahip olanı otomatik seçer
  • Bu yaklaşım, bakım ve tasarım çalışmalarının verimliliğini büyük ölçüde artırır
  • Basitçe color: contrast-color(renk); şeklinde tanımlanarak kullanılabilir

contrast-color() kullanım örneği

  • Düğmenin arka plan rengi değişkenine istenen renk atanır ve metin rengi için contrast-color() kullanılarak zıt siyah-beyaz seçeneklerinden biri otomatik seçilir
  • Tek seferde yalnızca tek bir rengi yönetmek yeterli olduğundan, tasarım politikasındaki değişikliklerde veya dark/light mode desteğinde bakım kolaylaşır
button {
  background-color: var(--button-color);
  color: contrast-color(var(--button-color));
}
  • Relative Color Syntax kullanılırsa hover durumu için de arka plan ve metin renkleri tutarlı biçimde yönetilebilir

Erişilebilirlik noktaları ve algoritma açıklaması

  • contrast-color() kullanımı tüm erişilebilirlik sorunlarını otomatik olarak çözmez
  • Orta parlaklıktaki bazı arka plan renklerinde, hem siyah hem de beyaz gerekli eşiği karşılamayabilir
  • Şu anda Safari Technology Preview'da kullanılan WCAG 2 algoritması, resmi web erişilebilirliği standardıdır
    • Bu algoritma kontrast oranına göre seçim yapar, ancak bazen gözle algılanan parlaklık kontrastıyla uyuşmayan sonuçlar üretebilir
  • Örneğin #317CFF mavi arka planında hesaplamaya göre siyah daha yüksek kontrastlı görünse de, gerçekte beyaz daha okunaklıdır
  • Buna yönelik eleştiriler ve iyileştirme talepleri doğrultusunda, yeni nesil erişilebilirlik standardı (WCAG 3) içinde daha gelişmiş APCA (Accessible Perceptual Contrast Algorithm) kullanımına dair tartışmalar sürüyor
  • APCA, renk kontrastını insan algısının özelliklerini yansıtarak hesapladığı için gerçek okunabilirliği daha iyi güvence altına alır

Gerçek kullanımda yeterli kontrast sağlama

  • CSS'teki @media (prefers-contrast: more) medya sorgusu kullanılarak, kullanıcının erişilebilirlik tercihine göre ek yüksek kontrast stilleri uygulanabilir
@media (prefers-contrast: more) {
  /* 더 높은 대조 스타일 정의 */
}
  • Örneğin marka ana renginin #2DAD4E gibi açık bir yeşil olduğu durumda, gelecekte contrast-color() beyazı seçse bile küçük metinlerde kontrast yine de yetersiz kalabilir
  • APCA algoritması uygulandığında, yazı tipi boyutu ve kalınlığına göre gerekli minimum kontrast eşiği ayrıntılı biçimde değerlendirilebilir ve bu da pratik tasarım kararlarına yardımcı olur
    • Gerçekte 24px/400 kalınlıktaki yazı için beyaz uygundur; ancak daha ince FONT'lar veya daha küçük yazılar için daha koyu bir arka plan önerilir
  • Tasarım ekipleri light/dark mode, prefers-contrast tercihleri gibi koşulları dikkate alarak her duruma uygun renk paletini değişkenlerle kolayca yönetebilir
--button-color: #2DAD4E;

@media (prefers-contrast: more) {
  @media (prefers-color-scheme: light) {
    --button-color: #419543;
  }
  @media (prefers-color-scheme: dark) {
    --button-color: #77CA8B;
  }
}
button {
  background-color: var(--button-color);
  color: contrast-color(var(--button-color));
  font-size: 1.5rem;
  font-weight: 500;
}
  • Özünde contrast-color() sayesinde yalnızca arka plan rengi merkez alınarak renk yönetimi yapılır; metin rengi kontrast eşleri ise tarayıcı tarafından otomatik oluşturulur

Siyah ve beyazın ötesi

  • Mevcut contrast-color() yalnızca siyah ve beyaz arasında seçim yapıyor, ancak ilk sürümlerde birden fazla renk arasından seçim de mümkündü
  • CSS Working Group, gelecekteki algoritma değişiklikleri ve uyumluluk için önce basit sürümü (yalnızca siyah-beyaz seçimi) sunuyor; ileride ise kullanıcı tanımlı renk seçenekleri ve istenen minimum kontrast eşiğinin belirlenmesi gibi genişletmeler planlanıyor
  • Basit ihtiyaçlar için şimdiden yeterince kullanışlıdır
  • Bu işlev yalnızca arka plan rengiyle sınırlı olmayıp kenarlıklar ve diğer görsel öğeler için de çeşitli şekillerde kullanılabilir

Sonuç ve ek bilgiler

  • Yeni nesil erişilebilirlik standardı yansıtıldıktan sonra, contrast-color() algoritmasını değiştirerek daha iyi otomatik kontrast seçimi sunacaktır
  • O zamana kadar özellikle temel arka plan renginin belirgin biçimde açık veya koyu olduğu durumlarda oldukça faydalıdır
  • Metin dışındaki çeşitli UI öğelerine de geniş ölçekte uygulanabilir
  • APCA (Accessible Perceptual Contrast Algorithm) gibi güncel erişilebilirlik algoritmalarını takip etmeyi sürdürmek yararlıdır

Kaynaklar

  • APCA'nın resmi belgeleri ve APCA Contrast Calculator üzerinden çeşitli örnekler ve değerlendirme ölçütleri incelenebilir
  • CSSWG içinde contrast-color işlevi ile ilgili standardizasyon tartışmaları sürüyor
  • WebKit veya ilgili topluluklarda görüş paylaşımı ve geri bildirime katılım mümkün

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-19
Hacker News yorumu

  • Bu sorunu çözmek için, tasarım aşamasında basit ve öngörülebilir WCAG/APCA kontrast oranlarına sahip renk çiftleri üreten bir palet aracı geliştiriyorum. https://www.inclusivecolors.com/ masaüstünde daha fazla özellik sunuyor. Yöntemlerden biri, 100 (açık renk) ile 900 (koyu renk) arasında derecelendirilmiş renk örnekleri üretmek ve örneğin 700 seviyesindeki bir rengin 100 seviyesiyle, 800 seviyesinin de 200 seviyesiyle belirgin kontrast oluşturacak şekilde parlaklığı ayarlamak. Böylece red-700 vs gray-100, green-800 vs yellow-200 gibi eşleşmelerin parlaklık kontrolü yapmadan da güvenilir biçimde kontrast sağladığını bilebilirsiniz. Contrast menüsünde, APCA algoritmasının WCAG'ye kıyasla ne kadar daha katı olduğunu, özellikle de açık zemin üzerindeki koyu metinlerde ne kadar talepkar davrandığını inceleyebilirsiniz. Koyu tema için neden WCAG kullanılmaması gerektiğinin sebebi de bu. Examples menüsünde Tailwind ve IBM Carbon palet örneklerine bakarsanız, her seviyede doygunluk ve tonun (Hue) doğrusal olmayan biçimde değiştiğini görürsünüz; bu yüzden yalnızca siyah ya da beyaz arasından en iyi kontrastı seçmek kolay olsa da, markalamanın önemli olduğu paletlerde yalnızca parlaklık ayarıyla renk üretmek daha karmaşık bir problemdir.

  • lch kullanarak benzer bir şey yapmanın bir yolu var

     --text: lch(from var(--bg) calc((49.44 - l) * infinity) 0 0);

    Kaynak: https://til.jakelazaroff.com/css/…

    • LCH de harika ama OKLCH daha da iyi. https://evilmartians.com/chronicles/oklch-in-css-why-quit-rgb-hsl/… Bu yazı düşüncemi tamamen değiştiren şey oldu. Gerçekten müthiş bir araç. Şaşırtıcı biçimde tasarımcı arkadaşlarımın hiçbiri OKLCH'yi bilmiyordu. Bu yaklaşım birçok sorunu çözüyor.

    • CSS'te parametreleri böyle bir callback ile alabilen bir fonksiyonu ilk kez görüyorum. Gerçekten ilginç bir kavram. lch dışında bu tarz başka fonksiyonlar var mı merak ediyorum.

    • Lea Verou'nun buna benzer geçici çözümler hakkında yazdığı güzel bir yazı var. https://lea.verou.me/blog/2024/contrast-color/

  • Bu yazı, otomatik kontrast seçimi yaklaşımının artı ve eksilerine dair mükemmel bir özet. Basit bir site yapıyorsanız bu yöntem, doğru kontrastı sağlamanın kolay ve basit bir yolu.
    Ama büyük ölçekte WCAG uyumluluğu gerekiyorsa bundan kaçınır, gerçek bir semantik biçimlendirme token katmanı kullanırdım. Semantik token'lar geliştirme hızını artırır ve yalnızca siyah/beyaz geçişine göre görsel olarak daha hoş kontrastlar garanti edebilir. Semantik token katmanının güzel yanı, tema oluşturmayı çok kolaylaştırması; böylece açık/koyu tema neredeyse ek maliyet olmadan mümkün olur. Marka renkleriniz WCAG2'ye takılıyorsa, uyumluluk kazanırken daha iyi kontrast sağlamak için ayrı bir WCAG2/APCA teması bile oluşturabilirsiniz.
    Ben Figma'da variables/tokens akışından sorumluyum ve Figma ile Atlassian'ın dark mode uygulamalarında da yer aldım. Token'lar, temalar ve erişilebilir renkler hakkında sorunuz varsa memnuniyetle yanıtlarım.

    • Semantik token'ın tam olarak ne olduğunu merak ediyorum. Bu tür özellikler olduğu için üzerinde çalıştığım büyük projede göreli renk hesaplamaları ve kontrast renkleri için CSS-in-JS kullanmıştım. Bu tekniklerin yakında yaygın biçimde benimseneceğini umuyorum.

    • Son 2/3 kısmı fazla geveze ve bilgiççe geliyor. Şirket sitesinde/uygulamasında bu tür bir fonksiyona güvenmek riskli olur çünkü ortaya çıkan renkler öngörülemez. WebKit bir hatayı düzelttiğinde renk sonucu değişebilir.

  • Kontrast renginin tarayıcı üreticisinin takdirine göre belirlenmesinin her zaman doğru ya da öngörülebilir olduğuna hâlâ ikna olmuş değilim. Tüm tarayıcıların aynı sonucu üretmesini sağlayacak deterministik bir ölçüt oluşacak mı merak ediyorum. Bu fonksiyon, pratikte daha çok UX ekibinin tasarım aşamasını destekleyen bir araç gibi geliyor.

    • Makaleye göre standart, hesaplama yöntemini açıkça tanımlıyor

    • 'seçer' ifadesi bana muğlak geliyor. Aslında bir algoritma renk üretiyor

    • Linkteki APCA örnek formülündeki hata veya kafa karıştırıcı kısımları dışarıda bırakırsak, %100 doğru çalışıyor. Tam tutarlılık istiyorsanız, iki aday rengin de (hem daha açık hem daha koyu olanın) aynı anda kabul edilebilir olduğu durumlarda arka plan renginin parlaklığına (L*) göre, örneğin L* 60 ve üzeriyse açık olanı seçebilirsiniz. Böylece %100 tutarlılık elde edilir.

  • Büyük projelerde düğmelerin görünmez hale gelen renklere dönüşmemesini sağlamakla özellikle uğraşmanın zor olduğundan söz ediliyor; örneğin koyu bir düğmede siyah metin gibi. Ama acaba yayına çıkmadan önce tüm düğmeleri tek tek kontrol etmek mümkün olmaz mı diye düşündüm. Ya da ekip genelinde, koyu düğmelerde siyah metnin kesinlikle yasak olduğuna dair bir ön kural koyup paylaşabilirsiniz. Algısal kontrast ile matematiksel kontrast arasındaki fark ilginç geldi. Bunu iş akışıma uygulayacağım.

    • Pratikte tüm düğmeleri tek tek kontrol etmek mümkün ama bunu bu şekilde yaparsanız sürüm öncesi regresyon testi haftalar, hatta bazen aylar sürebilir. Büyük projelerde düğme sayısı kolayca binleri aşar ve bazı düğmeler yalnızca belirli seçenek kombinasyonlarında ya da belirli iş akışlarında görünür.

    • APCA'ya bakarsanız algıya dayalı kontrast hesabı yapabilirsiniz

  • Sistem renkleri popülerken düğme stilleri yazdığım olmuştu. Görsel olarak güzel duruyordu ama kontrast oranının ne olacağını bilemiyordum; bu yüzden biri JavaScript ile getComputedStyle üzerinden bunu hesaplıyordu. Kontrast kötü çıkarsa ikinci bir renk adayını kullanıyorduk, mecbur kalırsak da text-shadow ile metnin etrafındaki kontrast etkisini güçlendiriyorduk. Hesap yöntemini unuttum ama üç RGB değerinin ortalamasını alıp karşılaştırmak yeterli olabilir gibi geliyor. Mavide ortalama düşük olacağı için beyaz metne öncelik verebilir.

  • En azından light/dark tema için active, focus, hover, link, visited gibi pseudo-class'lar bazında iyi renk önerileri verse güzel olurdu. Material UI buna disabled, before, after durumlarını da ekliyor.

  • Eskiden arka plan rengine göre siyah/beyaz metin seçen bir video eğitimi hazırlamıştım. Benim yöntemim basitti; rengi gri tonlamaya çevirip siyah mı beyaz mı kullanılacağına karar veriyordum. Eğlenceli bir çalışmaydı. Video hazırlama konusunda çok iyi değilim.
    https://youtu.be/tUJvE4xfTgo?si=vFlegFA_7lzijfSR (Portekizce uyarısı)

    • İlginç şekilde, başka bir yorumda tam olarak bunu yapan bir renk uzayı formülü tanıtılmıştı.
      https://news.ycombinator.com/item?id=44015990
      Video da fena görünmüyor. Kod iyi görünüyor ama Portekizce bilmediğim için içeriği değerlendiremiyorum.

  • Tüm renk şemasını zaten kendim seçiyorsam, neden düğme metni için kontrast rengini seçmenin en baştan onu da doğrudan seçmekten daha kolay olduğu sorgulanmalı. Bu özellik ancak arka plan renklerinin rastgele ve farklı farklı seçildiği, ama ön plan renginin (düğme metin rengi) seçilemediği çok uç durumlarda gerekli gibi görünüyor. Asıl sorunlu durum, görsellerin ya da çeşitli arka planların üzerindeki metinler gibi her zaman okunabilir olması gereken yerler; ama bu özellik onlara hiç çözüm sunmuyor. O yüzden ancak böyle sınırlı durumlarda işe yarayabilecek bir özellik için yeni bir fiil türetilmiş olması, işlevin de siyah/beyaz seçimiyle sınırlı kalması ve üstelik en kötü kontrast seçim algoritmasının (WCAG 2) kullanılması biraz hayal kırıklığı yaratıyor. Gerçekten etkileyici.

    • İnsanların bir aracı hiç kullanmaları gereken bir durumla karşılaşmadıkları için onu hemen değersiz sayması üzücü. Pek çok web sitesinde kullanıcılar istedikleri renkleri seçebiliyor ya da yükledikleri içerikten renk çıkarılıyor. Erişilebilirliğe önem veren siteler bu tür durumlar için otomatik kontrast hesabı yapmak zorunda kalıyor. Böyle yerleşik bir CSS özelliği gelirse temel erişilebilirliği sağlamak çok daha kolay olur. Elbette daha gelişmiş deneyimler kurmak isteyen geliştiriciler için bu hiçbir engel oluşturmaz. contrast-color npm paketi gibi daha özelleştirilebilir bir yaklaşım olsa daha da iyi olurdu ama blog yazısında da belirtildiği gibi, algoritma şimdilik ilk adım olarak yalnızca siyah/beyaz seçimiyle başladı ve ileride geliştirilmesi planlanıyor.
      Örnek: https://coolors.co/8fbfe0-7c77b9-1d8a99-0bc9cd-14fff7

    • Kontrast seçim algoritmasının zayıf olduğu eleştirisine karşılık, WCAG 2 algoritmasını izlediğini ve WCAG 3 standartlaştığında o algoritmaya kolayca geçilebileceğini açıkça belirtiyor

  • SASS, Tailwind vb. için buna benzer build-time alternatifleri olup olmadığını merak ediyorum. Bu özelliğin yaygın olarak benimsenmesi zaman alacak gibi görünüyor; ayrıca farklı platformlarda uygulamanın aynı olup olmayacağı konusunda da endişeliyim.