مرحبًا بكم مجددًا 👋
استكمالاً لما كتبته حول مبادئ سهولة الوصول الأربعة، سأتحدث في هذه السلسلة حول المبدأ الأول، ألا وهو قابلية التصور.
سأتطرق لإرشادات التنفيذ ومعايير قياس نجاحه، إضافةً إلى نصائح تقنية جمعتها خلا لسنوات خبرتي في هذا المجال.
#سهولة_الوصول #مواقع #تطبيقات #تقنية
استكمالاً لما كتبته حول مبادئ سهولة الوصول الأربعة، سأتحدث في هذه السلسلة حول المبدأ الأول، ألا وهو قابلية التصور.
سأتطرق لإرشادات التنفيذ ومعايير قياس نجاحه، إضافةً إلى نصائح تقنية جمعتها خلا لسنوات خبرتي في هذا المجال.
#سهولة_الوصول #مواقع #تطبيقات #تقنية
تعني قابلية التصور (Perceivability) عرض المعلومات وعناصر الواجهة بطريقة يمكن للمستخدم تصورها. ويشمل ذلك وصف الصور نصيًّا، وإضافة وصف صوتي للمقاطع المرئية للمعاقين بصريًّا، وإضافة نصوص أو لغة الإشارة لللمعاقين سمعيًّا، وإضافة تسميات توضيحية لكافة الخيارات وعناصر التحكم، وغيرها.
إذا كان المحتوى غير نصي، فيجب توفير محتوى بديل يمكن للمستخدم تصوره. وتمكن التقنيات المساعدة الأشخاص ذوي الإعاقة من الاستفادة من المحتوى البديل بعدة صور، كقراءته بشكل مكبر، أو تحويله إلى نص منطوق، أو عرضه على عارض بريل إلكتروني لقراءته بطريقة بريل.
ويستثنى من ذلك ما يلي:
ويستثنى من ذلك ما يلي:
1. مربعات الإدخال وعناصر التحكم: إذا كان المحتوى غير النصي يرتبط بمربع إدخال أو عنصر تحكم، فيجب توفير تسميات توضيحية تعبر عن وظيفته بدلاً من وصف المحتوى المرتبط به.
على سبيل المثال: ترتبط أيقونة العدسة المكبرة في أذهان الناس بوظيفة البحث. ولكن عند تسمية مربع البحث لمستخدمي التقنيات المساعدة، يجب عدم كتابة "عدسة مكبرة" إذ أن ذلك لا يوحي للمستخدم المعاق بصريًّا بوظيفة العنصر الذي يتعامل معه.
في بعض الحالات، تقلل التسمية التوضيحية لعنصر ما من جمالية الواجهة، أو لا يكون هنالك ضرورة لوجودها.
على سبيل المثال: تُعَد أيقونة العدسة المكبرة دلالة واضحة على البحث، ولذا، فإننا نحتاج في هذه الحالات إلى تسمية توضيحية لمستخدمي التقنيات المساعدة دون غيرهم.
على سبيل المثال: تُعَد أيقونة العدسة المكبرة دلالة واضحة على البحث، ولذا، فإننا نحتاج في هذه الحالات إلى تسمية توضيحية لمستخدمي التقنيات المساعدة دون غيرهم.
يمكننا القيام بذلك في برمجة واجهات الويب باستخدام خاصية (aria-label) والتي تُظْهِر التسمية التوضيحية لمستخدم التقنيات المساعدة فقط، وتكون مخفية للمستخدمين الآخرين:
developer.mozilla.org
developer.mozilla.org
في لغة Swift, يمكننا القيام بنفس الإجراء من خلال خاصية (accessibility(label:))، أما عن لغة ObjectiveC فهي تستخدم خاصية (AccessibilityLabel) لتحقيق ذلك:
developer.apple.com
developer.apple.com
developer.apple.com
developer.apple.com
2. المحتوى المبني على الوقت كالمقاطع المرئية: إذا كان المحتوى غير النصي عبارةً عن مقطع مرئي أو صوتي، فيتم وصف محتواه نصيًّا بشكل مبسط قبل بداية المحتوى ومن ثم إدراج الأوصاف الصوتية أو لغة الإشارة أو التسميات التوضيحية داخل المقطع نفسه.
على سبيل المثال: يتم كتابة المحتوى التالي في الواجهة قبل مقطع فيديو لفيلم سيعرض قريبًا: "فيديو تشويقي للفيلم". ومن ثم يتم إدراج الفيديو المحتوي على الوصف الصوتي أسفل النص.
ويفصل المرجع التالي في طرق إدراج الوصف الصوتي أو النصي في المقاطع المرئية:
w3.org
w3.org
3. الاختبارات: إذا كان وصف المحتوى غير النصي يؤدي إلى كشف إجابة سؤال معين، فيجب وصفه بما يكفي لإيصال الصورة إلى المستخدم دون كشف إجابة السؤال.
على سبيل المثال: إذا كان هنالك صورة لبرج المملكة في الرياض ويجب اختيار إجابة معينة عن ماهيته، فيمكن وصف صورة البرج بأنه "أحد الأبراج في مدينة الرياض، يبلغ طوله 302 متر".
4. الحواس: إذا ارتبط المحتوى النصي بتجربة حسية، فيجب وصف التجربة الحسية للمستخدم بما يكفي لإيصال الصورة الذهنية إليه.
على سبيل المثال: إذا صفَّق الحضور في فيلم معين، فيمكن وصف المشهد نصيًّا لذوي الإعاقة السمعية بأنه "تصفيق حار".
على سبيل المثال: إذا صفَّق الحضور في فيلم معين، فيمكن وصف المشهد نصيًّا لذوي الإعاقة السمعية بأنه "تصفيق حار".
5. التحقق البصري: إذا كانت وظيفة المحتوى غير النصي هي التحقق من المستخدم، فيجب وصف صورة التحقق على أنها "رمز تحقق مرئي" وإيجاد طرق بديلة تعتمد على حواس أخرى لتمكين المستخدم من تنفيذ العملية.
على سبيل المثال: يجب توفير محتوى تحدي صوتي لتمكين المعاقين بصريًّا من تخطي التحقق المرئي، ويعرض هذا المحتوى أرقامًا أو كلمات يسمعها المستخدم ويقوم بإدخالها بدلاً من الموجودة في الصورة. ولا يُفضَّل استخدام العمليات الحسابية؛ لصعوبة استيعابها في بعض حالات الإعاقة الإدراكية.
6. المحتوى الجمالي: إذا كان المحتوى غير النصي موجودًا لتجميل الصفحة، ولم يكن مرتبطًا بأي معاني أخرى تهم المستخدم، فيجب عدم عرضه لمستخدمي التقنيات المساعدة.
على سبيل المثال: إذا كانت هنالك صورة لوردة تظهر في بداية المقال، وكانت هذه الصورة لتجميل المقال لا أكثر.
على سبيل المثال: إذا كانت هنالك صورة لوردة تظهر في بداية المقال، وكانت هذه الصورة لتجميل المقال لا أكثر.
لإدراج وصف للصور، يمكن استعمال خاصية (alt) والموجودة ضمن خصائص HTML, ولإخفائها لمستخدمي التقنيات المساعدة، يمكن إبقاء قيمة alt خالية.
ويمكن استخدام label في لغتَي Swift و ObjectiveC لتوفير أوصاف للصور، أو إخفائها من خلال خاصية Hidden.
#attr-alt" target="_blank" rel="noopener" onclick="event.stopPropagation()">developer.mozilla.org
ويمكن استخدام label في لغتَي Swift و ObjectiveC لتوفير أوصاف للصور، أو إخفائها من خلال خاصية Hidden.
#attr-alt" target="_blank" rel="noopener" onclick="event.stopPropagation()">developer.mozilla.org
عند إنشاء محتوى الواجهة، يجب أن لا يكون اللون هو الأداة الوحيدة لإيصال المعلومات إلى المستخدم، بل يجب استعمال النصوص لتدعيم ذلك.
على سبيل المثال: إذا كان اللون الأحمر يدل على خطأ في الإدخال، فيجب وضع نص يدل على ذلك لمساعدة مستخدمي التقنيات المساعدة على فهم ما يجري.
على سبيل المثال: إذا كان اللون الأحمر يدل على خطأ في الإدخال، فيجب وضع نص يدل على ذلك لمساعدة مستخدمي التقنيات المساعدة على فهم ما يجري.
يؤثر مكان عناصر الواجهة في الكود البرمجي بشكل كبير على تجربة مستخدمي التقنيات المساعدة. ولذا، فإنه من المهم جدًّا ترتيبها بشكل منطقي في الكود البرمجي.
على سبيل المثال: يقوم بعض مطوري الواجهات بكتابة عناصر الواجهة من اليسار إلى اليمين لِتُعْرَض بشكل صحيح في الواجهات العربية!
على سبيل المثال: يقوم بعض مطوري الواجهات بكتابة عناصر الواجهة من اليسار إلى اليمين لِتُعْرَض بشكل صحيح في الواجهات العربية!
ولكن هذا يؤدي إلى قراءة التقنيات المساعدة لهذه العناصر بشكل مقلوب، إذ أنها تقرأها بناءً على مكانها في الكود البرمجي. ولذا يجب استعمال خصائص التصميم الأخرى لتغيير أماكن العناصر بدلاً من كتابتها برمجيًّا بهذا الشكل.
من المهم ربط التسميات التوضيحية بعناصرها برمجيًّا، إذ يمكن ذلك التقنيات المساعدة من معرفة ماهية العناصر وكيفية التعامل معها.
على سبيل المثال: يقوم بعض مطوري الواجهات بكتابة تسمية حقل معين بجانب الحقل، ولكنهم لا يستعملون خصائص التسميات التوضيحية (مثل <label> في خصائص HTML) مما يؤدي إلى عدم اكتشاف التقنيات المساعدة للربط بين هذه التسميات والحقول الخاصة بها.
يجب أن يكون هنالك تباين بين ألوان العناصر وخلفية الصفحة بما يعادل 4.5:1، ويستثنى من ذلك الشعارات.
بالنسبة للنصوص أو الصور كبيرة الحجم، فإن التباين يكون فيها بما يعادل 3:1.
بالنسبة للنصوص أو الصور كبيرة الحجم، فإن التباين يكون فيها بما يعادل 3:1.
يُمَكِّن إطار Flutter المطورين من إضافة هذه الخصائص من خلال (Semantics class):
api.flutter.dev
api.flutter.dev
كانت هذه نظرة سريعة على قابلية التصور، وهو المبدأ الأول من مبادئ سهولة الوصول، وهنالك العديد من الأمور التي لم يسعفني الوقت للتطرق إليها، ويمكن لمن أراد الاستزادة الانتقال إلى صفحة المرجع السريع لمبادئ النفاذ إلى محتوى الويب من موقع منظمة الويب العالمية:
w3.org
w3.org
ألقاكم بإذن الله قريبًا للحديث حول المبدأ الثاني: قابلية الاستخدام، وهو أهم المبادئ الأربعة وأكثرها إهمالاً (مع كل أسف).
كما ويسعدني الإجابة عن استفساراتكم بكل رحابة صدر.
دمتم سُعَداء. 😊
كما ويسعدني الإجابة عن استفساراتكم بكل رحابة صدر.
دمتم سُعَداء. 😊
جاري تحميل الاقتراحات...