WCAG Başarı Kriterleri · Level AAA

WCAG 2.2.5: Yeniden kimlik doğrulama

WCAG 2.2.5, kimlik doğrulanmış bir oturum sona erdiğinde, kullanıcıların yeniden kimlik doğrulaması yapabilmesini ve girmiş oldukları herhangi bir veriyi kaybetmeden etkinliklerine devam edebilmesini gerektirir. Bu ölçüt, görevleri tamamlamak için daha fazla zamana ihtiyaç duyabilen ve çalışmalarını silen oturum zaman aşımı nedeniyle cezalandırılmaması gereken engelli kullanıcılar için kritik öneme sahiptir.

Bu Kuralın Anlamı

WCAG 2.2.5 Yeniden Kimlik Doğrulama, 2.2 (Yeterli Zaman) İlkesine aittir ve Seviye AAA gereksinimidir. Ölçüt şunu belirtir: "Kimliği doğrulanmış bir oturum sona erdiğinde, kullanıcı yeniden kimlik doğrulamasından sonra veri kaybı olmadan etkinliğe devam edebilir." Pratikte bu, bir kullanıcının kimlik doğrulaması gerektiren bir platformda bir form doldurmanın, bir satın alma işlemini tamamlamanın, bir mesaj yazmanın veya çok adımlı herhangi bir görevi yerine getirmenin ortasındayken oturumu zaman aşımına uğrarsa, tekrar giriş yapabilmesi ve tam olarak kaldığı yerden devam edebilmesi gerektiği anlamına gelir — daha önce girilen tüm veriler korunmuş olmalıdır.

Bu ölçüt, WCAG 2.2.1 (Zaman Ayarlanabilir, Seviye A) ve 2.2.4 (Bölünmeler, Seviye AAA) ile yakından ilişkilidir, ancak belirli bir senaryoyu ele alır: bir oturum sınırının aşıldığı anı. 2.2.1 kullanıcılara yeterli zaman vermenizi veya oturumu uzatmalarına izin vermenizi isterken, 2.2.5 başarısızlık durumunu — sürenin dolmasından sonra ne olduğunu — ele alır. Bu ikisi birlikte çalışır: ideal olarak hem oturumu uzatır hem de oturum sona ererse verileri korursunuz.

Bu ölçüt kapsamında bir başarı, platformun kullanıcı tarafından girilen tüm verileri — metin girişleri, seçili seçenekler, dosya ekleri, onay kutuları, radyo seçimleri ve diğer tüm form durumlarını — yeniden kimlik doğrulama olayı boyunca korumasını gerektirir. Kullanıcı tekrar giriş yaptıktan sonra, verileri sağlam şekilde, gerçekleştirmekte olduğu etkinliğin aynı noktasına döndürülmeli ve görevi tekrar etmek zorunda kalmadan tamamlayabilmelidir.

Bir başarısızlık, oturum zaman aşımının aşağıdakilerden herhangi birine neden olması durumunda ortaya çıkar: kullanıcı bir giriş sayfasına yönlendirilir ve başarılı girişten sonra bulunduğu sayfa yerine ana sayfaya gönderilir; zaman aşımından önce girilen form verileri kaybolur ve kullanıcı her şeyi yeniden girmek zorunda kalır; kısmen tamamlanmış çok adımlı sihirbaz durumu sıfırlanır; veya kullanıcı yeniden kimlik doğrulayıp devam etmesini sağlayan herhangi bir mekanizma olmadan basitçe oturumdan çıkarılır.

Resmi WCAG spesifikasyonu bu ölçüt için minimum bir oturum süresi tanımlamaz — zaman aşımı süresi ne kadar uzun veya kısa olursa olsun geçerlidir. Ancak, güvenlik endişeleri nedeniyle veri kaybı için hiçbir istisna tanınmadığını unutmayın; beklenti, uygulamaların, kullanıcının kimliğine göre anahtarlanan sunucu tarafı oturum depolaması veya yeniden kimlik doğrulama akışından sonra da geçerli olan şifreli istemci tarafı belirteçler gibi durumu korumanın güvenli yollarını bulmasıdır.

Neden Önemlidir

Verileri silen oturum zaman aşımı, engelli kişiler için orantısız derecede ağır bir yük oluşturur. Birçok engelli kullanıcı, dijital görevleri engeli olmayan akranlarına göre önemli ölçüde daha uzun sürede tamamlar ve çoğu zaman keyfi bir zaman aşımını basitçe "daha hızlı yazarak" veya "etrafından dolaşarak" telafi edemez.

Kör veya az gören kullanıcılar formlarda ekran okuyucularla gezinir; bu, görsel taramaya kıyasla doğası gereği daha yavaştır. Uzun bir sigorta talep formunu dolduran kör bir kullanıcı, alan alan dikkatle gezinerek 20 veya 30 dakika harcayabilir ve 15 dakikalık oturum zaman aşımı tetiklendiğinde tüm çalışması silinebilir. Ardından yeniden başlamak zorundadır — aynı şeyin ikinci kez olmayacağına dair hiçbir garanti olmadan.

Motor bozuklukları olan kişiler — örneğin anahtarlı erişim cihazları, göz izleme teknolojisi veya ağız çubukları kullananlar — metin girmek ve formlarda gezinmek için ortalamadan birkaç kat daha uzun süreye ihtiyaç duyabilir. ALS veya spinal müsküler atrofiye sahip bir kullanıcı, kritik bir tıbbi sevk formu dolduruyor ve dakikada sadece birkaç karakter yazıyor olabilir. Çalışmalarını yok eden oturum zaman aşımları küçük bir rahatsızlık değil; temel görevleri tamamlamanın önünde tam bir engel olabilir.

Bilişsel engelleri olan kullanıcılar, disleksi, DEHB, travmatik beyin hasarı veya demans dahil olmak üzere, talimatları birden çok kez yeniden okumaya, bilgiyi işlemek için ara vermeye veya çok adımlı süreçlerde basitçe daha yavaş ilerlemeye ihtiyaç duyabilir. Araştırmalar, bu nüfusun zaman baskısı ve veri kaybından orantısız şekilde etkilendiğini — her ikisinin de sıfırdan yeniden başlamaya çalışmanın bilişsel yükünü katladığını — tutarlı biçimde göstermektedir.

Somut bir gerçek dünya senaryosunu düşünün: Multipl sklerozlu bir kullanıcı, bir kamu kurumunun web portalı üzerinden devlet engellilik yardımı için başvuruda bulunuyor. Başvuru 8 adımdan oluşuyor ve tıbbi belgelerin yüklenmesini, iş geçmişinin girilmesini ve kişisel bir beyan yazılmasını gerektiriyor. 45 dakikada 6 adımı tamamlıyor, oturumu sona eriyor ve girdiği tüm veriler kayboluyor. Şimdi aynı belgeleri tekrar toplaması ve tüm süreci baştan tekrarlaması gerekiyor; bu da başvuruyu tamamen bırakmasına yol açabilir. Bu bir varsayım değil — erişilebilirlik araştırmalarında ve kullanıcı testlerinde defalarca belgelenmiş bir örüntüdür.

Engellilik bağlamının ötesinde, oturum zaman aşımında veri kaybı tüm kullanıcıları etkiler ve ölçülebilir iş etkileri yaratır: terk edilmiş alışveriş sepetleri, tamamlanmamış kayıtlar ve kaybedilen potansiyel müşteriler. Oturum durumunu korumak hem bir erişilebilirlik zorunluluğu hem de sağlam bir UX ve dönüşüm optimizasyonu uygulamasıdır. Baymard Institute’a göre, form terk edilmesi e-ticaret sepet terk oranlarına büyük katkıda bulunur ve beklenmedik veri kaybı, kullanıcıların çevrimiçi satın alma işlemlerini tamamlamamasının en çok belirtilen nedenlerinden biridir.

İlgili Axe-core Kuralları

WCAG 2.2.5 yalnızca manuel test gerektirir. Bu ölçüt ihlallerini güvenilir şekilde tespit edebilecek otomatik axe-core kuralları yoktur. Aşağıda, otomatik araçların neden yetersiz kaldığı ve insan test uzmanlarının bunun yerine ne yapması gerektiği açıklanmaktadır:

  • Oturum durumu koruma için otomatik bir kural yoktur: Axe-core ve benzeri otomatik erişilebilirlik motorları, mevcut DOM’u inceleyerek renk kontrast oranları, ARIA öznitelik doğruluğu ve eksik alternatif metin gibi statik veya statik benzeri koşulları değerlendirerek çalışır. Zamanın geçişini simüle edemez, bir oturum sona erme olayını tetikleyemez, yeniden kimlik doğrulama kimlik bilgilerini gönderemez ve ardından daha önce girilen verilerin geri yüklenip yüklenmediğini doğrulayamaz. Bu dizinin tamamı, bir insanın (veya uçtan uca betiklenmiş bir testin) gözlemlemesini gerektiren durumsal, zamana bağlı bir davranıştır.
  • Oturum zaman aşımı tespiti statik analiz kapsamı dışındadır: Otomatik bir araç bir sayfanın oturum zaman aşımı uyguladığını (örneğin bir meta yenileme etiketi veya bir JavaScript setTimeout çağrısını okuyarak) tespit edebilse bile, zaman aşımı tetiklendikten sonra kullanıcı verilerine ne olduğunu değerlendiremez. Veri koruma davranışı, otomatik araçların analiz ettiği DOM yapısında değil, sunucu tarafı oturum yönetimi mantığında bulunur.
  • Yeniden kimlik doğrulama akışının karmaşıklığı: Yeniden kimlik doğrulama deneyimi birden fazla sayfayı (giriş formu, MFA istemi, yönlendirme) içerebilir ve durumun geri yüklenmesi sunucu tarafı mantığa, çerezlere, yerel depolamaya veya URL parametrelerine bağlı olabilir. Tek sayfalık bir DOM inceleme aracı bu çok sayfalı, çok sistemli akışı izleyemez.
  • Neden manuel test zorunludur: Nitelikli bir test uzmanı, kimlik doğrulaması yapılmış bir iş akışını manuel olarak başlatmalı, oturumun sona ermesini kasıtlı olarak beklemeli veya tetiklemeli, yeniden kimlik doğrulama sürecini tamamlamalı ve ardından veri bütünlüğünü doğrulamalıdır. Uygunluğu test etmenin tek güvenilir yöntemi budur. Otomatik taramalar, 2.2.1 kapsamında ele alınan eksik oturum uyarı mekanizmaları gibi ilgili sorunları işaretlemek için başlangıç noktası olarak kullanılabilir, ancak 2.2.5 için manuel testin yerini alamaz.

Nasıl Test Edilir

  1. Kimlik doğrulaması gerektiren, form veya çok adımlı süreç içeren iş akışlarını belirleyin. Sitede kimlik doğrulaması gerektiren ve kullanıcı veri girişi içeren tüm alanları haritalayarak başlayın — ödeme akışları, profil düzenleyiciler, başvuru formları, rezervasyon sistemleri, mesajlaşma arayüzleri ve yönetim panelleri. Bunlar 2.2.5 başarısızlıkları için en yüksek riskli alanlardır.
  2. Oturum zaman aşımı süresini belirleyin. Oturumların ne zaman sona erdiğini öğrenmek için sunucu yapılandırmasını, uygulama ayarlarını kontrol edin veya geliştirme ekibiyle görüşün. Alternatif olarak, bir oturum başlatın ve otomatik olarak oturumdan çıkarılana kadar bekleyin. Süreyi not edin. Yaygın zaman aşımları 15 dakikadan 2 saate kadar değişir.
  3. Bir göreve başlayın ve kayda değer miktarda veri girin. Giriş yapın ve temsil niteliğinde bir form doldurmaya başlayın — örneğin çok alanlı bir kayıt veya satın alma akışı. Metin alanlarına metin girin, seçimler yapın ve varsa sihirbaz adımlarında ilerleyin. Formu göndermeyin.
  4. Oturum sona ermesini tetikleyin. Doğal zaman aşımının gerçekleşmesini bekleyin veya — geliştirici erişiminiz varsa — tarayıcının geliştirici araçlarında oturum çerezini geçersiz kılarak (Application sekmesi > Cookies > oturum çerezini sil) ya da oturumu doğrudan sunucu tarafında sona erdirerek oturumu yapay olarak sonlandırın.
  5. Yeniden kimlik doğrulama istemini gözlemleyin. Sitenin sizi yeniden kimlik doğrulamaya yönlendirip yönlendirmediğini (başarı) veya sizi uyarı olmadan basitçe bir giriş sayfasına yönlendirip yönlendirmediğini kontrol edin (ilgili bir kullanılabilirlik sorunu, ancak 2.2.5 uyarının kendisinden ziyade veri korumaya odaklanır). Tekrar giriş yapmayı deneyin.
  6. Girişten sonra veri korumasını doğrulayın. Yeniden kimlik doğrulamayı başarıyla tamamladıktan sonra nereye yönlendirildiğinizi ve daha önce girdiğiniz verilerin sağlam olup olmadığını gözlemleyin. Ana sayfaya gönderilirseniz ve/veya form verileriniz kaybolmuşsa, bu 2.2.5’in bir başarısızlığıdır.
  7. Yardımcı teknolojilerle test edin. Yeniden kimlik doğrulama isteminin ekran okuyucu kullanıcıları için erişilebilir olduğundan ve geri yüklenen sayfa durumunun doğru şekilde duyurulduğundan emin olmak için yukarıdaki test dizisini NVDA ile Firefox, JAWS ile Chrome ve VoiceOver ile Safari kullanarak tekrarlayın. Gören bir kullanıcı geri yüklenen verileri görsel olarak fark edebilir; ekran okuyucu kullanan bir kullanıcının odağın doğru yere yerleştirilmesine ve geri yüklenen içeriğin okuma sırasına dahil edilmesine ihtiyacı vardır.
  8. Yalnızca klavye ile gezinmeyi test edin. Oturum sona erme bildiriminden, tekrar giriş yapmaya ve korunmuş göreve geri dönmeye kadar tüm yeniden kimlik doğrulama sürecinin yalnızca klavye kullanılarak, fare gerektirmeden tamamlanabildiğinden emin olun.
  9. Uzun süreli zaman aşımı simülasyonlarıyla test edin. Mümkünse, geliştirme ortamında oturum zaman aşımını 1–2 dakikaya düşürün ve test döngüsünü daha hızlı ve tekrarlanabilir hale getirmek için tam kullanıcı yolculuğu testleri gerçekleştirin.

Nasıl Düzeltilir

Oturum Zaman Aşımlı Basit Giriş Formu — Hatalı

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Oturum Zaman Aşımlı Basit Giriş Formu — Doğru

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

İlerlemesini Kaybeden Çok Adımlı Sihirbaz — Hatalı

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

İlerlemesini Kaybeden Çok Adımlı Sihirbaz — Doğru

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Veri Koruması Olmadan Oturum Sona Erme Uyarısı — Hatalı

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Veri Koruması Olmadan Oturum Sona Erme Uyarısı — Doğru

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Yaygın Hatalar

  • Yeniden kimlik doğrulamadan sonra ana sayfaya yönlendirmek yerine orijinal sayfaya dönmemek: En yaygın başarısızlık örüntüsü. Girişten sonra uygulama, kullanıcının oturumu sona erdiğinde bulunduğu URL yerine kullanıcıyı /dashboard veya / adresine gönderir; bu da kullanıcının görevine manuel olarak geri dönmesini zorunlu kılar — ve verileri zaten kaybolmuştur.
  • Form durumunu yalnızca JavaScript belleğinde veya React/Vue bileşen durumunda saklamak: İstemci tarafı çerçeve durumu, oturum zaman aşımı nedeniyle giriş sayfasına yönlendirme ile tetiklenen bir sayfa yeniden yüklemesinden sağ çıkamaz. Durum, sunucu tarafında veya geri dönüşte güvenilir şekilde geri yüklenebilen bir depolama mekanizmasında (örneğin localStorage) kalıcı hale getirilmelidir.
  • Yalnızca bir "dönüş URL’si" kaydedip form verilerini kaydetmemek: Bazı uygulamalar, girişten sonra geri yönlendirmek için URL’yi saklar ancak gerçek form alanı değerlerini kaydetmez. Kullanıcı doğru sayfaya gelir ancak alanlar boştur; bu da 2.2.5’i yine ihlal eder.
  • Sekme kapandığında temizlenen sessionStorage’a otomatik kaydetmek: Oturum sona ermesi tarayıcı sekmesinin başka bir sayfaya gitmesine neden olursa (örneğin giriş sayfasına yönlendirme), sessionStorage temizlenir. Kullanıcıya göre adlandırılmış bir ad alanıyla localStorage kullanın veya tercihen sunucu tarafı taslak depolaması kullanın.
  • Dosya yükleme alanlarıyla test etmemek: Güvenlik nedenleriyle dosya girişleri HTML tarafından önceden doldurulamaz. Bir form, oturum sona ermeden önce tamamlanmış bir dosya yükleme alanı içeriyorsa, dosya referansı kaybolur. Uygulamalar, yüklenen dosya referanslarını sunucu tarafında saklayarak ve kullanıcının dosyasının hâlâ ekli olduğunu göstererek bunu ele almalıdır.
  • Yeniden kimlik doğrulama sırasında kaydedilmiş taslak verilerini hemen temizlemek: Bazı uygulamalar, kullanıcı geri yüklenen verileri gerçekten görüp onayladığını doğrulamadan, kullanıcı giriş yapar yapmaz taslağı siler. Taslak, görev açıkça tamamlanana veya iptal edilene kadar korunmalıdır.
  • Geri yüklenen verileri ekran okuyucu kullanıcılarına duyurmamak: Yeniden kimlik doğrulama ve yönlendirmeden sonra, ekran okuyucu kullanıcılarının verilerinin geri yüklendiğini ve kaldıkları yerden devam edebileceklerini doğrulayan bir aria-live bölgesine veya odaklanmış bir duyuruya ihtiyaçları vardır. Bu olmadan, çalışmalarının kaydedildiğini fark etmeyebilirler.
  • AJAX tabanlı oturumları sayfa tabanlı oturumlardan farklı ele almak: Jeton tabanlı kimlik doğrulama (örneğin JWT zaman aşımı) kullanan tek sayfalı uygulamalar, jeton süresi dolduğunda kullanıcıya yeniden kimlik doğrulama ve devam etme şansı vermeden API çağrılarında sessizce başarısız olabilir. Yeniden kimlik doğrulama mekanizması SPA mimarileri için de aynı derecede sağlam olmalıdır.
  • Önceden veri kaydı olmadan <meta http-equiv='refresh'> kullanarak zorla oturum kapatma: Zaman aşımında tetiklenen bir meta yenileme, kullanıcıyı sunucu tarafı durum koruması olmadan anında yönlendirir ve veri kurtarmayı imkânsız hale getirir. Oturum yönetimi, uygun durum kalıcılığı ile uygulama katmanında ele alınmalıdır.
  • Kısa oturumların bu ölçüt ihtiyacını ortadan kaldırdığını varsaymak: 5 dakikalık bir oturum zaman aşımı bile yavaş yazan bir kullanıcıyı, talimatları yeniden okuyan bilişsel engelli bir kullanıcıyı veya bir bakıcı tarafından bölünen birini yakalayabilir. Zaman aşımının süresi, yeniden kimlik doğrulama boyunca verileri koruma yükümlülüğünü değiştirmez.

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ımlanmıştır), dijital erişilebilirlik için ulusal çerçeveyi oluşturur ve teknik standart temeli olarak WCAG 2.2’ye atıfta bulunur. Genelge, Türkiye’de faaliyet gösteren geniş bir yelpazedeki kuruluş için uyumu zorunlu kılar; bunlar arasında kamu kurum ve kuruluşları, e-ticaret platformları, bankalar ve finansal hizmet sağlayıcıları, hastaneler ve özel sağlık hizmeti sunucuları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MoNE) tarafından yetkilendirilmiş özel eğitim kurumları yer alır.

WCAG 2.2.5 Yeniden Kimlik Doğrulama bir Seviye AAA ölçütüdür; bu da Genelge kapsamında asgari yasal olarak zorunlu tutulan gereksinimler arasında olmadığı anlamına gelir (Genelge, Seviye A ve AA uyumunu hedefler). Ancak, erişilebilirlikte liderlik göstermeyi, engelliler de dahil olmak üzere çeşitli kullanıcı gruplarına hizmet etmeyi veya kendilerini sınıfının en iyisi dijital hizmet sağlayıcıları olarak konumlandırmayı amaçlayan kuruluşlar, özellikle 2.2.5 kadar pratik etkisi yüksek olan Seviye AAA ölçütlerini, peşinden gitmeye değer hedefler olarak ele almalıdır.

Kapsam dâhilindeki bazı kuruluş kategorilerinin 2.2.5’i uygulamak için özellikle güçlü gerekçeleri vardır. Bankalar ve finansal platformlar genellikle kredi başvuruları, hesap açılışları veya yatırım ürünleri için kullanıcıların uzun formlar doldurmasını gerektirir ve güvenlik odaklı kısa oturum zaman aşımları, veri koruma yükümlülükleriyle doğrudan gerilim yaratır. Hastaneler ve sağlık portalları, randevu alma veya sağlık anketi doldurma gibi kritik görevler sırasında hastaları veri kaybına maruz bırakır; bu da bakım sürekliliği açısından gerçek sonuçlar doğurabilir. Kamu kurumları, vergi beyanı, ruhsat başvuruları veya yardım talepleri gibi e-devlet hizmetleri sunarken, karmaşık devlet formlarını tamamlamak için daha uzun süreye ihtiyaç duyabilecek engelli vatandaşlara hizmet eder.

Seviye AAA uyumu yasal olarak zorunlu olmasa bile, Türkiye’deki kuruluşlar, düzenleyicilerin, sivil toplum kuruluşlarının ve engelli hakları savunucularının dijital erişilebilirlik uygulamalarının kalitesini ve bütünlüğünü giderek daha fazla mercek altına aldığının farkında olmalıdır. 2.2.5 gibi Seviye AAA ölçütleriyle uyumu belgelendirmek, bir kuruluşun erişilebilirlik beyanını güçlendirir, dava riskini azaltır ve asgari kutu işaretleme uyumunun ötesinde kapsayıcı tasarıma gerçek bir bağlılık gösterir. Özellikle Türkiye ile birlikte AB pazarlarında faaliyet gösteren uluslararası erişime sahip kuruluşlar için, Seviye AAA ölçütleri Avrupa Erişilebilirlik Yasası (EAA) ve ilgili ulusal uygulamalar kapsamındaki gerekliliklerle kesişebilir.