اختبار إمكانية الوصول

ما اختبار إمكانية الوصول ولماذا يهم

إمكانية الوصول هي مدى قدرة أوسع طيف من الناس بقدراتهم المختلفة على استخدام المنتج. والمعنيون بها ليسوا فئة هامشية: المكفوفون وضعاف البصر الذين يعتمدون على قارئات الشاشة أو التكبير، والصم وضعاف السمع الذين يحتاجون إلى الترجمة النصية والنصوص المكتوبة، وذوو الإعاقات الحركية الذين يستخدمون لوحة المفاتيح أو أجهزة التبديل (Switch) أو التحكم الصوتي، وذوو الإعاقات الإدراكية أو التعلّمية أو العصبية الذين يعتمدون على تخطيط متوقَّع ولغة واضحة. كما أن القيود المؤقتة والظرفية — معصم مكسور، أو شمس ساطعة على شاشة الهاتف، أو غرفة صاخبة — تضع الجميع في الموقف نفسه لبعض الوقت.

بالنسبة لفريق ضمان الجودة، إمكانية الوصول سمة جودة مثل الأمان أو الأداء: يمكن تحديدها في معايير القبول، والتصميم لها، واختبارها، وقياسها، ورصد تراجعها. وهي تفشل بالطرق نفسها التي تفشل بها سمات الجودة الأخرى — متطلبات مفقودة، واكتشاف متأخر، وغياب تغطية الانحدار (Regression) — وتُعالَج بالانضباط نفسه.

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

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

كيف تُنظَّم WCAG 2.2

WCAG 2.2 توصية صادرة عن W3C (والإصدار المشار إليه هنا مؤرخ في 12 ديسمبر 2024)، ومتطلباتها المعيارية (Normative) موزعة على ثلاث طبقات (وتضيف WCAG نفسها في وصفها «لطبقات الإرشاد» طبقةً رابعة غير معيارية وغير ملزمة، هي التقنيات الكافية والاستشارية). أربعة مبادئ تحدد ما يجب أن يكون عليه المحتوى؛ و13 إرشاداً تحتها تحدد الأهداف؛ ومعايير النجاح (Success Criteria) القابلة للاختبار تحت الإرشادات هي ما تختبره فعلاً وتبلّغ عنه. لكل معيار رقم واسم ومستوى — مثل المعيار 2.1.1 Keyboard (المستوى A) أو المعيار 1.4.3 Contrast (Minimum) (المستوى AA). وتنشر W3C أيضاً وثائق «Understanding WCAG 2.2» الإرشادية لكل معيار، ومرجعاً سريعاً (Quick Reference) يسرد التقنيات وحالات الإخفاق الشائعة؛ وهناك يجد المختبِر المقصد والاستثناءات والحالات الحدّية وراء النص المعياري المختصر.

• قابل للإدراك (Perceivable) — يجب تقديم المعلومات بطرق يستطيع المستخدم إدراكها: بدائل نصية (1.1.1 Non-text Content)، وترجمة نصية للوسائط، وبنية متاحة برمجياً لا بصرياً فقط (1.3.1 Info and Relationships)، وتباين كافٍ (1.4.3 Contrast (Minimum))، ومحتوى يُعاد تدفقه عند التكبير (1.4.10 Reflow).
• قابل للتشغيل (Operable) — يجب أن تعمل كل وظيفة بوسيلة الإدخال المتاحة للمستخدم: لوحة المفاتيح (2.1.1 Keyboard و2.1.2 No Keyboard Trap)، ووقت كافٍ، وعدم وجود وميض قد يسبب نوبات، ووسائل تنقّل (2.4.1 Bypass Blocks و2.4.3 Focus Order و2.4.7 Focus Visible)، وبدائل للإيماءات المعقدة (2.5.1 Pointer Gestures).
• قابل للفهم (Understandable) — النص مقروء والواجهة متوقَّعة: لغة الصفحة معلنة (3.1.1 Language of Page)، والتركيز والإدخال لا يسببان تغييراً مفاجئاً في السياق (3.2.1 On Focus و3.2.2 On Input)، والمستخدم يحصل على مساعدة في الأخطاء (3.3.1 Error Identification و3.3.2 Labels or Instructions).
• متين (Robust) — يعمل المحتوى مع وكلاء المستخدم الحاليين والمستقبليين بما فيها التقنيات المساعدة: كل مكوّن واجهة يكشف اسمه ودوره وقيمته (4.1.2 Name, Role, Value)، ويمكن إعلان رسائل الحالة دون نقل التركيز (4.1.3 Status Messages).

المستويات ومعنى المطابقة

المستويات تراكمية. المستوى A هو الحد الأدنى؛ والمستوى AA يشمل كل معايير A وAA وهو الهدف الذي تعتمده معظم المؤسسات والعقود واللوائح؛ والمستوى AAA هو الأعلى، وتنصح WCAG نفسها بعدم اشتراطه سياسةً عامة لمواقع كاملة لأن بعض المحتوى لا يمكنه استيفاء كل معايير AAA. وما لم ينص عقدك على غير ذلك، اختبر مقابل WCAG 2.2 المستوى AA.

أضافت WCAG 2.2 تسعة معايير نجاح إلى WCAG 2.1 — منها 2.4.11 Focus Not Obscured (Minimum) و2.5.7 Dragging Movements و2.5.8 Target Size (Minimum) و3.2.6 Consistent Help و3.3.7 Redundant Entry و3.3.8 Accessible Authentication (Minimum) — وأدرجت المعيار 4.1.1 Parsing على أنه متقادم ومحذوف. فإذا كانت خطة اختبار قديمة أو تقرير أداة ما زال يرفع نتائج 4.1.1، فأبقِ مشكلة الترميز فقط إذا سببت إخفاقاً في معيار آخر مثل 4.1.2.

ادعاء المطابقة (Conformance) بيانٌ عن الصفحات، لا عن شركة أو فريق. وتضع WCAG 2.2 خمسة متطلبات للمطابقة: استيفاء المستوى المختار بالكامل؛ وانطباق المطابقة على صفحات كاملة لا على أجزاء منها؛ وعندما تكون الصفحة خطوة في عملية، يجب أن تطابق كل صفحات العملية الكاملة؛ والاعتماد فقط على طرق استخدام للتقنيات مدعومة من ناحية إمكانية الوصول؛ وألا تتداخل التقنيات غير المعتمد عليها مع بقية الصفحة (عدم التداخل).

اثنان من هذه المتطلبات يشكّلان تصميم الاختبار مباشرة. «الصفحات الكاملة» تعني أن نموذجاً مطابقاً في صفحة فيها شريط ملفات تعريف ارتباط غير قابل للوصول لا يجعل الصفحة مطابقة. و«العمليات الكاملة» تعني أن إتمام الشراء أو التسجيل أو طلب التمويل لا ينجح إلا إذا نجحت كل خطواته — بما فيها صفحة الدفع وشاشة رمز التحقق (OTP) وخطوة التأكيد. فعند تحديد نطاق التقييم، اسرد العمليات لا عناوين URL فقط. والمطابقة لقطة في لحظة: الصفحة المطابقة في مارس قد تفشل في أبريل بعد إطلاق منتقي تاريخ جديد، ولهذا تحتاج إمكانية الوصول إلى تغطية انحدار كأي سمة جودة أخرى.

المجالات العملية الخمسة

تُنظَّم WCAG حسب المبدأ، لكن المختبِرين يعملون حسب التقنية. خمسة مجالات فرعية تغطي معظم العمل اليومي، ولكل منها دليله الخاص ضمن هذا الموضوع.

• إمكانية الوصول بلوحة المفاتيح — كل وظيفة قابلة للوصول والتشغيل بـ Tab وShift+Tab وEnter وSpace والأسهم وEscape؛ وترتيب تركيز منطقي؛ ومؤشر تركيز مرئي لا يختفي خلف الترويسات الثابتة؛ ولا فخاخ لوحة مفاتيح؛ وروابط تخطٍّ؛ ونوافذ حوار مشروطة تدير التركيز. وهو الفحص الأسرع ذو القيمة العالية، والأساس الذي يبني عليه مستخدمو قارئات الشاشة وأجهزة التبديل والتحكم الصوتي.
• اختبار قارئات الشاشة — هل تصل دلالات الصفحة إلى التقنيات المساعدة: الأسماء القابلة للوصول، والأدوار والحالات، والعناوين والمعالم، ونصوص الروابط ذات المعنى، والاستخدام الصحيح لـ ARIA، وإعلان رسائل الحالة، مع التحقق بثنائيات حقيقية من قارئ شاشة ومتصفح مثل NVDA أو JAWS على Windows، وVoiceOver على macOS وiOS، وTalkBack على Android.
• النماذج القابلة للوصول — تسميات وتعليمات مرئية، وتجميع الحقول المترابطة، والإشارة إلى الحقول الإلزامية، وتحديد الأخطاء واقتراح تصحيحها، ومنع الأخطاء في الإرسالات القانونية والمالية، والإكمال التلقائي لغرض الإدخال، والمصادقة القابلة للوصول. والنماذج هي الموضع الذي تمنع فيه إخفاقات إمكانية الوصول إتمام المعاملة كلياً في أغلب الأحيان.
• إمكانية الوصول البصرية — تباين النص والعناصر غير النصية، واستخدام اللون، وتغيير الحجم وإعادة التدفق، وتباعد النص، والاتجاه (Orientation)، وحجم الهدف، والمحتوى الذي يظهر عند التمرير أو التركيز، والحركة والوميض، والبدائل النصية للصور.
• الاختبار الآلي لإمكانية الوصول — محركات قواعد مثل axe-core وعمليات تدقيق مثل Lighthouse، تعمل في المتصفح وفي اختبارات المكوّنات والاختبارات الشاملة وفي CI لالتقاط الإخفاقات القابلة للكشف آلياً مع كل تغيير، مع ترك الأحكام التقديرية للبشر.

الاختبار اليدوي والآلي: ما الذي يكتشفه كل منهما

أدوات الفحص الآلي قيّمة ومحدودة في آن. فهي تكشف بموثوقية الحالات التي يمكن الحكم عليها من الشيفرة والأنماط المحسوبة: صورة بلا سمة alt، وعنصر تحكم في نموذج بلا اسم قابل للوصول، وسمة ARIA غير مسموحة على دور معيّن، وإشارة إلى معرّف id غير موجود، ونص عادي تحت حد التباين. لكنها لا تستطيع الحكم على ما إذا كان نص alt يصف الصورة، أو ما إذا كان ترتيب التركيز منطقياً، أو ما إذا كان العنوان يصف قسمه، أو ما إذا كانت رسالة الخطأ مفيدة، أو ما إذا كان عنصر واجهة مخصص يمكن تشغيله فعلاً بقارئ الشاشة. وتنص نظرة W3C العامة على التقييم على أن الأدوات وحدها لا تستطيع تحديد ما إذا كان الموقع قابلاً للوصول؛ ومقدار ما تلتقطه الأداة من مشكلات المنتج يعتمد على المنتج والأداة، وهو دائماً جزء من الصورة فقط.

تصف قواعد اختبار المطابقة لإمكانية الوصول (ACT Rules) الصادرة عن W3C، بصيغة محايدة تجاه الأدوات، كيفية اختبار جوانب محددة من WCAG وARIA. بعض القواعد يمكن أتمتتها بالكامل وبعضها يحتاج إلى حكم بشري؛ وعند مقارنة الأدوات، فإن السؤال عن قواعد ACT التي تنفذها كل أداة أنفع من مقارنة الأرقام الدعائية. وتقسيم عملي للجهد يبدو هكذا:

• آلي، مع كل تغيير — فحوصات بمحرك قواعد للصفحات والمكوّنات الأساسية، ضمن CI.
• يدوي، لكل قصة — جولة بلوحة المفاتيح، وجولة قصيرة بقارئ الشاشة، والتكبير وإعادة التدفق، وتباين كل جديد في الواجهة المعدّلة.
• تقييم خبير، لكل إصدار أو كل ربع سنة — تقييم WCAG منظّم لعينة ممثِّلة (انظر WCAG-EM أدناه).
• اختبار مع مستخدمين من ذوي الإعاقة، دورياً — الطريقة الوحيدة لمعرفة ما إذا كان المنتج قابلاً للاستخدام عملياً لا مطابقاً على الورق فقط.

جرّبها: فاحص إمكانية الوصول في HTML

تقييم المنتج بمنهجية WCAG-EM

تصف منهجية تقييم WCAG (WCAG-EM) 2.0، التي نشرتها W3C بوصفها ملاحظة مجموعة (Group Note) في يوليو 2026، كيفية تقييم مدى مطابقة منتج رقمي لـ WCAG 2. وهي إجراء لا أداة، وتصلح لموقع أو تطبيق ويب أو مجموعة شاشات تطبيق. وتنطبق خطواتها الخمس بسلاسة على خطة الاختبار:

• 1. حدّد نطاق التقييم — المنتج وأجزاؤه، وهدف المطابقة (عادةً WCAG 2.2 المستوى AA)، وخط الأساس لدعم إمكانية الوصول (المتصفحات والتقنيات المساعدة التي يُتوقع أن يعمل معها المنتج)، وأي متطلبات إضافية.
• 2. استكشف المنتج — حدّد الواجهات الشائعة، والوظائف الأساسية، وتنوع أنواع الصفحات أو الشاشات، والتقنيات المعتمد عليها.
• 3. اختر عينة ممثِّلة — عينة منظّمة تغطي ما وجدته الخطوة 2، وبعض العينات المختارة عشوائياً، وكل عملية كاملة.
• 4. قيّم العينة — افحص كل عينة وكل عملية كاملة مقابل معايير الهدف، ثم قارن نتائج العينة المنظّمة بالعشوائية؛ فإذا كشفت العينات العشوائية أنواعاً جديدة من الإخفاق، فالعينة المنظّمة فاتها شيء.
• 5. أبلغ عن النتائج — وثّق نتيجة كل خطوة؛ واختيارياً أضف تفاصيل التقييم، وبيان تقييم، ودرجة مجمّعة، وتقارير قابلة للقراءة آلياً.

إمكانية الوصول داخل السبرنت

تكون إمكانية الوصول أرخص ما تكون عندما تصبح خاصية لكل قصة مستخدم لا مرحلة مستقلة. وبالنسبة لفريق يعمل بالسبرنت، تتقلص WCAG-EM بشكل طبيعي: النطاق هو الإصدار، والعينة هي الشاشات المعدّلة مع العمليات التي تمسّها، والتقرير هو قائمة المعايير المخفقة مع العيوب المرتبطة بها. تدفق عملي:

• التهيئة (Refinement) — أضف معايير قبول لإمكانية الوصول إلى كل قصة فيها واجهة: التشغيل بلوحة المفاتيح، وأسماء عناصر التحكم، وإعلان الأخطاء والحالة، وتباين الألوان الجديدة. واذكر أرقام معايير النجاح.
• مراجعة التصميم — افحص التباين وأنماط التركيز وأحجام الأهداف وترتيب القراءة والتركيز، وأن لا شيء يُنقل باللون وحده، قبل كتابة الشيفرة.
• التطوير — فضّل عناصر HTML الأصلية، واتبع أنماط ARIA Authoring Practices للعناصر المخصصة، وشغّل أداة فحص آلي محلياً وفي اختبارات المكوّنات.
• اختبار القصة — يجري المختبِر جولة لوحة المفاتيح، وجولة دخان (Smoke) بقارئ الشاشة على ثنائية واحدة متفق عليها، والتكبير إلى 200% وإعادة التدفق عند 400%، ويراجع النتائج الآلية.
• الانحدار — احتفظ بمجموعة انحدار قصيرة لإمكانية الوصول للرحلات الحرجة (تسجيل الدخول، والبحث، وإتمام الشراء، والنماذج الأساسية)، وأعد تشغيلها مع كل إصدار، وبدّل ثنائيات قارئ الشاشة مع الوقت.
• تعريف الإنجاز (Definition of Done) — لا تُعدّ القصة منجزة ما دامت فيها إخفاقات مفتوحة من المستوى A أو AA، ما لم يقبلها الفريق صراحةً ويسجّلها في تذاكر ويجدولها.
• بنود قائمة تعريف الإنجاز أدناه (وهي بالإنجليزية لتُنسخ كما هي) — كل وظيفة جديدة تعمل بلوحة المفاتيح وحدها (Tab وShift+Tab وEnter وSpace والأسهم وEsc)؛ ترتيب التركيز يتبع ترتيب القراءة والتركيز مرئي على كل عنصر قابل للتركيز؛ لا يُحجب العنصر المركَّز بالكامل خلف ترويسة أو تذييل أو شريط ثابت؛ لكل عنصر تحكم اسم قابل للوصول يتضمن تسميته المرئية؛ العناوين والمعالم تعكس البنية المرئية؛ الأخطاء والإشعارات وحالات التحميل تُعلَن (status أو alert)؛ تباين النص 4.5:1 على الأقل (والنص الكبير 3:1 على الأقل)، ومكوّنات الواجهة والرسوم 3:1 على الأقل؛ الواجهة قابلة للاستخدام بحجم نص 200% وتعيد التدفق عند تكبير 400% دون تمرير أفقي؛ lang وdir صحيحتان في كل لغة (العربية: ⁦lang="ar" dir="rtl"⁩)؛ لا مخالفات جديدة في الفحص الآلي؛ وجولة دخان بقارئ الشاشة على الثنائية المتفق عليها (مثل NVDA مع Firefox).

Accessibility definition of done (story with UI)

[ ] Every new function works with keyboard only (Tab, Shift+Tab, Enter, Space, arrows, Esc)
[ ] Focus order follows reading order; focus is visible on every focusable element
[ ] Focused element is never fully hidden by a sticky header, footer or banner
[ ] Every control has an accessible name that contains its visible label
[ ] Headings and landmarks reflect the visual structure
[ ] Errors, toasts and loading states are announced (status / alert)
[ ] Text contrast >= 4.5:1 (large text >= 3:1); UI components and graphics >= 3:1
[ ] Usable at 200% text size; reflows at 400% zoom without horizontal scrolling
[ ] lang and dir correct in every locale (Arabic: lang="ar" dir="rtl")
[ ] Automated scan: no new violations
[ ] Screen reader smoke pass on the agreed pairing (for example NVDA + Firefox)

جرّبها: مولّد قوائم تحقق QA بالذكاء الاصطناعي

عيوب إمكانية الوصول الشائعة وكيف تُبلَّغ

تتكرر الإخفاقات نفسها عبر المنتجات. هذه صياغتها كعناوين تقارير أخطاء، مع المعيار الذي يخفق فيه كل منها:

• «قائمة الدولة المنسدلة لا يمكن فتحها أو تغيير قيمتها بلوحة المفاتيح» — 2.1.1 Keyboard.
• «يعود التركيز إلى أعلى الصفحة بعد إغلاق نافذة تعديل العنوان» — 2.4.3 Focus Order.
• «لا يوجد مؤشر تركيز مرئي على الأزرار الرئيسية (أُزيل outline في CSS العام)» — 2.4.7 Focus Visible.
• «زر الحذف ذو الأيقونة فقط يُعلَن كـ button دون اسم» — 4.1.2 Name, Role, Value.
• «عناوين الأقسام فقرات منسّقة؛ وقائمة العناوين في قارئ الشاشة فارغة» — 1.3.1 Info and Relationships.
• «إشعار إضافة المنتج إلى السلة لا تعلنه قارئات الشاشة» — 4.1.3 Status Messages.
• «نص المساعدة الرمادي على الأبيض نسبة تباينه 2.9:1» — 1.4.3 Contrast (Minimum).
• «الصفحة العربية تعلن lang=en؛ فيقرأ قارئ الشاشة النص العربي بصوت إنجليزي» — 3.1.1 Language of Page.

جرّبها: مولّد عناوين الأخطاء بالذكاء الاصطناعي جرّبها: مولّد وصف الأخطاء بالذكاء الاصطناعي

الإبلاغ عن العيوب والأتمتة في CI

يحتاج تقرير خطأ إمكانية الوصول إلى كل ما يحتاجه أي تقرير خطأ (ويغطي دليل كتابة تقارير الأخطاء البنية والفرق بين الخطورة والأولوية)، إضافة إلى أربعة أمور: معيار النجاح ومستواه؛ والتقنية المساعدة والمتصفح ونظام التشغيل مع إصداراتها؛ وتسلسل المفاتيح الدقيق أو الإعلان المسموع بنصه؛ والأثر على المستخدم. فعبارة «مستخدمو قارئات الشاشة لا يستطيعون إتمام الشراء» هي التي تحدد الأولوية. وعادةً ما يُعامَل إخفاق من المستوى A يمنع رحلة أساسية على أنه مانع للإصدار.

تنتمي الفحوصات الآلية إلى خط التسليم للسبب نفسه الذي تنتمي إليه اختبارات الوحدات: فهي توقف حالات الانحدار المعروفة بتكلفة منخفضة. ومن الأنماط الشائعة تشغيل محرك قواعد داخل الاختبارات الشاملة القائمة (مثل axe-core مع Playwright أو Cypress أو Selenium)، وفحص قائمة عناوين URL بعد النشر في بيئة اختبار، وتشغيل تدقيقات Lighthouse لإمكانية الوصول على الصفحات الأساسية. اجعل البوابة على ما تستطيع الأدوات الحكم عليه: أفشل البناء عند وجود مخالفات جديدة، واحتفظ بخط أساس للمشكلات المعروفة مع تذاكرها حتى لا يبقى الخط أحمر إلى الأبد، وراجع مجموعة القواعد عند تحديث الأداة. ولا تصف خط تسليم أخضر بأنه «قابل للوصول» — فهو يعني فقط أن القواعد الآلية لم تجد شيئاً. ويغطي دليل الاختبار الآلي لإمكانية الوصول دمج الأدوات واختيار القواعد وفرز النتائج بالتفصيل.

إمكانية الوصول في المنتجات متعددة اللغات ومن اليمين إلى اليسار

المنتجات المستخدمة بالعربية والإنجليزية — وهي شائعة في المملكة العربية السعودية ودول الخليج — تحتاج إلى فحوصات تفوتها خطط الاختبار أحادية اللغة. فقارئات الشاشة تعتمد على اللغة التي تعلنها الصفحة لتحميل قواعد النطق الصحيحة، لذا يجب أن تطابق سمة lang على العنصر html لغة الصفحة (3.1.1 Language of Page)، وأن تحمل المقاطع المكتوبة بلغة أخرى — كاسم منتج إنجليزي داخل نص عربي — سمة lang خاصة بها (3.1.2 Language of Parts). وقيمة lang الخاطئة تنتج نطقاً يصعب فهمه جداً حتى لو نجحت كل الفحوصات الأخرى.

الاتجاه هو الشاغل الثاني. تحدد السمة dir (أي dir="rtl" على العنصر html في الصفحات العربية) الاتجاه الأساسي؛ فينعكس التخطيط، ويجب أن يظل ترتيب التركيز تابعاً لترتيب القراءة، وهو في العربية من اليمين إلى اليسار. تحقّق من أن Tab يتنقل عبر التخطيط المعكوس بترتيب منطقي، وأن مفاتيح الأسهم في المنزلقات وعروض الشرائح وقوائم التبويب تتصرف بما يتسق مع التخطيط المعكوس، وأن الأيقونات الدالة على الاتجاه معكوسة حيث يجب، وأن السلاسل المختلطة بين العربية واللاتينية — أرقام الطلبات وعناوين البريد وأرقام الهواتف — تُعرض وتُقرأ بالترتيب الصحيح. ويغطي دليل اختبار RTL النص ثنائي الاتجاه وعكس التخطيط بالتفصيل.

جرّبها: مولّد بيانات اختبار متعددة اللغات جرّبها: مولّد بيانات الاختبار العربية

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

المراجع

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)الشرح التوضيحي لكل إرشاد ومعيار نجاح في WCAG 2.2: الغرض، ومن يستفيد، والأمثلة والتقنيات (غير إلزامي).
• WCAG Evaluation Methodology (WCAG-EM) 2.0W3C · 2026منهجية W3C لتقييم موقع كامل وفق WCAG: تحديد النطاق، والاستكشاف، واختيار عيّنة ممثِّلة، وتدقيقها، ثم إعداد التقرير.
• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)مدخل W3C إلى تقييم إمكانية الوصول: لماذا يبدأ التقييم مبكراً ويستمر طوال التطوير، وكيف تتكامل الفحوص اليدوية والأدوات ومشاركة المستخدمين.
• All ACT RulesW3C Web Accessibility Initiative (WAI)قواعد اختبار مطابقة إمكانية الوصول (ACT): إجراءات اختبار دقيقة وموثّقة لمتطلبات WCAG وARIA، تجعل نتائج الأدوات والاختبار اليدوي متسقة.
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)قائمة قابلة للتصفية بكل معايير نجاح WCAG 2.2 مع التقنيات الكافية وحالات الإخفاق الشائعة.
• EN 301 549 V4.1.1 (2026-09) — Accessibility requirements for ICT products and servicesETSI / CEN / CENELEC · 2026المعيار الأوروبي الموحّد لإمكانية الوصول في تقنية المعلومات والاتصالات، يبني على WCAG لمحتوى الويب ويضيف متطلبات للبرمجيات والمستندات والأجهزة.
• Structural markup and right-to-left text in HTMLW3Cكيف يُضبط الاتجاه الأساسي بسمة dir على عنصر html والعناصر البنيوية، ولماذا لا يُعتمد على CSS وحده لذلك.