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

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

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

يُعد كل اختبار - التكنولوجيا الآلية واليدوية والمساعدة - أمرًا بالغ الأهمية لتحقيق أكثر منتج يسهل الوصول إليه.

تعتمد اختباراتنا على إرشادات إتاحة محتوى الويب (WCAG) 2.1 مستوى المطابقة A وAA كمقاييس لدينا. تذكر أن مجال عملك أو نوع المنتج أو القوانين والسياسات المحلية/الخاصة بالبلد أو أهداف سهولة الوصول العامة ستحدد الإرشادات التي يجب اتباعها والمستويات التي يجب تلبيتها. إذا لم تكن بحاجة إلى معيار محدد لمشروعك، فننصحك باتباع أحدث إصدار من WCAG. يمكنك الرجوع إلى "كيف يتم قياس إمكانية الوصول الرقمي؟" للحصول على معلومات عامة حول عمليات تدقيق إمكانية الوصول، وأنواع/مستويات المطابقة، وإرشادات إتاحة محتوى الويب، والتدفق.

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

أساسيات الاختبار المبرمَج

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

مزايا اختبارات إمكانية الوصول الآلية:

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

سلبيات اختبارات إمكانية الوصول التلقائية:

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

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

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

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

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

تعتمد الأداة التلقائية التي تختار استخدامها على عدة عوامل، منها:

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

وثمة العديد من العوامل الإضافية التي يجب وضعها في الاعتبار أيضًا. راجع مقالة 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] أكبر من 0. تشير القيمة الأكبر من 0 إلى طلب تنقل صريح. على الرغم من صحة ذلك تقنيًّا، غالبًا ما يؤدي إلى إنشاء تجارب محبطة للمستخدمين الذين يعتمدون على التكنولوجيا المساعدة. مزيد من المعلومات حول قواعد فهرسة Tab

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

يُرجى حلّ المشكلة.

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

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

الخطوة 6

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

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

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

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

التحقّق من استيعابك

اختبر معلوماتك عن اختبار إمكانية الوصول التلقائي