WCAG 2.5.6: Eşzamanlı Girdi Mekanizmaları

Bu Kuralın Anlamı

\n

WCAG 2.5.6 — Eşzamanlı Girdi Mekanizmaları, WCAG 2.2 kapsamında Seviye AAA başarı ölçütüdür. Temel gereksinimi basittir: web içeriği, kullanıcının birden fazla girdi mekanizmasını aynı anda veya birbirinin yerine kullanma yeteneğini kısıtlamamalı veya buna müdahale etmemelidir. Pratikte bu, bir web sayfası veya uygulamanın, kullanıcının o anda hangi girdi aygıtını kullandığını programatik olarak tespit edip onu tek bir modaliteye kilitleyemeyeceği, diğer mevcut girdi yöntemlerine erişimini reddedemeyeceği anlamına gelir.

\n

Modern cihazlar zengin bir girdi mekanizması çeşitliliğini destekler: fiziksel klavyeler, fareler ve izleme dörtgenleri, dokunmatik ekranlar, kalemler, anahtarlama kontrolleri, sesli giriş, göz takibi ve daha fazlası. Birçok kullanıcı aynı anda bunlardan birden fazlasına güvenir — örneğin, dokunmatik ekranlı bir dizüstü bilgisayar kullanıcısı, dokunmatik yüzey ile parmakla dokunma arayüzü arasında akıcı biçimde geçiş yapabilir. İleri düzey bir kullanıcı, bir formda klavye ile gezinirken fareyi kaydırma için kullanabilir. Motor engeli olan bir kişi, baş işaretçisi ile anahtar cihazını birlikte kullanabilir. Ölçüt, bu iş akışlarının tümünü korur.

\n

Başarısızlık, bir web sitesi kullanılan girdi türünü tespit etmek için JavaScript kullandığında ve ardından diğer girdi türleri için işlevselliği kaldırdığında veya devre dışı bıraktığında ortaya çıkar. Örneğin, bir site bir dokunma olayını tespit eder ve ardından klavye odak göstergelerini kaldırır veya klavye ile gezinmeyi devre dışı bırakırsa, bu doğrudan bir ihlaldir. Benzer şekilde, klavye kullanımı tespit edildikten sonra işaretçi girdisini engellemek veya platform API’lerini kullanarak girdiyi yapay olarak tek bir modaliteyle sınırlamak da başarısızlık teşkil eder.

\n

Başarı, kullanıcılar etkileşimleri boyunca istedikleri anda mevcut tüm girdi mekanizmalarıyla etkileşime girebildiklerinde söz konusudur. İçerik, kullanıcının herhangi bir anda kullanmayı seçtiği girdi mekanizmasına, sayfayı yeniden yükleme, mod değiştirme veya bir girdi türünü yeniden etkinleştirmek için ek bir kullanıcı eylemi gerektirmeden doğru şekilde yanıt vermelidir.

\n

Ölçütte WCAG’de tanımlanmış resmi bir istisna vardır: kısıtlama zorunlu olduğunda — yani belirli bir girdi modalitesinin doğası gereği gerekli olduğu durumlarda — izin verilir. Klasik bir örnek, dokunma veya kalem girdisinin işlevselliğin bizzat kendisi olduğu el yazısı tanıma uygulamasıdır. Diğer bir örnek, belirli bir işaretçi girdisi gerektiren dijital imza alanı olabilir. Bu durumlarda bile istisna dar yorumlanmalı ve yazar, mümkün olan her yerde görevi tamamlamak için alternatif yollar sağlamalıdır.

\n

Bu ölçütün, yazarlardan cihazın sahip olmadığı girdi mekanizmalarına destek eklemelerini istemediğini not etmek önemlidir. Cihazın ve platformun hâlihazırda desteklediği mekanizmalara getirilen kısıtlamaları düzenler. Bir cihazda dokunmatik ekran yoksa, kısıtlanacak bir şey de yoktur.

\n\n

Neden Önemlidir

\n

Eşzamanlı veya birbirinin yerine kullanılabilir girdi mekanizmalarını kullanma özgürlüğü bir konfor özelliği değildir — birden fazla farklı kullanıcı grubunu doğrudan etkileyen kritik bir erişilebilirlik gereksinimidir.

\n

Motor engeli olan kullanıcılar sıklıkla birden fazla girdi mekanizmasını birleştiren yardımcı teknolojilere güvenir. El hareketliliği sınırlı bir kişi, ekrandaki klavye ile birlikte nefesle çalışan bir anahtar cihazı kullanabilir. Titremesi olan biri, bir sayfada gezinmeye klavye ile başlayıp bir klavye kısayolu başarısız olduğunda fare veya dokunmatik arayüze geçebilir. Bir web sitesi bir girdi türünü tespit eder ve diğerlerini devre dışı bırakırsa, bu kullanıcılar içerikten veya işlevsellikten tamamen mahrum kalabilir.

\n

Bilişsel veya öğrenme güçlüğü olan kullanıcılar genellikle belirli bir görev için en rahat veya en doğal gelen girdi yöntemini seçebilme yeteneğinden fayda sağlar. Tek bir modaliteye zorlamak bu seçimi ortadan kaldırır ve özellikle kullanıcı cihazın birincil girdi yönteminde yetkin değilse gereksiz bilişsel yük getirebilir.

\n

Yaşlı yetişkinler, yaşa bağlı motor zorluklara sahip olabilir ve giderek hem dokunma hem de klavye girdisini destekleyen cihazlar kullanmaktadır. İnce motor kontrol gün boyunca dalgalanırken bu mekanizmalar arasında geçiş yapabilme yeteneği, web’i sürdürülebilir biçimde bağımsız kullanmak için önemlidir.

\n

Güçlü kullanıcılar ve çok modlu cihaz kullanıcıları — örneğin Surface Pro veya iPad Pro kullanıcıları — aynı cihazda aynı oturumda düzenli olarak klavye, kalem ve dokunmatik arayüz kullanır. Dokunma girdisini tespit edip klavye kısayollarını kaldıran veya tam tersi davranan bir web sitesi, kendini engelli olarak tanımlamayan çok büyük bir kullanıcı kitlesinin deneyimini kötüleştirir.

\n

Şu gerçek dünya senaryosunu düşünün: Bir Türk bankasının çevrimiçi portalı, müşterinin dokunmatik ekranlı bir tablet kullandığını tespit eder ve klavye ile gezinmeyi devre dışı bırakan bir “mobil moda” geçer. Tableti Bluetooth klavye ile kullanan motor engelli bir müşteri artık form alanları arasında sekme ile dolaşamaz, menülerde ok tuşlarıyla gezemez veya klavye kısayollarını kullanamaz. Bankacılık işlemlerini bağımsız olarak tamamlayamaz. Bu yalnızca bir erişilebilirlik başarısızlığı değil, aynı zamanda Türk erişilebilirlik düzenlemeleri kapsamında potansiyel bir hukuki risktir.

\n

Kullanılabilirlik ve SEO açısından, eşzamanlı girdi mekanizmalarına saygı göstermek daha iyi Core Web Vitals puanları, daha düşük hemen çıkma oranları ve farklı cihaz kategorilerinde daha yüksek kullanıcı memnuniyeti ile korelasyon gösterir — bunların tümü arama motorlarının ödüllendirdiği sinyallerdir.

\n\n

İlgili Axe-core Kuralları

\n

WCAG 2.5.6 manuel test gerektirir — bu ölçütün tüm ihlallerini güvenilir şekilde tespit edebilecek otomatik bir axe-core kuralı yoktur. Bunun nedeni temeldir: otomatik araçlar statik DOM ve CSS’i inceleyebilir ve belirli JavaScript kalıplarını tespit edebilir, ancak farklı girdi modalitelerine gerçek bir kullanıcı oturumu sırasında yanıt verirken olay dinleyicilerinin çalışma zamanı davranışını tam olarak gözlemleyemezler. Bir girdi mekanizmasını kısıtlama kararı genellikle yalnızca belirli olaylara yanıt olarak çalışan uygulama mantığına kodlanmıştır; bu da statik analizi yetersiz kılar.

\n

\n
• 2.5.6 için özel bir otomatik axe-core kuralı yoktur. Axe-core, eşzamanlı girdi mekanizması kısıtlamalarını özel olarak kontrol eden bir kural sunmaz; çünkü ihlal, yapısal bir HTML veya ARIA sorunu yerine dinamik JavaScript davranışı olarak ortaya çıkar. Bir sayfa tüm otomatik axe kontrollerini geçebilir ve yine de, olay işleyicileri çalışma zamanında girdi modalitelerini programatik olarak kaldırır veya devre dışı bırakırsa 2.5.6’yı ihlal edebilir.
\n
• İşaretçi olayları ve dokunma olayı tespiti: Axe-core kısıtlamanın kendisini yakalayamasa da, manuel denetçiler touchstart veya pointerdown olaylarını dinleyen ve ardından DOM’u değiştiren, odak yönetimini kaldıran veya klavye davranışını değiştiren bayraklar ayarlayan JavaScript’i aramalıdır. Benzer şekilde, dokunma hedeflerini gizleyen CSS sınıf değişikliklerini tetikleyen keydown dinleyicileri manuel inceleme için uyarı işaretleridir.
\n
• Otomasyon neden yetersiz kalır: Otomatik tarayıcılar belgeyi belirli bir anda analiz eder. Girdi mekanizması kısıtlamaları koşulludur — yalnızca belirli bir girdi olayı tetiklendikten sonra etkinleşirler. Kullanıcı etkileşiminden önce çalışan bir tarayıcı, bir touchstart işleyicisinin daha sonra document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) çağıracağını ve klavye ile gezinmeyi fiilen yok edeceğini göremez. Yalnızca her iki girdi modalitesini de sırayla kullanan bir insan testçi bu başarısızlığı keşfedebilir.
\n

\n\n

Nasıl Test Edilir

\n

\n
1. Otomatik temel tarama: Sayfada bir temel seviye oluşturmak ve eşzamanlı görülen diğer sorunları yakalamak için axe DevTools veya Lighthouse çalıştırın. Her iki aracın da özel bir 2.5.6 kuralı olmasa da, axe DevTools’un en iyi uygulama kontrolleri, girdi kısıtlamasının belirtisi olan klavye tuzaklarını veya odak yönetimi sorunlarını işaretleyebilir. Aşağıdaki manuel kontrollerle birlikte giderilmek üzere tüm başarısızlıkları not edin.
\n
2. JavaScript kaynağını ve olay dinleyicilerini inceleyin: Chrome DevTools’u açın, Elements paneline gidin ve Event Listeners bölmesini kullanarak touchstart, pointerdown, pointermove veya MSPointerDown dinleyicilerinin document veya body’ye eklenip eklenmediğini inceleyin. Console’da, DOM değişiklikleriyle birleştirilmiş ontouchstart in window, navigator.maxTouchPoints veya 'pointer' in navigator gibi kalıplar için sayfanın JavaScript kaynağını arayın. Bunlar, girdi modalitesini tespit etmek ve işlevselliği sınırlandırmak için kullanılan yaygın tekniklerdir.
\n
3. Çoklu modalite etkileşim testi (klavye + dokunma): Hem dokunma hem de klavye girdisini destekleyen bir cihazda (ör. Surface, klavyeli iPad veya dokunmatik ekranlı dizüstü bilgisayar), sayfada yalnızca klavye ile gezinmeye başlayın (Tab, Shift+Tab, Enter, Space, ok tuşları). Hangi etkileşimli öğelere ulaşılabildiğini ve işlevsel olduğunu not edin. Ardından, sayfayı yeniden yüklemeden dokunma ile gezinmeye geçin — bağlantılara, düğmelere ve form kontrollerine dokunun. Klavye ile erişilebilen tüm işlevlerin dokunma ile de erişilebilir kaldığını ve tam tersini doğrulayın. Geçişten sonra ulaşılamaz veya işlevsiz hale gelen tüm öğeleri belgeleyin.
\n
4. Ekran okuyucu ile birleşik girdi testi: NVDA ve Firefox kullanarak, ekran okuyucu modunu etkinleştirmek için sayfada klavye ile gezin. Ardından, (varsa) dokunmatik ekranı kullanarak aynı öğelerle etkileşim kurmayı deneyin. Hem ekran okuyucunun hem de sayfanın her iki girdiye de doğru yanıt verdiğini doğrulayın. Bunu, iPad’de Safari üzerinde VoiceOver ile, hem dokunma hareketlerini hem de eşleştirilmiş bir Bluetooth klavyeyi kullanarak tekrarlayın. Chrome üzerinde JAWS ile, klavye ve fare arasında geçiş yapmanın odak yönetimini bozmadığını veya etkileşimli öğelerin kullanılamaz hale gelmesine neden olmadığını doğrulayın.
\n
5. Modalite kilitleme kalıpları için kod incelemesi: Sayfada kullanılan JavaScript kütüphanelerini veya framework’lerini, yerleşik modalite tespiti açısından manuel olarak inceleyin. Özellikle eski mobil öncelikli framework’ler olmak üzere bazı UI kütüphaneleri, dokunma tespit edilen cihazlarda fare veya klavye olaylarını devre dışı bırakan kod içerir. Bu tür davranışlar için kütüphane dokümantasyonunu ve kaynağını kontrol edin ve bunların geçersiz kılındığını veya devre dışı bırakıldığını doğrulayın.
\n
6. Dinamik etkileşimlerden sonra yeniden test: Önemli DOM değişikliklerini tetikleyen işlemler gerçekleştirin — modal açmak, tek sayfa uygulaması rotalarında gezinmek, formları göndermek — ve her geçişten sonra çoklu modalite testini yeniden çalıştırın. Kısıtlamalar bazen yalnızca belirli uygulama durumlarında devreye girer.
\n

\n\n

Nasıl Düzeltilir

\n

Dokunmayı tespit edip klavye ile gezinmeyi devre dışı bırakma — Hatalı

\n

<!-- JavaScript dokunmayı tespit eder ve tüm tabindex değerlerini kaldırır,\n     girdi modlarını değiştiren kullanıcılar için klavye ile gezinmeyi bozar -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Dokunmayı tespit edip klavye ile gezinmeyi devre dışı bırakma — Doğru

\n

<!-- Dokunma tespitine dayanarak klavye erişilebilirliğini kısıtlamayın.\n     Her iki girdi modalitesinin de eşzamanlı çalışmasına izin verin.\n     Estetik için odak stillerini yönetmeniz gerekiyorsa, tabindex\n     kaldırmak yerine :focus-visible CSS pseudo-class kullanın. -->\n<style>\n  /* Klavye ile gezinme için odak halkalarını gösterin, fare tıklamaları için değil,\n     klavye erişimini tamamen kaldırmadan */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- JavaScript modalite tespiti gerekmez -->

\n\n

İşaretçi olayı kullanılarak klavye olaylarının bastırılması — Hatalı

\n

<!-- Özel bir kaydırıcı, işaretçi girdisi aldıktan sonra\n     klavye ok tuşlarına yanıt vermeyi durdurur ve kullanıcıyı\n     yalnızca işaretçi etkileşimine kilitler -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // işaretçi etkileşiminden sonra klavye devre dışı\n    if (e.key === 'ArrowRight') { /* artır */ }\n    if (e.key === 'ArrowLeft') { /* azalt */ }\n  });\n</script>

\n

İşaretçi olayı kullanılarak klavye olaylarının bastırılması — Doğru

\n

<!-- Hem işaretçi hem de klavye etkileşimleri bağımsız olarak ele alınır.\n     Biri kullanıldıktan sonra diğerinin çalışmasını engelleyen hiçbir bayrak\n     ayarlanmaz. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // İşaretçi işleyicisi — her zaman etkin\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // yeni değeri işaretçi konumundan hesapla\n    }\n  });\n\n  // Klavye işleyicisi — her zaman etkin, işaretçi kullanımıyla devre dışı bırakılmaz\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Mobil framework’ün fare olaylarını otomatik devre dışı bırakması — Hatalı

\n\n

(İçerik, belirteç sınırı nedeniyle kısaltıldı — lütfen bu makaleyi yeniden deneyin.)