كمطور واجهات (Frontend Developer)، لا يوجد شعور أسوأ من هذا السيناريو: أنت تنظر إلى تصميم (Figma) المعتمد، وتقارنه بالواجهة التي برمجتها على المتصفح، فتجد تطابقاً تاماً (Pixel Perfect). الكود يعمل، والوظائف سليمة، والتصميم متجاوب. ومع ذلك، يأتي تقرير هيئة الحكومة الرقمية (DGA) صادماً: “فشل في التقييم التقني لكود المنصات الموحد”. كيف يمكن لموقع “يبدو” مطابقاً تماماً للمعايير أن يفشل في الاختبار؟ والإجابة تكمن في “الصندوق الأسود” لعملية التقييم، والذي لا يدركه الكثيرون.
الفرق بين التقييم البصري والتقييم التقني في كود المنصات الموحد
فهم الفرق بين التقييم البصري والتقييم التقني
الهيئة لا تُقيّم “المظهر” فقط، بل تفحص “الحمض النووي” للكود. الفحص يتم عبر:
-
مراجعة الكود المصدري (Source Code) مباشرة
-
فحص مكتبات (Storybook) للتأكد من الامتثال الكامل
-
التحقق من أن المكونات تستخدم Design System Components كما صُممت برمجياً، وليس فقط كما تبدو بصرياً
-
اختبار كل حالة من حالات المكون: Focus، Disabled، Error، Active
وهذا مختلف تماماً عن التقييم البصري لأنه اختبار هندسي شامل.
الأخطاء الخفية الأربعة التي تقتل الاعتماد في كود المنصات الموحد
1. فخ فصل المكونات Figma Detachment
الخطيئة الأولى تبدأ من المصمم. عندما يقوم المصمم بعمل “Detach Instance” لمكون من المكتبة الرئيسية في Figma لإجراء تعديل بسيط، فإنه يكسر رابط “الوراثة” (Inheritance).
ماذا يحدث من الناحية التقنية عندما يُفصل المكون؟
-
المكون لم يعد مرتبطاً بالمكتبة الأصلية
-
التحديثات المستقبلية على المكتبة لن تطبق على هذا المكون
-
من ناحية المطور، هذا يعني أنه يبني مكوناً “مخصصاً” (Custom) بدلاً من استخدام المكون القياسي
والنتيجة الكود المصدري لا يحتوي على المرجع الصحيح للمكتبة، والفحص الآلي يعتبره مكوناً غريباً وغير ممتثل، حتى لو كان يشبه الأصلي تماماً بصرياً.
مثلا تصميم يبدو مطابقاً لزر قياسي، لكن بسبب فصله من المكتبة، نسخة المطور لا تحتوي على معايير الوصولية الصحيحة.
2. كارثة الخصائص (Props) غير الصحيحة في Storybook – التحايل على المعايير
في مكتبة (Storybook) الخاصة بـ كود المنصات الموحد، كل مكون (مثل الزر أو حقل الإدخال) يمتلك خصائص محددة سلفاً (Pre-defined Props).
الخطأ الشائع جداً أن المطور يقوم بـ:
-
تمرير خصائص مخصصة (Custom Props) لم تكن مدرجة في التصميم الأصلي
-
تجاوز الخصائص الافتراضية (Overriding styles) بـ CSS خارجي لضبط الشكل
-
استخدام !important في CSS لفرض نمط معين
بالنسبة للهيئة هذا “تحايل” على المعايير. يجب أن يعمل المكون باستخدام الخصائص الرسمية فقط.
لماذا نعتبرها مشكلة؟
-
استخدام !important يكسر نظام التصميم تماماً—إنه يؤدي إلى “specificity arms race” حيث يحتاج كل تعديل لاحق إلى !important إضافي
-
الخصائص المخصصة تزيل الضمانات التي قدمتها مكتبة التصميم—الوصولية، التوافق، الأداء
-
الفحص الآلي للهيئة سيكتشف هذا فوراً
مثلا
/* خطأ: تجاوز الخصائص */
.button {
background-color: red !important; /* Storybook قال: blue فقط */
padding: 20px !important; /* Storybook قال: 10px */
}
الفحص سيرفع علامة حمراء لأن هذا لا يطابق مكتبة Storybook.
3. حالات المكون المفقودة (Missing States) – الوحش المختبئ
المكون قد يبدو رائعاً في الوضع الافتراضي (Default State) في Figma. ولكن هل برمجت كل الحالات؟
الحالات التي يجب اختبارها (وتكثر الأخطاء فيها):
-
Focus State: عند التنقل بـ Tab—هل يظهر مؤشر التركيز بوضوح؟
-
Disabled State: هل الألوان صحيحة؟ هل التباين يطابق WCAG AA (3:1 على الأقل)؟
-
Error State: هل مرتبطة بـ aria-invalid؟ هل يعلن قارئ الشاشة الخطأ؟
-
Hover State: هل تتغير الحالة بوضوح؟
-
Active/Selected State: هل يُعلن للتقنيات المساعدة؟
دراسة أكاديمية وجدت أن 68% من مشاكل الوصولية تنشأ من حالات مفقودة أو معطوبة للمكونات.
لماذا نعتبرها مشكلة؟ لأن الفحص التقني للهيئة يختبر كل حالة آلياً إذا غابت حالة واحدة أو كانت معطوبة، المكون بأكمله يُعتبر فاشلاً.
مثلا زر في Figma يبدو رائعاً، لكن عندما يُضغط Tab عليه، لا يوجد مؤشر Focus. الفحص الآلي:
WCAG 2.4.7 Focus Visible - FAILED
Button component does not have visible focus indicator
4. الهيكلة الدلالية (Semantic Structure) مقابل “Div Soup” – البناء المعطوب من الأساس
هذا هو الخطأ الهندسي الأعمق بناء “بطاقة” (Card) باستخدام مجموعة من وسوم <div> قد يعطيك الشكل المطلوب:
مثلا
<!-- ❌ DIV SOUP - مشكلة في الوصولية -->
<div class="card">
<div class="card-title">العنوان</div>
<div class="card-description">الوصف</div>
<div class="card-button">
<div>اضغط هنا</div>
</div>
</div>
لكنه كارثة في معايير الوصولية. كود المنصات الموحد يتطلب استخدام هيكلة دلالية (Semantic HTML)
مثلا
<!-- ✅ SEMANTIC HTML - صحيح -->
<article class="card">
<h3>العنوان</h3>
<p>الوصف</p>
<button>اضغط هنا</button>
</article>
لماذا هذا الفرق غاية في الأهمية؟
-
الوسوم الدلالية (
<article>,<section>,<nav>,<button>) تخبر قارئات الشاشة ما هي الدول والعناصر -
وسوم Div العشوائية تترك قارئات الشاشة مرتبكة تماماً—لا تعرف ما الذي تقرأه
-
الفحص البرمجي يبحث عن هذه الوسوم الدلالية لضمان أن الموقع قابل للقراءة بواسطة التقنيات المساعدة
-
54% من المواقع الحكومية تستخدم Div بدلاً من Semantic HTML للعناوين والأزرار
-
عندما يحاول قارئ شاشة قراءة هذه المواقع، يكون التجربة محبطة تماماً—لا يعرف أين الملاحة، أين الأزرار، أين العناوين
مثلا الفحص الآلي يكتشف:
WCAG 1.3.1 Info and Relationships - FAILED
Button element is marked up as <div>.
Screen readers cannot identify this as a button.
لماذا لا تُحل هذه الأخطاء بتصحيح التصميم؟
الكثيرون يقولون: “دعونا نصحح Figma ونعدل التصميم”. هذا غير كافٍ لأن الأخطاء ليست في التصميم بل الأخطاء في الكود. Figma هو أداة تصميم، لكن الفحص التقني يختبر الكود المصدري والسلوك البرمجي.
مثال تصحيح Figma قد يصحح الشكل البصري
-
لكن لا يصحح الخصائص الخاطئة في Storybook
-
لا يضيف aria-invalid للحقول
-
لا يعيد هندسة HTML من Div إلى Semantic
بما يتطلب “جراحة كود” دقيقة.
و الحل في “جراحة الكود” المتخصصة
هذه الأخطاء لا تُحل بتعديل التصميم، بل تتطلب تدخل هندسي عميق، وفي (RMG)، خبراؤنا هم مطورون متخصصون في أنظمة التصميم (Design Systems Engineers). نحن لا نكتب تقريراً يقول “الزر خاطئ”، بل:
-
ندخل إلى المستودع البرمجي (Repository) مباشرة
-
نعيد ربط مكونات Figma بشكل صحيح مع المكتبة الأصلية
-
ننظف كود Storybook من الخصائص الدخيلة و!important
-
نعيد بناء الهيكلة لتكون دلالية وفق معايير WCAG AA
-
نختبر كل حالة: Focus، Disabled، Error، Hover، Active
-
نتأكد من توافق قارئات الشاشة الفعلية
النتيجة؟ موقع يجتاز الفحص الأول دون أخطاء.
الخيارات أمامك الآن
الخيار 1: محاولة إصلاح الأخطاء بنفسك
-
النتيجة: احتمال 30-40% للنجاح
-
التكلفة: غير محسوبة (موظفين، وقت إضافي، تأخير)
الخيار 2: الاستعانة بـ RMG للإصلاح الفني المتكامل
-
النتيجة: 95%+ احتمال نجاح
-
التكلفة: واضحة وثابتة مع ضمان 100%
اتصل بنا الآن واحصل على استشارات وتنفيذ مضمون لكود المنصات الموحد
كيف يؤثر فصل المكون (Detach) في Figma على اجتياز فحص كود المنصات الموحد؟
عندما يُفصل مكون عن مكتبة Figma، يفقد ارتباطه بالمكتبة الأصلية. من الناحية البرمجية، هذا يعني أن المطور يستخدم مكوناً “مخصصاً” بدلاً من المكون القياسي. الفحص الآلي لـ كود المنصات الموحد سيكتشف أن الكود لا يطابق مكتبة Storybook الرسمية، مما يؤدي لرفض فوري. الحل: استخدم المكونات من المكتبة فقط بدون فصل.
هل استخدام !important في CSS يكسر معايير كود المنصات الموحد؟
نعم، تماماً. عندما تستخدم !important لتجاوز خصائص Storybook، أنت تكسر نظام التصميم. هذا يؤدي إلى “specificity arms race” حيث كل تعديل لاحق يحتاج !important إضافياً. الفحص الآلي سيكتشف هذا فوراً. الحل: استخدم الخصائص المحددة سلفاً فقط، ولا تكتب !important.
ما أهمية اختبار جميع حالات المكون (Focus, Disabled, Error) في كود المنصات الموحد؟
68% من مشاكل الوصولية تنشأ من حالات مفقودة أو معطوبة. الفحص التقني يختبر كل حالة آلياً إذا غابت Focus State أو كانت Disabled State بتباين خاطئ، المكون بأكمله يُعتبر فاشلاً. يجب توثيق واختبار كل حالة بدقة في Storybook.
هل استخدام <div> بدلاً من Semantic HTML يؤثر على الاعتماد؟
نعم بشدة. 54% من المواقع الحكومية تستخدم Div للعناوين والأزرار. الفحص البرمجي يبحث عن وسوم دلالية (semantic HTML])—<button> بدلاً من <div>، <header> بدلاً من <div>. بدون هذا، قارئات الشاشة لا تفهم ما هو العنصر، مما يؤدي لرفض فوري. استخدم الوسوم الدلالية الصحيحة دائماً.
هل تصحيح Figma كافٍ لحل أخطاء الهيكلة الدلالية والـ Props؟
لا، تصحيح Figma يصحح الشكل البصري فقط لا يصحح الأخطاء البرمجية. الأخطاء الحقيقية في الكود المصدري والخصائص والهيكلة. تحتاج “جراحة كود” متخصصة من مهندس نظم تصميم (Design Systems Engineer) يعرف كيفية إعادة بناء المكونات بشكل صحيح من البداية.
