WCAG 2.2.6: Zaman Aşımı

Bu Kuralın Anlamı

WCAG 2.2.6 Zaman Aşımı (Seviye AAA), kullanıcılar, kullanıcı hareketsizliğinin veri kaybına neden olabileceği herhangi bir sürenin uzunluğu konusunda uyarılmadıkça, verilerin 20 saatten fazla kullanıcı hareketsizliği boyunca korunmadığı durumları kapsar. Pratikte bu, web uygulamanız veya hizmetiniz, bir kullanıcının verilerini — örneğin form girişleri, bir alışveriş sepeti veya devam eden bir işlem — kullanıcının belirli bir süre boyunca hareketsiz kalması nedeniyle kaybedebiliyorsa, kullanıcıları bu verilerin kaybolmasına ne kadar süre kaldığı konusunda tam olarak bilgilendirmeniz gerektiği anlamına gelir.

Bu ölçüt, zaman aşımının veri kaybıyla sonuçlandığı her duruma uygulanır. Yaygın örnekler arasında form verilerini temizleyen banka veya devlet portallarındaki oturum süresinin dolması, belirli bir hareketsizlik süresinden sonra boşalan alışveriş sepetleri, oturum çerezi süresi dolduğunda sıfırlanan çok adımlı sihirbazlar veya formlar ve kısmi yanıtları atan çevrimiçi sınav veya rezervasyon sistemleri yer alır. Temel tetikleyici, hareketsizlik (bir görevi tamamlama için konulan katı bir zaman sınırı değil; bu 2.2.1 tarafından kapsanır) ile veri kaybı sonucunun birleşimidir.

Geçer sayılan durumlar: Bir sayfa, oturumun başında — veya kullanıcılar veri girmeye başlamadan önce — veri kaybına yol açacak belirli hareketsizlik zaman aşımı süresi hakkında kullanıcıları açıkça bilgilendiriyorsa 2.2.6’yı geçer. Alternatif olarak, kullanıcı ne kadar süre hareketsiz kalırsa kalsın veri kaybı meydana gelmiyorsa (örneğin, sunucu tüm form verilerini 20 saatten uzun süre veya süresiz olarak sakladığı için) sayfa yine geçer. Yalnızca oturum zaten sona erdikten sonra bir uyarı göstermek bu ölçütü karşılamaz.

Başarısız sayılan durumlar: Bir sayfa, kullanıcıyı bu risk hakkında hiçbir zaman bilgilendirmeden, belirli bir hareketsizlik süresinden sonra kullanıcı verilerini sessizce kaybediyorsa başarısız olur. Ayrıca, bir uyarı mevcutsa ancak yalnızca veri kaybı anında (artık harekete geçmek için çok geç olduğunda) gösteriliyorsa veya uyarı belirsizse — örneğin, zaman aşımını tetikleyen gerçek hareketsizlik süresini belirtmeden "oturumunuzun süresi dolabilir" diyorsa — yine başarısız olur.

Resmi istisnalar: Ölçüt, verilerin 20 saatten fazla hareketsizlik süresince korunduğu durumları açıkça muaf tutar. 20 saatlik eşik, bir göreve bir gün başlayıp ertesi gün devam eden kullanıcıları kapsamak için seçilmiştir. Sisteminiz, kullanıcıdan herhangi bir işlem gerektirmeden girilen tüm verileri sunucu tarafında en az 20 saat boyunca güvenilir şekilde saklıyorsa, bir uyarı göstermeniz gerekmez. Ayrıca, bu ölçüt, güvenlik için zorunlu olan zaman aşımlarına uygulanmaz — örneğin, kullanıcı eyleminden bağımsız olarak bir oturumun sabit bir süreden sonra sona ermesini zorunlu kılan bir yasa veya düzenleme gibi. Bu tür durumlarda ölçüt, yine de bilgilendirmeyi teşvik eder ancak yasal kısıtı kabul eder.

Neden Önemlidir

Yeterli uyarı olmadan gerçekleşen zaman aşımları, orantısız şekilde bilişsel engelli kişiler, motor bozukluğu olanlar ve kör veya az gören kullanıcıları etkiler. Disleksi, DEHB veya travmatik beyin hasarı gibi bilişsel engelleri olan kullanıcılar, talimatları okumak, metin yazmak veya bir formu göndermeden önce bilgileri gözden geçirmek için önemli ölçüde daha fazla zamana ihtiyaç duyabilir. Oturum, kullanıcı hâlâ çalışırken sessizce zaman aşımına uğrarsa, tüm emeklerini kaybederler ve baştan başlamak zorunda kalırlar — bu son derece cesaret kırıcı bir deneyimdir ve görevi tamamen bırakmalarına neden olabilir.

Switch erişimi, göz izleme cihazları veya diğer alternatif giriş yöntemlerine güvenen motor engelli kişiler, arayüzlerle bir fare kullanıcısına göre çok daha yavaş etkileşime girer. Uzun bir sigorta talep formunu veya çok sayfalı bir devlet başvuru formunu tamamlamak, varsayılan oturum zaman aşımının öngördüğünden kat kat daha uzun sürebilir. Geri sayımı bilmeden, verileri kaybolmadan önce ilerlemeyi kaydetmek veya süre uzatımı istemek gibi bir eylemde bulunma fırsatları olmaz.

Ekran okuyucu kullanıcıları da bileşik bir zorlukla karşı karşıyadır: her alanın sesli okunması ve klavye ile onaylanması gerektiğinde karmaşık formlarda gezinmek daha uzun sürer. Kullanıcı hâlâ uzun bir form üzerinde sistematik şekilde çalışırken oturumun süresinin dolması, yalnızca rahatsızlık verici değildir — saatlerce emeğin kaybı ve temel hizmetlere erişimde önemli bir engel anlamına gelebilir.

Şu gerçek dünya senaryosunu düşünün: Multipl sklerozu olan bir kullanıcı, bir devlet portalı üzerinden engellilik yardımı için başvuruda bulunuyor. Form 12 bölümden oluşuyor ve destekleyici belgelerin yüklenmesini gerektiriyor. Oturum, 15 dakikalık hareketsizlikten sonra sona eriyor, ancak kullanıcı 7. bölümün ortasında başka bir odadan bir belge almak için ara veriyor. Geri döndüğünde tüm veriler silinmiş ve baştan başlaması gerekiyor — bunun olacağına dair önceden hiçbir uyarı almadan. 2.2.6 kapsamında, portalın, kullanıcıyı en başta, 15 dakikadan fazla hareketsiz kalmanın veri kaybına yol açacağı konusunda bilgilendirmesi gerekir; böylece kullanıcı buna göre plan yapabilir.

Erişilebilirliğin ötesinde, zaman aşımı davranışını proaktif olarak açıklamak, herkes için kullanıcı deneyimini iyileştirir ve ödeme, kayıt ve başvuru formları gibi yüksek değerli dönüşüm akışlarında terk oranlarını azaltır. Ayrıca güven inşa eder; kullanıcılar verilerinin neden kaybolduğunu merak etmek zorunda kalmaz.

İlgili Axe-core Kuralları

WCAG 2.2.6 manuel test gerektirir. Bu ihlali tespit edebilecek otomatik bir axe-core kuralı yoktur ve bunun nedenini anlamak hem test uzmanları hem de geliştiriciler için önemlidir.

• Manuel test gerekli — Oturum zaman aşımı bilgilendirmesi: Axe-core gibi otomatik araçlar, belirli öğelerin, özniteliklerin ve metin kalıplarının varlığını veya yokluğunu tespit etmek için DOM’u tarayabilir, ancak bir web uygulamasının belirli bir hareketsizlik süresinden sonra kullanıcı verilerini kaybedip kaybetmeyeceğini belirleyemez. Zaman aşımı davranışı genellikle sunucu tarafı oturum yapılandırmasıyla (örneğin bir PHP veya Node.js oturum TTL’i) yönetilir ve bilgilendirme — varsa — giriş metninde, bir modal pencerede, bir yardım sayfasında veya hatta hizmet şartları bölümünde yer alabilir. Hiçbir statik DOM analizi, bir bilgilendirme metnini gerçek sunucu tarafı zaman aşımı davranışıyla güvenilir şekilde ilişkilendiremez. Bir araç, "Güvenliğiniz için, oturumlar 15 dakika sonra sona erer" gibi bir cümlenin doğru olup olmadığını, mevcut sayfanın verileri için geçerli olup olmadığını veya kullanıcı yolculuğunun yeterince erken bir aşamasında yer alıp almadığını bilemez. Yalnızca uygulamayla etkileşime girebilen, zaman içindeki davranışını gözlemleyebilen ve herhangi bir bilgilendirmenin kapsamını ve zamanlamasını değerlendirebilen bir insan test uzmanı uyumluluğu belirleyebilir.
• Manuel test gerekli — Veri koruma doğrulaması: Axe-core, 20 saatlik istisnayı da doğrulayamaz. Verilerin gerçekten sunucu tarafında 20 saatten fazla saklanıp saklanmadığı — ve dolayısıyla herhangi bir bilgilendirmenin gerekip gerekmediği — tamamen tarayıcı tabanlı bir tarama aracına görünmeyen arka uç mantığına bağlıdır. Test uzmanları, sunucu yapılandırmasını incelemeli, geliştiricilerle konuşmalı veya kısmen doldurulmuş bir formu uzun süre bırakıp verilerin kalıcı olup olmadığını gözlemleyerek ampirik test yapmalıdır.

Nasıl Test Edilir

1. Otomatik ön tarama: Formu, ödeme akışını veya diğer veri giriş arayüzünü içeren sayfaya karşı axe DevTools veya Lighthouse çalıştırın. Bu araçların hiçbiri doğrudan bir 2.2.6 ihlalini işaretlemeyecek olsa da, bu adımı, uyarı mekanizmasının parçası olabilecek zaman aşımıyla ilgili ARIA canlı bölgelerini veya iletişim kutusu bileşenlerini belirlemek ve bunların kendilerinin erişilebilir olduğunu (doğru roller, etiketler, odak yönetimi) doğrulamak için kullanın.
2. Zaman aşımı davranışını belirleyin: Oturum için hareketsizlik zaman aşımı süresini belirlemek üzere geliştirme ekibiyle konuşun veya sunucu tarafı yapılandırmasını inceleyin. Yaygın konumlar arasında web sunucusu yapılandırma dosyaları, uygulama oturum ara katman ayarları ve kimlik doğrulama sağlayıcısı dokümantasyonu bulunur. Sürenin tam uzunluğunu dakikalar cinsinden kaydedin.
3. Başta yapılan bilgilendirmeyi kontrol edin: Sayfayı taze olarak yükleyin ve kullanıcı veri girmeye başlamadan önce sunulan tüm içeriği okuyun. Sayfa gövdesinde, giriş paragrafında, bir banner’da veya bir modal pencerede, tam hareketsizlik zaman aşımı süresini belirten ve kullanıcı bu süre boyunca hareketsiz kalırsa verilerin kaybolacağını ifade eden net bir açıklama arayın. Bilgilendirme, süreyi açıkça (örneğin, "15 dakika") belirtmeli, belirsiz (örneğin, "kısa bir süre") olmamalıdır.
4. Ekran okuyucu ile test edin: NVDA ile Firefox, VoiceOver ile Safari veya JAWS ile Chrome kullanarak sayfada en baştan gezin. Herhangi bir zaman aşımı bilgilendirmesinin, kullanıcının onu aktif olarak aramasını gerektirmeden ekran okuyucu tarafından erişilebilir ve sesli okunur olduğundan emin olun. Bilgilendirme görsel olarak belirgin bir banner içindeyse, okuma sıralamasında ilk form alanından önce yer aldığını doğrulayın.
5. Hareketsizliği simüle edin: Formu doldurmaya başlayın. Ardından, zaman aşımı süresinden biraz daha kısa bir süre boyunca sayfayla etkileşimi durdurun ve ne olduğunu gözlemleyin. Sonra tekrarlayın, bu kez zaman aşımı süresi geçene kadar bekleyin. Verilerin kaybolup kaybolmadığını, veri kaybı gerçekleşmeden önce bir uyarı gösterilip gösterilmediğini ve bu uyarının oturum başlamadan önce iletilip iletilmediğini kaydedin.
6. 20 saatlik istisnayı test edin: Ekip, verilerin 20 saatten fazla süreyle korunduğunu iddia ediyorsa, bunu ampirik olarak doğrulamak için formu kısmen doldurun, en az 20 saat bekleyin ve verilerin hâlâ mevcut olduğunu doğrulamak için sayfaya geri dönün. Alternatif olarak, geliştirme ekibiyle birlikte sunucu tarafı oturum deposu yapılandırmasını inceleyin.
7. Klavye ve odak testi: Bir zaman aşımı uyarı iletişim kutusu veya bildirimi görünürse, yalnızca klavye ile gezinerek, odaklanmanın otomatik olarak bu iletişim kutusuna taşındığını, içeriğinin tamamen okunabilir olduğunu ve kullanıcının fare kullanmadan bunu kapatabildiğini veya (örneğin, oturumu uzatmak gibi) bir eylem gerçekleştirebildiğini doğrulayın.

Nasıl Düzeltilir

Sessiz veri kaybı olan oturum — Hatalı

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Sessiz veri kaybı olan oturum — Doğru

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Belirsiz uyarılı ödeme oturumu — Hatalı

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Belirsiz uyarılı ödeme oturumu — Doğru

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Verilerin sunucu tarafında 20 saatten fazla korunması — Doğru (istisna uygulanır)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Yaygın Hatalar

• Zaman aşımı uyarısını yalnızca tarayıcı konsolu içinde veya son kullanıcıların göremeyeceği bir sunucu günlük kaydında göstermek — uyarı, kullanıcı arayüzünde, kullanıcı veri kaybı gerçekleşmeden önce karşılaşacağı bir konumda sunulmalıdır.
• Bilgilendirmeyi, kullanıcıların veri girmeye başlamadan önce okuma olasılığı düşük olan bir alt bilgiye, gizlilik politikasına veya hizmet şartları sayfasına yerleştirmek yerine, doğrudan formun üzerinde veya hemen öncesinde sunmak.
• Yaklaşan oturum süresi dolumu konusunda kullanıcıları uyarmak için bir modal iletişim kutusu kullanmak ancak klavye odağını bu iletişim kutusuna taşımamak — klavye ve ekran okuyucu kullanıcıları uyarının göründüğünden hiç haberdar olmayabilir.
• Bir oturum süresi (örneğin, "oturumunuz 30 dakika sürer") belirtmek yerine bir hareketsizlik zaman aşımı (örneğin, "15 dakikalık hareketsizlikten sonra verileriniz kaybolacaktır") belirtmek — bunlar farklı kavramlardır ve yalnızca hareketsizlik kaynaklı veri kaybı 2.2.6 tarafından yönetilir.
• Görsel kullanıcılar için bir zaman aşımı uyarı modali bulunduğu için ölçütün karşılandığını varsaymak — eğer modal klavye ile erişilebilir değilse, erişilebilir bir ada sahip değilse veya ARIA canlı bölgeleri ya da odak yönetimi ile duyurulmuyorsa, ekran okuyucu kullanıcıları uyarıyı alamaz.
• Sunucu tarafı oturum zaman aşımını 25 saat olarak ayarlayıp, tarayıcı tarafı veya uygulama düzeyindeki durumun (örneğin bir Redux store veya localStorage) daha önce temizlenip temizlenmediğini doğrulamadan bilgilendirmenin gereksiz olduğuna karar vermek — fiili zaman aşımı, verileri ilk kaybeden mekanizmadır.
• Yalnızca fareyle üzerine gelmeyle tetiklenen bir araç ipucunda zaman aşımı süresini açıklamak — klavye ile gezinmeye veya dokunmatik cihazlara güvenen kullanıcılar bu bilgilendirmeyle hiç karşılaşmayabilir.
• Veri kaybı zaten gerçekleşmişken gösterilen ve "oturum süresi doldu" diyen genel bir CMS veya framework uyarısına güvenmek yerine, kullanıcıları veri girmeye başlamadan önce proaktif olarak bilgilendirmemek.
• Formu arka plandaki bir sekmede açan kullanıcıları hesaba katmamak: Oturum zamanlayıcısı sekme etkin değilken de çalışıyorsa, kullanıcı form ile etkileşime geçme fırsatı bulamadan veri kaybolabilir. Bu, arka plan sekmelerini agresif şekilde askıya alan mobil tarayıcılarda özellikle sorunludur.
• Uyarıyı masaüstü sürümünde gösterirken mobil sürümlerde veya progressive web app (PWA) bağlamlarında atlamak ve 2.2.6’yı önemli bir kullanıcı kitlesi için başarısız kılan tutarsız bir deneyim yaratmak.

Türkiye’nin Erişilebilirlik Mevzuatıyla İlişkisi

21 Haziran 2025’te 32933 sayılı Resmî Gazete’de yayımlanan Türkiye Cumhurbaşkanlığı Genelgesi 2025/10, Türkiye’de faaliyet gösteren çok çeşitli kamu ve özel sektör kuruluşları için bağlayıcı web erişilebilirliği yükümlülükleri getirir. Genelge, teknik standart olarak WCAG 2.2’ye uyumu zorunlu kılar ve kapsamdaki kuruluşların en az Seviye AA uyumluluğunu sağlamasını ister. WCAG 2.2.6 Zaman Aşımı, Seviye AAA ölçütüdür ve bu nedenle genelgenin asgari gereklilikleri tarafından doğrudan zorunlu kılınmaz. Ancak genelgenin kapsamı ve amacı, kapsamdaki kuruluşların 2.2.6 gibi ölçütlerde AAA uyumluluğunu hedeflemesi için güçlü pratik gerekçeler yaratır.

Cumhurbaşkanlığı Genelgesi 2025/10 kapsamındaki kuruluşlar arasında kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finans kuruluşları, hastaneler ve sağlık hizmeti sağlayıcıları, 200.000’den fazla abonesi olan telekomünikasyon işletmecileri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel okullar yer alır. Bu sektörlerin çoğu, 2.2.6’nın korumayı amaçladığı veri giriş iş akışlarının aynısını içeren çevrimiçi portallar işletir: kredi başvuruları, hasta kabul formları, bilet rezervasyon sistemleri, kayıt başvuruları ve devlet yardımı talepleri.

Özellikle bankalar ve e-ticaret platformları için oturum zaman aşımları rutin bir güvenlik önlemidir ve güvenlik gereklilikleri ile erişilebilirlik yükümlülükleri arasındaki etkileşim doğrudan önem taşır. Bir banka, hareketsiz oturumları belirli bir süreden sonra sonlandırma yönünde düzenleyici bir yükümlülüğe sahip olsa bile, zaman aşımı süresini en başta açıklayarak WCAG 2.2.6’yı uygulamak bu güvenlik gerekliliğiyle çelişmez — onu tamamlar. Kullanıcılar, banka oturum güvenliği duruşunu zayıflatmak zorunda kalmadan kısıtlamadan haberdar edilir.

Genelge kapsamındaki sağlık hizmeti sağlayıcıları ve hastaneler, hayal edilebilecek en kritik veri giriş görevlerinden bazılarını yürütür — hasta geçmişi formları, ön onay talepleri ve randevu planlama sistemleri. Bu bağlamlarda, bilişsel engelli veya motor bozukluğu olan hastaların form ortasında verilerini kaybetmesi, yalnızca hayal kırıklığı değil, aynı zamanda bakım almada potansiyel gecikme anlamına gelir. Bu ortamlarda 2.2.6’nın uygulanması, genelgenin temelini oluşturan kapsayıcı hizmet ilkesinin doğrudan bir ifadesidir.

Her ne kadar Seviye AAA yasal olarak zorunlu olmasa da, uygulanması nispeten düşük çaba gerektiren (bir forma tek, doğru bir bilgilendirme ifadesi eklemek gibi) ve kırılgan kullanıcı gruplarına önemli fayda sağlayan 2.2.6 gibi ölçütlerde bu seviyeye ulaşmak, birinci sınıf erişilebilirlik uygulamasını temsil eder. Türkiye pazarında dijital kapsayıcılığa olan bağlılığını göstermek isteyen veya gelecekte daha sıkı düzenlemeleri öngören kuruluşlar, 2.2.6’yı isteğe bağlı bir hedef yerine pratik bir uygulama hedefi olarak ele almakla iyi eder.