يتحدث الجميع عن معايير الوصولية (WCAG)، لكن القليل جداً يعرف كيفية تطبيقها لدرجة “الاجتياز” في الفحص التقني الصارم لهيئة الحكومة الرقمية، والواقع يثبت أن عدم الامتثال لمعايير الوصولية هو السبب الأول والأكثر شيوعاً لرفض منح شهادة كود المنصات الموحد. والإحصاءات تؤكد ذلك حيث أن 94.8% من صفحات الويب تحتوي على أخطاء WCAG قابلة للكشف الآلي، وأدوات الفحص الآلي (مثل Lighthouse) لا تكتشف سوى 30% من أخطاء الوصولية الحقيقية، بينما الـ 70% المتبقية والتي تفشل بسببها المنصات تتطلب تدقيقاً بشرياً متخصصاً
قائمة التدقيق التقني لتطبيق معايير WCAG حسب متطلبات كود المنصات الموحد
المحور الأول: التباين اللوني Color Contrast – معيار الحد الأدنى
كود المنصات الموحد يعتمد ألواناً مستوحاة من الهوية الوطنية (الأخضر السعودي، وبنفسجي الخزامى). التحدي يكمن في استخدام هذه الألوان كخلفيات للنصوص.
النقاط التي يجب فحصها
☐ فحص النصوص العادية
-
هل تحقق نسبة تباين لا تقل عن 4.5:1 بين النص والخلفية؟
-
احذر من استخدام اللون الذهبي أو الأخضر الفاتح للنصوص البيضاء يفشل هذا الاختبار دائماً
-
استخدم أداوت مثل WebAIM Contrast Checker أو TPGi Color Contrast Analyzer للتحقق الفوري
☐ فحص العناصر غير النصية
-
هل أيقونات الواجهة وحدود حقول الإدخال والأزرار تحقق تباين 3:1 على الأقل؟
-
الأيقونات الملونة قد تبدو واضحة، لكنك تحتاج الاختبار البرمجي للتأكد
☐ فحص النصوص الكبيرة
-
إذا كان النص 18pt أو أكثر (أو 14pt إذا كان بسمك عريض)، يمكنك استخدام نسبة تباين 3:1
-
النصوص العادية تحتاج 4.5:1 دائماً
☐ استثناءات مسموحة:
-
الصور ذات الألوان الزاهية (مثل الشعارات والصور الفوتوغرافية) لا تطبق عليها معايير التباين
-
لكن إذا كان هناك نص فوق الصورة، النص يجب أن يحقق 4.5:1
المحور الثاني: التنقل بلوحة المفاتيح Keyboard Navigation – الاختبار الحقيقي
هذا هو الاختبار الحقيقي الذي يجريه مدققو الهيئة يدوياً. افصل “الفأرة” (Mouse) وحاول استخدام الموقع بـ زر (Tab) فقط:
النقاط التي يجب فحصها
☐ الوصول الشامل
-
هل يمكنك الوصول لـ كل عنصر تفاعلي (أزرار، روابط، قوائم منسدلة، حقول نصية) باستخدام لوحة المفاتيح؟
-
استخدم Tab و Shift+Tab للتنقل الأمامي والخلفي
☐ مؤشر التركيز Focus State الخطأ الأكثر فتكاً
-
هل يظهر إطار واضح ومرئي حول العنصر الذي تقف عليه حالياً؟
-
تحذير حاسم: العديد من المصممين يطلبون
outline: noneفي CSS لجماليات التصميم—هذا خطأ قاتل يمنع الاعتماد فوراً -
يجب أن يكون focus outline واضحاً—على الأقل 2px، بتباين 3:1
-
الحد الأدنى المقبول: border أو outline بسمك 2px وتباين واضح
☐ الترتيب المنطقي
-
هل ينتقل المؤشر بترتيب بصري منطقي؟ من اليمين لليسار (للعربية) ومن الأعلى للأسفل؟
-
أم يقفز عشوائياً دون منطق؟
-
تجنب استخدام
tabindexبقيم موجبة- استخدم DOM order فقط
☐ فخ لوحة المفاتيح
-
هل يمكن للمستخدم الخروج من أي نافذة منبثقة (Modal) باستخدام زر (Esc) دون أن يعلق؟
-
هل التركيز محصور داخل النافذة المنبثقة أثناء فتحها؟ (صحيح)
-
هل يمكن الخروج بسهولة؟ (مطلوب)
☐ القوائم المنسدلة والقوائم المعقدة
-
هل يمكن فتح القائمة بـ Enter أو Spacebar؟
-
هل يمكن التنقل بين الخيارات بـ Arrow Keys؟
-
هل يمكن إغلاق القائمة بـ Escape؟
المحور الثالث: قارئات الشاشة والهيكلة الدلالية Screen Readers & Semantics
وهنا يتم كشف “جودة الكود” الحقيقية!
النقاط التي يجب فحصها
☐ النصوص البديلة (Alt Text)
-
هل جميع الصور الوظيفية تحمل وصفاً دقيقاً وموجزاً؟
-
الصيغة الصحيحة:
<img src="..." alt="وصف الصورة"> -
مثال صحيح:
<img src="chart.png" alt="رسم بياني يوضح نمو المبيعات 2024"> -
مثال خاطئ:
<img src="chart.png" alt="صورة">أو<img src="chart.png">(بدون alt)
☐ الصور التجميلية (Decorative Images)
-
هل الصور التجميلية (مثل الخلفيات والفواصل) تحمل
alt=""(فارغ)؟ -
هذا يخبر قارئ الشاشة: “تجاهل هذه الصورة”—مما يعطي تجربة أنظف للمستخدمين
-
لا تحذف الـ alt attribute بالكامل—يجب أن يكون موجوداً لكن فارغاً
☐ الصور التي تحتوي على نصوص
-
WCAG يسمح استثناءاً قليلاً لصور النصوص، لكن الأفضل تجنبها
-
إذا كان لا بد منها، استخدم نفس النص في alt
☐ التسميات (Labels)
-
هل كل حقل إدخال (Input) مرتبط برمجياً بـ
<label>خاص به؟ -
الصيغة الصحيحة:
<label for="email">بريدك الإلكتروني</label>
<input type="email" id="email" />
-
الخطأ الشائع: استخدام placeholder فقط:
<!-- ❌ خاطئ - لا تسميات -->
<input type="email" placeholder="أدخل بريدك الإلكتروني" />
-
Placeholder ليس بديلاً عن Label: الـ placeholder يختفي عندما يكتب المستخدم—الأشخاص ذوو الذاكرة قصيرة سيفقدون السياق
☐ الهيكلة الدلالية (Semantic HTML)
-
هل تستخدم وسوم HTML الصحيحة دلالياً؟
-
زر الإجراء يجب أن يكون
<button>وليس<div>مع حدث onClick -
الروابط يجب أن تكون
<a>وليس<span>مع حدث click -
الملاحة يجب أن تكون
<nav>وليس<div class="navigation"> -
استخدام
<h1>إلى<h6>للعناوين، ليس<div class="title"> -
استخدام
<section>أو<article>للأقسام الرئيسية
☐ أيقونات بدون نص
-
هل الأيقونات التي تمثل أزراراً (مثل أيقونة القائمة ☰) تحمل
aria-labelأوtitle؟ -
الصيغة الصحيحة:
<button aria-label="فتح القائمة">☰</button>
المحور الرابع: التغذية الراجعة والمحتوى الديناميكي Dynamic Content & Feedback
النقاط التي يجب فحصها
☐ رسائل الخطأ (Error Messages)
-
عند فشل إرسال نموذج، هل ينتقل التركيز (Focus) آلياً إلى الحقل الخاطئ؟
-
هل يُقرأ نص الخطأ آلياً بواسطة قارئ الشاشة؟
-
هل حقل الخطأ مرتبط برمجياً بـ
aria-invalid="true"؟
☐ الرسائل المنبثقة (Toasts/Notifications)
-
هل رسائل النجاح (مثل “تم الحفظ بنجاح”) تمتلك
role="status"أوrole="alert"؟ -
هذا ينبه قارئ الشاشة فوراً بالتحديث دون انتقال التركيز
-
الصيغة الصحيحة:
<div role="status" aria-live="polite" aria-atomic="true">
تم حفظ البيانات بنجاح
</div>
☐ ARIA Live Regions
-
هل العناصر التي تتغير ديناميكياً (بدون إعادة تحميل الصفحة) مرتبطة بـ
aria-live="polite"؟ -
استخدم
aria-atomic="true"لإخبار قارئ الشاشة بقراءة كل المحتوى
☐ تحديثات القوائم والبيانات
-
عندما تتحدث البيانات (مثل عدد السلع في السلة)، هل يُعلن التحديث لقارئ الشاشة؟
المحور الخامس: اختبار الفيديو والملتيميديا
النقاط التي يجب فحصها
☐ الفيديوهات
-
هل جميع الفيديوهات تحمل نصوص مرئية (Captions) أو ترجمات؟
-
هل هناك وصف صوتي (Audio Description) للمحتوى البصري المهم؟
☐ الملفات الصوتية
-
هل هناك نسخة نصية (Transcript) للملفات الصوتية؟
تحذير حاسم: الاعتماد على الأدوات الآلية وحدها هو “وصفة للفشل”
❌ الخطأ الشائع: “استخدمنا Lighthouse وحصلنا على 95/100، إذن نحن متوافقون”
✅ الحقيقة: Lighthouse يكتشف فقط 30% من أخطاء الوصولية
الفحص من قبل هيئة الحكومة الرقمية يتضمن
-
فحص آلي باستخدام axe-core: يكتشف ~57% من الأخطاء
-
فحص يدوي باستخدام قارئات شاشة حقيقية: NVDA أو VoiceOver
-
اختبار التنقل بلوحة المفاتيح: بدون استخدام الفأرة
-
اختبار مع مستخدمين حقيقيين: ذوي إعاقات فعلية (قد يحدث هذا)
خطة العمل من RMG من هنا إلى الاعتماد
الخطوة 1: استدعاء خبراء الفحص
-
تدقيق شامل مع فحص محاكاة يدويّ حقيقي (Simulated User Testing)
-
اختبار مع قارئات شاشة فعلية
الخطوة 2: الإصلاح والتحقق
-
تصحيح الأخطاء تحت إشراف متخصصين
-
إعادة الفحص للتأكد من عدم إدخال أخطاء جديدة
تحذير نهائي
لا تخاطر بتجميد مشروعكم بسبب وسم HTML مفقود أو خطأ تباين لوني صغير.
هذه القائمة هي مجرد البداية. الفحص التقني الكامل يتطلب خبرة عميقة وأدوات متخصصة واتصل بنا وابدأ أجراءات الفحص والتدقيق وترقية موقعك لتحصل على شهادة اعتماد كود المنصات الموحد.
هل نسبة تباين لوني 4.5:1 هي المعيار الدولي للوصولية؟
نعم، WCAG 2.1 يتطلب 4.5:1 للنصوص العادية و 3:1 للنصوص الكبيرة (18pt) و 3:1 للعناصر غير النصية مثل الأيقونات. هذا هو المعيار الذي يطبقه كود المنصات الموحد في الفحص التقني. استخدم أداة WebAIM Contrast Checker للتحقق الفوري.
هل حذف outline من CSS يسبب رفض الاعتماد؟
نعم، تماماً. outline: none بدون بديل واضح هو خطأ قاتل يؤدي لرفض فوري. يجب أن يكون focus state مرئياً وواضحاً—على الأقل 2px border أو outline بتباين 3:1. الهيئة تختبر هذا يدوياً بـ Tab key.
هل استخدام Placeholder يغني عن استخدام Label؟
لا، أبداً. Placeholder ليس بديلاً عن Label. الـ Placeholder يختفي عندما يكتب المستخدم، مما يربك الأشخاص ذوي الذاكرة القصيرة. يجب استخدام <label> دائماً، مرتبطة برمجياً بـ for="id" مع حقل الإدخال.
هل الصور التجميلية تحتاج alt text؟
لا، الصور التجميلية تحتاج alt="" (فارغ)، وليس alt text. هذا يخبر قارئ الشاشة بتجاهلها. لا تحذف الـ alt attribute بالكامل—يجب أن يكون موجوداً لكن فارغاً.
هل أدوات الفحص الآلي كافية لضمان اجتياز تقييم كود المنصات الموحد؟
لا، أدوات الفحص الآلي تكتشف فقط 30% من أخطاء الوصولية. الـ 70% المتبقية تتطلب فحصاً يدوياً متخصصاً مع قارئات شاشة حقيقية (NVDA، VoiceOver) واختبار التنقل بلوحة المفاتيح. الهيئة تجري كل هذه الاختبارات معاً.









