بناء تلميح مساعدة سهل الوصول للجميع

…إنّه أصعب مما ظننت

اليوم هو أحد تلك الأيام التي بدأت مع بحث غوغل عن سؤال/مسألة أخرى تتعلق بسهولة الوصول (accessibility). أنا أعمل على مشروع جديد لعميلتي Provta وجزء من هذا المشروع هو بناء تلميح مساعدة بسيط وجميل يشرح للقارئ/المستخدم عن ماهيّة حاسبة فرامنغهام.

يتم تشغيل التلميح بواسطة أيقونة مساعدة صغيرة مثل تلك التي تظهر في الزاوية اليمنى العليا من لقطة الشاشة هذه:

كما هو الحال مع كل مشروع، فإنّ البدء بالتفكير ما هو عنصر HTML الذي سأستخدمه لترميز المكوّن هو أوّل شيء فعلته. لكن اتّضح أنّه لا يوجد عنصر HTML لترميز تلميح كهذا. وعندما لا يكون لدينا عناصر دلالية لترميز مكوناتنا، فإنّنا نواجه التحدي في التأكّد من أنّ التقنيات المساعدة (ATs)- التي عادةً ما تكون قادرة على فهم ونقل المعنى عن طريق الدلالات - قادرة على فهم ما هي عناصرنا بالفعل وماذا تفعل.

هل تنقذنا خاصية ARIA؟

جعل العناصر سهلة القراءة من قِبل التقنيات المساعدة عندما لا يكون HTML كافيًا باستخدام خاصيّات ARIA. مثلًا، يمكنك الحصول على ذلك بإنشاء شريط تقدّم بدون استخدام عنصر <progess> من HTML غير المدعوم جيّدًا. يمكن جعل هذا الشريط يبدو ويتصرّف كأنّه شريطًا باستخدام CSS، لكن إذا كنت تستخدم عناصر div وspan لبنائه، فأنت بحاجة لإعطاء التقنيات المساعدة المزيد لصنع شيءٍ ما من تلك العناصر غير الدلالية. هذا هو المكان الذي تصبح فيه خاصيّات ARIA مثل role="progressbar"‎ ورفقائها المساعدين aria-valuenow، aria-valuemin وaria-valuemax (من بين أمور أخرى) مفيدةً. يمكنك تحديث القيمة داخل aria-valuenow باستخدام بعض الجافاسكربت كلّما تقدّم المستخدم في الخطوات قدّمتها له وهذا جيّد عمومًا. يمكنك قراءة المزيد حول هذا الموضوع على MDN إذا كنت مهتمًا أو غير معتاد على ذلك.

عظيم!

لدينا قيمة الخاصيّة ARIA لمساعدتنا في الإشارة إلى أن عنصرًا معينًا هو تلميح: tooltip. باستخدام role="tooltip"‎ فإنّ التقنيات المساعدة تعرف أنّ هذا العنصر هو بالفعل تلميح.

لكن عادةً ما يتم تشغيل التلميحات بواسطة إجراء يتم تنفيذه على عنصر آخر.

دعنا أولًا نعود إلى الأساسيات. حسب ويكيبيديا:

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

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

تشغيل فتح/إغلاق التلميح

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

بدأت في عرض التلميح عندما يتم التمرير والضغط على أيقونة المساعدة معًا.

من الجدير بالذكر عند هذه النقطة أنّ التلميحات تعمل أحيانًا على شاشة اللمس والمؤشر بدون أن تضطر للقيام بأي عملٍ إضافي، مثل تلك التي تظهر كتسميات مساعدة في حقول الإدخال input، مثل هذا المثال لـ Heydon Pickering. في سيناريوهات مثل عندما يكون role="tooltip"‎ مع aria-describedby فإنّ هذا كافٍ لتعرف التقنيات المساعدة أنّ هذا الجزء من النص يحتاج إلى تلميح يصف محتوى أو وظيفة حقل الإدخال. من السهل جدًا وضع علامة على التلميح في هذه الحالة لأنّه واضح بالفعل بما فيه الكفاية. كل ما تبقى لك هو إظهار/إخفاء النص عندما يتم التركيز على حقل input، وهذا يمكن أن يتم باستخدام سطري CSS فقط. التجربة ممتازة بالنسبة لشاشات اللمس والفأرة، وسيجرّبها الجميع بنفس الطريقة.

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

إليك بعض الأفكار التي دارت بذهني عندما كنت أفكر في تنفيذ هذا:

• استخدام عنصر <button> لتشغيل فتح وإغلاق التلميح. سيكون التلميح مخفيًا بالحالة الافتراضية لذا فإنّ التقنيات المساعدة لن تقرأه بصوتٍ عالٍ أثناء تحرّك المستخدم إلى أسفل الصفحة. يقاطع التلميح تدفق المحتويات في حالة مشروعنا لذا يجب عرضه عند الطلب فقط.
• "عند الطلب" تعني عندما يمرر/يضغط/ينقر/يركّز للتشغيل
• سيُخفى التلميح في الحالة الافتراضية باستخدام display: none ويُعرض فقط عند الطلب.
• بما أنّ الدلالات و"كيف ستقرأ الآلات هذا" هي التي ستحدد كيف سأبدأ بكتابة شيفرة HTML، فكرت:
  • إذا استخدمت <button> يجب أن أستخدم aria-controls للإشارة إلى عناصر التحكم للزر والتي ستُظهر/ستخفي بعض العناصر عندما تُضغط. الأمور جيّدة.
• عند الحديث عن الدلالات، يمكنني أيضًا استخدام رابط <a> يرتبط بقسم معين في الصفحة، وهو في حالتي العنصر الذي يحتوي على النص المساعد.
• عند استخدام رابط، سينتقل المستخدم إلى قسم الصفحة الذي يرتبط به هذا الرابط. أنا أكره القفز في الصفحات، أتجنّبه مثل الطاعون إلا إذا كان قرار القفز مقصودًا. (مثلًا، رابط "العودة إلى الأعلى" في كل صفحة طويلة).
• أحتاج جافاسكربت لتجنب القفز عند استخدام <a>، ولجعل <button> يفتح ويُغلق التلميح.
• أريد تجنّب جافاسكربت واستخدامه فقط عند الضرورة لسببٍ شاملٍ. ماذا لو كان المستخدم رجلًا كبيرًا ويستخدم جهازًا قديمًا تمّ تعطيل الجافاسكربت به؟

عادةً، أبحث عن آراء ثانية، عندما أحتار بين حلّين وعندما تبدأ الأفكار تدور في ذهني حول استخدام جافاسكربت وعدم استخدامها. مصدري الأول لرأيٍ ثانٍ هو غوغل. فكرت: "يجب أن يكون شخصًا ما قد بنى واحدًا من قبل وكذلك يجب أن يكون شخصًا غيره قد قام بذلك، لذا دعنا نرى كيف تعاملوا معه وحلّوا هذه المشكلة".

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

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

• تجنّب استخدام العنصر <button> وتمسّك باستخدام العنصر <a> لأنّه يمكن استخدام الروابط لأي شيء تقريبًا بينما يجب ترك الأزرار للاستخدام في النماذج. يجدر بي القول أنّني لا أتفق مع هذه النقطة، إذا كنت تعرف سببًا جيّدًا لتجنّب استخدام <button> الرجاء إخباري.
• عند استخدام العنصر <a> يجب أن تأخذ بالحسبان/تتذكر ما يلي:
  • إذا كنت تستخدم <a> وتمّ تضمين النص المساعد بداخله:
  • ستبدو الشيفرة كالتالي:

<a href="#" aria-describedby="#tip"> <!-- your icon here, img or svg --> <span id="tip"> Your hint text here </span> </a>

• • سيكون النص قابلاً للقراءة مع التدفق (وهو غير مناسب في حالتي) لأن محتوى النص المساعد يقاطع تدفق المعلومات والبيانات المعروضة في المحتوى الرئيسي.
  • يمكنك إخفاء وإظهار النص باستخدام CSS فقط مع display: none وdisplay: block على التوالي عندما يتم التمرير فوق الرابط. هذا جيد للمستخدمين المبصرين باستخدام الفأرة. لكن…
  • إذا أخفيت النص باستخدام display: none داخل <a> وعرضته عند التركيز فإنّ التقنيات المساعِدة لن تكون قادرة على قراءة النص المعروض لأنّ محتويات الرابط تُعلن فقط عند focus الأولى ولن يتم إعادة الإعلان عنها عندما يُعرض النص داخل الرابط مع display: block.
  • باختبار ذلك، لاحظتُ أنّه بما أنّ الرابط لا يرتبط فعليًا بأي مكان فإنّ المستخدم سينتقل إلى أعلى الصفحة عندما ينقر الرابط في شاشة تعمل باللمس. هذا أمر فظيع بشكلٍ خاص في حالتنا لأنّه لدينا صفحة طويلة والانتقال إلى الأعلى سيُربك المستخدمين. يمكن حلّ هذا باستخدام جافاسكربت preventDefault لمنع الحدث الإفتراضي عند النقر.
  • (برأيي: أنا لا أحب حقيقة أنّ الرابط لا يرتبط بأيّ مكان. إنّه رابط ذاتي التضمين، برأيي، إذا كان هذا يصنع فرقًا فإنّه ينفي دور الرابط للبدء به. كنت أعلم أنني لا أريد استخدام هذا على الرغم من أنّني اختبرته بدافع الفضول.)
  • إذا كنت تستخدم <a> وجعلته يرتبط بجزء نصي منفصل (ليس من فروع الرابط نفسه):
  • ستكون الشيفرة كالتالي:

<a href="#tip"><!-- icon here --></a><div id="tip"> <!-- tooltip text here --> </div>

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

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

خاتمة

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

إذا كنت مهتمًا بمعرفة المزيد حول ما تتطلّبه الخاصيّات، أنصح بشدّة بفحص مقاييس دور ARIA من WhatSock. فهي توفر نظرة عامة سهلة القراءة.

أيضًا لدى Paul J Adam عرض تجريبي يظهر الطرق المختلفة لعرض تلميحات عند التمرير. لا تزال أمثلته تستخدم جافاسكربت لبناء مكونات أكثر قابلية للوصول بتشغيل خاصيات ARIA عندما تفتح/تغلق التلميحات. هذا العرض يستحق تفحّصه بالتأكيد.

ترجمة -وبتصرف- للمقال Building a fully-accessible help tooltip لصاحبته Sara Soueidan