وهم إضافة “سهولة الوصول” لاحقا: التصميم الشامل للخدمات في بوابات القطاع العام

إنّ العبارة الأكثر تكلفة في المشتريات الرقمية للمؤسسات والحكومات هي: “سنقوم بإجراء تدقيق لسهولة الوصول (Accessibility Audit) قبل الإطلاق مباشرة.”

عندما نتعامل مع سهولة الوصول الرقمية (Digital Accessibility) كإجراء شكلي في اللحظة الأخيرة بدلاً من كونها أساساً تُبنى عليه المنصة، تكون النتيجة كارثية. فالنتيجة هي موقع مرقّع بحلول مؤقتة: مكونات واجهة (UI Components) تشمل أزراراً لا تعمل بشكل صحيح (مثل عناصر <div>)، وصعوبة في التنقل باستخدام لوحة المفاتيح، وهياكل صفحات (DOM Trees) تعجز قارئات الشاشة عن قراءتها للمكفوفين، مما يتسبب في أعطال متكررة وتكاليف إصلاح باهظة يُطلق عليها الديون التقنية.

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

بيانات معايير الصناعة:

وفقاً للأبحاث الكلاسيكية لدورة حياة البرمجيات (SDLC) من معهد آي بي إم لعلوم الأنظمة (IBM Systems Sciences Institute) والمعهد الوطني للمعايير والتقنية (NIST)، فإن إصلاح عيب هيكلي في مرحلة الإنتاج (Production) يكلف ما بين ٣٠ إلى ١٠٠ مرة أكثر من معالجته خلال مرحلة التصميم والمتطلبات الأولية. (https://totalshiftleft.com/blog/why-bugs-keep-reaching-production)

أما في مجال سهولة الوصول الرقمية، فتتوقع شركة (Deque Systems) أن تزيد تكلفة الإصلاح في المراحل المتأخرة بمقدار ١٠٠ ضعف. ففي حين أن حل الخلل في مرحلة التصميم الأولى يكلف ما بين ١٠٠ و ٢٥٠ دولاراً فقط، فإن تعديل موقع مكتمل يعمل بالفعل يتطلب إعادة بناء الكود البرمجي (Cascading DOM Refactoring)، وتعديل تنسيقات الصفحات (CSS Architecture)، وتحديث نظام التصميم بالكامل (Design System)، وإعادة فحص الموقع يدوياً باستخدام أدوات ذوي الإعاقة (Assistive Technologies) — مما يرفع تكلفة إصلاح الخلل الهيكلي الواحد إلى أكثر من ١٠ ألاف دولار. (https://betterqa.co/bug-fixing-costs-throughout-sdlc/)

العملية الحسابية: الخطأ الذي يستغرق إصلاحه ٣٠ دقيقة في مرحلة المتطلبات، يستغرق من يومين إلى ٥ أيام وأكثر من ١٠ ألاف دولار لإصلاحه في مرحلة الإنتاج.

خطأ “ترقيع سهولة الوصول لاحقاً” في البيئات ذات البيروقراطية العالية

تُدار بوابات القطاع العام والشركات وسط تعقيدات إدارية وبيروقراطية كثيرة؛ حيث يتوزع العمل بين لجان متعددة وشركات تنفيذية متداخلة. ونتيجة لذلك، تُعامل سهولة الوصول كشرط شكلي وعابر في العقود (مثل كتابة جملة “يجب الامتثال لمعايير WCAG 2.2 AA”) دون وجود متابعة فعلية للتطبيق الحقيقي منذ البداية.

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

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

والنتيجة المحزنة هي أن هذه المواقع تظل معطلة لسنوات — بل لعقود أحيانا — ويبقى الناس يعانون في استخدامها كل يوم. هذا هو الثمن الحقيقي لإهمال الأساس منذ اليوم الأول.

طريقة التطوير التقليدية (Traditional Development Way): بناء الموقع —> اكتشاف العيوب —> محاولة الترقيع —> تعطل واجهة المستخدم (UI)

طريقة الشمول المدمج (Built-In Inclusion Way): وضع الضوابط مبكراً —> تصميم مسارات استخدام بسيطة —> بناء مكونات برمجية نظيفة —> الاختبار الشامل قبل الإطلاق

وعندما يفشل فحص اللحظات الأخيرة حتماً، يسارع المطورون لتطبيق تصحيحات وتدابير سطحية:

• إضافة تسميات شكلية (مثل سمات aria-label) على عناصر غير مخصصة (مثل <div>) دون حل مشكلة التنقل وإدارة حالة التركيز (Focus State Management).
• فرض تعديلات مرئية قسرية في التنسيقات (CSS) تُفسد تجاوب الصفحة مع الجوال (Responsive Reflow) وتمنع تكبير النص.
• إضافة برمجيات أو “أدوات سهولة الوصول” خارجية (Widgets) تتداخل مع قارئات الشاشة الأصلية وتُعطلها، وتفشل في الاختبارات القانونية.

النتيجة: تجربة مستخدم هشة وغير متناسقة تضر بالمستخدم النهائي، وتُعرّض الجهة للمسؤولية القانونية لعدم الامتثال للمعايير الدولية والمحلية (مثل معايير WCAG 2.2 AA وإرشادات هيئة الحكومة الرقمية DGA في السعودية).

بناء البوابات الحكومية عبر “المستويات الخمسة لتجربة المستخدم” (The 5 Planes of UX)

لتفادي إخفاقات سهولة الوصول في المنصات الكبرى يجب على فِرق الهندسة والتصميم اعتماد إطار عمل “المستويات الخمسة لتصميم تجربة المستخدم” (Five Planes of UX Framework) وهي:الاستراتيجية، النطاق، الهيكل، الهيكل العظمي، والسطح؛ كدليل عملي موحد لبناء موقع شامل وسهل الاستخدام للجميع منذ اليوم الأول.

١. مستوى الاستراتيجية: المتطلبات القانونية كرؤية للمنتج

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

• اعتماد المعايير في العقود: جعل الامتثال لمعايير سهولة الوصول (مثل WCAG 2.2 AA) شرطا أساسيا وغير قابل للتفاوض في عقود المشتريات والتعاقدات.
• تمثيل جميع المستخدمين: تضمين الأشخاص الذين يعتمدون على التقنيات المساعدة — مثل قارئات الشاشة (NVDA ،VoiceOver) وأجهزة التحكم البديلة وأوضاع التباين العالي — ضمن شرائح المستخدمين المستهدفة. وهذا من اليوم الأول.

٢. مستوى النطاق: تحديد الميزات والمحتوى

سياق المستوى: المتطلبات الوظيفية ومتطلبات المحتوى. أي يحدد هذا المستوى الميزات المطلوبة في البوابة والمعلومات التي يحتاجها المستخدم لإتمام مهمته. ومنه:

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

٣. مستوى البنية: تنظيم عمل البوابة وطرق التنقل

سياق المستوى: تصميم التفاعل (Interaction Design) وهيكلة المعلومات (Information Architecture). أي يتحكم هذا المستوى في كيفية تحرك المستخدم داخل الموقع وتنفيذه للعمليات متعددة الخطوات:

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

٤. مستوى الهيكل التخطيطي: بناء العناصر التفاعلية

سياق المستوى: النماذج الهيكلية (Wireframes)، وطرق التنقل (Navigation)، وتخطيط الواجهة (Interface Layout). أي يحدد هذا المستوى طريقة عمل الأزرار والقوائم والنماذج عند النقر عليها أو التفاعل معها:

• استخدام العناصر القياسية: بناء الأزرار والقوائم باستخدام المكونات الأساسية للويب (مثل <button>) بدلاً من ابتكار أشكال معقدة، لتتمكن قارئات الشاشة من التفاعل معها تلقائياً.
• حجم مناسب للنقر: جعل الروابط والأزرار بحجم ملائم (٢٤*٢٤ بكسل كحد أدنى) ليتمكن مستخدمو الجوال، أو من يعانون من ارتعاش في اليد، من النقر عليها بسهولة ودون أخطاء.

٥. مستوى المظهر الخارجي: ضبط الألوان والشكل النهائي

سياق المستوى: التنسيق المرئي، ورموز التصميم، والمكونات النهائية. وهو الطبقة المرئية الأخيرة التي تشمل الألوان والخطوط والتفاصيل الجمالية:

• تباين عالٍ للألوان: اختيار ألوان متضادة بوضوح للنصوص والخلفيات ليتمكن ضعاف البصر — أو من يقرأ الشاشة تحت أشعة الشمس الساطعة — من قراءة المحتوى بلا عناء.
• إظهار مؤشر التركيز (Focus Indicator): الإبقاء على الإطار المرئي الذي يحيط بالزر أو الرابط عند التنقل باستخدام لوحة المفاتيح ليعرف المستخدم مكانه الحالي في الصفحة دائماً.

مقارنة النهج المعماري

المستوى المعماري	النموذج التقليدي (التعديل اللاحق)	التصميم الشامل المدمج للخدمات
الاستراتيجية	يُعامل كفكرة لاحقة أو عبء للتوافق الشكلي.	يُعامل كشرط أساسي وغير قابل للتفاوض في المشروع.
النطاق	نماذج طويلة بحقول غير محدودة ونصوص قانونية معقدة.	مسارات عمل مبسطة مع تطبيق إلزامية اللغة الواضحة.
البنية	ترتيب برمجي فوضوي للكود (DOM Tree) يعتمد على حيل الشكل المرئي.	تسلسل برمجي منطقي للكود (DOM Tree) يتماشى مع ترتيب التنقل المرئي.
الهيكل التخطيطي	أزرار وأدوات مخصصة (مثل عناصر <div>) تتطلب ترقيعات جافا سكريبت.	عناصر HTML أساسية وأصلية تدعم التنقل بلوحة المفاتيح تلقائياً.
المظهر الخارجي	اختيار الألوان للجماليات فقط، وتعديل التباين يتم متأخراً بعد التدقيق.	نظام تصميم يضمن تباين الألوان ووضوح النصوص تلقائياً.

عرض المعلومات بالتدريج: الحفاظ على بساطة الموقع مع الالتزام بالمتطلبات القانونية

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

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

لتطبيق هذا الأسلوب مع ضمان سهولة الوصول:

• استخدام العناصر الأساسية للويب: الاعتماد على العناصر البرمجية الجاهزة (مثل <details> و <summary>) لإنشاء القوائم القابلة للطي، بدلاً من بنائها من الصفر بطرق معقدة.
• إعلام قارئات الشاشة بالتغييرات: عند فتح قائمة أو إظهار نص مساعدة مخفي، يجب برمجة الموقع ليُبلغ قارئ الشاشة فوراً بهذا التغيير (عبر خصائص مثل aria-expanded)، ليتمكن المكفوفون من متابعة ما يحدث.
• الحفاظ على ترتيب القراءة المنطقي: ترتيب الكود البرمجي للصفحة بشكل منطقي، حتى لا يفقد مستخدمو قارئات الشاشة أو لوحة المفاتيح مكانهم أو يواجهوا قفزات مفاجئة (Focus Skips) عند ظهور المحتوى الجديد.

جعل سهولة الوصول عملية آلية (Automated) في المؤسسات الكبرى

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

مسار العمل الآمن للمؤسسات:

مكونات تصميم جاهزة (Design Tokens)

—> فحص آلي للأكواد (Automated Checks) 

—> بوابات الموافقة الآلية (CI/CD Gates) 

—> فحص يدوي أخير (Manual Audits)

كيف تضمن تطبيق سهولة الوصول في مراحل التطوير؟

• الاعتماد على نظام تصميم موحد (Shared Design System): توفير مكتبة مركزية تضم مكونات الواجهة (مثل الأزرار، والنماذج، والنوافذ المنبثقة) التي تم فحصها وضمان توافقها مسبقاً. بهذه الطريقة، تستخدم فرق التطوير مكونات جاهزة يسهل الوصول إليها تلقائياً، دون الحاجة للبدء من الصفر في كل مشروع جديد.
• المنع الآلي للأكواد المخالفة (CI/CD Build Gates): ضبط أنظمة النشر التلقائية لاكتشاف ورفض أي كود برمجي لا يلتزم بمعايير سهولة الوصول بشكل آلي قبل اعتماده أو إطلاقه.
• فرض الاختبار اليدوي الفعلي: تكتشف الفحوصات الآلية حوالي ٣٠% إلى ٥٠% فقط من الأخطاء. لذا، يجب إجراء اختبارات يدوية باستخدام لوحة المفاتيح وقارئات الشاشة (مثل NVDA و VoiceOver) كخطوة إلزامية لضمان الجودة قبل الاعتماد النهائي للمشروع.
• ربط عقود الشركات المنفذة بتقارير الامتثال (VPAT/ACR): ألزم المقاولين والشركات الخارجية بتقديم تقارير مستقلة تثبت توافق الموقع مع معايير سهولة الوصول. اجعل اجتياز هذا الفحص شرطاً أساسياً وغير قابل للتفاوض لصرف الدفعات المالية النهائية للمشروع.

سهولة الوصول: الأساس المعماري للمشاريع الكبرى

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

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

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

ما تحتاجه حقا هو نهج عملي ومُجرب يوجهه خبير متمرس. فمن خلال وضع ضوابط واضحة لأساسات المشروع منذ اليوم الأول — أياً كانت منهجية العمل التي تختارها — يمكن لقادة التقنية ومهندسي الحلول (Solutions Architects) إطلاق خدمات رقمية متوافقة قانونيا، وموفرة للتكاليف، وجاهزة لاستخدام جميع أفراد المجتمع بكل سهولة منذ اللحظة الأولى.