WCAG 2.2.3: Zamanlama Yok

Bu Kuralın Anlamı

WCAG 2.2.3 — Zaman Sınırı Yok, 2.2 Yönergesi: Yeterli Zaman altında AAA uyumluluk seviyesinde yer alır. Gereksinimi nettir: kullanıcıya sunulan herhangi bir olay veya etkinlikte zamanlamanın temel bir parça olmaması gerekir. Başka bir deyişle, içeriğiniz veya işlevselliğiniz bir zaman sınırı, son tarih veya herhangi bir türde zamana duyarlı etkileşim içeriyorsa, bu zaman bağımlılığı ya kaldırılabilir olmalı ya da eldeki görev için tamamen önemsiz olmalıdır — dar kapsamlı istisnalardan biri geçerli olmadığı sürece.

Bu ölçüt, Seviye A ölçütü 2.2.1 (Zaman Ayarlanabilir) ve Seviye AA ölçütü 2.2.2 (Duraklat, Durdur, Gizle) kapsamını aşar. Önceki bu ölçütler ayarlanabilir veya duraklatılabilir zaman sınırlarına izin verirken, 2.2.3 zamanlamanın anlamlı bir kısıt olarak hiç var olmamasını şart koşar. Bir formu doldurmak, bir menüde gezinmek veya bir iş akışını tamamlamak için on saniye ya da on dakika harcayan bir kullanıcı, işlemi anında bitiren bir kullanıcıyla aynı sonuca ulaşmalıdır.

Geçer sayılan durumlar: Hiçbir zaman sınırının olmadığı içerik veya mevcut herhangi bir zaman sınırının tamamen kozmetik olduğu ve sonuca hiçbir etkisinin bulunmadığı içerik (örneğin, etkileşimi engellemeyen döngüsel bir animasyon). Kullanıcının ne kadar süre harcadığından bağımsız olarak tamamen işlevsel kalan içerik bu ölçütü karşılar.

Kalır sayılan durumlar: Hareketsizlikten sonra kullanıcıları oturumdan çıkaran oturum zaman aşımı; puanın veya tamamlamanın belirli bir süre içinde bitirmeye bağlı olduğu süreli sınavlar veya değerlendirmeler; ürünleri silen alışveriş sepeti zamanlayıcıları; teklifleri kapatan geri sayım saatli açık artırma arayüzleri; süresi dolan tek kullanımlık şifre (OTP) alanları; zaman sınırlı CAPTCHA doğrulamaları; ve geçen süreye bağlı olarak kullanılamaz hale gelen veya kendiliğinden gönderilen herhangi bir etkileşimli öğe.

WCAG tarafından tanımlanan resmi istisnalar: Ölçüt açıkça iki kategoriyi muaf tutar. Birincisi, gerçek zamanlı istisnalar — canlı açık artırma, canlı yayın veya gerçek zamanlı çok oyunculu oyun gibi, zamanlamanın etkinliğin doğasına mutlak olarak içkin olduğu olaylar. İkincisi, temel (essential) istisnalar — zaman sınırının kaldırılmasının etkinliği temelden değiştireceği durumlar. Örneğin, bir hızlı yazma yeterlilik testi doğası gereği hızı ölçer, dolayısıyla zamanlama temeldir. Ancak geliştiriciler ve ürün sahipleri titiz olmalıdır: kolaylık, teknik miras veya iş tercihi “temel” sayılmaz. Ölçüt, zaman kısıtı olmadan etkinliğin temel anlamını veya amacını yitirip yitirmediğidir.

Altyazılı önceden kaydedilmiş bir video gibi eşzamanlı medya da hariç tutulur; çünkü medya oynatımındaki zamanlama, kullanıcının kendi medya oynatıcısı tarafından kontrol edilir ve kullanıcının sayfanın geri kalanıyla etkileşime girme yeteneği üzerinde bir kısıt oluşturmaz.

Neden Önemli

Web’deki zaman sınırları, çok geniş bir yelpazedeki engelli kullanıcıları orantısız biçimde olumsuz etkiler. Etki soyut değildir — birçok kullanıcı için zamanlı bir arayüz fiilen erişilemez bir arayüzdür.

Motor beceri bozukluğu olan kullanıcılar — anahtarlı erişim cihazları, ağız çubukları, göz izleme yazılımları veya diğer alternatif giriş yöntemlerini kullananlar dahil — fare ve klavye kullanıcılarından temelde farklı bir hızda çalışırlar. Çok adımlı bir formu tamamlamak veya açılır menüde gezinmek birkaç kat daha uzun sürebilir. Bir oturum zaman aşımı veya otomatik süresi dolan sepet, dakikalarca süren dikkatli ve zahmetli çalışmayı bir anda silebilir.

Bilişsel engelleri olan kullanıcılar, disleksi, DEHB, işlem bozuklukları ve edinilmiş beyin hasarları dahil, talimatları okumak, seçenekleri anlamak veya yanıtlar oluşturmak için önemli ölçüde daha fazla zamana ihtiyaç duyabilir. Web Erişilebilirliği Girişimi tarafından derlenen araştırmalar, bilişsel ve öğrenme engellerinin dünya nüfusunun yaklaşık %15–20’sini bir biçimde etkilediğini tahmin etmektedir. Bu kullanıcılar için geri sayım sayacı yalnızca stresli değildir — görevi tamamlamak için gereken bilişsel işlemeyi aktif olarak bozar.

Ekran okuyucu kullanıcıları — kör veya az gören kullanıcılar — içeriği doğrusal olarak gezinir ve arayüz öğelerini sırasıyla dinlemek veya okumak zorundadır. Karmaşık bir sayfadaki yapıyı ve seçenekleri anlamak, görsel olarak hızlıca göz atan gören bir kullanıcıdan daha uzun sürer. Kör bir kullanıcı sipariş özetini dikkatle incelerken süresi dolan zamanlı bir ödeme akışı, ticarete doğrudan bir engeldir.

Anksiyete bozukluğu olan kullanıcılar, yalnızca bir geri sayım sayacının varlığının bile, teknik olarak yeterli zamanları olsa bile, görevi tamamlamayı engelleyecek kadar bilişsel ve duygusal yük oluşturduğunu deneyimleyebilir. Zamanlamayı bir faktör olmaktan çıkarmak bu engeli tamamen ortadan kaldırır.

Somut bir gerçek dünya senaryosu: Beş dakikalık hareketsizlik zaman aşımı ile altmış saniyede süresi dolan bir OTP’yi birleştiren bir çevrimiçi bankacılık portalını düşünün. Yazmak için yardımcı giriş teknolojisine ihtiyaç duyan Parkinson hastalığı olan bir kullanıcı veya uygulamalar arasında hızlı geçişe aşina olmayan yaşlı bir kullanıcı, SMS’i almak, uygulama değiştirmek, kodu okumak, geri dönmek ve kodu verilen süre içinde girmek için fiziksel olarak yeterli zamana sahip olmayabilir. Kendi hesaplarına erişimleri, güvenlik gerekliliğiyle değil, keyfi bir zaman kısıtıyla engellenir. OTP’nin daha uzun süre geçerli olacak şekilde tasarlanması (veya sert zaman aşımı yerine yeniden gönderme mekanizmasının kullanılması) güvenliği zedelemeden sorunu çözer.

Erişilebilirliğin ötesinde, gereksiz zaman kısıtlarını kaldırmak genel kullanılabilirliği artırır ve terk oranlarını azaltır. Akışı ortasında süresi dolmayan bir e-ticaret ödeme süreci daha fazla müşteriyi elde tutar, dönüşümü artırır ve destek yükünü azaltır — bu da bunu etik bir zorunluluğun yanı sıra iş açısından olumlu bir değişiklik haline getirir.

İlgili Axe-core Kuralları

WCAG 2.2.3 manuel test gerektirir. Hiçbir otomatik axe-core kuralı bu ölçüte doğrudan karşılık gelmez ve bu, anlaşılması gereken önemli bir mimari gerçektir.

• Manuel test gerekli — Oturum ve etkileşim zamanlaması: Otomatik araçlar, bir web uygulamasının zaman sınırı uygulayıp uygulamadığını tespit edemez; çünkü zamanlama mantığı sunucu tarafı oturum yönetiminde, JavaScript zamanlayıcılarında veya arka uç API yanıtlarında uygulanır — bunların hiçbiri statik DOM analizinde görünmez. Axe-core gibi bir araç, oluşturulmuş HTML’yi ve erişilebilirlik ağacını inceler; beş dakikalık hareketsizlikten sonra bir fetch isteğinin 401 döndüreceğini veya bir JavaScript setTimeout’un kullanıcıyı oturum kapatma sayfasına yönlendireceğini gözlemleyemez. Yalnızca uygulamayla yavaşça etkileşime giren ve ne olduğunu gözlemleyen bir insan testçi, zaman kısıtlarının var olup olmadığını ve görev tamamlamayı etkileyip etkilemediğini belirleyebilir.
• Manuel test gerekli — OTP ve CAPTCHA süresinin dolması: Tek kullanımlık şifreler ve zaman sınırlı doğrulama görevleri DOM’da sıradan giriş alanları olarak görünür. Görünürse geri sayım sayacı basit bir metin düğümü veya CSS ile canlandırılmış bir öğe olabilir. Axe, bu alana doksan saniye sonra bir değer girmenin hata durumuyla sonuçlanacağını çıkaramaz. Bir testçinin, zaman aşımı penceresinin ötesine kasıtlı olarak beklemesi ve zamanlamanın uygulanıp uygulanmadığını doğrulamak için göndermeyi denemesi gerekir.
• Manuel test gerekli — Otomatik gönderilen ve otomatik ilerleyen formlar: Bazı arayüzler, belirli bir hareketsizlik süresinden sonra veya belirli bir sürenin ardından (örneğin, otuz saniye sonra bir sonraki soruya geçen bir anket) otomatik olarak bir sonraki adıma ilerler veya formu gönderir. Axe-core bunu işaretlemez; çünkü DOM yapısı geçerli görünür; sorunlu davranış yalnızca zaman içinde gerçek etkileşim sırasında ortaya çıkar.
• Manuel test gerekli — Ticaret ve rezervasyon süresinin dolması: Alışveriş sepeti rezervasyon zamanlayıcıları, bilet rezervasyon tutmaları ve randevu slot kilitlemeleri sunucu mantığıyla uygulanır ve yalnızca geri sayım göstergesi olarak arayüze yansıtılır. Otomatik araçlar ekranda güncellenen bir sayı görür, ancak sıfıra ulaştığında veri kaybına veya erişim reddine neden olup olmadığını belirleyemez.

Nasıl Test Edilir

1. Otomatik temel tarama: Sayfada axe DevTools veya Lighthouse çalıştırarak, sizi daha derin manuel inceleme gerektiren alanlara yönlendirebilecek ilgili alt seviye zamanlama ihlallerini (örneğin 2.2.1 veya 2.2.2 kapsamındakiler) belirleyin. Her ne kadar hiçbir axe kuralı 2.2.3’ü doğrudan test etmese de, zaman sınırı uyarıları veya otomatik yenileme ile ilgili bulgular manuel denetim kapsamınızı yönlendirebilir. Lighthouse’ta, zamanla ilgili herhangi bir işaret için “Erişilebilirlik” bölümünü inceleyin.
2. Tüm zamana bağlı özelliklerin envanterini çıkarın: Testten önce, uygulamadaki zamanlamayı içerebilecek her özelliği sistematik olarak listeleyin. Buna şunlar dahildir: oturum yönetimi ve hareketsizlik zaman aşımı; OTP ve doğrulama kodu alanları; alışveriş sepeti veya rezervasyon tutmaları; süreli sınavlar, değerlendirmeler veya anketler; açık artırma veya teklif arayüzleri; CAPTCHA görevleri; gönderim pencereli otomatik kaydetme mekanizmaları; ve görünür herhangi bir geri sayım veya ilerleme zamanlayıcısı.
3. Oturum zaman aşımı davranışını test edin: Uygulamayı açın ve birden fazla adımı kapsayan bir göreve başlayın (örneğin, çok sayfalı bir form doldurmak veya bir ödeme işlemini tamamlamak). Şüphelenilen zaman aşımı penceresini aşan bir süre boyunca etkileşimde bulunmayın. Ardından devam etmeye çalışın. İlerlemenizin korunup korunmadığını, uyarılıp uyarılmadığınızı ve oturumunuzu uzatma imkânı verilip verilmediğini veya oturumunuzun kapatılıp verilerinizi kaybedip kaybetmediğinizi gözlemleyin. Geçer sayılması için ya hiçbir zaman aşımı olmamalı, ya zaman aşımı yalnızca önleyici olmalı ve yeniden kimlik doğrulamada veriler korunmalı ya da kullanıcıya yeterli uyarı ve kontrol sağlanmalıdır.
4. OTP ve kod süresinin dolmasını test edin: Bir OTP veya doğrulama kodu akışını tetikleyin. Kodun belirtilen son kullanma süresinin (veya süre gösterilmiyorsa daha uzun bir sürenin) sonuna kadar bekleyin. Kodu girmeye çalışın. Sistem kodu yalnızca zaman nedeniyle reddederse, bu 2.2.3’ün ihlalidir. Not: Yalnızca bir “yeniden gönder” mekanizması sağlamak 2.2.3’ü düzeltmez — orijinal kodun süresinin dolması hâlâ bir zaman kısıtı uygular.
5. Ekran okuyucu testi (NVDA + Firefox): NVDA ile Firefox kullanarak, yalnızca klavye ve ekran okuyucu ile herhangi bir zamanlı arayüzde gezinin. Yardımcı teknolojiyle gezinmenin getirdiği ek süreyi de dikkate alarak her adımın ne kadar sürdüğünü not edin. Kasıtlı olarak yavaş ilerleyin — tüm talimatları dinlemek için duraklayın, sanal imleçle tüm seçenekleri keşfedin — ardından göndermeye veya devam etmeye çalışın. Yavaş gezinmenin zaman aşımını veya durum kaybını tetiklemediğini doğrulayın.
6. Ekran okuyucu testi (macOS’ta VoiceOver + Safari): Aynı yavaş gezinme testini macOS’ta Safari ile VoiceOver kullanarak tekrarlayın. Özellikle dinamik geri sayım sayaçlarına dikkat edin: VoiceOver kalan süreyi aciliyet yaratacak şekilde duyuruyor mu ve süre dolduğunda arayüz başarısız oluyor mu?
7. Ekran okuyucu testi (JAWS + Chrome): JAWS ile Chrome kullanarak aynı akışları test edin. JAWS kullanıcıları, profesyonel ekran okuyucu kullanıcılarının önemli bir bölümünü temsil eder; NVDA kullanıcılarını etkileyen zamanlama sorunları genellikle JAWS kullanıcılarını da eşit derecede etkiler.
8. İstisnelerin meşruiyetini doğrulayın: Geliştirme ekibinin “temel” veya “gerçek zamanlı” olduğunu iddia ettiği herhangi bir zamanlama için gerekçeyi belgeleyin ve zamanlamanın gerçekten etkinliğin amacına içkin olup olmadığını veya görevin temel doğasını değiştirmeden gevşetilip gevşetilemeyeceğini, uzatılıp uzatılamayacağını ya da kaldırılıp kaldırılamayacağını değerlendirin.

Nasıl Düzeltilir

Oturum Zaman Aşımı — Hatalı

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Oturum Zaman Aşımı — Doğru

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Süresi Dolan OTP Alanı — Hatalı

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Süresi Dolan OTP Alanı — Doğru

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Süreli Sınav — Hatalı

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Süreli Sınav — Doğru

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Yaygın Hatalar

• Oturum güvenliğinin mutlaka sert bir zaman aşımı gerektirdiğini varsaymak: Birçok ekip, güvenlik gerekliliklerini gerekçe göstererek kısa hareketsizlik zaman aşımı uygular; ancak çoğu güvenlik standardı (PCI-DSS ve OWASP dahil) kullanıcı kontrollü oturum uzatmaya izin verir. Uyarı veya uzatma imkânı olmadan yapılan sert oturum kapatma, güvenlik gerekliliği değil, erişilebilirlik ihlalidir.
• Geri sayım sayacı gösterip durdurma veya uzatma yolu sunmamak: Bir geri sayım sayacına aria-live bölgesi eklemek, ekran okuyucu kullanıcıları için durumu daha da kötüleştirir — her saniyeyi duyurur — ancak altta yatan zamanlama sorununu çözmez. Çözüm, kısıtı kaldırmaktır; onu daha erişilebilir şekilde duyurmak değil.
• “Kodu yeniden gönder” seçeneğini OTP süresinin dolması için çözüm saymak: Yeniden gönderme düğmesi sağlamak, kullanıcıların yeni bir kod almasına izin verir, ancak orijinal kodun zaman nedeniyle süresinin dolduğu gerçeğini değiştirmez. Zaman sınırı hâlâ mevcuttur. Doğru çözüm, zaman baskısını ortadan kaldırmak için geçerlilik penceresini uzatmaktır.
• Hareketsizlikten sonra otomatik ilerleyen karusel veya sihirbaz adımları kullanmak: Belirli bir süreden sonra otomatik olarak bir sonraki adıma geçen çok adımlı formlar veya sihirbazlar zaman kısıtı uygular. Talimatları okuyan veya yanıtını düşünen kullanıcılar cezalandırılır. Adımlar yalnızca açık kullanıcı eylemiyle ilerlemelidir.
• Ürünleri korumadan silen alışveriş sepeti zamanlayıcıları: E-ticaretteki rezervasyon zamanlayıcıları (“Sepetiniz 15 dakika içinde süresi dolacak”), süre dolduğunda ürünler rezervasyondan yalnızca serbest bırakılmak yerine kalıcı olarak kayboluyorsa 2.2.3’ü ihlal eder. En azından, ürünler bir istek listesine kaydedilmeli veya oturum geri yüklenebilir olmalıdır.
• “Gerçek zamanlı istisna”yı çok geniş uygulamak: Gerçekten canlı olmayan bir arayüzde zaman kısıtlarını gerekçelendirmek için arayüzü “gerçek zamanlı” olarak etiketlemek. Önceden kaydedilmiş bir açık artırma tekrar yayını, statik bir teklif arayüzü veya sadece yarışma programına benzeyen bir sınav, gerçek zamanlı istisna kapsamına girmez.
• Arka uç API yanıtlarındaki zamanlamayı göz ardı etmek: Ekipler ön uç zamanlayıcılarını düzeltir, ancak API’nin kendisinin belirli bir pencereden sonra yapılan istekleri reddettiğini gözden kaçırır. Kullanıcı herhangi bir geri sayım görmez, ancak gönderimi sessizce başarısız olur. Arka uç oturum yönetimi, ön uç deneyimiyle uyumlu olmalıdır.
• Form durumunu kalıcı hale getirmeden otomatik oturum kapatma için setTimeout kullanmak: Otomatik oturum kapatma kaçınılmaz olduğunda (örneğin, düzenleyici gereklilikler nedeniyle), yönlendirmeden önce kullanıcının form verilerini kaydetmemek tüm çalışmanın kaybolması anlamına gelir. En azından taslak durum kaydedilmeli ve yeniden kimlik doğrulamadan sonra geri yüklenmelidir.
• 2.2.1 uyumluluğunu 2.2.3 uyumluluğu ile karıştırmak: (Seviye A 2.2.1’in gerektirdiği gibi) “kapatma, ayarlama veya uzatma” kontrolü sağlamak 2.2.3’ü karşılamaz. AAA seviyesi, zamanlamanın yönetilebilir olmasını değil, temel olmamasını gerektirir. Cömert uzatma imkânı olan bir zaman sınırı hâlâ bir zaman sınırıdır.
• Üçüncü taraf gömülü bileşenlerdeki zamanlamayı gözden kaçırmak: Gömülü sohbet widget’ları, ödeme sağlayıcıları, kimlik doğrulama SDK’ları ve harita servisleri kendi zaman kısıtlarını getirebilir. Üçüncü taraf kökenli olmaları, arayüzünüze entegre edildiklerinde WCAG uygulanabilirliğinden muaf oldukları anlamına gelmez.

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

Türkiye’nin 2025/10 sayılı Cumhurbaşkanlığı Genelgesi, 21 Haziran 2025 tarihli ve 32933 sayılı Resmî Gazete’de yayımlanarak, teknik dayanak olarak WCAG 2.2’ye atıfta bulunan ulusal bir web erişilebilirliği çerçevesi oluşturur. Genelge, Türkiye’de dijital hizmet sunan geniş bir yelpazedeki kuruluş için uyumluluğu zorunlu kılar.

Kapsam dâhilindeki kuruluş türleri arasında kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finansal hizmetler, hastaneler ve sağlık hizmeti sağlayıcıları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MEB) tarafından yetkilendirilmiş özel okullar yer alır. Bu kuruluşlar, halka dijital hizmet sunarken Genelge’de tanımlanan veya atıfta bulunulan erişilebilirlik standartlarını karşılamakla yükümlüdür.

WCAG 2.2.3 — Zaman Sınırı Yok, bir Seviye AAA ölçütüdür ve 2025/10 sayılı Cumhurbaşkanlığı Genelgesi, uyumlu olduğu Avrupa EN 301 549 standardı gibi, yasal asgari olarak Seviye A ve Seviye AA uyumluluğunu zorunlu kılar. AAA seviyesi uyumluluk bu çerçeve altında doğrudan yasal bir yükümlülük değildir. Ancak AAA seviyesine ulaşmak — ve özel olarak 2.2.3’ü uygulamak — birinci sınıf erişilebilirlik olgunluğunun göstergesi olarak kabul edilir ve asgari yasal eşiklerin ötesinde kapsayıcı tasarıma gerçek bir bağlılık sergiler.

Özellikle BDDK denetimi altındaki bankalar ve finansal hizmetler ile yüksek işlem hacmine sahip e-ticaret platformları gibi bazı kuruluş türlerinde, OTP süresinin dolması, oturum yönetimi ve ödeme akışı zamanlayıcıları gibi zaman kısıtları yaygın özelliklerdir. 2.2.3 yasal olarak zorunlu olmasa bile, bu akışlardaki zamanlama engellerini ele almamak, özellikle Türkiye’de erişilebilirlik denetim mekanizmaları olgunlaştıkça ve şikâyet prosedürleri daha yerleşik hale geldikçe, gerçek bir ayrımcılık riski yaratır.

Engelli kullanıcılar, yaşlı kullanıcılar ve düşük dijital okuryazarlığa sahip kullanıcılarla çalışan kamu kurumları ve sağlık hizmeti sağlayıcılarının, zaman kısıtlarını tamamen ortadan kaldırmak için özellikle güçlü bir etik gerekçesi vardır. Dijital kamu hizmetlerinden ve sağlık portallarından zaman sınırlarını kaldırmak, Türkiye’nin daha geniş e-devlet kapsayıcılık hedefleriyle uyumludur ve kamu sektöründe AAA benimsenmesinin tedarik süreçlerinde daha yaygın hale gelmesiyle gelecekteki düzenleyici riskleri azaltır.

Dijital ürünlerini tamamen kapsayıcı olarak konumlandırmak isteyen kuruluşlar — ister yurt içi liderlik, ister uluslararası pazar erişimi, ister Avrupa Birliği bağlamında (EN 301 549 ve Avrupa Erişilebilirlik Yasası’nın uygulandığı yerlerde) tedarik avantajları için olsun — WCAG 2.2.3 uyumluluğunu isteğe bağlı bir iyileştirme değil, stratejik bir yatırım olarak görmelidir.