Algoritmik Tema Motorları: Kontrast renk() ile Kendi Kendini Düzelten Renk Sistemleri Oluşturma
Twitter'da paylaş, LinkedIn
2025'te web sitelerinin yüzde yetmişi hâlâ temel WCAG kontrast kontrollerinde başarısız oluyor. Yıllar süren tasarım sistemi araçları, erişilebilirlik linterleri ve JavaScript kitaplıklarından sonra hiçbir şey iğneyi kıpırdatmadı. Daha iyi kütüphanelere ihtiyacımız yoktu. Daha iyi CSS'ye ihtiyacımız vardı. kontrast-renk() daha iyi CSS'dir. 2025'te web sitelerinin yüzde yetmişi hâlâ temel WCAG kontrast kontrollerinde başarısız oluyor. Yıllar süren tasarım sistemi araçları, erişilebilirlik linterleri ve JavaScript kitaplıklarından sonra hiçbir şey iğneyi kıpırdatmadı. Daha iyi kütüphanelere ihtiyacımız yoktu. Daha iyi CSS'ye ihtiyacımız vardı. Bu daha iyi CSS.
Teknik Analiz
HTTP Arşivi Web Almanağı yıllardır renk kontrastı hatalarını izliyor. Rakamlar neredeyse hiç değişmedi. Yarım on yıllık tasarım sistemi araçları, erişilebilirlik linterleri ve okunabilir metin renklerini hesaplamaya adanmış tüm JavaScript kitaplıklarından sonra, web sitelerinin %70'i 2025'te hala temel WCAG kontrast kontrollerinde başarısız oluyor. WebAIM Million daha da kasvetli bir tablo çiziyor - ana sayfaların %83,9'u düşük kontrastlı metin için işaretlendi; 2025'teki %79,1'den bu oran 2026'da %83,9'du. Oran, bir kıyaslamada yılda belki birkaç yüzde puan arttı ve aslında bir başkasında daha da kötüleşiyor. 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ı.
Gelecekte Ne Bekleniyor?
kontrast-renk () 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: Eski makalelerde ve spesifikasyon taslaklarında bunun color-contrast() olarak adlandırıldığını gördüyseniz, bu ad değiştirilmiştir ve eski sözdizimi artık hiçbir tarayıcıda çalışmamaktadır.
Ne Yapar (Ve Ne Yapmaz)
Önemli Gelişmeler
Seviye 5 versiyonu basittir. Sen ona bir renk ver. Girişinize karşı hangisi daha fazla kontrasta sahipse, size siyah veya beyazı geri verir.
.button { arka plan rengi: var(--marka-renk); renk: kontrast-renk(var(--marka-renk)); }
Uzmanların Görüşleri
--brand-color'u neon yeşili olarak değiştirin, metin siyah olur. 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 sayı değil,
, bir sayı değil. Gerçek bir renk değeri ( veya ) elde edersiniz, CSS'nin rengi kabul ettiği her yerde kullanabilirsiniz. Şimdilik sadece siyah veya beyaz. Seviye 6 için aday renk listeleri ve hedef oranları planlanmıştır.
Detaylar ve Etkileri
şimdilik. Seviye 6 için aday renk listeleri ve hedef oranları planlanmıştır. Anahtar kelime yoktur. Eski blog yazılarında max'ı gördüyseniz bu özellikten çıkarılmıştır. Bunu kullanmak beyanınızı sessizce bozacaktır.
Daha eski blog yazılarında gördüyseniz bu özellikten çıkarılmıştır. Bunu kullanmak beyanınızı sessizce bozacaktır. Yukarıda belirtildiği gibi, ilk taslaklarda bu işleve color-contrast() adı veriliyordu. Bu ad artık geçerli değil; CSSWG, CSS işlevlerinin döndürdükleri şeye göre adlandırıldığı kuralına uyacak şekilde onu yeniden adlandırdı. color-mix() bir renk döndürür. kontrast-renk() bir renk döndürür. Eski color-contrast() adı, yanıltıcı olan bir kontrast oranı (4,5 gibi bir sayı) döndürüyormuş gibi geliyordu. 2021-2023 yılları arasında color-contrast() sözdizimini gösteren hiçbir eğitim mevcut tarayıcılarda çalışmayacaktır.
Sonuç ve Değerlendirme
Özellik Ayrımı: Seviye 5 ve Seviye 6
Bu işlev iki spesifikasyonda yaşar. Bu alışılmadık bir durum ve anlamaya değer.
CSS Renk Düzeyi 5, tarayıcıların bugün hangileri 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.
Bu bağlamda APCA'dan (Erişilebilir Algısal Kontrast Algoritması) çokça bahsedildiğini göreceksiniz. 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. Tarayıcı satıcıları, Düzey 5 spesifikasyonuna "WCAG 2.x kullan" seçeneğini kilitlemeyerek daha sonra mevcut herhangi bir kodu bozmadan APCA'ya geçiş yapabilirler. Spesifikasyon varsayılan olarak bir wcag2() anahtar kelimesiyle gönderilmiş olsaydı, onu kullanan her site kalıcı olarak eski matematiğe takılıp kalırdı.
Sistem Güvenliği
Ancak APCA'nın geleceği çok daha az kesin. heyecanın önerdiği gibi. Adrian Roselli'nin "Nisan 2026 itibarıyla WCAG3 Kontrastı" mevcut durumu açıkça ortaya koyuyor: APCA, Yeterli Çalışma Grubu desteğini alamayınca 2023 ortasında WCAG 3 çalışma taslağından çekildi. WCAG 3 spesifikasyonu şu anda kontrast algoritmasının "henüz belirlenmediğini" ve standardın kendisinin 2030 veya sonrasına kadar kesinleşmeyebileceğini söylüyor. Roselli ayrıca Mayıs 2024'te Chromium'a bir başvuruda bulunarak "Gelişmiş Algısal Kontrast Algoritması" deneme bayrağının DevTools'tan tamamen kaldırılmasını talep etti; 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ı risk taşıdığını ileri sürdü. 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ı, APCA yönergelerini geçen renklerin çoğu durumda WCAG 2 minimumlarını büyük ölçüde aştığını belirtmiştir. Ancak şu anda APCA'nın WCAG 2.x'in yerini alacak algoritma olacağının garantisi yok ve bu belirsizlik kontrast-color() için önemli. 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 özelliklerinin (aday renk listeleri, hedef oranlar, tbd-fg / tbd-bg anahtar sözcükleri) hepsinin mevcut haliyle gerçekleşebilecek veya gerçekleşmeyebilecek bir algoritma etrafında tasarlandığı anlamına gelir.
Nasıl Önlem Alınmalı?
CSS Renk Düzeyi 6, aday renk listeleri ve hedef kontrast oranlarından oluşan genişletilmiş sözdizimini ekler:
/* Seviye 6 gelecek sözdizimi — henüz gönderilmiyor */ color: 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-bg anahtar sözcükleri, 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 gönderdi: Chrome 147 (Nisan 2026), Firefox 146 ve Safari 26.0. Nisan 2026'da Baseline Newly Available durumuna ulaştı. Tam sürüm matrisi için caniuse'u kontrol edin. Her üç motor da kontrast-color() için Web Platformu Testlerini geçmiştir; 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.
@supports kullanılarak aşamalı geliştirme basittir:
.card { arka plan: var(--bg); renk: #fff; metin gölgesi: 0 0 4px rgb(0 0 0 / 0,8); } @destekler (renk: kontrast-renk(kırmızı)) { .card { 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.) text-shadow'u değerlendiremez. Yalnızca hesaplanan renge karşı arka plan rengine bakarlar. 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:
Derleme sırasında kontrast-renk() işlevini değerlendiren bir eklenti (@csstools/postcss-contrast-color-function) var. kontrast rengi(#ff0000) gibi statik renkler için çalışır. Ancak özel bir özelliği - kontrast-renk(var(--bg)) kullandığınız anda 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 @supports'a güvenin.
Algısal veya AAA Uyumluluğunu Garanti Etmez
Bu insanları yanıltabilir: "Kontrast işlevini kullandım, dolayısıyla sitem artık erişilebilirlik kontrollerini 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. Bir (veya her ikisi) her zaman geçecektir.
#2277d3'ü (orta mavi) alın. 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-renk() size hangisinin hafif matematiksel üstünlüğü varsa onu verecektir.
Ancak işin aslı şu: WCAG 2.x matematiği algısal kör noktaları biliyor. Siyah metinli aynı #2277d3 matematiksel olarak AA'yı geçer, ancak insan gözü için okunması inanılmaz derecede zor olabilir. kontrast-renk() size matematiksel uyumluluk sağlar; bu, otomatik denetimler için harikadır ancak bu her zaman algısal erişilebilirliğe eşit değildir. (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ölge mevcuttur. Parlaklığı kabaca %10 ila %30 arasında olan arka planlar için ne siyah ne de beyaz 7:1'e ulaşamaz. Bu gibi durumlarda, kontrast-renk() sizi kurtaramaz; yalnızca "en az kötü" başarısızlık seçeneğini sunar.
Geçişler Anında Anlaşılır, Solmaz
Fareyle üzerine gelindiğinde bir arka planı beyazdan siyaha hareketlendiriyorsanız:
.btn { arka plan rengi: #fff; renk: kontrast rengi(#fff); /* siyah */ geçiş: arka plan rengi 1'ler, renk 1'ler; } .btn:hover { arka plan rengi: #000; renk: kontrast rengi(#000); /* beyaz */ }
Arka plan bir saniye içinde yumuşak bir şekilde kaybolur. Ancak Düzey 5 çıktısı ayrı bir değer olduğundan (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 hafifliğin($bg)>%50 olup olmadığını kontrol ettiğimiz eski Sass günlerinden kalma kas hafızanız vardır. 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.
Geçiş davranışının olduğunu varsayabilirsiniz: izin verme-discrete bunu düzeltir. Değil. izin verme-discrete, bir ikili çıktının enterpolasyonunu yapamadığı için sarsıcı 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 renk geçişlerine ihtiyacınız varsa, renk karışımını () katmanlamanız veya çapraz geçişi kendiniz yönetmeniz gerekir.
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şitliği bozan özelliği vardır: 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ı
İşlev düz bir
Ö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: etkin medya sorgusu devreye girer ve tarayıcı agresif bir şekilde yazarın tanımladığı renklerin üzerine yazar. kontrast-renk() öne çıkıyor; CanvasText gibi zorunlu sistem renkleri kontrolü tamamen ele alıyor. Kontrast mantığınızı geri almak için manuel medya sorguları yazmanıza gerek yoktur; tarayıcı hiyerarşiyi yönetir.
Diğer Renk İşlevleriyle Birleştirilmesi
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. Peki ya kontrast metni arka plan renginin çok koyu veya çok açık bir tonuysa?
Kevin Hamer ilgili territoyu araştırdı ry, CSS-Tricks makalesinde "Contrast-color()'a Diğer CSS Özellikleriyle Yaklaşma" bölümünde OKLCH hafiflik ve round() kullanarak kontrast-color() olmadan siyah/beyaz anahtarını yaklaşık olarak yakınlaştırdı - aslında oklch(from
.card { --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 kromayı ve arka planın tonunu enjekte edin */ color: oklch(from kontrast-renk(var(--bg)) l 0.05 var(--bg-hue)); }
kontrast-renk() beyaza döndüğünde l 1'dir (tam açıklık). Siyaha döndüğünde l 0'dır. Arka planın tonunu tekrar içeri ç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ırda bir kontrast oranını başarısızlığa itebilirsiniz. Renkli çıktınızı göndermeden önce daima erişilebilirlik linterinden geçirin.
Şunu da belirtmekte fayda var: Bu örnek iki çok modern özelliği zincirliyor — kontrast-renk() ve oklch(from ...) . Bunlardan herhangi biri desteklenmiyorsa bildirimin tamamı sessizce başarısız olur. @supports bloğunuzun her ikisini de test etmesi gerekiyor:
@supports (renk: kontrast rengi(kırmızı)) ve (renk: oklch(kırmızıdan l c h)) { /* Her ikisini de kullanmak güvenlidir */ }
Renk karışımıyla () Yumuşatılmış Kontrast
Benzer fikir, daha basit API. Keskin siyah/beyaz çıktıyı yumuşatmak için arka plana karıştırın:
.alert { --bg: var(--alert-color); arka plan: var(--bg); /* %80 kontrast, %20 arka plan = daha yumuşak ama okunabilir */ color: color-mix(in oklch, kontrast-color(var(--bg)) 80%, var(--bg)); /* İnce bir kenarlık için %40 kontrast */ kenarlık: 1px katı renk karışımı(in oklch, kontrast-renk(var(--bg)) 40%, var(--bg)); }
Metni, kenarlığı ve potansiyel olarak kutu gölgesini veya anahattı yönlendiren tek bir özel özellik. --alert-color değerini değiştirdiğinizde tüm bileşen yeniden hesaplanır.
Bu model aynı zamanda dinamik temada yaygın bir sıkıntı noktası olan ::placeholder metni için de işe yarar. Yer tutucu metin okunabilir olmalı ancak görsel olarak girişin ana metninden daha yumuşak olmalıdır; color-mix() ve kontrast-color() sizi hedefe ulaştırır:
giriş { --bg: var(--input-bg); arka plan: var(--bg); renk: kontrast-renk(var(--bg)); } input::placeholder { color: color-mix(oklch içinde, kontrast-renk(var(--bg)) 50%, var(--bg)); }
%50 karışım, girişin bulunduğu arka plana otomatik olarak uyum sağlayan sessiz ancak okunaklı bir yer tutucu sağlar.
Açık-koyu() ile Temaya Duyarlı Kontrast
Sistem açık/karanlık modunu destekleyen uygulamalar için:
:root { renk şeması: açık koyu; --surface: açık-koyu(#fff, #121212); } .component { arka plan: var(--surface); renk: kontrast-renk(var(--surface)); }
İşletim sistemi karanlık moda geçtiğinde --surface #121212 olarak çözümlenir ve kontrast-renk() beyaza döner. Medya sorgusu yok, JavaScript teması tespiti yok. Tüm zincir doğal olarak çözümlenir.
Paketinizden Neleri Kaldırabilirsiniz?
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:
Kitaplık Boyutu Ne yaptı chroma-js ~14 kB Renk ayrıştırma, parlaklık hesaplaması, okunabilir renk seçimi cilalı ~11 kB stil bileşenleri için readableColor() Tinycolor2 ~5 kB Hex ayrıştırma, WCAG kontrast oranı matematiği
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-renk() tüm bunları tarayıcının yerel stildeki hesaplama aşamasına taşır; boyamadan önce çalışan, yoğun şekilde optimize edilmiş C++. bir için Çok sayıda temalı bileşene sahip pps'ler, bu yanıt vermede gerçek bir farktır.
Ayrıca ortadan kaybolan ince bir hata da var: sıvı alımı 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. Hafifliği($bg)>%50 kontrol eden ve derleme zamanında siyah veya beyaz döndüren bir fonksiyon yazarsınız. 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 --r , --g , --b kanallarına böldü, calc() içindeki Rec.709 parlaklığını hesapladı, negatif sonsuzlukla çarptı ve 0 veya 1'e sabitledi. İşe yaradı. Aynı zamanda okunamazdı, sürdürülemezdi ve bir parantez yanlış girildiğinde sessizce bozulurdu. (Kevin Hamer'in OKLCH tabanlı yaklaşımı, bu soyun en zarif versiyonudur - daha temiz matematik, daha iyi algısal hizalama - ama yine de artık yerel olarak gönderilen bir işlev için geçici bir çözümdür.)
kontrast-renk() 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'lik 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-renk() geliştiricilerin daha fazla ilgilenmesini sağlamaz. Bakımın hiçbir maliyeti yoktur.
