تطبيقي كان حصناً منيعاً أمام ذوي الإعاقة: كيف أنقذتني سمات ARIA من جحيم الاستبعاد الرقمي؟

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

في ليلة من الليالي، وأنا بقلّب في البريد الإلكتروني، لمحت رسالة بعنوان غريب: “محاولة فاشلة لاستخدام تطبيقك الرائع”. فتحت الرسالة بفضول، وكانت من شاب اسمه “أحمد”. بدأ أحمد رسالته بمدح التصميم والأفكار، لكن بعدها… بدأ الكابوس.

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

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

الصدمة الأولى: لما تطبيقي “الرائع” كان كابوسًا لغيري

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

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

ما هي إمكانية الوصول (Accessibility)؟ وليش هي “مش رفاهية”؟

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

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

• للمستخدمين العاديين: في ظروف معينة، مثل استخدام التطبيق تحت أشعة الشمس الساطعة (تباين الألوان مهم)، أو بيد واحدة (سهولة النقر).
• لكبار السن: الذين قد يعانون من ضعف في البصر أو صعوبة في استخدام الفأرة.
• لمحركات البحث (SEO): بنية الصفحة الواضحة والدلالية التي تساعد قوارئ الشاشة، تساعد أيضاً عناكب البحث على فهم موقعك بشكل أفضل.

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

المنقذ ARIA: جسر التواصل بين الكود وقارئات الشاشة

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

شو قصة الـ ARIA هاي؟

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

بكلمات أبسط، ARIA هي المترجم اللي بيوصف لقارئ الشاشة شو عم بصير على الشاشة، خصوصاً مع المكونات المعقدة اللي بنبنيها بـ JavaScript.

متى نستخدم ARIA؟ القاعدة الذهبية

قبل ما نغوص في الأمثلة، لازم تعرف أهم قاعدة في عالم ARIA، وهي: “القاعدة الأولى لـ ARIA هي… لا تستخدم ARIA”.

غريب، صح؟ المقصد من هذه القاعدة هو: دائماً وأبداً، استخدم عناصر HTML الدلالية (Semantic HTML) الأصلية كلما أمكن. إذا كنت تريد زراً، استخدم <button> وليس <div>. إذا كنت تريد رابطاً، استخدم <a href="...">. هذه العناصر تأتي مع إمكانية وصول مدمجة (Built-in accessibility) من المصنع، وتفهمها المتصفحات وقارئات الشاشة بدون أي مجهود إضافي منك.

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

جولة عملية: كيف حوّلت “حصني المنيع” إلى بيت يرحب بالجميع

خلونا نشوف أمثلة حقيقية من تطبيقي وكيف استخدمت ARIA لإصلاح المشاكل.

المشكلة الأولى: الأزرار الغامضة (Buttons without context)

كان عندي أزرار للحذف والحفظ عبارة عن أيقونات فقط، مكتوبة بهذا الشكل:

<!-- الكود السيء -->
<div class="icon-save"></div>

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

الحل باستخدام ARIA:

الحل الأفضل هو استخدام عنصر <button>، لكن إذا كان لا بد من استخدام <div> لأسباب تتعلق بالتصميم، يمكننا جعله سهل الوصول كالتالي:

<!-- الكود الجيد -->
<div 
  class="icon-save" 
  role="button" 
  tabindex="0" 
  aria-label="حفظ المهمة">
</div>

• role="button": تخبر قارئ الشاشة أن هذا العنصر يتصرف كـ “زر”.
• tabindex="0": تجعل العنصر قابلاً للوصول إليه والتركيز عليه باستخدام زر Tab في لوحة المفاتيح.
• aria-label="حفظ المهمة": هذه هي الجوهرة. هي التي توفر “النص البديل” الذي سيقرأه قارئ الشاشة بصوت عالٍ. الآن عندما يصل المستخدم إلى هذا العنصر، سيسمع: “حفظ المهمة، زر”.

المشكلة الثانية: النماذج (Forms) الصامتة ورسائل الخطأ

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

الحل باستخدام ARIA:

لربط رسائل الخطأ بشكل برمجي مع حقول الإدخال، نستخدم aria-describedby.

<!-- الكود الجيد -->
<label for="user-email">البريد الإلكتروني</label>
<input 
  type="email" 
  id="user-email" 
  aria-describedby="email-error" 
  aria-invalid="true">
<div id="email-error" role="alert">
  الرجاء إدخال بريد إلكتروني صالح.
</div>

• aria-describedby="email-error": تخبر قارئ الشاشة أن هناك وصفاً إضافياً لهذا الحقل موجود في العنصر الذي يحمل id="email-error". عندما يركز المستخدم على حقل الإدخال، سيقرأ قارئ الشاشة الملصق (Label) ثم يقرأ رسالة الخطأ.
• aria-invalid="true": تخبر قارئ الشاشة أن القيمة الحالية في الحقل غير صالحة.
• role="alert": على عنصر الخطأ تجعل قارئ الشاشة يقرأ الرسالة فور ظهورها (بشكل تلقائي)، لتنبيه المستخدم مباشرة.

المشكلة الثالثة: المحتوى الديناميكي المفاجئ

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

الحل باستخدام ARIA Live Regions:

مناطق ARIA الحية (Live Regions) هي الحل. هي مناطق في الصفحة نطلب من قارئ الشاشة أن يراقبها ويعلن عن أي تغييرات تحدث بداخلها.

<!-- حاوية الإشعارات في كود HTML -->
<div id="notifications" aria-live="polite" aria-atomic="true"></div>

<!-- وعندما يحدث شيء، نضيف المحتوى بـ JavaScript -->
<script>
  function showNotification(message) {
    const notificationArea = document.getElementById('notifications');
    notificationArea.textContent = message;
  }

  // مثال الاستخدام
  // showNotification('تمت إضافة المهمة بنجاح');
</script>

• aria-live="polite": تخبر قارئ الشاشة أن يعلن عن التغييرات في هذه المنطقة عندما ينتهي من قراءة ما يقرأه حالياً. (الخيار الآخر هو assertive وهو يقاطع المستخدم فوراً، ويستخدم فقط للتنبيهات الحرجة جداً).
• aria-atomic="true": تضمن أن قارئ الشاشة سيقرأ المنطقة بأكملها كوحدة واحدة عند حدوث تغيير، وليس فقط الجزء الذي تغير.

المشكلة الرابعة: حالة العناصر التفاعلية (State Management)

كان لدي قائمة “أكورديون” للأسئلة الشائعة. بصرياً، يمكنك رؤية القسم المفتوح والمغلق. لكن قارئ الشاشة كان يقرأ العناوين فقط، دون أن يعرف حالتها.

الحل باستخدام ARIA States:

<!-- الكود الجيد لأكورديون -->
<h3>
  <button 
    aria-expanded="false" 
    aria-controls="section1">
    السؤال الأول: كيف أبدأ؟
  </button>
</h3>
<div id="section1" role="region" hidden>
  <p>هنا تضع الإجابة على السؤال الأول...</p>
</div>

عندما يضغط المستخدم على الزر، نقوم بتغيير قيمة aria-expanded باستخدام JavaScript:

• aria-expanded="false": تخبر قارئ الشاشة أن القسم المرتبط بهذا الزر “مطوي” أو مغلق. عندما يضغط المستخدم عليه، يجب أن نغير القيمة إلى "true". الآن سيسمع المستخدم: “السؤال الأول، زر، مطوي”. وعند الضغط: “السؤال الأول، زر، موسّع”.
• aria-controls="section1": تربط الزر بالقسم الذي يتحكم فيه.

نصائح أبو عمر الذهبية لإمكانية وصول من الآخر

1. ابدأ من اليوم الأول: لا تؤجل إمكانية الوصول لنهاية المشروع. اجعلها جزءاً من عملية التصميم والتطوير من البداية. إصلاحها لاحقاً يكلف أكثر بكثير.
2. استخدم الأدوات المساعدة: هناك أدوات رائعة تساعدك على اكتشاف المشاكل، مثل Lighthouse في أدوات مطوري كروم، وإضافة axe DevTools للمتصفح.
3. جرّب بنفسك: هذه أهم نصيحة. حاول تصفح موقعك باستخدام لوحة المفاتيح فقط (بدون فأرة). هل يمكنك الوصول لكل شيء؟ ثم، قم بتثبيت قارئ شاشة مجاني مثل NVDA (للويندوز) أو استخدم VoiceOver (المدمج في أجهزة آبل) وحاول استخدام تطبيقك. هذه التجربة ستفتح عينيك على عالم جديد تماماً.
4. HTML الدلالي هو الأساس: قبل أن تفكر في ARIA، اسأل نفسك: “هل يوجد عنصر HTML أصلي يقوم بهذه الوظيفة؟”. استخدم <nav>, <main>, <header>, <footer>, <button>… إلخ.

الخلاصة: من مطور “أناني” إلى مدافع عن الشمولية الرقمية

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

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