كان تطبيقنا يستبعد 15% من المستخدمين بصمت: كيف أنقذتنا ‘إمكانية الوصول الرقمية’ (a11y) من كارثة التصميم؟

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

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

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

الصدمة: كنا نبني جدرانًا لا جسورًا

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

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

ما هي “إمكانية الوصول الرقمية” (a11y) وليش اسمها هيك؟

هنا دخل مصطلح جديد على قاموس فريقنا: إمكانية الوصول الرقمية (Digital Accessibility). الاسم المختصر تبعها هو “a11y”، والقصة وراه بسيطة وحلوة: هو الحرف الأول “a” والحرف الأخير “y” وبينهم 11 حرف (accessibility). بالزبط زي ما بنختصر internationalization لـ i18n.

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

ولحسن الحظ، ما كان لازم نخترع العجلة من جديد. في معايير عالمية ومبادئ توجيهية اسمها Web Content Accessibility Guidelines (WCAG)، وهي بتعتبر الدستور أو المرجع الأساسي لكل حدا بده يشتغل على تحسين إمكانية الوصول في منتجه.

خطواتنا الأولى في عالم الـ a11y: من وين بلّشنا؟

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

1. تدقيق تباين الألوان (Color Contrast)

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

نصيحة أبو عمر: لا تثق بعينيك! استخدم أدوات. عينك ممكن تخدعك، لكن الأرقام ما بتكذب.

استخدمنا أدوات مثل WebAIM Contrast Checker لفحص كل ألوان التطبيق. المعيار الذهبي (حسب WCAG) هو نسبة تباين 4.5:1 للنص العادي على الأقل.

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

/* ❌ سيء: تباين ضعيف جدًا */
.bad-button {
  color: #aaaaaa; /* رمادي فاتح */
  background-color: #ffffff; /* أبيض */
}

/* ✅ جيد: تباين عالي ومقروء */
.good-button {
  color: #ffffff; /* أبيض */
  background-color: #007bff; /* أزرق */
}

2. النصوص البديلة للصور (Alt Text)

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

نصيحة أبو عمر: لما تكتب نص بديل (alt text)، تخيل إنك بتوصف الصورة لواحد صاحبك على التلفون. شو رح تحكيله بالزبط؟

الحل كان بسيط بشكل مدهش: إضافة خاصية alt لكل صورة ذات معنى في التطبيق.

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

<!-- ❌ سيء: قارئ الشاشة سيقول "صورة" أو يتجاهلها -->
<img src="add-to-cart.png">

<!-- ✅ جيد: قارئ الشاشة سيقرأ "إضافة المنتج إلى سلة التسوق" -->
<img src="add-to-cart.png" alt="إضافة المنتج إلى سلة التسوق">

<!-- ✅ جيد أيضًا للصور التزيينية: اترك النص البديل فارغًا ليتجاهله قارئ الشاشة -->
<img src="decorative-line.png" alt="">

3. التنقل باستخدام لوحة المفاتيح (Keyboard Navigation)

هاي كانت صدمة تانية. جربنا نتصفح التطبيق باستخدام زر الـ Tab فقط، بدون ماوس. كانت تجربة كارثية! لا يمكن الوصول لنصف الأزرار، والترتيب كان عشوائي، وما كنا نعرف أي عنصر “مُفعّل” حاليًا.

المشكلة كانت إننا استخدمنا عناصر <div> و <span> بكثرة وعملناها “أزرار” باستخدام جافاسكريبت، بدل ما نستخدم العناصر المخصصة لهيك إشي.

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

مثال بالكود:

<!-- ❌ سيء: لا يمكن الوصول إليه بالكيبورد بسهولة، ولا يعلن عن نفسه كزر -->
<div class="custom-button" onclick="doSomething()">اضغط هنا</div>

<!-- ✅ جيد: يمكن الوصول إليه بالكيبورد، مفهوم لقارئ الشاشة، ويعمل بشكل صحيح -->
<button onclick="doSomething()">اضغط هنا</button>

4. البنية المنطقية والعناوين (Semantic Structure)

كانت صفحاتنا عبارة عن “حساء من الـ divs” (div soup). استخدمنا الخط الكبير والـ bold عشان نعمل عناوين، بدل ما نستخدم الوسوم المخصصة للعناوين زي <h1>, <h2>, etc.

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

قمنا بإعادة هيكلة الصفحات لاستخدام وسوم HTML الدلالية (Semantic HTML). الصفحة الرئيسية صار فيها <h1> واحد فقط، والأقسام الرئيسية <h2>، والعناوين الفرعية <h3> وهكذا. هذا التغيير البسيط حسّن تجربة قارئ الشاشة بشكل خيالي، وكمان حسّن الـ SEO تبعنا كهدية إضافية!

أكثر من مجرد كود: تغيير في العقلية

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

  • المصمم صار يفكر في تباين الألوان وحجم الخطوط من أول يوم.
  • المطور صار يكتب كود HTML دلالي ويسأل “هل هذا العنصر يمكن الوصول إليه بالكيبورد؟”.
  • فاحص الجودة (QA) صار يختبر التطبيق باستخدام قارئ شاشة وبدون ماوس كجزء أساسي من عمله.
  • مدير المنتج صار يضع “قصص مستخدمين” (User Stories) لأشخاص من ذوي الإعاقة.

إمكانية الوصول بطلت “ميزة إضافية” (nice-to-have)، بل صارت جزء لا يتجزأ من تعريف “الجودة” و “الاكتمال” لأي مهمة بنشتغل عليها.

خلاصة الحكي ونصيحة أخيرة

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

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

تذكروا دائمًا: نحن نبني منتجات للبشر، وكل البشر يستحقون تجربة كريمة ومحترمة. 😉

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

تسويق رقمي

كانت حملاتنا تصرخ في الفراغ: كيف أنقذتنا ‘التجزئة الديناميكية بالتعلم الآلي’ من جحيم العروض غير الملائمة؟

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

28 مايو، 2026 قراءة المزيد
برمجة وقواعد بيانات

ما وراء البحث التقليدي: كيف تُمكّن قواعد بيانات المتجهات تطبيقات الذكاء الاصطناعي من فهم المعنى؟

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

27 مايو، 2026 قراءة المزيد
الحوسبة السحابية

كانت فواتيرنا السحابية لغزاً محيراً: كيف أنقذتنا ثقافة FinOps من جحيم الإنفاق غير المنضبط؟

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

27 مايو، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

كانت سيرتي الذاتية مجرد حبر على ورق: كيف أنقذتني ‘المساهمات مفتوحة المصدر’ من جحيم ‘سنتصل بك لاحقاً’؟

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

27 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

كانت طلباتنا تضيع في الزحام: كيف أنقذتنا طوابير الرسائل (Message Queues) من جحيم الانهيار؟

أشارككم قصة حقيقية من قلب المعركة البرمجية، يوم كاد تطبيقنا ينهار تحت ضغط مفاجئ. اكتشفوا كيف كانت "طوابير الرسائل" (Message Queues) هي طوق النجاة الذي...

27 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

كنا نكتشف الأعطال بالصدفة: كيف أنقذنا Prometheus و Grafana من جحيم ‘أخبرني العميل أن الموقع لا يعمل’؟

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

27 مايو، 2026 قراءة المزيد
البودكاست