WCAG 2.5.1: إيماءات المؤشر

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

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

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

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

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

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

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

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

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

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

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

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

تتطلب WCAG 2.5.1 اختبارًا يدويًا لأن الأدوات الآلية لا يمكنها اكتشاف ما إذا كان السلوك المعتمد على الإيماءات لديه بديل يعتمد على مؤشر واحد بشكل موثوق. لا توجد قاعدة axe-core آلية تطابق هذا المعيار مباشرة. أسباب عدم كفاية الاكتشاف الآلي هي:

• يتطلب اختبارًا يدويًا — اكتشاف الإيماءات: تحلل أدوات الفحص الآلي بنية DOM الثابتة والأنماط المحسوبة. لا يمكنها ملاحظة سلوك مستمعي أحداث JavaScript أثناء التشغيل بطريقة تميز ما إذا كان معالج touchstart/touchmove/touchend يطبق سحبًا معتمدًا على المسار أو مجرد نقرة. يرى الفاحص أن أحداث اللمس موجودة لكنه لا يستطيع تحديد ما إذا كانت الوظيفة الناتجة متاحة أيضًا عبر بديل يعتمد على مؤشر واحد. يتطلب هذا من مختبِر بشري التفاعل مع الواجهة باستخدام كل من الطرق المعتمدة على الإيماءات وطرق المؤشر الواحد ومقارنة الوظائف المتاحة.
• يتطلب اختبارًا يدويًا — التحقق من التكافؤ: حتى لو تمكنت أداة من الإشارة إلى وجود مستمع لإيماءة متعددة النقاط، فإنها لا تستطيع تقييم ما إذا كان الزر أو الرابط المقدم يحقق نتائج مكافئة وظيفيًا. يتطلب التحقق من التكافؤ — أي أن البديل يطلق نفس النتيجة، وأنه مرئي وقابل للوصول، وأنه ليس مخفيًا خلف خطوة إضافية — حكمًا بشريًا مستنيرًا بنية المعيار.
• يتطلب اختبارًا يدويًا — استثناء الإيماءة الأساسية: يتطلب تحديد ما إذا كانت الإيماءة تستوفي شروط استثناء "الأساسية" فهمًا سياقيًا لغرض التطبيق لا يمكن لأي قاعدة آلية تقييمه بشكل موثوق.

يجب على المختبِرين استخدام أدوات المطور في المتصفح لفحص مستمعي الأحداث المرفقة (في Chrome DevTools، انقر بزر الفأرة الأيمن على عنصر، اختر "Inspect"، ثم اعرض علامة تبويب "Event Listeners") كنقطة بداية لتحديد العناصر التي لديها معالجات لأحداث اللمس أو المؤشر، ثم التحقق يدويًا من وجود وتكافؤ البدائل المعتمدة على مؤشر واحد.

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

1. تشغيل فحص آلي كخط أساس: استخدم axe DevTools أو Lighthouse أو التدقيق المدمج في أداة Accsible لفحص الصفحة. رغم عدم وجود قاعدة تطابق 2.5.1 مباشرة، يمكن لنتائج الفحص الإشارة إلى مشكلات ذات صلة (مثل عناصر التحكم القابلة للتركيز المفقودة) التي توفر سياقًا للمراجعة اليدوية. دوّن أي عناصر تفاعلية تم الإشارة إليها لافتقارها إلى دعم لوحة المفاتيح أو المؤشر.
2. تحديد الوظائف المعتمدة على الإيماءات: استكشف الصفحة يدويًا على جهاز لمس (أو باستخدام محاكاة الجهاز في Chrome DevTools — فعّل شريط أدوات الجهاز وتفاعل باستخدام لمس محاكى). ابحث عن أشرطة عرض، وأشرطة تمرير، وخرائط، وأكورديونات، ومعارض صور، ولوحات قابلة للتمرير، وواجهات سحب وإفلات، وأدوات رسم، وأي مكوّن آخر يستجيب لإيماءات اللمس. وثّق كل وظيفة تكتشفها يتم تشغيلها عبر سحب، أو قرص، أو تدوير، أو أي إيماءة أخرى معتمدة على المسار أو متعددة النقاط.
3. محاولة إيجاد مكافئات تعتمد على مؤشر واحد: لكل وظيفة تعتمد على الإيماءات تم تحديدها، حاول إنجاز نفس الوظيفة باستخدام اللمسات الواحدة فقط (أو نقرات الفأرة على سطح المكتب). تحقق مما إذا كانت هناك عناصر تحكم مرئية مثل الأزرار أو الأسهم أو الروابط التي تطلق نفس النتيجة. حاول تشغيل هذه العناصر باستخدام الفأرة، ولوحة المفاتيح (Tab للتركيز، Enter/Space للتفعيل)، وقارئ الشاشة.
4. التحقق باستخدام قارئ الشاشة (NVDA + Firefox): افتح NVDA وFirefox. تنقل عبر المكونات التفاعلية باستخدام مفاتيح Tab والأسهم. تحقق من أن عناصر التحكم المعتمدة على مؤشر واحد (أزرار، روابط) للوظائف المعتمدة على الإيماءات يتم الإعلان عنها بواسطة قارئ الشاشة، ويمكن الوصول إليها عبر لوحة المفاتيح، وتنتج النتيجة المتوقعة عند تفعيلها.
5. التحقق باستخدام قارئ الشاشة (VoiceOver + Safari على iOS): فعّل VoiceOver على iPhone أو iPad. اسحب إلى اليمين بإصبع واحد للتنقل بين العناصر. تحقق من أن جميع عناصر التحكم التي توفر بدائل تعتمد على مؤشر واحد للإيماءات يمكن الوصول إليها وتفعيلها عبر إيماءة النقر في VoiceOver، وأنها تنتج النتيجة الصحيحة.
6. التحقق باستخدام قارئ الشاشة (JAWS + Chrome): استخدم JAWS مع Chrome على Windows. تنقل باستخدام Tab عبر المكونات التفاعلية وتحقق من أن عناصر التحكم البديلة للإيماءات قابلة للتركيز، وموسومة بشكل صحيح، وتعمل.
7. تقييم استثناء "الأساسية": لأي وظيفة تعتمد على الإيماءات وتفتقر إلى بديل يعتمد على مؤشر واحد، حدد ما إذا كانت الإيماءة أساسية حقًا للمحتوى أو الوظيفة. إذا لم تتمكن من تبرير الاستثناء، فسجّلها كفشل. وثّق نتائجك بلقطات شاشة وخطوات لإعادة الإنتاج.

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

شريط صور مع تنقل بالسحب فقط — غير صحيح

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

شريط صور مع تنقل بالسحب فقط — صحيح

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

خريطة مع تكبير بالقرص فقط — غير صحيح

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

خريطة مع تكبير بالقرص فقط — صحيح

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

شريط نطاق بقيمة يتم تغييرها بالسحب على المسار فقط — غير صحيح

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

شريط نطاق بقيمة يتم تغييرها بالسحب على المسار فقط — صحيح

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

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

• توفير أشرطة عرض تعتمد على السحب فقط بدون أي أزرار تحكم للسابق/التالي: العديد من مكتبات أشرطة العرض تأتي بدعم للإيماءات فقط؛ يجب على المطورين تكوين أزرار التنقل وعرضها صراحة لتوفير بديل يعتمد على مؤشر واحد.
• إخفاء أزرار التنقل على أجهزة اللمس عبر استعلامات وسائط CSS: نمط شائع يخفي أزرار الأسهم على الشاشات التي يُفترض أنها أجهزة لمس (مثل @media (pointer: coarse))، مما يزيل البديل المعتمد على مؤشر واحد للمستخدمين ذوي الإعاقات الحركية الذين يعتمدون عليه حتى على شاشات اللمس.
• الاعتماد فقط على إيماءة القرص بإصبعين لتكبير الخريطة دون تقديم أزرار للتكبير: عمليات تضمين الخرائط من أطراف ثالثة (تنفيذات مخصصة) غالبًا ما تُهمل عناصر التحكم في التكبير، تاركة القرص كآلية التكبير الوحيدة.
• استخدام أنماط السحب للحذف أو السحب للكشف بدون زر إجراء بديل: عناصر القوائم في تطبيقات الويب التي تكشف خيارات الحذف أو الإجراءات فقط عبر سحب أفقي لا تملك آلية مكافئة تعتمد على النقر للمستخدمين الذين لا يمكنهم السحب بشكل موثوق.
• واجهات السحب والإفلات المخصصة التي لا تحتوي على بديل لإعادة الترتيب يعتمد على لوحة المفاتيح أو النقر: تفاعلات السحب بطبيعتها معتمدة على المسار؛ عدم توفير آلية بديلة (مثل أزرار للأعلى/للأسفل أو نموذج قص ولصق) ينتهك هذا المعيار.
• أدوات الرسم أو التوقيع التي تفترض أن المسار المرسوم نفسه ليس المخرَج: أحيانًا يسيء المطورون استخدام استثناء "الأساسية" لأدوات هي في الواقع مجرد عناصر تحكم في واجهة المستخدم (مثل نمط فتح بالقفل عبر الإيماءات لكشف المحتوى) بدلاً من أدوات إدخال حر حقيقية.
• وضع عناصر التحكم البديلة المعتمدة على مؤشر واحد خارج إطار العرض المرئي أو في حالة مطوية افتراضيًا: إذا كانت الأزرار المكافئة موجودة في DOM ولكنها مخفية بصريًا أو تتطلب تفاعلًا إضافيًا للكشف عنها، فإنها لا تفي بالكامل بمتطلب وجود بديل يعتمد على مؤشر واحد يمكن إدراكه وتشغيله.
• تنفيذ مكتبات إيماءات تعترض أحداث المؤشر وتمنع السلوك الافتراضي: المكتبات التي تستدعي event.preventDefault() على أحداث اللمس يمكن أن تحجب عن غير قصد تفاعلات المؤشر الواحد والتمرير الخاصة بالمتصفح نفسه، مما يخلق حالات فشل غير مقصودة تتجاوز معيار الإيماءات نفسه.
• افتراض أن إضافة aria-label إلى منطقة تعتمد على الإيماءات فقط كافٍ: وضع تسمية لمنطقة السحب لا يوفر بديلًا يعتمد على مؤشر واحد — بل يصفها فقط لمستخدمي قارئ الشاشة الذين لا يزالون غير قادرين على تشغيلها بدون دعم الإيماءات.
• عدم الاختبار على أجهزة حقيقية أو باستخدام محاكاة اللمس: قد لا يكتشف المطورون الذين يختبرون فقط على سطح المكتب باستخدام الفأرة أن ميزة ما تعمل حصريًا عبر الإيماءات على الهاتف المحمول، لأن آلية النقر بالفأرة الاحتياطية تعمل بالصدفة على سطح المكتب بينما مسار الكود الخاص باللمس فقط يفتقر إلى مكافئ للنقر.

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

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

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

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

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

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