إمكانية الوصول للمؤشر والحركة

لماذا يهم

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

وبالنسبة إلى المنتج، فهذه المعايير كلها مطلوبة للمطابقة للمستوى AA في WCAG 2.2، وهو المستوى الذي تستهدفه معظم المؤسسات والعقود، والمعيار 2.5.7 Dragging Movements جديد في الإصدار 2.2، لذلك فالتصاميم التي اعتُمدت وفق WCAG 2.1 ربما لم تُفحص على ضوئه أصلاً. وبالنسبة إلى المختبِر، يسهل أن تفوته هذه العيوب: فالإيماءة تعمل معك على الحاسوب المكتبي بالفأرة أو على هاتفك. لذلك عليك أن تختبر عمداً من أجل من لا يستطيع أداءها.

إيماءات المؤشر وإلغاء المؤشر (2.5.1 و2.5.2)

يغطي المعيار 2.5.1 Pointer Gestures (المستوى A) الإيماءات متعددة النقاط (Multipoint)، التي تحتاج إلى إصبعين أو أكثر في الوقت نفسه (القرص للتكبير، والتمرير بإصبعين)، والإيماءات القائمة على المسار (Path-based)، التي يهمّ فيها مسار الحركة لا بدايتها ونهايتها فقط (التمرير السريع في اتجاه معين، ورسم شكل). ويجب أن تعمل كل وظيفة من هذا النوع أيضاً بمؤشر واحد ومن دون مسار: لمسة أو نقرة أو لمسة مزدوجة أو ضغطة مطوّلة. فالخريطة التي تُكبَّر بالقرص تنجح إذا كان فيها أيضاً زرّا + و−، وشريط الشرائح الدوّار (Carousel) الذي لا يتنقل إلا بالتمرير السريع يُخفق. والاستثناء هو الإيماءة الجوهرية، مثل رسم توقيعك، حيث يكون المسار نفسه هو المُدخل؛ أما إذا كان الرسم لمجرد الإقرار بشيء فيكفي زر، فلا يكون جوهرياً. ولا يشمل المعيار إلا الإيماءات التي تفسّرها الصفحة نفسها: فتكبير المتصفح بالقرص وإيماءات قارئ الشاشة خارج نطاقه.

أما المعيار 2.5.2 Pointer Cancellation (المستوى A) فيحمي من التشغيل العَرَضي. فلكل وظيفة تُشغَّل بمؤشر واحد يجب أن يتحقق واحد على الأقل مما يلي: ألّا يُنفّذ حدث الضغط (Down-event)، أي لحظة نزول الزر أو الإصبع، أيَّ جزء من الوظيفة؛ أو أن تكتمل الوظيفة عند حدث الرفع (Up-event) مع وسيلة لإلغائها قبل اكتمالها أو التراجع عنها بعده؛ أو أن يعكس حدث الرفع كل ما أحدثه حدث الضغط؛ أو أن يكون الإكمال عند الضغط جوهرياً. والأزرار والروابط الأصلية تتصرف تصرفاً سليماً أصلاً: فالحدث click لا يقع إلا بعد الرفع، ولذلك فإن الضغط ثم الانزلاق خارج العنصر ثم الرفع لا يفعل شيئاً. ويظهر العيب حين يربط المطور الإجراء بالحدث pointerdown أو mousedown أو touchstart. ويُعدّ الضغط على مفتاح في لوحة مفاتيح أو لوحة أرقام على الشاشة حالة جوهرية.

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

// Defect (2.5.2): the item is deleted the moment the pointer goes down
deleteButton.addEventListener('pointerdown', deleteItem);

// Expected: click fires after release, and not if the pointer slid off the button
deleteButton.addEventListener('click', deleteItem);

حركات السحب وحجم الهدف (2.5.7 و2.5.8)

المعيار 2.5.7 Dragging Movements (المستوى AA) جديد في WCAG 2.2. وحركة السحب هي الضغط على عنصر ثم تحريك المؤشر ثم الرفع عند نقطة أخرى، حيث لا تهمّ إلا نقطتا البداية والنهاية: إعادة ترتيب قائمة، ونقل بطاقة بين الأعمدة، وتحريك مقبض المنزلق (Slider)، وتحريك الخريطة. وكل وظيفة من هذا النوع تحتاج إلى طريقة تعمل بإجراءات مؤشر مفردة ومن دون سحب، ما لم يكن السحب جوهرياً أو كان السلوك من المتصفح نفسه ولم يعدّله المؤلف.

وانتبه إلى ما لا يُحتسب: دعم لوحة المفاتيح. فالمنزلق الذي يستجيب لمفاتيح الأسهم يستوفي 2.1.1 Keyboard، لكن من يستخدم مؤشراً يُحرَّك بالرأس، أو فأرة مع رعاش، ما زال مستخدماً للمؤشر وقد يبقى عاجزاً عن السحب. ويجب أن تكون البدائل عناصر تحكم حقيقية تستوفي 2.5.8 Target Size (Minimum) (المستوى AA): ‏24 × 24 بكسل CSS على الأقل، أو تباعداً كافياً، مع الاستثناءات التي شرحها دليل اختبار إمكانية الوصول البصرية. فسهم «نقل لأعلى» بعرض 16 بكسل ملتصق بسهم «نقل لأسفل» يستبدل إخفاقاً بإخفاق آخر. أما 2.5.5 Target Size (Enhanced) في المستوى AAA فيطلب 44 × 44.

• القائمة القابلة لإعادة الترتيب: زرّا «نقل لأعلى» و«نقل لأسفل» في كل صف، أو قائمة «نقل إلى».
• لوحة كانبان (Kanban): حدّد البطاقة، ثم اختر العمود الهدف من قائمة أو المس العمود.
• المنزلق: لمسة أو نقرة على المسار تنقل المقبض إلى تلك القيمة، أو زرّا − و+، أو حقل رقمي بجانبه.
• الخريطة: أزرار أسهم للتحريك، وزرّا + و− للتكبير والتصغير.

التشغيل بالحركة واتجاه العرض (2.5.4 و1.3.4)

ينطبق المعيار 2.5.4 Motion Actuation (المستوى A) حين يشغّل تحريكُ الجهاز وظيفةً (الهزّ للتراجع، والإمالة للتمرير)، أو حين تشغّلها حركة المستخدم أمام الكاميرا (التلويح للانتقال إلى الصفحة التالية). والمطلوب أمران: أن تتاح الوظيفة نفسها عبر عنصر تحكم عادي على الشاشة، وأن يمكن إيقاف الاستجابة للحركة حتى لا يشغّلها رعاش أو اهتزاز حافلة. والاستثناءان هما الحركة المستخدمة عبر واجهة مدعومة من إمكانية الوصول (Accessibility supported interface)، وهي تشمل الحركات العادية لتشغيل لوحة المفاتيح أو الفأرة أو الشاشة اللمسية أو تقنية مساعدة؛ والحركة الجوهرية للنشاط نفسه مثل عدّاد الخطوات. وهذه حركة بوصفها مُدخلاً؛ أما الرسوم المتحركة على الشاشة وتفضيل تقليل الحركة فقد تناولهما اختبار إمكانية الوصول البصرية.

وينص المعيار 1.3.4 Orientation (المستوى AA) على ألا يقيّد المحتوى عرضه وتشغيله باتجاه واحد، رأسي أو أفقي، ما لم يكن اتجاه معين جوهرياً؛ ومن الأمثلة التي تذكرها WCAG شيك مصرفي، وتطبيق بيانو، وشرائح عرض لجهاز إسقاط أو تلفاز، ومحتوى الواقع الافتراضي (Virtual reality). فمن ثُبّت جهازه اللوحي على كرسي متحرك لا يستطيع تدويره ليناسب صفحتك. والتخطيط الذي يتغير بين الاتجاهين سليم ومتوقع؛ أما الإخفاق فهو صفحة ترفض العمل، أو لا تعرض إلا رسالة «يُرجى تدوير جهازك»، أو تُدير محتواها جانبياً. وعند الاختبار أوقف قفل التدوير في الجهاز أولاً، وإلا فلا معنى للنجاح.

Where an orientation lock usually hides (search the code and config):

CSS       @media (orientation: landscape) { main { display: none; } }
JS        screen.orientation.lock('portrait')
Manifest  "orientation": "portrait"             (installed web app)
Android   android:screenOrientation="portrait"   (AndroidManifest.xml)
iOS       UISupportedInterfaceOrientations       (Info.plist, portrait only)

الاختبار بالفأرة وبجهاز لمس وبمحاكاة الأجهزة

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

• الفأرة: أكمل كل وظيفة سحب أو تمرير سريع أو قرص بنقرات مفردة فقط؛ واضغط ثم ابتعد ثم ارفع على كل عنصر ينفّذ إجراءً؛ وقِس الأهداف الصغيرة في أدوات المطوّر.
• جهاز اللمس: أدِّ كل إيماءة، ثم ابحث عن بديلها باللمس واستخدمه؛ والمس زراً ثم اسحب إصبعك خارجه وارفعه؛ وهزّ الجهاز وأمِله حيث تستجيب الميزة للحركة، ثم أوقف الاستجابة للحركة من الإعدادات؛ وأوقف قفل التدوير ودوّر الجهاز في كل شاشة، بما فيها نوافذ الحوار المفتوحة.
• محاكاة الأجهزة: في Chrome DevTools يضبط شريط أدوات الجهاز (Ctrl+Shift+M، أو Cmd+Shift+M على Mac) منفذ عرض (Viewport) بحجم هاتف، ويحاكي اللمس بالفأرة، وفيه زر للتدوير؛ وتضبط لوحة Sensors قيم اتجاه الجهاز. ويوفّر وضع التصميم المتجاوب (Responsive Design Mode) في Firefox أيضاً منفذ عرض بحجم هاتف ومحاكاةً للّمس وزراً للتدوير. وراقب البدائل التي يخفيها تخطيط الهاتف، مثل أسهم شريط الشرائح التي تختفي تحت نقطة توقف (Breakpoint) معينة، أي العرض الذي يتبدّل عنده التخطيط.
• حدود المحاكاة: تغيّر المحاكاة ما تراه الصفحة، مثل منفذ العرض وأحداث اللمس، وكذلك سلسلة User-Agent عند اختيار جهاز من القائمة الجاهزة (Device preset)، وهي النص الذي يذكر فيه المتصفح اسمه وإصداره ونظام التشغيل؛ لكنها لا تغيّر العتاد. فهي لا تستطيع هزّ الهاتف، ولا تُظهر كيف يغطي إصبع حقيقي هدفاً صغيراً، وقد يختلف سلوك التدوير في نظام التشغيل الحقيقي. والصق قيمة navigator.userAgent من وحدة التحكم في محلّل User-Agent، وسترى أن الجلسة تدّعي أنها هاتف وهي تعمل على عتاد مكتبي. وأكّد كل نجاح على جهاز حقيقي واحد على الأقل.
• سجّل مع كل نتيجة: الجهاز ونظام التشغيل، والمتصفح، والمُدخل المستخدَم (فأرة أو إصبع أو قلم)، والاتجاه وحالة قفل التدوير. وتسجيل شاشة قصير يجعل عيوب الإيماءات قابلة لإعادة الإنتاج.

جرّبها: محلّل User-Agent جرّبها: مولّد حالات الاختبار

مثال تطبيقي: اختبار لوحة مهام

يطلق فريق لوحة مهام تعمل على الهاتف. تنتقل البطاقات بين الأعمدة بالسحب، والتمرير السريع لليسار على بطاقة يؤرشفها، وهزّ الهاتف يتراجع عن آخر تغيير، وأيقونة الحذف على البطاقة تستجيب عند اللمس.

ينفّذ المختبِر جلسة القسم السابق، ويسجّل ما نجح أيضاً: فالتكبير في اللوحة يعمل بزرّي + و− إلى جانب القرص (2.5.1)، وأزرار رؤوس الأعمدة بحجم 32 × 32 بكسل CSS ‏(2.5.8). ثم يكتب هذه العيوب، لكلٍّ منها المعيار والسلوك المتوقع:

• «لا يمكن نقل البطاقة بين الأعمدة إلا بالسحب، ولا طريقة بمؤشر واحد»: إخفاق في 2.5.7 (AA). المتوقع: قائمة «نقل إلى» في كل بطاقة، أو تحديد البطاقة ثم لمس العمود.
• «الأرشفة متاحة فقط بالتمرير السريع لليسار»: إخفاق في 2.5.1 (A)، لأن التمرير السريع إيماءة قائمة على المسار. المتوقع: عنصر «أرشفة» في قائمة البطاقة.
• «الهزّ للتراجع بلا زر تراجع على الشاشة ولا يمكن إيقافه»: إخفاق في شرطَي 2.5.4 (A) كليهما. المتوقع: زر «تراجع» بعد كل تغيير، وإعداد يعطّل الهزّ.
• «البطاقة تُحذف عند touchstart، والانزلاق بالإصبع خارجها لا يلغي الحذف»: إخفاق في 2.5.2 (A). المتوقع: الحذف عند الرفع، ويُفضَّل مع إمكانية التراجع.
• «اللوحة تعرض رسالة تطلب التدوير إلى الوضع الرأسي في الوضع الأفقي على الأجهزة اللوحية»: إخفاق في 1.3.4 (AA)، فلوحة المهام ليس لها اتجاه جوهري.

جرّبها: مولّد عناوين الأخطاء بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)الشرح التوضيحي لكل إرشاد ومعيار نجاح في WCAG 2.2: الغرض، ومن يستفيد، والأمثلة والتقنيات (غير إلزامي).
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)قائمة قابلة للتصفية بكل معايير نجاح WCAG 2.2 مع التقنيات الكافية وحالات الإخفاق الشائعة.
• What are browser developer tools? — MDNMDN Web Docs (Mozilla)مقدمة لأدوات المطوّرين المدمجة في المتصفحات — المفتّش ووحدة تحكم JavaScript ومصحّح الأخطاء — لفحص الصفحة أثناء اختبارها.