WCAG 2.2.5: إعادة المصادقة

يتطلب المعيار WCAG 2.2.5 أنه عند انتهاء جلسة مصادقة، يمكن للمستخدمين إعادة المصادقة ومتابعة نشاطهم دون فقدان أي بيانات كانوا قد أدخلوها. يُعد هذا المعيار بالغ الأهمية للمستخدمين ذوي الإعاقة الذين قد يحتاجون إلى وقت أطول لإكمال المهام، ولا يجب أن يُعاقَبوا بانتهاء الجلسات الذي يمحو عملهم.

ماذا يعني هذا المعيار

المعيار WCAG 2.2.5 Re-authenticating يندرج تحت الإرشاد 2.2 (وقت كافٍ) وهو متطلب من مستوى AAA. ينص المعيار على ما يلي: "عندما تنتهي صلاحية جلسة مصادَقة، يمكن للمستخدم متابعة النشاط دون فقدان البيانات بعد إعادة المصادَقة." عملياً، يعني هذا أنه إذا كان المستخدم في منتصف تعبئة نموذج، أو إتمام عملية شراء، أو كتابة رسالة، أو تنفيذ أي مهمة متعددة الخطوات على منصة تتطلب المصادَقة وانتهت صلاحية جلسته، فيجب أن يكون قادراً على تسجيل الدخول مرة أخرى ومتابعة العمل من النقطة نفسها التي توقف عندها — مع الحفاظ على جميع البيانات التي أدخلها سابقاً.

هذا المعيار مرتبط ارتباطاً وثيقاً بالمعيارين WCAG 2.2.1 (قابلية ضبط التوقيت، مستوى A) و2.2.4 (المقاطعات، مستوى AAA)، لكنه يعالج سيناريو محدداً: لحظة تجاوز حدود الجلسة. بينما يطلب منك المعيار 2.2.1 منح المستخدمين وقتاً كافياً أو السماح لهم بتمديد الجلسة، يتعامل المعيار 2.2.5 مع حالة الفشل — أي ما يحدث بعد انقضاء الوقت. يعمل المعياران معاً: من الناحية المثالية تقوم بتمديد الجلسة وفي الوقت نفسه الحفاظ على البيانات إذا انتهت صلاحيتها.

لتحقيق النجاح وفق هذا المعيار، يجب على المنصة الحفاظ على جميع البيانات التي أدخلها المستخدم — حقول النص، الخيارات المحددة، الملفات المرفقة، مربعات الاختيار، أزرار الاختيار، وأي حالة أخرى للنموذج — عبر حدث إعادة المصادَقة. بعد أن يسجل المستخدم الدخول مرة أخرى، يجب إعادته إلى نفس النقطة في النشاط الذي كان يقوم به، مع بقاء بياناته سليمة وإمكانية إكمال المهمة دون تكرار.

يحدث الفشل عندما يؤدي انتهاء مهلة الجلسة إلى أي مما يلي: يتم توجيه المستخدم إلى صفحة تسجيل الدخول، وبعد تسجيل الدخول بنجاح يُرسل إلى الصفحة الرئيسية بدلاً من الصفحة التي كان عليها؛ يتم فقدان بيانات النموذج التي أُدخلت قبل انتهاء المهلة ويضطر المستخدم إلى إعادة إدخال كل شيء؛ تتم إعادة تعيين حالة معالج متعدد الخطوات كان قد أُنجز جزئياً؛ أو يتم ببساطة تسجيل خروج المستخدم دون وجود آلية لإعادة المصادَقة والمتابعة.

لا يحدد المعيار الرسمي لـ WCAG مدة دنيا للجلسة لهذا المعيار — فهو ينطبق بغض النظر عن طول أو قِصر فترة انتهاء المهلة. ومع ذلك، لاحظ أنه لا توجد أي استثناءات لفقدان البيانات بسبب مخاوف أمنية؛ التوقع هو أن تجد التطبيقات طرقاً آمنة للحفاظ على الحالة، مثل تخزين الجلسة على الخادم باستخدام مفتاح مرتبط بهوية المستخدم، أو رموز مشفّرة على جانب العميل تبقى صالحة خلال تدفق إعادة المصادَقة.

لماذا يهم هذا المعيار

انتهاء الجلسات بطريقة تمحو البيانات يخلق عبئاً غير متناسب الشدة على الأشخاص ذوي الإعاقة. كثير من المستخدمين ذوي الإعاقة يحتاجون إلى وقت أطول بكثير لإكمال المهام الرقمية مقارنةً بأقرانهم غير المعاقين، وغالباً لا يمكنهم ببساطة "الكتابة بسرعة أكبر" أو "التحايل" على مهلة زمنية عشوائية.

المستخدمون الذين هم مكفوفون أو ضعاف البصر يتنقلون في النماذج باستخدام قارئات الشاشة، وهو ما يكون أبطأ بطبيعته من المسح البصري. قد يقضي مستخدم كفيف 20 أو 30 دقيقة في تعبئة نموذج طويل لمطالبة تأمين، يتنقل بعناية من حقل إلى آخر، ليُمحى كل عمله عندما تنطلق مهلة جلسة مدتها 15 دقيقة. ثم يضطر للبدء من جديد — دون أي ضمان بألا يحدث الشيء نفسه مرة ثانية.

الأشخاص ذوو الإعاقات الحركية — مثل الذين يستخدمون أجهزة الوصول بالمفاتيح (switch access)، أو تقنيات تتبع العين، أو عصي الفم — قد يستغرقون وقتاً أطول بعدة مرات من المتوسط لإدخال النص والتنقل في النماذج. قد يكون مستخدم مصاب بمرض ALS أو ضمور العضلات الشوكي يكتب نموذج إحالة طبية حرجاً ولا يكتب سوى بضعة أحرف في الدقيقة. مهلات الجلسة التي تدمر عملهم ليست مجرد إزعاج بسيط؛ بل يمكن أن تكون حاجزاً كاملاً يمنعهم من إكمال مهام أساسية.

المستخدمون ذوو الإعاقات الإدراكية، بما في ذلك المصابون بعُسر القراءة، أو اضطراب فرط الحركة وتشتت الانتباه (ADHD)، أو إصابات الدماغ الرضّية، أو الخَرَف، قد يحتاجون إلى إعادة قراءة التعليمات عدة مرات، أو أخذ فترات استراحة لمعالجة المعلومات، أو ببساطة التحرك ببطء أكثر عبر العمليات متعددة الخطوات. تُظهر الأبحاث باستمرار أن هذه الفئة تتأثر بشكل غير متناسب بضغوط الوقت وفقدان البيانات — وكلاهما يزيد العبء الإدراكي لمحاولة البدء من الصفر.

فكّر في سيناريو واقعي ملموس: مستخدم مصاب بالتصلب المتعدد يتقدم بطلب للحصول على إعانة إعاقة حكومية عبر بوابة إلكترونية لمؤسسة عامة. يتكون الطلب من 8 خطوات ويتطلب تحميل مستندات طبية، وإدخال تاريخ التوظيف، وكتابة بيان شخصي. يصل إلى الخطوة السادسة خلال 45 دقيقة، تنتهي جلسته، وتُفقد جميع البيانات التي أدخلها. عليه الآن جمع المستندات نفسها مرة أخرى وتكرار العملية بأكملها، وقد يتخلى عن الطلب تماماً. هذا ليس افتراضاً نظرياً — بل نمط موثق مراراً في أبحاث وتجارب قابلية الوصول مع المستخدمين.

بعيداً عن الإعاقة، فإن فقدان البيانات عند انتهاء الجلسة يؤثر على جميع المستخدمين وله آثار تجارية قابلة للقياس: عربات تسوق مهجورة، تسجيلات غير مكتملة، وفرص مبيعات مفقودة. الحفاظ على حالة الجلسة هو في آن واحد ضرورة من منظور الوصول، وممارسة سليمة في تجربة المستخدم وتحسين معدلات التحويل. وفقاً لـ Baymard Institute، فإن التخلي عن النماذج هو مساهم رئيسي في معدلات التخلي عن عربات التسوق في التجارة الإلكترونية، ويُعد فقدان البيانات غير المتوقع أحد أهم الأسباب التي يذكرها المستخدمون لعدم إكمال عمليات الشراء عبر الإنترنت.

قواعد Axe-core ذات الصلة

يتطلب المعيار WCAG 2.2.5 اختباراً يدوياً فقط. لا توجد قواعد آلية في axe-core يمكنها اكتشاف انتهاكات هذا المعيار بشكل موثوق. يوضح ما يلي سبب قصور الأدوات الآلية وما الذي يجب على المختبرين البشر القيام به بدلاً من ذلك:

لا توجد قاعدة آلية للحفاظ على حالة الجلسة: تعمل axe-core ومحركات الوصول الآلي المشابهة من خلال فحص DOM الحالي وتقييم الشروط الثابتة أو شبه الثابتة مثل نسب تباين الألوان، وصحة سمات ARIA، والنص البديل المفقود. لا يمكنها محاكاة مرور الوقت، أو تشغيل حدث انتهاء الجلسة، أو إرسال بيانات إعادة المصادَقة، ثم التحقق مما إذا كانت البيانات المدخلة سابقاً قد تمت استعادتها. هذا التسلسل بأكمله سلوك يعتمد على الحالة والزمن ويتطلب إنساناً (أو اختباراً شاملاً end-to-end مكتوباً) لملاحظته.
اكتشاف انتهاء مهلة الجلسة خارج نطاق التحليل الساكن: حتى لو تمكنت أداة آلية من اكتشاف أن الصفحة تطبق مهلة للجلسة (على سبيل المثال بقراءة وسم meta refresh أو استدعاء JavaScript setTimeout)، فإنها لا تستطيع تقييم ما يحدث لبيانات المستخدم بعد انطلاق انتهاء المهلة. سلوك الحفاظ على البيانات موجود في منطق إدارة الجلسة على الخادم، وليس في بنية DOM التي تحللها الأدوات الآلية.
تعقيد تدفق إعادة المصادَقة: قد تتضمن تجربة إعادة المصادَقة عدة صفحات (نموذج تسجيل الدخول، خطوة المصادَقة متعددة العوامل MFA، إعادة التوجيه)، وقد تعتمد استعادة الحالة على منطق على الخادم، أو ملفات تعريف الارتباط، أو التخزين المحلي، أو معلمات عنوان URL. لا يمكن لأي أداة فحص DOM لصفحة واحدة تتبع هذا التدفق متعدد الصفحات والأنظمة.
لماذا الاختبار اليدوي ضروري: يجب على مختبر مؤهل أن يبدأ يدوياً سير عمل يتطلب المصادَقة، وينتظر عمداً انتهاء الجلسة أو يسبب انتهائها، ويكمل عملية إعادة المصادَقة، ثم يتحقق من سلامة البيانات. هذه هي الطريقة الموثوقة الوحيدة لاختبار الامتثال. يمكن استخدام الفحوصات الآلية كنقطة بداية للإشارة إلى مشكلات ذات صلة (مثل آليات تحذير الجلسة المفقودة التي يغطيها المعيار 2.2.1)، لكنها لا يمكن أن تحل محل الاختبار اليدوي للمعيار 2.2.5.

كيفية الاختبار

تحديد مسارات العمل التي تتطلب المصادَقة وتحتوي على نماذج أو عمليات متعددة الخطوات. ابدأ برسم خريطة لجميع مناطق الموقع التي تتطلب المصادَقة وتتضمن إدخال بيانات من المستخدم — تدفقات الدفع، محررات الملف الشخصي، نماذج الطلبات، أنظمة الحجز، واجهات المراسلة، ولوحات التحكم الإدارية. هذه هي المناطق الأعلى خطراً للفشل في المعيار 2.2.5.
تحديد مدة مهلة الجلسة. تحقق من إعدادات الخادم أو إعدادات التطبيق، أو استشر فريق التطوير لمعرفة متى تنتهي صلاحية الجلسات. بدلاً من ذلك، ابدأ جلسة وانتظر حتى يتم تسجيل خروجك تلقائياً. دوّن المدة. تتراوح المهلات الشائعة بين 15 دقيقة و2 ساعة.
بدء مهمة وإدخال بيانات كبيرة نسبياً. سجّل الدخول وابدأ في تعبئة نموذج تمثيلي — على سبيل المثال، تدفق تسجيل متعدد الحقول أو عملية شراء. أدخل نصاً في حقول النص، واختر خيارات، وتقدم عبر أي خطوات في المعالج. لا ترسل النموذج.
تفعيل انتهاء الجلسة. إما أن تنتظر انتهاء المهلة بشكل طبيعي، أو — إذا كان لديك وصول مطوّر — قم بإنهاء الجلسة بشكل مصطنع عن طريق إبطال ملف تعريف ارتباط الجلسة في أدوات المطور في المتصفح (علامة التبويب Application > Cookies > حذف ملف تعريف ارتباط الجلسة)، أو عن طريق إنهاء الجلسة مباشرة على الخادم.
ملاحظة مطالبة إعادة المصادَقة. تحقق مما إذا كان الموقع يطالبك بإعادة المصادَقة (نجاح) أو ببساطة يعيد توجيهك إلى صفحة تسجيل الدخول دون تحذير (مشكلة في سهولة الاستخدام ذات صلة، رغم أن المعيار 2.2.5 يركز على الحفاظ على البيانات، لا على التحذير نفسه). حاول تسجيل الدخول مرة أخرى.
التحقق من الحفاظ على البيانات بعد تسجيل الدخول. بعد إعادة المصادَقة بنجاح، لاحظ إلى أين يتم توجيهك وما إذا كانت بياناتك المدخلة سابقاً لا تزال سليمة. إذا تم توجيهك إلى الصفحة الرئيسية و/أو فُقدت بيانات النموذج، فهذا فشل في المعيار 2.2.5.
الاختبار باستخدام تقنيات المساعدة. كرر تسلسل الاختبار أعلاه باستخدام NVDA مع Firefox، وJAWS مع Chrome، وVoiceOver مع Safari للتأكد من أن مطالبة إعادة المصادَقة متاحة لمستخدمي قارئات الشاشة وأن حالة الصفحة المستعادة يتم الإعلان عنها بشكل صحيح. قد يتعرف المستخدم المبصر على البيانات المستعادة بصرياً؛ بينما يحتاج مستخدم قارئ الشاشة إلى وضع التركيز بشكل صحيح وأن تكون المحتويات المستعادة ضمن ترتيب القراءة.
الاختبار باستخدام التنقل عبر لوحة المفاتيح فقط. تأكد من أن عملية إعادة المصادَقة بأكملها — من إشعار انتهاء الجلسة إلى تسجيل الدخول مرة أخرى والعودة إلى المهمة المحفوظة — يمكن إكمالها باستخدام لوحة المفاتيح فقط، دون الحاجة إلى الفأرة.
الاختبار باستخدام محاكاة مهلات ممتدة. إذا أمكن، قلّل مهلة الجلسة إلى 1–2 دقيقة في بيئة التطوير وأجرِ اختبارات كاملة لرحلة المستخدم لجعل دورة الاختبار أسرع وأكثر قابلية للتكرار.

كيفية الإصلاح

نموذج تسجيل دخول بسيط مع مهلة جلسة — غير صحيح

<!-- 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. -->

نموذج تسجيل دخول بسيط مع مهلة جلسة — صحيح

<!-- 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>

معالج متعدد الخطوات يفقد التقدم — غير صحيح

<!-- 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>

معالج متعدد الخطوات يفقد التقدم — صحيح

<!-- 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>

تحذير بانتهاء الجلسة دون الحفاظ على البيانات — غير صحيح

<!-- 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>

تحذير بانتهاء الجلسة دون الحفاظ على البيانات — صحيح

<!-- 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>

الأخطاء الشائعة

إعادة التوجيه إلى الصفحة الرئيسية بعد إعادة المصادَقة بدلاً من الصفحة الأصلية: نمط الفشل الأكثر شيوعاً. بعد تسجيل الدخول، يرسل التطبيق المستخدم إلى /dashboard أو / بدلاً من عنوان URL الذي كان عليه عندما انتهت جلسته، مما يجبره على العودة إلى مهمته يدوياً — بينما تكون بياناته قد فُقدت بالفعل.
تخزين حالة النموذج في ذاكرة JavaScript فقط أو في حالة مكوّن React/Vue: حالة أطر العمل على جانب العميل لا تبقى بعد إعادة تحميل الصفحة الناتجة عن إعادة التوجيه إلى صفحة تسجيل الدخول عند انتهاء الجلسة. يجب حفظ الحالة على الخادم أو في آلية تخزين (مثل localStorage) تُستعاد بشكل موثوق عند العودة.
حفظ "عنوان URL للعودة" دون بيانات النموذج: بعض التطبيقات تخزن عنوان URL لإعادة التوجيه إليه بعد تسجيل الدخول لكنها لا تحفظ القيم الفعلية لحقول النموذج. يصل المستخدم إلى الصفحة الصحيحة ولكن مع حقول فارغة، وهو ما يزال انتهاكاً للمعيار 2.2.5.
الحفظ التلقائي في sessionStorage الذي يُمسح عند إغلاق التبويب: إذا تسبب انتهاء الجلسة في انتقال تبويب المتصفح إلى صفحة أخرى (مثل إعادة التوجيه إلى تسجيل الدخول)، يتم مسح sessionStorage. استخدم localStorage مع مساحة اسم مرتبطة بالمستخدم، أو يفضّل تخزين المسودات على الخادم.
عدم الاختبار مع حقول رفع الملفات: لا يمكن تعبئة حقول رفع الملفات مسبقاً بواسطة HTML لأسباب أمنية. إذا كان النموذج يتضمن رفع ملف تم قبل انتهاء الجلسة، فسيُفقد مرجع الملف. يجب على التطبيقات التعامل مع ذلك عن طريق تخزين مراجع الملفات المرفوعة على الخادم وإظهار أن الملف ما زال مرفقاً للمستخدم.
مسح بيانات المسودة المحفوظة فوراً عند إعادة المصادَقة: بعض التطبيقات تحذف المسودة بمجرد تسجيل دخول المستخدم، قبل التحقق من أن المستخدم قد رأى البيانات المستعادة وأكّدها فعلاً. يجب الحفاظ على المسودة حتى تُستكمل المهمة صراحة أو تُلغى.
عدم الإعلان عن البيانات المستعادة لمستخدمي قارئات الشاشة: بعد إعادة المصادَقة وإعادة التوجيه، يحتاج مستخدمو قارئات الشاشة إلى منطقة aria-live أو إعلان يركّز عليه المؤشر يؤكد أن بياناتهم قد تمت استعادتها وأن بإمكانهم المتابعة من حيث توقفوا. بدون ذلك، قد لا يعلمون أن عملهم قد تم حفظه.
معاملة الجلسات المعتمدة على AJAX بشكل مختلف عن الجلسات المعتمدة على الصفحات: التطبيقات أحادية الصفحة (SPA) التي تستخدم مصادَقة قائمة على الرموز (مثل انتهاء صلاحية JWT) غالباً ما تفشل استدعاءات API بصمت عند انتهاء صلاحية الرمز دون منح المستخدم فرصة لإعادة المصادَقة والمتابعة. يجب أن تكون آلية إعادة المصادَقة قوية بالقدر نفسه في بنية SPA.
استخدام <meta http-equiv='refresh'> لفرض تسجيل الخروج دون حفظ البيانات مسبقاً: يؤدي وسم meta refresh الذي ينطلق عند انتهاء المهلة إلى إعادة توجيه المستخدم فوراً دون أي حفظ لحالة الخادم، مما يجعل استعادة البيانات مستحيلة. يجب إدارة الجلسة على مستوى التطبيق مع الحفاظ الصحيح على الحالة.
افتراض أن الجلسات القصيرة تلغي الحاجة إلى هذا المعيار: حتى مهلة جلسة مدتها 5 دقائق يمكن أن تطال كاتباً بطيئاً، أو مستخدماً ذا إعاقة إدراكية يعيد قراءة التعليمات، أو شخصاً قاطعه مقدم رعاية. مدة المهلة لا تغيّر الالتزام بالحفاظ على البيانات عبر إعادة المصادَقة.

العلاقة مع لوائح الوصول في تركيا

تضع التعميم الرئاسي 2025/10 في تركيا (المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025) الإطار الوطني لقابلية الوصول الرقمية وتشير إلى WCAG 2.2 كأساس معياري تقني. يفرض التعميم الامتثال على مجموعة واسعة من الكيانات العاملة في تركيا، بما في ذلك المؤسسات والهيئات العامة، منصات التجارة الإلكترونية، البنوك ومقدمي الخدمات المالية، المستشفيات ومقدمي الرعاية الصحية الخاصة، شركات الاتصالات التي لديها 200,000 مشترك أو أكثر، وكالات السفر، شركات النقل الخاصة، والمؤسسات التعليمية الخاصة المخوّلة من قبل وزارة التربية الوطنية (MoNE).

المعيار WCAG 2.2.5 Re-authenticating هو معيار من مستوى AAA، ما يعني أنه ليس ضمن الحد الأدنى من المتطلبات القانونية الإلزامية بموجب التعميم (الذي يستهدف الامتثال لمستويي A وAA). ومع ذلك، ينبغي على المنظمات التي تسعى لإظهار الريادة في مجال الوصول، وخدمة شرائح مستخدمين متنوعة بما في ذلك الأشخاص ذوي الإعاقة، أو تقديم نفسها كمزوّدين لخدمات رقمية رائدة في فئتها أن تتعامل مع معايير مستوى AAA — وخاصة تلك ذات الأثر العملي الكبير مثل 2.2.5 — كأهداف طموحة تستحق السعي لتحقيقها.

بعض فئات الكيانات المشمولة لديها أسباب قوية بشكل خاص لتطبيق المعيار 2.2.5. غالباً ما تتطلب البنوك والمنصات المالية من المستخدمين تعبئة نماذج طويلة لطلبات القروض، أو فتح الحسابات، أو منتجات الاستثمار، وتخلق مهلات الجلسة القصيرة المدفوعة بالاعتبارات الأمنية توتراً مباشراً مع التزامات الحفاظ على البيانات. تعرّض المستشفيات وبوابات الرعاية الصحية المرضى لخطر فقدان البيانات أثناء مهام حرجة مثل حجز المواعيد أو تعبئة الاستبيانات الصحية، وهو ما يمكن أن تكون له عواقب حقيقية على استمرارية الرعاية. تقدم المؤسسات العامة التي تدير خدمات الحكومة الإلكترونية — مثل تقديم الإقرارات الضريبية، أو طلبات التصاريح، أو مطالبات الإعانات — خدماتها لمواطنين من ذوي الإعاقة قد يحتاجون إلى وقت ممتد لإكمال النماذج الحكومية المعقدة.

حتى في الحالات التي لا يكون فيها الامتثال لمستوى AAA مطلوباً قانوناً، ينبغي على المنظمات التركية أن تدرك أن الجهات التنظيمية، ومنظمات المجتمع المدني، والمدافعين عن حقوق الأشخاص ذوي الإعاقة يزدادون تدقيقاً في جودة وكمال تطبيقات الوصول الرقمية. إن توثيق الامتثال لمعايير مستوى AAA مثل 2.2.5 يعزز بيان الوصول الخاص بالمنظمة، ويقلل من مخاطر التقاضي، ويُظهر التزاماً حقيقياً بالتصميم الشامل يتجاوز الحد الأدنى من الامتثال الشكلي. بالنسبة للكيانات ذات الامتداد الدولي، وخاصة تلك التي تعمل في أسواق الاتحاد الأوروبي إلى جانب تركيا، قد تتقاطع معايير مستوى AAA مع المتطلبات المنصوص عليها في قانون الوصول الأوروبي (EAA) والتنفيذات الوطنية ذات الصلة.