WCAG 3.2.1: عند التركيز

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

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

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

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

الأنماط الشائعة التي تفشل في تحقيق هذا المعيار تشمل:

• قائمة منسدلة <select> تنتقل تلقائيًا إلى عنوان URL جديد بمجرد أن يتلقى خيار ما التركيز (وليس عندما يؤكد المستخدم اختياره).
• أداة اختيار تاريخ تفتح حوارًا منبثقًا (modal) بمجرد أن يتلقى أي من حقول الإدخال الخاصة بها التركيز، دون أي تفعيل من المستخدم.
• شريط تمرير (carousel) أو عرض شرائح يتقدم تلقائيًا إلى الشريحة التالية عندما تتلقى نقاط التنقل الخاصة به التركيز.
• تلميح أداة (tooltip) أو نافذة منبثقة (popover) يقوم، عند تشغيله بواسطة التركيز، بنقل تركيز لوحة المفاتيح إلى نفسه في الوقت نفسه دون تحذير، مما يترك المستخدم في موقع غير متوقع.
• حقل بحث يرسل النموذج فورًا ويعيد تحميل الصفحة عندما يتلقى التركيز.

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

لا توجد استثناءات رسمية محددة في WCAG 3.2.1. ينطبق المعيار عالميًا على جميع مكوّنات واجهة المستخدم في الصفحة. ومع ذلك، يشير مستند الفهم الخاص بـ WCAG إلى أن تغييرات السياق التي يتم تشغيلها بواسطة تفعيل متعمّد من المستخدم (نقرة، Enter، Space) تقع خارج نطاق هذا المعيار، الذي يهتم فقط بالفعل السلبي المتمثل في تلقي التركيز.

لماذا يهم

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

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

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

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

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

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

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

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

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

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

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

1. فحص آلي مسبق: شغّل axe DevTools (امتداد المتصفح أو CLI) أو Google Lighthouse على الصفحة. رغم أن أياً من الأداتين لا يمكنه الإشارة بشكل قاطع إلى انتهاكات معيار "عند التركيز"، قد يعرض axe DevTools مشكلات ذات صلة بإدارة التركيز (مثل نمط scrollable-region-focusable أو مصائد التركيز) تستحق فحصًا يدويًا أدق. استخدم لوحة "Needs Review" في axe DevTools — فالعناصر المعلَّمة هناك غالبًا ما تتعلق بسلوكيات المكوّنات التفاعلية التي تتطلب حكمًا بشريًا.
2. تحديد جميع العناصر التفاعلية: قبل اختبار لوحة المفاتيح، أنشئ قائمة بجميع المكوّنات التفاعلية: الروابط، الأزرار، حقول النماذج، القوائم المنسدلة، مربعات الاختيار، أزرار الاختيار، أدوات اختيار التاريخ، الشرائح (carousels)، الأكورديونات، الألسنة (tabs)، الحوارات المنبثقة (modals)، وأي ويدجت مخصصة تستخدم tabindex. أولِ اهتمامًا خاصًا لويدجت JavaScript المخصصة التي تستمع لأحداث focus أو focusin.
3. اختبار التنقل بلوحة المفاتيح فقط: باستخدام لوحة المفاتيح فقط (دون فأرة)، اضغط على Tab بالتسلسل عبر كل عنصر قابل للتركيز في الصفحة. بعد كل ضغطة Tab، وقبل الضغط على أي شيء آخر، راقب: هل تغيّر عنوان URL؟ هل فُتحت نافذة أو لسان جديد؟ هل انتقل التركيز بعيدًا عن العنصر الذي وصلت إليه للتو؟ هل تم إرسال نموذج؟ هل تغيّر المحتوى الأساسي للصفحة بشكل درامي؟ أي إجابة "نعم" تُعد مرشحًا لانتهاك.
4. اختبار عناصر select: ضع التركيز على أي قائمة منسدلة <select>. استخدم مفاتيح الأسهم للأعلى والأسفل للتنقل بين الخيارات دون الضغط على Enter أو Space. تحقّق من أن التنقل بين الخيارات لا يطلق أي تنقل أو إرسال نموذج أو تغيير في السياق. هذا أحد الأنماط الأكثر انتهاكًا.
5. NVDA + Firefox: فعّل NVDA (مجاني، لنظام Windows). افتح Firefox وانتقل إلى الصفحة. اضغط على Tab عبر جميع العناصر التفاعلية. استمع إلى إعلانات NVDA — إذا بدأ NVDA في الإعلان عن جزء مختلف تمامًا من الصفحة أو سياق صفحة جديد بعد ضغطة Tab (دون أن تضغط Enter أو Space)، فهذا مؤشر قوي على وجود انتهاك.
6. JAWS + Chrome: فعّل JAWS. افتح Chrome. استخدم Tab للتنقل. سيعلن JAWS عن كل عنصر يحصل على التركيز. راقب الإعلانات غير المتوقعة لحوارات جديدة أو صفحات جديدة أو مواقع تركيز لم تتنقل إليها عمدًا.
7. VoiceOver + Safari (macOS/iOS): فعّل VoiceOver (Cmd+F5 على macOS). تنقّل باستخدام Tab (أو السحب على iOS). راقب التحولات غير المتوقعة في السياق. على iOS، اختبر أيضًا باستخدام "الوصول عبر المفاتيح" (switch access) لمحاكاة المستخدمين ذوي الإعاقات الحركية الشديدة الذين يتنقلون عبر المسح التتابعي.
8. فحص مستمعي الأحداث في أدوات المطوّرين بالمتصفح: في Chrome DevTools، اختر أي عنصر تفاعلي مشكوك فيه، انتقل إلى لوحة Elements، وانقر على "Event Listeners". ابحث عن مستمعي focus أو focusin. إذا وُجدت، راجع كود JavaScript المرتبط لتحديد ما إذا كان المعالج يطلق تنقلًا أو إرسال نموذج أو نقل تركيز أو إجراءات أخرى تغيّر السياق.

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

قائمة select تُرسل تلقائيًا — غير صحيح

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

قائمة select تُرسل تلقائيًا — صحيح

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

فتح حوار منبثق عند تركيز حقل إدخال — غير صحيح

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

فتح حوار منبثق عند تركيز حقل إدخال — صحيح

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

تقدّم الشريط (Carousel) تلقائيًا عند التركيز — غير صحيح

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

تقدّم الشريط (Carousel) تلقائيًا عند التركيز — صحيح

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

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

• استخدام onfocus كبديل لـ onclick على عناصر التنقل: أحيانًا يربط المطوّرون معالجات onfocus بروابط أو أزرار التنقل لـ "تحميل" الوجهة مسبقًا، فيطلقون عن غير قصد تنقلًا كاملًا بدلًا من مجرد جلب مسبق. استخدم دائمًا onclick أو onkeydown (مع التحقق من Enter/Space) لأي إجراء يغيّر السياق.
• ربط onchange بعناصر <select> دون إجراء إرسال: في متصفحات سطح المكتب، يتم تشغيل onchange على <select> عند تأكيد الخيار، لكن في بعض التطبيقات الأقدم وبعض متصفحات الأجهزة المحمولة يمكن أن يتم تشغيله أثناء التنقل بين الخيارات بمفاتيح الأسهم. اربط دائمًا التنقل المعتمد على select بزر إرسال صريح أو استخدم <form> مع <button type='submit'>.
• نقل التركيز برمجيًا داخل معالج حدث focus: استدعاء element.focus() داخل معالج onfocus أو focusin لعنصر آخر يخلق قفزة غير متوقعة في التركيز. هذا انتهاك مباشر — المستخدم انتقل بالتركيز إلى العنصر A وتم نقل التركيز بصمت إلى العنصر B. انقل التركيز دائمًا فقط استجابةً لإجراءات متعمّدة من المستخدم.
• فتح الحوارات المنبثقة عند أحداث التركيز لأي عنصر مشغِّل: من الاختصارات الشائعة ربط معالج فتح حوار منبثق بحدث focus لزر أو حقل إدخال مشغِّل. يجب أن تُفتح الحوارات المنبثقة فقط استجابةً لنقرة أو مفتاح Enter أو Space — وليس عند التركيز وحده.
• تشغيل الوسائط أو الرسوم المتحركة تلقائيًا التي تغيّر سياق منفذ العرض عند التركيز: بانر رئيسي يبدأ فيديو بملء الشاشة أو رسمًا متحركًا كبيرًا بمجرد أن يتلقى زر التشغيل الخاص به التركيز يغيّر السياق البصري بشكل كبير. اربط إجراءات التشغيل بأحداث التفعيل، لا بأحداث التركيز.
• تشغيل تحديثات مناطق حية (live regions) تقوم بتمرير الصفحة إلى محتوى جديد عند التركيز: بعض الويدجت الديناميكية تحدّث منطقة حية ثم تمرّر منفذ العرض إلى تلك المنطقة بمجرد أن يتلقى حقل إدخال التركيز. هذا يغيّر سياق منفذ العرض ويُربك مستخدمي تكبير الشاشة. افصل قدر الإمكان بين تحديثات المناطق الحية وأحداث التركيز.
• تنفيذ مصائد تركيز مخصصة تحاصر المستخدمين فورًا دون توضيح: مكوّن مخصص يعترض جميع ضغطات Tab بمجرد أن يتلقى التركيز، دون الإعلان للمستخدم بأنه داخل مصيدة تركيز، ينتهك نص وروح هذا المعيار. لا تكون مصائد التركيز مناسبة إلا داخل الحوارات المنبثقة المفتوحة بالكامل، ويجب إبلاغ المستخدمين بكيفية الخروج.
• استخدام CSS :focus لتشغيل display: block على قوائم منسدلة تحتوي على عناصر قابلة للتركيز، مما يسبب حركات تركيز متسلسلة غير متوقعة: القوائم المعتمدة على CSS فقط والمبنية على التركيز والتي تكشف عناصر قابلة للتركيز يمكن أن تسبب قفزات مربكة عندما ينتقل ترتيب التركيز في المتصفح إلى العناصر التي أصبحت مرئية حديثًا. تأكد من أن القوائم المكشوفة متوقعة ومُبلَّغ عنها بوضوح عبر سمات ARIA مثل aria-expanded.
• الاعتماد على مكتبات ويدجت من طرف ثالث دون تدقيق سلوك التركيز فيها: العديد من مكتبات مكوّنات واجهة المستخدم (أدوات اختيار التاريخ، محررات النصوص الغنية، القوائم المنسدلة على نمط select2) انتهكت تاريخيًا المعيار 3.2.1 عبر فتح نوافذ منبثقة أو نقل التركيز عند أحداث focus. قم دائمًا بتدقيق المكوّنات الخارجية يدويًا قبل النشر، بغض النظر عن ادعاءات المكتبة المتعلقة بإمكانية الوصول.
• نسيان الاختبار في سياقات توجيه تطبيقات الصفحات الواحدة (SPA): في تطبيقات React وVue وAngular، يمكن أن تؤدي أحداث التركيز على روابط التنقل أحيانًا إلى تشغيل تغييرات في المسار عبر منطق الموجّه (router) الخاص بالتحميل المسبق أو نتيجة انتشار الأحداث (event bubbling)، خاصة عندما لا يتم إيقاف أحداث التركيز من الانتشار بشكل صحيح. اختبر مكوّنات التنقل في تطبيقات SPA صراحةً للتحقق من الامتثال للمعيار 3.2.1.

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

تُقرّر التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، متطلبات إلزامية لإمكانية الوصول على الويب تشير صراحةً إلى WCAG 2.2 كمعيار تقني. معيار WCAG 3.2.1 الخاص بالتركيز هو معيار من المستوى A، ما يعني أنه يقع ضمن خط الأساس للامتثال الإلزامي بموجب التعميم. لا توجد إعفاءات لمعايير المستوى A — يجب على جميع الجهات المشمولة الالتزام بها ضمن الجداول الزمنية المحددة.

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

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

بموجب التعميم، يؤدي عدم الامتثال إلى تعريض الكيانات المشمولة لعقوبات إدارية ومخاطر على السمعة. بالنسبة للجهات التي تمر حاليًا بعمليات تحول رقمي أو تقوم بشراء أنظمة ويب جديدة، فإن تضمين الامتثال لمعيار WCAG 3.2.1 في متطلبات الشراء وإرشادات المطوّرين الآن — بدلًا من إجراء تعديلات بعد تقديم شكوى — أكثر فعالية من حيث التكلفة وأكثر انسجامًا مع روح التنظيم. تستفيد المنظمات التي تستخدم حزمة Accsible overlay SDK من أدوات إدارة التركيز المدمجة التي تساعد في تحديد ومعالجة السلوكيات غير المتوقعة عند التركيز كجزء من سير عمل أوسع للامتثال لمستوى A من WCAG 2.2.