“تطبيقك جميل… لكنه لا يراني”: صفعة أيقظتني من غفلتي
قبل عدة سنوات، كنت في قمة حماسي. أطلقت للتو تطبيقاً كنت أعمل عليه لأشهر طويلة، تطبيق لحجز المواعيد وتنظيمها، واجهته كانت “آخر موضة”، ألوانه عصرية، وتأثيراته الحركية سلسة. كنت أفتح التطبيق كل يوم وأتأمل تحفتي الفنية، وأنا أقول لنفسي: “عاش يا أبو عمر، شغلك نظيف”.
بدأت التعليقات الإيجابية تنهال، وزاد غروري معها. إلى أن وصلتني تلك الرسالة على البريد الإلكتروني. كانت من شخص اسمه “خالد”، وبدأت رسالته بكلمات لن أنساها ما حييت: “أستاذ أبو عمر، يعطيك العافية. تطبيقك يبدو جميلاً جداً من وصف الأصدقاء، لكن للأسف، أنا كفيف، وتطبيقك بالنسبة لي هو مجرد شاشة صامتة. قارئ الشاشة لا يقرأ شيئاً، ولا أستطيع حجز موعد واحد. أتمنى أن تأخذ ملاحظتي بعين الاعتبار”.
قرأت الرسالة مرة، ومرتين، وعشر مرات. شعرت بالدم يغلي في عروقي، ليس غضباً من خالد، بل غضباً من نفسي. “يا خيبة المسعى!”، همست لنفسي. أنا، المبرمج الخبير الذي يتغنى بالتقنيات الحديثة، بنيت جداراً عازلاً، حصناً منيعاً يستثني شريحة كاملة من المجتمع. كل تلك الأناقة البصرية، كل تلك الأكواد المعقدة، كانت بلا قيمة حقيقية لأنها أقصت إنساناً. شعرت بالخجل، وبأنني فشلت في أهم مبدأ من مبادئ الهندسة: حل المشاكل للجميع، وليس لفئة معينة. كانت تلك اللحظة هي بداية رحلتي الحقيقية مع ما يُعرف بـ “الوصول الرقمي” أو “Digital Accessibility”.
ما هي معايير الوصول الرقمي (WCAG)؟ وليش هي مهمة إلنا كمطورين؟
في خضم بحثي عن حل، تعثرتُ بهذا الاختصار: WCAG (Web Content Accessibility Guidelines). في البداية، ظننته مجرد مجموعة أخرى من القواعد والبيروقراطية التقنية المملة. لكن كلما تعمقت فيه، اكتشفت أنه ليس مجرد “قائمة مهام”، بل هو فلسفة ومنهجية عمل. هو الدليل الذي يضمن أن ما نبنيه على الويب يكون متاحاً للجميع، بغض النظر عن قدراتهم الجسدية أو العقلية.
تستند هذه المعايير على أربعة مبادئ أساسية، سهلة الحفظ والتذكر بكلمة POUR:
- Perceivable (يمكن إدراكه): يجب أن تكون المعلومات ومكونات واجهة المستخدم قابلة للإدراك من قبل المستخدمين. ببساطة، لا يمكن أن يكون المحتوى “خفياً” عن حواسهم. هذا يعني توفير بدائل نصية للصور، وترجمة نصية للفيديوهات.
- Operable (يمكن تشغيله): يجب أن تكون مكونات واجهة المستخدم والتنقل فيها قابلة للتشغيل. يعني هذا أن الموقع أو التطبيق يجب أن يعمل بالكيبورد فقط، تماماً كما يعمل بالفأرة.
- Understandable (يمكن فهمه): يجب أن تكون المعلومات وتشغيل واجهة المستخدم قابلة للفهم. اللغة يجب أن تكون واضحة، والتنقل يجب أن يكون منطقياً ومتوقعاً.
- Robust (متين): يجب أن يكون المحتوى متيناً بما يكفي ليتم تفسيره بشكل موثوق من قبل مجموعة واسعة من وكلاء المستخدم، بما في ذلك التقنيات المساعدة (مثل قارئات الشاشة). هذا يعني كتابة كود HTML نظيف وذي معنى (Semantic).
فهم هذه المبادئ الأربعة كان بمثابة النور في نهاية النفق. لقد أعطاني خريطة طريق واضحة لإصلاح “الجريمة” التي ارتكبتها بحق خالد وغيره من المستخدمين.
رحلتي العملية: كيف طبّقت معايير WCAG على تطبيقي؟
قررت أن أبدأ العمل فوراً. لم يكن الأمر مجرد إصلاحات تجميلية، بل كان إعادة تفكير شاملة في طريقة بنائي للتطبيق. إليكم بعض المشاكل التي واجهتني وكيف حللتها، مع أمثلة عملية.
أولاً: جعلتُ المحتوى “مرئياً” للجميع (مبدأ Perceivable)
كانت أولى مشاكلي تتعلق بالشكل والمظهر الذي كنت فخوراً به.
مشكلة تباين الألوان: كنت أستخدم لون رمادي فاتح جداً للنصوص على خلفية بيضاء. كان التصميم “أنيقاً” في نظري، لكنه كان كابوساً لمن يعانون من ضعف البصر.
الحل: استخدمت أدوات فحص تباين الألوان (مثل أداة “Contrast Checker” الموجودة في متصفحات كروم وفايرفوكس) للتأكد من أن نسبة التباين بين النص والخلفية تتوافق مع معايير WCAG (على الأقل 4.5:1 للنص العادي).
/* قبل: نص شبه غير مرئي */
.subtle-text {
color: #cccccc; /* نسبة تباين سيئة جداً */
background-color: #ffffff;
}
/* بعد: نص واضح ومقروء */
.readable-text {
color: #555555; /* نسبة تباين ممتازة */
background-color: #ffffff;
}مشكلة الصور الصامتة: تطبيقي كان مليئاً بالأيقونات والصور التوضيحية بدون أي نص بديل. بالنسبة لخالد، كانت قارئات الشاشة تقول “صورة، صورة، زر غير مسمى”، تجربة محبطة للغاية.
الحل: عدت على كل صورة في التطبيق وأضفت السمة alt. هذه السمة هي “صوت” الصورة للمستخدم الكفيف.
<!-- قبل: صورة صامتة -->
<img src="profile.jpg">
<!-- بعد: صورة ناطقة -->
<img src="profile.jpg" alt="صورة شخصية للمستخدم أبو عمر وهو يبتسم">
<!-- نصيحة احترافية: إذا كانت الصورة للزينة فقط ولا تضيف معلومة، اترك السمة فارغة -->
<img src="decorative-line.png" alt="">ثانياً: حرّرتُ المستخدم من سجن الفأرة (مبدأ Operable)
أدركت أنني كنت أصمم فقط لمستخدمي الفأرة (Mouse)، متناسياً أن هناك من يتنقل باستخدام لوحة المفاتيح فقط (بسبب إعاقة حركية أو ببساطة تفضيل شخصي).
مشكلة الأزرار الوهمية: كنت أستخدم عناصر
<div>وأضيف لها حدثonClickبالجافاسكريبت لتبدو كأنها أزرار. هذه العناصر لا يمكن الوصول إليها بلوحة المفاتيح بشكل افتراضي.
الحل: استبدلت كل هذه العناصر بعناصر HTML المخصصة لهذا الغرض: <button> و <a>. هذه العناصر تأتي مع “بطارية مدمجة” من الوصولية: يمكن التركيز عليها (Focusable)، ويمكن تفعيلها بمفتاح Enter أو Space.
<!-- قبل: فخ للفأرة فقط -->
<div class="fake-button" onclick="submitForm()">إرسال</div>
<!-- بعد: زر ديموقراطي للجميع -->
<button class="real-button" onclick="submitForm()">إرسال</button>نصيحة من أبو عمر: إياك ثم إياك أن تكتب هذا السطر في ملف الـ CSS الخاص بك: *:focus { outline: none; }. هذا السطر يحذف الإطار الذي يظهر حول العناصر عند التنقل بالكيبورد، وهو بمثابة “مؤشر الفأرة” لمستخدمي لوحة المفاتيح. أنت بذلك تجعلهم “عمياناً” داخل موقعك.
ثالثاً: تحدثتُ بلغة يفهمها الإنسان والآلة (مبدأي Understandable & Robust)
كان كود HTML الخاص بي فوضوياً. كنت أستخدم العناصر لأغراض شكلية فقط، وليس لأغراض دلالية (Semantic).
مشكلة العناوين الوهمية والنماذج الغامضة: كنت أستخدم
<p style="font-size:24px; font-weight:bold;">لإنشاء عنوان، وكنت أضع حقول الإدخال بدون تسميات<label>مرتبطة بها.
الحل: أعدت هيكلة الكود لاستخدام العناصر الصحيحة. العناوين أصبحت <h1>, <h2>… إلخ، مما يعطي الصفحة بنية هرمية واضحة تفهمها قارئات الشاشة. وكل حقل إدخال <input> حصل على شقيقه الوفي <label>.
<!-- قبل: فوضى دلالية -->
<p style="font-size:24px; font-weight:bold;">تسجيل الدخول</p>
اسم المستخدم: <input type="text" id="username">
<!-- بعد: كود نظيف ومنظم -->
<h2>تسجيل الدخول</h2>
<label for="username">اسم المستخدم</label>
<input type="text" id="username">هذا التغيير البسيط لا يؤثر على الشكل النهائي (يمكنك التحكم بالشكل كما تريد عبر CSS)، لكنه يُحدث فرقاً هائلاً في كيفية “قراءة” الآلة لصفحتك، وبالتالي كيفية تقديمها للمستخدم الذي يعتمد على هذه الآلة.
نصائح من قلب الميدان
بعد هذه الرحلة، خرجت ببعض الدروس التي أود مشاركتكم إياها:
- الوصولية ليست إضافة، بل أساس: لا تؤجل التفكير في الوصولية إلى نهاية المشروع. اجعلها جزءاً من عملية التصميم والتطوير من اليوم الأول. هذا سيوفر عليك الكثير من الوقت والألم لاحقاً.
- استخدم الأدوات المتاحة: هناك أدوات رائعة ومجانية مثل Lighthouse (مدمجة في Chrome)، و Axe, و WAVE. هذه الأدوات يمكنها أن تكشف لك 80% من المشاكل بشكل آلي.
- كن أنت المستخدم: أفضل اختبار هو الاختبار اليدوي. حاول تصفح موقعك باستخدام لوحة المفاتيح فقط. أغلق الشاشة واستمع إلى موقعك عبر قارئ شاشة (NVDA مجاني على ويندوز، و VoiceOver مدمج في أجهزة آبل). ستتفاجأ بما ستكتشفه.
- التعاطف هو أهم مهارة للمبرمج: الوصولية في جوهرها هي التعاطف. هي أن تضع نفسك مكان الآخرين وتصمم لهم وليس لنفسك فقط.
الخلاصة: من الإقصاء إلى الاحتواء 🚀
بعد أسابيع من العمل، أرسلت بريداً إلكترونياً إلى خالد، وقلت له: “أخي خالد، هل يمكنك تجربة التطبيق الآن؟”. جاء رده بعد دقائق قليلة: “أبو عمر، لا أعرف كيف أشكرك. الآن أستطيع استخدام كل شيء. التطبيق لم يعد جميلاً فقط، بل أصبح مفيداً لي أيضاً. شكراً لأنك رأيتني”.
تلك الكلمات كانت تساوي عندي أكثر من كل المديح الذي تلقيته سابقاً. لقد علمتني قصة خالد أن وظيفتنا كمطورين ومصممين تتجاوز كتابة الكود ورسم الواجهات الجميلة. وظيفتنا هي بناء جسور، لا جدران. وظيفتنا هي تمكين الناس، لا إقصاؤهم.
لذا، في مشروعك القادم، تذكر خالد. تذكر أن خلف كل شاشة هناك إنسان له احتياجاته وقدراته المختلفة. دعونا نجعل من الإنترنت مكاناً أرحب وأكثر عدلاً للجميع. هذا ليس مجرد عمل تقني جيد، بل هو العمل الإنساني الصحيح.
