قد يبدو الحكم على سهولة الوصول 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
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.