Makale Yaklaşan WCAG Değişiklikleri Hakkında Bilinmesi Gerekenler

Yayınlanan: 2022-10-07

2022 yılının Eylül ayında, W3C, WCAG'nin bir sonraki versiyonunun aday tavsiye statüsüne ulaştığını duyurdu. Onbirinci saat değişiklikleri dışında, standardın 2.2 sürümü yakında onaylanmalıdır. Değişiklikler nispeten küçüktür, ancak bir web sitesinin yapımından veya bakımından sorumlu olan herkes neyin geleceğini bilmelidir.

WCAG'a zaten aşina iseniz, genel bakışı atlayabilir ve doğrudan inek ayrıntılarına atlayabilirsiniz, aksi takdirde okumaya devam edebilirsiniz.

WCAG nedir ve Neden Önemlidir?

Web İçeriği Erişilebilirlik Yönergeleri (WCAG), web geliştiricilerinin, tasarımcılarının ve içerik yöneticilerinin web sitelerinin çok çeşitli engelleri olan kişiler tarafından erişilebilir olmasını sağlamalarına yardımcı olmak için tasarlanmış bir dizi kriterden oluşur. W3C'nin Web Erişilebilirlik Girişimi ekibi standarttan sorumludur. W3C ve WAI, web'i daha erişilebilir hale getirmeye odaklanan sektör liderleri ve konu uzmanlarından oluşan bir konsorsiyumdan oluşur.

WCAG, erişilebilirliğin dört ilkesi altında düzenlenmiştir. Bu ilkeler, bir web sitesinin algılanabilir, çalışabilir, anlaşılabilir ve sağlam olması gerektiğini belirtir. Bu ilkelerin her birinde temel hedefleri tanımlayan yönergeler bulunur. Her kılavuzda, web sitesi geliştiricilerinin WCAG uyumlu olması için karşılaması gereken belirli, ölçülebilir bir hedefi tanımlayan başarı kriterleri bulunur.

Başarı kriterlerinin her birinin A, AA veya AAA uygunluk düzeyi göstergesi vardır. A Düzeyi kriterleri daha kolay karşılanırken, AAA en katı olanıdır.

Web Sitem WCAG 2.2 AA Uyumlu Değilse Dava Açar mıyım?

Kesin cevap "belki" dir.

ABD'de yasalar belirsizdir ve ADA web sitelerini açıkça ele almaz. Fiziksel bir alanda yapılması gereken konaklamalarla ilgili çok özel yasalar olsa da, ADA'nın doğrudan web sitelerine uygulanabileceğini söylediği tek şey, bir şirketin "tesislerinin erişilebilir olması gerektiği"dir. O zaman bile, tüm mahkemeler bir web sitesinin bir şirketin tesisi olarak sayılıp sayılmadığı konusunda hemfikir değildir ve hiçbir yerde net bir "erişilebilir" tanımı yoktur. Özel şirketlerin web siteleri ve federal yasalar hakkında konuştuğumuzu unutmayın. Federal ve bazı eyalet hükümeti web siteleri için geçerli yasalar vardır.

"Erişilebilir"in net bir tanımı olmadığından, bir web sitesi oluştururken veya bakımını yaparken ne yapacağımızı bize söylemesi için WCAG'a bakıyoruz. Hiçbir ABD kanunu, genel web siteleri için WCAG'ın (veya başka bir standardın) herhangi bir sürümünü özel olarak önermez. Ancak, WCAG başarı kriterlerinin herhangi bir versiyonunu karşılamaya çalışmak iyi bir hedeftir. Herkes için makul bir şekilde erişilebilir bir siteye yönlendirmelidir.

Standartlar Nasıl Geliştirilir?

Popüler inanışın aksine, standart geliştirme bir fildişi kulesinde seçilmiş bir avuç katılımcı tarafından gerçekleştirilmez. İşlerin çoğu üye kuruluşların çalışanları tarafından yapılırken, işin büyük bir kısmı davetli uzmanlar ve konuyla ilgili tutkulu ve zaman ayırmaya istekli diğer kişilerden geliyor. Ayrıca, birçok standart ekibinin, genel olarak topluluk üyelerinin sorular sorarak veya yeni konular gündeme getirerek katılmaya teşvik edildiği halka açık forumlar vardır.

WCAG için, halk yeni bir konu açarak, bir çekme talebi açarak veya Github'daki WCAG deposundaki mevcut tartışmalara katılarak standartlar hakkında okuyabilir ve yorum yapabilir. Gruba bir fikirle gelirken, fikrinizin henüz masaya getirilmediğinden emin olmak için mevcut tüm sorunları araştırmak ve istekleri çekmek her zaman akıllıca olacaktır. WCAG'a bir çekme talebi ile katkıda bulunmayı düşünüyorsanız, her zaman bir konu açmak için zaman ayırın ve önce fikrinizi tartışın. Kendinizi gereksiz işlerden kurtarmanız için çok iyi bir şans var.

Standartlara katkıda bulunmak sinir bozucu ve zor olabilir, ancak aynı zamanda çok faydalıdır. Çoğunlukla, katılımcılar çok misafirperver ve sabırlıdır. Fikirlerinizi araştırmak için zaman ayırır, gereken özeni gösterir ve başkalarına karşı kibar ve saygılı davranırsanız, katkılarınız memnuniyetle karşılanacaktır. Mümkün olan en kötü sonuç, konuya, mümkün olduğunu düşündüğünüzden daha fazla aşina olmanızdır.

Ne Değişiyor?

WCAG 2.2'de mevcut bir başarı kriteri değişti ve dokuz yeni başarı kriteri eklendi. AAA'yı nadiren hedeflediğimiz için burada kendimizi sadece A ve AA Düzeyleri ile sınırlayacağız. Tüm yeni kriterleri görmek için W3C'deki makalenin tamamına göz atın,

2.4.7 Odak Görünür (A)

Bu kriter, AA Düzeyinden WCAG uyumluluğu için en düşük çubuk olan A'ya değişmiştir. Var olmasının bir nedeni, çok da uzak olmayan bir geçmişte, odak halkalarını kaldırmak için web siteleri oluşturan insanlar için yaygın bir uygulama olmasıdır. Sonuçta, tasarımın bir parçası değildiler. Bu, klavyeleriyle bir web sayfasında gezinen kullanıcıların bir sayfada nerede olduklarını göremedikleri anlamına geliyordu. Bu kriterin tek-A'ya taşınması mantıklıdır, çünkü bu kadar çok sayıda kullanıcı, herhangi bir bozulma olmaksızın bile klavye navigasyonuna bağımlıdır.

Tüm büyük web tarayıcıları, varsayılan olarak odak halkalarını görüntüler. Buradaki temel gereksinim, yerleşik işlevselliği bozmamaktır.

W3C – Odak Görünürlüğünü Anlamak

2.4.11 Odak Görünümü (AA)

Bu yeni kriter, odak halkalarının görünürlüğü hakkında bazı açıklayıcı kurallar tanımlar. Çevreleyen pikseller ve değiştirdikleri piksellerle 3:1 kontrast oranına sahip olmalıdırlar. Ayrıca, odaklanılan öğeyi veya alt bileşeni çevrelemeli veya öğenin en kısa kenarı boyunca 4 piksel kalınlığında bir çizgi kadar büyük olmalıdırlar.

WCAG standartlarını karşılayan bir odak halkası örneği (kaynak: w3.org)
WCAG standartlarını karşılamayan bir odak halkası örneği (kaynak: w3.org)

Yine, tarayıcının varsayılan odak halkaları genellikle bu kriteri karşılayacaktır. Kullanıcılar varsayılanlara alıştığından, bunları yalnızca gerekirse geçersiz kılmalısınız. Varsayılan odak halkası ile markanızın ana rengi arasında yetersiz renk kontrastı olması buna bir örnek olabilir. Tarayıcılar genellikle varsayılan olarak mavi odak halkalarına sahiptir, bu nedenle markanızın paletinde mavi varsa, bir çakışma olabilir.

W3C – Odak Görünümünü Anlama

2.4.12 Odak Gizlenmemiş (Minimum) (AA)

Bu kriter, odağın kullanıcı tarafından oluşturulan içerik tarafından tamamen gizlenmemesi gerektiğini belirtir. Bu, yapışkan gezinme (kullanıcı kaydırırken pencerenin üst kısmında kalan bir menü çubuğu) gibi katmanlı içeriğin odak göstergelerini kapatmasını önlemek içindir.

Buradaki en kolay düzeltme, herhangi bir yapışkan öğeye sahip olmamaktır. Bununla birlikte, modern web siteleri, yapışkan gezinme ve kayan CTA'ları özgürce kullanır, bu nedenle bu muhtemelen bir seçenek değildir. Kaydırma dolgusu ve kaydırma marjı CSS özelliklerinin bir gün yapışkan gezinmeyi barındıracak bir ofset tanımlamamıza izin vereceğine dair bazı beklentiler var. Şimdilik, bu özellikler yalnızca kaydırmalı yakalamadan yararlanan öğelerde kullanılmaktadır.

Bu bize JavaScript'i bırakıyor. Genel olarak amacımız, tarayıcıda yalnızca gerektiğinde JavaScript kullanmaktır. Bu StickyFix işlevi, ana öğenin içindeki odaklanabilir öğeleri izleyecek ve odaklandıklarında yapışkan gezinme tarafından gizlenirlerse, görünüme kaydırılacaktır.

Bu işlevi kullanmak için sitenizin JavaScript dosyalarına eklemeniz yeterlidir.

 /** * A minimal function that will detect if a focusable element is obscured by sticky navigation * This only works for sticky elements at the top of the page, but could be extended * @author Donovan Buck <[email protected]> * @param {string} selector - A valid CSS selector string for the sticky element * @param {number} offset - An additional offset for the focused element * * @see https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Selectors * @tutorial https://www.brandextract.com/Insights/Articles/Changes-to-the-Web-Content-Accessibility-Guidelines/ * @license MIT */ function stickyFix(selector, offset = 0) { // Find the height of our sticky element const sticky = document.querySelector(selector); let stickyRect = sticky.getBoundingClientRect(); let stickyHeight = stickyRect.bottom - stickyRect.top; // Select all the focusable elements within the main element const focusables = document.querySelectorAll('main button:not([disabled]), main [href], main input:not([disabled]), main select:not([disabled]), main textarea:not([disabled]), main [tabindex]:not([tabindex="-1"]):not([disabled]), main details:not([disabled]), main summary:not(:disabled)'
); // Add a listener to each focusable element focusables.forEach(focusable => { focusable.addEventListener('focus', (event) => { const targetRect = event.target.getBoundingClientRect(); if(targetRect.top < stickyHeight + offset) { window.scrollTo({ top: targetRect.top + window.scrollY - stickyHeight - offset }); } }); }); };

Daha sonra işlevi çağırabilirsiniz:

 // Wait for the document to load document.addEventListener("DOMContentLoaded", function() { stickyFix('.sticky', 24); });

Odağı Anlama Gizlenmemiş (Minimum)

2.5.7 Sürükleme Hareketleri (AA)

Bu kriter, sürükleme hareketleri kullanıcı arayüzünün bir parçasıysa, basit işaret ve tıkla eylemlerine izin veren alternatif bir yöntemin sağlanması gerektiğini belirtir. Buna bir örnek, kullanıcıların yükleme için bilgisayarlarından tarayıcıya dosyaları sürükleyip bırakmalarına izin veren bir form olabilir. Bir kullanıcının hangi dosyaların yükleneceğini seçmek için dosya yükleme iletişim kutusunu da kullanabilmesini sağlamalısınız. Bu istisna dışında, çoğu web sitesi kullanıcı arayüzünde sürükleme hareketleri genellikle gerekli değildir.

Sürükleme Hareketlerini Anlama

2.5.8 Hedef Boyutu (Minimum) (AA)

Hedef her bitişik hedeften en az 24 piksel uzakta değilse veya hedef bir cümle veya metin bloğunda değilse, herhangi bir işaretçi hedefi en az 24 x 24 piksel olmalıdır. Bu kriterler için bir tasarımı kontrol ederken, yalnızca simgeleri ve tüm gezinme listelerinizi kullanan sosyal paylaşım bağlantılarını kontrol etmeye çok dikkat edin.

Başarısız bir örneğe karşı hedef boyutları geçmenin üç örneği (kaynak: w3.org)

Hedef Boyutu Anlama (Minimum)

3.2.6 Tutarlı Yardım (A)

Web sitenizin iletişim bilgileri, kendi kendine yardım seçeneği veya birden çok sayfada görünen herhangi bir iletişim mekanizması içerdiğini varsayalım. Bu durumda, bu öğeler sitenizdeki diğer sayfa içeriğine göre aynı sırada görünmelidir. Bu, büyük ölçüde iyi ve tutarlı tasarımın bir işlevidir ve bu kriterin karşılanması zor olmamalıdır.

Tutarlı Yardımı Anlama

3.3.7 Erişilebilir Kimlik Doğrulama (AA)

Bir kullanıcıyı bir kullanıcı adı ve parolayı hatırlamaya zorlamak, bilişsel engelli kişiler için gereksiz bir yük oluşturabilir. Bu nedenle, web geliştiricileri asla şifre yöneticilerinin kullanımına veya kopyala-yapıştır kullanımına izin vermeyen bir oturum açma işlemi oluşturmamalıdır. Bu kriter, parola hatırlama veya bulmaca çözme gibi bilişsel bir işlev testine bağlı olmadığı sürece alternatif kimlik doğrulama yöntemlerine izin verir.

Erişilebilir Kimlik Doğrulamayı Anlama

3.3.9 Fazla Giriş (A)

Bu kriter, aynı işlem sırasında kullanıcı tarafından daha önce girilen bilgilerin otomatik olarak doldurulacağını veya bilgileri manuel olarak yeniden girmek zorunda kalmadan kullanıcı tarafından seçilebileceğini belirtir. Açıkçası, bu herkes için beklenen bir kolaylık olmalıdır.

Fazla Girişi Anlama

Referanslar

  • WCAG 2.2 Taslağındaki Yenilikler
  • W3C'nin Github'daki WCAG deposu