ربما مررتم بهذا السيناريو أو سمعتم عنه: فريق العمل أنفق أشهراً في التطوير، والمصممون أكدوا أن الواجهات مطابقة تماماً للهوية البصرية، وتم تسليم المشروع بثقة. ثم تأتي الصدمة في رسالة بريد إلكتروني واحدة من هيئة الحكومة الرقمية (DGA): “المنصة غير ممتثلة”.
لماذا تفشل 70% من الجهاتتقييم كود المنصات الموحد؟
فجأة، يتجمد المشروع، ويتعطل الجدول الزمني، وتصبح ميزانيتكم في خطر حقيقي. إذا كنتم تواجهون هذا الموقف، فأنتم لستم وحدكم. هذا السيناريو هو “قاتل المشاريع” الأكثر شيوعاً حالياً، والسبب ليس ضعفاً في فريقكم، بل هو سوء فهم جوهري لطبيعة “التقييم“.
وفقاً لدراسة WebAIM فإن 94.8 % من صفحات الويب الرئيسية تحتوي على أخطاء WCAG قابلة للكشف الآلي، بمتوسط 51 خطأ لكل صفحة. وفي المملكة المتحدة، وجدت دراسة حكومية أن 99% من المواقع الحكومية تحتوي على مشاكل وصولية، مع متوسط 6 مشاكل لكل موقع، وربع المواقع تحتوي على 9 مشاكل أو أكثر. في بعض الحالات، وجدت مواقع بـ 26 مشكلة وصولية على صفحتها الرئيسية فقط!
هذا يعني أن نسبة الفشل في المحاولة الأولى ليست 30% فقط، بل قد تصل إلى70% أو أكثر وهذا ينطبق تماماً على الجهات الحكومية السعودية التي تحاول اجتياز تقييم كود المنصات الموحد.
لماذا يشيع الفشل جداً؟
السبب ببساطة هو أن تقييم كود المنصات الموحد ليس مسابقة لجمال التصميم، بل هو فحص تقني شرعي وعميق للكود المصدري (Source Code). الهيئة لا تنظر فقط إلى واجهة الموقع، بل تطلب إيداع الكود عبر منصة (Git) لفحصه آلياً ويدوياً. وهنا تظهر”الأخطاء القاتلة” التي لا تُرى بالعين المجردة.
الأخطاء التقنية الشائعة الـ 7 الأكثر فتكاً
1. الفشل في تطبيق معايير الوصولية (WCAG) السبب رقم 1 للرفض
هذا هو السبب الأول والأكثر حتمية للرفض. الأمر لا يتعلق فقط بتباين الألوان (رغم أن79.1% من الصفحات تعاني من مشكلة تباين لوني منخفض). بل يتعلق بالبنية التحتية للكود نفسه:
- هل يمكن تصفح الموقع كاملاً باستخدام لوحة المفاتيح فقط؟معظم المواقع لا—هيئة الحكومة الرقمية ستختبر هذا يدوياً.
- هل تتوافق العناصر مع قارئات الشاشة؟دراسات حديثة تظهر أن55.5% من الصفحات تفتقد نصاً بديلاً للصور.
- هل البنية الدلالية للكود (Semantic HTML) دقيقة؟خطأ واحد في استخدام الـ<div>بدلاً من<header>أو<nav>كفيل برفض الاعتماد.
- الهيئة لا تتهاون في معايير الوصولية، وأي خلل في الهيكلة الدلالية أو في تجربة الاستخدام سيؤدي حتماً إلى رفض الاعتماد.
وأكثر الأخطاء الشائعة
- تباين لوني منخفض:79.1% من الصفحات
- نص بديل مفقود للصور:55.5% من الصفحات
- تسميات نماذج مفقودة:48.2% من الصفحات
- روابط فارغة:45.4% من الصفحات
- أزرار فارغة:29.6% من الصفحات
2. التعديل غير المسموح على مكتبة Storybook
المطورون يحبون التخصيص وقد يقوم المطور بتعديل بسيط في كود مكون “الزر” (Button) ليبدو أجمل، أو يغير السلوك قليلاً “ليحسّن” الأداء معتقداً أنه يحسن التصميم. بالنسبة لهيئة الحكومة الرقمية، هذا “عبث” بالكود الموحد. الفحص الآلي يقارن كودكم مع مكتبة Storybook الرسمية(axe-core يمكنه اكتشاف حتى 57% من مشاكل WCAG تلقائياً)، وأي انحراف في الخصائص (Props) أو الهيكلة الدلالية يؤدي للفشل الفوري.
مثلا مطور يغير الـaria-label على زر تغيير صغير يبدو تافهاً. لكن هيئة الحكومة الرقمية تكتشفه وتعتبره خروجاً عن المعيار الموحد.
3. الفجوة المخادعة بين Figma والكود
التصميم على (Figma) قد يبدو مطابقاً 100% للمعايير جميع الألوان صحيحة، جميع الأحجام موحدة. لكن الكود الذي بناه المطور لا يتبع الإرشادات الدلالية للمكون. الهيئة تقيم الكود، وليس ملف التصميم، والخطأ الشائع تصميم يستخدم<div>بدلاً من<button>لأنه “أسهل في التصميم”، والنتيجةفشل كامل في الوصولية والتوافق مع قارئات الشاشة.
4. استخدام مكونات جاهزة بدون اختبار حقيقي
الكثير من فرق التطوير تستسهل الاعتماد على مكتبات جاهزة (UI Kits) دون اختبار مدى مطابقتها الفعلية لكل السيناريوهات، خصوصاً عند تخصيص المكونات أو بناء مسارات خدمات متقدمة. هنا تظهر المشاكل الخفية:
- فقد التركيز (Focus Loss) عند الانتقال بين العناصر
- تشوش قراءة البرنامج الناطق للمحتوى
- صعوبة التنقل للأشخاص ذوي الإعاقة الحركية
- عدم التوافق مع تقنيات مساعدة معينة
5. مشاكل النماذج والتفاعل الديناميكي
النماذج الحكومية معقدة بحقول متعددة، قوائم منسدلة، رسائل خطأ. في 48.2% من الصفحات، حقول النموذج لا تحتوي على تسميات مناسبة. هذا يعني أن قارئات الشاشة لن تفهم ما يُتوقع من المستخدم.
مثلا حقل “البريد الإلكتروني” بدون<label>مرتبطة به وقارئ الشاشة يقول فقط “حقل نص” دون توضيح.
6. أخطاء معالجة الـ PDF والملفات الأخرى
العديد من الجهات الحكومية لا تزال تستخدم ملفات PDF بدلاً من صفحات HTML. والمشكلة أن ملفات PDF عادةً ما تكون أقل وصولية من صفحات الويب، وعادةً لا تحتوي على معلومات تساعد التقنيات المساعدة على تفسير المحتوى.
متطلبات كود المنصات تشمل PDF أيضاً، فيجب أن تكون قابلة للقراءة بواسطة قارئات الشاشة، مع هيكلة دقيقة وتوسيم صحيح.
7. الهيكلة الدلالية المعطوبة والبنية المنطقية الخاطئة
أكثر من 50% من المواقع الحكومية التي فشلت في الاختبارات الأولى كانت تستخدم هياكل HTML خاطئة كاستخدام الـ<div>للملاحة بدلاً من<nav>، استخدام<span>للعناوين بدلاً من<h2>—<h6>، و هذا لا يؤثر على المستخدمين البصريين (الموقع يبدو طبيعياً)، لكن قارئات الشاشة تتعطل تماماً.والهيئة ستكتشف هذا في الفحص الآلي الأول!
“مشكلتكم الحقيقية ليست نقصاً في التقارير. إنها ‘فجوة التنفيذ'”
أنتم لديكم تقرير من استشاري يعدد 100 خطأ. هذا جيد. لكنم شكلتكم الحقيقية هي “فجوة التنفيذ”، فأنتم تفهمون المشاكل، لكن فريق التطوير لديكم (أو الشركة المتعاقدة)يفتقر للخبرة الدقيقة والمعقدة لإصلاح مكونات (Storybook) المعقدة – تطبيق (WCAG) برمجياً في كود متطور- فحص التوافق مع قارئات الشاشة الحقيقية – إعادة بناء النماذج والعناصر التفاعلية، والمطورون العاديون يقولون: “أضفنا aria-label، ألن تكون الآن متوافقة؟” الإجابة:لا. الوصولية ليست tag بسيط إنها ممارسة هندسية معقدة تتطلب فهماً عميقاً لكيفية عمل التقنيات المساعدة.
الحل يكمن في “التنفيذ المتكامل” بدلاً من التقارير المحبطة
في (RMG)، نحن لا نؤمن ببيع التقارير التي تزيد من حيرتكم. نموذجنا هو”التنفيذ المتكامل“: الفريق الذي يدقق الكود ويكتشف الأخطاء،هو نفسه الفريق الذي يفتح المحرر البرمجي و”يصلحها”، فنحن نمتلك الخبرة لإعادة بناء المكونات المعقدة وضمان اجتياز الفحص التقني خلالأسابيع، وليس شهوراً. من خلال منهجية عملية معقدة تشمل على سبيل المثال:
- اختبار آلي مستمر مع axe-core (يكتشف حتى 57% من المشاكل تلقائياً)
- اختبار يدوي من خبراء متخصصين في WCAG
- اختبار فعلي مع قارئات الشاشة الحقيقية
- معالجة مشاكل الـ PDF والملفات الأخرى
ضمان الامتثال الكامل لمعايير كود المنصات الموحد
ماذا لو تأخرتم عن الموعد النهائي؟ التأخير هنا ليس خياراً، فللهيئة لديها جدول زمني صارم. كل يوم تأخير يعني:
- عدم تفعيل الخدمة
- عدم توفرها للمواطنين
- تأثير مباشر على مؤشرات الحكومة الرقمية
لذا من الإضل أن تأخذوا الخطوة الأولى: “تدقيق فوري وإصلاح مضمون”
هل لديك تقرير “عدم الامتثال” على مكتبك الآن؟ لا تضيع المزيد من الوقت في محاولات الإصلاح العشوائية.تواصل معنا الآن لتحصل على
- تدقيق فوري لمعايير (WCAG) وكود المنصات الموحد
- إصلاح مضمون للأخطاء التقنية
- اختبار شامل مع الأدوات الحقيقية
- ضمان قبول الهيئة من المرة الأولى
- مضمون 100% أو نستمر في العمل حتى تحقيق الامتثال الكامل.
ما أسباب فشل معظم الجهات في اجتياز تقييم كود المنصات الموحد من المحاولة الأولى؟
الإجابة:أكثر من 70% من المواقع تفشل لأن 94.8% من الصفحات تحتوي على أخطاء WCAG. الأسباب الرئيسية: تباين لوني منخفض (79.1% من الصفحات)، نص بديل مفقود (55.5%)، تسميات نماذج مفقودة (48.2%)، وهيكلة دلالية معطوبة. الفشل ليس لأن المطورين غير أكفاء، بل لأن تقييم كود المنصات الموحد فحص تقني عميق للكود، وليس مسابقة تصميم.
هل التعديلات البسيطة على مكونات Storybook تؤثر على اجتياز التقييم؟
نعم، بشدة فأي انحراف في خصائص المكون (Props) أو الهيكلة الدلالية يؤدي لرفض فوري. هيئة الحكومة الرقمية تقارن كودك مع مكتبة Storybook الرسمية تلقائياً. تغيير بسيط في aria-label أو هيكل HTML كفيل برفع علامة الفشل في الفحص الآلي.
هل استخدام مكتبات تصميم جاهزة يضمن توافق WCAG؟
لا.حتى مع مكتبات جاهزة، 57% فقط من مشاكل WCAG يمكن اكتشافها تلقائياً بينما المشاكل الخفية تظهر عند التخصيص أو بناء مسارات معقدة. يجب اختبار كل مكون يدوياً مع قارئات الشاشة الحقيقية وقبل عرضه على الهيئة.
هل مشاكل الـ PDF تؤثر على اعتماد كود المنصات الموحد؟
نعم. معاييركود المنصات الموحد تشمل ملفات PDF والمحتوى الرقمي الآخر. ملفات PDF بدون هيكلة دقيقة أو توسيم صحيح ستؤدي لرفض الاعتماد. يجب أن تكون كل ملفات PDF الحكومية متوافقة WCAG مع نص يمكن البحث فيه وعناصر قابلة للوصول.
كيف أضمن أن فريقي يصلح الأخطاء بشكل صحيح ولا نفشل في الفحص الثاني؟
لا تعتمد على التقارير وحدها واطلب “تنفيذاً متكاملاً”. الفريق الذي يدقق الكود يجب أن يكون نفسه الذي يصلحه، بخبرة عملية في: اختبار آلي مع axe-core، اختبار يدوي مع قارئات الشاشة الحقيقية، واختبار التوافق الكامل مع معاييركود المنصات الموحد و RMG توفر هذا الضمان 100%.
