قائمة تحقق WCAG 2.2 AA لمنتجات SaaS وتطبيقات الويب

قائمة تحقق WCAG 2.2 AA لمنتجات SaaS: تسجيل الدخول والنماذج ومربعات الحوار وتنقل تطبيقات الصفحة الواحدة والجداول والمخططات والسحب والمهلات وتقرير ACR.

فريق تحرير FixReportsتاريخ التحديث: 26 أكتوبر 2026مدة القراءة: 8 دقيقة

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

أبرز النقاط

أصبح WCAG 2.2 توصية من W3C في أكتوبر 2023، وأضاف تسعة معايير نجاح، ستة منها في المستوى A أو AA (W3C (يفتح في علامة تبويب جديدة)).
يعني معيار المصادقة القابلة للوصول (Accessible Authentication، 3.3.8، AA) أن تسجيل الدخول لا يجوز أن يعتمد على تذكّر كلمة مرور أو نسخها يدويًا، ما لم يتمكن الناس من لصقها أو استخدام مدير كلمات مرور (W3C (يفتح في علامة تبويب جديدة)).
يجب ألا تقل أهداف التفاعل عن 24 × 24 بكسل CSS، أو أن تحيط بها مساحة كافية (2.5.8، AA) (W3C (يفتح في علامة تبويب جديدة)).
يجب أن تصل رسائل مثل «تم الحفظ» أو «3 نتائج» إلى قارئات الشاشة دون نقل التركيز (4.1.3، AA) (W3C (يفتح في علامة تبويب جديدة)).
كثيرًا ما يطلب المشترون من الشركات والقطاع العام تقرير مطابقة إمكانية الوصول (Accessibility Conformance Report)، ويُكتب عادةً على نموذج VPAT الصادر عن مجلس صناعة تكنولوجيا المعلومات (ITI) (ITI (يفتح في علامة تبويب جديدة)).

لماذا تهم إمكانية الوصول في SaaS أكثر من موقع تعريفي؟

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

وتهم أيضًا لأن الاختبارات الآلية لا تلتقط إلا جزءًا من المشكلة. فأدوات مثل axe-core تجد الإخفاقات في الترميز، مثل غياب التسميات والتباين المنخفض. لكنها لا تستطيع أن تعرف ما إذا كان مربع الحوار يعيد التركيز إلى المكان الصحيح، أو ما إذا كانت بيانات المخطط متاحة كنص، أو ما إذا كان يمكن إكمال مسار عمل باستخدام لوحة المفاتيح. فالتطبيق يحتاج إلى الفحوصات الآلية والاختبار اليدوي معًا.

كيف تجعل التسجيل وتسجيل الدخول قابلين للوصول؟

المصادقة هي المجال الذي أضاف فيه WCAG 2.2 أهم متطلب جديد لمنتجات SaaS.

اسمح باللصق وبمديري كلمات المرور (3.3.8، AA). لا تمنع اللصق في حقول كلمة المرور أو الرموز، واستخدم autocomplete="username" وautocomplete="current-password" وautocomplete="one-time-code" حتى تتمكن المتصفحات ومديرو كلمات المرور من ملئها.
تجنّب الألغاز كطريق وحيد للدخول. فاختبار CAPTCHA الذي يطلب من الناس نسخ نص مشوّه أو حل لغز هو اختبار للوظائف الإدراكية. قدّم بديلًا، وفضّل الفحوصات التي لا تتطلب أي إجراء من المستخدم (W3C (يفتح في علامة تبويب جديدة)).
ضع تسمية لكل حقل (1.3.1 و3.3.2، A). استخدم عنصر <label> مرئيًا مرتبطًا بحقل الإدخال؛ فالنص النائب يختفي عندما يبدأ المستخدم الكتابة، وهو ليس تسمية.
حدّد الأخطاء نصيًا (3.3.1، A) واقترح طرق تصحيحها (3.3.3، AA). فرسالة «يجب أن تتكون كلمة المرور من 12 حرفًا على الأقل» تساعد؛ أما الإطار الأحمر وحده فلا.
لا تطلب المعلومة مرتين (3.3.7، A). إذا طلب التسجيل متعدد الخطوات اسم الشركة أو العنوان من قبل، فاملأه تلقائيًا أو اسمح للناس باختياره بدلًا من إعادة كتابته.
أبقِ المساعدة في المكان نفسه (3.2.6، A). إذا كنت تقدّم دردشة أو رابط مساعدة أو بيانات اتصال، فضعها في الموضع النسبي نفسه في كل صفحة من صفحات المسار.

ما أنماط النماذج والأخطاء التي تسبب أكثر الإخفاقات؟

النماذج هي موطن معظم إخفاقات التطبيقات. فقد وجد مسح WebAIM لعام 2026 لمليون صفحة رئيسية غياب تسميات النماذج في 51% منها (WebAIM (يفتح في علامة تبويب جديدة))، والتطبيقات تحتوي على نماذج أكثر بكثير من الصفحات الرئيسية.

امنح كل حقل إدخال اسمًا برمجيًا، واجمع عناصر التحكم المترابطة، مثل أزرار الاختيار، باستخدام <fieldset> و<legend>.
أخبر الناس بالأخطاء حيث سيلاحظونها: انقل التركيز إلى ملخص للأخطاء في أعلى النموذج، أو إلى أول حقل غير صالح، واربط كل بند في الملخص بحقله.
ميّز الحقول الإلزامية بالنص، لا باللون وحده (1.4.1، A).
لا ترسل النموذج ولا تغيّر السياق لمجرد أن شخصًا اختار خيارًا (3.2.2، A)؛ بل انتظر إجراءً صريحًا.

كيف يجب أن تتصرف مربعات الحوار والقوائم والنوافذ المنبثقة؟

المكونات المخصصة هي المكان الذي يتعطل فيه دعم لوحة المفاتيح وقارئات الشاشة أكثر من غيره. ويصف دليل ممارسات التأليف WAI-ARIA (ARIA Authoring Practices Guide) السلوك المتوقع لكل نمط (W3C (يفتح في علامة تبويب جديدة)).

مربعات الحوار: انقل التركيز إلى داخل مربع الحوار عند فتحه، وأبقِ Tab داخله ما دام مفتوحًا، وأغلقه بمفتاح Escape، وأعد التركيز إلى عنصر التحكم الذي فتحه. استخدم عنصر <dialog> الأصلي أو role="dialog" مع aria-modal="true" واسم.
لا مصائد للوحة المفاتيح (2.1.2، A): يجب أن يكون الخروج من كل مكوّن ممكنًا بلوحة المفاتيح.
تركيز مرئي (2.4.7، AA) لا تخفيه الرؤوس الثابتة أو شرائط ملفات تعريف الارتباط أو أدوات الدردشة (2.4.11، AA، جديد في 2.2).
التلميحات والنوافذ المنبثقة (1.4.13، AA) يمكن للناس إغلاقها بمفتاح Escape، وتحريك المؤشر فوقها دون أن تختفي، وتبقى ظاهرة حتى تُغلق.
اختصارات المفتاح الواحد (2.1.4، A): إذا كان الضغط على مفتاح حرف ينفّذ إجراءً، فاسمح للناس بإيقاف الاختصارات أو إعادة تعيينها، أو اجعلها تعمل فقط عندما يكون التركيز على المكوّن المعني.

كيف تتعامل مع التنقل في تطبيق الصفحة الواحدة؟

في تطبيق الصفحة الواحدة (single-page app) يتغير عنوان URL دون تحميل صفحة جديدة، لذا قد لا تعلن قارئات الشاشة أن شيئًا قد حدث.

حدّث عنوان المستند مع كل تغيير في المسار، حتى يكون لكل عرض عنوان وصفي (2.4.2، A).
انقل التركيز إلى العنوان الرئيسي للعرض الجديد، أو أعلن التغيير في منطقة حية من النوع polite؛ وتتضمن أطر عمل مثل Next.js أداة لإعلان تغيير المسار (route announcer) لهذا الغرض.
حافظ على ترتيب تركيز منطقي (2.4.3، A): فبعد حذف عنصر، يجب أن ينتقل التركيز إلى عنصر مجاور مناسب، لا أن يعود إلى أعلى الصفحة.
وفّر طريقة لتخطي التنقل المتكرر (2.4.1، A)، مثل رابط تخطٍّ أو معالم الصفحة (landmarks).

كيف تجعل لوحات المعلومات وجداول البيانات والمخططات قابلة للوصول؟

الجداول: استخدم ترميز <table> حقيقيًا مع <th> وscope للعناوين، وتسمية توضيحية (caption) (1.3.1، A). أما الشبكات المبنية من عناصر <div> فتحتاج إلى نمط ARIA grid الكامل، وإتقانه أصعب بكثير.
المخططات: امنح كل مخطط بديلًا نصيًا يذكر الفكرة الرئيسية، وقدّم البيانات في جدول (1.1.1، A). ولا تعتمد على اللون وحده للتمييز بين السلاسل (1.4.1، A)؛ بل أضف تسميات أو أنماطًا.
التباين: يحتاج النص إلى 4.5:1 (1.4.3، AA)، وتحتاج خطوط المخططات والأيقونات وحدود حقول الإدخال إلى 3:1 مقابل خلفيتها (1.4.11، AA). وافحص الوضع الداكن على حدة. وتختبر أداة فحص تباين الألوان لدينا أي زوج من الألوان.
رسائل الحالة (4.1.3، AA): يجب أن تستخدم رسائل «تم الحفظ» و«اكتمل الرفع» وأعداد النتائج role="status" أو منطقة حية، حتى تسمعها قارئات الشاشة دون أن يفقد المستخدم موضعه.

ما الذي تغيّره المعايير الجديدة في WCAG 2.2 لتطبيقات الويب؟

المعيار	المستوى	ماذا يعني في التطبيق
2.4.11 Focus Not Obscured (Minimum)	AA	يجب ألا تغطي أشرطة الأدوات الثابتة واللافتات وأدوات الدردشة العنصرَ الذي عليه التركيز تغطيةً كاملة
2.5.7 Dragging Movements	AA	كل ما يُنفَّذ بالسحب، مثل إعادة ترتيب لوحة kanban، يحتاج إلى بديل يعمل بمؤشر واحد، مثل قائمة أو زرَّي تحريك لأعلى ولأسفل
2.5.8 Target Size (Minimum)	AA	الأزرار والروابط لا تقل عن 24 × 24 بكسل CSS، أو متباعدة بحيث لا تتداخل دائرة قطرها 24 بكسل حول كل منها مع هدف آخر
3.2.6 Consistent Help	A	روابط المساعدة والدردشة وبيانات الاتصال في الموضع النسبي نفسه في كل صفحة
3.3.7 Redundant Entry	A	المعلومات التي أُدخلت سابقًا في العملية نفسها تُملأ تلقائيًا أو تكون قابلة للاختيار
3.3.8 Accessible Authentication (Minimum)	AA	تسجيل الدخول دون حفظ أو نسخ يدوي، ما لم يُسمح باللصق أو بمديري كلمات المرور أو بطريقة أخرى

وأزال WCAG 2.2 أيضًا المعيار 4.1.1 Parsing، الذي لم يعد له أثر عملي في إمكانية الوصول (W3C (يفتح في علامة تبويب جديدة)).

ماذا عن مهلات الجلسة والتخطيط والتكبير؟

مهلات الجلسة (2.2.1، A): نبّه الناس قبل انتهاء الجلسة واسمح لهم بتمديدها بإجراء بسيط، ما لم يكن الحد الزمني ضروريًا أو أطول من 20 ساعة. وحفظ العمل الجاري يجنّب أسوأ النتائج.
إعادة التدفق (1.4.10، AA): يجب أن يعمل المحتوى بعرض 320 بكسل CSS (ما يعادل التكبير إلى 400% على شاشة بعرض 1280 بكسل) دون التمرير في اتجاهين؛ وتُستثنى جداول البيانات والمحتوى المشابه.
تباعد النص (1.4.12، AA): يجب ألا تؤدي زيادة ارتفاع الأسطر والتباعد بين الأحرف إلى اقتطاع النص، وهو ما تفعله الحاويات ثابتة الارتفاع كثيرًا.
الاتجاه (1.3.4، AA): لا تقيّد التطبيق بالوضع العمودي أو الأفقي ما لم يكن ذلك ضروريًا.

ما تقرير ACR، وهل تحتاج إليه؟

يوثّق تقرير مطابقة إمكانية الوصول (Accessibility Conformance Report، ACR) كيفية استيفاء المنتج لكل معيار من معايير إمكانية الوصول: يدعمه، أو يدعمه جزئيًا، أو لا يدعمه، مع ملاحظات. وتُكتب معظم هذه التقارير على نموذج VPAT الذي ينشره مجلس صناعة تكنولوجيا المعلومات (ITI)، وله إصدارات لـ WCAG ولمعايير Section 508 الأمريكية وللمعيار الأوروبي EN 301 549 (ITI (يفتح في علامة تبويب جديدة)).

يجب على الوكالات الفيدرالية الأمريكية شراء تكنولوجيا قابلة للوصول بموجب Section 508 (Section508.gov (يفتح في علامة تبويب جديدة))، وتستند الجهات العامة في الاتحاد الأوروبي إلى EN 301 549، لذا كثيرًا ما يُطلب من منتجات B2B التي تبيع لهؤلاء العملاء تقديم تقرير ACR أثناء إجراءات الشراء. والتقرير الصادق الذي يذكر الثغرات المعروفة أكثر فائدة للمشترين من تقرير يدّعي الدعم الكامل. ويجب أن يستند إلى اختبار المنتج، بما في ذلك الاختبار اليدوي؛ فالفحص الآلي وحده لا يكفي لملئه.

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

كيف يجب أن يختبر فريق SaaS إمكانية الوصول؟

اختبر الأساسيات آليًا. شغّل axe-core أو محركًا مشابهًا في اختبارات end-to-end وعلى الموقع التسويقي، واجعل عمليات البناء تفشل عند ظهور مخالفات جديدة. وتشغّل أداة فحص إمكانية الوصول المجانية لدينا المحرك نفسه على أي صفحة عامة.
اختبر بلوحة المفاتيح. أكمل مسارات العمل الرئيسية، مثل التسجيل وإنشاء سجل وتغيير الإعدادات، باستخدام Tab وShift+Tab وEnter وSpace وEscape ومفاتيح الأسهم فقط.
اختبر بقارئ شاشة. NVDA على Windows وVoiceOver على macOS وiOS مجانيان. تحقّق من أن الأسماء والأدوار والحالات والرسائل تُعلَن.
كبّر الشاشة وغيّر حجم النافذة. افحص تكبير النص إلى 200% ونافذة بعرض 320 بكسل.
أصلح في نظام التصميم. معظم الإخفاقات تأتي من المكونات المشتركة؛ وإصلاح زر أو مربع حوار مرة واحدة يُصلحه في كل مكان.

الأسئلة الشائعة

هل ينطبق WCAG على الأجزاء التي تتطلب تسجيل الدخول في تطبيق الويب؟

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

هل يمكن لأداة تراكب أن تجعل منتج SaaS قابلًا للوصول؟

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

ما مقدار ما تستطيع الأدوات الآلية فحصه من WCAG؟

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

أي إصدار من WCAG يجب أن نستهدف؟

WCAG 2.2 بالمستوى AA هو الإصدار الحالي. ولا تزال قوانين وقواعد شراء كثيرة تشير إلى WCAG 2.1 AA؛ واستيفاء 2.2 AA يستوفي 2.1 AA أيضًا، باستثناء معيار Parsing المحذوف.

هل نحتاج إلى استيفاء المستوى AAA؟

لا يوصي W3C باشتراط AAA لمنتجات كاملة، لأن بعض المحتوى لا يمكنه استيفاء كل معايير AAA. والمستوى AA هو الهدف المعتاد.