accessibilty: ما هي إمكانية الوصول وما هي أهميتها لذوي الإعاقات؟

• يعاني 1 من كل 10 أشخاص من إعاقة شديدة.
• 1 من كل 2 من الأشخاص الذين تزيد أعمارهم عن 65 عامًا لديهم قدرات منخفضة.

تشمل الإعاقات العمى أو الصمم أو المعاقين أو أي اضطرابات في الجسم.

يمكن لمنتج برمجي أن يلبي احتياجات هذا السوق الكبير، إذا تم جعله مناسبًا للمعاقين.

السبب الثاني

الالتزام بالتشريعات الخاصة بإمكانية الوصول

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

فيما يلي الإجراءات القانونية من قبل مختلف الحكومات –

• الولايات المتحدة: قانون الأمريكيين ذوي الإعاقة – 1990
• المملكة المتحدة: قانون التمييز ضد المعوقين – 1995
• أستراليا: قانون التمييز ضد المعوقين – 1992
• أيرلندا: قانون الإعاقة لعام 2005

يعد اختبار إمكانية الوصول أمرًا مهمًا لضمان الامتثال القانوني.

السبب ألثالث

تجنب الدعاوى القانونية المحتملة

في الماضي، تمت مقاضاة شركات Fortune 500 لأن منتجاتها لم تكن صديقة للمعاقين. هنا بعض الحالات البارزة

• الاتحاد الوطني للمكفوفين (NFB) ضد أمازون (2007)
• Sexton و NFB مقابل الهدف (2007)
• تسوية NFB مقابل AOL (1999)

من الأفضل إنشاء منتجات تدعم المعاقين وتتجنب الدعاوى القضائية المحتملة.

ما هي الإعاقات التي يجب دعمها؟

يجب أن يدعم التطبيق الأشخاص ذوي الإعاقة مثل:

كيف يتم اختبار إمكانية الوصول accessibilty؟

يمكن إجراء اختبار إمكانية الوصول بطريقتين، وهما:

1. يدوي
2. الآلي

فيما يلي احتياجات النقطة التي يجب التحقق منها للتطبيق ليتم استخدامها من قبل جميع المستخدمين. تُستخدم قائمة التحقق هذه للتوقيع على اختبار إمكانية الوصول “accessibilty”

1. ما إذا كان التطبيق يوفر معادلات لوحة المفاتيح لجميع عمليات الماوس والنوافذ؟
2. ما إذا كانت التعليمات مقدمة كجزء من وثائق المستخدم أو الدليل؟ هل من السهل فهم التطبيق وتشغيله باستخدام الوثائق؟
3. ما إذا كانت علامات التبويب مرتبة منطقيًا لضمان التنقل السلس؟
4. ما إذا كانت مفاتيح الاختصار متوفرة للقوائم؟
5. ما إذا كان التطبيق يدعم جميع أنظمة التشغيل؟
6. ما إذا كان وقت الاستجابة لكل شاشة أو صفحة مذكورًا بوضوح حتى يعرف المستخدمون كم من الوقت ينتظرون؟
7. ما إذا كانت جميع الملصقات مكتوبة بشكل صحيح في التطبيق؟
8. ما إذا كان لون التطبيق مرنًا لجميع المستخدمين؟
9. ما إذا كانت الصور أو الرموز مستخدمة بشكل مناسب، بحيث يسهل على المستخدمين فهمها؟
10. ما إذا كان التطبيق يحتوي على تنبيهات صوتية؟
11. ما إذا كان المستخدم قادرًا على ضبط عناصر التحكم في الصوت أو الفيديو؟
12. ما إذا كان يمكن للمستخدم تجاوز الخطوط الافتراضية للطباعة وعرض النص؟
13. ما إذا كان يمكن للمستخدم ضبط أو تعطيل الشاشات الوامضة أو الدوارة أو المتحركة؟
14. تحقق للتأكد من عدم استخدام الترميز اللوني مطلقًا باعتباره الوسيلة الوحيدة لنقل المعلومات أو الإشارة إلى إجراء ما
15. ما إذا كان التمييز قابل للعرض بألوان مقلوبة؟ اختبار اللون في التطبيق عن طريق تغيير نسبة التباين؟
16. هل يتم سماع المحتوى المرتبط بالصوت والفيديو بشكل صحيح من قبل الأشخاص ذوي الإعاقة؟ اختبر جميع صفحات الوسائط المتعددة بدون مكبرات صوت في مواقع الويب.
17. هل يتم توفير التدريب للمستخدمين ذوي الإعاقة التي ستمكنهم من التعرف على البرنامج أو التطبيق؟

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

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

1) فقد البصر

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

للوصول للموقع الذي يريده هناك برنامج اسمه  SCREENREADER. قارئ الشاشة.

ما هو قارئ الشاشة هذا؟

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

سوف يروي قارئ الشاشة كل شيء بالنسبة للمستخدم.

بشكل أساسي، عند بدء تشغيل برنامج jaws أو أي قارئ شاشة ثم الانتقال إلى موقع الويب، فسوف يروي لك المحتوى الكامل. على سبيل المثال: لقد بدأت jaws، وبدأت المتصفح، سيعلن JAWS أن صفحة بدء Mozilla Firefox، والآن إذا انتقلت إلى شريط العناوين، فسيعلن JAWS عن ADDRESS BAR ثم اكتب www.google.com في شريط العناوين، فسيذهب jaws لشرح إلى حد ما مثل هذا: –

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

الآن إذا تم تصميم موقع ويب وتطويره بشكل سيئ، فقد يكون من الممكن (يحدث بشكل عام) أن البرنامج لن يكون قادرًا على سرد المحتوى الصحيح والذي بدوره يؤدي إلى عدم إمكانية الوصول “accessibilty” إلى الشخص المكفوف.

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

2) الإعاقة البصرية

هناك فئتان أريد أن أذكرهما تحت ضعف البصر.

الأول هو عمى الألوان.

عمى الألوان يعني عدم العمى تمامًا ولكن عدم القدرة على رؤية بعض الألوان المحددة بشكل صحيح.

الأحمر والأزرق هما الألوان الشائعة التي لا يستطيع الناس رؤيتها بشكل صحيح إذا كان لديهم عمى الألوان. إذن، إذا كان لدي عمى ألوان من اللون الأحمر وأريد استخدام موقع ويب 80٪ باللون الأحمر إذن؟ هل سأكون مرتاحًا لهذا الموقع؟ الجواب لا.

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

3) ضعف البصر

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

1) في مثل هذه الحالات، فإن أفضل ما يمكنك فعله هو تجنب النصوص الصغيرة. لأنها ستكون مشكلة كبيرة للأشخاص الذين يعانون من ضعف البصر.

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

4) إعاقة أخرى

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

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