WCAG 3.3.5: المساعدة

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

\n

ينص معيار النجاح 3.3.5 من WCAG بعنوان المساعدة (المستوى AAA) على ما يلي: \"تتوفر مساعدة حساسة للسياق.\" وهذا يعني أنه في أي مكان يطلب فيه موقع ويب أو تطبيق من المستخدمين إدخال معلومات، يجب توفير مساعدة مناسبة لتوضيح ما هو متوقع. يجب أن تكون المساعدة سياقية — أي أن ترتبط مباشرة بالحقل أو المهمة أو العملية التي ينشغل بها المستخدم حاليًا، بدلاً من أن تكون صفحة مساعدة عامة مدفونة في مكان ما ضمن عناصر التنقل.

\n

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

\n

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

\n

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

\n

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

\n\n

لماذا يهم

\n

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

\n

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

\n

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

\n

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

\n

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

\n\n

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

\n

يتطلب WCAG 3.3.5 اختبارًا يدويًا لأن الامتثال له يعتمد على جودة محتوى المساعدة وملاءمته وسياقيته — وهي عوامل لا يمكن للأدوات الآلية تقييمها. يمكن لأداة فحص آلية أن تؤكد وجود تسمية أو أن سمة aria-describedby تشير إلى عنصر حقيقي، لكنها لا تستطيع تحديد ما إذا كان محتوى تلك التسمية أو الوصف مفيدًا بالفعل أو دقيقًا أو كافيًا لحقل إدخال معيّن.

\n

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

\n\n

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

\n

\n
1. تشغيل فحص إمكانية وصول آلي كنقطة أساس. استخدم axe DevTools (امتداد المتصفح أو CLI)، أو Lighthouse في أدوات مطوري Chrome، أو IBM Equal Access Checker على الصفحة التي تحتوي على النموذج. لن تشير هذه الأدوات مباشرة إلى انتهاكات 3.3.5، لكنها ستُظهر مشكلات ذات صلة مثل التسميات المفقودة (عنصر label غير مرتبط بحقل إدخال)، أو أهداف aria-describedby المفقودة، أو تطبيقات التلميحات غير القابلة للوصول. يضمن حل هذه المشكلات الأساسية أولاً أنه عندما تتم إضافة المساعدة الحساسة للسياق، تكون قابلة للوصول تقنيًا أيضًا.
\n
2. مراجعة كل حقل في النموذج يدويًا للتحقق من توفر المساعدة. بالنسبة لكل حقل إدخال، اسأل: (أ) هل تشرح التسمية وحدها بالكامل نوع الإدخال المطلوب، بما في ذلك أي متطلبات للصيغة؟ (ب) هل يوجد نص مساعدة إضافي مرئي بجوار الحقل؟ (ج) هل توجد أيقونة مساعدة أو تلميح أو قسم قابل للتوسيع يقدّم مزيدًا من الإرشاد؟ (د) هل يوجد رابط إلى محتوى مساعدة ذي صلة؟ إذا كان الجواب على كل هذه الأسئلة هو لا، وكان الحقل ينطوي على أي غموض، فهذا يُعد فشلًا في 3.3.5.
\n
3. اختبار إمكانية الوصول بلوحة المفاتيح لجميع آليات المساعدة. تنقّل عبر النموذج باستخدام لوحة المفاتيح فقط (من دون فأرة). تحقق من أن كل تلميح، وأيقونة مساعدة، ووصف قابل للتوسيع، ورابط مساعدة يمكن الوصول إليه وتفعيله عبر لوحة المفاتيح. يجب أن تظهر التلميحات عند التركيز كما تظهر عند التحويم. يجب تشغيل أزرار المساعدة باستخدام Enter أو Space. أي آلية مساعدة لا يمكن الوصول إليها إلا بالفأرة تفشل في هذا الاختبار.
\n
4. الاختبار باستخدام NVDA + Firefox. تنقّل إلى كل حقل نموذج باستخدام Tab. استمع إلى ما يعلنه NVDA لكل حقل — هل يعلن التسمية؟ هل يعلن أي وصف مرتبط (عبر aria-describedby)؟ فعّل أيقونات المساعدة أو التلميحات وتأكد من الإعلان عن محتواها. حاول الوصول إلى محتوى المساعدة المرتبط وتحقق من أنه يتعلق بالحقل الحالي.
\n
5. الاختبار باستخدام VoiceOver + Safari (على macOS أو iOS). استخدم VoiceOver للتنقل في النموذج. على macOS، استخدم Tab للانتقال بين الحقول واستمع إلى الإعلان الكامل لكل حقل. على iOS، استخدم التنقل بالسحب. تحقق من أن كل محتوى المساعدة المرتبط بحقول الإدخال يُقرأ بصوت عالٍ، وأن مشغلات المساعدة (الأزرار، الروابط) يمكن الوصول إليها ومُسمّاة بشكل صحيح بواسطة VoiceOver.
\n
6. الاختبار باستخدام JAWS + Chrome. استخدم وضع النماذج في JAWS (يُفعّل بالضغط على Enter عند التواجد على عنصر نموذج). تنقّل بين الحقول باستخدام Tab وتحقق من أن JAWS يقرأ التعليمات والأوصاف المرتبطة. استخدم المؤشر الافتراضي في JAWS للتحقق من أن محتوى المساعدة الموضوع خارج الارتباطات القياسية للتسميات يمكن الوصول إليه أيضًا.
\n
7. إجراء جولة إدراكية (Cognitive Walkthrough). اطلب من شخص غير مألوف بالنموذج (أو حاكِ ذلك بمراجعة النموذج بعد استراحة) محاولة إكماله من دون أي إرشاد خارجي. دوّن كل نقطة يتردد فيها، أو يطرح سؤالاً، أو يرتكب خطأ بسبب توقعات غير واضحة. كل نقطة من هذه النقاط مرشحة لتحسين المساعدة الحساسة للسياق وفقًا لـ 3.3.5.
\n

\n\n

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

\n

حقل نصي غامض بدون شرح — غير صحيح

\n

<!-- No help provided for an ambiguous field expecting a specific format -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

حقل نصي غامض مع مساعدة مضمّنة — صحيح

\n

<!-- Inline description associated via aria-describedby gives format guidance before the user types -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

تلميح أيقونة مساعدة غير قابل للوصول لمستخدمي لوحة المفاتيح — غير صحيح

\n

<!-- Tooltip only shown on mouseover; keyboard users and screen reader users cannot access it -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

تلميح أيقونة مساعدة قابل للوصول لجميع المستخدمين — صحيح

\n

<!-- Button with aria-expanded controls a help panel; accessible via keyboard and screen readers -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript toggles aria-expanded and the hidden attribute on button click/keypress -->

\n\n

نموذج معقد متعدد الخطوات بدون إرشاد على مستوى الخطوة — غير صحيح

\n

<!-- Step 2 of a 4-step application with no explanation of what documents are needed -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

نموذج معقد متعدد الخطوات مع مساعدة سياقية على مستوى الخطوة — صحيح

\n\n

(Content truncated due to token limit — please retry this article.)