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

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

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

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

ما هي إرشادات الوصول الرقمي (WCAG)؟ وليش هي مهمة “إلك” كمطور؟

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

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

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

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

الغوص في المبادئ الأربعة (POUR): كيف طبقتها عملياً في تطبيقي؟

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

المبدأ الأول: قابلية الإدراك (Perceivable) – “إذا ما انشاف أو انسمع، ما انوجد”

هذا المبدأ يعني أن المحتوى لازم يكون قابل للعرض للمستخدمين بطريقة يقدروا يدركوها. يعني مش لازم يعتمد حصراً على حاسة واحدة (مثل البصر أو السمع).

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

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

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

قبل:

<img src="/icons/save.png">

بعد:

<img src="/icons/save.png" alt="حفظ المستند">

هذا السطر البسيط `alt=”حفظ المستند”` حوّل أيقونة صامتة إلى زر وظيفي وواضح للمستخدمين اللي بيعتمدوا على قارئ الشاشة.

تباين الألوان (Color Contrast)

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

المبدأ الثاني: قابلية التشغيل (Operable) – “الكل لازم يقدر يستخدمه، مش بس اللي عندهم ماوس”

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

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

جربت بنفسي أستخدم تطبيقي بدون ماوس. كانت كارثة! كنت أضغط على زر Tab وما أشوف أي إشي بتغير على الشاشة. السبب؟ لأني كنت حاذف الـ `outline` الافتراضي اللي بيظهر حول العناصر عند التركيز عليها عشان “الشكل يكون أحلى”.

/* الكود السيء اللي كنت كاتبه */
:focus {
  outline: none;
}

الحل كان إني أرجع مؤشر التركيز (focus indicator) لكن بتصميم يتناسب مع هوية التطبيق.

/* الكود الصحيح */
:focus-visible {
  outline: 2px solid #007bff; /* أزرق واضح */
  outline-offset: 2px;
}

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

المبدأ الثالث: قابلية الفهم (Understandable) – “خليك واضح يا حبيب”

المعلومات وطريقة تشغيل الواجهة لازم تكون مفهومة. يعني بلاش فلسفة زايدة وتعقيدات مالها داعي.

توجيهات وأخطاء واضحة

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

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

قبل: “خطأ في الإدخال.”

بعد: “صيغة البريد الإلكتروني غير صحيحة. الرجاء التأكد من استخدام صيغة مثل name@example.com.”

هذا التغيير مش بس ساعد المستخدمين ذوي الإعاقة، بل ساعد كل المستخدمين وقلل من شعورهم بالإحباط.

المبدأ الرابع: المتانة (Robust) – “التطبيق لازم يشتغل صح على كل الأجهزة والتقنيات”

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

استخدام HTML الدلالي (Semantic HTML)

في البداية، كنت أستخدم `

` لكل إشي. زر؟ `

`. قائمة تنقل؟ `

`. مقال؟ `

`. هذا خطأ فادح لأنه بيحرم قارئات الشاشة من فهم بنية الصفحة.

قبل (سيء جداً):

<div class="button" onclick="submitForm()">إرسال</div>

بعد (صحيح وممتاز):

<button onclick="submitForm()">إرسال</button>

لما تستخدم `

أبو عمر

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

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

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

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

آخر المدونات

برمجة وقواعد بيانات

بياناتي كانت تتلف بصمت: كيف أنقذتني ‘معاملات قاعدة البيانات’ (Transactions) من جحيم البيانات الفاسدة؟

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

4 أبريل، 2026 قراءة المزيد
الشبكات والـ APIs

تطبيقي كان يغرق في بحر من طلبات API: كيف أنقذتني GraphQL من جحيم الـ Over-fetching والـ Under-fetching؟

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

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

مقابلاتي لتصميم النظم كانت كارثة: كيف أنقذني هذا الإطار المنهجي من جحيم الرفض؟

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

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

عطل في خدمة واحدة كان يسقط النظام بأكمله: كيف أنقذني نمط ‘قاطع الدائرة’ من جحيم الأعطال المتتالية؟

أشارككم قصة حقيقية عن ليلة كاد فيها عطل بسيط في خدمة واحدة أن ينهار نظامنا بالكامل. سأشرح لكم بالتفصيل نمط "قاطع الدائرة" (Circuit Breaker) الهندسي،...

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