في مايو 2024، دخلتُ موقعاً إلكترونياً لإتمام معاملةٍ بسيطة. لكن قبل أن أصل إلى أيّ محتوى، قفزت أمامي نافذة من أداة إصلاحٍ تلقائي لإمكانية الوصول (Accessibility Overlay): أزرار بلا تسميات، لا تستجيب لمفتاح Tab ولا Shift+Tab ولا Escape، ولا سبيل لإغلاقها.
أنا مطوّرُ ويب كفيف، أستخدم قارئ الشاشة يومياً منذ سنوات. فإذا عجزتُ أنا عن التعامل مع هذه النافذة، فماذا سيفعل مستخدمٌ عادي من ذوي الإعاقة؟
ففعلتُ ما يفعله أيّ مبرمج عنيد: فتحتُ ملف الاستضافة المحلي (Host File) وأدرجتُ عناوين IP الخاصة بالشركة المزوّدة للأداة، كما تُدرَج المواقع المشبوهة تماماً. ثمّ أكملتُ حياتي 🙂
لكنّ السؤال الذي لم يفارقني بعدها: كم مستخدماً من ذوي الإعاقة يملك المعرفة التقنية ليفعل ما فعلته؟ وكم منهم تخلّى ببساطة عن الموقع ومضى؟ هذا الموقف تحديداً هو ما دفعني لكتابة هذا المقال.
ACCESSIBILIAMUS!
كتبتُ هذه الكلمة ساخراً على تويتر ذات يوم، مستلهماً إياها من عالم هاري بوتر. تعويذة سحرية تُلقيها على موقعك فيصبح متوافقاً بنسبة مئة بالمئة، بتوفيق الله ودعوات الوالدين وشيء من السحر 😂
لكنّ الواقع أنه لا توجد تعويذة، ولا يوجد سطر كود واحد يُعالج تحدياتٍ تراكمت على المستوى الاستراتيجي والتنظيمي والتقني في جهةٍ بأكملها. ولفهم لماذا تلجأ جهاتٌ كثيرة لهذه الأدوات رغم محدوديتها، علينا أن ننظر إلى الصورة الأكبر أولاً.
دورة إمكانية الوصول: أين نحتاج أن ننمو؟
إمكانية الوصول دورةٌ متكاملة من خمس حلقات: تبدأ من التوجه الاستراتيجي، ثمّ تمرّ بمؤشرات الأداء، ففريق تجربة المستخدم، ففريق التطوير، وتنتهي بفريق الاختبار. وحين ننظر إلى كلّ حلقة على حدة، نجد أنّ ثمّة فجوات في أكثر من موضع.
التوجه الاستراتيجي
تبدأ الدورة من مكانٍ أبعد بكثير ممّا قد يتصوّره البعض، إذ تبدأ من التوجه الاستراتيجي للمنشأة: هل تؤمن فعلاً بأنّ محتواها يجب أن يكون متاحاً للجميع؟ وهذا قرارٌ واعٍ ومتعمَّد يحتاج أن يأتي من الإدارة العليا، لأنّ كلّ حلقةٍ بعده تعتمد عليه.
وهنا تبرز أسئلةٌ تستحق أن نطرحها بصدق: كم عدد المستخدمين من ذوي الإعاقة الذين نخدمهم؟ كم عدد كبار السن؟ أين تتركّز المشكلات التي يواجهونها يومياً؟ هل نملك قنوات نسمع من خلالها أصواتهم؟ هل أجرينا جلسةَ تركيزٍ واحدة مع مستخدمٍ من ذوي الإعاقة؟ كثيرٌ من الجهات لم تبدأ بعد بالإجابة عن هذه الأسئلة، إلا أنّ هذا أمرٌ يمكن تغييره.
مؤشرات الأداء
ومن هذه النقطة ننتقل إلى جانب الأعمال، إذ تظهر هنا فجوةٌ تستحق أن نتوقف عندها.
حين كنتُ أعمل مستقلاً قبل سنوات، عملتُ مع فريق تجربة مستخدم وفريق تطوير على مشروعٍ أنجزناه بعنايةٍ كبيرة. فنُشر على LinkedIn وأشاد به كثيرون. لكن بعد سنةٍ تقريباً، بدأ كلّ شيء يتهاوى.
فتواصلتُ مع الفريق وسألتهم: ما الذي حدث يا جماعة؟
فجاء الردّ صريحاً:
“إمكانية الوصول شيء جميل، لكنها لن تدفع لي مكافأة نهاية السنة. الذي سيدفع لي مكافأتي هو تحقيق مؤشرات أدائي.”
لا ألوم الفريق، فهم يعملون وفق ما يُطلَب منهم. لكنّ هذا الموقف يكشف فجوةً حقيقية: فحين لا تُدرَج إمكانية الوصول ضمن مؤشرات الأداء التي يُحاسَب عليها الموظف، لا يمكننا أن نتوقع منه أن يمنحها الأولوية. فما لا يمكن قياسه لا يمكن تحسينه، وهذه قاعدةٌ لا تقبل الاستثناء.
من المسؤول عن التفاعلات؟
وبالحديث عن المسؤوليات، ننتقل إلى فريق تجربة المستخدم. وهنا تلقّيتُ درساً شخصياً غيّر نظرتي لعملي.
في مؤتمر CSUN 2023، كنتُ أحضر دورةً مع أحد كبار المستشارين في إمكانية الوصول. فأخبرته بأنني أكتب الأوصاف البديلة للصور، وأضبط تفاعلات مربعات الحوار والنوافذ المنبثقة، وأدير ترتيب التنقل باستخدام لوحة المفاتيح، وأراقب سلوك التصفّح بقارئ الشاشة.
فقاطعني وقال: “مهلاً! هذه ليست مسؤوليتك كمطوّر إمكانية وصول. هذه مسؤولية فريق تجربة المستخدم.”
أصابتني كلماته، إذ اكتشفتُ أنني كنتُ أحمل على عاتقي مهامّ فريقٍ كامل دون أن أدري.
والحقيقة أنّ كثيراً من فِرَق تجربة المستخدم تحتاج إلى بناء معرفتها في هذا الجانب: كيف يتفاعل مستخدمو التقنيات المساعدة مع الموقع؟ ما الذي يجب أن يكون إجراءً مخصّصاً؟ أين يذهب التركيز حين تُغلَق قائمة منسدلة؟ وكيف تُدار عملية التركيز في الصفحة بأكملها؟ هذه كلّها مسؤوليات تجربة المستخدم لأنها تتعلّق بالسلوك والتفاعل البشري، لا بالكود.
فالمطوّر يستطيع تنفيذ كلّ شيء إن امتلك المعرفة، تقدر “تخترع الذرّة” لو بغيت. لكن من الذي يوجّهك؟ المفترض أن يوجّهك الفريق الأدرى بمعاناة المستخدمين وبأفضل ممارسات التفاعل البشري.
ولم يكن هذا الدرس نظرياً بالنسبة لي. ففي أحد المشاريع، استلهمتُ من مواقع مثل Stripe وجعلتُ النظام ينقل التركيز تلقائياً إلى مربع الإدخال التالي عند انتهاء المستخدم من المربع السابق. كان السلوك مناسباً لمستخدمي VoiceOver من وجهة نظري، لكن تبيّن أنه يتسبّب في فتح لوحة المفاتيح بشكل متكرر عند المستخدم المبصر. ومع خللٍ آخر في عرض الألوان، دفع أحد المستخدمين عشرة آلاف ريال بدلاً من مئة.
فعدتُ للعمل الساعة الثالثة فجراً لإصلاح المشكلة. ولم يكن أحد غيري يعرف سبب هذا السلوك، لأنني كنتُ أؤدّي مهامّ فريقٍ كامل بمفردي. وهذا بالضبط ما يحدث حين تغيب الحوكمة الواضحة للتفاعلات.
التطوير
وعلى مستوى التطوير، ثمّة تحدٍّ مشابه، إذ إنّ من أسوأ ما حدث في HTML ظهور عنصرَي div وspan، اللذين سهّلا على كثير من المطورين بناء مواقع كاملة بعناصر غير دلالية مع الاعتماد على CSS وحدها للتنسيق. وحين يحاول أحدهم الإصلاح، يفتقر غالباً للتدريب الكافي في إمكانية الوصول وفي ARIA تحديداً.
سأعطيكم مثالاً حقيقياً: كانت إحدى الصحف الإلكترونية تضع في خاصية aria-label معرّفات عناصر بدلاً من نصوصٍ مقروءة، فكان قارئ الشاشة يقرأ كلّ رابط على أنه “fallback-hero-image” أو “fallback-author-image”. صحيفة بأكملها لا يمكن قراءتها! ليس بسبب سوء نية، بل بسبب غياب التدريب المتخصّص.
الاختبار
أمّا فريق ضمان الجودة، فيواجه تحدياً لا يقلّ أهمية: إذ لا يملك في الغالب التدريب الكافي لاختبار إمكانية الوصول، ولا يعرف كيف يستخدم التقنيات المساعدة لرصد المشكلات. وبدون فريقٍ قادر على اختبار المنتج كما يختبره المستخدم ذو الإعاقة، تمرّ المشكلات إلى بيئة الإنتاج دون أن يلاحظها أحد.
إذًا، حين ننظر إلى هذه الدورة بأكملها، نجد أنّ ثمّة فجواتٍ في أكثر من حلقة: في التوجه الاستراتيجي، وفي مؤشرات الأداء، وفي التدريب، وفي الاختبار. ولمن لا يعرف، فإنّ إمكانية الوصول بالنسبة لكثير من الجهات تبدو كصندوقٍ أسود: مجالٌ معقّد، ومعاييره كثيرة، ولا يُعرف من أين يبدأ فيه ولا أين ينتهي. وحين تجتمع هذه الفجوات مع غموض المجال نفسه، يصبح مفهوماً لماذا تبدو أداة الإصلاح التلقائي حلاً مُغرياً: يأتي أحدهم ويقول لك “سطر كود واحد، وانتهى الأمر.”
الوعد الذي لم يتحقق
لم تصل أدوات الإصلاح التلقائي إلى السعودية إلا حوالي عامَي 2018-2019، لكنّها كانت موجودة في الولايات المتحدة قبل ذلك بسنوات، وخطابها التسويقي واحد: تخلّص من عبء إمكانية الوصول، اربط موقعك بأداتنا، ونحن نتكفّل بكلّ شيء.
غير أنّ هذا الوعد لم يصمد أمام التجربة الفعلية. فقد غرّمت لجنة التجارة الفيدرالية الأمريكية شركة AccessiBe مليون دولار في يناير 2025 بسبب مبالغاتٍ في وصف قدرات أداتها. كما رُفعت دعوى جماعية ضدها في 2024. والأكثر دلالة أنه رُفعت قضايا على أكثر من ثمانمئة جهة كانت تستخدم هذه الأدوات ظنّاً منها أنها تحقق الامتثال المطلوب.
ثمّ انتقل النموذج إلينا: فدخلت شركات أمريكية أولاً، ثمّ ظهرت شركات محلية تبني حلولاً خاصة أو تُعيد تغليف منتجاتٍ جاهزة، والوعد هو ذاته. وأُنصف هنا بالقول إنّ شركةً أو شركتين كانت تنبّه عملاءها بأنّ الأداة وحدها لا تكفي وأنّ إصلاح الكود ضرورة، لكنّ كثيراً من الجهات تبحث عن حلٍّ يُريحها من تعقيدات هذا الملف.
ولعلّ أقرب تشبيه يوضّح المسألة هو الأمن السيبراني: إذ لا يقبل أحد أن يقول له مزوّد خدمة “عندي أداة تسدّ كلّ ثغراتك الأمنية بضغطة زر”، لأنّ كلّ ثغرة تعتمد على سياق الكود والبنية وأنماط الاستخدام. والأمر ذاته ينطبق على إمكانية الوصول.
الذكاء الاصطناعي لا يُصلح ما لا يفهمه
ومع تطوّر الذكاء الاصطناعي، ظهر جيلٌ جديد من هذه الأدوات يدّعي أنه يُعالج حتى المشكلات التي عجزت عنها الأدوات السابقة.
وهنا نقطةٌ تستحق التأمل: أكبر تحديات الذكاء الاصطناعي اليوم هي الهَلْوَسة، إذ لا يملك الأشخاص ذوو الإعاقة في كثير من الأحيان وسيلةً للتحقق ممّا يُخبرهم به. فحين يصف لي النظام صورةً بطريقةٍ معينة، لا أستطيع كشخصٍ كفيف أن أتحقق من صدق هذا الوصف، وأجدني مُجبَراً على الثقة بنظامٍ قد يُخطئ.
ولو كانت هذه الأدوات تحلّ مشاكلنا فعلاً، لكنتُ أوّل من يدفع عليها ولو عشرة آلاف ريال شهرياً، لأنها ستجعلني مستقلاً تماماً ومستغنياً عن طلب المساعدة من أيّ أحد. لكنها لا تفعل. والسؤال الذي يجب أن يسأله كلّ من يشتري هذه الأدوات لنفسه: لو كانت بهذه القوة، فلماذا لم يشترِها الأشخاص ذوو الإعاقة أنفسهم؟ بل لماذا لم تحلّ التقنيات المساعدة ذاتها كلّ هذه المشكلات، وهي برامج مُثبَّتة على النظام ولها وصولٌ أعمق إلى واجهة إمكانية الوصول الخاصة بالمتصفح؟
حين يُختبَر الوعد
في عملنا كمدققين لإمكانية الوصول، لا نأخذ أدوات الإصلاح التلقائي في الحسبان عند التقييم. فنحن نستخدم التقنيات المساعدة مباشرة (NVDA، وVoiceOver، وغيرها)، ونتصفّح الموقع كما يتصفّحه أيّ مستخدمٍ من ذوي الإعاقة. وهذا ما يفعله كلّ مدقّقٍ محترف ومتخصّص في هذا المجال.
والنتيجة التي نراها تتكرّر هي أنّ كثيراً من الجهات تعتقد أنها في وضعٍ ممتاز فيما يتعلق بسهولة الوصول، وأقدّر لهم هذا الاهتمام. لكن حين تُجرى عمليات التدقيق اليدوي، سواءً بطلبٍ من الجهة نفسها أو من جهاتٍ تشريعية، يتبيّن أنّ الواقع مختلفٌ تماماً عمّا أظهرته أدوات الفحص الآلي.
والأرقام تؤكّد ذلك: تشير الدراسات إلى أنّ أدوات الفحص الآلي لا تكتشف سوى عشرين إلى ثلاثين بالمئة من مشكلات إمكانية الوصول الفعلية. وبالتالي فإنّ أدوات الإصلاح التلقائي التي تعتمد على ما تكتشفه هذه الأدوات لا تُعالج إلا جزءاً محدوداً من المشكلات. مدخلاتٌ ناقصة تُنتج مخرجاتٍ ناقصة.
والأخطر من ذلك أنّ هذه الأدوات في كثيرٍ من الحالات تتداخل مع التقنيات المساعدة وتُعيق تجربة المستخدم بدلاً من تحسينها، إذ تُعدّل بنية الصفحة بطريقةٍ تتعارض مع ما يتوقعه قارئ الشاشة. وقد أظهر استطلاع WebAIM لمختصي إمكانية الوصول أنّ اثنين وسبعين بالمئة من المستخدمين من ذوي الإعاقة يرون أنّ هذه الأدوات غير فعّالة أو غير فعّالة على الإطلاق، ولم يصفها بالفعّالة جداً سوى اثنين فاصل أربعة بالمئة فقط. وقد وقّع أكثر من ثمانمئة مختصٍّ ومنظمة على بيانٍ علني يوثّق هذه المحدوديات.
وإن لم تكن هذه الأدوات تُعيق التجربة، فهي حتماً لا تُحسّنها. وهذا ليس عيباً في الجهات التي اشترتها، بل في الوعد الذي أوحى لها بأنّ الأمور على ما يُرام.
كان يا مكان، في قديم الزمان، وسالف العصر والأوان،
كانت هناك أداة إصلاحٍ تلقائي وعدت بتوافقٍ كامل لأيّ موقع بصرف النظر عن بنيته التقنية. وحين خضعت للتدقيق، فشلت لعدم توافُقِها مع التقنيات المساعدة!
النهاية.
جانب الخصوصية
وثمّة بُعدٌ آخر يتعلّق بالخصوصية لا ينتبه له كثيرون.
إذ تجمع بعض هذه الأدوات بيانات عن إعاقة المستخدم: فتكتشف وجود التقنيات المساعدة على جهازه، وقد تُحدّد نوع الإعاقة، وتتبّع سلوكه عبر المواقع التي تستخدم الأداة ذاتها. وقد كشف تحليلٌ تقني أنّ إحدى هذه الأدوات تُنفق خمسةً وسبعين بالمئة من نشاطها الشبكي على تحليلاتٍ سلوكية، لا على تحسين إمكانية الوصول.
وهذا أمرٌ يستوجب الانتباه، لأنّ نظام حماية البيانات الشخصية في المملكة يُعرِّف البيانات الحساسة بأنها تشمل صراحةً البيانات الصحية والجينية والحيوية، وبيانات الإعاقة تندرج ضمنها. ويفرض النظام قيوداً إضافية على معالجة هذه البيانات، ويحظر استخدامها لأغراضٍ تسويقية، ويُلزم بحمايتها بتدابير مشدّدة. وقد تعمّد مطوّرو معايير الويب إخفاء هذا النوع من المعلومات عن المواقع لسببٍ وجيه: الإفصاح عن الإعاقة حقٌّ للشخص ذي الإعاقة وحده.
ولذلك، من المهم أن تتأكد أيّ جهة تستخدم هذه الأدوات من أنّ بيانات مستخدميها محمية وفق النظام، وأنها لا تُجمَع أو تُنقَل دون موافقةٍ صريحة.
ما البديل الحقيقي؟
حسنًا، تحدّثنا عن المشكلة بما يكفي. فما حلّها؟ الجواب يبدأ من حيث يجب أن يبدأ: من الدورة ذاتها، حلقةً بحلقة.
الاستراتيجية
ابدأ برؤيةٍ واضحة. أين أنت الآن؟ وأين التحديات؟ أدرِج إمكانية الوصول ضمن مؤشرات الأداء التي يُحاسَب عليها الفريق، واجعلها جزءاً من ثقافة المنشأة لا بنداً في قائمة الامتثال. واعرف من تخدم: كم عددهم؟ في أيّ مدنٍ يتوزّعون؟ ما التقنيات المساعدة التي يستخدمونها؟ هل عندك قناة تواصلٍ مفتوحة معهم؟ هل أجريتَ جلسة تركيزٍ واحدة معهم؟ وكيف العلاقة بينك كجهة وبين مجتمع الأشخاص ذوي الإعاقة؟
مؤشرات الأداء
اجعل إمكانية الوصول جزءاً ممّا يُقاس ويُحاسَب عليه. فإن لم تظهر في مؤشرات أداء الفريق، لن يمنحها أحدٌ الأولوية التي تستحقها.
تجربة المستخدم
تأكّد من أنّ فريق تجربة المستخدم يملك إرشاداتٍ واضحة لإمكانية الوصول، وأنه يعرف كيف يتفاعل مستخدمو التقنيات المساعدة مع المنتج. وهل فُحص نظام التصميم من جهةٍ مختصّة؟ توجد في المملكة شركاتٌ مهنية تقدّم هذا الفحص.
التطوير
أيّ كود غير دلالي يجب أن يُوقَف عند مراجعة الكود. على المراجِع أن يسأل: لماذا اخترتَ هذا العنصر؟ وكيف جعلته متاحاً؟
الاختبار
درّب فريق ضمان الجودة على استخدام التقنيات المساعدة حتى يتمكّنوا من رصد المشكلات بأنفسهم. فبدون فريقٍ يختبر المنتج كما يختبره المستخدم ذو الإعاقة، لا يمكنك أن تثق بأنّ ما بنيته يعمل فعلاً.
والأهم: وظّف أشخاصاً من ذوي الإعاقة
وأقولها من تجربة: في أحد المشاريع التي عملتُ عليها، كنتُ المطوّر وكنتُ في الوقت ذاته من يختبر إمكانية الوصول. كنتُ أكتب الكود ثمّ أفتح قارئ الشاشة وأتصفّح ما بنيته كما يتصفّحه أيّ مستخدمٍ كفيف. لم نحتج إلى أيّ أداة إصلاحٍ تلقائي، لأنّ من يعيش التجربة يومياً يرصد ما لا ترصده أيّ أداة.
ولا أقصد بالتوظيف المبرمجين فقط، وإن كان فيهم مبرمجون مبدعون. أقصد أن تضعهم في فِرَق ضمان الجودة ليختبروا منتجك بأيديهم، أو في أبحاث تجربة المستخدم ليحكموا على ما صمّمه الفريق، أو حتى في الجانب الإداري ليكونوا صوت المستخدم داخل المنشأة. هؤلاء يؤدّون دوراً مزدوجاً لا يستطيع غيرهم أن يؤدّيه: يعرفون المشكلة لأنهم يعيشونها، ويعرفون الحل لأنهم يعملون عليه.
وتُظهر إحصاءات هيئة رعاية الأشخاص ذوي الإعاقة أنّ نسب توظيف الأشخاص ذوي الإعاقة لا تزال متدنية مقارنةً بغيرهم. وهذا يعني أنّ هناك كفاءاتٍ متاحة تنتظر الفرصة.
أكثر من مجرّد رقم
ولعلّ أكثر ما يُحزنني هو سؤالٌ يتكرّر حين أتحدّث مع بعض المسؤولين عن هذا الموضوع: “كم عددكم أنتم؟”
إذ لو كان هناك شخصٌ واحد فقط، فإنسانيتنا تدعونا إلى أن نجعل خدماتنا متاحةً له. وفي ظل ما وفّرته الدولة من أدوات تشريعية من خلال نظام حقوق الأشخاص ذوي الإعاقة، وما قدّمته الجهات التنظيمية من استشاراتٍ وتسهيلات، فقد أصبح لدينا كلّ ما نحتاجه لنبدأ.
صدقني يا صديقي، لو كانت أدوات الإصلاح التلقائي تحلّ مشاكلنا، لاشتريتُها ولو بآلاف الريالات، ولما قعدتُ أطلب من الناس يساعدوني عشان أحجز تذكرة سفر، أو موعداً في مستشفى، أو تذكرة فيلم.
لن تنفع تعويذة ACCESSIBILIAMUS، ولن تنفع أيّ أداة تعِدُك بحلٍّ لا تبذل أنت جهداً فيه. ما ينفع هو أن تقرّر أنّ إمكانية الوصول ليست ملفاً تُغلقه، بل طريقةً تبني بها منتجاتك من الأساس. وأن ننقل هذا الحوار بأكمله من دائرة العاطفة والشفقة إلى دائرة الحقوق والعمل.
إمكانية الوصول ليست ميزة، بل متطلبٌ أساسي.
التعليقات
لا توجد تعليقات بعد.
سجّل الدخول للتعليق