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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الخطوة 1

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

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

الخطوة 2

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

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

الخطوة 3

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

الخطوة 4

انقر على تحليل أداء تحميل الصفحة وامنح Lighthouse وقتًا لتشغيل اختباراته.

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

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

الخطوة 5

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

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

تنص المشكلة الأولى على ما يلي: "العناصر التي تتضمّن [role] في ARIA والتي تتطلب عناصر ثانوية للاحتواء على [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. للحفاظ على ترتيب الانتقال الطبيعي بعلامة التبويب، يمكننا إما تغيير tabindex إلى 0 أو إزالة السمة تمامًا.

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

الخطوة 6

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

لقد طبّقنا كل هذه التعديلات المبرمَجة في إمكانية الوصول على CodePen جديد. CodePen

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

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