اختبار مبرمَج لإمكانية الوصول

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

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

كل اختبار، سواء كان مبرمَجًا أو يدويًا أو باستخدام تكنولوجيا مساعِدة، مهم لتحقيق أكبر قدر ممكن من إمكانية الوصول إلى المنتج. تستند اختباراتنا إلى مستوى المطابقة A وAA ضمن الإصدار 2.1 من "إرشادات إتاحة محتوى الويب" (WCAG) كمعايير.

تذكَّر أنّ المجال الذي تعمل فيه أو نوع منتجك أو القوانين والسياسات المحلية أو الوطنية أو أهداف تسهيل الاستخدام بشكل عام هي التي تحدّد الإرشادات التي يجب اتّباعها والمستويات التي يجب استيفاؤها. إذا لم تكن بحاجة إلى معيار محدّد لمشروعك، ننصحك باتّباع أحدث إصدار من إرشادات WCAG. يمكنك الرجوع إلى القسم كيف يتم قياس إمكانية الوصول الرقمي؟ للحصول على معلومات عامة حول عمليات تدقيق إمكانية الوصول وأنواع/مستويات التوافق وإرشادات WCAG ومبادئ POUR.

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

• إجراء اختبارات قابلية الاستخدام مع أشخاص يعانون من عجز
• توظيف أشخاص من ذوي الاحتياجات الخاصة للعمل في فريقك
• استشارة فرد أو شركة لديهما خبرة في تسهيل استخدام المحتوى الرقمي

أساسيات الاختبار الآلي

تستخدم اختبارات إمكانية الوصول المبرمَجة برامج لفحص منتجك الرقمي بحثًا عن مشاكل متعلّقة بإمكانية الوصول استنادًا إلى معايير محدّدة مسبقًا للتوافق مع متطلبات إمكانية الوصول.

مزايا اختبارات تسهيل الاستخدام المبرمَجة:

• تكرار الاختبارات بسرعة في مراحل مختلفة من دورة حياة المنتج
• لا تتطلّب العملية سوى بضع خطوات بسيطة وستحصل على النتائج بسرعة كبيرة.
• لا تحتاج إلى معرفة كبيرة بميزات تسهيل الاستخدام لتشغيل الاختبارات أو فهم النتائج.

عيوب اختبارات سهولة الاستخدام المبرمَجة:

• لا ترصد الأدوات المبرمَجة جميع أخطاء تسهيل الاستخدام في منتجك
• تم الإبلاغ عن حالات إيجابية خاطئة (تم الإبلاغ عن مشكلة لا تشكّل انتهاكًا حقيقيًا لمعايير WCAG)
• قد تحتاج إلى أدوات متعددة لأنواع المنتجات والأدوار المختلفة

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

أنواع الأدوات المبرمَجة

تم تطوير إحدى أولى أدوات اختبار إمكانية الوصول الآلية على الإنترنت في عام 1996 من قِبل "مركز التكنولوجيا الخاصة التطبيقية" (CAST)، وأُطلق عليها اسم "تقرير بوبي". يتوفّر اليوم أكثر من 100 أداة اختبار آلي يمكنك الاختيار من بينها.

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

يمكن أن يعتمد اختيارك للأداة الآلية على العديد من العوامل، بما في ذلك:

• ما هي معايير ومستويات المطابقة التي تختبرها؟ وقد يشمل ذلك معايير WCAG 2.2 أو WCAG 2.1 أو الفقرة 508 من قانون إعادة التأهيل في الولايات المتحدة أو قائمة معدّلة من قواعد تسهيل الاستخدام.
• ما هو نوع المنتج الرقمي الذي تختبره؟ يمكن أن يكون هذا المنتج موقعًا إلكترونيًا أو تطبيق ويب أو تطبيقًا أصليًا لنظام الجهاز الجوّال أو ملف PDF أو كشكًا أو منتجًا آخر.
• ما هو الجزء الذي تختبر فيه منتجك من دورة حياة تطوير البرامج؟
• كم من الوقت يستغرق إعداد الأداة واستخدامها؟ هل هي فرد أو فريق أو شركة؟
• من سيجري الاختبار: المصمّمون أو المطوّرون أو فريق ضمان الجودة أو شخص آخر؟
• ما هو عدد المرات التي تريد فيها التحقّق من إمكانية الوصول؟ ما هي التفاصيل التي يجب تضمينها في التقرير؟ هل يجب ربط المشاكل مباشرةً بنظام تذاكر؟
• ما هي الأدوات الأنسب لبيئتك؟ لفريقك؟

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

العرض التوضيحي: اختبار مبرمَج

بالنسبة إلى العرض التوضيحي لاختبار تسهيل الاستخدام المبرمَج، سنستخدم Lighthouse من Chrome. ‫Lighthouse هي أداة مبرمَجة ومفتوحة المصدر تم إنشاؤها لتحسين جودة صفحات الويب من خلال أنواع مختلفة من عمليات التدقيق، مثل الأداء وتحسين محركات البحث وتسهيل الاستخدام.

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

الخطوة 1

باستخدام متصفّح Chrome، ثبِّت إضافة Lighthouse.

هناك العديد من الطرق لدمج Lighthouse في عملية سير عمل الاختبار. نستخدم إضافة Chrome في هذا العرض التوضيحي.

الخطوة 2

لقد أنشأنا عرضًا توضيحيًا في CodePen. يمكنك الاطّلاع عليه في وضع تصحيح الأخطاء للمتابعة إلى الاختبارات التالية. هذا الإجراء مهم لأنه يزيل <iframe> الذي يحيط بصفحة الويب التجريبية، ما قد يتعارض مع بعض أدوات الاختبار.

مزيد من المعلومات حول وضع تصحيح الأخطاء في CodePen

الخطوة 3

افتح "أدوات مطوّري البرامج في Chrome" وانتقِل إلى علامة التبويب Lighthouse. محو جميع خيارات الفئات باستثناء "تسهيل الاستخدام" اترك الوضع كإعداد تلقائي واختَر نوع الجهاز الذي ستجري عليه الاختبارات.

الخطوة 4

انقر على تحليل أداء تحميل الصفحة وانتظِر إلى أن تنتهي Lighthouse من إجراء اختباراتها.

بعد اكتمال الاختبارات، تعرض أداة Lighthouse نتيجة تقيس مدى سهولة استخدام المنتج الذي تختبره. ويتم احتساب نتيجة Lighthouse من خلال عدد المشاكل وأنواعها وتأثيرها في المستخدمين.

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

الخطوة 5

الآن، راجِع مثالاً لكل مشكلة من مشاكل تسهيل الاستخدام التي تم رصدها تلقائيًا، وعدِّل الأنماط وعلامات الترميز ذات الصلة.

المشكلة 1: أدوار ARIA

تنص المشكلة الأولى على ما يلي: "إنّ العناصر التي تتضمّن ARIA [role] والتي تتطلب عناصر ثانوية للاحتواء على عنصر [role] محدّد لا تتضمّن بعض هذه العناصر الثانوية المطلوبة أو جميعها. يجب أن تحتوي بعض أدوار ARIA الرئيسية على أدوار ثانوية محدَّدة لأداء وظائف إمكانية الوصول المقصودة. مزيد من المعلومات حول قواعد أدوار ARIA

في العرض التوضيحي، يتعذّر النقر على زر الاشتراك في النشرة الإخبارية:

<button role="list" type="submit" tabindex="1">Subscribe</button>

لنحاول إصلاح هذه المشكلة.

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

<button type="submit" tabindex="1">Subscribe</button>

المشكلة 2: ARIA مخفية

تحتوي عناصر "[aria-hidden="true"] على عناصر تابعة قابلة للتركيز. العناصر التابعة التي يمكن التركيز عليها ضِمن عنصر [aria-hidden="true"] تمنع إتاحة العناصر التفاعلية لمستخدمي التكنولوجيا المساعِدة، مثل برامج قراءة الشاشة. مزيد من المعلومات حول قواعد aria-hidden

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

لنحاول إصلاح هذه المشكلة.

تم تطبيق السمة aria-hidden="true" على حقل الإدخال. تؤدي إضافة هذه السمة إلى إخفاء العنصر (وكل العناصر المتداخلة تحته) عن التكنولوجيات المساعدة.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

في هذه الحالة، عليك إزالة هذه السمة من الإدخال للسماح للمستخدمين الذين يعتمدون على تكنولوجيات مساعدة بالوصول إلى حقل النموذج وإدخال المعلومات فيه.

المشكلة 3: اسم الزر

لا تحتوي الأزرار على اسم العنصر الظاهر على واجهة المستخدم. عندما لا يحتوي زر على اسم عنصر ظاهر على واجهة المستخدم، تشير برامج قراءة الشاشة إليه باسم "زر"، ما يجعله غير قابل للاستخدام بالنسبة إلى المستخدمين الذين يعتمدون على برامج قراءة الشاشة.

مزيد من المعلومات عن قواعد أسماء الأزرار

<button role="list" type="submit" tabindex="1">Subscribe</button>

لنحاول إصلاح هذه المشكلة.

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

<button type="submit" tabindex="1">Subscribe</button>

المشكلة 4: سمات النص البديل للصور

عناصر الصور لا تتضمّن سمات [alt]. يجب أن تتضمن العناصر الإعلامية نصًا بديلاً وصفيًا وقصيرًا. يمكن تجاهل العناصر غير الضرورية من خلال استخدام سمة نص بديل فارغة. مزيد من المعلومات حول قواعد النص البديل للصور

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

لنحاول إصلاح هذه المشكلة.

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

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

المشكلة 5: نص الرابط

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

<a href="#!"><svg><path>...</path></svg></a>

لنحاول إصلاح هذه المشكلة.

يجب أن تتضمّن جميع الصور القابلة للنقر على الصفحة معلومات حول المكان الذي ينقل إليه الرابط المستخدمين. إحدى طرق حلّ هذه المشكلة هي إضافة نص بديل إلى الصورة يوضّح الغرض منها، كما فعلت مع صورة الشعار في المثال. تعمل هذه الطريقة بشكل رائع مع الصور التي تستخدم علامة <img>، ولكن لا يمكن استخدامها مع علامات <svg>.

بالنسبة إلى رموز وسائل التواصل الاجتماعي التي تستخدم علامات <svg>، يمكنك استخدام نمط وصف بديل مختلف يستهدف ملفات رسومات موجّهة يمكن تغيير حجمها (SVG)، أو إضافة المعلومات بين علامتَي <a> و<svg> ثم إخفاؤها بصريًا عن المستخدمين، أو إضافة ARIA متوافق، أو خيارات أخرى. استنادًا إلى البيئة وقيود الرمز، قد تكون إحدى الطريقتين أفضل من الأخرى.

استخدِم أبسط خيار للنمط مع أكبر تغطية لتكنولوجيات تسهيل الاستخدام، وهو إضافة role="img" إلى العلامة <svg> وتضمين العنصر <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

المشكلة 6: تباين الألوان

لا تحتوي ألوان الخلفية والمقدّمة على نسبة تباين كافية. تستحيل أو تصعب على كثير من المستخدمين قراءة النص المنخفض التباين. مزيد من المعلومات حول قواعد تباين الألوان

تم الإبلاغ عن مثالَين.

لنحلّ هذه المشكلة.

تم رصد العديد من مشاكل تباين الألوان على صفحة الويب. كما تعلّمت في وحدة اللون والتباين، يجب أن تبلغ نسبة تباين الألوان في النصوص العادية الحجم (أقل من 18 نقطة / 24 بكسل) 4.5:1، بينما يجب أن تبلغ نسبة تباين الألوان في النصوص الكبيرة الحجم (18 نقطة / 24 بكسل على الأقل أو 14 نقطة / 18.5 بكسل بخط غامق) والرموز الأساسية 3:1.

بالنسبة إلى عنوان الصفحة، يجب أن يستوفي النص باللون الأزرق المخضر متطلبات تباين الألوان بنسبة 3:1 لأنّه نص كبير الحجم يبلغ 24 بكسل. ومع ذلك، تُعدّ أزرار اللون الأزرق المخضر نصًا عادي الحجم بخط عريض يبلغ 16 بكسل، لذا يجب أن تستوفي متطلبات تباين الألوان بنسبة 4.5:1.

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

لا يستوفي كل النص الرمادي على الخلفية البيضاء معايير تباين الألوان، باستثناء العنوانَين الأكبر حجمًا على الصفحة. يجب تعتيم هذا النص لاستيفاء متطلبات تباين الألوان بنسبة 4.5:1.

المشكلة 7: بنية القائمة

عناصر القائمة (<li>) غير مضمّنة في العناصر الرئيسية <ul> أو <ol> تتطلّب برامج قراءة الشاشة عناصر قائمة (<li>) يجب تضمينها في عنصر رئيسي <ul> أو <ol> حتى يتم الإعلان عنها بشكلٍ صحيح.

مزيد من المعلومات عن قواعد القوائم

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

لنحاول إصلاح هذه المشكلة.

استخدمنا فئة CSS في هذا العرض التوضيحي لمحاكاة القائمة غير المرتبة بدلاً من استخدام علامة <ul>. وعندما كتبنا هذا الرمز بشكل غير صحيح، أزلنا ميزات HTML الدلالية المضمّنة في هذه العلامة. من خلال استبدال الفئة بعلامة <ul> حقيقية وتعديل CSS ذي الصلة، يمكننا حلّ مشكلة تسهيل الاستخدام هذه.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

المشكلة 8: tabindex

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

<button type="submit" tabindex="1">Subscribe</button>

لنحاول إصلاح هذه المشكلة.

ما لم يكن هناك سبب محدّد لتعطيل ترتيب الانتقال الطبيعي بين علامات التبويب على صفحة ويب، لن تحتاج إلى استخدام عدد صحيح موجب في سمة tabindex. للحفاظ على ترتيب التنقل الطبيعي باستخدام مفتاح Tab، يمكننا إما تغيير قيمة tabindex إلى 0 أو إزالة السمة تمامًا.

<button type="submit">Subscribe</button>

الخطوة 6

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

لقد طبّقنا كل هذه التعديلات التلقائية المتعلقة بتسهيل الاستخدام على CodePen جديد.

الخطوة التالية

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