WCAG 2.4.3: ترتيب التركيز

ماذا تعني هذه القاعدة

المعيار WCAG 2.4.3 ترتيب التركيز هو معيار نجاح من المستوى A ضمن مبدأ "قابلية التشغيل" (Operable). وينص على ما يلي: "إذا كان من الممكن التنقل في صفحة ويب بشكل تسلسلي، وكان تسلسل التنقل يؤثر في المعنى أو التشغيل، فيجب أن تتلقى المكونات القابلة للتركيز التركيز بترتيب يحافظ على المعنى وقابلية التشغيل."

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

ينطبق هذا المعيار على التنقل التسلسلي باستخدام لوحة المفاتيح، وهو الطريقة الأساسية التي يستخدمها مستخدمو لوحة المفاتيح فقط ومستخدمو قارئات الشاشة للتنقل في الصفحة. ترتيب عناصر DOM هو المصدر الافتراضي لترتيب التركيز في المتصفحات: تظهر العناصر في تسلسل التبويب بالترتيب الذي تظهر به في نموذج كائن المستند (DOM)، ما لم يقم CSS أو JavaScript بتغيير هذا الترتيب عمدًا. تنشأ المشكلات عندما يختلف التخطيط البصري عن ترتيب DOM (على سبيل المثال، من خلال إعادة الترتيب باستخدام CSS Flexbox أو Grid)، أو عندما تفرض قيم tabindex تسلسلاً غير طبيعي.

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

ما الذي يُعد فشلًا: قفز التركيز من حقل "اسم المستخدم" في نموذج تسجيل الدخول إلى بانر ترويجي غير ذي صلة تمامًا قبل الوصول إلى حقل "كلمة المرور" يُعد فشلًا. تطبيق صفحة واحدة (Single-page application) يفتح حوارًا لكنه يترك التركيز على الصفحة الخلفية يُعد فشلًا. استخدام قيم tabindex صحيحة موجبة (مثل tabindex='2'، tabindex='5') تفرض تسلسل تبويب غير منطقي عبر الصفحة يُعد فشلًا.

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

آليات HTML وJavaScript الأساسية التي تؤثر في ترتيب التركيز تشمل: الترتيب الطبيعي لعناصر DOM التفاعلية، وخصيصة tabindex (خصوصًا القيم الصحيحة الموجبة)، وخصائص CSS التي تعيد ترتيب التخطيط البصري دون تغيير DOM (مثل order في Flexbox/Grid، وposition: absolute، وfloat)، وإدارة التركيز المدفوعة بـ JavaScript (استدعاء .focus() على العناصر)، وأنماط حوارات ARIA التي تتطلب إدارة تركيز صريحة.

لماذا يهم هذا الأمر

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

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

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

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

سيناريو واقعي ملموس: تخيل صفحة إتمام شراء في موقع تجارة إلكترونية تركي. يستخدم التصميم البصري CSS Grid لوضع ملخص الطلب على اليسار ونموذج الدفع على اليمين. لكن في DOM، يأتي نموذج الدفع أولًا ويأتي ملخص الطلب ثانيًا. يبدو التخطيط البصري صحيحًا لمستخدمي الفأرة المبصرين، لكن مستخدم لوحة المفاتيح الذي يضغط على Tab سيصل إلى حقول نموذج الدفع قبل أن تتاح له فرصة مراجعة ملخص الطلب. قد يؤكد طلبًا خاطئًا دون أن يدري. والأسوأ من ذلك، إذا حصل زر "تأكيد الشراء" على التركيز قبل حقل "تطبيق القسيمة" بسبب سوء إدارة قيم tabindex الموجبة، فقد يقوم المستخدم عن غير قصد بإتمام عملية شراء كان ينوي خصمها. هذا أثر مالي مباشر وحقيقي ناتج عن ترتيب تركيز معطوب.

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

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

يتطلب WCAG 2.4.3 إجراء اختبار يدوي للحصول على تقييم حاسم. لا يمكن للأدوات الآلية مثل axe-core أن تحدد خوارزميًا ما إذا كان تسلسل تركيز معين "يحافظ على المعنى وقابلية التشغيل" — فهذا الحكم يتطلب إنسانًا يفهم هدف الصفحة وعلاقات المحتوى. ومع ذلك، يمكن لـ axe-core والأدوات ذات الصلة الإشارة إلى أنماط معينة تعد مؤشرات قوية على مشكلات في ترتيب التركيز:

• tabindex (القيم الموجبة) — إشارة استدلالية: تحذر بعض أدوات الفحص والتدقيق عندما تحمل العناصر قيم tabindex صحيحة موجبة (أي قيمة أكبر من 0). تتجاوز قيم tabindex الموجبة الترتيب الطبيعي لـ DOM وتضع هذه العناصر في مقدمة تسلسل التبويب، وهو ما يؤدي في الغالب إلى إنشاء ترتيب تركيز غير منطقي وغير متوقع. وبينما لا تتضمن مجموعة قواعد axe-core الأساسية قاعدة آلية مخصصة لـ "focus-order" (لأن الصحة المنطقية للتسلسل لا يمكن حسابها)، فإن أدوات مثل axe DevTools Pro وعمليات التدقيق اليدوية تتحقق تحديدًا من استخدام tabindex الموجب كمؤشر بديل.
• scrollable-region-focusable: يتضمن axe-core قاعدة تشير إلى المناطق القابلة للتمرير التي لا يمكن الوصول إليها بلوحة المفاتيح (غير قابلة للتركيز). وعلى الرغم من أنها ليست قاعدة خاصة بترتيب التركيز مباشرة، فإن منطقة قابلة للتمرير لا يمكنها تلقي التركيز تكسر التسلسل الملاحي العام، مما يجعل مستخدمي لوحة المفاتيح يتجاوزون محتوى يحتاجون إلى التفاعل معه.
• الفحص اليدوي للمحتوى المعاد ترتيبه بواسطة CSS: لا يمكن للأدوات الآلية اكتشاف الحالات التي يؤدي فيها استخدام order في CSS Flexbox أو وضع Grid إلى إنشاء عدم تطابق بين الترتيب البصري وترتيب DOM. يجب على المختبر البشري مقارنة التخطيط الظاهر على الشاشة مع تسلسل التركيز الذي يُلاحظ أثناء التنقل باستخدام لوحة المفاتيح. هذا هو المصدر الأكثر شيوعًا لفشل 2.4.3 في التصاميم المتجاوبة الحديثة، وهو غير مرئي تمامًا لأدوات الفحص الآلي.
• الفحص اليدوي لإدارة التركيز في المحتوى الديناميكي باستخدام JavaScript: تتطلب تطبيقات الصفحة الواحدة، وتنفيذات التمرير اللانهائي، والنوافذ المنبثقة (modals)، والقوائم المنسدلة الجانبية (fly-out menus) جميعها استخدام JavaScript لنقل التركيز بشكل مناسب مع تغيّر المحتوى. تعمل الأدوات الآلية على لقطة ثابتة من DOM ولا يمكنها محاكاة تسلسل تفاعلات المستخدم اللازمة لتفعيل سيناريوهات إدارة التركيز هذه. لا يمكن إلا للاختبار اليدوي باستخدام لوحة المفاتيح التحقق من أن التركيز ينتقل إلى النافذة المنبثقة الجديدة عند فتحها، ويعود إلى المشغّل الصحيح عند إغلاقها، ولا يترك المستخدم عالقًا في طبقة خلفية غير قابلة للوصول.

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

1. فحص آلي كنقطة بداية: شغّل axe DevTools (امتداد المتصفح) أو Google Lighthouse على الصفحة. ابحث عن أي تحذيرات بشأن قيم tabindex الموجبة والمناطق القابلة للتمرير التي تم الإشارة إليها. لاحظ أن نتيجة آلية خالية من الأخطاء لا تعني أن 2.4.3 مستوفى — الاختبار اليدوي مطلوب دائمًا. سجّل أي مشكلات تم الإشارة إليها لمزيد من التحقيق.
2. افصل الفأرة وتنقل باستخدام Tab فقط: بدءًا من شريط عناوين المتصفح أو أعلى الصفحة، اضغط على Tab بشكل متكرر للانتقال عبر كل عنصر قابل للتركيز. راقب التسلسل بعناية. اسأل نفسك: هل يتحرك التركيز بترتيب يطابق تدفق القراءة والتفاعل المنطقي للصفحة؟ هل يقفز التركيز في أي وقت إلى منطقة غير متوقعة؟ هل يصبح محصورًا (غير قادر على التحرك للأمام أو للخلف) إلا داخل حوار مقصود؟
3. اختبر المكونات الديناميكية: فعّل أي نوافذ منبثقة (modals)، أو حوارات، أو قوائم منسدلة، أو أكورديونات، أو ألسنة (tab panels)، أو منتقيات التاريخ، أو ودجات تفاعلية أخرى باستخدام لوحة المفاتيح. تحقق من أن التركيز ينتقل إلى المحتوى الذي تم كشفه حديثًا فور تفعيله. بعد إغلاق حوار، تأكد من أن التركيز يعود إلى العنصر الذي فعّل الحوار — لا إلى أعلى الصفحة أو إلى موقع عشوائي.
4. اختبر باستخدام NVDA + Firefox: افتح NVDA، وشغّل Firefox، وانتقل إلى الصفحة. استخدم Tab للانتقال عبر العناصر التفاعلية واستمع إلى الإعلانات. تحقق من أن التسلسل المُعلن منطقي سياقيًا. استخدم وضع التصفح (Browse Mode) في NVDA (مفاتيح الأسهم) لقراءة المحتوى الثابت وتأكد من أن ترتيب القراءة يتماشى مع ترتيب التركيز للعناصر التفاعلية داخل هذا المحتوى.
5. اختبر باستخدام VoiceOver + Safari (macOS/iOS): فعّل VoiceOver واستخدم Tab (على سطح المكتب) أو إيماءات السحب (على iOS) للانتقال عبر العناصر القابلة للتركيز. تأكد من أن تسلسل التركيز منطقي. على iOS، اختبر أن النوافذ المنبثقة والطبقات المتراكبة تحصر التركيز بشكل صحيح وتعيده عند الإغلاق.
6. اختبر باستخدام JAWS + Chrome: استخدم تنقل Tab في JAWS وتأكد من أن تسلسل التركيز المُعلن متماسك. استخدم المؤشر الافتراضي (virtual cursor) في JAWS لمقارنة ترتيب القراءة مع ترتيب التركيز للعناصر التفاعلية وتحديد أي تناقضات.
7. افحص DOM مقابل التخطيط البصري: افتح أدوات المطور في المتصفح وافحص بنية DOM. قارن ترتيب العناصر التفاعلية في DOM مع موضعها البصري على الشاشة. إذا كانت خصائص CSS مثل order أو position: absolute أو float تُحدث اختلافات كبيرة، فتابع تسلسل التبويب يدويًا لتحديد ما إذا كان المعنى أو قابلية التشغيل متأثرين.
8. تحقق من قيم tabindex في DOM: في وحدة تحكم المتصفح، شغّل document.querySelectorAll('[tabindex]') لسرد جميع العناصر التي تحتوي على خصائص tabindex صريحة. افحص أي عنصر له قيمة صحيحة موجبة وقيّم ما إذا كان موضعه في تسلسل التبويب المعدّل منطقيًا.

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

قيم tabindex الموجبة التي تنشئ ترتيبًا غير منطقي — غير صحيح

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

قيم tabindex الموجبة التي تنشئ ترتيبًا غير منطقي — صحيح

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

إعادة الترتيب البصري باستخدام CSS بما لا يطابق ترتيب DOM — غير صحيح

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

إعادة الترتيب البصري باستخدام CSS بما لا يطابق ترتيب DOM — صحيح

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

نافذة حوارية (Modal) لا تدير التركيز — غير صحيح

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

نافذة حوارية (Modal) لا تدير التركيز — صحيح

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

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

• استخدام قيم tabindex صحيحة موجبة (مثل tabindex='1'، tabindex='5') لـ "التحكم" في ترتيب التركيز بدلًا من تصحيح بنية DOM. تضع قيم tabindex الموجبة العناصر قبل جميع العناصر القابلة للتركيز طبيعيًا في الصفحة، مما يخلق تسلسل تبويب عالميًا فوضويًا يصعب للغاية الحفاظ عليه ويؤدي تقريبًا دائمًا إلى أخطاء.
• تطبيق خاصية order في Flexbox أو CSS Grid لإعادة ترتيب المحتوى بصريًا دون إعادة ترتيب DOM ثم الفشل في اختبار التنقل باستخدام لوحة المفاتيح. يبدو التخطيط البصري صحيحًا للمستخدمين المبصرين، لكن تسلسل التبويب يتبع ترتيب DOM وليس الترتيب البصري — وهو تناقض غير مرئي لكنه خطير لمستخدمي لوحة المفاتيح.
• فتح نافذة منبثقة أو حوار دون نقل التركيز إليها برمجيًا باستخدام طريقة .focus() في JavaScript. يبقى مستخدمو قارئات الشاشة ولوحة المفاتيح عالقين في المحتوى الخلفي، وغالبًا غير قادرين على العثور على الحوار أو التفاعل معه على الإطلاق.
• الفشل في إعادة التركيز إلى العنصر الذي فعّل النافذة المنبثقة أو الدرج (drawer) أو القائمة المنسدلة بعد إغلاقها. إعادة التركيز إلى أعلى الصفحة أو تركه على عنصر أصبح الآن مخفيًا يجبر المستخدمين على إعادة التنقل من البداية، مما يفقدهم موضعهم في صفحة قد تكون طويلة.
• إدراج محتوى يتم تحميله ديناميكيًا (مثل رسالة خطأ مضمنة، أو إشعار toast، أو قسم يتم تحميله كسولًا) في DOM بعد عناصر قابلة للتركيز تسبقه بصريًا بحيث يواجه مستخدمو لوحة المفاتيح المحتوى الجديد خارج التسلسل أو لا يواجهونه على الإطلاق.
• استخدام tabindex='-1' لإزالة العناصر من تسلسل التبويب دون توفير وسيلة بديلة للوصول إليها بلوحة المفاتيح. بينما يعد tabindex='-1' أداة صالحة بحد ذاته (يجعل العنصر قابلًا للتركيز برمجيًا لكنه يزيله من ترتيب التبويب الطبيعي)، فإن إساءة استخدامه على عناصر تحكم يحتاج المستخدمون بالفعل للوصول إليها يخفي هذه العناصر فعليًا عن مستخدمي لوحة المفاتيح.
• بناء انتقالات المسارات في تطبيقات الصفحة الواحدة بحيث تعيد تعيين التركيز إلى جسم المستند (document body) أو واجهة المتصفح بدلًا من نقل التركيز إلى عنوان الصفحة الجديد أو معلم تخطي التنقل (skip-navigation). يُجبر المستخدمون حينها على الضغط على Tab عبر كامل التنقل في كل تغيير مسار.
• تنفيذ ودجات مخصصة لعروض الشرائح (carousel) أو المنزلقات (slider) حيث لا يتم تنفيذ التنقل بمفاتيح الأسهم ويقوم Tab بنقل التركيز عبر كل شريحة مخفية، مما يجبر المستخدمين على الضغط على Tab عبر عشرات العناصر خارج الشاشة قبل الوصول إلى محتوى الصفحة التالي.
• وضع رابط تخطي التنقل "غير مرئي" في DOM يكون دائمًا display:none (بدلًا من إخفائه بصريًا باستخدام تقنية .sr-only / clip). يتم إزالة الرابط الذي يحمل display:none من تسلسل التبويب تمامًا، فلا يقدم أي فائدة، بينما يتلقى رابط التخطي المنفذ بشكل صحيح التركيز عند الضغط على Tab ويصبح مرئيًا، مما يدعم مباشرة تدفق التركيز المنطقي إلى المحتوى الرئيسي.
• تعشيش عناصر تفاعلية داخل عناصر تفاعلية أخرى (على سبيل المثال، عنصر <button> داخل وسم <a>)، مما ينتج عنه سلوك تبويب غير متسق بين المتصفحات ويمكن أن يتسبب في أن يهبط التركيز على نفس عنصر التحكم المنطقي عدة مرات أو يتجاوزه تمامًا.

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

يرتبط معيار WCAG 2.4.3 ترتيب التركيز مباشرة بالتشريع التركي البارز في مجال إمكانية الوصول: التعميم الرئاسي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025. يضع هذا التعميم معايير إلزامية لإمكانية الوصول على الويب لمجموعة واسعة من الكيانات في القطاعين العام والخاص العاملة في تركيا، ويشترط الالتزام بإرشادات معترف بها دوليًا — بما في ذلك جميع معايير النجاح من المستوى A في WCAG 2.x، والتي يعد 2.4.3 واحدًا منها.

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

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

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

يدعم حزمة Accsible للتراكب (overlay SDK) المنظمات في رحلتها نحو الامتثال من خلال توفير تحسينات قابلة للتهيئة لإدارة التركيز، لكن من المهم ملاحظة أن حلول التراكب تعمل بشكل أفضل جنبًا إلى جنب — وليس بدلًا من — بنية HTML دلالية صحيحة وإدارة مسؤولة للتركيز في قاعدة كود التطبيق نفسها. يتطلب تحقيق توافق مستدام وقابل للتدقيق مع التعميم الرئاسي 2025/10 أن يفي المنتج الأساسي بالمعيار 2.4.3 من خلال ممارسات تطوير صحيحة.