WCAG 2.1.2: عدم وجود فخ لوحة المفاتيح

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

WCAG 2.1.2 — عدم وجود فخ لوحة المفاتيح (No Keyboard Trap) — هو معيار نجاح من المستوى A ضمن مبدأ إمكانية التشغيل (Operable). وينص على ما يلي: "إذا كان من الممكن نقل تركيز لوحة المفاتيح إلى مكوّن في الصفحة باستخدام واجهة لوحة المفاتيح، فيجب أن يكون من الممكن نقل التركيز بعيدًا عن ذلك المكوّن باستخدام واجهة لوحة المفاتيح فقط، وإذا كان ذلك يتطلب أكثر من مفاتيح الأسهم غير المعدّلة أو مفاتيح Tab لنقل التركيز بعيدًا، فيتم إبلاغ المستخدم بطريقة نقل التركيز."

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

يشمل هذا المعيار جميع عناصر HTML التي يمكنها استقبال تركيز لوحة المفاتيح: العناصر التفاعلية الأصلية مثل وسوم <input> و<select> و<textarea> و<button> و<a>، بالإضافة إلى الودجات المخصصة التي تستقبل التركيز عبر tabindex أو أدوار ARIA أو إدارة التركيز عبر JavaScript. وينطبق ذلك بالتساوي على المكوّنات المضمّنة من أطراف ثالثة مثل ودجات الدردشة ومشغّلات الفيديو وخرائط embeds ومنتقيات التواريخ ومحررات النصوص المنسقة.

يُعتبَر المكوّن مستوفيًا لهذا المعيار إذا كان بإمكان مستخدم لوحة المفاتيح دائمًا نقل التركيز بعيدًا عنه باستخدام المفاتيح القياسية — عادة Tab وShift+Tab وEscape أو مفاتيح الأسهم — أو إذا كانت الصفحة تُعلِم المستخدمين بوضوح بآلية لوحة مفاتيح غير قياسية لنقل التركيز بعيدًا. ويُعتبَر المكوّن غير مستوفٍ إذا أصبح التركيز محبوسًا بداخله دون مسار خروج يمكن الوصول إليه بلوحة المفاتيح، أو إذا كانت آلية الخروج الوحيدة تتطلب نقرة فأرة أو إيماءة لمس أو أي إدخال آخر غير لوحة المفاتيح.

يوفّر WCAG استثناءً ضيقًا: يُسمح بتقييد تركيز لوحة المفاتيح داخل مكوّن بشكل مؤقت عندما يكون ذلك جزءًا من نمط تصميم مقصود وقابل للوصول — وأبرز مثال على ذلك هو مربع الحوار النمطي (modal dialog). يجب أن يحصر مربع الحوار النمطي التركيز داخله أثناء فتحه (لمنع المستخدمين من التفاعل مع المحتوى الخلفي المحجوب)، لكنه يجب أن يوفّر دائمًا وسيلة يمكن الوصول إليها بلوحة المفاتيح لإغلاق مربع الحوار وإطلاق التركيز — مثل معالج لمفتاح Escape أو زر إغلاق مُسمّى بوضوح يمكن الوصول إليه عبر Tab. هذا النوع من احتواء التركيز المقصود والقابل للهروب ليس فخًا للوحة المفاتيح؛ بل هو تنفيذ صحيح لنمط مربع الحوار النمطي. يصبح الفخ فشلًا فقط عندما لا يستطيع المستخدم الهروب على الإطلاق.

لماذا يهم

تُعدّ أفخاخ لوحة المفاتيح من أشد إخفاقات الوصولية خطورة التي يمكن أن توجد في موقع ويب. على عكس العديد من مشكلات الوصولية الأخرى التي تُضعِف التجربة لبعض المستخدمين، يمكن لفخ لوحة المفاتيح أن يمنع المستخدم تمامًا من الاستمرار في استخدام الصفحة. فهو في جوهره يعادل وضع حاجز مادي في ممر دون توفير أي طريق لتجاوزه.

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

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

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

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

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

يتطلب WCAG 2.1.2 إجراء اختبارات يدوية. لا توجد قاعدة آلية في axe-core تكتشف أفخاخ لوحة المفاتيح بشكل مباشر وموثوق. يعود ذلك إلى أن الأدوات الآلية تعمل عبر تحليل البنية الثابتة لـ DOM — يمكنها تحديد العناصر القابلة للتركيز، والتحقق من ترتيب الانتقال عبر Tab، والتحقق من صحة سمات ARIA، لكنها لا تستطيع محاكاة تجربة التنقل التفاعلي الكاملة بلوحة المفاتيح التي يقوم بها المختبِر البشري. عادةً ما ينشأ فخ لوحة المفاتيح من منطق معالجة أحداث JavaScript الذي يعترض أو يمنع أحداث لوحة المفاتيح أثناء وقت التشغيل؛ هذا السلوك غير مرئي في بنية DOM ولا يمكن استنتاجه بواسطة محلّل ثابت.

• يتطلب اختبارًا يدويًا — لا توجد قاعدة مخصّصة في axe-core: لا يوفّر axe-core قاعدة تكتشف أفخاخ لوحة المفاتيح تلقائيًا لأن نمط الفشل سلوكي في جوهره. لا يظهر الفخ إلا عندما ينتقل المستخدم فعليًا إلى مكوّن باستخدام مفتاح Tab ويحاول الخروج. لا يمكن لأداة فحص آلية تكرار ذلك لأنها ستحتاج إلى محاكاة التنقل التسلسلي بلوحة المفاتيح عبر كل عنصر قابل للتركيز في الصفحة، وتشغيل جميع مستمعي أحداث JavaScript المرتبطين، ثم تحديد ما إذا كان التركيز قد خرج من المنطقة المقصودة — وهي مشكلة غير عملية حسابيًا في الصفحات المعقدة. بالإضافة إلى ذلك، يتطلب التمييز بين الفخ واحتواء التركيز المقصود (مثل المودال) حكمًا سياقيًا لا يمكن للقواعد الآلية اتخاذه بشكل موثوق. ينبغي للمختبِرين استخدام axe DevTools أو Lighthouse لتحديد العناصر القابلة للتركيز ومشكلات ترتيب Tab كنقطة بداية، ثم يجب عليهم التنقل يدويًا بلوحة المفاتيح عبر كل منطقة تفاعلية للتأكد من عدم وجود أفخاخ.

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

1. إجراء فحص وصولية آلي كنقطة أساس. افتح axe DevTools (امتداد المتصفح) أو نفّذ تدقيق وصولية عبر Lighthouse في Chrome DevTools. رغم أن أياً من الأداتين لن يعلّم مباشرة على فخ لوحة مفاتيح، فإن الفحص سيحدّد العناصر القابلة للتركيز، وأدوار ARIA المفقودة، وترتيب Tab غير الصحيح الذي قد يشير إلى مكوّنات تفاعلية خطرة تستحق التحقيق اليدوي. دوّن أي ودجات مخصصة، أو iframes مضمّنة، أو مكوّنات من طرف ثالث، أو مربعات حوار نمطية، أو قوائم منسدلة، أو منتقيات تواريخ، أو سلايدر (carousels)، أو محررات نصوص منسقة — فهذه هي أكثر مصادر أفخاخ لوحة المفاتيح شيوعًا.
2. افصل الفأرة أو ضعها جانبًا. لكي يكون اختبار لوحة المفاتيح اليدوي صالحًا، يجب ألا تستخدم الفأرة. ضع الفأرة بعيدًا عن متناول يدك أو عطّلها في إعدادات نظام التشغيل لتجنّب الاعتماد عليها عن غير قصد أثناء الاختبار.
3. تنقّل في الصفحة بالكامل باستخدام مفاتيح Tab وShift+Tab فقط. بدءًا من شريط عنوان المتصفح أو أعلى الصفحة، اضغط Tab بشكل متكرر وراقب إلى أين ينتقل التركيز. تتبّع مؤشر التركيز بصريًا في كل خطوة. عندما تصل إلى كل مكوّن تفاعلي — خصوصًا أي ودجت مخصص أو محتوى مضمّن أو عنصر واجهة مستخدم معقّد — تحقّق من أن الضغط على Tab أو Shift+Tab ينقل التركيز بسلاسة خارج المكوّن إلى العنصر القابل للتركيز التالي أو السابق في الصفحة.
4. اختبر كل مكوّن تفاعلي على حدة. بالنسبة لمربعات الحوار النمطية: افتح المودال، وتحقّق من انتقال التركيز إلى داخله، ثم اضغط Escape وتأكد من عودة التركيز إلى العنصر الذي فتحه. بالنسبة للقوائم المنسدلة: افتح القائمة، وتنقّل داخلها، ثم اضغط Escape وتأكد من أن القائمة تُغلَق ويعود التركيز إلى الزر أو العنصر الذي فتحها. بالنسبة لمنتقيات التواريخ ومنتقيات الألوان والودجات المشابهة: انتقل إليها عبر Tab، وتفاعل معها، ثم اخرج عبر Tab وتأكد من أن التركيز يغادرها. بالنسبة لـ iframes المضمّنة (مثل الخرائط أو مشغّلات الفيديو أو ودجات الدردشة): انتقل إلى iframe عبر Tab، وتنقّل داخله، وتأكد من أنك تستطيع الخروج منه عبر Tab والعودة إلى الصفحة الرئيسية.
5. اختبر باستخدام NVDA وFirefox. افتح NVDA، وانتقل إلى الصفحة في Firefox، واستخدم Tab للتنقل عبر العناصر التفاعلية. انتبه إلى ما إذا كان NVDA يقرأ عنصرًا جديدًا في كل مرة تضغط فيها Tab أو يبدو أنه يعود إلى نفس العنصر. إذا لم يُحرّك Tab التركيز إلى ما بعد مكوّن ما، فهذا فخ لوحة مفاتيح.
6. اختبر باستخدام VoiceOver وSafari على macOS. فعّل VoiceOver (Command + F5)، وافتح الصفحة في Safari، واستخدم مفتاح Tab للتنقل. تأكد من أن VoiceOver يعلن عن عنصر جديد في كل ضغطة Tab وأن التركيز لا يعلق أبدًا في منطقة لا يمكنك الخروج منها.
7. اختبر باستخدام JAWS وChrome. افتح JAWS، وانتقل إلى الصفحة في Chrome، واستخدم Tab للتنقل عبر جميع المكوّنات التفاعلية. اختبر بشكل خاص أي مكوّن يستخدم إدارة تركيز مدفوعة بـ JavaScript، إذ يتفاعل JAWS مع شجرة الوصولية بطريقة يمكن أن تكشف عن أفخاخ غير مرئية في الاختبار البصري وحده.
8. تحقّق من آليات الهروب غير القياسية. إذا كان أي مكوّن يتطلب مفتاحًا غير Tab أو Shift+Tab أو Escape للخروج، فتحقّق من أن الصفحة توصل ذلك بوضوح إلى المستخدم — على سبيل المثال، عبر تعليمات على الشاشة، أو تلميح أداة (tooltip)، أو إعلان عبر منطقة ARIA حية عند دخول التركيز إلى المكوّن.

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

مربع حوار نمطي بدون معالجة لمفتاح Escape — غير صحيح

<!-- Modal opens but has no Escape key handler and no close button reachable by keyboard -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- No close button, no Escape key listener -- keyboard users are trapped -->
</div>

مربع حوار نمطي بدون معالجة لمفتاح Escape — صحيح

<!-- Modal with proper focus trap, Escape handler, and accessible close button -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Close button is reachable by Tab and allows keyboard users to exit -->
  <button id='modal-close' onclick='closeModal()' aria-label='Close dialog'>Cancel</button>
</div>

<script>
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') {
      closeModal(); // Escape key closes the modal and returns focus to trigger
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Return focus to opener
  }
</script>

قائمة منسدلة مخصصة تلتقط جميع أحداث مفتاح Tab — غير صحيح

<!-- Custom dropdown intercepts all keydown events including Tab, preventing focus from leaving -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='true'>
  <ul role='listbox'>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  // BUG: This captures ALL keyboard events and calls preventDefault on Tab,
  // meaning the user can never Tab out of this component
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // This traps the keyboard
    if (e.key === 'ArrowDown') { /* move focus down */ }
    if (e.key === 'ArrowUp') { /* move focus up */ }
  });
</script>

قائمة منسدلة مخصصة تلتقط جميع أحداث مفتاح Tab — صحيح

<!-- Correct: Only prevent default for arrow keys used for internal navigation;
     allow Tab and Escape to function normally so users can exit -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='false'>
  <ul role='listbox' hidden>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    if (e.key === 'ArrowDown' || e.key === 'ArrowUp') {
      e.preventDefault(); // Only prevent default for internal navigation keys
      // move focus between options
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // Do NOT call preventDefault -- allow Tab and Escape to propagate
      // so the browser can move focus away from this component naturally
      closeDropdown();
    }
  });
</script>

Iframe مضمّن من طرف ثالث بدون مسار خروج — غير صحيح

<!-- An embedded chat widget iframe that absorbs all Tab keypresses
     and never returns focus to the parent page -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- The iframe's internal JavaScript consumes Tab events, trapping users inside it -->

Iframe مضمّن من طرف ثالث بدون مسار خروج — صحيح

<!-- Use a button to open the chat in a new window rather than embedding
     an iframe that may trap keyboard users -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- If an iframe must be used, add a visible skip link before it
     so keyboard users can bypass it if they choose -->
<a href='#after-chat-widget' class='skip-link'>Skip chat widget</a>
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<span id='after-chat-widget' tabindex='-1'></span>

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

• استدعاء event.preventDefault() داخل مستمع keydown دون تقييده بمفاتيح محددة — تطبيق preventDefault() على جميع أحداث لوحة المفاتيح في مكوّن قابل للتركيز يمنع عمل Tab وShift+Tab، مما يخلق فورًا فخًا للوحة المفاتيح. احرص دائمًا على تقييد preventDefault() بالمفاتيح المحددة التي يحتاج مكوّنك إلى التعامل معها داخليًا (مثل مفاتيح الأسهم في صناديق القوائم).
• بناء مربع حوار نمطي يضع التركيز داخله لكنه لا يوفّر معالجًا لمفتاح Escape أو زر إغلاق — غالبًا ما يطبّق المطوّرون جزء إدخال التركيز من نمط المودال بشكل صحيح لكنهم ينسون أن احتواء التركيز داخل المودال مقبول فقط إذا كان هناك دائمًا مخرج يمكن الوصول إليه بلوحة المفاتيح. يجب أن يتعامل كل مودال مع مفتاح Escape وأن يتضمن زر إغلاق قابلًا للوصول عبر Tab.
• استخدام tabindex='-1' على عنصر حاوية لمنعه من الظهور في ترتيب Tab، مع السماح في الوقت نفسه لـ JavaScript بنقل التركيز إليه برمجيًا — عندما يُنقَل التركيز إلى عنصر يحمل tabindex='-1' عبر element.focus()، لا يوجد هدف Tab طبيعي للخروج منه، مما قد يترك المستخدم عالقًا إذا لم تُنفَّذ معالجة إضافية للوحة المفاتيح.
• تضمين ودجات من طرف ثالث (دردشة، خرائط، فيديو) دون تدقيقها بحثًا عن سلوك فخ لوحة المفاتيح — لا يبني المورّدون دائمًا ودجاتهم المضمّنة لتكون قابلة للوصول بلوحة المفاتيح. يظل مالكو المواقع مسؤولين عن كل المحتوى في صفحاتهم، بما في ذلك المضمّن من أطراف ثالثة. اختبر دائمًا المكوّنات المضمّنة يدويًا، وإذا كانت تحبس مستخدمي لوحة المفاتيح، فقم بتغليفها برابط تخطٍّ (skip link) أو استبدلها ببديل آمن من ناحية لوحة المفاتيح.
• تنفيذ فخ تركيز لمودال أو درج (drawer) دون تحرير الفخ عند إغلاق المكوّن — إذا لم يُنظَّف JavaScript الذي يقيّد التركيز بشكل صحيح عند إغلاق المودال، يمكن أن يستمر في اعتراض أحداث Tab وحبس المستخدم في الطبقة التي أصبحت الآن غير مرئية.
• استخدام CSS visibility: hidden أو display: none لإخفاء زر إغلاق مربع الحوار لأسباب تصميمية بصرية دون توفير مخرج بديل عبر لوحة المفاتيح — إذا كان زر الإغلاق مخفيًا بصريًا لكن لم يُزَل من شجرة الوصولية، يمكن لمستخدمي قارئات الشاشة العثور عليه؛ لكن إذا أُخفي أيضًا من شجرة الوصولية، فقد لا يكون هناك مخرج. تأكد من أن جميع آليات الإغلاق قابلة للتشغيل بلوحة المفاتيح حتى لو تم تصميمها بصريًا لتكون غير بارزة.
• بناء مكوّنات إكمال تلقائي أو كتابة مسبقة مخصصة تفتح قائمة اقتراحات ثم توجّه جميع ضغطات Tab إلى التنقل بين الاقتراحات بدلًا من الخروج — يجب أن يكون المستخدم قادرًا على الضغط على Escape لإغلاق قائمة الاقتراحات ثم الضغط على Tab للانتقال إلى حقل النموذج التالي. الودجات التي تعيد توجيه Tab إلى التنقل الداخلي تنتهك هذا المعيار.
• نسيان اختبار محررات النصوص المنسقة (محررات WYSIWYG مثل TinyMCE أو CKEditor أو Quill) — تدير هذه المكوّنات تفاعل لوحة المفاتيح داخليًا وغالبًا ما تكون مصدرًا لأفخاخ لوحة المفاتيح. تأكد دائمًا من أن الضغط على Escape أو تسلسل مفاتيح موثّق يخرج من المحرر ويعيد التركيز إلى ترتيب Tab العادي في الصفحة.
• افتراض أنه بما أن المكوّن يستخدم عناصر HTML أصلية فلا يمكن أن يكون فخًا للوحة المفاتيح — يمكن لعنصر <select> داخل نموذج يستخدم JavaScript لتجاوز حدث blur أن يحبس التركيز. استخدام HTML دلالي لا يضمن سلوكًا خاليًا من أفخاخ لوحة المفاتيح عندما تُضاف معالجة أحداث JavaScript مخصصة فوقه.
• عدم توفير توثيق على الشاشة عندما يكون مفتاح غير قياسي مطلوبًا للخروج من مكوّن — يسمح WCAG 2.1.2 صراحةً بالمكوّنات التي تتطلب مفاتيح غير قياسية للخروج، بشرط إبلاغ المستخدم. إذا كان الودجت الخاص بك يتطلب الضغط على F6 أو مجموعة مفاتيح مخصصة للمغادرة، يجب أن توصل ذلك بوضوح إلى المستخدم، ويفضّل أن يكون ذلك عبر تعليمات مرئية بجوار المكوّن أو إعلان عبر منطقة ARIA حية عند دخول التركيز.

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

تضع التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، متطلبات ملزمة للوصولية الرقمية لمجموعة واسعة من الكيانات في القطاعين العام والخاص العاملة في تركيا. يفرض التعميم الالتزام بمعايير الوصولية على الويب المعترف بها دوليًا — متوافقًا مع WCAG 2.1 مستوى AA كأساس، والذي يشمل جميع معايير المستوى A بما في ذلك WCAG 2.1.2 عدم وجود فخ لوحة المفاتيح (No Keyboard Trap).

WCAG 2.1.2 هو معيار من المستوى A، والذي يمثّل الحد الأدنى من مستويات الالتزام. بموجب التعميم، يُعتبَر الالتزام بمستوى A إلزاميًا لجميع الكيانات المشمولة. يُطلب من المؤسسات العامة تحقيق هذا الالتزام خلال عام واحد من تاريخ نشر التعميم، بينما يُمنح الكيانات في القطاع الخاص عامان للامتثال.

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

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

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