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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الخطوة 1

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

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

الخطوة 2

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

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

الخطوة 3

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

الخطوة 4

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

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

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

الخطوة 5

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

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

تنص المشكلة الأولى على ما يلي: "عناصر 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>

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

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

<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.

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

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

التحقق من فهمك

اختبر معلوماتك حول اختبار إمكانية الوصول الآلي