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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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