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

مفهوم إمكانية الوصول

تحدث الكثيرون وأسهبوا في مفهوم إمكانية الوصول، ولعلي أختصر ما قرأت بالقول: أن إمكانية الوصول تعني “ملاءمة التطبيق أو الموقع لكل المستخدمين، أيًّا كانت أجهزتهم أو التحديات التي يواجهونها.”

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

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

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

تحدٍّ جديد: إنها لعبة الصور المتشابهة!

ضمن دورة تطوير مواقع الويب التي تقدمها أكاديمية مسك بالتعاون مع Udacity, والتي أَخُوض غمارها حاليًّا، طُلِبَ منا إنجاز لعبة الصور المتشابهة باستخدام لغات HTML, CSS وَJavascript لتكون عبارة عن صفحة ويب يمكن استخدامها من خلال أي متصفح على أي جهاز كان.

طريقة اللعب

وللإيضاح أكثر، إليكم طريقة لعب الصور المتشابهة:

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

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

في سيارة تمشي في طرقات جدة، اعترفت لأحد الأصدقاء بأن هذا المشروع ممل إلى حد كبير، فكيف يمكن تحويل لعبة تعتمد بشكل كامل على البصر إلى لعبة يمكن لشخص كفيف أن يستمتع بها؟! ساد الصمت برهةً من الوقت، ثم أجابني صديقي قائلاً: “طيب إنتا خليها متوافقة، أكيد في طريقة، وأنا رح أساعدك بالبحث”.

بدأ صديقي بالبحث، وكذلك فعلت أنا، ووصلت إلى مبادئ كانت الأساس لعملي على هذا المشروع بأكمله.

قبل البدء، دعوني أشارككم بنتيجة عملي: لعبة الصور المتشابهة، متوافقة مع برامج قراءة الشاشة

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

العب الآن

عرض اللعبة على GitHub

والآن أصدقائي وصديقاتي المطورين: حانت لحظة البداية الحقيقية!

مبادئ في إمكانية الوصول لمواقع الويب

عندما بدأت العمل على لعبة الصور المتشابهة طمعًا في أن يلعبها مَن هم على شاكلتي من بني عميان، كان هنالك مجموعة من المبادئ الأولية والتي ينبغي علي الالتزام بها، بُغْيَةَ العدل والمساواة بيننا وبين الأصدقاء والصديقات من المبصرين. (تَحَزُّب؟ لا والله أحبكم كثير ). وكانت تلك المبادئ على النحو التالي:

عدم تأثير خصائص إمكانية الوصول بأي حال على التصميم البصري للعبة

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

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

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

استخدام العناصر الافتراضية عند بناء الصفحة ما أمكن، وإدراج خصائص إمكانية الوصول بداخلها

وإليكم مجموعة من الخصائص التي يجب إدراجها لضمان توافقية الصفحات مع برامج قراءة الشاشة:

• role: ويتم من خلالها إعلام قارئ الشاشة بوظيفة العنصر الحالي. فعند تصميم لعبة الصور المتشابهة، كان من غير الممكن استعمال عنصر "<button>" الافتراضي؛ لأنه يتعارض مع التصميم المطلوب للبطاقات، ولذلك قمت باستعمال العنصر "<span>" والذي يعطيني حرية أكبر في التصميم، وأضفت إليه الخاصية: role="button" لإعلام قارئ الشاشة أن هذا العنصر هو عبارة عن زر.
• tabindex: ويمكن من خلالها تحديد ما إذا كان العنصر قابلاً للوصول من خلال الضغط على مفتاح Tab, وعادةً ما يستخدم هذا المفتاح للتنقل بين عناصر الصفحة التفاعلية من خلال برامج قراءة الشاشة. يجب على المطور عدم استخدام هذه الخاصية إلا عند الحاجة فقط، كما هو الحال عند إنشاء أزرار مخصصة كما في النقطة السابقة. وينصح عادةً باستخدام إحدى قيمتين:
  • 0: وتدل على أن العنصر قابل للوصول باستخدام مفتاح Tab.
  • -1: وتدل على أن العنصر غير قابل للوصول باستخدام مفتاح Tab, ولكن يمكن الوصول إليه برمجيًّا من خلال Javascript, وتستخدم هذه الطريقة عند إنشاء تطبيقات ويب متوافقة مع برامج قراءة الشاشة.
• alt: ويتم من خلاله إدراج وصف لأي صورة على الصفحة. وعلى الرغم من أن هذه الخاصية تفيد برامج قراءة الشاشة، إلا أنها تفيد المستخدمين الذين لا يستطيعون تحميل الصورة لأي سبب، كما وتفيد محركات البحث والأرشفة أيضًا.

استخدام خصائص ARIA المتعددة لجعل اللعبة قابلة للوصول باستخدام برامج قراءة الشاشة

Accessible Rich Internet Applications (ARIA) هي مجموعة من الخصائص التي تعنى بجعل تطبيقات الويب (وخاصةً تلك التي تستخدم Javascript) أكثر توافقية مع التقنيات المساعدة ومن ضمنها برامج قراءة الشاشة. فهي تساعد على إيصال المعلومات إلى تلك البرامج عندما لا يكون ذلك ممكنًا من خلال لغة HTML وحدها.

على سبيل المثال: يمكن جعل برامج قراءة الشاشة تراقب محتوى متغير على الصفحة، لتقوم بالإعلان عن أي تغيرات تطرأ عليه تلقائيًّا، وعادةً ما تستخدم خصائص ARIA في تطبيقات الويب المختلفة مثل Google Docs, وبعض الألعاب الخاصة بالمكفوفين كلعبة Playroom.

وهنالك الكثير من الخصائص المتفرعة من ARIA, ولعلي أدرج ما استخدمته في لعبتي منها هنا:

• aria-label: ويمكن من خلالها إضافة اسم لأي عنصر، دون أن يظهر على الشاشة. وقد استخدمت هذه الخاصية من خلال Javascript لإظهار وإخفاء أسماء البطاقات عند الحاجة، حيث أنها عبارة عن صور، ولذا كان يجب إضافة أسماء لها باستخدام هذه الخاصية.
• aria-live: ويمكن من خلالها تحديد عنصر أو مجموعة من العناصر، ليتم مراقبتها من قبل برامج قراءة الشاشة والإعلان عن أي تغيرات تطرأ عليها. وقد قمت باستخدامها للإعلان عن عدد الحركات التي قام بها اللاعب، إضافةً إلى درجته في اللعبة. ويمكن التحكم بطريقة إعلان برامج قراءة الشاشة عن هذه التغيرات بإحدى القيمتين التاليتين:
  • “polite”: مما يعني انتظار برامج قراءة الشاشة حتى الانتهاء من قراءة النص الحالي، ومن ثم قراءة المعلومات المتغيرة، ويُنصَح باستخدامه للمعلومات المتغيرة على الصفحة والتي لا تحتاج إجراءً عاجلاً.
  • “assertive”: وهنا يتم مقاطعة برامج قراءة الشاشة وقراءة المعلومات المتغيرة مباشرةً، ويُنصَح باستخدامها للأخطاء والرسائل العاجلة.
• aria-atomic: وتعلم هذه الخاصية برامج قراءة الشاشة عما إذا كان يجب قراءة العنصر كاملاً عند وجود أي تغيير، أو قراءة النص المتغير فقط. وتأخذ قيمة true أو false مع كون False قيمة افتراضية.
• aria-hidden: وتمكننا هذه الخاصية من إخفاء أي عنصر عن برامج قراءة الشاشة، مع المحافظة على وجوده في الصفحة بصريًّا. ويُنصَح باستخدامه لإخفاء الأيقونات أو أي عناصر قد تسبب ارتباكًا لمستخدمي التقنيات المساعدة.

عقبات وتحديات

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

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

ومع أني قمت بتغيير خاصية aria-hidden المذكورة أعلاه لتكون بقيمة false, إلى أن Voiceover لا يزال يرفض إظهار البطاقات، على عكس برامج قراءة الشاشة الأخرى التي أظهرتها دون مشاكل.

إضافةً إلى ما ذكرْتُهُ أعلاه، فإن لغة HTML4 لا تدعم خصائص ARIA, وكذلك برامج قراءة الشاشة والمتصفحات القديمة، ولذا يُفَضَّل الاستعاضة عن خصائص ARIA بخصائص HTML Semantics ما أمكن؛ لأنها تتوافق مع برامج قراءة الشاشة والمتصفحات القديمة.

التجربة فالتجربة فالتجربة…

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

أذكر أنني مررت بتجارب كثيرة كان العمل فيها يسير على ما يرام باستخدام برنامج NVDA ومتصفح Google Chrome, ولكن الأمر اختلف تمامًا مع JAWS باستخدام Firefox وكنت أحتاج للمزيد من العمل لجعل الواجهة تعمل بشكل مماثل أو مقارب لما هو الحال عليه في Chrome.

هنالك الكثير بعد!

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

إمكانية الوصول ليست ميزة، إنما هي متطلب أساسي

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

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

---

يسعدني مشاركتكم للمقال، وإرسال التعليقات إلي عبر حسابي على Twitter.