اختبار قابلية الاستخدام

قيمة الوصول

ماذا لو أخبرتك مصممي مواقع الويب بوجود هناك أشخاص قد يزورون موقعك على الويب لا يهتمون بما يبدو؟

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

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

تأخذ الحبة الزرقاء - تنتهي القصة ، تستيقظ في سريرك وتؤمن بما تريد أن تصدق. كنت تأخذ حبوب منع الحمل الحمراء - كنت البقاء في بلاد العجائب ، وأريكم مدى عمق ذهب أرنب حفرة. - المصفوفة

هل أنت على استعداد للذهاب إلى أرنب الوصول مع الاستمرار؟ سنحتاج للتعمق في الجوانب الفنية لصفحات الويب. HTML هي الهيكل العظمي لصفحة الويب بينما تعمل CSS وجافا سكريبت والصور على تحسين HTML. في كثير من الأحيان يفقد الأشخاص ضعاف البصر كل هذه التحسينات. على الرغم من أن إمكانية الوصول هي مهمة للمطورين ، إلا أن المتطلبات الفنية اللازمة للحفاظ على إمكانية الوصول أو تحسينها تؤثر في مظهر الموقع. وهذا يعني أن كل من التصميم والنسخ وتجربة المستخدم والتطوير يحتاج إلى التعاون للتأكد من إمكانية الوصول إلى عناصر التحكم في التنقل والنماذج والأزرار والعناوين والأزرار والروابط وغير ذلك.

يجب أن يتعاون كل من التصميم والنسخ وتجربة المستخدم والتطوير على التأكد من إمكانية الوصول إلى عناصر التحكم في التنقل والنماذج والأزرار والعناوين والأزرار والروابط وغير ذلك الكثير

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

لاختبار شامل لإمكانية الوصول ، ستحتاج إلى التأكد من أن موقع الويب أو التطبيق يعملان بشكل جيد على كل من قارئات الشاشة العديدة المتاحة. هناك العديد من برامج قراءة الشاشات المجانية و / أو مفتوحة المصدر على كل نظام أساسي بما في ذلك JAWS و NVDA . يمكن لمستخدمي Microsoft استخدام NVDA ، بينما تأتي أجهزة Apple وأجهزة iOS صوت أكثر التي يمكن أن تضخم عناصر تحكم لوحة المفاتيح وقراءة محتويات الشاشة ، وأجهزة يونكس هناك أرك . يحتوي متصفح Chrome على مكونين إضافيين من التقنيات المساعدة ، ChromeVox من لقراءة الشاشة و ChromeVis للتكبير.

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

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

يمكن لـ WAI-ARIA سد الفجوات بين ما يقوله HTML الخام للصفحة وما يراه المستخدمين الذين يشاهدونه

يتم ذلك من خلال استخدام علامات HTML خاصة تسمى وي-ARIA العلامات. يمكن لـ WAI-ARIA (تطبيقات الإنترنت الغنية التي يمكن الوصول إليها) سد الفجوات بين ما يقوله HTML الخام للصفحة وما يراه المستخدمون من خلال توفير طريقة موحدة للمطورين لإضافة معنى إضافي إلى الولايات والممتلكات والعلاقات والأدوار والمناطق الحية قارئ الشاشة وإلا لن يفهم.   يمكن للمطورين استخدام aria- مستوى لشرح الشاشة للقراء التسلسل الهرمي لكل عنوان على الصفحة. مع مطوري العلامة aria يمكنهم إضافة عنوان لوصف الغرض من عنصر منفصل على الصفحة. يساعد ذلك المطورين على إنشاء علاقات واضحة بين العناصر المختلفة. يمكن للمطورين أيضًا جذب الانتباه إلى عناصر التحكم المهمة عن طريق تصنيفها بعلامات aria-role ، على سبيل المثال ، يمكن تسمية زر القائمة المنسدلة بالعلامة التالية: Aria-has popup: true.

انظر القلم علامات تبويب سهلة الاستخدام سكوت فينكل ( svinkle ) على CodePen .

في HTML في المثال أعلاه ، يتم إنشاء علامات التبويب باستخدام قائمة غير مرتبة بفئات في كل عنصر قائمة. يلتقط jQuery أحداث النقر عندما يتم النقر فوق علامة تبويب ويضيف "aria-selected": 'true' و 'tab-widget__tab-content — active' إلى علامة التبويب المحددة ويخفي علامات التبويب الأخرى عن طريق إضافة 'aria-selected': ' كاذبة "لباقي علامات التبويب. في السطر 127 ، يتم تعيين السمات الأولية لعلامات التبويب ، تساعد هذه القصاصات معًا برامج قراءة الشاشة على التعرف على علامة التبويب التي تكون مرئية. تضيف JavaScript على الخط 35 أيضًا دعم لوحة المفاتيح لعلامات التبويب. يعالج باقي الملف أحداث النقر و لوحة المفاتيح بحيث يمكن أن تضيف jQuery سمات "الدور" و "العرض التقديمي" إلى علامة التبويب المحددة حاليًا.

يمكن لعلامات Aria أن تساعد قارئات الشاشة على تفسير عناصر التحكم المخصصة كأزرار إذاعية عند تسمية عنصر التحكم المخصص بـ: Aria-role = زر الاختيار. عندما يحتوي أحد التطبيقات على منطقة وضع الحماية التي تنقل التعليقات أو التحديثات للمستخدم ، يمكن تصنيفها بعلامة منطقة حية: Aria-live. يضمن هذا أنه عند تغيير النص على هذا العنصر ، سيتم نطقه تلقائيًا للمستخدم من خلال قارئ الشاشة.

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

تحتفظ W3 بالمواصفات الكاملة لـ WAI-ARIA مثل مواصفات HTML نفسها في إطار مبادرة الوصول إلى الويب (WAI) ولكن أحيانًا قد تكون الإرشادات أكثر فائدة من المواصفات ، لذا فإليك بعض الإرشادات العامة للمصممين:

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

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

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