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

سنوجّه اهتمامنا في هذا المقال إلى سهولة الوصول أو سهولة الوصول Accessibility -أي شمولية كل المستخدمين وتسهيل وصولهم واستخدامهم الموقع بمن فيهم ذوي الاحتياجات الخاصة- وتوفير معلومات حول المشاكل الشائعة وكيفية إجراء اختبار بسيط والاستفادة من أدوات التدقيق أو الاختبارات الآلي للعثور على مشاكل سهولة الوصول للتوافق مع المتصفحات Cross Browser. المتطلبات الأساسية: يجب أن تتعلم أساسيات لغات HTML وCSS وجافاسكربت JavaScript، وأن يكون لديك فكرة عن المبادئ عالية المستوى لاختبار التوافق مع المتصفحات. الهدف: القدرة على تشخيص مشاكل سهولة الوصول الشائعة واستخدام الأدوات والتقنيات المناسبة لإصلاحها. ما هي سهولة الوصول Accessibility؟ يفكر معظم الناس مباشرةً عندما نقول سهولة الوصول في سياق تقنيات الويب في التأكد من أن مواقع أو تطبيقات الويب يمكن أن يستخدمها الأشخاص ذوي الاحتياجات الخاصة بسهولة مثل: الأشخاص المعاقون بصريًا الذين يستخدِمون قارئات الشاشة أو التكبير أو التقريب للوصول إلى النص. الأشخاص الذين يعانون من إعاقات في الوظائف الحركية ويستخدِمون لوحة المفاتيح (أو ميزات أخرى بدون استخدام الفأرة) لتنشيط وظائف موقع الويب. الأشخاص الذين يعانون من إعاقات سمعية والذين يعتمدون على التسميات أو العناوين التوضيحية أو البدائل النصية الأخرى للمحتوى الصوتي أو الفيديو. لكن من الخطأ القول أنّ سهولة الوصول تتعلق بالإعاقات فقط، فالهدف منها هو جعل مواقع أو تطبيقات الويب يمكن أن يستخدِمها أكبر عدد ممكن من الأشخاص ضمن أكبر عدد ممكن من السياقات، وليس فقط هؤلاء المستخدِمين الذين يستخدِمون حواسيب عالية المواصفات مثل: مستخدِمو الأجهزة المحمولة. مستخدِمو أجهزة تصفح بديلة مثل أجهزة التلفاز والساعات وما إلى ذلك. مستخدِمو الأجهزة القديمة التي يمكن ألّا تحتوي على أحدث المتصفحات. مستخدِمو الأجهزة ذات المواصفات الأقل والتي يمكن أن تحتوي على معالجات بطيئة. يتأكد اختبار التوافق مع المتصفحات Cross Browser Testing من أنّ أكبر عدد ممكن من الأشخاص يستخدِمون موقعك، ويدور هذا المقال بأكمله حول سهولة الوصول، إذ سنغطي التوافق مع المتصفحات المختلفة ومشاكل الاختبار التي تواجه الأشخاص ذوي الاحتياجات الخاصة وكيفية استخدامهم للويب، وتحدثنا سابقًا عن مجالات أخرى مثل التصميم المتجاوب مع الشاشات والأداء. ملاحظة: لا تُعَدّ سهولة الوصول ناجحةً بنسبة 100% مثل العديد من الأشياء الأخرى في عملية تطوير الويب، فمن المستحيل إلى حد كبير تحقيق سهولة الوصول بنسبة 100% لجميع المحتويات خاصةً وأنّ المواقع تصبح أكثر تعقيدًا، وإنما يتعلق الأمر ببذل جهد أكبر لجعل أكبر قدر ممكن من محتواك في متناول أكبر عدد ممكن من الأشخاص من خلال استخدام التكويد الدفاعي Defensive Coding والالتزام بأفضل الممارسات. مشاكل سهولة الوصول الشائعة سنشرح في هذا القسم بالتفصيل بعض مشاكل سهولة الوصول الرئيسية في صفحات الويب والمتصلة بتقنيات محددة إلى جانب أفضل الممارسات التي يجب اتباعها وبعض الاختبارات السريعة التي يمكنك إجراؤها لمعرفة سير موقعك في الاتجاه الصحيح. ملاحظة: تُعَدّ سهولة الوصول أمرًا أخلاقيًا يجب تطبيقه، كما تُعَدّ جيدة للأعمال، إذ يمثِّل عددُ المستخدِمين ذوي الاحتياجات الخاصة والمستخدِمين على الأجهزة المحمولة وغيرهم شرائحًا سوقيةً مهمةً، لكنها تُعَدّ مطلبًا قانونيًا في أجزاء كثيرة من العالم لإنشاء محتوى ويب يمكن أن يصل إليه الأشخاص ذوي الاحتياجات الخاصة. سهولة الوصول في شيفرة HTML يمكن الوصول إلى شيفرة HTML الدلالية حيث تُستخدَم العناصر لغرضها الصحيح مباشرةً، إذ يمكن أن يقرأ المشاهدون المبصرون هذا المحتوى بشرط ألا تفعل شيئًا غير منطقي مثل جعل حجم النص صغيرًا جدًا أو إخفائه باستخدام لغة CSS، ويمكن أن تقرأها التقنيات المساعدة مثل قارئات الشاشة -أي التطبيقات التي تقرأ حرفيًا صفحة الويب لمستخدميها- مع مزايا أخرى. البنية الدلالية أهم مكسب في لغة HTML الدلالية هو استخدام عناوين وفقرات لمحتواك، لأن مستخدِمي قارئات الشاشة يميلون إلى استخدام عناوين المستند بوصفها علامات إرشاديةً للعثور على المحتوى الذي يحتاجون إليه بسرعة أكبر، فإذا لم يتضمن محتواك على عناوين، فكل ما سيحصلون عليه هو جدار نصي ضخم بدون علامات إرشادية للعثور على أيّ شيء، وإليك أمثلة على بينة شيفرة HTML السيئة أولًا: <font size="7">My heading</font> <br><br> This is the first section of my document. <br><br> I'll add another paragraph here too. <br><br> <font size="5">My subheading</font> <br><br> This is the first subsection of my document. I'd love people to be able to find this content! <br><br> <font size="5">My 2nd subheading</font> <br><br> This is the second subsection of my content. I think it is more interesting than the last one. ثم إليك الجيدة: <h1>My heading</h1> <p>This is the first section of my document.</p> <p>I'll add another paragraph here too.</p> <h2>My subheading</h2> <p>This is the first subsection of my document. I'd love people to be able to find this content!</p> <h2>My 2nd subheading</h2> <p>This is the second subsection of my content. I think it is more interesting than the last one.</p> كما يجب أن يكون المحتوى منطقيًا بترتيب المصدر، بحيث يمكنك دائمًا وضعه في المكان الذي تريد استخدام شيفرة CSS فيه لاحقًا، ولكن يجب أن يكون ترتيب المصدر صحيحًا في البداية. يمكنك إيقاف تشغيل شيفرة CSS الخاصة بالموقع للاختبار ومعرفة مدى سهولة فهمه بدون هذه الشيفرة، إذ يمكنك تطبيق هذا الاختبار يدويًا من خلال إزالة شيفرة CSS من شيفرتك البرمجية، ولكن أسهل طريقة هي استخدام ميزات المتصفح، فمثلًا: في فايرفوكس Firefox: حدِّد الخيار عرض View ثم تنسيق الصفحة Page Style ثم بلا تنسيق No Style من القائمة الرئيسية. في سفاري Safari: حدِّد الخيار تطوير Develop ثم إلغاء تفعيل التنسيق Disable Styles من القائمة الرئيسية، حيث يمكن تفعيل قائمة التطوير Develop من خلال تحديد الخيار Safari ثم تفضيلات Preferences ثم خيارات متقدمة Advanced ثم إظهار Show Develop من شريط القوائم. في كروم Chrome: ثبّت الإضافة Web Developer Toolbar، ثم أعد تشغيل المتصفح، وانقر على الرمز الذي يشبه الترس الظاهر، ثم حدِّد الخيار CSS ثم إلغاء تفعيل جميع التنسيقات Disable All Styles. في إيدج Edge: حدِّد الخيار عرض View ثم التنسيق Style ثم بلا تنسيق No Style من القائمة الرئيسية. لمزيد من التفاصيل حول الدلالية في HTML، ارجع إلى مقال مدخل إلى مواصفات ARIA: إعطاء عناصر HTML دلالات خاصة لتسهيل الوصول. سهولة الوصول في استخدام لوحة المفاتيح الأصيلة يمكن تحديد بعض ميزات HTML باستخدام لوحة المفاتيح فقط، حيث يُعَدّ ذلك السلوك الافتراضي المتاح منذ الأيام الأولى للويب، كما أنّ العناصر التي لديها هذه الإمكانية هي العناصر الشائعة التي تسمح للمستخدِم بالتفاعل مع صفحات الويب والروابط والأزرار <button> وعناصر النموذج مثل <input>. يمكنك تجربة ذلك باستخدام المثال native-keyboard-accessibility.html (اطّلع على شيفرته البرمجية)، لذا افتح هذا المثال في تبويب جديد، وحاول الضغط على مفتاح Tab، ويجب أن ترى بعد بضع ضغطات أنّ تركيز التبويب ينتقل بين العناصر المختلفة القابلة للتركيز، وتُعطَى العناصر المركَّزة تنسيقًا افتراضيًا مميزًا في كل متصفح (يختلف قليلًا من متصفح إلى آخر) بحيث يمكنك تحديد العنصر الذي يُركَّز عليه. ملاحظة: في متصفح Firefox يمكنك تفعيل خيار يسمى show tapping order أو ما شابه من ضمن حزمة خيارات سهولة الوصول accessibility لإظهار ترتيب العناصر عند الضغط على مفتاح Tab. يمكنك بعد ذلك الضغط على زر Enter أو Return لاتباع رابط مُركَّز أو الضغط على زر (ضمّنا شيفرة جافاسكربت لجعل الأزرار تعطي رسالة تنبيه) أو البدء في الكتابة لإدخال نص في حقل الإدخال، كما أنّ عناصر النموذج الأخرى لها عناصر تحكم مختلفة، إذ يمكن عرض خيارات العنصر <select> مثلًا والتبديل بينها باستخدام مفتاحَي الأسهم للأعلى وللأسفل. لاحظ أن المتصفحات يمكن أن تحتوي على خيارات تحكم مختلفة في لوحة المفاتيح، إذ تتبع معظم المتصفحات الحديثة نمط الضغط على مفتاح Tab الموضح سابقًا، كما يمكنك الضغط على الاختصار Shift + Tab للانتقال إلى الخلف بين العناصر القابلة للتركيز، ولكن لبعض المتصفحات خصائصها الخاصة مثل: لا يستخدِم متصفح Firefox لنظام التشغيل Mac مفتاح Tab افتراضيًا، لذلك يمكن تشغيله من خلال الانتقال إلى قائمة التفضيلات Preferences ثم خيارات متقدمة Advanced ثم عام General، ثم إلغاء تحديد الخيار "استخدم دائمًا مفاتيح المؤشر للتنقل بين الصفحات Always use the cursor keys to navigate within pages"، كما يجب بعد ذلك فتح تطبيق تفضيلاتك في نظام Mac ثم الانتقال إلى لوحة المفاتيح Keyboard ثم الاختصارات Shortcuts، ثم تحديد زر الاختيار "جميع عناصر التحكم All Controls". لا يسمح لك المتصفح Safari باستخدام مفتاح Tab للتنقل بين الروابط افتراضيًا، ولكن يمكن تفعيل ذلك من خلال فتح تفضيلات Safari، ثم الانتقال إلى الخيارات المتقدمة وتحديد مربع الاختيار "الضغط على مفتاح Tab لتمييز كل عنصر على صفحة الويب Press Tab to highlight each item on a webpage". تحذير: يجب إجراء هذا النوع من الاختبارات أو المراجعات على أيّ صفحة جديدة تكتبها، إذ يجب التأكد من أنّ لوحة المفاتيح تصل إلى وظيفة معينة، وأنّ ترتيب استخدام مفتاح Tab يوفر مسار تنقل جيد عبر المستند. يسلّط هذا المثال الضوء على أهمية استخدام العنصر الدلالي الصحيح مع الوظيفة الصحيحة، ويمكن تصميم أيّ عنصر ليبدو مثل رابط أو زر باستخدام لغة CSS، وأن يتصرف مثل رابط أو زر باستخدام لغة جافاسكربت، لكنها لن تكون روابطًا أو أزرارًا في الواقع، وستفقد كثيرًا من سهولة الوصول التي تمنحك إياها هذه العناصر مجانًا، لذا يمكنك عدم تطبيق ذلك إذا كان بإمكانك تجنبه. يمكنك التحكم في كيفية ظهور العناصر القابلة للتركيز عند التركيز عليها باستخدام الصنف الوهمي ‎:focus، إذ تُعَدّ مضاعفة تنسيقات التركيز Focus والتمرير Hover فكرةً جيدةً، وبالتالي يحصل المستخدِمون على الدليل المرئي بأن عنصر التحكم سيفعل شيئًا ما عند تنشيطه سواءً كانوا يستخدِمون الفأرة أو لوحة المفاتيح. a:hover, input:hover, button:hover, select:hover, a:focus, input:focus, button:focus, select:focus { font-weight: bold; } ملاحظة: إذا قررت إزالة تنسيق التركيز الافتراضي باستخدام شيفرة CSS، فتأكد من استبداله بشيء آخر يناسب تصميمك بصورة أفضل، لإنها أداة سهولة وصول قيّمة للغاية ولا يجب إزالتها. بناء لوحة مفاتيح سهلة الوصول لا يمكن في بعض الأحيان تجنب فقدان سهولة الوصول إلى لوحة المفاتيح، فلنفترض أنك حصلت على موقع لا تكون فيه الدلالات جيدةً جدًا مثل استخدام نظام CMS سيء ينشئ أزرارًا باستخدام عناصر <div>، أو أنك تستخدِم عنصر تحكم معقّد لا يحتوي على سهولة وصول مبنية مسبقًا للوصول إلى لوحة المفاتيح مثل العنصر <video>، ولكن يُعَدّ متصفح أوبرا Opera هو المتصفح الوحيد الذي يسمح لك بالانتقال بين عناصر تحكم المتصفح الافتراضية الخاصة بالعنصر <video> باستخدام مفتاح Tab، ولديك عدد قليل من الخيارات لعناصر التحكم تلك مثل: أنشئ عناصر تحكم مخصَّصة باستخدام عناصر الأزرار <button> -التي يمكننا الانتقال إليها افتراضيًا باستخدام مفتاح Tab- وباستخدام شيفرة جافاسكربت لتوصيل وظائفها. أنشئ اختصارات لوحة المفاتيح باستخدام جافاسكربت، بحيث يمكن تنشيط الوظيفة عند الضغط على مفاتيح معينة على لوحة المفاتيح. استخدِم بعض الأساليب لتزييف سلوك الأزرار، واطّلع على المثال fake-div-buttons.html وعلى شيفرته البرمجية، إذ أعطينا في هذا المثال أزرارَ العنصر <div> المزيفة القدرةَ على التركيز -باستخدام مفتاح Tab مثلًا- من خلال إعطاء كل زر السمة tabindex="0"‎، مما يسمح لنا بالانتقال إلى الأزرار باستخدام مفتاح Tab، ولكن ليس لتنشيطها عبر مفتاح Enter أو Return، إذ يجب في هذه الحالة إضافة الجزء التالي من شيفرة جافاسكربت: document.onkeydown = function(e) { if(e.keyCode === 13) { // ‫مفتاح Enter أو Return document.activeElement.onclick(e); } }; أضفنا هنا مستمعًا إلى الكائن document لاكتشاف وقت الضغط على زر من لوحة المفاتيح، ويمكن التحقق من الزر المضغوط باستخدام الخاصية keyCode الخاصة بكائن الحدث، فإذا كانت الخاصية keyCode هي الخاصية التي تتطابق مع مفتاح Return أو Enter، فسنشغّل الدالة المخزنة في معالج الحدث onclick الخاص بالزر باستخدام document.activeElement.onclick()‎، وتعطينا الخاصية activeElement العنصرَ المُركَّز عليه في الصفحة حاليًا. ملاحظة: لن تعمل هذه التقنية إلا إذا ضبطتَ معالجات الأحداث الأصلية باستخدام خاصيات معالج الأحداث مثل onclick، إذ لن تعمل الخاصية addEventListener، وستظهر كثير من المشاكل الإضافية عند إعادة بناء الوظائف، ولا بدّ أن تكون هناك مشاكل أخرى معها، لذا يُفضَّل استخدام العنصر المناسب مع الوظيفة المناسبة من البداية. النصوص البديلة تُعَدّ النصوص البديلة مهمةً جدًا لسهولة الوصول فإذا عانى المستخدِم من إعاقة بصرية أو سمعية تمنعه من رؤية أو سماع بعض المحتوى، فهذه مشكلة، وأبسط نص بديل متاح هو السمة alt والتي يجب أن نضعها في جميع الصور التي تحتوي على محتوى ذي صلة بالنص البديل، إذ يجب أن تحتوي السمة alt على وصف الصورة الذي ينقل المعنى والمحتوى بنجاح على الصفحة لتلتقطها قارئات الشاشة وتقرأها للمستخدِم، كما يمكن اختبار النص البديل المفقود بعدة طرق مثل استخدام أدوات تدقيق سهولة الوصول Accessibility Auditing. يُعَدّ النص البديل أكثر تعقيدًا إلى حد ما للمحتوى الصوتي والفيديو، فهناك طريقة لتحديد مسارات النص -مثل النصوص التوضيحية Subtitles- وعرضها عند تشغيل الفيديو بصيغة العنصر <track> وبتنسيق WebVTT، كما يُعَدّ توافق المتصفح مع هذه الميزات جيدًا إلى حد ما، ولكن إذا أردت توفير بدائل نصية للصوت أو دعم المتصفحات القديمة، فيمكن أن يكون عرض نسخة صوتية بسيطة في مكان ما على الصفحة أو على صفحة منفصلة فكرةً جيدةً. علاقات وسياق العنصر توجد ميزات معينة وممارسات أفضل في لغة HTML مصمَّمة لتوفير السياق والعلاقات بين العناصر حيث لا توجد طريقة أخرى لذلك، والأمثلة الثلاثة الأكثر شيوعًا لذلك هي الروابط وتسميات أو عناوين Labels النماذج وجداول البيانات. الفاصل في أن يكون نص الرابط سهل الوصول هو أن يستخدِم مستخدِمو قارئات الشاشة ميزةً شائعةً حيث يسحبون قائمةً بجميع الروابط على الصفحة، لذا يجب أن يكون نص الرابط منطقيًا في هذه الحالة، إذ تُعَدّ قائمة الروابط المسماة "انقر هنا" مثلًا سيئةً في تحقيق سهولة الوصول، إذ يُفضَّل أن يكون نص الرابط منطقيًا ضمن السياق وخارجه. يُعَدّ عنصر النموذج <label> أحد الميزات المركزية التي تجعل النماذج شاملة، وتكمن مشكلة النماذج في أنك بحاجة إلى تسميات <label> توضّح البيانات التي يجب إدخالها في كل حقل إدخال في النموذج، كما يجب تضمين كل تسمية ضمن العنصر <label> لربطها بوضوح بحقل الإدخال المقابل لها في النموذج، إذ يجب أن تتطابق السمة for الخاصة بالعنصر <label> مع قيمة معرّف id عنصر النموذج، وسيكون ذلك منطقيًا حتى لو لم يكن ترتيب المصدر منطقيًا تمامًا. يمكن كتابة جدول البيانات الأساسي باستخدام توصيف بسيط جدًا (اطلع على المثال bad-table.html مباشرةً وشيفرته البرمجية)، ولكن توجد مشاكل في هذا المثال، إذ لا توجد طريقة لمستخدِم قارئ الشاشة لربط الصفوف أو الأعمدة معًا بوصفها مجموعات من البيانات، لذا يجب معرفة ما هي صفوف العناوين، وما إذا كانت عناوينًا للصفوف أو للأعمدة وما إلى ذلك، إذ لا يمكن تطبيق ذلك إلّا بطريقة مرئية لمثل هذا الجدول. إذا اطّلعت على المثال punk-bands-complete.html مباشرةً أو اطّلعت على شيفرته البرمجية، فيمكنك رؤية بعض أدوات سهولة الوصول المساعدة مثل عناوين الجدول (العنصر <th> والسمات scope) والعنصر <caption>. سهولة الوصول في شيفرة CSS توفّر لغة CSS ميزات سهولة الوصول الأساسية بمقدار أقل بكثير من لغة HTML، ولكن لا تزال بإمكانها إحداث القدر نفسه من الضرر لسهولة الوصول إذا استخدِمت بطريقة غير صحيحة، وإليك بعض النصائح المتعلقة بسهولة الوصول المتضمنة في شيفرة CSS: استخدِم العناصر الدلالية الصحيحة لكتابة محتوًى مختلف في شيفرة HTML، فإذا أردت إنشاء تأثير مرئي مختلف، فاستخدم شيفرة CSS دون العبث بعنصر HTML للحصول على الشكل الذي تريده، فإذا أردت نصًا أكبر، فاستخدم الخاصية font-size وليس العنصر <h1>. تأكد من أنّ ترتيب المصدر منطقي بدون شيفرة CSS، إذ يمكنك دائمًا استخدام CSS لتنسيق الصفحة بالطريقة التي تريدها بعد ذلك. يجب عليك التأكد من أنّ العناصر التفاعلية مثل الأزرار والروابط لها حالات تركيز أو تمرير أو تنشيط مناسبة لإعطاء المستخدِم أدلة مرئية عن وظيفتها، فإذا أزلتَ الإعدادات الافتراضية لأسباب تتعلق بالتنسيق، فتأكد من تضمين بعض التنسيقات البديلة. الألوان وتباينها يجب أن تتأكد من أنّ لون النص (المقدمة) متباين جيدًا مع لون الخلفية عند اختيار نظام ألوان موقع الويب، فيمكن أن يكون تصميمك رائعًا، ولكنه ليس جيدًا إذا لم يستطع الأشخاص الذين يعانون من إعاقات بصرية مثل عمى الألوان قراءة محتوى موقعك، لذا استخدِم أداةً مثل الأداة Color Contrast Checker من WebAIM للتحقق مما إذا كان نظام ألوانك متباينًا بدرجة كافية. لا تعتمد على الألوان وحدها لإظهار الإشارات الدلالية أو المعلومات، لأنها لن تكون مفيدةً لمن لا يستطيعون رؤيتها، لذا ميّز مثلًا حقول النموذج الإلزامية بعلامة النجمة واللون الأحمر بدلًا من تميزها باللون الأحمر فقط. ملاحظة: تسمح نسبة التباين العالية لأيّ شخص يستخدِم هاتفًا ذكيًا أو جهازًا لوحيًا بقراءة الصفحات بصورة أفضل عندما يكون في بيئة مضاءة مثل ضوء الشمس. إخفاء المحتوى هناك العديد من الحالات التي يتطلب فيها التصميم المرئي عدم عرض كل المحتوى دفعةً واحدةً، فلدينا مثلًا ثلاث لوحات من المعلومات في مثال مربع المعلومات المبوب (اطّلع على شيفرته البرمجية)، لكننا نضعها فوق بعضها البعض ونوفّر تبويبات يمكن النقر عليها لإظهار محتواها، ويمكن الوصول إليها من خلال لوحة المفاتيح أو يمكنك استخدام مفتاح Tab و Enter/Return لتحديدها. لا يهتم مستخدِمو قارئات الشاشة بهذا الشيء، فهم سعداء بالمحتوى طالما أنّ ترتيب المصدر منطقي ويمكنهم الوصول إليه، كما يُنظَر إلى الموضع المطلق Absolute Positioning -كما هو مستخدَم في مثالنا- على أنه أحد أفضل آليات إخفاء محتوى التأثيرات المرئية، لأنه لا يمنع قارئات الشاشة من الوصول إلى هذا المحتوى، ولا يجب من ناحية أخرى استخدام الخاصيتين visibility:hidden و display:none لأنهما تخفيان المحتوى عن قارئات الشاشة ما لم يكن هناك سبب وجيه لإخفاء هذا المحتوى عنها. مشاكل سهولة الوصول المتعلقة بشيفرة جافاسكربت تمتلك شيفرة جافاسكربت النوع نفسه من المشاكل التي تواجهها في شيفرة CSS فيما يتعلق بسهولة الوصول، إذ يمكن أن تكون شيفرة جافاسكربت كارثيةً بالنسبة لسهولة الوصول إذا استخدِمت بطريقة سيئة أو مفرطة، وقد أشرنا سابقًا إلى بعض مشاكل سهولة الوصول المتعلقة بشيفرة جافاسكربت خاصةً في شيفرة HTML الدلالية، إذ يجب دائمًا استخدام شيفرة HTML دلالية مناسبة لتنفيذ الوظائف أينما كانت متاحةً مثل استخدام الروابط والأزرار حسب الحاجة، كما لا تُستخدَم عناصر <div> مع شيفرة جافاسكربت لتزييف الوظائف إذا كان ذلك ممكنًا، فهي عرضة للخطأ وتحتاج عملًا أكثر من استخدام الوظائف المجانية التي توفرها شيفرة HTML. الوظائف البسيطة يجب أن تعمل الوظائف البسيطة باستخدام شيفرة HTML فقط، إذ يجب استخدام شيفرة جافاسكربت لتحسين الوظائف فقط، وليس لبنائها بالكامل، وتشمل الاستخدامات الجيدة لشيفرة جافاسكربت ما يلي: توفير التحقق من صحة النموذج من طرف العميل الذي ينبّه المستخدِمين بالمشاكل المتعلقة بإدخالات النماذج بسرعة دون الحاجة إلى الانتظار حتى يتحقق الخادم من البيانات، فإذا لم يكن ذلك متاحًا، فسيبقى النموذج يعمل بنجاح، ولكن يمكن أن يكون التحقق من صحته أبطأ. توفير عناصر تحكم مخصصة لعناصر <video> التي يمكن أن يصل إليها مستخدِمو لوحة المفاتيح فقط، إذ لا يمكن الوصول إلى عناصر التحكم الافتراضية في المتصفح من خلال لوحة المفاتيح في معظم المتصفحات. يمكن أن تؤدي تطبيقات جافاسكربت الأكثر تعقيدًا إلى حدوث مشاكل في سهولة الوصول، لذا يجب أن تفعل ما بوسعك، فليس معقولًا مثلًا أن تتوقع إنشاء لعبة ثلاثية الأبعاد معقدة مكتوبة باستخدام واجهة WebGL يمكن أن يصل إليها شخص كفيف بنسبة 100%، ولكن يمكنك تنفيذ عناصر تحكم لوحة المفاتيح بحيث يمكن أن يستخدمها المستخدمِون الذين لا يستعملون الفأرة، وجعل نظام الألوان متباينًا بدرجة كافية ليتمكّن الأشخاص الذين يعانون من عمى الألوان من الوصول إليها. الوظائف المعقدة تُعَدّ التطبيقات المعقدة التي تتضمن عناصر تحكم معقدة في النماذج (مثل عنصر اختيار التاريخ Date Pickers) وتتضمن المحتوى الديناميكي الذي يُحدَّث بصورة متكررة ومتزايدة أحدَ المجالات الرئيسية التي تمثِّل مشكلة لسهولة الوصول. تمثِّل عناصر التحكم المعقدة غير الأصيلة في النموذج مشكلةً لأنها تتضمّن الكثير من عناصر <div> المتداخلة، ولا يعرف المتصفح ما يجب فعله بها افتراضيًا، فإذا أنشأت عناصر التحكم المعقدة بنفسك، فيجب التأكد من أنه يمكن الوصول إليها من خلال لوحة المفاتيح، وإذا استخدَمت إطار عمل خارجي، فراجع بعناية الخيارات المتاحة لمعرفة مدى إمكانية الوصول إليها قبل المتابعة، ويبدو إطار عمل Bootstrap على سبيل المثال جيدًا إلى حد ما لعملية سهولة الوصول بالرغم من بعض مشاكله التي تتعلق بتباين الألوان بصورة أساسية. يمكن أن يمثل المحتوى الديناميكي المُحدَّث بانتظام مشكلةً لأن مستخدِمي قارئات الشاشة يمكن أن يفوتهم ذلك خاصةً إذا جرى تحديثه بطريقة غير متوقعة، فإذا كان لديك تطبيق مؤلف من صفحة واحدة مع لوحة محتوى رئيسية يُحدَّث بانتظام باستخدام XMLHttpRequest أو Fetch، فيمكن أن يفوّت مستخدِمو قارئات الشاشة هذه التحديثات. WAI-ARIA إذا احتجتَ استخدام مثل هذه الوظائف المعقدة أو احتاجتها شيفرة HTML الدلالية القديمة، فعليك التفكير في استخدام مواصفات WAI-ARIA (تطبيقات الإنترنت الغنية سهلة الوصول Accessible Rich Internet Applications)، وهي مواصفات توفر دلالات Semantics بصورة سمات HTML جديدة لعناصر مثل عناصر التحكم المعقدة في النموذج ولوحات التحديث التي يمكن أن تفهمها معظم المتصفحات وقارئات الشاشة. يمكن التعامل مع عناصر النماذج المعقدة من خلال استخدام سمات ARIA مثل السمة roles لتحديد الدور الذي تلعبه العناصر المختلفة في عنصر واجهة المستخدِم (مثل هل هو تبويب أم لوحة تبويب؟)، والسمة aria-disabled التي تخبرنا فيما إذا كان عنصر التحكم معطلًا أم لا. يمكن التعامل مع مناطق المحتوى المحدّثة بانتظام من خلال استخدام السمة aria-live التي تحدد منطقة التحديث، وتشير قيمتها إلى مدى ضرورة أن يقرأ قارئ الشاشة هذا المحتوى، حيث يمكن أن تكون قيمتها إحدى القيم التالية: off: القيمة الافتراضية التي تمثّل أنه لا ينبغي الإعلان عن التحديثات. polite: يجب الإعلان عن التحديثات فقط إذا كان المستخدِم خاملًا. assertive: يجب الإعلان عن التحديثات للمستخدِم في أسرع وقت ممكن. rude: يجب الإعلان عن التحديثات مباشرةً حتى إذا تسبب ذلك في مقاطعة المستخدِم. إليك المثال التالي: <p><span id="LiveRegion1" aria-live="polite" aria-atomic="false"></span></p> يمكنك رؤية المثال العملي ARIA (Accessible Rich Internet Applications) Live Regions في موقع Freedom Scientific، حيث يجب أن تحدَّث الفقرة المُحدَّدة محتواها كل 10 ثوانٍ، ويجب على قارئ الشاشة قراءة ذلك للمستخدِم، ويمثل المثال ARIA Live Regions - Atomic مثالًا آخر مفيدًا. الخلاصة اطلعنا في هذا المقال على كيفية اختبار مشاكل سهولة الوصول الرئيسية التي يمكن أن تواجهها من أجل التغلب عليها، وسنلقي نظرةً في المقال التالي على أهم الأدوات اللازمة لتحقيق سهولة الوصول والتغلب على تلك المشاكل. ترجمة -وبتصرُّف- لقسم من المقال Handling common accessibility problems. اقرأ أيضًا المقال السابق: معالجة المشاكل الشائعة للتوافق مع المتصفحات في شيفرة جافاسكربت سهولة وصول جميع الزوار لمواقع وتطبيقات الويب سهولة الوصول في CSS شمولية التصميم: سهولة وصول جميع المستخدمين لصفحات موقع الويب

يكون الويب موجهًا للجميع عند تصميمه تصميمًا جيدًا، ولكن التصميم السيئ سيشكّل حاجزًا، مما يؤدي إلى الإخفاق ومنع الوصول والفشل في تمثيل الأفراد وحرمان المجموعات من حقوقها. يدرك الويب إمكانياته المتمثلة في العمل من أجل جميع الأشخاص -أي إمكانية الوصول وقابلية الاستخدام والشمولية-، وذلك عندما ينجح المصممون والمطورون في عملهم. يبدأ التطوّر من خلال الوضوح والتفاهم المشترك، ولكن الناس يبدّلون في عالم التصميم الرقمي وتجربة المستخدم بين المصطلحات، مما يشوّش المختصين في هذا المجال، مثلما يحدث عندما يشير العملاء إلى تجربة المستخدم UX على أنها واجهة المستخدم UI، أو عند استخدام مبدأ أجايل Agile على أنه عملية تطوير البرامج بسرعة مثلًا. وقد أدى الاستخدام غير الرسمي للمصطلحات غير الدقيقة المتعلقة بإمكانية الوصول accessibility والشمولية inclusivity إلى حدوث ارتباك يمتد إلى عالم التصميم، فهناك أوجه تشابه وتداخل بين المصطلحَين، مع وجود اختلافات رئيسية. يشرح هذا المقال الفرق بين هذين المصطلحين وأهميتهما للعاملين في مجال التصميم والتطوير. تعريف إمكانية الوصول والشمولية والاختلاف بينهما تضمن إمكانية الوصول Accessibility أن يتمكّن أيّ شخص من الوصول إلى تجربة أو وظيفة بغضّ النظر عن قدرته، إذ يركّز التعريف التقليدي لإمكانية الوصول الرقمية على تلبية احتياجات الأشخاص ذوي الإعاقة عند استخدام موقع ويب أو تطبيق أو نظام رقمي. تحدّد الإرشادات مثل إرشادات إمكانية الوصول إلى محتوى الويب في W3C، المعاييرَ التقنية والبرمجية والتفاعلية والتصميمية، مثل نسب تباين الألوان وأهداف اللمس وأحجام الخطوط والنص البديل والتنقّل باستخدام لوحة المفاتيح وما إلى ذلك، وتضمن تلبية هذه المتطلبات للأفراد الذين يعانون من إعاقات في النطق أو السمع أو البصر أو الحركة أن يفهموا ويتفاعلوا ويتنقّلوا دون عوائق بغض النظر عن قدرتهم. تستند هذه الإرشادات إلى مبادئ W3C الأربعة لإمكانية الوصول وهي: قابلية الإدراك Perceivable: يجب أن تكون المعلومات ومكونات واجهة المستخدم قابلةً للعرض على المستخدمين بطرقٍ يمكن إدراكها، حيث يمكن للشخص المصاب بإعاقة بصرية قراءة المحتوى باستخدام قارئ شاشة، أو يمكن توفير نصوص الأصوات التوضيحية للشخص الأصم. قابلية التشغيل Operable: يجب أن تكون مكونات واجهة المستخدم والتنقل قابلةً للتشغيل، إذ يجب أن يكون الأشخاص قادرين على التفاعل مع المحتوى المُدرَك سواءً عن طريق لوحة المفاتيح أو الصوت أو الفأرة أو اللمس. إمكانية الفهم Understandable: يجب أن تكون معلومات واجهة المستخدم وتشغيلها مفهومَين، حيث يجب أن يكون المستخدمون قادرين على فهم العرض المُقدَّم. المتانة Robust: يجب أن يكون المحتوى متينًا بدرجة كافية، بحيث يمكن تفسّره مجموعة متنوعة من وكلاء المستخدم بما في ذلك التقنيات المساعدة تفسيرًا موثوقًا، إذ يجب أن يكون المستخدمون قادرين على الوصول إلى المحتوى حتى في حالة تطور التقنيات. قد يكون بعض الأشخاص على دراية بمبادئ وإرشادات إمكانية الوصول السابقة، ولكنهم قد لا يكونون على دراية بمستويات التوافق conformance المختلفة، حيث يحدد كل مستوى بوضوح المتطلبات التي يمكن تطبيقها ومراقبتها وهي: المستوى A: وهو المستوى الأدنى من خلال تلبية جميع متطلبات إمكانية الوصول الأساسية. المستوى AA: يتمثّل بتلبية متطلبات إمكانية الوصول متوسطة المستوى، وهو المستوى الذي تهدف الشركات إلى الوصول إليه. المستوى AAA: وهو تلبية أكبر عدد من المتطلبات، ويتضمّن المستويات A وAA وAAA. تؤثّر المكونات المتعددة التي يجب أن تعمل جميعها معًا على إمكانية الوصول، مثل مكونات محتوى الويب بما في ذلك العناصر الموجودة على الشاشة وخارجها والشيفرة البرمجية، حيث تؤثر هذه المكونات على طريقة الوصول إلى المحتوى مثل المتصفحات والصوت والمشغّلات والبرمجيات، وعلى طريقة الإنتاج مثل البرمجيات والخدمات وأدوات التأليف authoring tools وأنظمة إدارة المحتوى وسكربتات التشغيل وغيرها. تتعلق معايير إمكانية الوصول إلى حد كبير بمعمارية وتنسيق المعلومات وكيفية تقديمها، ولكنها لا تتعلق بالمعلومات بحد ذاتها، إذ قد تكون الكلمات والصور ومقاطع الفيديو عديمة القيمة أو مسيئةً أو تمييزيةً أو متحيزة، ولكن لا يزال يمكن الوصول إليها. لا يضمن اتباع أفضل الممارسات المتعلقة بإمكانية الوصول شعور الأشخاص بأنهم ممثَّلون ويريدون استخدام شيء ما أو الإعجاب به، فهذا هو المجال الذي يناسبه اتباع نهج التصميم الشامل. التصميم الشامل Inclusive Design: من القدرات إلى وجهات النظر تسعى الشمولية إلى إنشاء شيء يمكن لجميع الأشخاص استخدامه مع وجود الرغبة في استخدامه أيضًا، وهي تشمل الأشخاص ذوي القدرات المختلفة إلى جانب الأقليات والسكان المتنوعين.يُعَد التصميم الشامل نهج تصميمٍ يأخذ في الحسبان تنوع سمات الأشخاص وخبراتهم وأحوالهم، مثل: الجنس. العمر. الموقع. الحضارة. اللغة. التعليم والثقافة. الكفاءة والخبرة التقنية. العوامل الاجتماعية والاقتصادية. البيئة الفيزيائية. التقنية والأجهزة والاتصالات. تعرِّف مايكروسوفت Microsoft التصميم الشامل بأنه منهجيةٌ نشأت من البيئات الرقمية، حيث تتيح هذه المنهجية مجال التنوع البشري الكامل وتعتمد عليه، وهذا يعني تضمين الأشخاص الذين لديهم مجموعةً من وجهات النظر والتعلم منهم. يكون الهدف من التصميم الشامل هو إنتاج موقع ويب أو واجهة أو منتج رقمي يمكن استخدامه على أوسع نطاقٍ ممكن، وذلك بغض النظر عن الحالة أو القدرة. لا يحتوي التصميم الشامل على قواعد موثَّقة أو إطار عمل محدَّد، على عكس التصميم الذي يمكن الوصول إليه، والذي حدد المتطلبات والإرشادات، لأن التصميم الشامل يركّز على عملية صنع التصميم الذي سيرغب الجميع في استخدامه، فهو أكثر عاطفيةً وأقل منطقية، وبالتالي لا يوجد نهج قابل للتطبيق عالميًا ومناسبٌ للجميع، إذ قد يتضمن التصميم الناتج حلولًا مختلفة. كتبت خبيرة ورائدة التصميم الشامل سوزان جولتسمان Susan Goltsman: وهذا يطرح سؤالين مرتبطين وهما: السؤال الأول: هل التصميم الذي يمكن الوصول إليه شامل، وهل يمكن الوصول إلى تصميم شامل؟ يمكن أن يدعم التصميم الذي يمكن الوصول إليه جوانب التصميم الشامل، ولكن تركيزه الأساسي سينصبّ على معالجة الإعاقات وليس على الانتماء الأوسع، بينما يفيد التصميم الشامل جميع المستخدمين سواء كانوا يعانون من إعاقة أم لا. يجب أن تؤدي عملية التصميم الشامل إلى تصميم يمكن الوصول إليه، ولكن ليست التصاميم التي يمكن الوصول إليها شاملةً دائمًا. السؤال الثاني: هل التنوع diversity يعني الشمول inclusion، وهل التصميم لأحدهما يضمن كليهما؟ يشير التنوع إلى أوجه التشابه أو الاختلاف بين الأفراد فيما يتعلق بالتركيبة السكانية وخصائص هويتهم، مثل الهوية الجنسية والعمر والعرق. من بين الأمثلة التي يمكن أن يعتمدها المصممون، نجد اختيار صور متنوعة مثل الصور الفوتوغرافية لأشخاص ليسوا سليمي البنية أو ان لديهم صفة مختلفة عن العادة، وذلك للابتعاد عن الصور النمطية؛ بينما بالنسبة لصانعي المحتوى، فإن استخدام الضمائر المحايدة بين الجنسين أو الشاملة في الكتابة أو استخدام لغة الشخص الأول person-first language من شأنه أن يأخذ التنوع في الحسبان. يمثّل التنوع الاختلاف بين الأفراد، بينما تمثّل الشمولية طريقة احتضان الأفراد ذوي الهويات المتنوعة وإدماجهم. أسباب أهمية إمكانية الوصول والشمولية يريد معظمنا عالمًا يحقق المساواة ويتيح الفرص نفسها للجميع، فالشيء العادل والصحيح الذي ينبغي عمله هو أن يتمتع كل شخص بوصول متساوٍ إلى المعلومات والخبرات الرقمية. ولكن إن لم تلتزم القيادة أو المالكون بالأخلاق وحدها في عالمٍ يكون فيه المال أكثر أهمية من الأشخاص، فإليك كيفية تأثير هذه المفاهيم أو تجاهلها على المحصلة النهائية. تقليل المخاطر تتعرض الشركات لخطر أن تكون هدفًا لدعاوى قضائية عندما يتعذر الوصول إلى التصاميم، وتتزايد الدعاوى القضائية بسبب عدم الامتثال لقانون الأمريكيين ذوي الإعاقة والمادة 508، فإذا تعذّر الوصول إلى شيءٍ ما، فهذا يمثّل تمييزًا. خلق قيمة للأعمال تخلق المنتجات الأفضل مزيدًا من القيمة، فإن لبَّت مواقع الويب أو التطبيقات أو الحلول الرقمية مزيدًا من احتياجات الأشخاص، فستتمتع بجاذبية أوسع وستستهدف مزيدًا من الأسواق، وكلما زاد عدد الأشخاص الذين يمكنهم استخدام المنتج، زادت احتمالية النجاح والربح. تحسين رضا العملاء يُعَد الاحتفاظ بالمستخدمين والعملاء أسهل من اكتساب عملاء جدد، وتزداد احتمالية رضا العملاء واستمرار عودتهم إليك من خلال فهم واحتضان ومعالجة تنوع قاعدة المستخدمين، وهذا مفيدٌ للأفراد والشركات. اتخاذ الإجراءات التي يمكن أن ينفذها مجتمع تجربة المستخدم UX يعرف المبتدئون والخبراء في تجربة المستخدم UX على حد سواء أن هناك دائمًا فرصة لجعل الأمور أسهل وأكثر فاعليةً وجاذبية. إليك كيفية البدء في إنشاء تصميمات ذات إمكانية وصول وشمولية أكبر: تحديد الأهداف والأولويات التي تتعلق بإمكانية الوصول أو الشمولية بناءً على جمهور المشروع وأهدافه وموارده. الاستفادة من الإرشادات والأدوات الراسخة لتحديد مجالات التحسين وتتبّع التقدم. التوظيف والتعاون والاختبار مع مستخدمين متنوعين لفهمٍ أفضل للتحديات والفرص. الاستمرار في استخدام مناهج وتقنيات تجربة المستخدم التي أثبتت جدواها مثل إجراء البحوث واستخدام الشخصيات personas ذات الصلة والتخطيط العاطفي empathy mapping وتحديد حالات الاستخدام والاختبارات التكرارية. طلب المساعدة من الخارج من خلال جلب الخبراء، أو استخدام الخدمات الخارجية لتقييم إمكانية الوصول أو مراجعات الشيفرة البرمجية أو اختبار المستخدم. بناء الفرق المتنوعة التي ستؤثر هوياتها ووجهات نظرها وخبراتها المختلفة على التصميمات. لا يمكن تحسين التجربة لكل مستخدم، ولكن يمكن تطبيق شيءٍ ما لجذب مزيدٍ من الأشخاص عند اقترابهم من التصميم، فهناك دائمًا طريقة لتحسين التجربة وتحقيق نتائج أفضل. مصادر التصاميم التي تتمتع بإمكانية الوصول والشمولية معايير W3C لإمكانية الوصول. قائمة أدوات إمكانية الوصول الخاصة بالويب في W3C. تطوير جوجل لإمكانية الوصول. أداة فحص إمكانية الوصول من أدوبي. إضافات إمكانية الوصول من ووردبريس. مجموعة أدوات التصميم الشامل من مايكروسوفت. دليل التصميم الشامل من مركز الأبحاث الشامل. فيديو جون مايدا John Maeda: تصميم فرق ومنتجات شاملة، تصميم من أجل التنوع. ترجمة -وبتصرّف- للمقال Accessibility and Inclusivity: Distinctions in Experience Design لصاحبته Jennifer Leigh Brown. اقرأ أيضًا تصميم تجربة تهيئة المستخدم User Onboarding الكتابة لتجربة المستخدم UX Writing أساس التهيئة الفعالة للواجهات ما هي الكتابة لتجربة المستخدم UX Writing؟ تاريخ موجز عن تجربة المستخدم