WCAG 2.2.6: انتهاء المهلة

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

يتطلب المعيار WCAG 2.2.6 Timeouts (المستوى AAA) تحذير المستخدمين من مدة أي فترة خمول يمكن أن تؤدي إلى فقدان البيانات، ما لم تُحفظ البيانات لأكثر من 20 ساعة من خمول المستخدم. عملياً، يعني هذا أنه إذا كان من الممكن أن يفقد تطبيقك أو خدمتك على الويب بيانات المستخدم — مثل إدخالات النماذج، أو سلة التسوق، أو معاملة جارية — بسبب خمول المستخدم لفترة من الزمن، فيجب عليك إبلاغ المستخدمين بالضبط بالمدة المتاحة لهم قبل فقدان تلك البيانات.

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

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

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

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

لماذا يهم

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

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

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

فكر في هذا السيناريو الواقعي: مستخدم مصاب بالتصلب المتعدد يتقدم بطلب للحصول على إعانة إعاقة عبر بوابة حكومية. يحتوي النموذج على 12 قسمًا ويتطلب تحميل مستندات داعمة. تنتهي الجلسة بعد 15 دقيقة من الخمول، لكن المستخدم توقف في منتصف القسم 7 لاسترجاع مستند من غرفة أخرى. عند عودته، تم مسح جميع البيانات ويجب عليه البدء من جديد — دون أي تحذير مسبق بأن هذا سيحدث. بموجب 2.2.6، سيكون مطلوبًا من البوابة إبلاغ المستخدم منذ البداية بأن الخمول لأكثر من 15 دقيقة سيؤدي إلى فقدان البيانات، مما يمكّنه من التخطيط وفقًا لذلك.

إضافة إلى جانب إمكانية الوصول، فإن الإفصاح الاستباقي عن سلوك المهلة يحسن تجربة المستخدم للجميع ويقلل معدلات التخلي في مسارات التحويل عالية القيمة مثل الدفع، والتسجيل، ونماذج التقديم. كما يعزز الثقة، إذ لا يُترك المستخدمون يتساءلون عن سبب اختفاء بياناتهم.

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

يتطلب المعيار WCAG 2.2.6 اختبارًا يدويًا. لا توجد قاعدة آلية في axe-core يمكنها اكتشاف هذا الانتهاك، وفهم السبب في ذلك مهم لكل من المختبرين والمطورين.

• اختبار يدوي مطلوب — الإفصاح عن مهلة الجلسة: يمكن للأدوات الآلية مثل axe-core فحص DOM بحثًا عن وجود أو غياب عناصر أو سمات أو أنماط نصية محددة، لكنها لا تستطيع تحديد ما إذا كان تطبيق الويب سيفقد بيانات المستخدم بعد فترة من الخمول. عادة ما يُحكم سلوك المهلة من خلال إعدادات الجلسة على جانب الخادم (مثل مدة صلاحية الجلسة في PHP أو Node.js)، وقد يظهر الإفصاح — إن وجد — في نص الترحيب، أو مربع حوار، أو صفحة مساعدة، أو حتى في قسم شروط الخدمة. لا يمكن لأي تحليل ثابت لـ DOM أن يربط بشكل موثوق قطعة من النص المعلوماتي بالسلوك الفعلي لمهلة الخادم. لا يمكن للأداة أن تعرف ما إذا كانت جملة مثل "من أجل أمانك، تنتهي الجلسات بعد 15 دقيقة" دقيقة، أو ما إذا كانت تنطبق على بيانات الصفحة الحالية، أو ما إذا كانت موضوعة في وقت مبكر بما يكفي في رحلة المستخدم لتكون قابلة للتنفيذ. وحده المختبر البشري الذي يمكنه التفاعل مع التطبيق، وملاحظة سلوكه بمرور الوقت، وتقييم اكتمال وتوقيت أي إفصاحات يمكنه تحديد الامتثال.
• اختبار يدوي مطلوب — التحقق من حفظ البيانات: لا يمكن لـ axe-core أيضًا التحقق من استثناء 20 ساعة. ما إذا كانت البيانات محفوظة فعليًا على الخادم لأكثر من 20 ساعة — وبالتالي ما إذا كان الإفصاح مطلوبًا من الأساس — يعتمد بالكامل على منطق الخلفية غير المرئي لأداة الفحص القائمة على المتصفح. يجب على المختبرين إما مراجعة إعدادات الخادم، أو التحدث مع المطورين، أو الاختبار تجريبيًا بترك نموذج مكتمل جزئيًا لفترة طويلة وملاحظة ما إذا كانت البيانات تستمر.

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

1. فحص آلي مبدئي: شغّل axe DevTools أو Lighthouse على الصفحة التي تحتوي على النموذج، أو مسار الدفع، أو واجهة إدخال البيانات الأخرى. رغم أن أياً من الأداتين لن يعلّم انتهاك 2.2.6 مباشرة، استخدم هذه الخطوة لتحديد أي مناطق ARIA حية أو مكونات حوارية متعلقة بالمهلة قد تكون جزءًا من آلية التحذير، وتحقق من أنها في حد ذاتها متاحة (أدوار صحيحة، تسميات، إدارة تركيز).
2. تحديد سلوك المهلة: تحدث مع فريق التطوير أو راجع إعدادات الخادم لتحديد مدة مهلة الخمول للجلسة. تشمل المواقع الشائعة ملفات إعدادات خادم الويب، وإعدادات وسيط الجلسة في التطبيق، ووثائق مزود المصادقة. سجّل المدة الدقيقة بالدقائق.
3. التحقق من الإفصاح المسبق: حمّل الصفحة من جديد واقرأ كل المحتوى المعروض للمستخدم قبل بدء أي إدخال بيانات. ابحث عن بيان واضح — في متن الصفحة، أو فقرة تمهيدية، أو شريط، أو مربع حوار — يحدد مدة مهلة الخمول بدقة ويذكر أن البيانات ستُفقد إذا كان المستخدم غير نشط لتلك الفترة. يجب أن يذكر الإفصاح المدة صراحة (مثل "15 دقيقة")، لا بشكل غامض (مثل "فترة قصيرة").
4. الاختبار باستخدام قارئ شاشة: باستخدام NVDA مع Firefox، أو VoiceOver مع Safari، أو JAWS مع Chrome، تنقل في الصفحة من البداية. تأكد من أن أي إفصاح عن المهلة يمكن الوصول إليه ويُقرأ بصوت عالٍ بواسطة قارئ الشاشة دون أن يضطر المستخدم للبحث عنه بنشاط. إذا كان الإفصاح في شريط بارز بصريًا، فتحقق من وجوده في ترتيب القراءة قبل أول حقل في النموذج.
5. محاكاة الخمول: ابدأ في ملء النموذج. ثم توقف عن التفاعل مع الصفحة لمدة أقل قليلاً من فترة المهلة، ولاحظ ما يحدث. ثم كرر، وانتظر حتى تنقضي فترة المهلة. سجّل ما إذا كانت البيانات تُفقد، وما إذا كان تحذير يُعرض قبل حدوث فقدان البيانات، وما إذا كان هذا التحذير قد تم إبلاغه قبل بدء الجلسة.
6. اختبار استثناء 20 ساعة: إذا ادعى الفريق أن البيانات تُحفظ لأكثر من 20 ساعة، فتحقق من ذلك تجريبيًا عن طريق إكمال نموذج جزئيًا، والانتظار لمدة لا تقل عن 20 ساعة، ثم العودة إلى الصفحة للتأكد من أن البيانات لا تزال موجودة. بدلاً من ذلك، راجع إعدادات مخزن الجلسة على الخادم مع فريق التطوير.
7. اختبار لوحة المفاتيح والتركيز: إذا ظهر مربع حوار تحذير من المهلة أو إشعار، فتحقق باستخدام التنقل بلوحة المفاتيح فقط من أنه يحصل على التركيز تلقائيًا، وأن محتواه قابل للقراءة بالكامل، وأن المستخدم يمكنه إغلاقه أو اتخاذ إجراء (مثل تمديد الجلسة) دون استخدام الفأرة.

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

جلسة مع فقدان بيانات صامت — غير صحيح

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

جلسة مع فقدان بيانات صامت — صحيح

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

جلسة دفع مع تحذير غامض — غير صحيح

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

جلسة دفع مع تحذير غامض — صحيح

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

البيانات محفوظة على الخادم لأكثر من 20 ساعة — صحيح (ينطبق الاستثناء)

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

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

• عرض تحذير المهلة فقط داخل وحدة تحكم المتصفح أو في سجل الخادم غير المرئي للمستخدمين النهائيين — يجب تقديم التحذير في واجهة المستخدم، في موقع سيصادفه المستخدم قبل حدوث فقدان البيانات.
• وضع الإفصاح في تذييل الصفحة، أو سياسة الخصوصية، أو صفحة شروط الخدمة التي من غير المرجح أن يقرأها المستخدمون قبل بدء إدخال البيانات، بدلاً من وضعه مباشرة على النموذج نفسه أو قبله مباشرة.
• استخدام مربع حوار (modal) لتحذير المستخدمين من قرب انتهاء الجلسة دون نقل تركيز لوحة المفاتيح إلى المربع — قد لا يدرك مستخدمو لوحة المفاتيح وقارئات الشاشة أن التحذير ظهر.
• ذكر طول الجلسة (مثل "تستمر جلستك 30 دقيقة") بدلاً من مهلة الخمول (مثل "بعد 15 دقيقة من الخمول، ستُفقد بياناتك") — هذان مفهومان مختلفان، ولا يحكم المعيار 2.2.6 إلا فقدان البيانات الناتج عن الخمول.
• الافتراض بأنه لمجرد وجود مربع حوار تحذير من المهلة للمستخدمين المبصرين، فإن المعيار مستوفى — إذا لم يكن المربع متاحًا عبر لوحة المفاتيح، أو يفتقر إلى اسم متاح، أو لا يُعلن عنه عبر مناطق ARIA الحية أو إدارة التركيز، فلن يتلقى مستخدمو قارئات الشاشة التحذير.
• ضبط مهلة الجلسة على الخادم إلى 25 ساعة والاستنتاج بأن الإفصاح غير ضروري، مع الفشل في التحقق من أن حالة المتصفح أو مستوى التطبيق (مثل مخزن Redux أو localStorage) لا تُمسح في وقت أقرب — المهلة الفعلية هي أي آلية تفقد البيانات أولاً.
• الإفصاح عن مدة المهلة في تلميح أداة يُفعّل فقط عند التحويم — قد لا يصادف المستخدمون الذين يعتمدون على التنقل بلوحة المفاتيح أو الأجهزة اللمسية هذا الإفصاح أبدًا.
• الاعتماد على تحذير عام من نظام إدارة المحتوى أو الإطار يقول "انتهت الجلسة" يُعرض بعد حدوث فقدان البيانات بالفعل، بدلاً من إبلاغ المستخدمين بشكل استباقي قبل أن يبدؤوا في إدخال البيانات.
• عدم مراعاة المستخدمين الذين يفتحون النموذج في علامة تبويب في الخلفية: إذا كان مؤقت الجلسة يعمل بينما تكون علامة التبويب غير نشطة، فقد تُفقد البيانات قبل أن تتاح للمستخدم أي فرصة للتفاعل مع النموذج على الإطلاق. يعد هذا الأمر إشكاليًا بشكل خاص في متصفحات الأجهزة المحمولة التي تعلّق علامات التبويب في الخلفية بشكل عدواني.
• إغفال التحذير في الإصدارات المحمولة أو سياقات تطبيقات الويب التقدمية (PWA) مع عرضه في الإصدار المكتبي، مما يخلق تجربة غير متسقة تفشل في تلبية 2.2.6 لجزء كبير من المستخدمين.

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

تُرسخ المذكرة الرئاسية التركية 2025/10، المنشورة في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، التزامات ملزمة بشأن إمكانية الوصول على الويب لمجموعة واسعة من الكيانات العامة والخاصة العاملة في تركيا. تفرض المذكرة الامتثال لـ WCAG 2.2 كمعيار تقني، وتُلزم الكيانات المشمولة بتحقيق مستوى توافق لا يقل عن المستوى AA. يعد المعيار WCAG 2.2.6 Timeouts معيارًا من المستوى AAA، وبالتالي لا يُفرض مباشرة بموجب متطلبات خط الأساس في المذكرة. ومع ذلك، فإن نطاق المذكرة وهدفها يخلقان أسبابًا عملية قوية للكيانات المشمولة للسعي إلى الامتثال للمستوى AAA في معايير مثل 2.2.6.

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

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

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

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