البحث في الموقع

شجعنا سابقًا على استخدام عناصر HTML الأساسية native لأنها توفر كل من إمكانية التركيز focus و دعم لوحة المفاتيح والدلالات المبنية مسبقًا built-in semantics. إلا أنه يوجد العديد من الحالات التي لا يكفي فيها استخدام عناصر HTML الأساسية مع نسق layout بسيط للوصول للمطلوب. مثلًا: لا يتوفر حاليًا عنصر HTML قياسي لإنشاء قائمة منبثقة pop-up menu رغم أنها شائعة الاستخدام. كما أنه لا يوجد عنصر HTML يوفر خاصية دلالية مثل "يحتاج المستخدم إلى معرفة ذلك بأسرع ما يمكن". نستكشف في هذه المقالة كيفية التعبير عن الدلالات التي لا تستطيع عناصر HTML التعبير عنها بمفردها وذلك بالاعتماد على مواصفات ARIA. مقدمة إلى ARIA تُعدّ المواصفات المُقدّمة من "مبادرة الوصول للويب لتطبيقات الإنترنت الغنية سهلة الوصول" Web Accessibility Initiative's Accessible Rich Internet Applications specification (WAI-ARIA أو فقط ARIA) مفيدة في الحالات التي لا يُمكن معالجتها باستخدام عناصر HTML الأساسية. تسمح هذه المواصفات بتحديد الخصائص التي تُعدّل طريقة ترجمة عنصر إلى شجرة الوصول accessibility tree. نبدأ أولًا بمثال بسيط. نستخدم في مقطع الشيفرة التالي عنصر قائمة li كنوع من مربع اختيار مخصص. يوفر الصف "checkbox" خصائص العنصر المرئية المطلوبة: <li tabindex="0" class="checkbox" checked> Receive promotional offers </li> لن يتمكن قارئ الشاشة من إعطاء أي إشارة للمستخدم بأن العنصر السابق يُعامل كمربع اختيار، وبذا لن يكون هذا العنصر واضحًا إلا للمستخدمين المبصرين أما بالنسبة لضعاف البصر (الذين يستخدمون قارئ الشاشة) فسيكون هذا العنصر مخفيًا تمامًا عنهم. تسمح خصائص ARIA بتوفير المعلومات الناقصة لهذا العنصر مما يُمكّن قارئ الشاشة من فهمه بشكل صحيح. تُبين الشيفرة التالية إضافة خاصية الدور role وخاصية حالة الاختيار aria-checked (من ARIA) للتصريح الواضح بأن العنصر هو مربع اختيار وحالته الافتراضية "مُحدّدًا". ستُضاف قائمة هذا العنصر إلى شجرة الوصول المستخدمة من قبل قارئ الشاشة الذي سيُعرّف هذا العنصر للمستخدم بشكل صحيح بعد الآن. <li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true"> Receive promotional offers </li> ملاحظة: نعرض خصائص ARIA لاحقًا. تُعدّل ARIA شجرة الوصول الناتجة عن شجرة DOM وفق ما يلي: تسمح ARIA بتعديل شجرة الوصول (جزئيًا أو كليًا) لأي عنصر في الصفحة، إلا أنها لا تزيد على أي من السلوكيات الأصيلة في العنصر. فهي، مثلًا، لن تُغيّر من إمكانية التركيز على العنصر ولن تُضيف له مستمع لحدث من لوحة المفاتيح. تبقى هذه الأمور من مهام المطور. يجب الانتباه جيدًا إلى أننا لا نحتاج لإعادة تعريف الدلالات الضمنية للعناصر. مثلًا: لا يحتاج مربع الاختيار القياسي <"input type="checkbox> لأن نُضيف له دور "role="checkbox ليٌعامله قارئ الشاشة بشكل صحيح. تجدر الإشارة أيضًا إلى أن لبعض عناصر HTML قيود على إضافة أدوار وخصائص ARIA إليها. مثلًا: لا يسمح عنصر مربع النص القياسي في HTML بإضافة أي دور أو خاصية عليه <"input type = "text>. يُمكن استعراض مواصفات ARIA من خلال ARIA in HTML spec. وسنعرض فيما يلي بعض الإمكانات الأخرى التي توفرها ARIA. ما الذي يمكن أن تفعله ARIA؟ يُمكن أن تُعدّل ARIA من دلالات العناصر أو تُضيف إليها دلالات جديدة غير موجودة في دلالاتها الأساسية كما عرضنا في مثال مربع الاختيار السابق. يُمكن لها أيضًا التعبير عن نماذج دلالات غير موجودة على الإطلاق في HTML، مثل قائمة menu أو تبويب في لوحة panel. تسمح ARIA غالبًا بإنشاء عناصر جديدة لواجهة المستخدم لا يُمكن بنائها باستخدام HTML القياسية. مثلًا، يُمكن أن تُضيف ARIA عنوان label إضافي لوضع نص توصيفي يُعامل فقط في واجهة برمجة التطبيقات للتقنية المساعدة. <button aria-label="screen reader only label"></button> يُمكن باستخدام ARIA التعبير عن العلاقات الدلالية بين العناصر التي تعمل على توسيع العلاقة القياسية أب/ابن، مثل شريط تمرير مخصص custom scrollbar يتحكم في منطقة معينة. <div role="scrollbar" aria-controls="main"></div> <div id="main"> . . . </div> يُمكن باستخدام ARIA جعل أجزاء من الصفحة "مباشر" live، بحيث تُعلّم التقنية المساعدة عند حدوث أي تغيير فيها فورًا . <div aria-live="polite"> <span>GOOG: $400</span> </div> من أهم الميزات المُقدّمة من ARIA هو مجموعة الأدوار التي يُمكن تعريفها للعناصر. إذ يسمح إسناد دور معين لعنصر بتعريف سلوك هذا العنصر مباشرًة. توفر ARIA مجموعة معينة من نماذج الأدوار التي يُمكن إسنادها لعناصر HTML. مثلًا: يُخبر استخدامنا للدور "role="checkbox التقنية المساعدة بأن سلوك هذا العنصر يجب أن يُماثل سلوك مربع اختيار checkbox. أي أنه يجب أن يكون له حالة الاختيار (مُحدّد أم لا)، وبأن هذه الحالة يُمكن قلبها باستخدام الفأرة أو شريط المسافة من لوحة المفاتيح (تمامًا مثل أي مربع اختيار من HTML). تلعب أحداث لوحة المفاتيح دورًا أساسيًا عند استخدام قارئ الشاشة، ولذا فمن المهم جدًا التأكد عند إنشاء عنصر مخصص من تطبيق خاصية الدور role في نفس مكان تطبيق خاصية ترتيب الجدولة tabindex مما يضمن ذهاب أحداث لوحة المفاتيح إلى المكان الصحيح وتطبيق الدور بدقة عندما يُصبح التركيز على عنصر. تُقدّم مواصفات ARIA مجموعة المفردات للقيم الممكنة لخاصية الدور ولخصائص ARIA التي يُمكن استخدامها مع الأدوار جنبًا إلى جنب بطريقة تدعمها المستعرضات والتقنيات المساعدة. نظرًا للعدد الكبير للمواصفات، يُمكن البدء من وثيقة ممارسات التأليف ARIA Authoring Practices document التي تعرض أفضل الممارسات لاستخدام أدوار وخصائص ARIA المتاحة. توفر ARIA أيضًا أدوارًا مميزة توسع الخيارات المتاحة في HTML5. يُمكن العودة إلى نماذج تصميم الأدوار Landmark Roles Design Patterns لمزيد من المعلومات. العناوين في ARIA توفر ARIA العديد من الآليات لإضافة عناوين labels أو وصف للعناصر. في الواقع، تُعدّ الخاصية aria-label الطريقة الوحيدة لإضافة مساعدة سهلة الوصول أو نص يصف للعنصر. نعرض فيما يلي الخصائص المستخدمة لإنشاء عناوين سهلة الوصول. عنوان aria-label ARIA تسمح الخاصية aria-label بتحديد سلسلة نصية لاستخدامها كعنوان سهل الوصول. تُلغي هذه الخاصية أي عنوان مُمكن آخر مُحدّد باستخدام طريقة أساسية كاستخدام العنصر label. مثلًا: إذا تضمن زر كل من خاصية النص text وخاصية aria-label فستُستخدم خاصية aria-label فقط. يُمكن استخدام الخاصية aria-label عندما يوفر العنصر نوعًا من المؤثرات المرئية لتوضيح الغرض من العنصر كوضع صورة مُعبّرة على زر عوضًا عن النص إلا أنه مازال ضروريًا توفير توضيح عن هذا العنصر لأي شخص غير قادر على إدراك المؤثر المرئي الموجود (مشاهدة الصورة الموضوعة على الزر). معنون باستخدام aria-labelledby تسمح الخاصية aria-labelledby بتحديد مُعرّف ID عنصر آخر في شجرة DOM كعنصر يوفر العنوان. يشبه هذا السلوك إلى حد كبير استخدام عنصر العنوان label، مع بعض الاختلافات الرئيسية: يُمكن استخدام aria-labelledby مع أي عنصر، وليس فقط مع العناصر القابلة للعنونة. يُشير عنصر العنوان label إلى الشيء الذي يُعنونه، تنعكس العلاقة في حالة aria-labelledby إذ أن الشيء المُعنون يشير إلى الشيء الذي يُعنونه. يُمكن ربط عنصر عنوان label واحد فقط بعنصر قابل للعنونة، أما الخاصية aria-labelledby فيُمكن أن تأخذ قائمة من المُعرّفات IDREFs لتكوين عنوان من عناصر متعدّدة. يكون العنوان النهائي حصيلة ضمّ نصوص العناصر وفق ترتيبها ضمن IDREFs. يُمكن استخدام aria-labelledby للإشارة إلى عناصر مخفية والتي لن تكون ضمن شجرة إمكانية الوصول. مثلًا: يُمكن إضافة امتداد span مخفي جانب العنصر المطلوب عنونته والإشارة إليه باستخدام aria-labelledby. لا تمنح الخاصية aria-labelledby سلوك النقر المألوف على عنصر العنوان label إذ أن ARIA لا يؤثر إلا على شجرة الوصول. يجب ملاحظة أن عنوان aria-labelledby له الأولوية الأولى أي أنه يتجاوز جميع مصادر العناوين الأخرى. مثلًا: في حال كان لعنصر كل من الخاصيتين aria-labelledby و aria-label أو كل من الخاصيتين aria-labelledby و label الأساسية من HTML، فسيكون العنوان المُعتمد هو العنوان المُحدّد من الخاصية aria-labelledby. العلاقات في ARIA تُنشئ الخصائص العلائقية علاقات Relationships دلالية بين عناصر الصفحة وذلك بغض النظر عن علاقتهم في شجرة DOM. مثلًا: الخاصية aria-labelledby هي مثال عن خاصية العلاقة "العنصر مُعنون بهذا العنصر". تُحدّد مواصفات ARIA ثمان خصائص علائقية [eight relationship attributes، ستٌ منها تُشير إلى عنصر أو أكثر على الصفحة وتُستخدم لإنشاء علاقات جديدة بين هذه العناصر: aria-activedescendant. aria-controls. aria-describedby. aria-labelledby. aria-owns. يكمن الفرق في كل حالة بمعنى العلاقة وكيفية عرضها للمستخدمين. التملك aria-owns تُعدّ خاصية التملك aria-owns من أكثر علاقات ARIA استخدامًا. تسمح هذه الخاصية بإعلام التقنية المساعدة بأن عنصر ما منفصل في شجرة DOM يجب أن يُعامل كابن للعنصر الحالي، أو أنه يجب إعادة ترتيب العناصر الأبناء بشكل مختلف. مثلًا: في حال وضع قائمة جزئية منبثقة pop-up sub-menu أمام القائمة الأب لها مع عدم إمكانية وضع هذه القائمة المنبثقة ابنًا للقائمة الأب في شجرة DOM لأن ذلك يؤدي إلى تغيير مظهر العرض المرئي المطلوب. يُمكن في هذه الحالة استخدام aria-owns لتقديم القائمة الفرعية المنبثقة كابن للقائمة الأب لقارئ الشاشة. الابن النشط aria-activedescendant تلعب الخاصية aria-activedescendant دور الوصل بين العناصر. مثلًا: تُعلّم هذه الخاصية التقنية المساعدة بأنه عند وصول التركيز على عنصر (الذي أسندنا قيمة لهذه الخاصية فيه) فيجب إعلام المستخدم بحصول التركيز على عنصر آخر. مثلًا: يُمكن أن يكون المطلوب عند استخدام مربع قائمة listbox ترك التركيز على حاوية مربع القائمة مع تحديث الخاصية aria-activedescendant إلى العنصر الحالي المُحدّد من القائمة مما يجعل هذا العنصر يظهر للتقنية المساعدة فيما لو كان العنصر الحاصل على التركيز. الوصف باستخدام aria-describedby توفر الخاصية aria-describedby وصفًا سهل الوصول بنفس الطريقة التي توفر بها الخاصية aria-labelledby العنوان. يُمكن لهذه الخاصية الإشارة إلى عناصر مخفية سواًء في شجرة الوصول أو في شجرة DOM. تُقدّم هذه الخاصية آلية مفيدة لتقديم شرحًا إضافيًا لكل من المستخدمين العاديين ولمستخدمي التقنية المساعدة. من الأمثلة الشهيرة على استخدام هذه الخاصية هي حالة حقل إدخال كلمة السر والمصحوب بنص يشرح متطلبات كلمة السر. على خلاف العنوان، يُمكن عرض هذا النص التوضيحي أم لا للمستخدم الذي يكون له الخيار في الوصول إليه أو قد يأتي بعد كل المعلومات الأخرى أو يُمكن استباقه بشيء آخر. مثلًا: إذا كان المستخدم يُدخل بعض المعلومات فيُمكن لهذه المعلومات أن تُظهر مرة أخرى مقاطعًة وصف العناصر. وبهذا يكون الوصف طريقة رائعة لتوصيل معلومات إضافية غير أساسية ولن يقف في طريق الحصول على معلومات أكثر أهمية مثل دور العنصر. المكان والحجم aria-posinset & aria-setsize تعمل الخصائص المتبقية معًا (والمختلفة قليلًا عن الخصائص السابقة). تُعرّف الخاصيتان aria-posinset (المكان في المجموعة) و aria-setsize (حجم المجموعة) العلاقة بين العناصر الأخوة في مجموعة، مثل حالة القائمة list. عند تعذر تحديد قياس المجموعة باستخدام العناصر الموجودة في شجرة DOM، مثل حالة التصيير الكسول lazy rendering المستخدمة عادًة لتجنب وجود قائمة ضخمة في شجرة DOM دفعة واحدة. تُحدّد الخاصية aria-setsize الحجم الفعلي للمجموعة، أما الخاصية aria-posinset فتُحدّد مكان العناصر في المجموعة. مثلًا: يُمكن في مجموعة تحوي 1000 عنصر من تعيين العنصر ذو الترتيب 857 ليكون الإظهار الأول في شجرة DOM واستخدام تقانات HTML الديناميكية للتأكد من تمكّن المستخدم من استكشاف كامل عناصر القائمة عند الحاجة. إظهار وإخفاء المحتوى تُعدّ عملية عرض الأجزاء المناسبة من الصفحة للتقنية المساعدة من الآليات المهمة في صقل تجربة مستخدمي التقنية المساعدة. يوجد العديد من الطرق للتأكد من عدم عرض جزء ما من شجرة DOM لواجهة برمجة تطبيقات شجرة الوصول. الإخفاء aria-hidden أولًا، لا يُضمّن في شجرة الوصول أي شيء مخفي بشكل صريح في شجرة DOM. وبالتالي، فإن أي نمط CSS يتعلق بالإخفاء مثل visibility: hidden أو display: none أو الخاصية hidden في HTML5 سيكون مخفيًا أيضًا لمستخدمي التقنية المساعدة. ومع ذلك، فإن أي عنصر لم يُعرض على الصفحة إلا أنه غير مخفي بشكل صريح سيبقى موجودًا في شجرة الوصول. من الطرق الشائعة تضمين "نص لقارئ الشاشة فقط" في عنصر موضوع خارج الشاشة بشكل مطلق absolute. .sr-only { position: absolute; left: -10000px; width: 1px; height: 1px; overflow: hidden; } يُمكن، كما عرضنا سابقًا، توفير نص لقارئ الشاشة فقط باستخدام aria-label أو aria-labelledby أو aria-describedby مع الإشارة إلى عنصر مخفي، كما يُمكن العودة إلى مقالة منظمة WebAIM حول تقانات إخفاء العناصر Techniques for hiding text للمزيد من المعلومات عن توفير "نص لقارئ الشاشة فقط". توفر ARIA آلية لاستبعاد المحتوى غير المخفي باستخدام الخاصية aria-hidden والتي يؤدي تطبيقها على عنصر إلى حذفه مع جميع أبناءه من شجرة الوصول مع استثناء العناصر المشار إليها بإحدى الخاصيتين aria-labelledby و aria-describedby. <div class="deck"> <div class="slide" aria-hidden="true"> Sales Targets </div> <div class="slide"> Quarterly Sales </div> <div class="slide" aria-hidden="true"> Action Items </div> </div> مثلًا: يُمكن استخدام الخاصية aria-hidden في حال إنشاء واجهة مستخدم شرطية modal والتي تمنع المستخدم من الوصول إلى الصفحة الرئيسية. في مثل هذه الحالة يرى المستخدم المبصر نوعًا من التراكب شبه الشفاف والذي يُفهمه بأنه لا يستطيع الوصول إلى عناصر الصفحة الأساسية أما مستخدم قارئ الشاشة فيبقى قادرًا على الوصول إلى جميع أجزاء الصفحة. يُمكن هنا إضافًة لقفل لوحة المفاتيح التأكد من أن جميع أجزاء الصفحة المطلوب إخفائها عن المستخدم لها الخاصية aria-hidden. يٌمكن الآن بعد فهم أساسيات ARIA وكيف تتعامل مع دلالات عناصر HTML الأساسية وآلية استخدامها لإجراء تعديلات في شجرة إمكانية الوصول، الانتقال إلى مسألة إيصال المعلومات الهامة بشكل فوري للمستخدم. الجزء الحي aria-live تسمح الخاصية aria-live للمطور بتحديد جزء من الصفحة على أنه "حي" live بمعنى أنه يجب إعلام المستخدم بأي تحديث في هذا الجزء فورًا وبغض النظر عن موضع المستخدم في الصفحة، أي دون أن يقوم المستخدم باستكشاف هذا الجزء من الصفحة. عندما يكون لعنصر الخاصية aria-live، يُدعى الجزء من الصفحة الذي يحوي هذا العنصر وأبناءه بالمنطقة الحية أو الآنية live region. مثلًا: إذا كانت المنطقة الحية عبارة عن رسالة حالة تُظهر نتيجة إجراء ما للمستخدم، وكانت الرسالة هامة كفاية لجذب أنظار المستخدمين المبصرين فإنه من الضروري بمكان تنبيه مستخدم التقنية المساعدة إليها وذلك بضبط الخاصية aria-live. يُمكن مقارنة حالة هذا القسم div العادي: <div class="status">Your message has been sent.</div> مع نظيره "الآني": <div class="status" aria-live="polite">Your message has been sent.</div> يُمكن أن يكون للخاصية aria-live إحدى القيم الثلاث التالية: polite و assertive و off. القيمة aria-live="polite": تُعلّم هذه القيمة التقنية المساعدة لتنبيه المستخدم بالتغيير الحاصل حال انتهائه مما يعمل حاليًا. تُستخدم هذه القيمة عندما يكون هنالك أمرًا هامًا إلا أنه غير مستعجل جدًا وهي الحالة العامة لاستخدام aria-live. القيمة aria-live="assertive": تُعلّم هذه القيمة التقنية المساعدة لتنبيه المستخدم بالتغيير الحاصل فورًا وبغض النظر عما يقوم به حاليًا. تُستخدم هذه القيمة عندما يكون هنالك أمرًا هامًا ومستعجلًا مثل "حصل خطأ على الخادم ولم تُحفظ تعديلاتك، يُرجى إعادة تحميل الصفحة"، أو كتعديل على حقل إدخال نتيجة إجراء مستخدم كالنقر على أزرار عنصر تحديد خطوة stepper widget. القيمة aria-live="off": تُعلّم هذه القيمة التقنية المساعدة بإيقاف مقاطعات aria-live بشكل مؤقت. من الإرشادات الذكية للتأكد من أن المناطق المباشرة تعمل بشكل صحيح: أولًا، قد تُحدّد المنطقة المباشرة aria-live خلال التحميل الأول للصفحة. لا يُعدّ هذا الأمر قاعدة مؤكدة إلا أنه قد يكون هذا سبب مشكلة المنطقة المباشرة. ثانيًا، يُمكن أن يكون تعامل برامج قراءة الشاشة مختلفًا مع أنواع التحديثات الممكنة. مثلًا: يُمكن إطلاق تنبيه في بعض برامج قراءة الشاشة لمجرد قلب حالة عنصر من مخفي إلى ظاهر أو بالعكس باستخدام النمط hidden. يُمكن للخصائص الأخرى التي تعمل مع aria-live المساعدة في الضبط الدقيق لما يُعرض للمستخدم حال حصول تحديثات في المنطقة المباشرة. تُحدّد الخاصية aria-atomic، والتي تأخذ إحدى القيمتين true أو false (القيمة الافتراضية)، فيما إذا كان من الواجب اعتبار كامل المنطقة المباشرة عند الإعلام بالتحديثات أم لا. مثلًا: في حال استخدام عنصر التاريخ والذي يتألف من اليوم والشهر والسنة، فإن تغيير المستخدم لقيمة الشهر فقط يؤدي إلى إعادة قراءة التاريخ فيما لو كانت aria-atomic=true و aria-live=true. تُحدّد الخاصية aria-relevant أنواع التغييرات الواجب إعلام المستخدم بها. يوجد بعض الخيارات التي يُمكن استخدامها بشكل منفصل أو بشكل قائمة: الإضافات additions: تعني أن أي إضافة إلى المنطقة المباشرة يجب إعلام المستخدم بها. مثلًا: في حال إضافة امتداد span لسجل رسائل الحالة يُمكن أن يعني أنه من الأنسب إعلام المستخدم بهذا الامتداد الجديد (بافتراض أن قيمة aria-atomic هي false). النص text: تعني أن النص المُضاف لأي عقدة تابعة descendant node هو نصًا مناسبًا لإعلام المستخدم به. مثلًا: يُمكن عند تحديث الخاصية textContent لحقل نص مخصص إعادة قراءة النص للمستخدم. الحذف removals: تعني وجوب إعلام المستخدم بحذف أي نص أو عقدة تابعة. الكل all: تعني أن جميع التغييرات مناسبة لإعلام المستخدم بها. تكون القيمة الافتراضية للخاصية هي التسلسل additions text مما يعني أنه في حال عدم تحديد الخاصية aria-relevant فسيُعلم المستخدم بأي إضافة إلى العنصر وهو المطلوب في معظم الأحيان. أخيرًا، تطلب الخاصية aria-busy من التقنية المساعدة إهمال جميع التحديثات على العنصر بشكل مؤقت، مثلًا: خلال فترة التحميل يُمكن إسناد القيمة true لهذه الخاصية وعند الانتهاء نعاود إسناد القيمة false لها للعودة للوضع الطبيعي لقارئ الشاشة. ترجمة -وبتصرف- لمجموعة المقالات: Introduction to ARIA ARIA Labels and Relationships Hiding and Updating Content للمؤلفين: Meggin Kearney وDave Gash وAlice Boxhall. اقرأ أيضًا المقال السابق: الدلالات المضمنة لعناصر صفحة الويب ودورها في تعزيز سهولة الوصول سهولة وصول جميع الزوار لمواقع وتطبيقات الويب التركيز على عناصر صفحة الويب نحو فهم أعمق لتقنيات HTML5

كنت أعمل البارحة على إنشاء الشرائح والعروض التجريبية المرافقة لحديثي القادم عن الشيفرة في موقع web directions الأسبوع المقبل. أحد العروض التجريبية التي أنشئها هو دليل أساسي لمفهوم المفتاح البسيط الذي يُستخدم لتبديل مظهر واجهة المستخدم من مضيء إلى مظلم وبالعكس، أحببته واستلهمته من مبدّل المظهر في تطبيق Medium المبين أدناه. مُخصِّص مظهر تطبيق Medium هو لوحة منبثقة بسيطة تتضمن مفتاح بسيط للتبديل من وضع مضيء إلى مظلم وبالعكس. الاختلاف الوحيد الذي أريده هو أن يشير مفتاحي إلى حالة المظهر الفعالة حاليًا بشكلٍ واضح. لذا بدلًا من تفعيل وتعطيل المظهر المظلم فقط مثل مفتاح Medium، أريد أن يبدّل المستخدم بين خيارَي مضيء ومظلم بوضوح. لا يوجد سبب محدد لذلك سوى أنّه تفضيل شخصي. هناك طرق أخرى للقيام بذلك أيضًا، يبقى أمر كيفية تصميمه تفضيلًا شخصيًا، طالما أنّه يعمل وقابلًا للفهم بسهولة من قِبل المستخدمين. بدأت أفكر كالعادة في كيفية تمييز هذا العنصر البسيط، مع التأكّد من سهولة الوصول إليه مباشرةً من البداية. لذا بدأت القيام بواجبي وقراءة وتعلّم كل ما بوسعي بشأن هذا الموضوع. كان من المهم بالنسبة إليّ التأكد أنّ هذا العرض التجريبي سهل الوصول حتى لو كان مجرد دليل سريع للمفهوم لحديث. أولًا وقبل كل شيء، بما أنّ شيفرة العرض التجريبي ستكون متاحة للعامة، كان لدي مسؤولية أكبر للتأكّد من أنّها سهلة الوصول، لأنني لا أريد نشر أي شيفرة لا يمكن الوصول إليها، خاصةً إذا كان هناك فرصة ليستخدمها الناس في مكان آخر. وأردت أن تكون الشيفرة جيدةً لسببٍ آخر هو أنّني ربما أرغب في إعادة استخدامها لمكونات أخرى في ورشة عمل قادمة لي حول تطوير الواجهة الأمامية. البدء بالشيفرة كما ذكرت أعلاه، بدأت أفكر في كيفية ترميز هذا العنصر لضمان سهولة وصوله إلى قارئات الشاشة. عندها أدركت (وأحسست بالغباء نوعًا ما) أنّ الوظيفة والترميز يعتمدان على الطريقة التي أريد أن يكون سلوك التبديل بها وكيف أريده أن يظهر. كان الأمر واضحًا جدًا بالنسبة لي: سيسمح المفتاح للمستخدم بالاختيار بين المظهر المضيء والمظهر المظلم، وسيكون المظهر المضيء هو الافتراضي. وفي هذه اللحظة تبادر إلى ذهني أزرار الانتقاء (radio buttons): خياران يمكن تفعيل أحدهما فقط في وقت واحد، هذا يمكن أن يصنع حالة استخدام ممتازة لأزرار الانتقاء القديمة الجيدة. كنت أعلم أنّه يجب عليّ اختيار شيء ما مختلف في حال أردت أن تبدو واجهة المستخدم وتتصرف بشكلٍ مختلف. مثلًا، إذا أردت لواجهة المستخدم أن تعرض "تفعيل/تعطيل النمط المظلم"، عندها لن أحتاج إلى استخدام أزرار الانتقاء لأنّ لدي خيارًا واحدًا فقط للتعامل معه وهو التشغيل أو إيقاف التشغيل، سيكون ذلك حالة استخدام رائعة لمربع تأشير (checkbox) أو عنصر زر <button> تبديل قديم جيد. تحليلات التصميم والوظيفة مترابطان، مما يساعد على التفكير في هذين الأمرين في وقت واحد عند التصميم لسهولة الوصول (وفي الحقيقة تصميم أي شيء بشكلٍ عام). ابدأ دائمًا وأبدًا بالتفكير حول الترميز وسهولة الوصول عند إنشاء المكونات بغض النظر عن مدى صغرها وبساطتها. دراسة كنت بحاجة -كما هو الحال دائمًا- إلى دعم نظريتي وتطبيقي العملي بالبحث الجيد، لذا بدأت بالقراءة، مراجعي الأولى التي ألجأ إليها هي المكونات الشاملة ومشروع A11y لـ Heydon Pickering. كما اتّضح، لدى Heydon مقالة رائعة حول أزرار التبديل تعلّمت منها الكثير، ولدى صديقي Scott O’Hara زر تبديل ARIA مضمّن في قسم الأنماط من مشروع A11y. لذلك، بطبيعة الحال، فحصتُ شيفرة الزر وقرأتُ مقالة Heydon للتأكّد فيما إذا كنت على الطريق الصحيح. تجدر الإشارة قبل المتابعة إلى أنّ هذه ليست مقالة حول كيفية إنشاء مفاتيح تبديل سهلة الوصول. مقالة Heydon تقوم بعمل رائع يغطي ذلك. النقاط الرئيسية التي استخلصتها شخصيّا من البحث أعلاه هي: هناك أنواع مختلفة من المفاتيح التي تبدو وكأنّها تقوم بأشياء مماثلة ولكنها تختلف اختلافًا جوهريًا عندما يتعلق الأمر بالترميز وسهولة الوصول. ليس بالضرورة أن تكون متشابهة، لمجرد أنّها مصممة لتظهر بنفس الشكل. أحتاج إلى التفكير بالسلوك الذي ستسلكه واجهة المستخدم، الشكل والصوت عند التبديل. أولًا التصميم وتجربة المستخدم، ثمّ الشيفرة. يمكن استخدام مفتاح التبديل للتبديل بين خيارين منفصلين، أو يمكن استخدامه لتشغيل خيار واحد أو إيقاف تشغيله (أو مثل تفعيل/تعطيل خيار). هنا تبدأ اختلافات التطبيق بالظهور. إذا كنت تبدّل بين خيارين منفصلين، فإنّ استخدام أزرار الانتقاء القياسية يبدو منطقيًا. يتم استخدام أزرار الانتقاء عندما تريد من المستخدمين اختيار خيار واحد فقط من خيارين أو أكثر، لذا فإنّ هذه حالة استخدام مثالية لهم. لديهم أيضّا إمكانية وصول أساسية وسيتم وضع إشارة إلى جانب الخيار الذي تم تفعيله. تأكّد فقط أنّك لا تحدّ من إمكانية الوصول لأيٍّ منهما في HTML أو باستخدام CSS. إذا كان الهدف من التبديل هو تفعيل/تعطيل ميزة (أو تشغيلها/إيقافها)، هناك طرق أخرى لذلك: استخدام صندوق تأشير لتأشير/إلغاء تأشير (تفعيل/تعطيل) هذا الخيار. استخدام زر <button> يكون له حالتان: مضغوط وغير مضغوط. تتطلب هذه الطريقة استخدام ARIA والذي بدوره سيتطلب جافاسكربت لتعمل التقنيات المساعدة بشكل صحيح (يتم تحديث قيم خاصية ARIA عند الضغط باستخدام جافاسكربت). اقرأ مقال Heydon للمزيد من التفاصيل عن هذه الطريقة. تعني هذه الطريقة أن لديك خيارًا واحدًا فقط، وهذا يعني بدوره أنّ زر التبديل له تسمية واحدة مرتبطة فقط، وربما لن يبدو زر "التبديل المزدوج" بعد الآن، إلا إذا: حالات زر التبديل المزدوج (التي تشير إلى تشغيل/إيقاف) سيكون لها نصّا واضحًا يصف الحالة الحالية الفعالة، لذا ستبدو مثل هذا المثال من العرض التجريبي لـScott في مشروع A11y: بالنسبة لاستخدامي لمحوّل المظهر، فهو خيارٌ واضحٌ: بما أنّ المستخدم لديه خيارات (مظلم ومضيء)، أردت استخدام أزرار الانتقاء. لم أكن أريد أن أقول "تشغيل/إيقاف تشغيل الوضع المظلم" إنّما أردت أن أقول "تفعيل الوضع المضيء أو تفعيل الوضع المظلم". سيكون الحل هو HTML وCSS فقط، ولا يتطلب جافاسكربت، وستتم إتاحة إمكانية الوصول بشكلٍ افتراضي. تحليل دَع لديك فكرة واضحة حول كيفية تصميم المكون وماذا يُفترض أن يفعل أو لا يفعل، واجعل الترميز والتصميم يعتمدان على هذه الفكرة. فحص الشيفرة الآن، وبعد قراءة وفحص المصادر السابقة، قررت أن أرى كيف يقوم الناس بالتبديل. بعد كل ذلك، كنت أعلم أنني سأجد الكثير من الأمثلة لمفاتيح التبديل التي تبدو وتتصرف مثل هذا المثال الحي على codepen، من الرائع دومًا أن أرى كيف يفعل الآخرون ذلك - ربما أفتقد بعض التقنيات الرائعة التي يمكن أن أتعلمها للتصميم، أو ربما أفتقد بعض المعلومات المهمة عندما يتعلق الأمر بالترميز وقابلية الوصول. نظرًا لأنني كنت أعمل في codepen على نسختي الخاصة من هذا المفتاح (شاركت العرض التجريبي أدناه)، أظنُّ أنني فحصت مفتاح التبديل الخاص بـcodepen: المفتاح الذي تستعمله لاختيار فيما إذا إذا كنت تريد لتصميمك أن يكون عامًا أو خاصًا. تحليل سريع من المفيد والممتع أن تتعلم من عمل الآخرين بفحص شيفرتهم (سواء ذلك عن طريق أدوات المطور [devtools] أو على codepen). مفتاح الخصوصية في Codepen يعرض مفتاح التبديل في codepen بعض السلوكيات الغريبة التي لاحظتها سابقًا ولكن لم أشعر أبدًا بالفضول لأقوم بال"تنقيح". يُظهر الفيديو التالي هذا السلوك: Your browser does not support the video tag. تجدر الإشارة أولًا إلى أنّني كنت محتارة بشأن هذا المفتاح. دائمًا ما يعطي اللون الأحمر مقابل الأخضر حلقة ردود فعل غريبة. إذا جعلت التصميم خاصًا، سيتحول اللون للأخضر، وجعله عامًا سيجعل اللون أحمر. بالنسبة لي فإنَّ الأخضر يعني أكثر من ذلك "التصميم قابل للوصول من قِبل الأشخاص، إنّه متاح" واللون الأحمر أكثر من ذلك "هذا التصميم مغلق، لا يُسمح للأشخاص بالوصول". ولكن بالنسبة لـcodepen فإن هذه الألوان ترمز إلى أشياء أخرى. وبشكل أكثر تحديدًا يرمز الأحمر إلى "المنطقة العامة = المنطقة الخطرة" أو "احذر هذا التصميم متاح للعامة وهذا غير جيّد". (آسفة لأنّي درامية جدًا، ولكن هذا هادفًا). ثمّ هناك سلوك الأخطاء المبيّن في الفيديو أعلاه (إذ أنّ النقر على نفس التسمية يغيّر قيمة المفتاح إلى قيمة التسمية الأخرى). كنت فضولية مجددًا لمعرفة سبب ذلك، شغّلتُ أدوات المطور وفحصت الشيفرة. وجدت أنَّ مفتاح codepen هو صندوق تأشير واحد يبدو أنّه يحتوي تسميتين. لذلك عند الضغط على "عام" و"خاص" معًا عدة مرات يؤدي إلى تشغيل وإيقاف تشغيل المفتاح عدة مرات. بكلماتٍ أخرى، هذا هو السبب في أنَّ رد الفعل/ السلوك المرئي للمفتاح لا يُطابق هدف المفتاح أو ما يبدو أنّه يعمل. كتبت تغريدةً حول هذا الخطأ، وسببه المحتمل واقترحتُ حلًا بديلًا يُصلح الأمر. بدأت في الحصول على ردود وآراء من مطورين آخرين، مما أدّى إلى نقاش جيد ومفيد للغاية استمتعت به تمامًا (أحد الجوانب الإيجابية القليلة في تويتر). بالطبع، كان الإجماع العام هو أنّ المفتاح يحتاج إلى إصلاح. لكن كيفية إصلاحه تعتمد بشكلٍ كبير على ما يريد فريق codepen القيام به: إذا كان من المفترض أن يكون مفتاح التبديل هو زر تفعيل/تعطيل للخيار "خاص" عندها: هذا يعني أنّ نمط التبديل تشغيل/إيقاف المذكور في القسم السابق أعلاه سيكون الحل المثالي. هذا يعني أنّه سيتم تجاهل التسمية "عام" والاحتفاظ بالتسمية "خاص" فقط، مع إشارة واضحة إلى أنّ المفتاح المجاور لها يعمل على إيقاف الخيار أو تشغيله، وهذا يقودني إلى نقطة أخرى: يجب إمّا أن يتغير التمثيل البصري للمفتاح بالكامل أو يتم تعديله: إذا كان يجب أن يبقى زر المفتاح كما هو بصريًا (أي الحفاظ على سلوك المفتاح المزدوج "نقل هذا التبديل يسارًا ويمينًا")، أقترح إضافة تسميات "تشغيل/إيقاف" له بشكلٍ شبيه لما فعله Scott في عرضه التجريبي مشروع A11y، لأنّه وفقًا لإرشادات الوصول لمحتوى الويب (WCAG)، يجب ألا تستخدم اللون فقط لنقل المعلومات. تحتاج الألوان أيضًا أن يكون لديها تباين كافٍ إذا كنت تستخدمها. ومرةً أخرى، كنت أعيد النظر في ألوان الأحمر والأخضر لأنّها قد تربك شخصًا ما مثلما أربكتني لفترةٍ من الوقت. (اقترح عليّ أحدهم الرمادي والأخضر، لأنّ "إضافة اللون يمكن أن تدلّ بشكلٍ كبيرٍ على الحالة الفعّالة (بدون لون مقابل لون يواجه لونين منفصلين)"). يمكن أن تكون البنية الأساسية والترميز لهذه الحالة (تسمية واحدة فقط): صندوق تأشير، يمكن أن يكون مفعّلًا أو غير مفعّل. أودّ اقتراح استخدام تصاميم صندوق تأشير بسيطة (ربما رائعة) لهذا السلوك والتخلّي عن أسلوب التبديل المزدوج بالكامل. زر <button> مع خاصية aria-pressed (و aria-checked إذا احتجت)، إذ تشير حالة الضغط إلى أنّ التصميم خاص، وحالة عدم الضغط إلى أنّ التصميم غير خاص، أي أنّه عام. سيتغير تصميم الزر في هذه الحالة أيضًا، وقد يتطلّب سلوكه استخدام جافاسكربت لتعديل قيمة خواص ARIA عند الضغط. إذا كان من المفترض أن يعرض مفتاح التبديل خيارين بشكلٍ واضح ويمكّنهما: عام وخاص برأيي، عندها سيكون استخدام زوج من أزرار الانتقاء له معنىً كبير. يعلن زري الانتقاء، كلّ منهما بتسمية خاصة به، عن تقنيات جذابة كخيارين منفصلين يجب على المستخدم اختيار أحدهما، وسهلة الوصول تمامًا عبر لوحة المفاتيح، ولا تتطلب ARIA أو جافاسكربت لتعمل، واستخدم قليلًا من الـCSS لها لتخلق تصميم زر "التبديل المزدوج" إذا أردت (حقيقةً لا أعرف ماذا أسميه بشكلٍ آخر) وستكون قمت بكل العمل. قد يختلف قليلًا الترميز والتصميم لمثل هذا الحل بين المطورين، ولكن جوهر الشيفرة سيكون نفسه. وهذا سيقودني إلى التجربة الحية… مثال حيّ هذا تنفيذي لمفتاح تبديل بين خيارين. لقد قمت بإنشاءه ليس كحلّ لمفتاح codepen، لكن ببساطة كمفتاح لتبديل المظهر مضيء/مظلم الذي أستخدمه في حديثي: سيكون مفتاح التبديل في سياق مجموعة أكبر من عناصر النموذج، لهذا السبب ليس لدي أيّ مجموعة حقول (fieldset) أو وسيلة إيضاح (legend) في العرض التجريبي. وأعلم جيّدًا أنّك قد تعدّل الشيفرة لعدم الحاجة إلى عناصر span إضافية في الترميز وتستخدم عناصر زائفة بدلًا منها، ولكنني على أيّة حال قد اخترت هذه الطريقة، فقط لأنني أريدها. جرّب أن تلعب بالشيفرة وتزيل تعليقات بعض التصاميم (حاول إزالة عناصر span بشكلٍ خاص لتشاهد كيف يبدو مفتاحي بدونها) لتحلل الشيفرة وتمتلك فكرة أفضل عن خياراتي وما الذي كنت أحاول تحقيقه. أضفت أيضًا تصميمًا للتأكّد من أنّ مستخدمي لوحة المفاتيح يمكنهم رؤية مكان التركيز، إذ أنني غطيت أزرار الانتقاء الافتراضية بعناصر span، ولم يتم تسليط الضوء على التسميات بشكلٍ افتراضي. استخدمت :focus-visible فقط في البداية (مع polyfill) لكنه لم يعمل كما هو متوقع في متصفحي فايرفوكس وسفاري، لذا انتهيت بإضافة :focus مجددًا واستخدمته بدلًا من :focus-visible. وأعلم أيضًا أنّ تصميم التركيز ليس جميلًا جدًا، لكن هذا العرض التجريبي هو مجرد دليل للمفهوم لذا لا يحتاج أن يكون جميلًا بشكلٍ ملفت للنظر. إذا كنت ترغب في مشاهدة عرض تجريبي آخر يستخدم أيضًا أزرار انتقاء لكن ينفذّها بطريقةٍ مختلفةٍ، بدون عناصر spanواستخدام عناصر زائفة، راجع هذا التصميم على codepen لصديقي Scott O’hara: كلمات أخيرة دعني أبدأ بالقول أنني قد أكون مخطئة. أعلم أنّ مستخدمي codepen قد يريدون شيئًا آخر مختلف تمامًا، أو يفكرون في شيء ما مختلف تمامًا. لذلك لا تهدف هذه المقالة إلى إعادة تصميم زر التبديل في codepen، إنّما تقدم توثيقًا لبحثي وتدريبي على التفكير أثناء العمل على إنشاء زر التبديل الخاص بي لحديثي. سأحتاج أن أقوم بالمزيد من الأبحاث عندما يحين الوقت لمتابعة عملي على ورشة العمل الجديدة الخاصة بي، وقد تتغير الأمور، وأعلم أنني سأتعلّم وأعرف المزيد عندما أنشئ مفتاحي التالي. لكن، حتى ذلك الحين، أعلم أنني حصلت على منشور المدونة هذا للإشارة إلى بعض الأفكار والآراء التي دارت في ذهني عندما اتخذت الخطوة الأولى لذلك. أتمنى أن تجد شيئًا مفيدًا بقراءتك لهذا المقال. إذا حصل ذلك بالفعل، فشكرًا لقراءتك. شكرًا. ترجمة -وبتصرف- للمقال On Designing and Building Toggle Switches لصاحبته Sara Soueidan

…إنّه أصعب مما ظننت اليوم هو أحد تلك الأيام التي بدأت مع بحث غوغل عن سؤال/مسألة أخرى تتعلق بسهولة الوصول (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