CSS neden yetmedi

axe-core gibi araçlar kontrastı color ve background-color değerlerinden hesaplar. Kendi sitemde metin, gradyan perde altındaki bir fotoğrafın üstündeydi; okunacak arka plan rengi yoktu, denetleyiciler ögeyi incomplete raporladı. En kötü noktadaki gerçek oran 4,5:1 gereksinime karşı 3:1 civarındaydı ve bunu bana kimse söylememişti.

Birinci deneme: metnin yanından örnekle

İlk sürüm bir ekran görüntüsü alıp arka plan rengini her harfin yanındaki piksellerden okudu. Düz zeminde çalışıyor. Gradyanda harfin yanındaki piksel altındakinden farklı renk; okumalar iki yönde de yanlıştı: geçen metne yanlış alarm, kalan metne temiz sonuç. Sayılar gördüğümle uyuşmadığı için fark ettim.

İkinci deneme: kapsamayı değişimden tahmin et

İkinci sürüm iki görüntü aldı, biri normal biri tüm metin gizli, ve her pikselin ne kadar harfle kaplandığını ne kadar değiştiğinden tahmin etti. Sonra renkleri en çok kaplanan piksellerden okudu.

Gradyanda iki görüntü arasındaki değişim zeminin koyuluğuyla büyür. Tahmin bu yüzden yalnızca en yüksek kontrastlı bölgenin piksellerini seçti ve açık uca hiç bakmadı. Zeminin metnin kendi renginden geçtiği gradient.html fixture'ının en kötü noktası 1,1:1 civarında. Bu sürüm 4,47:1 raporladı ve geçirdi. Test başarısız oldu; ben olmamıştım.

Dayanan yöntem

Aynı görünümün beş ekran görüntüsü:

• A: sayfanın kendisi
• A2: 300 ms sonra; değişen pikseller elenir (yüklenen yazı tipi, animasyon)
• B: tüm metin saydam
• C: tüm metin siyah
• D: tüm metin beyaz

C ve D her pikselin kapsamasını tam olarak verir. Bir piksel bg zemini üstünde α oranında örtülüyse C = (1−α)·bg ve D = α·255 + (1−α)·bg, yani α = (D − C)/255; zeminden ve metnin gerçek renginden bağımsız. Ögenin en büyük α'sına yakın pikseller harfin çekirdeği; kenar yumuşatma pikselleri atılır.

Sonra ön plan A'dan, arka plan B'den aynı piksellerden okunur. Hiçbir şey hesaplanmaz. Opaklık zincirleri, rgba renkler ve pseudo-element perdeler Chrome boyarken zaten uygulandı.

Testlerin sonradan zorladığı iki düzeltme

Alt piksel yumuşatma. Windows'ta ClearType her renk kanalına farklı kapsama verir. Tam kapalı sanılan pikseller hâlâ karışımdı ve her okuma yaklaşık yarım puan düşük çıkıyordu: beyaz üstünde #777 için hesaplanan 4,48'e karşı ölçülen 3,92. Chrome artık gri tonlamalı yumuşatmayla açılıyor (--disable-lcd-text).

İnce harfler. Gövde bir pikselden inceyse hiçbir piksel tam kapanmaz, en yoğun olan bile karışımdır. α bilindiği için karışım geri alınabilir: E = B + (A − B)/α. Bu olmadan gerçekte 5,85:1 olan 12 px altbilgi bağlantıları 3,81:1 çıkıyordu. Bu düzeltmenin ilk sürümü rengin kendi alfasını da kapsamadan böldü, ki bu yanlış: siyah ve beyaz sondalar rengi değiştirir ama ögenin opacity değerini değil, dolayısıyla bölünmesi gereken tek şey opaklık. Geçmesi gereken rgba .68 satır ve 3,32:1'de kalması gereken rgba .5 satır artık iki yönü de sabitliyor.

Doğrulanan ve doğrulanmayan

37bbe2a revizyonunda kayıtlı 57 test yerelde Windows 11 ve Chrome 152 ile geçti. Karşılaştırma betiği axe-core ile paintcheck’i aynı test sayfalarında çalıştırıyor; düz renklerde hesaplanan referans oranları kullanılıyor. Fotoğraf ve perde örneklerinin elle hesaplanmış referans değeri yok. Gösterilen sonuçlar yerel revizyona ait; bu revizyon henüz GitHub’da yayımlanmadı.

Güncelleme, 16 Eylül 2026: 37bbe2a revizyonu GitHub’da ve Ubuntu, Node 20/22 CI çalışması geçti. macOS hâlâ denenmedi. Yazı tiplerinin ekrana çizilmesi oranları değiştirebilir; bu iki ortam dışında aynı geçti/kaldı kararını vereceği doğrulanmış değil.

Araç henüz npm'de değil. npx github:hasanyahsitr/paintcheck ile depodan çalışır ve yerel Chrome ister.

paintcheck: vurgu rengi

Referans tasarım beyaz kartlar üstünde bağlantı ve düğmeler için parlak bir mavi kullanıyor: #4770ff. Gözle bakınca sorun yok. Boyanan piksellerden ölçünce var:

! [contrast] section.hy-kart > div.hy-kart-bas > a.hy-ok
    "More About Me"
    16px — 4.09:1 — needs 4.5:1
    rgb(73,114,255) on rgb(255,255,255)
! [contrast] div.hy-profil-dugmeler > a.hy-dugme
    "Write to me"
    16px — 4.16:1 — needs 4.5:1
    rgb(254,254,255) on rgb(71,112,255)

Ana sayfada on iki, hakkımda sayfasında altı, iletişim sayfasında altı bulgu. Hepsinin sebebi aynı: beyaz üstünde mavi metin ya da o mavi üstünde beyaz metin, 4,5:1 eşiğine karşı 4,09 ile 4,18 arasında. Bu düz zemin durumu; CSS aritmetiği burada kesindir, axe-core da yakalardı. Ben henüz hiçbir şey çalıştırmamıştım.

Düzeltme: açık temada metin ve düğme zemini için vurgu #3457e8 oldu (beyazda 5,8:1), koyu temadaki siyah kartlarda metin için daha açık #6b8cff. Gözle fark küçük. Değişiklikten sonra paintcheck dört sayfada da sıfır kontrast bulgusu veriyor. Kalan bulgular, etiketli seçim çiplerinin içindeki görünmez radyo girdileri için target-size notları; tıklama hedefi etiketin kendisi, girdi bilerek 1×1.

Lighthouse: var olmayan dosyalara 26 istek

Ana sayfada masaüstü Lighthouse: performans 96, erişilebilirlik 96, en iyi uygulamalar 96, SEO 100. "Konsolda hata" denetimi çalışma sırasında on tane 404 listeledi; bağlantıların üstünde gezen bir puppeteer betiği tam bir ziyarette 26 saydı.

İstekler /about/__next.!KGVuKQ.about.__PAGE__.txt gibiydi. Next.js 16.2 static export, segment ön yükleme dosyalarını iç içe klasör olarak yazıyor (out/about/__next.!KGVuKQ/about/__PAGE__.txt), istemci ise noktalı düz adı istiyor. Her ön yükleme başarısız oluyor, her istemci tarafı geçiş tam sayfa yüklemeye düşüyordu.

Bunun için bir yapılandırma anahtarı bulamadım; derleme artık her iç içe dosyayı düz adıyla kopyalayan 30 satırlık bir betik çalıştırıyor. Sonrası: sıfır 404, istemci geçişlerinde sondaki eğik çizgi korunuyor, masaüstü Lighthouse 95 / 100 / 100 / 100, LCP 1,5 s, CLS 0.

Lighthouse mobil: fotoğraf

Mobil çalışma performansta 76 verdi; Lighthouse'un benzetilmiş yavaş 4G'sinde LCP 7,1 s. En büyük öğe kendi fotoğrafımdı: 800×800 WebP, üstelik loading="lazy". Ekrandaki ilk şeyi tembel yüklemek tam tersi bir hata; özniteliği sayfanın aşağısında da kullanılan bir bileşenden kopyalamıştım.

Düzeltme: profil fotoğrafı artık hemen yükleniyor, fetchpriority="high" ile; telefon genişlikleri için srcset üzerinden 480 px sürüm sunuluyor. Yeniden ölçünce benzetilmiş mobil LCP 7,1 s'den 6,2 s'ye, puan 76'dan 77'ye geldi. Küçük bir hareket ve ayrıntı sebebini söylüyor: görselin kendisi yaklaşık 120 ms'de yükleniyor; gecikme 173 KB'lık HTML belgesinde ve öncesindeki çizim işinde, fotoğrafta değil.

Belgeyi de denedim. Logo yolları her logo için iki kez gömülüydü: bir kez işaretlemede, bir kez Next'in satır içi veri yükünde. Onları tek bir dış SVG sprite dosyasına taşımak ana sayfayı 170 KB'tan 82 KB'a indirdi. Başka hiçbir şey çalışmazken iki kez ölçtüm: mobilde 78 ve 74, LCP 5,9 s ve 6,1 s. Belge yarıya indi, LCP aynı. Kaldıraç başka yerde; bu gece tahmin etmeyi bıraktım. Küçülen sayfa yine de kalmaya değer.

Güncelleme, 16 Eylül 2026. Kaldıraç yerel sunucuymuş. Yukarıdaki mobil sayıların hepsi dizüstümdeki serve ile alındı; o da HTML'i sıkıştırmadan ve önbellek başlığı olmadan gönderiyor. Aynı derleme Firebase Hosting'de, canlı hasanyahsi.com üzerinde Lighthouse 12 ile: mobil 90 / 100 / 100 / 100, LCP 2,4 s; masaüstü 99 / 100 / 100 / 100, LCP 0,6 s. 6 saniye hiçbir zaman sayfa değildi, sunuş biçimiydi. Yayındaki siteyi ölçmek son adım değil ilk adım olmalıydı.

Mobildeki erişilebilirlik denetimi menü bağlantılarını da işaretledi: 1100 px altında etiket metnini display: none ile gizlemiştim, bu erişilebilir addan da siliyor. Artık yalnızca görsel olarak gizli; mobil erişilebilirlik puanı 100.

Bu not ne değil

Bu sayıların hiçbiri belge değil. Lighthouse tek makinede benzetilmiş kısıtlamayla çalışıyor; paintcheck tek bir anda tek bir görünümü ölçüyor. Mesele daha küçük: referanstan bir renk kopyaladım, kendi aracımın var olma sebebi olan eşikte kaldı ve bunu yalnızca aracı çalıştırdığım için öğrendim.

Bugün, ölçüm günü, önce Cloudflare paneline baktım. Güvenlik kurallarında şu vardı:

AI Crawl Control - Block AI bots by User Agent · Aktif

Kural ChatGPT-User, OAI-SearchBot, Claude-SearchBot, PerplexityBot ve bingbot dahil 16 botu robots.txt dışında her yolda engelliyordu. Son 24 saatte 212 yapay zekâ tarayıcı isteğinin 163'ü reddedilmişti. OpenAI, Anthropic, Perplexity ve Bing için izin verilen istek: sıfır.

Nasıl ölçtüm

Panele güvenmedim, dışarıdan denedim. Aynı sayfaya farklı User-Agent ile istek attım:

Googlebot        200
ChatGPT-User     403
PerplexityBot    403
bingbot          403

Yani iki haftalık iş, botların okuyamadığı sayfalara gitmişti.

Kural nereden gelmiş

Cloudflare'ın AI Crawl Control ekranında tek bir "Block" düğmesi bu kuralı üretiyor. Muhtemelen aylar önce "yapay zekâ içeriğimi çalmasın" refleksiyle basılmış. O gün mantıklıydı; bugün aynı düğme müşteriyi getirecek botu da kapı dışarı ediyor.

Bir de ikinci katman vardı: Güvenlik ayarlarındaki yönetilen "Block AI bots" kuralı. Özel kuralı düzelttikten sonra bile arama botları 403 almaya devam etti, bunu da kapatınca açıldı.

Ne yaptım

Kuralı silmedim, daralttım. Eğitim için tarayan botlar (GPTBot, ClaudeBot, CCBot, Bytespider) hâlâ engelli. Arama ve canlı çekim yapanlar (ChatGPT-User, OAI-SearchBot, Claude-SearchBot, PerplexityBot, bingbot) serbest. Sonra aynı testi tekrarladım:

ChatGPT-User     200
OAI-SearchBot    200
PerplexityBot    200
bingbot          200
GPTBot           403
ClaudeBot        403

Ders

İçerik yazmadan önce kapıyı kontrol et. Sitenizde Cloudflare varsa Güvenlik > Kurallar ve Güvenlik > Ayarlar > Bot trafiği bölümlerine bir kez bakın. "AI" kelimesi geçen her engel, arama botunu da engelliyor olabilir.

Bir hafta sonra tekrar ölçeceğim. Botların yeniden ne zaman geleceğini bilmiyorum; ilk sonuçlar düşük çıkarsa buraya onu da yazarım.