تطبيقي كان يستبعد المستخدمين: كيف أنقذتني إرشادات WCAG من جحيم التصميم الإقصائي؟

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

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

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

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

ما هي ‘إرشادات الوصول إلى محتوى الويب’ (WCAG)؟ وليش لازم تهتم؟

بعد الصدمة الأولى، بلشت أبحث زي المجنون عن حل. وكل الطرق كانت تؤدي إلى اختصار واحد: WCAG. هالاختصار يعني “Web Content Accessibility Guidelines” أو “إرشادات الوصول إلى محتوى الويب”.

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

• مشاكل في البصر (عمى الألوان، ضعف النظر، العمى الكلي).
• مشاكل في السمع.
• مشاكل حركية (صعوبة في استخدام الفأرة).
• صعوبات إدراكية وتعلمية.

هذه الإرشادات مبنية على أربعة مبادئ أساسية، بحب أسميها “أعمدة الوصولية الأربعة” (اختصارها POUR):

1. قابل للإدراك (Perceivable)

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

2. قابل للتشغيل (Operable)

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

3. قابل للفهم (Understandable)

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

4. متين (Robust)

المحتوى لازم يكون “متين” كفاية عشان تقدر تفسره مجموعة واسعة من التقنيات المساعدة (مثل قارئات الشاشة) والمتصفحات المختلفة حاليًا ومستقبلًا. هاد بيتحقق غالبًا عن طريق كتابة كود نظيف واستخدام معايير الويب الصحيحة (مثل HTML الدلالي).

كيف بدأت رحلتي مع WCAG: الدروس اللي تعلمتها بالطريقة الصعبة

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

الكارثة الأولى: تباين الألوان (Color Contrast)

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

معيار WCAG AA (المستوى المقبول) بطلب نسبة تباين (contrast ratio) لا تقل عن 4.5:1 للنص العادي. لما فحصت ألواني، النسبة كانت 2.5:1… كارثة!

الحل: استخدمت أدوات فحص التباين (مثل Adobe Color Contrast Analyzer أو أدوات المطور في المتصفح) لتعديل الألوان. رفعت درجة سطوع النص وقللت سطوع الخلفية بشكل بسيط لحد ما وصلت لنسبة تباين ممتازة فوق 6:1.

مثال بالكود (CSS):

/* ❌ الكود السيء - تباين ضعيف */
.card-text {
  color: #888888; /* رمادي فاتح */
  background-color: #333333; /* رمادي غامق */
  /* نسبة التباين هنا: 2.97:1 - فشل */
}

/* ✅ الكود الجيد - تباين عالي */
.card-text {
  color: #E0E0E0; /* رمادي أفتح بكثير */
  background-color: #333333; /* رمادي غامق */
  /* نسبة التباين هنا: 7.85:1 - نجاح باهر */
}

المصيبة الثانية: التنقل عبر لوحة المفاتيح (Keyboard Navigation)

كنت من عشاق بناء المكونات الخاصة فيي. كل الأزرار والقوائم المنسدلة كنت بانيها باستخدام <div> مع شوية JavaScript. المشكلة؟ الـ <div> بشكل افتراضي ما بتقدر توصلها بالكيبورد عن طريق زر Tab.

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

الحل: كان له شقين. الأول والأسهل هو استخدام عناصر HTML الدلالية كل ما أمكن. بدل ما أخترع زر من <div>، ليش ما أستخدم <button>؟ المتصفح بيعطيك ميزات الوصولية مجانًا معه.

الشق الثاني كان للمكونات المعقدة اللي لازم أبنيها بنفسي. هون تعلمت عن سمات ARIA (Accessible Rich Internet Applications) و tabindex.

مثال بالكود:

<!-- ❌ الطريقة السيئة -->
<div class="custom-button" onclick="submitForm()">إرسال</div>

<!-- ✅ الطريقة الأفضل (دلالية) -->
<button class="real-button" onclick="submitForm()">إرسال</button>

<!-- ✅ طريقة بديلة للمكونات المخصصة -->
<div class="custom-button"
     role="button"
     tabindex="0"
     onclick="submitForm()"
     onkeydown="event.key === 'Enter' && submitForm()">
  إرسال
</div>

لاحظ في المثال الأخير كيف أضفنا role="button" عشان نخبر قارئ الشاشة إن هاد العنصر وظيفته زر، و tabindex="0" عشان نخليه قابل للوصول بالكيبورد، وأضفنا حدث onkeydown عشان نسمح بتفعيله بزر Enter.

الدرس الثالث: النصوص البديلة والصور (Alt Text)

تطبيقي كان مليان أيقونات وصور توضيحية جميلة. بس للأسف، ما كنت حاطط ولا نص بديل واحد (alt text). بالنسبة لمستخدمي قارئات الشاشة، كانت هاي الصور مجرد “صورة” أو “رابط” بدون أي معنى. أيقونة الحفظ؟ مجرد “صورة”. صورة المستخدم؟ مجرد “صورة”.

الحل: رجعت على كل صورة وأيقونة في التطبيق وسألت نفسي: “شو وظيفة هاي الصورة؟”.

• إذا كانت الصورة بتقدم معلومة مهمة (مثل أيقونة “حذف”)، كتبت نص بديل وصفي ومختصر: alt="حذف العنصر".
• إذا كانت الصورة مجرد زخرفة أو شكل جمالي (مثل خط فاصل مزخرف)، تركت النص البديل فارغ: alt="". هذا بخلي قارئ الشاشة يتجاهلها تمامًا وما يزعج المستخدم فيها.

مثال بالكود:

<!-- ❌ سيء جدًا -->
<img src="trash-icon.svg">

<!-- ✅ جيد (صورة ذات معنى) -->
<img src="trash-icon.svg" alt="حذف">

<!-- ✅ جيد (صورة للزخرفة فقط) -->
<img src="decorative-line.png" alt="">

أدوات ونصائح عملية من “ختيار” في البرمجة

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

1. استخدم الأدوات المساعدة

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

والأهم: جرب شغل قارئ الشاشة على جهازك (VoiceOver على Mac، NVDA على Windows، TalkBack على Android) وحاول تستخدم تطبيقك. راح تتفاجأ وتتعلم كثير من هالتجربة.

2. فكّر في التصميم الشامل من اليوم الأول

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

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

3. اعشق HTML الدلالي (Semantic HTML)

قبل ما تفكر تكتب <div>، اسأل حالك: هل في عنصر HTML موجود أصلًا بيوصف هاد الجزء من الصفحة؟ بدل <div class="header"> استخدم <header>. بدل <div class="nav"> استخدم <nav>. بدل <span> عشان تعمل زر، استخدم <button>. هاي العناصر بتيجي مع “وصولية مدمجة” بتوفر عليك شغل كثير.

الخلاصة: من مطور “فنان” إلى مطور “إنسان” 👨‍💻❤️

هذيك الرسالة من الشب اللطيف كانت نقطة تحول في مسيرتي المهنية. حولتني من مطور همه الوحيد يبني أشياء “رائعة” من وجهة نظره، إلى مطور همه يبني أشياء “شاملة” ومتاحة للجميع.

الجميل في الموضوع أن التصميم الشامل لا يفيد فقط ذوي الاحتياجات الخاصة. تباين الألوان الجيد يساعد أي شخص يستخدم التطبيق في الخارج تحت الشمس. التنقل السهل بالكيبورد يعشقه المستخدمون المحترفون (Power Users). التسميات الواضحة والنصوص المفهومة تفيد الجميع بدون استثناء.

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