Algoritmik Tema Motorları: "Kontrast-renk()" ile Kendi Kendini Düzelten Renk Sistemleri Oluşturma

. HTTP Arşivi Web Almanağıyıllardır renk kontrastı hatalarını takip ediyor. Rakamlar neredeyse hiç değişmedi. Okunabilir metin renklerini hesaplamaya adanmış tasarım sistemi araçları, erişilebilirlik satırları ve tüm JavaScript kitaplıklarıyla geçen yarım on yılın ardından,Web sitelerinin %70'i 2025'te hâlâ temel WCAG kontrast kontrollerinde başarısız oluyor.WebAIM Milyondaha da kasvetli bir tablo çiziyor; 2026'da ana sayfaların %83,9'u düşük kontrastlı metin nedeniyle işaretlendi; bu oran 2025'te %79,1'di. Bu oran, bir kıyaslamada yılda belki birkaç yüzde puan artıyor ve aslında daha da artıyor.daha kötüsübaşka birinde. Bu bir ilerleme değil; bu, bu kadar temel bir şey için çalışma zamanı JavaScript'ine güvenmenin açık web'de ölçeklenemeyeceğinin kanıtıdır. Daha iyi kütüphanelere ihtiyacımız yoktu. Daha iyi bir CSS'ye ihtiyacımız vardı.

. kontrast rengi()işlevi daha iyi CSS'dir. Bir deklarasyon. Tarayıcı, sayfa boyanmadan önce stil hesaplaması sırasında kontrast matematiğini çalıştırır ve size doğru metin rengini verir. Kitaplık yok, derleme adımı yok, hidrasyon flaşı yok.

Not: Eğer çağrıldığını gördüysenizrenk kontrastı()eski makalelerde ve spesifikasyon taslaklarında —o isim değiştirildive eski sözdizimi artık hiçbir tarayıcıda çalışmıyor.

Seviye 5 versiyonu basittir. Sen ona bir renk ver. Seni geri verirsiyahveya beyaz, hangisinin girdinize karşı daha fazla kontrastı varsa.

.düğme {
  arka plan rengi: var(--marka-renk);
  renk: kontrast-renk(var(--marka-renk));
}

Değiştirmek--marka rengineon yeşiline, metin siyaha döner. Gece yarısı lacivertine değiştirin, metin beyaz olur. Temaları çalışma zamanında JavaScript aracılığıyla değiştirdiğinizde metin anında uyarlanır; olay dinleyicisi yok, yeniden hesaplama yok.

Mevcut sürüm hakkında bilmeniz gereken birkaç şey:

• Bir döndürür, bir sayı değil. Gerçek bir renk değeri elde edersiniz (siyahveya beyaz), CSS'nin renk kabul ettiği her yerde kullanabilirsiniz.
• Yalnızca siyah veya beyazşimdilik. Seviye 6 için aday renk listeleri ve hedef oranları planlanmıştır.
• Anahtar kelime yok.Eğer gördüysenizmaksimumeski blog yazılarında bu, spesifikasyondan çıkarıldı. Bunu kullanmak beyanınızı sessizce bozacaktır.
• Yukarıda belirtildiği gibi, bu işlev eskiden çağrılıyordu.renk kontrastı()erken taslaklarda. Bu isim öldüCSSWG onu yeniden adlandırdıCSS işlevlerinin döndürdükleri şeye göre adlandırıldığı kuralını takip etmek.renk karışımı()bir renk döndürür.kontrast rengi()bir renk döndürür. Eskirenk kontrastı()isim sanki bir kontrast döndürüyormuş gibi geliyorduoran(4,5 gibi bir sayı) bu yanıltıcıydı. 2021-2023 yılları arasında gösterilen herhangi bir eğitimrenk kontrastı()sözdizimi mevcut tarayıcılarda çalışmaz.

Bu işlev iki spesifikasyonda yaşar. Bu alışılmadık bir durum ve anlamaya değer.

CSS Renk Seviyesi 5tarayıcıların bugün neleri gönderdiğini tanımlar. Tek renk giriş, siyah veya beyaz çıkış. Algoritma kasıtlı olarak "UA tanımlı" olarak işaretlenmiştir; bu, dahili olarak hangi matematiğin kullanılacağına tarayıcının karar verdiği anlamına gelir. Şu anda her motor WCAG 2.x bağıl parlaklığını kullanıyor. Ancak bu "UA tanımlı" etiketi tesadüfi değil; planlı bir kaçış yolu.

APCA'yı göreceksiniz (Erişilebilir Algısal Kontrast Algoritması) bu bağlamda çokça bahsetti. APCA, yazı tipi ağırlığını, uzaysal frekansı ve ortam ışığını hesaba katarak insan gözünün kontrastı gerçekte nasıl algıladığını modeller; bu, WCAG 2.x formülüne göre gerçek bir gelişmedir. Kilitlenmeyerek“WCAG 2.x kullan”Düzey 5 spesifikasyonuna, tarayıcı satıcılarıolabilirdaha sonra mevcut herhangi bir kodu bozmadan APCA'ya geçiş yapın. Spesifikasyon bir ürünle birlikte gönderilmiş olsaydıwcag2()anahtar kelimeyi varsayılan olarak kullansaydınız, onu kullanan her site kalıcı olarak eski matematiğe takılıp kalırdı.

Ancak APCA'nın geleceği, sanıldığından çok daha az kesin. Adrian Roselli'nin "Nisan 2026 itibarıyla WCAG3 Kontrastımevcut durumu net bir şekilde ortaya koyuyor: APCA, WCAG 3 çalışma taslağından çıkarıldı2023'ün ortasındaYeterli Çalışma Grubu desteğini alamadıktan sonra. WCAG 3 spesifikasyonu şu anda kontrast algoritmasının şu şekilde olduğunu söylüyor:"henüz belirlenmedi"ve standardın kendisi2030 veya sonrasına kadar tamamlanamayabilir. Roselli deMayıs 2024'te bir Chromium sorunu bildirdik"Gelişmiş Algısal Kontrast Algoritması" deneme bayrağının DevTools'tan tamamen kaldırılmasını talep ederek, uygulamanın güncelliğini yitirdiğini ve geliştiricilerin APCA'nın gerçekte olduğundan daha ileri veya daha resmi olduğunu düşünmeleri konusunda yanıltıcı olma riskini taşıdığını öne sürüyor. Bu konu hâlâ açık.

Bunların hiçbiri APCA'nın öldüğü anlamına gelmiyor. Arkasındaki araştırma hakemli ve kapsamlıdır ve yaratıcısıkaydettiAPCA yönergelerini geçen renklerin çoğu durumda WCAG 2 minimumlarını büyük ölçüde aştığı görülüyor. Ancak şu anda APCA'nın WCAG 2.x'in yerini alacak algoritma olacağının garantisi yok ve bu belirsizlik bizim için önemli.kontrast rengi(). Farklı bir algoritma kazanırsa veya WCAG 3 tamamen yeni bir algoritmayı benimserse, "UA tanımlı" etiketi, tarayıcıların kodunuzu bozmadan uyum sağlayabileceği anlamına gelir. Bu aynı zamanda Seviye 6 özellikleri anlamına da gelir - aday renk listeleri, hedef oranlar,tbd-fg/tbd-bganahtar kelimelerin tümü mevcut haliyle gerçekleşebilecek veya gerçekleşmeyebilecek bir algoritma etrafında tasarlanmıştır.

CSS Renk Seviyesi 6aday renk listeleri ve hedef kontrast oranları gibi genişletilmiş sözdizimini ekler:

/* Seviye 6'nın gelecek sözdizimi — henüz gönderilmiyor */
renk: kontrast-renk(var(--bg) tbd-bg wcag2(aa), #1a1a2e, #e2e8f0, #fbbf24);

Tarayıcı her adayı soldan sağa değerlendirecek ve 4,5:1 AA eşiğini karşılayan ilk adayı seçecektir.tbd-fg ve tbd-bganahtar kelimeler, temel rengin ön plan mı yoksa arka plan mı olduğunu belirtir; bu, APCA gibi yönlü kontrast modelleri için önemlidir. APCA'nın belirsiz durumu göz önüne alındığında bu durum iki kat daha fazla Çalışma Taslağı bölgesidir. Şimdilik Seviye 5 sürümünü kullanın.

Bu, çoğu yeni CSS özelliğinden daha iyi durumda. Üç ana motor da onu kararlı sürümlerle piyasaya sürdü:Krom 147(Nisan 2026),Firefox146, VeSafari 26.0. UlaştıTemel Yeni MevcutNisan 2026'daki durum. Kontrol edinköpektam sürüm matrisi için. Her üç motor da Web Platformu Testlerini geçtikontrast rengi()Bu, uç durumların (örneğin, bağları bozma mantığı, renk alanı dönüşümü, sözdizimi ayrıştırma) tarayıcılar arasında aynı şekilde davrandığı anlamına gelir.

Caniuse'daki ham küresel destek yüzdesi düşük görünüyor ancak bu çoğunlukla kurumsal tarayıcıları ve hiçbir zaman güncelleme yapmayan kişileri yansıtıyor. Bunu okuyorsanız, tarayıcınız neredeyse kesinlikle bunu zaten destekliyordur.

Aşamalı iyileştirme kullanımı basittir@destekler:

.kart {
  arka plan: var(--bg);
  renk: #fff;
  metin gölgesi: 0 0 4px rgb(0 0 0 / 0,8);
}

@destekler (renk: kontrast rengi(kırmızı)) {
  .kart {
    renk: kontrast-renk(var(--bg));
    metin gölgesi: yok;
  }
}

Daha eski tarayıcılar, okunabilirlik için koyu gölgeli beyaz metinlere sahiptir. Destekleyen tarayıcılar yerel hesaplamayı alır. Kimse kırık metni görmüyor.

Dikkat edilmesi gereken bir şey var: Otomatik erişilebilirlik tarayıcıları (Deniz Feneri, Axe vb.)metin gölgesi. Sadece hesaplananlara bakıyorlarrenkaykırıarka plan rengi. Dolayısıyla, gölge metni insan gözü için mükemmel bir şekilde okunabilir hale getirse bile, geri dönüş CI/CD işlem hatlarında kontrast hatası olarak işaretlenmeye devam edecektir. Ekibiniz otomatikleştirilmiş her yıl kontroller yürütüyorsa söz konusu kuralı izin verilenler listesine eklemeniz veya bayrağın neden yanlış pozitif olduğunu açıklayan bir yorum eklemeniz gerekebilir.

PostCSS hakkında bir not:

Bir eklenti var (@csstools/postcss-contrast-color-function) değerlendirenkontrast rengi()inşaat zamanında. Gibi statik renkler için çalışırkontrast rengi(#ff0000). Ancak özel bir özelliği kullandığınız anda —kontrast-renk(var(--bg))— eklenti yardımcı olamaz çünkü çalışma zamanı değerlerine erişimi yoktur. Temanız dinamikse (bunu yapmanın asıl amacı da budur), çoklu doldurmayı atlayın ve@desteklerHer gün

Algısal veya AAA Uyumluluğunu Garanti Etmez

Bu, insanları şaşırtabilir:"Kontrast işlevini kullandığım için sitem artık erişilebilirlik kontrollerinden geçiyor, değil mi?"

Matematiksel olarak? Genellikle evet. Belirli "orta tonlu" arka planlar için hem siyah hem de beyazın standart WCAG 4,5:1 AA oranını karşılayamadığı yönünde ısrarcı bir efsane vardır. Bu matematiksel olarak yanlıştır. WCAG 2.x bağıl parlaklık formülüne göre, hem saf siyahın hem de saf beyazın AA'da başarısız olduğu bir arka plan rengi kesinlikle yoktur. Biri (veya her ikisi) her zaman geçecektir.

Almak#2277d3(orta mavi). Hem siyahın hem de beyazın aslında AA'yı geçtiği (her ikisi de kabaca 4,58:1'i vurdu) matematiksel açıdan bıçak sırtında duruyor.kontrast rengi()hangisinin hafif matematiksel üstünlüğü varsa onu verecektir.

Ancak işin aslı şu: WCAG 2.x matematiği algısal kör noktaları biliyor. Aynısı#2277d3siyah metin matematiksel olarak AA'yı geçer, ancak insan gözü için okunması inanılmaz derecede zor olabilir.kontrast rengi()sana verirmatematikseluyumluluk, otomatik denetimler için harikadır ancak her zaman aynı şey değildiralgısalerişilebilirlik. (APCA'nın var olmasının ve spesifikasyonun tarayıcıların daha sonra algoritmaları değiştirmesine izin verecek şekilde tasarlanmasının nedeni tam olarak budur.)

Ayrıca, daha katı WCAG AAA standardını (7.0:1) hedefliyorsanız gerçek bir ölü bölgeyapmakvar olmak. Parlaklığı kabaca %10 ila %30 arasında olan arka planlar için ne siyah ne de beyaz 7:1'e ulaşamaz. Bu durumlarda,kontrast rengi()seni kurtaramaz; sadece sana "en az kötü" başarısızlık seçeneğini sunar.

Geçişler Anında Anlaşılır, Solmaz

Bir arka planı canlandırıyorsanızbeyazilesiyahfareyle üzerine gelindiğinde:

.btn {
  arka plan rengi: #fff;
  renk: kontrast rengi(#fff); /* siyah */
  geçiş: arka plan rengi 1'ler, renk 1'ler;
}
.btn: üzerine gelin {
  arka plan rengi: #000;
  renk: kontrast rengi(#000); /* beyaz */
}

Arka plan bir saniye içinde yumuşak bir şekilde kaybolur. Ancak Seviye 5 çıktısı birayrık değer(siyah veya beyaz), metin rengine enterpolasyon yapılamaz. Çıtır çıtır.

Ve işte görsel sonuç: snap yarı yolda gerçekleşmiyor. Bir süredir temalar oluşturuyorsanız muhtemelen eski Sass günlerinden kalma kas hafızanız vardır.hafiflik($bg) > %50. Bu, %50'nin geometrik orta nokta olduğu HSL hafifliğine dayanıyordu.

Ancak WCAG 2.x bağıl parlaklığı doğrusal olmayan bir ölçektir. WCAG formülüne göre, siyah ve beyazın arka planla aynı kontrasta sahip olduğu matematiksel kırılma noktası aslında yaklaşık %18 bağıl parlaklıkta (özellikle ~%17,9) meydana gelir.

Bu nedenle, beyazdan siyaha geçiş sırasındaki görsel davranış oldukça çarpıktır. Metin ortada kırılmaz. Animasyonun büyük çoğunluğunda siyah kalıyor, yalnızca geçişin en sonunda arka plan aşırı karanlık olduğunda beyaza dönüyor. Bu sarsıcı, geç sert bir kesim.

varsayabilirsingeçiş davranışı: izin verme-ayrıkbunu düzeltir. Değil.izin-ayrıkikili çıktının enterpolasyonunu yapamadığı için rahatsız edici görsel deneyimi düzeltmez; yalnızca hızlı yakalamanın zamanlamasını animasyon süresinin %50'sine kaydırır. Düzgün metin rengi geçişlerine ihtiyacınız varsa katmanlamanız gerekirrenk karışımı()veya crossfade'i kendiniz yönetin.

Kravat Beyaza Gidiyor

Arka plan, hem siyah hem de beyazın aynı kontrast oranlarını ürettiği mükemmel bir orta gri ise,spesifikasyonun sabit kodlanmış bir eşitlik bozucusu var: beyaz kazanır. Pratikte çok fazla bir şey değil, ancak gri paletlerde hata ayıklama yapıyorsanız ve metin beklediğiniz gibi çalışmıyorsa bunu bilmeye değer.

Degradeler ve Görüntüler Çıktı

Fonksiyon bir daire alırdeğer. Ona bir degrade veya bir geçiş yapamazsınız.url()Bölge yöneticilerini kısa mesafelerde taşıyacak, sırtı ve bacakları kuvvetli personel alınacaktır. kontrast-renk(doğrusal-gradyan(...))bir ayrıştırma hatasıdır. Arka planınız bir fotoğraf veya karmaşık bir degradeyse, yine de JavaScript'e veya kaplama metni için manuel olarak renk seçimine ihtiyacınız vardır.

Önce Şeffaf Renkler Birleştirilir

Yarı şeffaf bir renk iletin ve tarayıcı, kontrast matematiğini çalıştırmadan önce onu varsayılan opak bir tuvalle (genellikle beyaz) harmanlar. Alfa kanalınızı görmezden gelmiyor, onu birleştiriyor. Ancak işlevin, öğenin arkasında ne varsa onu "görmesini" beklerseniz sonuç sizi şaşırtabilir.

Windows Yüksek Kontrast Modu

Bir kullanıcı Windows Yüksek Kontrast'ı etkinleştirirse,zorunlu renkler: etkinmedya sorgusu devreye giriyor ve tarayıcı agresif bir şekilde yazarın tanımladığı renklerin üzerine yazıyor.kontrast rengi()boyun eğiyor —zorunlu sistem renkleribeğenmekKanvas Metintamamen devralmak. Kontrast mantığınızı geri almak için manuel medya sorguları yazmanıza gerek yoktur; tarayıcı hiyerarşiyi yönetir.

Siyah veya beyaz kulağa sınırlayıcı geliyor, ancak bu çıktıyı diğer CSS renk işlevlerine beslediğinizde, tek bir özel özellikten bütün bir bileşen paleti oluşturabilirsiniz.

Göreli Renk Sözdizimi ile Markaya Özel Kontrast

Canlı bir karttaki saf siyah metin iyi görünüyor. Mercan kartındaki saf beyaz, düz bir his verebilir. Kontrast metni çok koyu veya çok açıksa ne olur?renk tonubunun yerine arka plan rengini mi kullanıyorsunuz?

Kevin Hamer CSS-Tricks makalesinde ilgili alanı araştırdı "Diğer CSS Özellikleriyle kontrast rengine () yaklaşma”, OKLCH hafifliğini kullandı veyuvarlak()siyah/beyaz geçişine yaklaşmak içinolmadan kontrast rengi()- esas olarakoklch( turundan(1,21 - l) 0 0). Bu bir çoklu doldurma stratejisidir: henüz yerel işlevi desteklemeyen tarayıcılarda ikili açık/koyu kararının çalışmasını sağlayın. Burada yaptığımız şey farklı; bizbaşlangıçilekontrast rengi()yerel çıktısını alın ve ardından arka planın kendi tonunu enjekte ederek onu zenginleştirin:

.kart {
  --bg-hue: 260; /* İndigo */
  --bg: oklch(0,6 0,1 var(--bg-hue));
  arka plan: var(--bg);

  /* Siyah/beyaz kontrast renginden L'yi çekin,
     ancak ince renk rengini ve arka planın tonunu enjekte edin */
  renk: oklch(contrast-color(var(--bg)) l 0,05 var(--bg-hue));
}

Doğru şekildekontrast rengi()beyaza döner,ben1'dir (tam açıklık). Siyaha döndüğünde,ben0'dır. Arka planın tonunu geri çekerek ve bir miktar kroma ekleyerek, genel siyah/beyaz yerine koyu koyu çivit veya soluk buzlu çivit olarak okunan bir metin elde edersiniz. Hamer'in yaklaşımı size tarayıcı desteği olmadan siyah/beyaz kararını verir; bu, tarayıcının halihazırda vermiş olduğu kararı alır ve ona kişilik kazandırır.

Adil uyarı: Siyah/beyaz çıktının parlaklığını ve rengini ayarlayarak, sınırdaki kontrast oranını başarısız bir alana itebilirsiniz. Renkli çıktınızı göndermeden önce daima erişilebilirlik linterinden geçirin.

Ayrıca dikkate değer: Bu örnek iki çok modern özelliği zincirliyor —kontrast rengi() ve tamam(...'dan). Bunlardan herhangi biri desteklenmiyorsa bildirimin tamamı sessizce başarısız olur. Senin@desteklerbloğun her ikisini de test etmesi gerekiyor:

@destekler (renk: kontrast rengi(kırmızı)) ve (renk: oklch(kırmızıdan l c h)) {
  /* Her ikisini de kullanmak güvenlidir */
}

Yumuşatılmış Kontrastrenk karışımı()

Benzer fikir, daha basit API. Keskin siyah/beyaz çıktıyı yumuşatmak için arka plana karıştırın:

.uyarı {
  --bg: var(--alert-color);
  arka plan: var(--bg);

  /* %80 kontrast, %20 arka plan = daha yumuşak ama okunabilir */
  renk: renk karışımı(oklch cinsinden, kontrast rengi(var(--bg)) 80%, var(--bg));

  /* İnce bir kenarlık için %40 kontrast */
  kenarlık: 1 piksel katı
    color-mix(oklch olarak, kontrast-renk(var(--bg)) 40%, var(--bg));
}

Metni, kenarlığı ve potansiyeli yönlendiren tek bir özel özellikkutu gölgesiveya taslak. Değiştirmek--uyarı rengive tüm bileşen yeniden hesaplanır.

Bu model aynı zamanda şu durumlarda da işe yarar:::yer tutucuDinamik temada ortak bir sorun noktası olan metin. Yer tutucu metin okunabilir olmalı ancak görsel olarak girişin ana metninden daha yumuşak olmalıdır —renk karışımı()ilekontrast rengi()seni oraya götürür:

giriş {
  --bg: var(--input-bg);
  arka plan: var(--bg);
  renk: kontrast-renk(var(--bg));
}

giriş::yer tutucu {
  renk: renk karışımı(oklch olarak, kontrast rengi(var(--bg)) 50%, var(--bg));
}

%50mix size, girişin bulunduğu arka plana otomatik olarak uyum sağlayan, sessiz ancak okunaklı bir yer tutucu sağlar.

Temaya Duyarlı Kontrastaçık-koyu()

Sistem açık/karanlık modunu destekleyen uygulamalar için:

:kök {
  renk şeması: açık koyu;
  --surface: açık-koyu(#fff, #121212);
}

.bileşen {
  arka plan: var(--surface);
  renk: kontrast-renk(var(--surface));
}

İşletim sistemi karanlık moda geçtiğinde,--yüzeyçözer#121212, Vekontrast rengi()beyaza döner. Medya sorgusu yok, JavaScript teması tespiti yok. Tüm zincir doğal olarak çözümlenir.

Pratik getirisi: Bu kütüphanelerin her biri CSS'nin kontrast matematiğini yapamaması nedeniyle var oldu. Bunları yalnızca okunabilir metin rengi seçimi için kullanıyorsanız çalışma zamanınızdan tamamen çıkarabilirsiniz:

Karmaşık renk skalaları oluşturmak için bunlara hala ihtiyacınız olabilir, ancak okunabilirlik için kontrast kullanım durumu artık yerel olarak kapsanmaktadır.

Paket boyutunun ötesinde, gözden kaçırılması kolay bir performans açısı vardır. Bu JavaScript kitaplıkları yalnızca ağ baytlarına mal olmakla kalmaz, aynı zamanda ana iş parçacığında da çalışırlar. Bir tema her değiştiğinde veya dinamik bir arka plana sahip bir bileşen bağlandığında, JS'nizin rengi ayrıştırması, parlaklığı hesaplaması, siyah veya beyaza karar vermesi ve sonucu DOM'a geri yazması gerekir. Bu, düzen, olay işleyicileri ve uygulamanızın yaptığı diğer her şeyle rekabet eden ana iş parçacığı çalışmasıdır.kontrast rengi()tüm bunları tarayıcının yerel stil hesaplama aşamasına taşır; bu, boyamadan önce çalışan, yoğun şekilde optimize edilmiş C++'dır. Çok sayıda temalı bileşene sahip uygulamalar için bu, yanıt vermede gerçek bir farktır.

Ayrıca ortadan kaybolan ince bir hata da var:nemlendirici flaş. React veya Vue SSR uygulamalarında sunucu, HTML'yi JavaScript olmadan işler. Daha sonra istemci, kontrastı hesaplamak ve doğru metin rengini enjekte etmek için JS'yi çalıştırarak nemlendirir. İlk boyama ile hidrasyon arasında kısa bir süre olması nedeniyle metin ya görünmez ya da yanlış renktedir. Kontrastı CSS'ye taşımak bunu tamamen ortadan kaldırır; tarayıcı, JavaScript yüklenmeden önce ilk boyama sırasında doğru rengi çözer.

Bunun neyin yerini aldığına ilişkin bağlam için:

Sass dönemi.Kontrol eden bir fonksiyon yazarsınızhafiflik($bg) > %50ve derleme zamanında siyah veya beyaz olarak döndü. Statik temalar için çalıştım. Kullanıcı tarafından seçilen renkler, CMS paletleri veya karanlık mod için tamamen işe yaramaz çünkü çıktı CSS dosyasına yerleştirildi ve çalışma zamanında asla değişemez.

Değişken geçiş hack.CSS özel özellikleri gönderildiğinde insanlar yaratıcı oldu. GitHub, sorun etiketi seçici için bunun bir versiyonunu kullandı; renkleri--Rdiye soruyorlar.--Gdiye soruyorlar.--Bkanallar, içerideki Rec.709 parlaklığını hesaplıyorhesap(), negatif sonsuzlukla çarpılır ve sabitlenir0veya 1. İşe yaradı. Aynı zamanda okunamazdı, sürdürülemezdi ve bir parantez yanlış girildiğinde sessizce bozulurdu. (Kevin Hamer'ınOKLCH tabanlı yaklaşımbu soyun en zarif versiyonudur (daha temiz matematik, daha iyi algısal hizalama), ancak artık yerel olarak gönderilen bir işlev için hâlâ geçici bir çözümdür.)

kontrast rengi()tüm bu yaklaşımları tek bir işlev çağrısıyla değiştirir. Spesifikasyon, tarayıcıların temel algoritmayı yükseltmesine izin verdiği için, WCAG 2.x kontrast matematiğinin halefinin (APCA veya tamamen başka bir şey) gelmesi durumunda kodunuzun değişmesine gerek kalmayacak.

Bu%70 başarısızlık oranıhiçbir zaman geliştiricilerin kontrastı önemsemeyi reddetmesiyle ilgili değildi. Bakım ve nakliye arasındaki mesafeyle ilgiliydi - kütüphane, oluşturma adımı, çalışma süresi hesaplaması, hidrasyon flaşı, birisinin kablolamayı unuttuğu tek bileşen. Bu zincirdeki her boşluk erişilebilirliğin sessizce kaybolduğu bir noktaydı.

kontrast rengi()geliştiricilerin daha fazla önemsemesini sağlamaz. Bakımın hiçbir maliyeti yoktur.