Önce özete göz atDersin sonundaki özet, okumaya başlamadan önce yol haritası olarak.
- Renk bilgi taşıyorsa, aynı bilgi en az bir başka kanaldan da verilir; WCAG 1.4.1 renk kullanmayı değil, rengin tek araç olmasını yasaklar.
- Hatalı form alanı, altında sorunu ve çözümü söyleyen bir cümle, bir simge, kalınlaşan bir kenar ve alana programatik olarak bağlanmış bir hata metniyle işaretlenir; bağlantılar alt çizgiyle, grafikler doğrudan etiketle, durum göstergeleri biçim ve sözcükle desteklenir.
- Gri tonlama, renk görme benzetimi ve ekran okuyucu testleri renk bağımlılığını ortaya çıkarır; yalnız renk tonuyla ayrılan fondöten alt tonları gibi ten tonuna bağlı seçimler, numara, sözcük ve biçimle kodlanır.
Kısa cevap
Bir arayüzde renk bilgi taşıyorsa, aynı bilgi en az bir başka yoldan da taşınmalıdır: bir şekil, bir simge, bir metin, bir desen ya da bir konum. Hatalı bir form alanı yalnız kırmızı kenarla değil, alanın hemen altında sorunu tarif eden bir cümleyle, bir uyarı simgesiyle ve ekran okuyucunun duyacağı bir işaretle gösterilir. Aynı ilke bağlantılar için alt çizgiyi, grafikler için doğrudan etiketleri, durum göstergeleri için simge ve yazıyı gerektirir; renk bu işaretlerin yanında yardımcı bir ses olarak kalır.
Renk bir kanal, tek kanal değil
BI-12, kırmızı–yeşil renk görme eksikliğinin Avrupa kökenli erkeklerde yaklaşık yüzde sekiz oranında görüldüğünü anlattı. Bu, renkle kodlanmış bir arayüzün her gün önemli sayıda kullanıcıya eksik bilgi verdiği anlamına gelir. Ama sorun yalnız renk görme farklılığı değildir. Güneşin altında parlayan bir telefon ekranı, gri tonlamalı bir yazıcı, gece kipinde renkleri kısılmış bir ekran ya da yalnız sesle çalışan bir ekran okuyucu da rengi kaybeder.
Durum renklerinde (UX-02) ve fotoğraf seçiminde (UX-04) bu ilkenin tek tek örneklerini kurduk. Bu ders ilkenin kendisini ele alıyor ve dört yaygın yerde nasıl uygulandığını gösteriyor: form hataları, bağlantılar, lejantlar ve durum göstergeleri.
UX-02'de andığımız 1.4.1 ölçütünün özü tek cümledir: renk kullanmak serbesttir, rengi yalnız bırakmak değildir.
Hatalı form alanı
Kartın sorusu: bir formdaki hatalı alanı renk dışında nasıl işaretlersiniz?
Önce ölçütün ne istediğine bakmak yararlıdır. 3.3.1 «Error Identification» ölçütü, bir giriş hatası otomatik olarak algılanırsa hatalı öğenin tanımlanmasını ve hatanın kullanıcıya metinle anlatılmasını ister. Anahtar sözcük «metin»dir: hata bir renk değişikliği değil, okunabilir bir açıklamadır.
İyi işaretlenmiş bir hatalı alan katmanlardan oluşur. Alanın hemen altında, sorunu ve çözümü söyleyen bir cümle durur: «E-posta adresinde @ işareti eksik.» «Geçersiz giriş» gibi genel bir cümle yetmez, çünkü kullanıcıya ne yapacağını söylemez. Cümlenin yanında bir uyarı simgesi bulunur; simge, renk görülmese de bir sorun olduğunu biçimiyle söyler. Alanın kenarı yalnız renk değiştirmez, kalınlaşır; böylece tonları karıştıran bir göz de kenarın değiştiğini fark eder. Etiket korunur ve hata cümlesi etiketin yerine geçmez: kullanıcı alanın ne istediğini de, ne yanlış gittiğini de aynı anda okur.
Görünmeyen bir katman daha vardır. Ekran okuyucu kullanan biri kırmızı kenarı hiç görmez; alanın hatalı olduğu ve hata cümlesinin o alana ait olduğu kodda işaretlenmelidir. Web'de bu, alanın geçersiz olarak işaretlenmesi ve hata metninin alana programatik olarak bağlanmasıyla yapılır. Birden fazla hata varsa, formun en üstünde hataların listelendiği ve her birinin ilgili alana götürdüğü bir özet de kullanıcının neyi düzelteceğini tek bakışta görmesini sağlar.
Kolay bir kontrol, gri tonlama testiyle başlar: formu gri tonlamada ve kırmızı–yeşil renk görme eksikliği benzetiminde açın, ardından ekran okuyucuyla dinleyin. Üç durumda da hangi alanın hatalı olduğu ve neden hatalı olduğu anlaşılıyorsa, hata renge bağlı değildir.
Bağlantının altı çizgisi
Gövde metninin içindeki bir bağlantıyı yalnız renkle ayırmak, en sık görülen renk bağımlılıklarından biridir. HTML standardının önerdiği varsayılan görünüm bu sorunu baştan çözer: ziyaret edilmemiş bağlantılar #0000EE mavisiyle ve altı çizili gösterilir.
Alt çizginin neden önemli olduğunu hesap gösterir. Varsayılan #0000EE mavisi, siyah gövde metnine karşı yalnız yaklaşık 2,2:1 verir; G183'ün istediği 3:1'in altındadır. Varsayılan tasarım bu açığı alt çizgiyle kapatır. Alt çizgiyi kaldıran bir tasarımcı ise dar bir aralığa sıkışır. Gövde metni #1A1A1A gibi neredeyse siyahsa, bağlantı rengi hem beyaz zemine karşı 4,5:1 vermeli hem de gövde metnine karşı 3:1 vermelidir. Bu iki şart birlikte, bağlantının göreli parlaklığını yaklaşık 0,13 ile 0,18 arasındaki dar bir pencereye hapseder. #0066CC bu pencerenin içindedir: beyaza karşı yaklaşık 5,6:1, gövde metnine karşı yaklaşık 3,1:1 verir. #005A9C ise beyaz üzerinde daha iyi okunur, ama gövde metninden yalnız 2,4:1 ile ayrılır ve alt çizgi olmadan bağlantı olduğu belli olmaz.
G183 kendisi de bir not düşer: teknik ölçütü karşılamaya yeterlidir, ama yazarlar yine de alt çizgi ya da kalın yazı gibi ek bir işaret düşünebilir. Ziyaret edilmiş ve edilmemiş bağlantıların varsayılan renkleri ise birbirinden 1,17'ye bir gibi küçük bir oranla ayrılır; bu ayrım zaten neredeyse yalnız ton farkına dayanır ve kullanıcı için kritik bir bilgiyse, bir simge ya da yazıyla desteklenmelidir.
Lejantlar ve durum göstergeleri
Grafiklerde renk bağımlılığının en tanıdık biçimi, çizgilerin yalnız renkle ayrıldığı ve anlamlarının grafiğin köşesindeki bir lejantta verildiği düzendir. Okuyucu her çizginin rengini lejanttaki küçük bir kareyle eşleştirmek zorundadır; iki renk yakınsa bu eşleştirme tahmine döner.
Doğrudan etiketleme, desenler ve farklı işaret şekilleri, grafiklerde bu sorunun başlıca çözümleridir; nasıl uygulanacakları ve simülasyonla nasıl sınanacakları VG-07'nin konusudur. Arayüz açısından önemli olan, bir kontrol panelindeki küçük grafiklerin de bu kurala tabi olmasıdır: bir kullanıcının kendi verisini gösteren iki çizgi, yalnız renkle ayrılıyorsa, o kullanıcı kendi verisini okuyamayabilir.
Durum göstergeleri aynı sorunun kısaltılmış hâlidir. Bir listede her satırın başındaki küçük bir nokta yeşilse «etkin», sarıysa «beklemede», kırmızıysa «durdu» anlamına gelebilir. Üç nokta aynı boyutta ve aynı biçimdeyse, kırmızı ile yeşili karıştıran bir okur ve gri bir yazıcı çıktısı için üçü aynı şeydir.
Çözüm, her durumun biçimini de değiştirmektir: etkin için dolu bir daire ve bir onay işareti, beklemede için içi boş bir daire ya da bir saat simgesi, durdu için bir kare ya da çarpı. Yanına kısa bir sözcük eklenirse, simge de artık tek başına kalmaz. Bu, trafik ışıklarının da çözdüğü bir sorundur: renklerin yanında lambaların sırası da bilgiyi taşır.
Örnek — fondöten tonu seçici
Bir kozmetik mağazasının uygulaması, fondöten tonlarını yalnız renk karelerinden oluşan bir ızgarada gösteriyor. Tonlar açıklığa göre sıralanmış; aynı açıklık düzeyinde de sıcak ve soğuk alt tonlu iki kare yan yana duruyor. Karelerin altında hiçbir yazı yok.
Hesap, bu düzenin kimi zorladığını gösteriyor. #C68863 ile ondan tonu otuz derece kırmızıya kaydırılmış #D2807C, CIELAB'da neredeyse aynı açıklığa sahip; aralarındaki WCAG kontrast oranı 1,0:1. Aynı hesap daha koyu bir çift için, #8D5524 ile #9E483F için de aynı sonucu veriyor. Yani sıcak ve soğuk alt ton arasındaki fark yalnız renk tonunda yaşıyor: gri tonlamada iki kare birebir aynı, renk tonunu kırmızı–sarı ekseninde ayırt etmekte zorlanan biri için de ayrım zorlaşabiliyor. Üstelik ekran ayarları ve ortam ışığı bu küçük ton farkını telefondan telefona değiştiriyor.
Ekip ızgarayı çift kodlamayla yeniden kuruyor. Her karenin altına bir açıklık numarası ve bir alt ton sözcüğü yazılıyor: «24 · sıcak», «24 · soğuk». Alt tonlar ayrıca küçük bir biçimle de işaretleniyor: sıcak için bir daire, nötr için bir kare, soğuk için bir üçgen. Seçilen ton, UX-04'teki gibi yalnız karartmayla değil, bir onay işareti ve çerçeveyle gösteriliyor. Bu düzen, çok açıktan çok koyuya bütün tonlar için aynı biçimde çalışıyor. Sonuç, yazısız ızgarayla karşılaştırmalı olarak, farklı tenlerden ve farklı renk görme durumlarından kullanıcılarla sınanıyor.
Sık yapılan yanlış
Yaygın yanlış"Kırmızı kenar yeterli; herkes kırmızıyı hata olarak anlar."
Kırmızı kenar; tonları ayıramayan bir gözde, renksiz bir çıktıda ve sesli bir okuyucuda kaybolur ve sorunun ne olduğunu hiç söylemez; hata metinle anlatılmalı ve alana bağlanmalıdır.
Yaygın yanlış"Alt çizgi eski görünüyor; bağlantıyı renkle ayırmak yeterli."
Gövde metni koyuysa, hem zemine hem metne karşı yeterli kontrast veren bağlantı rengi dar bir aralıkta kalır; alt çizgi, bu aralığa sıkışmadan bağlantıyı herkes için tanınır kılar.
Özet
- Renk bilgi taşıyorsa, aynı bilgi en az bir başka kanaldan da verilir; WCAG 1.4.1 renk kullanmayı değil, rengin tek araç olmasını yasaklar.
- Hatalı form alanı, altında sorunu ve çözümü söyleyen bir cümle, bir simge, kalınlaşan bir kenar ve alana programatik olarak bağlanmış bir hata metniyle işaretlenir; bağlantılar alt çizgiyle, grafikler doğrudan etiketle, durum göstergeleri biçim ve sözcükle desteklenir.
- Gri tonlama, renk görme benzetimi ve ekran okuyucu testleri renk bağımlılığını ortaya çıkarır; yalnız renk tonuyla ayrılan fondöten alt tonları gibi ten tonuna bağlı seçimler, numara, sözcük ve biçimle kodlanır.
Kendini sına
- (Kolay) HTML standardının önerdiği varsayılan stilde ziyaret edilmemiş bağlantılar hangi renk ve biçimle gösterilir?
- (Kolay) 3.3.1 «Error Identification» ölçütü bir giriş hatası için ne ister?
- (Orta) Bir formdaki hatalı alanı renk dışında nasıl işaretlersiniz?
- (Orta) Bir grafikte lejant yerine doğrudan etiketleme neden renk bağımlılığını azaltır?
- (Zor) Gövde metni #1A1A1A iken alt çizgisiz bir bağlantının rengi neden dar bir aralıkta kalmak zorundadır?
- (Zor) Fondöten tonu seçicisindeki sıcak ve soğuk alt tonlu kareler neden yalnız renkle ayırt edilemez ve nasıl kodlanmalıdır?
Cevaplar
- #0000EE mavisiyle ve altı çizili («Bağlantının altı çizgisi»).
- Hatalı öğenin tanımlanmasını ve hatanın kullanıcıya metinle açıklanmasını («Hatalı form alanı»).
- Alanın hemen altına sorunu ve çözümü söyleyen bir cümle yazılır, yanına bir uyarı simgesi konur, kenar yalnız renk değiştirmez kalınlaşır ve etiket korunur. Alan kodda geçersiz olarak işaretlenir ve hata metni alana programatik olarak bağlanır; birden fazla hata varsa formun başında bağlantılı bir özet verilir («Hatalı form alanı»).
- Okuyucunun her çizginin rengini köşedeki küçük bir kareyle eşleştirmesi gerekmez; serinin adı serinin yanında durur ve renk görülmese de okunur («Lejantlar ve durum göstergeleri»).
- Bağlantı hem beyaz zemine karşı 4,5:1 hem de gövde metnine karşı 3:1 vermelidir; iki şart birlikte bağlantının göreli parlaklığını yaklaşık 0,13 ile 0,18 arasına sıkıştırır. #0066CC bu aralıktadır, #005A9C ve varsayılan #0000EE değildir («Bağlantının altı çizgisi»).
- #C68863 ile #D2807C gibi çiftler CIELAB'da neredeyse aynı açıklıktadır ve aralarındaki kontrast 1,0:1'dir; fark yalnız renk tonunda yaşar ve gri tonlamada kaybolur. Her karenin altına açıklık numarası ve alt ton sözcüğü yazılır, alt tonlar ayrıca daire, kare ve üçgen gibi biçimlerle işaretlenir («Örnek — fondöten tonu seçici»).
Kaynaklar
- W3C, «Web Content Accessibility Guidelines (WCAG) 2.2», 3.3.1 ve 1.4.1 başarı ölçütleri.
- W3C, «Technique G183: Using a contrast ratio of at least 3:1 to distinguish inline text links from surrounding text».
- W3C, «Technique F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision».
- WHATWG, «HTML Living Standard», Rendering bölümü.
Sonraki adım
UX-08 bu dersin gri tonlama ve benzetim alışkanlığını bir sınama sürecine dönüştürüyor: kontrast oranını otomatik ölçen araçların bir hatanın metinle anlatılıp anlatılmadığını neden göremediğini, yüksek kontrast kiplerinin tasarımı nasıl bozabildiğini ve az gören ya da yaşlı kullanıcılarla oturup izlemenin neyi gösterdiğini soruyor. UX-09 ise renkleri yazma biçimine geçiyor: CSS'teki oklch() ve color-mix() işlevleriyle, göreli renk sözdizimiyle ve geniş gamlı P3 renkleriyle ton skalası kurmayı ele alıyor.