Bu makalede, Geliştirici Araçları ve Blink Oluşturucu'da renk körlüğü simülasyonunu neden ve nasıl uyguladığımız açıklanmaktadır.
Arka plan: kötü renk kontrastı
Düşük kontrastlı metin, web'de otomatik olarak algılanabilen en yaygın erişilebilirlik sorunudur.
WebAIM'nin en popüler 1 milyon web sitesi için yaptığı erişilebilirlik analizine göre, ana sayfaların %86'sından fazlasında düşük kontrast vardır. Ortalama olarak her ana sayfada 36 farklı düşük kontrastlı metin örneği bulunur.
Kontrast sorunlarını bulmak, anlamak ve düzeltmek için Geliştirici Araçları'nı kullanma
Chrome Geliştirici Araçları, geliştiriciler ile tasarımcıların kontrastı iyileştirmesine ve web uygulamaları için daha erişilebilir renk şemaları seçmesine yardımcı olabilir:
- Web sayfasının üst kısmında yer alan İnceleme Modu ipucu, metin öğelerinin kontrast oranını gösterir.
- Geliştirici Araçları renk seçici, metin öğeleri için kötü kontrast oranlarını belirtir, daha iyi renkleri manuel olarak seçmenize yardımcı olmak için önerilen kontrast satırını gösterir ve hatta erişilebilir renkler önerebilir.
- Hem CSS'ye Genel Bakış paneli hem de Lighthouse Erişilebilirliği denetim raporu, sayfanızda bulunan düşük kontrastlı metin öğelerini listeler.
Kısa süre önce bu listeye yeni bir araç ekledik ve bu araç diğerlerinden biraz farklı. Yukarıdaki araçlar esas olarak kontrast oranı bilgilerini göstermeye ve size bu sorunu düzeltme seçenekleri sunmaya odaklanır. Geliştirici Araçları'nın, geliştiricilerin bu sorun alanını daha iyi anlayacakları bir yöntem olmadığını fark ettik. Bu sorunu çözmek için Geliştirici Araçları oluşturma sekmesinde görme bozukluğu simülasyonu uyguladık.
Puppeteer'da yeni page.emulateVisionDeficiency(type) API, bu simülasyonları programlı bir şekilde etkinleştirmenize olanak tanır.
Renk görme bozuklukları
20 kişiden yaklaşık 1'i renk körlüğü ("renk körlüğü" olarak da bilinir) eksikliğinden muzdariptir. Bu tür bozukluklar, farklı renkleri ayırt etmeyi zorlaştırarak kontrast sorunlarını artırabilir.
Düzenli vizyonu olan bir geliştirici olarak, Geliştirici Araçları'nın görsel olarak size uygun görünen renk çiftleri için kötü bir kontrast oranı gösterdiğini fark edebilirsiniz. Bunun nedeni, kontrast oranı formüllerinin bu renk görme eksikliklerini hesaba katmasıdır. Bazı durumlarda yine de düşük kontrastlı metinleri okuyabilirsiniz ancak görme bozukluğu olan kişiler bu ayrıcalığa sahip değildir.
Tasarımcıların ve geliştiricilerin bu görme bozukluklarının kendi web uygulamaları üzerindeki etkisini simüle etmelerine izin vererek eksik parçayı sağlamayı amaçlıyoruz. Geliştirici Araçları yalnızca kontrast sorunlarını bulmanıza ve düzeltmenize yardımcı olmakla kalmaz, artık bunları anlamanıza da yardımcı olur.
HTML, CSS, SVG ve C++ ile renk görme bozukluklarını simüle etme
Özelliğimizin Blink Renderer uygulaması konusuna geçmeden önce, web teknolojisini kullanarak eşdeğer işlevleri nasıl uygulayacağınızı anlamamıza yardımcı olacaktır.
Bu renk körlüğü simülasyonlarından her birini, tüm sayfayı kaplayan bir yer paylaşımı olarak düşünebilirsiniz. Web Platformu'nda bunu yapmanın bir yolu vardır: CSS filtreleri. CSS filter özelliğiyle blur, contrast, grayscale, hue-rotate gibi önceden tanımlanmış bazı filtre işlevlerini kullanabilirsiniz. Daha fazla kontrol için filter özelliği, özel bir SVG filtre tanımına yönlendirebilen bir URL'yi de kabul eder:
<style>
:root {
filter: url(#deuteranopia);
}
</style>
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
Yukarıdaki örnekte, renk matrisine dayalı özel bir filtre tanımı kullanılmaktadır. Kavramsal olarak her pikselin [Red, Green, Blue, Alpha] renk değeri, yeni bir [R′, G′, B′, A′] rengi oluşturmak için matrisle çarpılır.
Matristeki her satır 5 değer içerir: R, G, B ve A için (soldan sağa) bir çarpan ve sabit bir kaydırma değeri için beşinci bir değer. 4 satır vardır: Matrisin ilk satırı yeni Kırmızı değerini hesaplamak için, ikinci satır Yeşil, üçüncü satır Mavi ve son Alfa satırı kullanılır.
Örneğimizdeki sayıların tam olarak nereden geldiğini merak ediyor olabilirsiniz. Bu renk matrisini iyi bir döteranopia tahmini yapan nedir? Cevap: bilim! Değerler Machado, Oliveira ve Fernandes'in geliştirdiği fizyolojik olarak doğru renk körlüğü simülasyonu modeline dayanır.
Her neyse, bu SVG filtresini kullanıyoruz ve şimdi bunu CSS kullanarak sayfadaki rastgele öğelere uygulayabiliriz. Aynı yöntemi diğer görme bozuklukları için de tekrarlayabiliriz. Aşağıda bunun nasıl göründüğüne ilişkin bir demo yer almaktadır:
İstediğimizde Geliştirici Araçları özelliğimizi şu şekilde geliştirebiliriz: Kullanıcı, Geliştirici Araçları kullanıcı arayüzünde görme eksikliği emülasyonu yaptığında, SVG filtresini incelenen belgeye ekler ve filtre stilini kök öğeye uygularız. Ancak, bu yaklaşımla ilgili bazı sorunlar vardır:
- Sayfanın kök öğesinde zaten bir filtre olabilir. Bu filtre, daha sonra kodu geçersiz kılabilir.
- Sayfada, filtre tanımımızla çelişen
id="deuteranopia"içeren bir öğe zaten olabilir. - Sayfa belirli bir DOM yapısını temel alıyor olabilir ve
<svg>öğesini DOM'ye ekleyerek bu varsayımları ihlal edebiliriz.
Uç durumlar bir yana, bu yaklaşımdaki temel sorun sayfada programlı olarak gözlemlenebilir değişiklikler yapıyor olmamızdır. Bir Geliştirici Araçları kullanıcısı DOM'yi incelerse aniden, hiç eklemediği bir <svg> öğesi veya hiç yazmadığı bir CSS filter görebilir. Bu kafa karıştırıcı olurdu. Bu işlevi Geliştirici Araçları'nda uygulamak için bu dezavantajları olmayan bir çözüme ihtiyacımız var.
Bunu nasıl daha az rahatsız edici hale getirebileceğimize bakalım. Bu çözümün gizlememiz gereken iki bölümü vardır: 1) filter özelliğine sahip CSS stili ve 2) şu anda DOM'nin parçası olan SVG filtre tanımı.
<!-- Part 1: the CSS style with the filter property -->
<style>
:root {
filter: url(#deuteranopia);
}
</style>
<!-- Part 2: the SVG filter definition -->
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
Doküman içi SVG bağımlılığından kaçınma
2. bölümden başlayalım: SVG'yi DOM'ye eklemekten nasıl kaçınabiliriz? Fikirlerden biri, dosyayı ayrı bir SVG dosyasına taşımaktır. Yukarıdaki HTML'den <svg>…</svg> öğesini kopyalayıp filter.svg olarak kaydedebiliriz, ancak önce bazı değişiklikler yapmamız gerekiyor. HTML'de satır içi SVG, HTML ayrıştırma kurallarını izler. Bu sayede bazı durumlarda özellik değerlerinin başında ve sonunda tırnak işareti kullanma gibi özelliklerden kurtulabilirsiniz. Bununla birlikte, ayrı dosyalardaki SVG'nin geçerli XML olması gerekir ve XML ayrıştırması HTML'den çok daha katıdır. Yine HTML içinde SVG snippet'imizi burada görebilirsiniz:
<svg>
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000">
</feColorMatrix>
</filter>
</svg>
Bu geçerli bağımsız SVG'yi (ve dolayısıyla XML) oluşturmak için bazı değişiklikler yapmamız gerekir. Hangisini tahmin edebilir misiniz?
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000" />
</filter>
</svg>
İlk değişiklik, en üstteki XML ad alanı beyanıdır. İkinci ekleme, "solidus" olarak da bilinir. <feColorMatrix> etiketini belirten eğik çizgi, öğeyi hem açar hem de kapatır. Bu son değişiklik aslında gerekli değildir (bunun yerine açıkça belirtilmiş </feColorMatrix> kapanış etiketine bağlı kalabiliriz), ancak hem XML hem de HTML içinde SVG bu /> kısaltmasını desteklediği için ondan da yararlanabiliriz.
Her neyse, bu değişikliklerle birlikte bunu geçerli bir SVG dosyası olarak kaydedip HTML belgemizdeki CSS filter özellik değerinden işaret edebiliriz:
<style>
:root {
filter: url(filters.svg#deuteranopia);
}
</style>
Hurrah, artık dokümana SVG eklemek zorunda değiliz. Bu şimdiden çok daha iyi. Ama... artık ayrı bir dosya kullanıyoruz. Bu hâlâ bir bağımlılık. Bir şekilde ondan kurtulabilir miyiz?
Ancak aslında bir dosyaya ihtiyacımız olmadığını fark ettik. Veri URL'si kullanarak bir URL içinde dosyanın tamamını kodlayabiliriz. Bunun gerçekleşmesi için, önceden sahip olduğumuz SVG dosyasının içeriğini kelimenin tam anlamıyla alıp data: önekini ekliyoruz, uygun MIME türünü yapılandırıyoruz ve kendimize aynı SVG dosyasını temsil eden geçerli bir veri URL'si elde ediyoruz:
data:image/svg+xml,
<svg xmlns="http://www.w3.org/2000/svg">
<filter id="deuteranopia">
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000
0.280 0.673 0.047 0.000 0.000
-0.012 0.043 0.969 0.000 0.000
0.000 0.000 0.000 1.000 0.000" />
</filter>
</svg>
Bunun avantajı, artık dosyayı herhangi bir yerde depolamamız veya HTML belgemizde kullanmak için diskten ya da ağ üzerinden yüklememiz gerekmemesidir. Önceden yaptığımız gibi dosya adına başvurmak yerine, artık veri URL'sini de belirtebiliriz:
<style>
:root {
filter: url('data:image/svg+xml,\
<svg xmlns="http://www.w3.org/2000/svg">\
<filter id="deuteranopia">\
<feColorMatrix values="0.367 0.861 -0.228 0.000 0.000\
0.280 0.673 0.047 0.000 0.000\
-0.012 0.043 0.969 0.000 0.000\
0.000 0.000 0.000 1.000 0.000" />\
</filter>\
</svg>#deuteranopia');
}
</style>
URL'nin sonunda, önceden olduğu gibi kullanmak istediğimiz filtrenin kimliğini belirtmeye devam ederiz. URL'deki SVG dokümanını Base64 olarak kodlamanıza gerek olmadığını unutmayın. Bunu yapmak yalnızca okunabilirliğe zarar verir ve dosya boyutunu artırır. Veri URL'sindeki yeni satır karakterlerinin CSS dizesi sabit değerini sonlandırmaması için her satırın sonuna ters eğik çizgi ekledik.
Şimdiye kadar sadece web teknolojisini kullanarak görme bozukluklarını nasıl simüle edebileceğimizden bahsettik. İlginç bir şekilde, Blink Renderer'daki uygulamamız aslında oldukça benzerdir. Belirli bir filtre tanımına sahip, aynı tekniğe sahip veri URL'si oluşturmak için eklediğimiz bir C++ yardımcı yardımcı programını burada görebilirsiniz:
AtomicString CreateFilterDataUrl(const char* piece) {
AtomicString url =
"data:image/svg+xml,"
"<svg xmlns=\"http://www.w3.org/2000/svg\">"
"<filter id=\"f\">" +
StringView(piece) +
"</filter>"
"</svg>"
"#f";
return url;
}
İhtiyaç duyduğumuz tüm filtreleri oluşturmak için bu modülü şu şekilde kullanıyoruz:
AtomicString CreateVisionDeficiencyFilterUrl(VisionDeficiency vision_deficiency) {
switch (vision_deficiency) {
case VisionDeficiency::kAchromatopsia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kBlurredVision:
return CreateFilterDataUrl("<feGaussianBlur stdDeviation=\"2\"/>");
case VisionDeficiency::kDeuteranopia:
return CreateFilterDataUrl(
"<feColorMatrix values=\""
" 0.367 0.861 -0.228 0.000 0.000 "
" 0.280 0.673 0.047 0.000 0.000 "
"-0.012 0.043 0.969 0.000 0.000 "
" 0.000 0.000 0.000 1.000 0.000 "
"\"/>");
case VisionDeficiency::kProtanopia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kTritanopia:
return CreateFilterDataUrl("…");
case VisionDeficiency::kNoVisionDeficiency:
NOTREACHED();
return "";
}
}
Bu tekniğin, herhangi bir şeyi yeniden uygulamak veya tekerlekleri yeniden icat etmek zorunda kalmadan SVG filtrelerinin tüm gücünden yararlanmamızı sağladığını unutmayın. Blink Renderer özelliğini uyguluyoruz, ancak bunu Web Platformu'ndan da faydalanarak yapıyoruz.
SVG filtrelerini nasıl oluşturacağımızı ve bunları CSS filter özelliğinin değerimizde kullanabileceğimiz veri URL'lerine nasıl dönüştüreceğimizi öğrendik. Bu teknikte aklınıza gelen bir sorun var mı? Ancak, hedef sayfada veri URL'lerini engelleyen bir Content-Security-Policy olabileceği için aslında her durumda yüklenmekte olan veri URL'sine güvenmemizin mümkün olmadığı anlaşılıyor. Blink düzeyindeki nihai uygulamamız, yükleme sırasında bu "dahili" veri URL'leri için İGP'yi atlamak amacıyla özel bir özen gösterir.
Uç durumlar bir yana, gayet iyi ilerleme kaydettik. Artık satır içi <svg> öğesinin aynı dokümanda bulunmamasına bağımlı olmadığımız için çözümümüzü etkili bir şekilde, bağımsız bir CSS filter özelliği tanımına indirdik. Çok güzel! Şimdi ondan da kurtulalım.
Doküman içi CSS bağımlılığından kaçınma
Özetlemek gerekirse şu ana kadar neler yaptığımızı özetleyelim:
<style>
:root {
filter: url('data:…');
}
</style>
Hâlâ bu CSS filter özelliğine bağımlıyız. Bu durum, gerçek belgedeki filter özelliğini geçersiz kılabilir ve işleri bozabilir. Ayrıca, Geliştirici Araçları'nda hesaplanan stiller incelenirken kafa karıştırıcı olabilirdi. Bu sorunlardan nasıl kaçınabiliriz? Dokümanları geliştiriciler tarafından programlı bir şekilde gözlemlemeden dokümana filtre eklemenin bir yolunu bulmamız gerekiyor.
Ortaya çıkan fikirlerden biri, filter gibi çalışan, ancak --internal-devtools-filter gibi farklı bir ada sahip yeni bir Chrome dahili CSS mülkü oluşturmaktı. Ardından, bu özelliğin Geliştirici Araçları'nda veya DOM'deki hesaplanan stillerde hiçbir zaman görünmemesini sağlayacak özel bir mantık ekleyebiliriz. Hatta bu işlevin yalnızca ihtiyacımız olan tek öğe olan kök öğede çalıştığından emin olabiliriz. Ancak bu çözüm ideal olmazdı: filter ürününde zaten var olan işlevleri yinelerdik. Standart olmayan bu mülkü gizlemeye çalışsak bile web geliştiricileri bunu tespit edip kullanmaya başlayabilir. Bu da Web Platformu için kötü bir durumdur. Bir CSS stilini DOM'de gözlemlenebilir olmadan uygulamanın başka bir yöntemine ihtiyacımız var. Fikirleriniz var mı?
CSS spesifikasyonunda, kullandığı görsel biçimlendirme modelini tanıtan bir bölüm bulunur. Temel kavramlardan biri de görünüm'dür. Bu, kullanıcıların web sayfasına başvurduğu görsel görünümdür. Yakından alakalı bir kavram, içeren ilk bloktur. Bu kavram, yalnızca spesifikasyon düzeyinde var olan, stilize edilebilir bir görüntü alanına <div> benzer. Bu spesifikasyon, her yerde bu "viewport" (görüntü alanı) kavramıyla ilgilidir. Örneğin, içerik sığmadığında tarayıcının kaydırma çubuklarını nasıl gösterdiğini biliyor musunuz? Bunların tümü, bu "görüntü alanına" göre CSS spesifikasyonunda tanımlanmıştır.
Bu viewport, uygulama ayrıntısı olarak Blink Oluşturucu'da da bulunur. Spesifikasyona göre varsayılan görüntü alanı stillerini uygulayan kodu aşağıda bulabilirsiniz:
scoped_refptr<ComputedStyle> StyleResolver::StyleForViewport() {
scoped_refptr<ComputedStyle> viewport_style =
InitialStyleForElement(GetDocument());
viewport_style->SetZIndex(0);
viewport_style->SetIsStackingContextWithoutContainment(true);
viewport_style->SetDisplay(EDisplay::kBlock);
viewport_style->SetPosition(EPosition::kAbsolute);
viewport_style->SetOverflowX(EOverflow::kAuto);
viewport_style->SetOverflowY(EOverflow::kAuto);
// …
return viewport_style;
}
Bu kodun görüntü alanının z-index, display, position ve overflow değerlerini (veya daha doğru bir şekilde: ilk içeren blokların) işlendiğini görmek için C+++ ya da Blink'in Stil motorunun inceliklerini anlamanız gerekmez. Bunların hepsi CSS'den aşina olabileceğiniz kavramlar. Bağlamların yığılmasıyla ilgili başka bir sihirli yaklaşım da vardır. Bu, doğrudan bir CSS mülküne dönüştürülmez, ancak genel olarak bu viewport nesnesini, DOM'nin parçası olmaması dışında, tıpkı bir DOM öğesi gibi Blink içinden CSS kullanılarak stillendirilebilen bir şey olarak düşünebilirsiniz.
Bu sayede istediğimizi elde ediyoruz. filter stillerimizi viewport nesnesine uygulayabiliriz. Bu işlem, oluşturmayı görsel olarak etkiler. Ancak, gözlemlenebilir sayfa stillerine veya DOM'ye hiçbir şekilde müdahalede bulunmaz.
Sonuç
Buradaki küçük yolculuğumuzu özetlemek gerekirse, C++ yerine web teknolojisini kullanarak bir prototip oluşturarak işe başladık ve bazı bölümlerini Blink Oluşturucu'ya taşımak için çalışmaya başladık.
- Öncelikle, veri URL'lerini satır içi yaparak prototipimizi daha bağımsız hale getirdik.
- Daha sonra, bu dahili veri URL'lerini özel olarak büyük/küçük harfe dönüştürerek CSP uyumlu hale getirdik.
- Stilleri Blink-internal
viewportöğesine taşıyarak uygulamamızı DOM'den bağımsız ve programlı olarak gözlemlenemez hale getirdik.
Bu uygulamanın benzersiz yönü, HTML/CSS/SVG prototipimizin nihai teknik tasarımdan etkilenmiş olmasıdır. Blink Renderer'da bile Web Platformu'nu kullanmanın bir yolunu bulduk.
Daha fazla bilgi için tasarım teklifimize veya ilgili tüm yamalara referans veren Chromium izleme hatasına göz atın.
Önizleme kanallarını indirme
Varsayılan geliştirme tarayıcınız olarak Chrome Canary, Dev veya Beta'yı kullanabilirsiniz. Bu önizleme kanalları en yeni Geliştirici Araçları özelliklerine erişmenizi, son teknoloji ürünü web platformu API'lerini test etmenizi ve kullanıcılarınızdan önce sitenizdeki sorunları bulmanızı sağlar.
Chrome Geliştirici Araçları ekibiyle iletişim kurma
Yayındaki yeni özellikleri ve değişiklikleri ya da Geliştirici Araçları ile ilgili diğer her şeyi tartışmak için aşağıdaki seçenekleri kullanın.
- Öneri veya geri bildirimlerinizi crbug.com adresinden bize iletebilirsiniz.
- Geliştirici Araçları sorunlarını bildirmek için Diğer seçenekler'i
> Yardım > Geliştirici Araçları'nda Geliştirici Araçları ile ilgili sorunları bildirin. - @ChromeDevTools adresinden tweet atabilirsiniz.
- Geliştirici Araçları YouTube videoları veya Geliştirici Araçları ipuçları YouTube videolarına yorum yazın.