WCAG 2.4.11: عدم حجب التركيز (الحد الأدنى)

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

المعيار WCAG 2.4.11 Focus Not Obscured (Minimum) هو معيار من المستوى AA تم تقديمه في WCAG 2.2 لمعالجة مشكلة شائعة ولكنها خطيرة في مجال الإتاحة: عندما يكون العنصر الذي عليه التركيز مخفياً بالكامل خلف طبقة أخرى من المحتوى في الصفحة. ينص المعيار على أنه عندما يحصل أي مكوّن من مكوّنات واجهة المستخدم على تركيز لوحة المفاتيح، يجب ألا يكون هذا المكوّن مخفياً بالكامل بواسطة محتوى أنشأه المؤلف.

الكلمة المفتاحية هنا هي بالكامل. يحدد WCAG 2.4.11 الحد الأدنى — فهو يطلب فقط أن يبقى جزء من العنصر الذي عليه التركيز مرئياً. إذا كان شريط تنقل ثابت يغطي النصف العلوي من زر عليه تركيز، لكن النصف السفلي لا يزال مرئياً، فإن ذلك يفي من الناحية التقنية بالمعيار 2.4.11. المعيار المرافق الأكثر صرامة، WCAG 2.4.12 Focus Not Obscured (Enhanced) من المستوى AAA، يذهب أبعد من ذلك من خلال اشتراط ألا يكون المكوّن الذي عليه التركيز محجوباً بمحتوى أنشأه المؤلف على الإطلاق — ولا حتى جزئياً.

أنواع المحتوى الذي ينشئه المؤلف والمسؤولة غالباً عن هذه المشكلة تشمل الرؤوس والتذييلات الثابتة أو ذات الموضع اللاصق، لافتات موافقة ملفات تعريف الارتباط، عناصر دعم الدردشة، إشعارات التوست، طبقات النوافذ المنبثقة (modals)، أزرار الإجراءات العائمة، وأشرطة التنقل السفلية في التصاميم المتجاوبة مع الأجهزة المحمولة. يتم عرض هذه العناصر باستخدام خصائص CSS مثل position: fixed وposition: sticky أو قيم z-index عالية، مما يجعلها تطفو فوق التدفق العادي للمستند وقد تغطي العناصر التفاعلية التي تحصل على التركيز.

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

ينطبق هذا المعيار على جميع عناصر HTML التفاعلية القابلة للحصول على تركيز لوحة المفاتيح بشكل افتراضي أو التي جُعلت قابلة للتركيز عبر tabindex، بما في ذلك <a> و<button> و<input> و<select> و<textarea> والعناصر ذات tabindex='0' أو قيم tabindex موجبة.

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

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

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

يتجاوز الأثر المستخدمين ذوي الإعاقة. المستخدمون المتقدمون الذين يفضلون التنقل بلوحة المفاتيح من أجل السرعة — مثل المطورين، ومتخصصي إدخال البيانات، والمستخدمين المتمرسين — يستفيدون أيضاً من وضوح مؤشر التركيز. وفقاً لمنظمة الصحة العالمية، يعيش حوالي 1.3 مليار شخص حول العالم مع شكل من أشكال الإعاقة، ويعتمد جزء كبير منهم على تقنيات مساعدة أو على التنقل بلوحة المفاتيح. في تركيا تحديداً، يشير تقرير معهد الإحصاء التركي (TÜİK) إلى أن حوالي 12.7% من السكان لديهم شكل من أشكال الإعاقة، ما يعادل تقريباً 10 ملايين شخص قد يستفيدون مباشرة من تحسين إدارة التركيز في المنصات الرقمية.

من منظور الأعمال، تزيد مؤشرات التركيز المحجوبة من معدلات التخلي عن المهام، وتقلل من التحويلات، وتعرّض المؤسسات لمخاطر قانونية وتنظيمية. المواقع التي تفشل في تلبية هذا المعيار من المرجح أيضاً أن تفشل في اجتياز تدقيقات الإتاحة المطلوبة بموجب القانون التركي، مما يعرّض قدرتها على الحصول على شعار الإتاحة الرسمي (Erişilebilirlik Logosu) أو الحفاظ عليه للخطر.

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

يُصنَّف المعيار WCAG 2.4.11 على أنه يتطلب اختباراً يدوياً في axe-core. لا توجد قاعدة آلية في axe-core تكتشف هذا الانتهاك مباشرة. يساعد فهم سبب عدم قدرة الأدوات الآلية على الإبلاغ عن هذه المشكلة بشكل موثوق الفرق على بناء عمليات اختبار يدوي أفضل.

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

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

1. قم أولاً بتشغيل فحص إتاحة آلي. استخدم axe DevTools (امتداد المتصفح)، أو Lighthouse في أدوات مطوري Chrome، أو فحص axe-core مدمج في CI لتحديد أي مشكلات يمكن اكتشافها تلقائياً في الصفحة. على الرغم من أن المعيار 2.4.11 نفسه يتطلب تحققاً يدوياً، فقد يكشف الفحص الآلي عن مشكلات ذات صلة مثل غياب مؤشرات التركيز (2.4.7) أو تكديس z-index غير الصحيح الذي يشير إلى عناصر متداخلة. دوّن جميع العناصر التي تم الإبلاغ عنها على أنها قد تكون إشكالية قبل بدء الاختبار اليدوي.
2. حدّد جميع العناصر الثابتة واللاصقة في الصفحة. افتح أدوات مطوري المتصفح وافحص CSS للصفحة. ابحث عن العناصر التي تستخدم position: fixed أو position: sticky. تحقق أيضاً من العناصر ذات قيم z-index العالية (مثل 100 أو أكثر). وثّق كل من هذه العناصر — الرؤوس، التذييلات، اللافتات، عناصر الدردشة، إشعارات ملفات تعريف الارتباط — لأنها المرشحة الأكثر احتمالاً لحجب المكوّنات التي عليها التركيز. غيّر حجم نافذة المتصفح لمحاكاة أحجام مختلفة لنافذة العرض، بما في ذلك عرض الأجهزة اللوحية والهواتف المحمولة، لأن العناصر اللاصقة/الثابتة غالباً ما تتصرف بشكل مختلف عبر نقاط التوقف (breakpoints).
3. قم بإجراء اجتياز كامل باستخدام مفتاح Tab. انقر خارج أي عنصر تفاعلي للتأكد من أن التركيز يبدأ من أعلى الصفحة، ثم اضغط على Tab بشكل متكرر للتنقل عبر كل عنصر قابل للتركيز. راقب كل عنصر بعناية عند حصوله على التركيز. انتبه بشكل خاص للعناصر التي تظهر بالقرب من أعلى أو أسفل نافذة العرض، حيث من المرجح أن تتداخل الرؤوس أو التذييلات الثابتة. إذا اختفى في أي لحظة إطار التركيز المرئي أو العنصر المميز بالكامل خلف طبقة ثابتة، فهذا فشل في المعيار 2.4.11. استخدم Shift+Tab للتنقل عكسياً أيضاً، لأن موضع التمرير والتخطيط قد يختلفان.
4. اختبر باستخدام NVDA وFirefox. افتح NVDA (قارئ شاشة مجاني ومفتوح المصدر لنظام Windows) وشغّل Firefox. فعّل وضع التصفح في NVDA واستخدم Tab للتنقل عبر الصفحة. بينما سيعلن NVDA عن كل عنصر عليه تركيز صوتياً، راقب الشاشة بصرياً أيضاً. لاحظ أي عنصر يعلن NVDA أن عليه التركيز لكن لا يظهر له مؤشر تركيز مرئي بسبب المحتوى الذي يحجبه. يُستخدم هذا المزيج على نطاق واسع في تركيا وعالمياً ويمثل اقتراناً رئيسياً لتقنيات المساعدة.
5. اختبر باستخدام VoiceOver وSafari على macOS/iOS. فعّل VoiceOver (Command+F5 على Mac) واستخدم Tab أو إيماءات التنقل الخاصة بـ VoiceOver للتحرك بين العناصر القابلة للتركيز. على iOS، استخدم إيماءات السحب. تحقق من أن العناصر التي عليها التركيز موجودة بصرياً وليست مخفية تحت طبقات واجهة مستخدم ثابتة، خصوصاً على الأجهزة المحمولة حيث قد تستهلك أشرطة التنقل ولافتات ملفات تعريف الارتباط جزءاً أكبر من نافذة العرض.
6. اختبر باستخدام JAWS وChrome. افتح JAWS (Job Access With Speech) واستخدم Chrome. تنقل عبر جميع العناصر التفاعلية باستخدام Tab وراقب أي لحظة ينتقل فيها مؤشر JAWS إلى عنصر مخفي بصرياً تحت طبقة ثابتة. يُستخدم JAWS على نطاق واسع في بيئات المؤسسات والجهات الحكومية، مما يجعل هذا المزيج مهماً بشكل خاص لاختبار مواقع القطاع العام والمواقع المؤسسية.
7. اختبر بعد تفاعلات المستخدم التي تغيّر التخطيط. أغلق لافتات ملفات تعريف الارتباط، وافتح وأغلق قوائم التنقل، وفعّل إشعارات التوست، وافتح عناصر الدردشة. بعد كل تغيير في الحالة، قم باجتياز جديد باستخدام Tab للتأكد من أن التخطيط الجديد لا يقدّم حالات جديدة لحجب التركيز. المحتوى الديناميكي مصدر شائع لفشل المعيار 2.4.11 الذي لا يظهر إلا بعد تفاعل المستخدم.
8. اختبر عند مواضع تمرير متعددة. مرّر إلى منتصف أو أسفل صفحة طويلة، ثم تنقل باستخدام Tab عبر العناصر في تلك المنطقة. قد لا تحجب الرؤوس الثابتة العناصر القريبة من أعلى الصفحة لكنها يمكن أن تغطي العناصر التي تظهر عند الحافة العلوية لنافذة العرض عندما يمرّر المستخدم للأسفل. تأكد من أن أي مزيج من موضع التمرير والعنصر الذي عليه التركيز لا يؤدي إلى إخفاء بصري كامل.

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

رأس لاصق يتداخل مع الروابط التي عليها تركيز — غير صحيح

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

رأس لاصق يتداخل مع الروابط التي عليها تركيز — صحيح

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

لافتة ملفات تعريف الارتباط تغطي حقل نموذج في الأسفل عليه تركيز — غير صحيح

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

لافتة ملفات تعريف الارتباط تغطي حقل نموذج في الأسفل عليه تركيز — صحيح

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

عنصر دردشة تابع لطرف ثالث يتداخل مع زر عليه تركيز — غير صحيح

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

عنصر دردشة تابع لطرف ثالث يتداخل مع زر عليه تركيز — صحيح

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

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

• تطبيق position: fixed على الرؤوس والتذييلات دون إضافة scroll-margin-top أو scroll-margin-bottom للعناصر القابلة للتركيز. لا يأخذ تمرير التركيز الأصلي في المتصفح في الحسبان العناصر الثابتة المتداخلة، لذا تنتقل العناصر التي عليها التركيز إلى أعلى أو أسفل نافذة العرض وتنتهي مخفية خلف الطبقة الثابتة. تحل قاعدة CSS عامة مثل * { scroll-margin-top: [header-height]px; } هذا الأمر بكفاءة.
• تعيين body { padding-top: 60px; } لتعويض رأس ثابت مع نسيان إضافة scroll-margin-top مكافئ لتركيز لوحة المفاتيح. يضمن الحشو ألا يكون المحتوى مخفياً في البداية، لكن عندما يؤدي تركيز لوحة المفاتيح إلى تمرير تلقائي من المتصفح، قد ينزلق هدف التمرير خلف الرأس. يجب استخدام كلا النهجين معاً.
• استخدام z-index: 9999 على اللافتات الترويجية أو عناصر الدردشة دون مراجعة العناصر القابلة للتركيز التي تقع ضمن نطاقها. يضمن z-index المرتفع أن تُعرض الطبقة فوق كل شيء، بما في ذلك الأزرار والروابط التي عليها التركيز، مما يجعلها السبب الجذري الأكثر شيوعاً لفشل المعيار 2.4.11.
• إغلاق لافتات ملفات تعريف الارتباط عبر JavaScript دون إزالتها من التخطيط فوراً. إذا بقي عنصر DOM الخاص باللافتة مع visibility: hidden أو opacity: 0 لكنه لا يزال يشغل مساحة أو لديه قيمة z-index غير صفرية، فيمكنه الاستمرار في حجب العناصر التي عليها التركيز بصرياً في بعض سيناريوهات عرض المتصفح.
• تضمين عناصر طرف ثالث (دردشة مباشرة، طبقات إتاحة، مديري GDPR) دون التحقق من تأثيرها على وضوح تركيز لوحة المفاتيح. غالباً ما تحقن سكربتات الطرف الثالث عناصر ذات موضع ثابت وقيم z-index عالية جداً. يجب على الفرق اختبار هذه التكاملات صراحة كجزء من عملية ضمان جودة الإتاحة.
• الفشل في اختبار المعيار 2.4.11 بعد تغييرات نقاط التوقف في التصميم المتجاوب. قد يكون شريط التنقل اللاصق بارتفاع 60px على سطح المكتب لكنه يتمدد إلى 120px على الأجهزة اللوحية عند فتح قائمة الهامبرغر، مما يحجب فجأة مساحة أكبر بكثير ويخلق حالات فشل جديدة عند نقاط التوقف التي اجتازت الاختبار على سطح المكتب.
• تطبيق scroll-margin-top فقط على أهداف الروابط (مثل <h2> و<section>) وليس على العناصر التفاعلية مثل <input> و<button> و<a>. غالباً ما تتم معالجة إزاحة التمرير للروابط، لكن التمرير التلقائي لتركيز لوحة المفاتيح إلى عناصر ليست أهداف روابط يتأثر بنفس القدر ويجب تغطيته بنفس قاعدة CSS.
• افتراض أنه بما أن العنصر الذي عليه التركيز يُعلن عنه بواسطة قارئ الشاشة، فهو مرئي أيضاً بصرياً. تصل قارئات الشاشة إلى شجرة الإتاحة، وليس العرض البصري. يمكن أن يكون العنصر مخفياً بالكامل خلف طبقة ثابتة بينما لا يزال يُعلن عنه بشكل صحيح بواسطة NVDA أو JAWS. هاتان مشكلتان منفصلتان — المعيار 2.4.11 يتعلق تحديداً برؤية التركيز بصرياً لمستخدمي لوحة المفاتيح المبصرين.
• إهمال اختبار حجب التركيز بعد تغييرات المسارات في تطبيقات الصفحة الواحدة (SPA). في تطبيقات React أو Vue أو Angular، غالباً ما تعيد انتقالات المسارات عرض الرؤوس الثابتة بحالة محدثة، ويمكن أن يؤدي إدارة التركيز أثناء التنقل إلى وضع التركيز على عناصر تُحجب فوراً بواسطة رأس لاصق يُعاد تركيبه قبل أن يرى المستخدم الصفحة الجديدة.
• الاعتماد فقط على أدوات الاختبار الآلي والاستنتاج بعدم وجود مشكلات 2.4.11 لأن أي قاعدة آلية لم تُبلغ عن الصفحة. بما أن axe-core لا يحتوي على قاعدة آلية لهذا المعيار، فإن تقريراً آلياً نظيفاً لا يعني أن الصفحة تجتاز الاختبار. اجتياز لوحة المفاتيح اليدوي عبر جميع أحجام نوافذ العرض وحالات الصفحة الديناميكية إلزامي.

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

يرتبط المعيار WCAG 2.4.11 Focus Not Obscured (Minimum) مباشرة بالإطار القانوني الناشئ للإتاحة في تركيا. ينص التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، على متطلبات إلزامية للإتاحة الرقمية تتماشى مع WCAG 2.2. يمثل هذا التعميم توسعاً كبيراً في التزام تركيا بالإدماج الرقمي ويفرض التزامات قابلة للتنفيذ على مجموعة واسعة من الكيانات العاملة في السوق الرقمية التركية.

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

لأن المعيار WCAG 2.4.11 هو معيار من المستوى AA في WCAG 2.2، فإن الامتثال لهذه القاعدة ليس اختيارياً للكيانات المشمولة. يجب على المنظمات التي تسعى للحصول على شعار الإتاحة الرسمي (Erişilebilirlik Logosu) الصادر عن وزارة الأسرة والخدمات الاجتماعية (Aile ve Sosyal Hizmetler Bakanlığı) أو الحفاظ عليه أن تحقق توافقاً مع المستوى AA. يعمل شعار الإتاحة كإشارة عامة على الالتزام بالإدماج الرقمي ويُتوقع بشكل متزايد من قبل المستهلكين الأتراك وجهات الشراء الحكومية.

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

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