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

لقد غطينا في المقال السابق معالجة مشاكل سهولة الوصول Accessibility الشائعة للتوافق مع المتصفحات أهم أفكار سهولة الوصول الخاصة بتقنيات الويب المختلفة بما في ذلك بعض تقنيات الاختبار مثل التنقل باستخدام لوحة المفاتيح وأدوات فحص تباين الألوان، وسنلقي نظرةً الآن على الأدوات الأخرى التي يمكنك الاستفادة منها عند إجراء اختبار سهولة الوصول. أدوات التدقيق Auditing Tools هناك عدد من أدوات التدقيق المتاحة التي يمكنك استخدامها في صفحات الويب، حيث ستلقي هذه الأدوات نظرةً على الصفحات وتعيد قائمةً بمشاكل سهولة الوصول الموجودة فيها، ومن هذه الأدوات ما يلي: Wave: تُعَدّ أداةً جيدةً لاختبار سهولة الوصول عبر الإنترنت، حيث تأخذ عنوان ويب وتعيد عرضًا توضيحيًا مفيدًا لتلك الصفحة مع إبراز مشاكل سهولة الوصول. Tenon: تُعَدّ أداةً جيدةً أخرى عبر الإنترنت تراجِع الشيفرة البرمجية من عنوان URL المُقدَّم وتعرض نتائجًا عن أخطاء سهولة الوصول بما في ذلك المقاييس والأخطاء المحددة باستخدام معايير WCAG التي تؤثر عليها والإصلاحات المقترحة، ولكنها تتطلب تسجيلًا تجريبيًا مجانيًا لعرض النتائج. tota11y: تُعَدّ أداةً سهولة وصول من Khan Academy تتخذ شكل مكتبة جافاسكربت التي ترفقها مع صفحتك لتوفير عدد من أدوات سهولة الوصول. لنلقِ نظرةً على مثال باستخدام أداة Wave: انتقل إلى صفحة Wave الرئيسية. أدخِل عنوان URL الخاص بالمثال bad-semantics.html في مربع إدخال النص بالقرب من أعلى الصفحة، ثم اضغط على مفتاح Enter أو انقر/اضغط على السهم في أقصى يمين مربع الإدخال. يجب أن يستجيب الموقع مع إعطاء وصف بمشاكل سهولة الوصول، وانقر على الرموز المعروضة لمعرفة المزيد من المعلومات حول كلٍّ من المشاكل التي حددها تقييم أداة Wave. ملاحظة: لا تُعَدّ هذه الأدوات جيدةً بما يكفي لحل جميع مشاكل سهولة الوصول، لذا ستحتاج إلى مزيج من المعرفة والخبرة واختبار المستخدِمين وغير ذلك للحصول على صورة كاملة. أدوات الاختبارات الآلية تذهب أداة Deque's aXe إلى أبعد قليلًا من أدوات التدقيق التي ذكرناها سابقًا، إذ تفحص الصفحات وتعيد أخطاء سهولة الوصول، كما يُحتمَل أن يكون شكلها الأكثر فائدةً هو إضافات المتصفح التالية: aXe للمتصفح Chrome. aXe للمتصفح Firefox. تضيف هذه الإضافات تبويب سهولة الوصول "Accessibility" إلى أدوات المطور في المتصفح، وقد ثبّتنا إصدار Firefox مثلًا، ثم استخدمناه لتدقيق المثال bad-table.html، وحصلنا على النتائج التالية: كما يمكن تثبيت الأداة aXe باستخدام npm ويمكن دمجها مع مشغّلات المهام مثل Grunt و Gulp وأطر العمل الآلية مثل Selenium و Cucumber وأطر اختبار الوحدات مثل Jasmine. قارئات الشاشة يجب بالتأكيد إجراء الاختبار باستخدام قارئات الشاشة لتعتاد على كيفية استخدام الأشخاص الكفيفين للويب، ويتوفر عدد من قارئات الشاشة مثل: بعض المنتجات التجارية المدفوعة مثل JAWS و Window Eyes (لنظام Windows). بعض المنتجات المجانية مثل NVDA (لنظام Windows) و ChromeVox (للمتصفح Chrome ونظامَي Windows و Mac OS X) و Orca (لنظام لينكس Linux). بعض المنتجات المدمَجة مع نظام التشغيل مثل VoiceOver (على نظام Mac OS X و iOS) و ChromeVox (على أجهزة Chromebook) و TalkBack (على نظام Android). تُعَدّ قارئات الشاشة عمومًا تطبيقات منفصلةً تعمل على نظام التشغيل المضيف ولا يمكنها قراءة صفحات الويب فحسب، وإنما يمكنها قراءة النصوص في التطبيقات الأخرى، ويمكن أن يكون بعضها إضافةً لمتصفح مثل ChromeVox، وتتصرف قارئات الشاشة بطرق مختلفة قليلًا ولديها عناصر تحكم مختلفة، لذا يجب الرجوع إلى الوثائق الخاصة بقارئ الشاشة الذي اخترته للحصول على جميع التفاصيل، ولكن يمكن القول بأن التفاصيل الأساسية لطريقة عملها واحدة. لنطبّق بعض الاختبارات باستخدام بعض قارئات الشاشة المختلفة لإعطائك فكرةً عامةً عن كيفية عملها وكيفية الاختبار باستخدامها. إضافة: توفر منظمة WebAIM معلومات دورية مفيدة حول التصميم الأمثل لقارئات الشاشة وتحقيق التوافقية معها بالإضافة إلى معلومات موسعة حول عن استخداماتها وما الحلول التي تتلاءم معها وبعض الإحصائيات المفيدة عنها. قارئ الشاشة VoiceOver يأتي قارئ الشاشة VoiceOver -أو VO اختصارًا- مجانًا مع جهاز Mac أو iPhone أو iPad، لذا فهو مفيد للاختبار على الحاسوب أو الهاتف المحمول إذا أردت استخدام منتجات Apple، إذ سنختبره على نظام Mac OS X على جهاز MacBook Pro. يمكنك تشغيل هذا البرنامج من خلال الضغط على الاختصار Cmd + F5، فإذا لم تستخدِم VO سابقًا، فستظهر شاشة ترحيب حيث يمكنك اختيار بدء تشغيل VO أو عدم تشغيله، وتشغيل برنامج تعليمي مفيد إلى حد ما لمعرفة كيفية استخدامه، ويمكنك إيقاف تشغيله من خلال الضغط على الاختصار Cmd + F5 مرةً أخرى. ستبدو الشاشة نفسها عند تشغيل VO، ولكنك سترى مربعًا أسودًا في الجزء السفلي الأيسر من الشاشة يحتوي على معلومات حول ما هو مُحدَّد حاليًا، كما سيُميَّز التحديد الحالي بحدود سوداء، ويُعرَف هذا التمييز بمؤشر VO. ستستفيد كثيرًا من معدِّل VO لاستخدام قارئ الشاشة VO، إذ يُعَدّ المعدِّل Modifier مفتاحًا أو مجموعة مفاتيح يجب الضغط عليها بالإضافة إلى اختصارات VO من لوحة المفاتيح الفعلية لجعلها تعمل، كما يُعَدّ استخدام المعدل بهذه الطريقة أمرًا شائعًا مع قارئات الشاشة من أجل ألّا تتعارض أوامرها مع الأوامر الأخرى، ويمكن أن يكون المعدِّل في حالة VO المفتاح CapsLock أو Ctrl + Option. يحتوي قارئ الشاشة VO على العديد من أوامر لوحة المفاتيح، ولكننا لن ندرجها جميعًا هنا، حيث ستجد أوامر أو اختصارات لوحة المفاتيح الأساسية الخاصة بقارئ الشاشة VO والتي ستحتاجها لاختبار صفحة الويب في الجدول التالي، إذ يعني الاختصار "VO" معدِّل VoiceOver في اختصارات لوحة المفاتيح: اختصار لوحة المفاتيح الوصف المعدِّل VO + مفاتيح الأسهم تحريك مؤشر قارئ الشاشة VO للأعلى ولليمين وللأسفل ولليسار. المعدِّل VO + مفتاح المسافة تحديد أو تنشيط العناصر المميزة باستخدام مؤشر VO، ويتضمن ذلك العناصر المحددة في الدوّار Rotor (انظر أدناه). المعدِّل VO + مفتاح Shift + السهم للأسفل الانتقال إلى مجموعة من العناصر (مثل جدول HTML أو نموذج، …إلخ)، ويمكنك التنقل وتحديد العناصر ضمن تلك المجموعة باستخدام الأوامر المذكورة أعلاه. المعدِّل VO + مفتاح Shift + السهم للأعلى الخروج من المجموعة. المعدِّل VO + مفتاح C قراءة عنوان العمود الحالي (عندما تكون ضمن الجدول). المعدِّل VO + مفتاح R قراءة عنوان الصف الحالي (عندما تكون ضمن الجدول). المعدِّل VO + مفتاح C + مفتاح C (مفتاحا C على التوالي) قراءة العمود الحالي بأكمله بما في ذلك عنوانه (عندما تكون ضمن الجدول). المعدِّل VO + مفتاح R + مفتاح R (مفتاحا R على التوالي) قراءة الصف الحالي بأكمله بما في ذلك العناوين التي تقابل كل خلية (عندما تكون ضمن الجدول). المعدِّل VO + السهم لليسار أو المعدّل VO + السهم لليمين التنقل بين الخيارات عندما تكون ضمن بعض الخيارات الأفقية مثل منتقي التاريخ أو الوقت. المعدِّل VO + السهم للأعلى أو المعدّل VO + السهم للأسفل تغيير الخيار الحالي عندما تكون ضمن بعض الخيارات الأفقية مثل منتقي التاريخ أو الوقت. المعدِّل VO + المفتاح U استخدم الدوّار Rotor الذي يعرض قوائم العناوين والروابط وعناصر التحكم في النموذج وغير ذلك لسهولة التنقل. المعدِّل VO + السهم لليسار أو المعدّل VO + السهم لليمين التنقل بين القوائم المختلفة المتوفرة في الدوّار Rotor (عندما تكون ضمن الدوّار Rotor). المعدّل VO + السهم للأعلى أو المعدّل VO + السهم للأسفل التنقل بين العناصر المختلفة في قائمة الدوّار Rotor الحالية (عندما تكون ضمن الدوّار Rotor). المفتاح Esc الخروج من الدوّار Rotor (عندما تكون ضمن الدوّار Rotor). المفتاح Ctrl إيقاف أو استئناف الكلام (عندما يتحدث قارئ الشاشة VO). المعدّل VO + المفتاح Z إعادة تشغيل الجزء الأخير من الكلام. المعدّل VO + المفتاح D الانتقال إلى لوحة التفضيلات في جهاز Mac لتتمكن من تحديد التطبيقات التي تعمل ضمنها. يمكن أن تكون هذه الأوامر كثيرةً، لكنها ليست سيئةً عندما تعتاد عليها، إذ يعطيك قارئ الشاشة VO بانتظام تذكيرات بالأوامر التي يجب استخدامها في أماكن معينة. قارئ الشاشة NVDA يعمل قارئ الشاشة NVDA في نظام ويندوز فقط ويجب تثبيته كما يلي: نزّله من موقع nvaccess، حيث يمكنك اختيار التبرع أو تنزيله مجانًا، ويجب أن تضع عنوان بريدك الإلكتروني قبل أن تتمكّن من تنزيله. ثبّته بعد تنزيله من خلال النقر نقرًا مزدوجًا على برنامج التثبيت واقبل الترخيص واتبع التعليمات. يمكنك بدء تشغيل NVDA من خلال النقر نقرًا مزدوجًا على ملف أو اختصار البرنامج أو استخدام اختصار لوحة المفاتيح Ctrl + Alt + N. سترى مربع حوار ترحيب NVDA عند بدء تشغيله، ويمكنك هنا الاختيار من بين عدة خيارات، ثم الضغط على زر "موافق OK" للبدء بالعمل. سيصبح NVDA نشطًا الآن على حاسوبك. ستستفيد كثيرًا من معدِّل NVDA لاستخدام NVDA، وهو مفتاح يجب الضغط عليه بالإضافة إلى اختصارات NVDA من لوحة المفاتيح الفعلية لتشغيله، كما يُعَدّ استخدام مثل هذا المعدِّل أمرًا شائعًا مع قارئات الشاشة بحيث لا تتعارض أوامرها مع الأوامر الأخرى، كما يمكن أن يكون المُعدِّل في حالة NVDA إما المفتاح Insert (الحالة الافتراضية) أو المفتاح CapsLock (يمكن اختياره من خلال تحديد مربع الاختيار الأول في مربع حوار ترحيب NVDA قبل الضغط على زر موافق). ملاحظة: يُعَدّ NVDA أدق من VoiceOver من حيث كيفية تمييز مكان التحديد وما يفعله، فإذا تنقّلت عبر العناوين والقوائم وما إلى ذلك، فستُميَّز العناصر التي حدّدتها بإطار دقيق، ولكن ليس ذلك هو الحال دائمًا، فإذا ضعت تمامًا، فيمكنك الضغط على الاختصار Ctrl + F5 لتحديث الصفحة الحالية والبدء من الأعلى مرةً أخرى. يحتوي قارئ الشاشة NVDA على العديد من أوامر لوحة المفاتيح التي لن نذكرها جميعًا هنا، وإنما سنذكر فقط الأوامر الأساسية التي ستحتاجها لاختبار صفحة الويب في الجدول التالي، حيث يعني الاختصار "NVDA" معدِّل NVDA في اختصارات لوحة المفاتيح: اختصار لوحة المفاتيح الوصف المعدِّل NVDA + المفتاح Q إيقاف تشغيل قارئ الشاشة NVDA بعد تشغيله. المعدِّل NVDA + السهم للأعلى قراءة السطر الحالي. المعدِّل NVDA + السهم للأسفل بدء القراءة في الموضع الحالي. السهم للأعلى والسهم للأسفل، أو مفتاح Shift + مفتاح Tab ومفتاح Tab الانتقال إلى العنصر السابق/التالي في الصفحة وقراءته. السهم لليسار والسهم لليمين الانتقال إلى المحرف السابق/التالي في العنصر الحالي وقراءته. مفتاح Shift + مفتاح H ومفتاح H الانتقال إلى العنوان السابق/التالي وقراءته. مفتاح Shift + مفتاح K ومفتاح K الانتقال إلى الرابط السابق/التالي وقراءته. مفتاح Shift + مفتاح D ومفتاح D الانتقال إلى علامة المستند السابق/التالي مثل <nav> وقراءته. مفتاح Shift + المفاتيح 1–6 والمفاتيح 1–6 الانتقال إلى العنوان السابق/التالي (ذات المستويات 1-6) وقراءته. مفتاح Shift + مفتاح F ومفتاح F الانتقال إلى حقل الإدخال في النموذج السابق/التالي والتركيز عليه. مفتاح Shift + مفتاح T ومفتاح T الانتقال إلى جدول البيانات السابق/التالي والتركيز عليه. مفتاح Shift + مفتاح B ومفتاح B الانتقال إلى الزر السابق/التالي وقراءة تسميته أو عنوانه. مفتاح Shift + مفتاح L ومفتاح L الانتقال إلى القائمة السابقة/التالية وقراءة عنصر القائمة الأول. مفتاح Shift + مفتاح I ومفتاح I الانتقال إلى عنصر القائمة السابق/التالي وقراءته. مفتاح Enter أو Return تنشيط العنصر (عند تحديد رابط/زر أو عنصر آخر قابل للتنشيط). المعدِّل NVDA + مفتاح المسافة Space الدخول في النموذج بحيث يمكن تحديد العناصر الفردية أو الخروج منه إذا كنت موجودًا فيه فعليًا (عند تحديد النموذج). مفتاح Shift + مفتاح Tab ومفتاح Tab التنقل بين حقول إدخال النموذج (عندما تكون ضمن النموذج). السهم للأعلى والسهم للأسفل تغيير قيم حقول إدخال النموذج في حالة مثل مربعات التحديد مثلًا (عندما تكون ضمن النموذج). مفتاح المسافة تحديد القيمة المختارة (عندما تكون ضمن النموذج). المفتاح Ctrl + المفتاح Alt + مفاتيح الأسهم التنقل بين خلايا الجدول (عند تحديد الجدول). اختبار قارئ الشاشة اعتدت الآن على استخدام قارئات الشاشة، لذا يمكنك استخدامه لإجراء بعض اختبارات سهولة الوصول السريعة للحصول على فكرة عن كيفية تعامل قارئات الشاشة مع ميزات صفحات الويب الجيدة والسيئة: اطّلع على المثال good-semantics.html ولاحظ كيف يعثر قارئ الشاشة على العناوين وكيف تكون متاحةً للاستخدام للتنقل، و اطّلع على المثال bad-semantics.html، ولاحظ كيف لا يحصل قارئ الشاشة على أيّ من هذه المعلومات، وتخيل كم سيكون هذا مزعجًا عند محاولة التنقل في صفحة نصية طويلة. اطّلع على المثال good-links.html، ولاحظ كيف تبدو منطقيةً عند عرضها، وليس ذلك هو الحال مع المثال bad-links.html فجميع عباراته مجرد عبارات "انقر هنا". اطّلع على المثال good-form.html ولاحظ كيف أنّ حقول إدخال النموذج موصوفة باستخدام تسمياتها لأننا استخدمنا عناصر <label> بصورة صحيحة، في حين ستحصل في المثال bad-form.html على تسمية غير مفيدة. اطّلع على المثال punk-bands-complete.html وشاهد كيف يمكن لقارئ الشاشة ربط أعمدة وصفوف المحتوى وقراءتها معًا لأننا حددنا العناوين بصورة صحيحة، في حين لا يمكن ربط الخلايا على الإطلاق في المثال bad-table.html، ولاحظ أنّ قارئ الشاشة NVDA يبدو أنه يتصرف بغرابة بعض الشيء عندما يكون لديك جدول واحد فقط في الصفحة، لذا يمكنك تجربة صفحة اختبار جدول WebAIM بدلًا من ذلك. ألقِ نظرةً على مثال WAI-ARIA Live Regions الذي رأيناه سابقًا، ولاحظ كيف سيستمر قارئ الشاشة في قراءة القسم المُحدَّث باستمرار عند تحديثه. اختبار المستخدم لا يمكنك الاعتماد على الأدوات الآلية وحدها لتحديد مشاكل سهولة الوصول على موقعك، إذ يُفضَّل تضمين بعض مجموعات مستخدمي سهولة الوصول إذا كان ذلك ممكنًا عند وضع خطة الاختبار، لذا حاول إشراك بعض مستخدِمِي قارئ الشاشة وبعض مستخدِمِي لوحة المفاتيح فقط وبعض المستخدِمين الصُم ومجموعات أخرى بما يناسب متطلباتك. قائمة مراجعة اختبار سهولة الوصول توفر القائمة التالية قائمة مراجعة يمكنك اتباعها للتأكد من أنك أجريت اختبار سهولة الوصول الموصَى به لمشروعك: تأكد من أنّ شيفرة HTML صحيحة دلاليًا قدر الإمكان، إذ يُعَدّ التحقق من صحتها بدايةً جيدةً، كما هو الحال مع استخدام أداة تدقيق. تأكد من أنّ المحتوى يبدو منطقيًا عند إيقاف تشغيل شيفرة CSS. تأكد من أنّ وظائفك تشمل مستخدِمِي لوحة المفاتيح واختبرها باستخدام مفاتيح Tab أو Return أو Enter. تأكد من أنّ المحتوى غير النصي يحتوي على نصوص بديلة، إذ تُعَدّ أداة التدقيق مفيدةً في اكتشاف مثل هذه المشاكل. تأكد من أنّ تباين ألوان موقعك مقبول باستخدام أداة فحص مناسبة. تأكد من أنّ المحتوى المخفي مرئي لقارئات الشاشة. تأكد من أنّ الوظائف قابلة للاستخدام بدون شيفرة جافاسكربت حيثما أمكن ذلك. استخدم مواصفات ARIA لتحسين سهولة الوصول في المكان المناسب. شغّل موقعك من خلال أداة تدقيق. اختبره باستخدام قارئ الشاشة. ضمّن سياسة أو بيان سهولة وصول في مكان ما يمكن العثور عليه على موقعك لتقول ما فعلته. العثور عن المساعدة هناك العديد من المشاكل الأخرى التي ستواجهها مع سهولة الوصول، ولكن أهم شيء يجب معرفته هو كيفية العثور على إجابات عبر الإنترنت، ويمكنك الاعتماد على قسم الأسئلة والأجوبة في أكاديمية حسوب للحصول على بعض المساعدة والنصائح الجيدة من مبرمجين أكفاء. الخلاصة اطلعنا على كيفية اختبار مشاكل سهولة الوصول الرئيسية التي يمكن أن تواجهها وتعرفنا في هذا المقال كيفية التغلب عليها عبر عرض أهم الأدوات اللازمة لتحقيق سهولة الوصول، وسنلقي نظرةً في المقال التالي على اكتشاف دعم المتصفح للميزات بمزيد من التفصيل. ترجمة -وبتصرُّف- لقسم من المقال Handling common accessibility problems. اقرأ أيضًا المقال السابق: معالجة مشاكل سهولة الوصول Accessibility الشائعة للتوافق مع المتصفحات الدلالات المضمنة لعناصر صفحة الويب ودورها في تعزيز سهولة الوصول التحقق من سهولة الوصول لصفحات الويب

سنوجّه اهتمامنا في هذا المقال إلى سهولة الوصول أو سهولة الوصول 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 شمولية التصميم: سهولة وصول جميع المستخدمين لصفحات موقع الويب

قد يبدو الحكم على سهولة الوصول accessibility لتطبيق أو لموقع ويب وشموليته لكل المستخدمين بأنه مهمة صعبة. ولربما يتساءل البعض عن نقطة البداية لهذه المهمة، لا سيما هؤلاء الذين يتعاملون مع عملية التحقق من سهولة الوصول للمرة الأولى. بما أن العملية تعني التحقق من مجموعة متنوعة من الإمكانات فهذا يعني وجوب مراعاة مجموعة من المسائل المختلفة. نعرض في هذه المقالة آلية مقترحة تفصل هذه المسائل وتعمل عليها بشكل منطقي خطوة بخطوة للتحقق من سهولة الوصول لموقع ويب. البدء مع لوحة المفاتيح يُعدّ التنقل في الصفحة باستخدام لوحة المفاتيح فقط الوسيلة الأساسية للوصول لكل شيء على الشاشة من قبل المستخدمين الذين لا يُمكن لهم استعمال الفأرة (أو الذين يُحبذون عدم استعمالها). توجد شريحة واسعة من هذا النوع من المستخدمين مثل الأشخاص الذين يعانون من إعاقات حركية أو من الشلل أو المصابون بالإجهاد المتكرر (الناتج أحيانًا عن الاستخدام الطويل للفأرة)، إضافًة إلى مستخدمي قارئ الشاشة (ضعاف البصر مثلًا). يُعدّ توفير ترتيب تنقل منطقي عبر مفتاح تاب tab ومراعاة التركيز على العناصر بدقة لتوضيح مكان المؤشر الحالي أحد أهم أساسيات تحقيق سهولة الوصول باستخدام لوحة المفاتيح. النقاط الأساسية يجب أن تراعى النقاط الأساسية التالية: يُمكن البدء بالتنقل في الموقع باستخدام مفتاح الجدولة tab للتأكد من توفير ترتيب الجدولة المنطقي. يجب أن يكون ترتيب الجدولة موافقًا لترتيب العناصر في شجرة DOM. يُمكن العودة للمقالة التركيز على عناصر صفحة الويب لمراجعة القاعدة الأساسية في التركيز والتي تنص على أن أي عنصر تحكم يتفاعل المستخدم معه يجب التمكن من وضع التركيز عليه وإظهار مؤشر مرئي واضح للمستخدم عندها (مثلًا: إظهار حلقة تركيز focus ring). من الممارسات الشائعة تعطيل تنسيق الحدود الظاهرة على حواف العنصر عبر ضبط outline: none دون توفير أي تنسيقات بدلية لحدود حواف العنصر في CSS ولا تعد هذه من الممارسات الجيدة.anti-pattern. لن يتمكن مستخدم لوحة المفاتيح من التفاعل مع الصفحة إذا كان لا يستطيع رؤية موضع التركيز. يُمكن استخدام مكتبة برمجية مثل المكتبة what-input في حال الرغبة بالتمييز بين التركيز باستخدام الفأرة أو باستخدام لوحة المفاتيح. يجب إتاحة التركيز على العناصر المخصصة التفاعلية. مثلًا: في حال استخدام سكريبت جافا لتحويل مقطع إلى قائمة منسدلة جميلة فلن تكون قابلة للتركيز آليًا. يجب إسناد القيمة 0 لخاصية ترتيب الجدولة tabindex=0 لإتاحة التركيز على العنصر. يجب تجنب وضع قيم أكبر من الصفر للخاصية tabindex لأن ذلك سيجعلها في مقدمة ترتيب الجدولة وبغض النظر عن مكانها في شجرة DOM، مما يضع مستخدمي قارئ الشاشة الذين يميلون للتنقل بشكل متسلسل في حيرة والتباس. يجب تجنب وضع التركيز على العناصر التي لا يتفاعل المستخدم معها كالترويسات headings مثلًا. يلجأ بعض المطورين إلى إدراج خاصية ترتيب الجدولة tabindex في الترويسات ظنًا منهم أنها مهمة. يُعدّ هذا السلوك سلوكًا غير شائعًا مما يُقلل من كفاءة الاستخدام عمومًا. أما بالنسبة لمستخدمي قارئ الشاشة يكون التركيز على الترويسات غير ضروري لأن قارئ الشاشة يقرؤها. يجب التأكد من توجيه تركيز المستخدم إلى المحتوى الجديد المُضاف للصفحة كي يتمكن المستخدم من التفاعل معه. يُمكن مراجعة فقرة إدارة التركيز على مستوى الصفحة من المقالة المشار إليها سلفًا، والمعنونة بالتركيز على عناصر صفحة الويب لمزيد من الأمثلة. يجب تجنب قفل التركيز في أي نقطة. قد تؤدي عناصر الإكمال التلقائي autocomplete widgets لقفل التركيز باستخدام لوحة المفاتيح. يُمكن قفل التركيز في بعض الحالات المُحدّدة مثل إظهار نافذة شرطية modal والرغبة بمنع المستخدم من التعامل مع بقية عناصر الصفحة مع الاحتفاظ بإمكانية إغلاق هذه النافذة الشرطية باستخدام لوحة المفاتيح. إمكانية التركيز لا تعني إمكانية الاستخدام يجب على المطور عند إنشاء عنصر تحكم مُخصّص التأكد من وصول مستخدم لوحة المفاتيح لجميع وظائف هذا العنصر. المحتوى خارج الشاشة تحوي العديد من المواقع على محتوى مخفي موجود في شجرة DOM، كحالة الروابط الموجودة داخل قائمة تظهر استجابًة لفعل مستخدم ما responsive drawer menu أو زر داخل نافذة شرطية لم يأتِ بعد وجوب عرضه. يؤدي ترك هذه العناصر في شجرة DOM إلى إرباك مستخدم لوحة المفاتيح لا سيما أن قارئ الشاشة سيقرأ هذه العناصر كما لو أنها جزءًا من الصفحة. يُمكن مراجعة فقرة أهمية ترتيب العناصر في شجرة DOM من مقالة التركيز على عناصر صفحة الويب، للحصول على إرشادات التعامل مع هذه العناصر. اختبار الصفحة مع قارئ الشاشة يؤدي تحسين دعم لوحة المفاتيح إلى وضع أساسيات الخطوة التالية وهي التحقق من احتواء الصفحة على العناوين labels والدلالات المناسبة وعدم وجود أي عوائق أمام تنقل قارئ الشاشة ضمن الصفحة. النقاط الأساسية يجب أن تراعى النقاط الأساسية التالية: يجب التحقق من أن لجميع الصور الخاصية alt لتوفير النص البديل لها عند الحاجة. يُمكن استثناء الصور التي توضع بهدف العرض فقط ولا تكون جزءًا أساسيًا من المحتوى. يجب إسناد السلسلة الفارغة ""=alt لإعلام قارئ الشاشة بوجوب تخطي صورة. يجب التحقق من توفير عناوين labels لجميع عناصر التحكم. يُمكن أن يتطلب ذلك استخدام الخاصيتين aria-label و aria-labelledby للعناصر المخصصة. للمزيد من التفاصيل يُمكن العودة إلى العناوين والعلاقات في ARIA. يجب التحقق من أن لجميع عناصر التحكم الدور role المناسب وخصائص ARIA المطلوبة لضبط حالتها. مثلًا: يحتاج مربع الاختيار المخصص إلى الدور "role="checkbox وإلى الخاصية "aria-checked="true|false للإعلام عن حالة العنصر بشكل صحيح. يجب التحقق من التسلسل المنطقي للانتقال بين عناصر الصفحة. بما أن برامج قراءة الشاشة تنتقل في الصفحة وفق ترتيب شجرة DOM فستؤدي عملية استخدام أنماط CSS لتغيير أماكن توضع العناصر إلى الإعلان عن هذه العناصر وفق تسلسل غير منطقي. يجب على المطور وضع العناصر في شجرة DOM وفق ترتيب الإظهار الذي يرغبه. يجب عدم السماح بإخفاء أي قسم من أقسام الموقع أو حظر وصول قارئ الشاشة إليه بشكل دائم إذا كان دعم تنقل قارئ الشاشة في كل محتوى الصفحة مطلوبًا. يجب التأكد من إسناد القيمة true إلى الخاصية aria-hidden إذا كان المطلوب إخفاء محتوى ما عن قارئ الشاشة كأن يكون خارج الشاشة أو عبارة عن شيئٍ للعرض فقط. التعرف على قارئ شاشة واحد يُساعد في فهم المسائل والمشاكل قد يبدو تعلم استخدام قارئ الشاشة للوهلة الأولى أمرًا صعبًا، إلا أنه عملية سهلة في الواقع إذ يُمكن للمطورين التعامل معه باستخدام بضعة أوامر من لوحة المفاتيح. يُمكن استخدام قارئ الشاشة VoiceOver الذي يتوفر في أنظمة Mac OS.كما يُمكن لمستخدمي النظام Windows مشاهدة هذا الفيديو عن قارئ الشاشة NVDA والذي هو برنامج مفتوح المصدر مدعوم بالتبرعات. لا تمنع الخاصية aria-hidden التركيز باستخدام لوحة المفاتيح يجب أن نتذكر أن خصائص ARIA تؤثر على دلالات العناصر فقط وليس على سلوكها. يُمكن إخفاء عنصر عن قارئ الشاشة باستخدام hidden=true إلا أن هذا لن يغير من سلوك التركيز على العنصر. أما بالنسبة للمحتوى التفاعلي الموجود خارج الصفحة فنحتاج غالبًا للجمع بين aria-hidden=true و "tabindex=”-1 للتأكد من إزالة العنصر من تسلسل استخدام لوحة المفاتيح. تهدف السمة الجديدة المقترحة inert إلى تسهيل ذلك بالجمع بين سلوك كلتا الخاصيتين. الإشارة إلى حالة العناصر التفاعلية مثل الروابط والأزرار والهدف منها يُسهّل عرض التلميحات hints المرئية للعناصر التفاعل والتنقل في الموقع. تُدعى هذه التلميحات بالإمكانات affordances والتي تُساعد الأشخاص على تصفح الموقع باستخدام مجموعة متنوعة من الأجهزة. النقاط الأساسية تراعى النقاط الأساسية التالية: يجب أن تكون العناصر التفاعلية، مثل الروابط والأزرار، قابلة للتمييز بوضوح عن العناصر غير التفاعلية. إذ يصعُب على المستخدمين التنقل في موقع أو تطبيق عندما لا يتمكنون من معرفة فيما إذا كان العنصر قابلاً للنقر أم لا. هناك العديد من الطرق الصحيحة لتحقيق هذا الهدف. إحدى الممارسات الشائعة هي وضع خط تحت الروابط لتمييزها عن النص المحيط بها. على غرار متطلبات التركيز، تتطلب العناصر التفاعلية مثل الروابط والأزرار حالة حومان hover لمستخدمي الفأرة كي يدركوا أنهم يحركون الفأرة فوق شيء يُمكن النقر عليه. علاوًة على ذلك، يجب أن يكون العنصر التفاعلي مميزًا بنفسه. إذ لا يُساعد الاعتماد على حالة الحومان وحدها للإشارة إلى العناصر القابلة للنقر على الشاشات التي تعمل باللمس. الاستفادة من الترويسات والعلامات تُعطي العناوين Headings والعلامات landmarks بنية دلالية للصفحة، وتزيد من كفاءة التنقل لمستخدمي التقنية المساعدة بشكل كبير. أفاد العديد من مستخدمي برامج قراءة الشاشة أنهم عندما يصلون إلى صفحة غير مألوفة لأول مرة فإنهم يحاولون التنقل عن طريق الترويسات عادةً. وبالمثل، توفر برامج قراءة الشاشة أيضًا القدرة على الانتقال إلى علامات مهمة مثل <main> و <nav>. لذا فمن المهم دراسة كيفية استخدام بنية الصفحة لتوجيه تجربة الاستخدام. النقاط الأساسية تراعى النقاط الأساسية التالية: يجب استخدام التسلسل الهرمي للترويسات h1-h6 بالشكل المناسب والتفكير بالترويسات كأدوات لإنشاء مخطط outline الصفحة. يجب عدم ترك الترويسات بالأنماط المبنية مسبقًا لها بل يجب الآخذ بعين الاعتبار فيما لو كانت جميع الترويسات بنفس الحجم واستخدام المستوى المناسب دلاليًا للمستوى الأول والثاني والثالث. وفي النهاية استخدام أنماط CSS لجعل الترويسات تتماشى مع تصميم الصفحة. يجب استخدام عناصر العلامات landmarks والأدوار roles لتمكين المستخدمين من تجاوز المحتوى المكرر. توفر العديد من التقنيات المساعدة الاختصارات shortcuts اللازمة للانتقال إلى أقسام محدّدة من الصفحة مثل الأقسام المُعرّفة باستخدام العناصر <main> أو <nav> والتي تلعب دور علامات ضمنية. يُمكن استخدام خاصية الدور role في ARIA لتعريف المناطق بشكل صريح في الصفحة مثلًا: <"div role="search>. يُمكن العودة لفقرة الدلالات والتنقل في المحتوى للمزيد من الأمثلة. يجب على المطور تجنب استخدام الخاصية role مع القيمة application إلا في حال تمتعه بالخبرة السابقة في العمل معها. إذ يؤدي هذا الاستخدام إلى إعلام التقنية المساعدة بتعطيل جميع اختصاراتها shortcuts وتمرير جميع ضغطات المفاتيح إلى الصفحة، مما يعني أن مفاتيح قارئ الشاشة التي يستعملها المستخدمون عادةً للتنقل في الصفحة لن تعمل بعد الآن، وسيحتاج المطور إلى معالجة جميع أحداث لوحة المفاتيح بنفسه. استخدام قارئ الشاشة للتحقق السريع من الترويسات والعلامات توفر برامج قراءة الشاشة مثل VoiceOver و NVDA قائمة سياقية context menu تسمح بالوصول السريع للمناطق الهامة في الصفحة. يُمكن استخدام هذه القوائم للحصول على نظرة عامة سريعة على الصفحة وتحديد ما إذا كانت مستويات الترويسات مناسبة وما هي العلامات المستخدمة. راجع مقاطع الفيديو التعليمية هذه حول أساسيات VoiceOver و NVDA. أتمتة العملية يمكن أن يكون التحقق من سهولة الوصول أمرًا شاقًا وعرضة للخطأ. ولذا يكون من الأفضل أتمتة هذه العملية في نهاية المطاف. يمكن القيام بذلك من خلال استخدام ملحقات extensions المستعرض وأدوات اختبار سهولة الوصول باستخدام سطر الأوامر. النقاط الأساسية يمكنك اتباع الخطوات التالية: يُمكن التحقق من اجتياز الصفحة لجميع الاختبارات باستخدام إضافات المتصفح aXe أو WAVE. هذه الإضافات ليست سوى خيارين متاحين ويمكن أن تكون إضافة مفيدة لأي عملية اختبار يدوي حيث تستطيع التعرف على المشكلات الدقيقة بسرعة مثل فشل نسب التباين failing contrast ratios وخصائص ARIA المفقودة. يُمكن استخدام سطر الأوامر واستخدام ax-cli الذي يوفر نفس الوظائف التي يوفرها امتداد المتصفح aXe، ولكن يمكن تشغيله بسهولة من الطرفية. يُمكن تضمين مكتبة برمجية مثل axe-core لمجموعة الاختبار المؤتمتة وذلك لضمان تجانس الاختبارات وتكاملها لا سيما في بيئة عمل تكاملي مستمر. وهي المكتبة نفسها التي تدعم الامتداد aXe إلا أنها أسهل للاستخدام عن طريق سطر الأوامر. في حال استخدام إطار عمل أو مكتبة فيُمكن أن يُطرح السؤال: هل توفر أدوات سهولة الوصول الخاصة بها؟ تتضمن بعض الأمثلة استخدام المكتبة البرمجية protractor-accessibility-plugin في Angular و a11ysuite في Polymer و Web Components. يجب دومًا الاستفادة من الأدوات المتاحة كلما أمكن ذلك تجنبًا لإعادة اختراع الدولاب. استخدام الأداة Lighthouse عند تطوير صفحات الويب التقدميّة تُساعد الأداة Lighthouse في قياس أداء تطبيق الويب التقدمي وتستخدم أيضًا المكتبة ax-core لتشغيل مجموعة من اختبارات سهولة الوصول. يُمكّن استخدام هذه الأداة في تحديد حالات فشل الوصول والتي يُساهم إصلاحها في تحسين تجربة المستخدم الإجمالية للموقع. النتيجة يجب إدراج عمليات التحقق من سهولة الوصول كجزء أساسي في خطة التطوير ويجب إجراء هذه العمليات مبكرًا وبشكل دوري، مما يُساهم في تحسين تجارب الاستخدام للموقع، كما يجب أن لا ننسى أن الوصول السهل يعني تجربة استخدام جيدة! ترجمة -وبتصرف- للمقالة How To Do an Accessibility Review للمؤلف Rob Dodson. اقرأ أيضًا سهولة وصول جميع الزوار لمواقع وتطبيقات الويب النسخة الكاملة من كتاب نحو فهم أعمق لتقنيات 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

واصل فريقي الوقوع في نفس النقطة مرارًا وتكرارًا في المراحل الأولى من كل مشروع. حتى عندما ملكنا مُحلِّلًا خاصًّا بسهولة الاستخدام بين أيدينا، لازلنا نعتمد في النهاية على الإحساس وصنع قرارات مبنية على العلم. أعطانا تحليل البيانات صورةً واضحةً عن ما كان يحدث ولكنه جعلنا نخمن، لماذا كان يحدث أصلًا. كنا قد حصلنا على ردود فعل هائلة من فحص سهولة الاستخدام، ولكننا شعرنا وكأن ردود الفعل لم تكن جديرة بالثقة حيث أن المستخدمين يتصرفون بشكل مختلف عندما يدركون بأنه تتم مراقبتهم. لذلك قمنا بصنع Jaco، وهي أداة تمكنك من رؤية ما يفعله الناس على موقعك أو تطبيقك. مهما كان تطبيقك معقدًا أو أيًا كان إطار العمل الذي تستعمله، فإن Jaco بإمكانه إعادة عرض كل جلسة مستخدم على شكل فيديو. خلال عملية تطوير Jaco، تعلمنا الكثير عن حالة الاستخدام لقدرة كهذه، واستخدمنا في الحقيقة Jaco لتطوير نفسه. التالي هو قصة حول كيف أضفنا Jaco لخط عملنا التقليدي وعن القيمة الإضافية التي ربحناها منه. بناء نسخة تجريبية لم يكن لدينا أدنى فكرة عن إذا ما كان Jaco شيءً يريده أو يحتاجه الناس، لذلك قمنا ببناء نسخة تجريبية لاختبار ردة الفعل. وكان هذا بتطوير إثبات عن الفكرة POC، وقررنا أن نشرك صفحتين أساسيتين فيها: صفحة الجلسات (لوحة التحكم الخاصة بنا) والتي تعرض قائمة بكل الجلسات المسجلة والأداء الوظيفي الأساسي لتصفية الجلسات حسب التاريخ، واسم المستخدم ورابط الصفحة الإلكتروني (بداخل الجلسة). صفحة المشغّل، حيثما يمكنك عرض تسجيل فيديو لمستخدمين حقيقيين ومشاهدتهم يتفاعلون مع موقعك. كل تفاعل خاص بمستخدم يتم ادراجه في نسخة على الجانب الأيمن من الصفحة ويتم أيضًا نقله للمخطط الزمني. الهدف الوحيد هنا كان أن تقدر على تخزين ومن ثم عرض جلسات المستخدم. لم يكن أي مصمم يعمل معنا وقمنا بإعطاء اهتمام قليل لتجربة المستخدم في ذلك الوقت. جعل الزبائن يستخدمون منتجاتنا الأساسية بعد أن أصبح لدينا شيءٌ يعمل فعليًا، كان قد حان الوقت للحصول على أول مختبرين لنسختنا التجريبية. وبما أن هدفنا كان إيجاد شركات ناشئة في مراحل متعددة لكسب فهم أفضل عن التناسب السوقي لمنتجنا، فكرنا في أفضل الأماكن التي يمكننا الذهاب إليها لإيجادهم، لذلك قمنا بحضور مقابلات ومحادثات موجهة نحو الشركات الناشئة واستطعنا أن نجد مختبري نسخة تجريبية متحمسين. قام أول المختبرين بتسليمنا قائمة بطلبات عن المزايا وأعطونا ردود فعلة ثمينة وملخّصة بالأسفل: الشركات الناشئة في المراحل المتقدمة: "على الرغم من أننا نتعلم شيئًا جديدًا من كل جلسة نشاهدها، لدينا أسئلة معينة نود تحريها باستخدام Jaco ولكن ينقص علينا الأدوات اللازمة لعمل ذلك." أخبرنا هذا بأننا احتجنا إلى إضافة المزيد من الفلاتر أو عوامل التصفية وإلى عمليات التكامل للسماح لزبائننا الذين يملكون حركة اتصالات كثيرة بأن يستخدموا Jaco. الشركات الناشئة في المراحل المبكرة: "مشاهدة تفاعل مستخدمينا مع منتجاتنا قام بإقصاء التخمينات من عملية صنع القرارات الصعبة." هذا أخبرنا بأن الشركات الناشئة في المراحل المبكرة يكتسبون الكثير من القيمة باستخدام Jaco. في ذلك الوقت، كنا شركة ناشئة في المراحل المبكرة، لذلك قررنا أن نجرب دراسة حالة على منتجنا الخاص واستخدام Jaco لمراجعة التسجيلات الخاصة بمختبري النسخ التجريبية. استخدام تسجيلات العملاء لتحسين Jaco لاحظنا نمطًا مرتبطًا بالطريقة التي يستخدم فيها عملاؤنا صفحة المشغّل. عندما يبدأ مستخدم جديد باستخدام منتجنا، فهو يقضي الوقت في مشاهدة مقاطع الفيديو المجمعة من البداية للنهاية. بعد فترة معينة، يبدأ المستخدم بمشاهدة المقاطع بسرعة مضاعفة 3 أضعاف، ولاحقًا، بينما يصبح على دراية أكبر بالمنتج، يبدأ باستخدام نسخة طبق الأصل لفحص محتوى الجلسة، يقوم أيضًا بالبحث عن مزايا في المخطط الزمني. بناءً على ما أظهر لنا Jaco، صنعنا ثلاثة تغييرات على ميزة النص: قمنا بتحريكها للجهة اليسرى حيث أصبحت مرئية أكثر بحثنا بالأصل عن السلوك في المخطط الزمني (وليس في النص)، لكن بما أننا لاحظنا أن العديد من المستخدمين يقومون بالضغط على فعالية ما في النص قبل أن يضغطوا على العلامة المترابطة في المخطط الزمني، قررنا أن نضيف هذا السلوك للنص أيضًا. أضفنا أيقونات وألوان مختلفة لكل نوع من أنواع الفعاليات في النص، بجانب سلوك التمرير التلقائي لجعل هذا العنصر ينبثق ويحث على تفاعل المستخدم. خلال يومين، 73% من مستخدمينا أصبحوا خبراء في صفحة المشغّل: بدأوا باستخدام النص لفحص الجلسة والبحث عن أجزاء معينة من التسجيلات، واستخدموا ميزة البحث لرؤية الأجزاء الأكثر صلة فقط من التسجيل. أنشأ هذا التغيير ردود فعل إيجابية من عملائنا، وبدأنا بالتفكير بطرق نستطيع من خلالها تطبيق ما تعلمناه في صفحة المشغّل على بقية Jaco. فكرنا بأخذ المخطط الزمني للجلسة من صفحة المشغّل ونسخها في صفحة الجلسة، وبالتالي مساعدة عملائنا على البحث بشكل أسرع في أكثر من جلسة واحدة على حدة. قمنا بتجسيد أفكارنا واختبارها بواسطة العديد من جلسات واحد لواحد مع عملائنا. بعد هذه العملية السريعة، صممنا النماذج بالأسفل: استثمرنا معظم تركيزنا في صنع إصدار أصغر من المخطط الزمني، وأضفنا المعلومات من النسخة طبق الأصل. عرض المخطط الزمني في صفحة الجلسات أعطى عملاءنا القدرة على فهم الإيقاع والمستوى الخاص بارتباط المستخدم في الجلسة بنظرة سريعة فقط. بعد ذلك، صنعنا نموذجًا تجريبيًا سريعًا. بعد اختبار فكرتنا الجديدة مع عملائنا، استنتجنا بأنه بينما كانت ردود الأفعال المتعلقة بفكرة هذا العنصر موجبة، بعض عملائنا شعروا بأن عملية التصفية الخاصة بنا كانت واهنة ومعقدة. أدركنا بأنه على الرغم من أن هذا الحل هو خطوة جيدة في الإتجاه الصحيح، كان لا يزال هنالك عمل يجب القيام به. أنشأنا نماذج جديدة مع اعتبار ردود الفعل، مما أدى للتصميم التالي: وبجانب عوامل التصفية الواهنة، أردنا حلًا يعطي الجدول مساحة أفقية أوسع والمزيد من الفراغ للمعلومات. قررنا أن نزيل العمود الأيسر وبناء واجهة جديدة كليًا للشرائح وميزة التصفية. بدت الواجهة الجديدة لعوامل التصفية أكثر بديهية، مرونة وأسهل في الاستخدام. استخدمنا عوامل تصفية JIRA كمرجع. أحببنا كيف يسمح JIRA باختيار كيفية إدخال استعلام أو قسم. بما أن سلسلة عملائنا الأساسية تتضمن مصممين ومالكي منتجات على طرف، وقراصنة على الطرف الآخر، فإن هذا حل مثالي لنا. وها هو التصميم النهائي: الملخص بمجرد إكمالنا دراسة الحالة الخاصة بنا، تعلمنا بأن Jaco يعود علينا بالفائدة بشكل أفضل عند إضافته لخط العمل الخاص بنا بالطرق التالية: بعد تحليل كل معلوماتنا من تحليلات جوجل Google Analytics لمعرفة حالتنا، نستخدم Jaco لتحديد كيف يجب علينا تحسين الأشياء. بعد كل نشر، نستخدم Jaco لرؤية الجلسات التي تم فيها استخدام ميزتنا الجديدة لكي نسبق المنحنى ونتنبأ بأداء الإعلان الجديد. هذا يمكننا من أن نتحقق من الفاعلية بدون الحاجة للانتظار لكمية كبيرة من حركة الاتصالات الخاصة بالتحاليل. مكنتنا هذه الطريقة من أن نكون معتمدين على البيانات خلال مرحلتنا المبكرة عندما لم تكن حركة الاتصالات الخاصة بنا كثيفة بشكل كافي ليتم تجميعها، وهذه الطريقة تساعدنا الآن بالتحرك بشكل أسرع وأن نكون معتمدين على البيانات بشكل أكبر حيث أننا نحصل على ردود فعل مباشرة من عملاء حقيقيين في غضون ساعة بعد أي طرح جديد. يقضي Jaco حاليًا آخر أسابيعه في مرحلة النسخة التجريبية المجانية، ونحن نعمل بحيوية لإضافة المزيد من التكاملات وعوامل التصفية المتقدمة. ننوي في المستقبل القريب بأن نضيف المزيد من الأدوات التي تسمح لمالكي المنتجات بأن يحصلوا على بيانات مجتمعة متعلقة باستخدام منتجهم من قبل كل من الجلسات وجوانب المستخدمين. ترجمة -بتصرف- للمقال ‎Creating a tool that records user interactions لصاحبه Ran Klein

Lighthouse هو أداة مُؤَتمتة (Automated) مفتوحة المصدر لتحسين صفحات الويب. يمكن تطبيق الأداة على أي صفحة ويب سواء كانت عامّة أو تحتاج للاستيثاق (Authentication). يمكن استخدام الأداة للتدقيق في الأداء، قابليّة الوصول (Accessibility)، صفحات الويب التقدميّة (Progressive web apps) وغيرها. تستطيع تشغيل Lighthouse من أدوات المُطوّر في Chrome أو سطر الأوامر أو بصيغة وحدة Node. تستقبل الأداة Lighthouse رابط URL لتدقيقه فتُشغِّل سلسلة من التدقيقات على الصفحة ثم تولّد تقريرًا عن حالة الصفحة. اعتمد على التقرير واستخدم التدقيقات التي أخفقت فيها الصفحة دليلا لكيفية تحسينها. يوجد في كلّ تدقيق توثيق مرجعي يشرح أهميّة التدقيق وكيف تصلح الصفحة لتتوافق معه. البداية اختر سير عمل Lighthouse الذي يناسبك: أدوات التطوير في Chrome. دقّق الصفحات التي تحتاج الاستيثاق بسهولة واقرأ التقارير بصيغة مفهومة للمستخدم. عبر سطر الأوامر. أتمت تشغيلات Lighthouse بسكربتات Shell. وحدة Node. ادمج Lighthouse في نظام التكامل المستمر (Continuous integration) الخاصّ بك. ملحوظة: تتطلّب كل واحدة من طرق العمل في Lighthouse وجود Google Chrome مثبَّت على جهازك. شغّل Lighthouse من أدوات تطوير Chrome يشغّل Lighthouse لوحة Audits في أدوات تطوير Chrome. اتبع الخطوات التالية لتشغيل تقرير: نزّل Google Chrome للأجهزة المكتبية. استخدم Google Chrome لتصفّح الصفحة التي تودّ تدقيقها. يمكنك تدقيق أي صفحة على الوِب. افتح أدوات التطوير DevTools في Chrome. انقر على اللسان Audits. يظهر في يسار الشاشة الإطار المعروض من الصفحة التي ستُدقَّق. تظهر في اليمين لوحة التدقيقات (Audits) التي يشغّلها Lighthouse. انقر على Perform an audit. تظهر أدوات التطوير قائمة بتصنيفات التدقيق. اتركها جميعا مُعلَّمة. انقر على Run audit. يعطيك Lighthouse بعد 60 إلى 90 ثانية تقريرًا عن الصفحة. تثبيت سطر أوامر Node وتشغيله اتبع الخطوات التالية لتثبيت وحدة Node: 1- نزّل Google Chrome للأجهزة المكتبية. 2- ثبّت الإصدار طويل الدعم الحالي من Node. 3- ثبّت Lighthouse. يشير الخيار ‎-g إلى تثبيت الوحدة على مستوى النظام. npm install -g lighthouse 4- نفّذ الأمر التالي لتنفيذ تدقيق: lighthouse <url> 5- لعرض خيارات التدقيق: lighthouse --help تشغيل وحدة Node برمجيا راجع استخدام هذا الرابط لمثال على تشغيل Lighthouse برمجيًّا على صورة وحدة Node. تشغيل Lighthouse عن طريقة إضافة Extension على Chrome ملحوظة: يُفتَرض استخدام خطة سير عملا مبنية على أدوات المطوِّر في Chrome بدلا من هذه الإضافة، إلا إذا كان لديك سبب خاصّ. تُوفّر أدوات المطوّر في Chrome نفس الفوائد التي توفّرها الإضافة، علاوةً على كون الأدوات لا تحتاج لتثبيت. اتبع الخطوات التالية لتثبيت الإضافة: نزّل Google Chrome للأجهزة المكتبية. ثبّت إضافة Lighthouse من مخزن إضافات Chrome. اتبع الخطوات التالية لتشغيل تدقيق: استخدم Google Chrome لتصفّح الصفحة التي تودّ تدقيقها. انقر أيقونة Lighthouse. يُفتَرَض أن توجد الأيقونة بعد شريط العنوان في Chrome. إن لم تكن هناك، افتح القائمة الرئيسية في Chrome وانقر على الأيقونة في أعلى القائمة. تتمدّد قائمة Lighthouse بعد النقر على الأيقونة. انقر على الزرّ Generate report. يدقّق Lighthouse الصفحة النشطة ثم يفتح لسانًا جديدًا يحوي تقريرًا عن نتائج تدقيق الصفحة. شارك التقارير واعرضها على الشبكة استخدم Lighthouse Viewer (عارض Lighthouse) لعرض التقارير ومشاركتها على الشبكة. شارك التقارير بصيغة JSON يحتاج Lighthouse Viewer إلى مُخرج بصيغة JSON من تقرير Lighthouse. تشرح الخطوات أدناه كيفية الحصول على مُخرج بصيغة JSON، حسب طريقة العمل التي اخترتها. بالنسبة لأدوات التطوير: انقر على تنزيل التقرير (السهم المتّجه إلى الأسفل). سطر الأوامر: lighthouse --output json --output-path <path/for/output.json> إضافة Chrome: انقر على زرّ التصدير Export ثم Save as JSON. لمعاينة بيانات التقرير: افتح Lighthouse Viewer في متصفّح Chrome. اسحب ملف JSON إلى العارض ثم أفلته، أو انقر في أي مكان في العارض لفتح متصفّح الملفّات لديك واختيار الملفّ. مشاركة التقارير عبر GitHub Gists إن لم تكن ترغب في تمرير تقاريرك يدويّا بصيغة ملفات JSON فيمكنك مشاركتها بسريّة عبر خدمة GitHub Gists. أحد فوائد الخدمة هو الحصول على تحكّم مجاني في الإصدارات Version control. اتبع الخطوات التالية لتصدير التقارير إلى GitHub Gists عبر إضافة Lighthouse على Chrome: انقر على Export ثم Open In Viewer. يُفتَح التقرير في العارض المتوفّر على الرابط https://googlechrome.github.io/lighthouse/viewer/. انقر على المشاركة Share في العارض. ستطلُب منك نافذة منبثقة في المرة الأولى السماح بالوصول إلى بياناتك الأساسية على GitHub، وصلاحية القراءة والكتابة على GitHub Gists. أنشئ Gist يدويًّا ثم انسخ التقرير بصيغة JSON وألصقه، إن أردت تصدير التقرير إلى GitHub Gists من سطر الأوامر. يجب أن ينتهي اسم Gist الذي يحوي مُخرَج JSON باللاحقة lighthouse.report.json. راجع هذا الرابط لمثال على كيفية توليد مُخرَج JSON من سطر الأوامر. اختر إحدى الطريقتيْن التاليّتين لعرض تقرير محفوظ على GitHub Gists: . أضف ‎?gist=<ID>‎ إلى رابط العارض، حيثُ ID هو معرّف Gist: https://googlechrome.github.io/lighthouse/viewer/?gist=<ID>‎ افتح العارض وألصق فيه رابط Gist المساهمة في Lighthouse Lighthouse مفتوح المصدر، ويرحّب مطوّروه بالمساهمة فيه. تحقّق من متتبّع المشاكل Issues tracker في المستودع للعثور على علل (Bugs) يمكنك إصلاحها، أو تدقيقات يمكنك إنشاؤها أو تحسينها. يعدّ متتبّع المشاكل مكانا جيّدا للنقاش حول قياسات التدقيق أو أفكار لتدقيقات جديدة أو أي أمر آخر له علاقة بأداة Lighthouse. ترجمة - بتصرّف - للمقال Lighthouse من موقع مطوّري Chrome.

سيفاجئك العملاء بطرق استخدام منتجك مبتكرة. وهذا لا يأتي من دراسة وتفكّر من جانبهم وإنّما نتيجة لجعلهم منتجك يتكيّف مع احتياجاتهم. يقول Peter Drucker قولته المشهورة: "نادرًا ما يشتري العميل ما تظنّ الشركة أنّها تبيعه"؛ وهذه إشارة إلى أنّه لكي تطوّر منتجًا ما يجب عليك أوّلًا أن تدرس وتفهم الغرض الذي سيُستخدم من أجله. لنوضّح الأمر بمثال: بعد أن أطلقنا Intercom بفترة قصيرة قمنا بإضافة ميزة الخارطة لنتمكّن من معرفة أماكن عملائنا حول العالم. كانت هذه الميزة من النوع الكلاسيكي وكانت رائعة جدًّا لكنّنا لا نعرف لماذا. ولقد استطعنا رؤية كم أصبحت هذه الخارطة شعبيّة من خلال عدد الأشخاص الذين يستخدمونها. لكن التسويق للخارطة كميزة كان صعبًا، لأنّه كان من الصعب معرفة سبب استخدامها. هل هو معرفة المكان الذي يأتي منه أغلب العملاء؟ كلّا، العديد من المُنتجات تفعل ذلك.هل هو رؤية العملاء من مدينة معيّنة؟ كلّا، فقوائم المستخدمين تفعل ذلك بشكل أفضل بكثير.هل هو معرفة عدد مستخدمي المنتج في بلد معيّن؟ كلّا، فقوائم المستخدمين تفعل ذلك بشكل أفضل بكثير أيضًا.إذًا ما هو الغرض من الخارطة بغضّ النظر عن كونها مثيرة للإعجاب؟ لقّد فكّرنا بثلاث طرق استُخدمت فيها هذه الخاصيّة: هنالك أشخاص يفضّلون استعراضها في المعارض التجارية والمؤتمرات (انظر إلى الحاسوب الشخصي): وأشخاص يفضّلون استعراضها على تويتر: وآخرون يفضّلون استعراضها أمام المستثمرين: إذًا ما تفعله الخارطة هو أنّها تبدو رائعة وتثير إعجاب العملاء؛ هذا كل ما تفعله. التحسين على أساس الاستخداملو أردنا تحسين الخارطة قبل معرفة الغرض الذي تُستخدم من أجله لحاولنا إنشاء خارطة أفضل. فيما يلي بعض الأمور التي قد نركّز عليها: الدّقة الجغرافية.المجموعات الجغرافيّة.حدود أفضل للدولة أو المدينة.خاصية السحب لإنشاء مناطق regions.تحسينات خرائطيّة أخرى متنوّعة.قد تستغرق منّا هذه التحسينات عدّة أسابيع أو أشهر، وفي النهاية تؤدّي إلى منتج أسوء؛ لأنّ العميل لم يكن يشتري ما كنّا نظن أنّنا نبيعه. فالخارطة أصبحت عبارة عن قطعة للعرض وليست خارطة. ما الذي يجعل الخارطة تقوم بتلك المهمّة بشكل أفضل؟ أولًا وقبل كل شيء، خارطة مصمّمة لتبدو جيّدة.خارطة تقوم بإخفاء البيانات الحسّاسة بشكل تلقائي مما يجعلها قابلة للمشاركة.خارطة من السهل على العملاء مشاركتها.وهذا بالضبط ما قمنا بعمله. لقد قمنا بعرض على عملائنا فرصة مشاركة خارطة متحرّكة وجميلة، وزوّدناهم بعنوان URL فريد من نوعه وقابل للمشاركة: خارطة أسوء تقوم بعمل أفضلعندما تقوم بالتركيز على الكيفيّة التي تُستخدم فيها الميزة، متجاهلًا فئة أو نوع الميزة، ستتعلم كيف تقوم بتحسينها بسرعة، وهذه التحسينات سيتردد صداها على الفور. بإمكانك مشاهدة المزيد من ردود أفعال العملاء تجاه الخارطة القابلة للمشاركة هنا. حقوق التّصميم عائدة لـHongyuan وحقوق تطوير الميزة عائدة لـEoin وPatrick. ترجمة -وبتصرّف-للمقال This is not a map لصاحبه: Des Traynor. حقوق الصورة البارزة: Designed by Freepik.

نعتقد جميعنا أننا نفهم هندسة المعلومات، ومع ذلك فإن هذا المجال مجال خاص نوعا ما والأشياء التي نظنّ أننا نعلمها قد لا تكون صحيحة. لم نعد نسمع عن مصطلح هندسة المعلومات كثيرًا في هذه الأوقات، هناك الكثير من الحديث عن فهم احتياجات المستخدمين وتقديم المحتوى المناسب لهم، ولكن القليل منه حول كيف يجد المستخدم هذا المحتوى. يعود هذا الأمر إلى أنّ هذا الموضوع مغطّى بشكل كامل، يوجد بعض الكتب الرائعة حول الموضوع، وعليه لا يشعر المدونون أنّ هناك المزيد لإضافته. المشكلة هي أنه عندما تتم تغطية الموضوع بشكل جيد، فإنه ينتقل إلى عالم المعرفة العامّة. إن مشكلة المعرفة العامّة أنّه يعلوها الغبار مع مرور الوقت، تظهر معلومات خاطئة وتكبر بعض الخرافات.هذا الأمر يتكرّر دائمًا، مثلما هو عليه الحال مع فكرة أن المُحتوى يجب أن يكون فوق خط الطّي الوهمي above the fold بحجة أن المُستخدمين لا ينزلون أسفل الصّفحة users don’t scroll. للأسف أصبحت هندسة المعلومات مشبعة بمثل هذه الخرافات، ولهذا أود أن آخذ القليل من الوقت لتبديد بعضٍ منها. أريد أن أبدأ مع الاعتقاد السّائد بأنه يُفترض ببنية المواقع أن تكون منطقيّة. يجب أن تكون بنية موقعك منطقيّةعندما أعمل على بنية موقع مُعيّن فعادة ما أدفع العميل وحتى زملائي إلى حافّة الجنون، حيث أنني لا أجعل بنية موقعي منطقية دائمًا. يوهم الناس أنفسهم بأن هندسة المعلومات تدور حول تنظيم المحتوى بطريقة منطقيّة. ولكنّ الأمر ليس كذلك. المشكلة هي أنّ الناس ليسوا منطقيين، نحن ندعيّ ذلك ولكننا نقوم باتخاذ القرارات بناءً على النزعات الثقافيّة، التنشئة، الأفكار المبلورة سابقًا وغيرها من العوامل. خذ على سبيل المثال سوق الخضر. عندما تقوم بزيارته أين تبحث عن الطماطم؟ تبحث عليها في قسم الخضروات أليس كذلك؟ ولكن لماذا لا تضع الأسواق الطماطم في قسم الفاكهة، فهي فاكهة ولا يُمكن تصنيفها مع الخضروات، حيث أن هذا هو التصّرف المنطقي إلا أنهم لا يقومون بذلك لأن الناس تتوقع رؤية الطماطم مع الخضروات وذلك بسبب أفكارهم المبلورة سابقًا. يجب علينا أن نتخلى عن فكرة أن تكون بنية مواقعنا منطقية بالنسبة لعقولنا، وعوضًا عن ذلك يجب أن تتناسب مع النموذج العقليّ لمستخدمينا سواء كان هذا الأمر منطقيًّا أم لا. يجب على المستخدم أن يكون قادرا إلى الوصول إلى المحتوى بثلاث نقراتفيما يخص المنطق دائمًا، هناك خرافة أخرى قد تبدو منطقيّة وتنصّ على أنه يجب على المستخدم أن يصل إلى المحتوى بـ 3 نقرات كأقصى حدّ، قد يبدو هذا الأمر منطقيّا إلا أنه لسوء الحظ ليس كذلك. بدأت هذه الخرافة من الأيام الأولى للويب عندما كان المستخدمون يستخدمون صلات dial-up. جعلت السرعات البطيئة المستخدمين يشعرون بالإحباط أثناء التصفّح بين العديد من الصفحات، وفسّر هذا الأمر بشكل مغلوط على أنّه مرتبط بعدد النقرات. في الواقع لا يوجد هناك أي دليل لدعم هذه الفرضية بل أن هناك من يقترح بأن عدد النقرات لا يهم. ما يهم عوضًا عن ذلك هو الشعور بالتقدّم إلى الهدف المطلوب. فإن شعر المستخدمون بأنهم يتقدمون، سيكونون سعيدين بالتقدّم بشكلٍ جيد بعيدًا عن النقرات الثلاث السحريّة. يجب أن يكون لديك فقط 7 خيارات (زائد أو ناقص 2)إحدى خرافات الأرقام السحرية الأخرى هي فكرة أنه لا يجب أن يكون لديك أكثر من 7 خيارات (زائد أو ناقص 2) أثناء التصفّح. يعود أصل هذا الاعتقاد إلى بحث في علم نفس أعدّه جورج ميلر. يُعلّل جورج ميلر ذلك بأن الأشخاص لا يستطيعون استيعاب أكثر من 7 خيارات (زائد أو ناقص 2) في ذاكرتهم قصيرة الأمد. إلا أنّ هذا الفرضية خاطئة لسببين: أولًا، هناك بحثُ آخر يقول أننا نجد صعوبات لكي نبقي أكثر من 4 أشياء في ذاكرتنا قصيرة الأمد، ولهذا فإن بطاقات الدّفع الإلكتروني تقوم بجمع الأرقام في مجموعات من أربعة أرقام. ثانيًا، إن صفحة الويب لا تطلب من المستخدم أن يقوم بحفظ الخيارات في الذاكرة قصيرة الأمد وذلك لأن المعلومات تظهر أمامه بشكل بصريّ.تكمن المشكلة في أن الأشخاص يحبون مثل هذه القواعد. قواعد يمكنك متابعتها والتي تجنبك القيام بأمور قد لا ترغب فيها مثل اختبار قابلية الاستخدام. ولكن في الحقيقة هذه هي الطريقة الوحيدة للتأكد مما يصلح من غيره. وبحكم أننا نتحدّث عن الأشياء التي يرغب النّاس في تجنّبها، لنُعرّج على ترتيب الأولويات. من المستحيل تجنب تحديد الأولوياتيُدهشني عدد المنظمات التي تكره تحديد الأولويات. سواء تعلّق الأمر بتحديد الأولويات للأهداف التجارية أو الجمهور. وذلك لأن تحديد الأولويات هو أمر مثير للخلاف. وهذا يعني القول إن قسما ما أكثر أهمية من قسم آخر أو مجموعة واحدة من المستخدمين لديها قيمة أكثر من غيرها. يمكن أن يكون هذا الأمر مشكلة في بعض المنظمات والتي يتراجع أداؤها بسبب غياب تحديد الأوليات. والنتيجة هي موقع على شبكة الإنترنت يحاول إرضاء الجميع وينتهي به المطاف بعدم إرضاء أيّ أحد. فتجدهم يُرتّبون عناصر التّصفّح أبجديا لتجنّب الإساءة لطرف أو لآخر، كما أن عناصر الصّفحة الرّئيسية تظهر بنفس الشّكل لتجنب مشكلة تفضيل عنصر على حساب آخر. ما لا تدركه هذه المنظمات أن تجنب تحديد الأولويات هو أمر مستحيل. فحتى ولو تم ترتيب العناصر أبجديّا، فإن العناصر التي تظهر في أعلى القائمة ستكون مُفضّلة على غيرها. بإمكانك عرض جميع عناصر الصّفحة بنفس الشّكل، لكن سيبدأ المستخدمون بتصفّح الموقع من الزاوية العلوية اليسرى. حاول أن تقوم بذلك، لكنه لا يُمكنك تجنب تحديد الأوليات وبالتالي فمن باب أولى أن تُعطي الأولية لما هو أكثر أهمّيّة. لا يهم إن لم يفهم المستخدم مصطلحا ما، ما لم يكن موجها إليهإحدى الجامعات التي كان لي شرف العمل مثال واضح عن هذا المُشكل، كان لدينا بعض التحفظات حول إذا ما كان مصطلح Alumni مناسبا لوضعه في قائمة التّصفّح الرّئيسية حيث توقّعنا أن بعض الزّوار لن يتمكّنوا من فهمه. في بداية الأمر عارضت الجامعة فكرة تغيير المصطلح، بحجة أن الناس الذين لا يقدرون على فهم مصطلح Alumni هم غير مناسبون لمؤسستهم، لكنهم قاموا بتغيير رأيهم عندما أشرنا لهم أن الطّلبة الذين لا تكون الإنجليزية لغتهم الأم لن يفهموا المُصطلح، حيث أن نسبة ليست صغيرة من مداخيل الجامعة مصدرها الطّلبة الأجانب. ثم ما لبثوا أن وقعوا في فخ المُغالطة التي يقع فيها الكثيرون: "سيتجاهل الزوّار المُصطلح إذا لم يفهموه وسيعتقدون بأنّه غير مُوجّه لهم". ولسوء الحظ هذا ليس صحيحا، فإن واجهت الزّائر مجموعة من الخيارات ولم تكن أيها هي الخطوة القادمة (الصفحة القادمة) التي يجب أن يذهب إليها فإنه من المُحتمل جدًا أن يذهب إلى قسم ما حتّى وإن لم يفهم ما يعنيه له ظانا بأنه سيحتوي على الإجابة التي يبحث عنها. والمزيد من الخرافاتخلاصة القول: القليل من المعرفة خطير ومُضرّ والأمر صحيح حتّى في مجال هندسة المعلومات ونفس الأمر مع تجربة المُستخدم. يجب أن نحذر أي النّظريات والقواعد يجب أن نُصدّق ونتّبع، حيث أنه يجب علينا أن نبحث ونحقّق من الأمر بأنفسنا ونُبث صحّته أو خطأه عبر التّجربة. ترجمة -وبتصرّف- للمقال What you know about information architecture, might not be true لصاحبه Paul Boag. حقوق الصورة البارزة: Infographic vector designed by Freepik.

إن الهدف من إعداد وتجهيز المخططات الهيكلية (Wireframes) لمواقع الإنترنت هو حلّ مشاكل التصميم المُرتبطة بتخطيط وتصميم الصّفحة، وترتيب عناصرها، وذلك عبر ابتداع تصوّر للموقع قبل تطويره، وذلك باستخدام جملة من المُمارسات والمبادئ. إن تطبيق مبادئ جشطلت (Gestalt) على العناصر، سيُساعد على تحضير الأفكار بسرعة، فالفكرة من الأساس من العمل على هذا المُستوى من الجودة هو السرعة الّتي تُمكن المُصمّم من اكتشاف الأفكار بدرجة معقولة من الدقّة. تعلّمتُ بعض الطُرق المُفيدة في السنوات الأخيرة، جعلت مني أعمل بإنتاجيّة أكبر مع الحفاظ على الجودة، وبطبعي أكره كتابة عناوين من نوع" أفضل الحيل مع تصاميم المخططات الهيكلية" ولكن بعد عملي مع مُصممين قليلي الخبرة، وجدت أنّ بعض هذه المواضيع تحدث بشكل متكرّر ومن الضروري الإشارة إليها. 1. كل شيء مهم وذو معنى كل تلوين، كل خطّ، كل ظل، كل تدرّج لوني، كل شيء يَهم وله معنى، فاستخدام حواف وإطارات غير متقطّعة (solid)، وخلفيّة ملوّنة، وظلالًا، قد يكون أمرًا لا لزوم لها، خاصّة أنّ هذه العناصر يُمكن أنّ تنتقل إلى مرحلة التصميم والتطوير، وبدون أنّ يُفكّر بها مليًّا، فيجب على كل شيء أنّ يكون له معنى، وأنّ لا تُدرج العناصر والرسومات هنا وهناك اعتباطيًّا. الانسجام يُساعد يجدر الانتباه عند استخدام الرسم التمهيدي (sketching) هو أنّ التلوين والخطّ موحد في كامل الرسم (يعني، وجوب تبديل القلم المُستخدم، أو تغيير خطّ اليد من أجل إبراز الاختلاف)، بالإضافة إلى تتكرّر مُشكلة مع المخططات الهيكلية وهي الاختلاف في تدرجات الألوان وعمق السطور والخطّ المُستخدم، جميعها يُدرج ويُستخدم بدون تفكير، الأمر الّذي يجعل من المخطط الهيكلي صعب الفهم والقراءة، ويجعل مني أتساءل في معظم الأحيان: هل التغيير من الخط المُستخدم هنا متعمّد؟ هل هذه الرقعة (label) هي أكبر حجمًا لأنّها أكثر أهميّة؟ وغيره من هذه الأسئلة، ولتجنب هذه المشكلة، من المُستحسن استخدام مجموعة محدّدة من الألوان، (ربّما من 3-5 من اللون الرمادي) ونوعين من الخطوط، واستخدام عناصر HTML الافتراضيّة، مع العلم أنّ هذا قد يؤدي إلى مخططات هيكلية باهتة، ولكن يجب أنّ يُعلم أنّ جميع المخططات الهيكلية ينتهي الأمر بها إلى سهلة المهملات، فليس الغرض منها إبهار الزوّار، إنما الغرض هو تصميم برمجيّة قابلة للاستخدام، أمّا المخطط الهيكلي الخلّاب فهو مضيعة للوقت. إن من الأمور المُهمّة الّتي يجب التركيز عليها هي نقطة الانطلاق، فالبدء مع خطّ أسود، يعني إمكانيّة تكبير وتعريض الخط فقط، الأمر الّذي قد يؤدي إلى جعل المخطط الهيكلي صارخ وحاد بالنسبة لبقيّة الأجزاء، ولكن البدء مع خطّ رمادي، يسمح للمُصمّم بزيادة العمق اللوني وتخفيفه بطبيعة الحال. السرعة والاستكشاف إن الغرض من التصميم ذو الدقّة المُنخفضة ليس التلوين والتحسين، ولكن الغرض هو استكشاف الحلّ الأنسب، حيثُ سيظهر العديد من الحلول، وفقط عن طريق استكشاف بعضها، وصفهم أمام الأعين سيمكّن المُصمّم من التقرير أيها سيَعمل بالشكل الأمثل للمشروع، لقد شرح كانيد بولز كيف يواجه لاعبي الشطرنج تحديًّا مُشابهًا، حيثُ في بداية اللعب، يوجد الكثير من الخيارات، بعضها يُمكن استبعاده عن طريق الغريزة أو عبر الخبرة والممارسة، وتُستكشف باقي الحلول ذهنيًّا، ولذلك سيُعجب المُصمّمون المبتدؤون بفكرتهم الأولى، ويتعلّقون بها ويبذلون جهدًا كبيرًا في تنفيذها مهما تتطلّب الأمر، ولقد وصفَ آندي روتلدج هذه الظاهرة بظاهرة "ملك الخواتم" وذلك في مقالة أكثر من رائعة بعنوان "كنزي العزيز". إن لم يكن بالإمكان تنفيذ التصوّر بسرعة، إذًا فإن التنفيذ يتمّ على الدقّة الخاطئة، فإن كان المخطط الهيكلي يعمل على تقديم نسخة ذات التدرّج الرمادي (grayscale) فقط مما قد تقرّر بناؤه بالفعل، فذلك مضيعة للوقت. النسخة المُطابقة تعطي نتائج أكثر واقعيّة تصدر الأخطاء عادةً من المُصممين الذين ليس لديهم تصوّر مُسبق للمحتوى، فإن كان المشروع يتضمّن معرضًا للصور، فمن المفترض رؤية الصور قبل اتخاذ القرار في إدراجها، والاهتمام بها كميّزة رئيسيّة أو عدم إبرازها لعدم أهميتها، وبشكل مُشابه، إن كان التصميم مبني بالأساس لعرض البيانات، فيجب معرفة ماهيّة هذه البيانات، مع العلم أنّ استخدام البيانات الوهميّة في التصميم الأوّلي تَدفع بالمُصمّم إلى تصاميم مخططات هيكلية تكون فيها العناوين والنصوص مُتناسقة بمثاليّة كبيرة، والصور مُتجاوبة مع التصميم ككل، والأرقام مُلائمة داخل صناديق صغيرة لا تتخطاها، طبعًا هذا أبعد ما يكون عن الواقع، بعبارة أخرى، إن هلاك واجهة المُستخدم يبدأ بالعنوان "لوريم أيبسزم". يجب إتقان التقنيّة المُستخدمة يُمكن للتصميم الخلّاب أنّ يُقدّم حلًّا سيّئًا للمشروع، فإن كان التصميم يتضمّن عناصر HTML مخصّصة، وأزرارًا جذّابة وقوائم مُنسدلة، وحقل بحث ديناميكي بتقنيّة أجاكس، فمن الضروري على المُصمّم أنّ يدرك أنّ لكل مشروع ميزانيّة مُختلفة عن الآخر، وخاصّة إن كان المُصمّم يعرف أساسيّات HTML و CSS و جافا سكريبت، فهو بالتأكيد يعرف ما يُتطلّب لاختبار هذه العناصر على المُتصفحات، وبالتالي على المُصمم أنّ يفكّر مليًّا فيما يُدرج في المخطط الهيكلي، طبعًا قد لا يكون هذا العنصر بذلك التعقيد، وقد يكون متوفّرًا في مكتبة jQuery، ولكن على المصمم أنّ يدرك أنّه لا يوجد شيء يدعى "مجرّد تعديل بسيط"، طبعًا هذا لا يعني عدم إدراج عناصر تفاعليّة في المخطط الهيكلي، ولكن يجب على المُصمم دائمًا معرفة تكلفة كل عنصر يُدرج في التصميم، فبعض المواقع قد تتطلّب هذا النوع من التعقيد، فمثلًا الاهتمام في عنصر اختيار التاريخ قد يكون أمرًا جوهريًا ومطلب أساسي في بعض المواقع، ومن المنطقي جدًا التركيز عليه، ولكن عندما يكون عنصر اختيار التاريخ من أجل "تاريخ الميلاد"، فمن الأفضل استغلال هذا الوقت على أمرٍ أكثر أهميّة فليعمل ما يعمل إن الهدف الرئيسي هو تقديم شيء عمليّ، وليس شيء مثالي، فلا يُبهر بالجماليّات سوء مُصمّمي تجربة المُستخدم UI، بمعنى إن تمّ الرسم والتخطيط باستخدام الورق فقط وبخط اليد، وكان المُصمّم واثقًا من تقديم الحلّ المطلوب، وذلك بتوافق تصميمه مع البيانات المعُطاة من قبل العميل، وكان هذا الرسم رسمًا واضحًا لجميع فريق العمل، فإذًا لا قيمة من إعادة تمثيل هذا الرسم باستخدام المخطط الهيكلي، بمعنى آخر على المُصمّم أنّ يكون عمليًّا، وأن يهتم بتقديم المطلوب وأن يَبتعد عن تصميم تصميمات مثاليّة . مصادر إضافيّةإن جميع المواضيع السابقة هي من واقع الخبرة ونتاج طويل من والتجربة والخطأ، ولتكتمل الصورة، هذه بعض المقالات الهامّة، والّتي ترتبط بالموضوع بشكل مُباشر وغير مُباشر: هيكلة وتوزيع محتوى صفحات الويب.ما هو النّظام اللّوني.أساسيات الوزن البصري في التّصميم الجرافيكي.الاختلافات ما بين التصاميم المسطّحة (flat design) و التصاميم المادية (material design).مدخل إلى عالم الخُطوط.مصادر أجنبية: Gestalt Principles – Andy Rutledge.Good design faster – Leah Buley.Sketching User Experiences – Bill Buxton.ترجمة وبتصرّف للمقال Wireframing for Web Apps.