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

يا أهلاً فيكم، معكم أبو عمر.

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

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

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

الصحوة المؤلمة: عندما تدرك أنك تبني جدراناً لا جسوراً

في اجتماع الفريق التالي، طرحت الموضوع. بالبداية، كانت ردود الفعل متباينة. البعض شعر بنفس الصدمة اللي حسيت فيها، والبعض الآخر قلل من حجم المشكلة: “كم عدد المستخدمين المكفوفين أصلاً؟”، “هاي شغلة بدها وقت وميزانية ما عنا ياها حالياً”.

هنا كان لازم أكون حاسم. الوصولية الرقمية (Digital Accessibility) مش “ميزة إضافية” أو “لمسة لطيفة”. هي حق أساسي للمستخدم، وجزء لا يتجزأ من أي منتج رقمي محترم. الأمر لا يتعلق بالأرقام والإحصائيات، بل بالمبدأ. هل نريد أن نبني منتجات تخدم الجميع، أم نريد أن نبني جدراناً تزيد من عزلة الناس؟

قررنا نتبنى معايير الوصولية العالمية (Web Content Accessibility Guidelines – WCAG) كدستور لعملنا. ومن هنا، بدأت رحلتنا مع عالم جديد بالنسبة للكثيرين في الفريق: عالم ARIA.

ما هي ARIA بالضبط؟ وهل هي تعويذة سحرية؟

ببساطة، ARIA (Accessible Rich Internet Applications) هي مجموعة من السمات (Attributes) اللي بنضيفها على عناصر HTML. وظيفتها مش تغيير شكل العنصر أو طريقة عمله، بل هي بتضيف “طبقة وصفية” فوقه، عشان برامج قراءة الشاشة (Screen Readers) تفهم شو هاد العنصر وشو بيعمل.

تخيل إنك دخلت مبنى حكومي ضخم، وكل الأبواب والغرف متشابهة وما عليها أي لافتات. رح تضيع، صح؟ هاد هو حال المستخدم الكفيف مع تطبيقنا قبل التعديل. ARIA هي اللافتات اللي بنحطها على الأبواب والغرف، هي اللي بتحكي لقارئ الشاشة: “هذا زر الإعدادات”، “هذه قائمة الخيارات الرئيسية”، “أنت الآن في التبويب الثاني من ثلاثة”.

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

الغوص في التفاصيل: كيف طبقنا ARIA خطوة بخطوة

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

الحالة الأولى: الزر الغامض (The Mysterious Button)

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

الحل: استخدام السمة aria-label.

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

<!-- قبل -->
<button class="settings-btn">
  <i class="fa fa-cog"></i>
</button>

<!-- بعد -->
<button class="settings-btn" aria-label="الإعدادات">
  <i class="fa fa-cog" aria-hidden="true"></i> <!-- نخفي الأيقونة نفسها عن قارئ الشاشة -->
</button>

بسطر واحد، تحول الزر الغامض إلى “زر الإعدادات”.

الحالة الثانية: التبويبات المفقودة (The Lost Tabs)

كانت واجهة المستخدم الرئيسية في التطبيق عبارة عن نظام تبويبات (Tabs) بنيناه باستخدام عناصر <div> و JavaScript. بالنسبة لقارئ الشاشة، كانت هاي مجرد مجموعة من الـ divs المتجاورة، بدون أي معنى أو سياق.

الحل: استخدام أدوار (roles) وحالات (states) ARIA.

استخدمنا مجموعة من السمات عشان نوصف العلاقة بين عناصر التبويبات والمحتوى التابع لكل تبويب.

• role="tablist": للحاوية التي تضم كل أزرار التبويبات.
• role="tab": لكل زر من أزرار التبويبات.
• aria-selected="true/false": لتحديد التبويب النشط حالياً.
• role="tabpanel": لحاوية المحتوى الخاصة بكل تبويب.
• aria-controls و id: لربط كل زر تبويب بالمحتوى الخاص به.

<!-- أصبح الكود مفهوماً للآلة -->
<div role="tablist" aria-label="القائمة الرئيسية">
  <button role="tab" aria-selected="true" id="tab1" aria-controls="panel1">
    الرئيسية
  </button>
  <button role="tab" aria-selected="false" id="tab2" aria-controls="panel2">
    ملفي الشخصي
  </button>
</div>

<div role="tabpanel" id="panel1" aria-labelledby="tab1">
  <p>محتوى الصفحة الرئيسية...</p>
</div>
<div role="tabpanel" id="panel2" aria-labelledby="tab2" hidden>
  <p>محتوى ملفي الشخصي...</p>
</div>

الآن، قارئ الشاشة يخبر المستخدم: “أنت في قائمة تبويبات، التبويب الأول من اثنين، الرئيسية، محدد.” يا له من فرق!

الحالة الرابعة: الإشعارات الخفية (The Invisible Notifications)

لما المستخدم كان يحفظ تغييرات، كان يظهر إشعار صغير في زاوية الشاشة لمدة ثانيتين ويختفي (Toast Notification). المستخدم الكفيف لم يكن لديه أي فكرة أن عملية الحفظ نجحت أو فشلت.

الحل: استخدام المناطق الحية aria-live.

هذه السمة السحرية تخبر قارئ الشاشة أن يراقب منطقة معينة في الصفحة، وأي تغيير يحدث فيها يجب أن يُقرأ فوراً (أو عندما ينتهي المستخدم من مهمته الحالية).

<!-- نضع هذا الـ div في أي مكان بالصفحة، ويفضل أن يكون فارغاً في البداية -->
<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" تعني أن قارئ الشاشة سينتظر حتى ينهي المستخدم ما يفعله ثم يقرأ الإشعار. أما إذا استخدمنا aria-live="assertive"، فسيقاطع قارئ الشاشة كل شيء ويقرأ الإشعار فوراً، وهذا نستخدمه للحالات الطارئة جداً.

نصائح من قلب الميدان (يا خَال)

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

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

الخلاصة: من الإقصاء إلى الاحتواء.. رحلة تستحق العناء

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

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

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