يا جماعة الخير، صلّوا على النبي. قبل عدة سنوات، كنت في قمة حماسي. بعد أشهر من السهر والقهوة وكتابة الكود، أطلقت تطبيقاً كنت أعتبره “تحفتي الفنية”. تصميم عصري، ألوان متناسقة، حركات انسيابية… كل شيء كان يبدو مثالياً. كنت أتفقد التحليلات كل ساعة، وأرى أرقام التحميل ترتفع، وشعور الفخر يغمرني.
وفي مساء أحد الأيام، وبينما كنت أقلّب في رسائل البريد الإلكتروني، لفت انتباهي عنوان رسالة: “ملاحظة بخصوص استخدام تطبيقكم مع قارئ الشاشة”. فتحت الرسالة بفضول، لأجد كلمات من مستخدم كفيف غيّرت نظرتي للبرمجة إلى الأبد.
كانت الرسالة مهذبة لكنها مؤلمة. كتب المستخدم: “تطبيقكم جميل بصرياً كما وصفه لي أصدقائي، لكني لم أستطع استخدامه. قارئ الشاشة الذي أعتمد عليه للتنقل في هاتفي يخبرني بوجود ‘زر غير مسمى’، ‘صورة’، ‘زر غير مسمى’ مرة أخرى. شعرت وكأنني أقف أمام جدار جميل المظهر، لكنه مصمت وبلا باب”.
والله يا جماعة، شعرت بالخجل. “شو هالحكي يا أبو عمر؟” قلت لنفسي. كيف لم أفكر في هذا؟ أنا، المبرمج الذي يدّعي الخبرة، بنيت منتجاً يستثني شريحة من الناس عن غير قصد. في تلك اللحظة، أدركت أن الجمال البصري وحده لا يصنع تجربة مستخدم ناجحة. ومن هنا بدأت رحلتي الحقيقية مع عالم “إمكانية الوصول الرقمية” أو ما يُعرف اختصاراً بـ “a11y”.
ما هي “إمكانية الوصول الرقمية” (a11y) يا أبو عمر؟
بكل بساطة، إمكانية الوصول الرقمية (Accessibility، وتُختصر a11y لأن هناك 11 حرفاً بين الـ ‘a’ والـ ‘y’) هي ممارسة تصميم وتطوير المواقع والتطبيقات الرقمية بحيث يمكن لجميع الأشخاص استخدامها، بغض النظر عن قدراتهم الجسدية أو العقلية.
الفكرة ليست محصورة فقط بالمكفوفين الذين يستخدمون قارئات الشاشة. هي تشمل نطاقاً أوسع بكثير:
- ضعاف البصر: الذين يحتاجون لتباين عالٍ في الألوان أو القدرة على تكبير النص.
- ذوو الإعاقات السمعية: الذين يعتمدون على الشروحات النصية (Captions) لمقاطع الفيديو.
- ذوو الإعاقات الحركية: الذين قد يستخدمون لوحة المفاتيح فقط أو تقنيات مساعدة أخرى للتنقل بدلاً من الفأرة.
- ذوو الإعاقات الإدراكية: الذين يستفيدون من التصاميم الواضحة والبسيطة والتنقل المنطقي.
إمكانية الوصول ليست “ميزة إضافية” أو “عمل خيري”. إنها حق أساسي للمستخدم، ومؤشر على جودة المنتج، وبكل أمانة، هي استثمار ذكي لأي بزنس يريد الوصول إلى أوسع شريحة ممكنة من الجمهور.
“خطاياي” في التصميم وكيف تتجنبها
دعوني أشارككم بعض الأخطاء الفادحة التي ارتكبتها في تطبيقي الأول، والتي أراها تتكرر كثيراً اليوم. اعتبروها دروساً مجانية من أخيكم أبو عمر.
الخطيئة الأولى: الزر الأيقوني “الأخرس”
كان لديّ في التطبيق زر بحث على شكل أيقونة عدسة مكبرة. جميل وبسيط، أليس كذلك؟ بالنسبة للمستخدم المبصر، نعم. لكن بالنسبة لقارئ الشاشة، كان هذا الزر مجرد “زر، غير مسمى”. المستخدم لا يعرف وظيفته إطلاقاً.
نصيحة عملية: كل عنصر تفاعلي يجب أن يكون له اسم واضح ومفهوم. إذا كنت تستخدم أيقونة بدون نص، يجب أن توفر وصفاً برمجياً لها.
الحل بسيط باستخدام خاصية aria-label.
<!-- خطأ: زر بدون وصف -->
<button class="icon-button">
<svg>...</svg> <!-- أيقونة العدسة المكبرة -->
</button>
<!-- صحيح: زر مع وصف لقارئ الشاشة -->
<button class="icon-button" aria-label="بحث">
<svg>...</svg>
</button>الآن، عندما يصل قارئ الشاشة إلى هذا الزر، سينطق “بحث، زر”، وهو ما يمنح المستخدم السياق الكامل.
الخطيئة الثانية: كارثة تباين الألوان
كنت قد اخترت لوحة ألوان “عصرية”: رمادي فاتح على خلفية بيضاء، وأزرار بلون رمادي أغمق قليلاً. النتيجة كانت أنيقة في نظري، لكنها كانت جحيماً للمستخدمين الذين يعانون من ضعف البصر.
معايير الوصول العالمية (WCAG) تحدد نسب تباين (Contrast Ratio) دنيا بين لون النص ولون الخلفية لضمان الوضوح. المستوى المقبول (AA) يتطلب نسبة 4.5:1 للنص العادي.
نصيحة عملية: لا تعتمد على عينيك فقط للحكم على تباين الألوان. استخدم أدوات فحص التباين مثل WebAIM Contrast Checker أو الأدوات المدمجة في متصفحات الويب (DevTools).
/* خطأ: تباين ضعيف جداً */
.subtle-text {
color: #aaaaaa; /* رمادي فاتح */
background-color: #ffffff; /* أبيض */
/* نسبة التباين هنا 1.67:1 فقط! */
}
/* صحيح: تباين مقبول (AA) */
.readable-text {
color: #595959; /* رمادي داكن */
background-color: #ffffff; /* أبيض */
/* نسبة التباين هنا 4.54:1 */
}الخطيئة الثالثة: الـ `<div>` الذي تمنى لو كان `<button>`
في بعض الأماكن، ولكي أتحكم بالشكل 100%، استخدمت عنصر <div> وأضفت له حدث onClick في جافاسكريبت ليقوم بعمل الزر. يا لها من جريمة برمجية!
المشكلة أن الـ <div> ليس عنصراً تفاعلياً بطبيعته. لا يمكن الوصول إليه باستخدام مفتاح Tab للتنقل، ولا يتم تفعيله بمفتاح Enter أو Space، وقارئ الشاشة لا يتعرف عليه كـ”زر”. لقد بنيت زراً للمستخدمين الذين يستخدمون الفأرة فقط.
نصيحة عملية: استخدم عناصر HTML الدلالية (Semantic HTML) كلما أمكن. إذا كان الشيء يبدو كزر ويعمل كزر، فاستخدم عنصر
<button>. المتصفحات وقارئات الشاشة تعرف كيف تتعامل معه بشكل صحيح “من المصنع”.
<!-- خطأ فادح: زر مزيف لا يعمل إلا بالفأرة -->
<div class="fake-button" onclick="doSomething()">اضغط هنا</div>
<!-- صحيح: زر حقيقي ومتاح للجميع -->
<button class="real-button" onclick="doSomething()">اضغط هنا</button>الخطيئة الرابعة: الصور الصامتة والنص البديل المفقود
كان تطبيقي مليئاً بالصور الجميلة التي تشرح الخدمات. لكنني نسيت تماماً إضافة النص البديل (alt text). النتيجة؟ قارئ الشاشة كان يقول “صورة، graphic-promo-final-v2.jpg”. معلومة عديمة الفائدة تماماً.
النص البديل هو وصف موجز للصورة يظهر إذا فشل تحميلها، والأهم، يقرأه قارئ الشاشة للمستخدم الكفيف.
نصيحة عملية: اسأل نفسك: ما هي المعلومة التي تقدمها هذه الصورة؟ إذا كانت الصورة تحمل معلومة، اكتبها في النص البديل. إذا كانت مجرد زخرفة، اترك النص البديل فارغاً (
alt="") ليتجاهلها قارئ الشاشة.
<!-- خطأ: بدون نص بديل -->
<img src="chart.png">
<!-- صحيح: وصف مفيد للصورة -->
<img src="chart.png" alt="رسم بياني يوضح نمو أرباح الشركة بنسبة 20% في الربع الأخير">
<!-- صحيح (لصورة زخرفية): تجاهلها قارئ الشاشة -->
<img src="decorative-swirl.png" alt="">“وضوئي الرقمي”: قائمة عملية لبناء تطبيق شامل
بعد تلك الرسالة، قمت بما أسميه “الوضوء الرقمي” لتطهير تطبيقي من ذنوب عدم إتاحة الوصول. إليك خطوات عملية يمكنك اتباعها اليوم:
المرحلة الأولى: “تفقّد” تطبيقك بلوحة المفاتيح
اترك الفأرة جانباً. حاول استخدام موقعك أو تطبيقك بالكامل باستخدام لوحة المفاتيح فقط. استخدم مفتاح Tab للتنقل بين العناصر (الأزرار، الروابط، حقول الإدخال) و Shift+Tab للرجوع. هل يمكنك الوصول إلى كل شيء؟ هل ترى تركيزاً بصرياً واضحاً (Focus Ring) على العنصر الذي تقف عليه؟ إذا كانت الإجابة لا، فلديك مشكلة.
المرحلة الثانية: “اسمع” تطبيقك بأذنيك
هذه هي الخطوة الأهم. قم بتفعيل قارئ الشاشة على جهازك (VoiceOver على أجهزة آبل، NVDA وهو مجاني على ويندوز، أو TalkBack على أندرويد) وأغلق عينيك. حاول استخدام تطبيقك. هل التجربة منطقية؟ هل الأسماء والأوصاف واضحة؟ ستتفاجأ بما ستكتشفه.
المرحلة الثالثة: افحص ألوانك بعين الناقد
استخدم أدوات فحص تباين الألوان التي ذكرتها سابقاً. لا تفترض أن الألوان جيدة لأنها تبدو كذلك لك. تذكر أن هناك درجات مختلفة من القدرة على الإبصار.
المرحلة الرابعة: استعن بالأدوات الآلية (لكن بحذر!)
هناك أدوات رائعة مثل Lighthouse (في أدوات مطوري كروم)، و axe DevTools، و WAVE يمكنها فحص صفحتك آلياً وإعطائك تقريراً بالمشاكل الواضحة. هذه الأدوات ممتازة كنقطة بداية، لكنها تكتشف حوالي 30-40% فقط من مشاكل إمكانية الوصول. الاختبار اليدوي (خاصة باستخدام قارئ الشاشة ولوحة المفاتيح) لا غنى عنه.
خلاصة الكلام ونصيحة من القلب 🙏
يا أصدقائي المبرمجين والمصممين، بناء منتجات رقمية شاملة ليس مجرد اتباع قائمة من القواعد التقنية. إنه تحول في العقلية. إنه الانتقال من التفكير “كيف سيبدو هذا؟” إلى التفكير “كيف سيعمل هذا للجميع؟”.
عندما نصمم للجميع منذ اليوم الأول، فإننا لا نساعد فئة معينة فقط، بل نحسّن التجربة للكل. الميزات التي نصممها لذوي الإعاقة غالباً ما تفيد الجميع، وهذا ما يعرف بـ “تأثير الرصيف المنحدر” (Curb-Cut Effect) – فالمنحدرات التي صُممت للكراسي المتحركة يستخدمها اليوم آباء مع عربات أطفال، وعمال يجرون عربات، ومسافرون مع حقائب.
لا تبنوا جدراناً جميلة. ابنوا جسوراً متينة وقوية ترحب بالجميع. ففي نهاية المطاف، قيمة ما نصنعه لا تقاس بجمال الكود أو أناقة التصميم، بل بمدى الأثر الإيجابي الذي نتركه في حياة الناس. كل الناس. 💻❤️
