قائمة تحقق إمكانية الوصول للويب: WCAG 2.2 للمصممين العاملين
قائمة تحقق WCAG 2.2 لإمكانية الوصول مرتبة حسب مكان العمل: Figma والمتصفح وما بعد الإطلاق. بالإضافة إلى خريطة ربط أخطاء المصمم بالمعايير.
معظم قوائم تحقق إمكانية الوصول للويب لا تفيد المصممين في شيء. إنها مرتبة حسب رقم معيار WCAG في مواصفة النجاح، وهذه هي الطريقة التي يقرأ بها المحامي المواصفة، وليست الطريقة التي يبني بها أحد البرمجيات.
المصممون لا يفتحون Figma وفي أذهانهم المعيار 1.4.3. يفتحون Figma ويختارون لون نص. قائمة التحقق المفيدة هي التي تلتقي بالمصمم في اللحظة التي يتخذ فيها القرار، وهذا يعني ثلاث قوائم منفصلة: واحدة لملف التصميم، وواحدة للمتصفح، وواحدة بعد الإطلاق. رتّبها بأي طريقة أخرى وستُتجاهل.
ما الذي يتطلبه WCAG 2.2 فعلاً
WCAG 2.2 هو المعيار العالمي الحالي اعتباراً من 2026، ويُضيف تسعة معايير نجاح جديدة فوق WCAG 2.1، تركز معظمها على الأجهزة المحمولة وأهداف اللمس والحمل المعرفي والمصادقة.
المعايير التسعة الجديدة التي تهم المصممين قائمة قصيرة. يصبح ظهور التركيز أكثر صرامة (2.4.11 و2.4.13). تحتاج إيماءات السحب الآن إلى بديل بدون سحب (2.5.7). لأهداف اللمس حجم أدنى يبلغ 24 × 24 CSS بكسل ما لم يكن حول الهدف مسافة كافية (2.5.8). يُشترط وضع المساعدة في نفس المكان على جميع الصفحات (3.2.6). لا يجوز للنماذج أن تطلب نفس المعلومات مرتين بدون مبرر (3.3.7). لا يجوز للمصادقة أن تعتمد على اختبار معرفي كتذكر كلمة مرور بدون بديل (3.3.8 و3.3.9).
AA هو المستوى الذي تشترطه معظم قوانين إمكانية الوصول حول العالم، بما فيها قانون إمكانية الوصول الأوروبي للاتحاد الأوروبي، والقسم 508 في الولايات المتحدة، ولوائح إمكانية الوصول لهيئات القطاع العام في المملكة المتحدة. AAA أكثر صرامة ويُخصص في الغالب للحكومات والرعاية الصحية والتعليم.
قائمة التحقق المرتبة حسب أرقام أقسام WCAG هي مواصفة. قائمة التحقق المرتبة حسب مكان العمل هي أداة.
الصيغة الوحيدة لقائمة التحقق التي تنجح
ثمة ثلاثة أماكن تُتخذ فيها قرارات إمكانية الوصول. ملف التصميم. الواجهة المبنية في المتصفح. الموقع في بيئة الإنتاج بعد الإطلاق.
ما يقارب 70% من إخفاقات إمكانية الوصول قرارات اتُخذت في Figma، و20% اتُخذت في مرحلة التنفيذ، و10% تتسرب بعد الإطلاق عبر تغييرات المحتوى أو التضمينات من جهات خارجية أو المواد التي ينتجها المستخدمون. أي قائمة تحقق لا ترتبط بهذه المراحل الثلاث تُجبر المصمم على الترجمة من لغة المواصفة إلى لغة سير العمل، وفي هذه الترجمة تُفقد العناصر.
بقية هذا المقال هي القوائم الثلاث بالترتيب. شغّلها بالترتيب. أي شيء يفشل في مرحلة التصميم يجب ألا يصل إلى مرحلة البناء. وأي شيء يفشل في مرحلة البناء يجب ألا يُطلق.
قائمة تحقق مرحلة التصميم (ما تفحصه في Figma)
ما يقارب 70% من إخفاقات إمكانية الوصول قرارات اتُخذت في ملف التصميم، وهذا يعني أيضاً أنها الأرخص في الإصلاح هناك.
| الفحص | معيار WCAG 2.2 | طريقة التحقق في Figma |
|---|---|---|
| نص الجسم يحقق تباين 4.5:1 مقارنة بخلفيته | 1.4.3 التباين (الحد الأدنى) | Stark أو Able أو مدقق التباين المدمج في Figma |
| النص الكبير (18pt+ أو 14pt+ بولد) يحقق 3:1 | 1.4.3 | نفس الأدوات |
| عناصر واجهة المستخدم غير النصية (الأزرار والحدود والأيقونات وحلقات التركيز) تحقق 3:1 | 1.4.11 التباين غير النصي | أخذ عينات يدوية من أزواج الألوان على اللوحة |
| أهداف اللمس بحد أدنى 24 × 24 CSS px (يُوصى بـ 48 × 48) | 2.5.8 حجم الهدف (الحد الأدنى) | قياس أبعاد الإطار مباشرة |
| المعلومات لا تُنقل بالألوان وحدها | 1.4.1 استخدام اللون | تحويل الإطار إلى تدرجات الرمادي (مكوّن إضافي لـ Figma أو فلتر لقطة الشاشة) |
| كل إطار صورة يحتوي على نص بديل في بيانات الطبقة | 1.1.1 المحتوى غير النصي | لوحة إمكانية الوصول في Figma أو وضع المطور |
| العناوين تُستخدم بترتيب منطقي (H1 ثم H2 ثم H3، لا H1 ثم H3 ثم H2) | 1.3.1 المعلومات والعلاقات | قراءة شجرة العناوين من الأعلى إلى الأسفل |
| حالة التركيز مصممة لكل عنصر تفاعلي | 2.4.7 التركيز المرئي، 2.4.11 التركيز غير المحجوب | كل مكون تفاعلي يحتوي على متغير تركيز |
| نص الرابط مفهوم خارج السياق | 2.4.4 غرض الرابط | لا توجد تسميات "انقر هنا" أو "اعرف المزيد" |
| تسميات النماذج مرئية وليست نصاً مؤقتاً فقط | 3.3.2 التسميات أو التعليمات | كل حقل يحتوي على تسمية دائمة خارج حقل الإدخال |
ملف التصميم هو أيضاً المكان الذي تكتشف فيه معايير WCAG 2.2 الجديدة للأجهزة المحمولة. أهداف النقر التي تفشل في تحقيق 2.5.8 تفشل في الغالب لأن المصمم كان يفكر بوحدات بكسل لسطح المكتب والهدف هو أيقونة 16 بكسل بدون حشو.
للتعمق في موضوع التباين تحديداً، انظر قواعد التباين وAPCA. عمل الألوان في مرحلة التصميم هو المكان الذي تخسر فيه معظم المواقع عملية المراجعة قبل كتابة سطر واحد من الكود.
قائمة تحقق مرحلة البناء (ما تفحصه في المتصفح)
المتصفح هو المكان الذي تُثبت فيه قرارات إمكانية الوصول أو تُكشف، لأنه أول مكان تلمس فيه تقنيات المساعدة الحقيقية عملك.
| الفحص | معيار WCAG 2.2 | طريقة التحقق في المتصفح |
|---|---|---|
| كل صفحة تعمل بلوحة المفاتيح فقط (tab وshift-tab وenter وspace والأسهم) | 2.1.1 لوحة المفاتيح | افصل الماوس وتنقل في الصفحة |
| ترتيب التركيز يتبع الترتيب المرئي (يسار إلى يمين، أعلى إلى أسفل في اتجاه LTR) | 2.4.3 ترتيب التركيز | اضغط tab وراقب حلقة التركيز |
| التركيز لا يُخفى بالرؤوس الثابتة أو بانرات ملفات تعريف الارتباط أو النوافذ المنبثقة | 2.4.11 التركيز غير المحجوب (الحد الأدنى) | قم بالتمرير أثناء الضغط على tab للتأكد من الظهور |
| تفاعلات السحب لها بديل بالنقر أو اللمس | 2.5.7 حركات السحب | افحص المنزلقات والقوائم القابلة للترتيب وعروض الشرائح |
| رابط "انتقل إلى المحتوى" يظهر عند الضغط الأول على tab | 2.4.1 تجاوز الكتل | اضغط tab مرة واحدة عند تحميل الصفحة |
| يُستخدم معالم HTML (header وnav وmain وfooter وaside) | 1.3.1، 4.1.2 | افحص مخطط DOM |
| أخطاء النماذج مُعلنة وليست مرمزة بالألوان فقط | 3.3.1، 3.3.3، 4.1.3 | أرسل نموذجاً خاطئاً مع قارئ الشاشة |
| قارئ الشاشة يُعلن العناوين والقوائم والأزرار بشكل صحيح | 4.1.2 الاسم والدور والقيمة | NVDA على Windows وVoiceOver على Mac وTalkBack على Android |
| سمات الإكمال التلقائي مضبوطة على حقول البيانات الشخصية | 1.3.5 تحديد غرض الإدخال | افحص autocomplete على حقول الاسم والبريد الإلكتروني والعنوان |
| الوسائط تحتوي على تعليق توضيحي أو نص تحريري أو أوصاف صوتية | 1.2.1 إلى 1.2.5 | شغّل كل فيديو وافحص المسارات |
الأدوات الآلية تكتشف نحو 30% من هذه العناصر. البقية تحتاج إلى إنسان يضغط tab ويستمع إلى قارئ شاشة. كلاهما مهم، ولا يُغني أحدهما عن الآخر.
أفضل مجموعة أدوات لمرحلة المتصفح في 2026 صغيرة: axe DevTools للمسح الآلي، وLighthouse لعمليات التدقيق على مستوى الصفحة، وقارئ شاشة حقيقي للمرور اليدوي. ثلاث أدوات وعشر دقائق لكل صفحة تكشف عن تقريباً كل ما سيُشير إليه مراجع فعلي.
قائمة تحقق ما بعد الإطلاق (ما تفحصه في بيئة الإنتاج)
إمكانية الوصول لا تنتهي عند الإطلاق، لأن المحتوى والتضمينات من جهات خارجية والمواد التي ينتجها المستخدمون تُطلق بعد أن يوقّع المصمم على العمل.
| الفحص | معيار WCAG 2.2 | طريقة التحقق في بيئة الإنتاج |
|---|---|---|
| الصور التي ينشئها CMS يُفرض عليها وجود نص بديل على مستوى المحرر | 1.1.1 | اختبر CMS: هل يمكن للمؤلف النشر بدون نص بديل؟ |
| الأدوات المضمنة من جهات خارجية (الدردشة والخرائط والنماذج) يمكن الوصول إليها | متباين | شغّل axe على الصفحات التي تحتوي على تضمينات |
| ملفات PDF والوثائق القابلة للتنزيل معلّمة وقابلة للقراءة | 1.1.1، 1.3.1، 2.4.6 | افتحها في مدقق إمكانية الوصول في Acrobat |
| روابط المساعدة والدعم والتواصل في نفس المكان في كل صفحة | 3.2.6 المساعدة المتسقة (جديد في WCAG 2.2) | مراجعة بصرية عبر القوالب |
| النماذج لا تطلب معلومات زائدة في مسار واحد | 3.3.7 الإدخال المتكرر (جديد في WCAG 2.2) | تنقل في النماذج متعددة الخطوات |
| المصادقة لها بديل يمكن الوصول إليه (مفاتيح المرور وروابط البريد الإلكتروني وSSO) | 3.3.8، 3.3.9 المصادقة الميسورة (جديد في WCAG 2.2) | جرّب التسجيل وتسجيل الدخول مع حظر مدير كلمات المرور |
| المحتوى الديناميكي (النوافذ المنبثقة والإشعارات ومناطق البث المباشر) مُعلن | 4.1.3 رسائل الحالة | شغّل كلاً منها مع فتح قارئ الشاشة |
| الصفحة تستمر في تحقيق قواعد التباين وحجم الهدف بعد تكبير المستخدم إلى 200% | 1.4.4 تغيير حجم النص، 1.4.10 إعادة التدفق | كبّر المتصفح إلى 200% وافحص |
| لا توجد وسائط تشغيل تلقائي، أو الوسائط تحتوي على عنصر تحكم للإيقاف المؤقت | 1.4.2 التحكم في الصوت، 2.2.2 إيقاف مؤقت وإيقاف وإخفاء | حمّل الصفحة من البداية |
| بانر ملفات تعريف الارتباط لا يحبس تركيز لوحة المفاتيح | 2.1.2 لا فخ للوحة المفاتيح | اضغط tab للدخول إلى البانر ثم tab للخروج |
قائمة ما بعد الإطلاق هي المكان الذي تفشل فيه معظم الفرق. التصميم أُطلق بإمكانية وصول مناسبة. ثم يملأ مؤلفو CMS الموقع بملفات PDF غير معلّمة ومقاطع فيديو بتشغيل تلقائي وأداة دردشة بنسبة تباين 2:1 على زر تشغيلها. إمكانية الوصول خاصية للنظام، لا مرحلة نهائية عند الإطلاق.
أخطاء المصممين الشائعة مربوطة بمعايير WCAG
كل نتيجة في تدقيق إمكانية الوصول ترتبط بمعيار نجاح محدد في WCAG، ومعظم المصممين يقعون في نفس الأخطاء الخمسة مقابل نفس المعايير الخمسة.
| خطأ المصمم | ما هو فعلاً | معيار WCAG 2.2 الذي ينتهكه |
|---|---|---|
| نص العنصر النائب كتسمية وحيدة | يفقد المستخدمون التسمية لحظة بدء الكتابة | 3.3.2 التسميات أو التعليمات |
| أزرار بأيقونات فقط بدون aria-label أو تلميح أداة | قارئات الشاشة تُعلن "زر" بدون غرض | 4.1.2 الاسم والدور والقيمة |
| رسائل خطأ تظهر بحدود حمراء أو نص أحمر فقط | المستخدمون المصابون بعمى الألوان لا يرون الخطأ | 1.4.1 استخدام اللون، 3.3.1 تحديد الخطأ |
| إزالة حلقة التركيز لأسباب جمالية | مستخدمو لوحة المفاتيح لا يرون أين هم | 2.4.7 التركيز المرئي |
| أهداف اللمس أقل من 24 × 24 px بدون مسافات | مستخدمو الأجهزة المحمولة يخطئون النقر باستمرار | 2.5.8 حجم الهدف (الحد الأدنى) |
| تباين منخفض في واجهات المستخدم "الخفية" (النص المؤقت والحالات المعطّلة ونص المساعدة) | القراء في ضوء الشمس أو ذوو ضعف البصر لا يستطيعون قراءته | 1.4.3 التباين (الحد الأدنى)، 1.4.11 التباين غير النصي |
| نافذة منبثقة تحبس التركيز لكن ليس بها إغلاق بـ ESC | مستخدمو لوحة المفاتيح محاصرون في النافذة | 2.1.2 لا فخ للوحة المفاتيح |
| عروض شرائح بتنقل بالسحب فقط | المستخدمون ذوو الإعاقات الحركية لا يستطيعون التقدم | 2.5.7 حركات السحب |
| رأس ثابت يُخفي العنصر المُركّز عليه عند الضغط على tab | المستخدمون يرون الصفحة تتمرير لكن يفقدون تتبع موضعهم | 2.4.11 التركيز غير المحجوب |
| تسجيل دخول بكلمة مرور فقط بدون SSO أو رابط بريد إلكتروني | فشل الحمل المعرفي | 3.3.8 المصادقة الميسورة |
نفس الأخطاء العشرة تشكّل غالبية كل تقرير تدقيق. أصلحها وستكون 80% في طريقك نحو WCAG 2.2 AA قبل أن يفتح أي مستشار جدول بيانات.
أساسيات إمكانية الوصول مرتبطة أيضاً بما تبقى من التسلسل الهرمي المرئي الجيد. التباين وحجم الهدف وحالات التركيز كلها قرارات هرمية. التصميم الذي يُتقن الهرمية يُتقن معظم قائمة تحقق إمكانية الوصول تلقائياً، ولهذا يكاد يكون التداخل بين نظرية الألوان الجيدة والتصميم الميسور تاماً.
كيف تشغّل قائمة التحقق بدون إضاعة أسبوع
قائمة التحقق مفيدة فقط إذا كان تشغيلها يستغرق دقائق لا أياماً، وهذا يعني أن الأدوات يجب أن تُنجز معظم العمل.
الإيقاع العملي هو ثلاثة مرورات، واحدة لكل مرحلة، كل مرة تصل العمل فيها إلى تلك المرحلة. ليس الثلاثة في النهاية. وليس واحدة منها في النهاية. ثلاث مرورات منفصلة، كل منها رخيصة، كل منها مدعومة بالأدوات حيثما أمكن.
- مرور التصميم: 10 دقائق لكل شاشة. Stark أو مدقق التباين في Figma على كل زوج من الألوان النصية، تحويل الإطار إلى تدرجات الرمادي لاختبار المعلومات القائمة على اللون وحده، قياس كل هدف لمس. افعل ذلك قبل تسليم الملف لا أثناء المراجعة.
- مرور البناء: 10 دقائق لكل قالب. مسح axe DevTools، اختبار التنقل بلوحة المفاتيح فقط، مرور واحد بقارئ الشاشة على أكثر الصفحات زيارة. ادمج axe-core في CI حتى لا يمكن دمج الكود الجديد مع تراجعات.
- مرور الإطلاق: شهرياً لا لكل إصدار. زحف axe أو pa11y على كامل الموقع في بيئة الإنتاج، تدقيق PDF على أي مكتبة وثائق، جولة يدوية عبر النماذج وتدفقات المصادقة.
هذا نصف يوم عمل شهرياً لكل منتج وربما 15 دقيقة لكل تسليم تصميم. أي شيء أكثر من ذلك والفريق سيتوقف عن تشغيله. وأي شيء أقل وتعود التدقيقات غير مُصلحة.
الأسئلة الشائعة
هل WCAG 2.2 مطلوب قانونياً؟
نعم، في معظم الأسواق الرئيسية. دخل قانون إمكانية الوصول الأوروبي حيز التنفيذ في يونيو 2025 ويشير إلى WCAG 2.1 كحد أدنى مع WCAG 2.2 كمعيار العمل الحالي. القسم 508 في الولايات المتحدة يشير إلى WCAG 2.0 لكن عقود المشتريات تشترط 2.2 بشكل متزايد. كندا والمملكة المتحدة وأستراليا واليابان لديها متطلبات مماثلة مرتبطة بـ WCAG 2.1 أو 2.2. إذا كنت تُطلق في أي من هذه الأسواق فـ 2.2 AA هو الهدف الآمن.
ما معايير WCAG 2.2 الجديدة التي أحتاج معرفتها فعلاً؟
أربعة منها تهم المصممين بشكل خاص. 2.5.7 حركات السحب يشترط بديلاً غير سحب لتفاعلات السحب. 2.5.8 حجم الهدف (الحد الأدنى) يشترط أهداف لمس بحجم لا يقل عن 24 × 24 CSS بكسل مع مسافة كافية. 2.4.11 التركيز غير المحجوب يشترط بقاء العنصر المُركّز عليه مرئياً خلال التمرير والتراكبات الثابتة. 3.3.8 المصادقة الميسورة يحظر الاختبارات المعرفية كتذكر كلمة مرور بدون بديل (SSO أو مفتاح مرور أو رابط بريد إلكتروني).
هل أحتاج قائمة تحقق منفصلة للأجهزة المحمولة؟
لا. WCAG 2.2 مكتوب صراحةً ليشمل الأجهزة المحمولة واللمس، ولهذا كثير من معاييره الجديدة (حجم الهدف والسحب والتركيز) تراعي الأجهزة المحمولة. نفس قائمة التحقق الثلاثية تعمل لويب الأجهزة المحمولة والتصميم المتجاوب. التطبيقات الأصلية لديها إرشادات منصة إضافية (HIG من Apple وإمكانية الوصول في Android) لكن قواعد WCAG لا تزال تنطبق.
ما الحجم الأدنى لهدف اللمس في WCAG 2.2؟
24 × 24 CSS بكسل هو الحد الأدنى وفق 2.5.8 حجم الهدف (الحد الأدنى)، لكن هناك استثناءات إذا كان حول الأهداف مسافة كافية أو كانت مدمجة في النص. الهدف العملي الذي يجب أن يسعى إليه معظم المصممين هو 48 × 48 CSS بكسل، وهو ما يتوافق مع توصيات منصتي Apple وGoogle ويتجنب الحالات الاستثنائية في مواصفة WCAG.
أطلق قائمة التحقق لا التخمين
إمكانية الوصول ليست مهمة امتثال. إنها خاصية تصميم، تُبنى في ثلاث لحظات، تُفرض بالأدوات، يتحقق منها البشر.
الفرق التي تُطلق مواقع ميسورة بدون معاناة ليست تلك التي لديها أفضل المدققين. إنها الفرق التي نقلت الفحوصات إلى مرحلة التصميم ومرحلة البناء ومرحلة الإطلاق، ورفضت السماح للعمل بالتقدم عبر أي منها مع وجود إخفاقات معروفة.
شغّل القوائم الثلاث. اكتشف الأخطاء العشرة الشائعة قبل أن تتراكم. أتمتة مسوحات مرحلة المتصفح في CI. دقّق الانجراف بعد الإطلاق شهرياً. سيتوقف WCAG 2.2 AA عن كونه خطاً للنهاية ويصبح خاصية لكيفية عمل الفريق.
اختر سطحاً واحداً من منتجك اليوم. شغّل قائمة تحقق مرحلة التصميم على ملف Figma الخاص به. عدّ الإصلاحات. هذا العدد هو تكلفة عدم تشغيل هذا في وقت أبكر.
أطلق قائمة التحقق لا التخمين.
Need a site that passes WCAG 2.2 without a three-month remediation cycle? Brainy ships accessible design from the first Figma frame.
Get Started
