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

ما تستطيع القواعد الآلية حسمه — وما يحتاج إلى إنسان

تستطيع القاعدة حسم سؤال حين تكون الإجابة موجودة كاملة في DOM وشجرة إمكانية الوصول والأنماط المحسوبة. ولا تستطيع حسم أسئلة المعنى أو الجودة أو التجربة. وكثير من معايير نجاح WCAG يجمع الأمرين: تستطيع الأداة رؤية وجود السمة alt (جزء من 1.1.1) لكنها لا تعرف هل النص مكافئ للصورة. تعامل بحذر مع أي ادعاء منشور بأن الأدوات تغطي نسبة ثابتة من WCAG؛ المهم أن تعرف أي فحوصك حاسمة وأيها يطرح أسئلة فقط.

• قابل للحسم عادةً: غياب السمة alt؛ حقل نموذج أو زر بلا اسم قابل للوصول؛ غياب lang في <html>؛ أدوار ARIA وحالاتها وخصائصها غير الصالحة أو المكتوبة خطأ؛ غياب الأبناء أو الآباء المطلوبين في ARIA؛ تباين النص العادي على خلفية مصمتة؛ تعطيل التكبير عبر وسم viewport؛ العناوين والروابط الفارغة.
• قابل للحسم جزئياً (الأداة تنبّه والإنسان يؤكد): تباين النص فوق الصور أو التدرّجات؛ هل الصورة زخرفية؛ هل بنية العناوين منطقية؛ حجم الهدف حين قد تنطبق استثناءات التباعد؛ هل تُعلن المنطقة الحيّة في الوقت المناسب.
• يحتاج حكماً بشرياً: جودة النص البديل والتسميات؛ منطقية ترتيب التركيز وترتيب القراءة؛ هل تُوصف الأخطاء بطريقة مفيدة (3.3.3)؛ قابلية تشغيل العناصر المخصّصة بلوحة المفاتيح أبعد من السمات الثابتة؛ دقة الترجمة النصية والوصف الصوتي؛ هل الحركة جوهرية أم لا؛ العبء الإدراكي ووضوح اللغة؛ وهل يمكن إنجاز المهمة كاملة بقارئ شاشة.

قواعد ACT: تعريف مشترك للاختبار

قد تُبلغ أداتان عن نتيجتين مختلفتين للصفحة نفسها لأنهما تفسّران المعيار بشكل مختلف. تعالج قواعد اختبار مطابقة إمكانية الوصول (ACT rules) ذلك: كل قاعدة إجراء اختبار دقيق وموثّق لجزء من متطلب في WCAG أو ARIA، مع قابلية التطبيق والتوقعات والافتراضات وحالات الاختبار. تسردها W3C في صفحة «All ACT Rules»؛ ويطوّرها ACT Rules Community Group وفريق ACT Task Force التابع لمجموعة عمل إرشادات إمكانية الوصول، وهي إرشادية — غير مطلوبة لتحديد المطابقة.

تُوسم القواعد بأنها مقترحة (Proposed) أو معتمدة (Approved)؛ والقاعدة المعتمدة نفّذتها أداة واحدة على الأقل وراجعتها مجموعة عمل W3C المعنية. وتُسرد التنفيذات لكل أداة، وقد تكون آلية أو شبه آلية أو يدوية أو على شكل مدقّق شيفرة (Linter). ومن أمثلة عناوين القواعد «Image has non-empty accessible name» و«HTML page has lang attribute». وبالنسبة إلى المختبِر، قواعد ACT حَكَم مفيد: حين تُعترض نتيجة أداة، قارنها بتوقعات القاعدة وحالات اختبارها.

المحركات والأدوات بوصف محايد

معظم الأدوات محرّك قواعد مع طريقة لتشغيله. ومعرفة المحرك الذي تحت الأداة تفسّر لماذا تتفق أداتان كثيراً.

• axe-core — محرك قواعد إمكانية وصول مفتوح المصدر بلغة JavaScript يعمل داخل سياق المتصفح. يعيد المخالفات (Violations) والنجاحات والنتائج غير المكتملة (عناصر تحتاج مراجعة بشرية) والقواعد غير المنطبقة، ويوسم القواعد بمستوى WCAG. وتغلّفه تكاملات كثيرة.
• تدقيق إمكانية الوصول في Lighthouse — جزء من Lighthouse من Google؛ فحوصه لإمكانية الوصول مبنية على axe-core ويُنتج درجة موزونة. الدرجة 100 تعني أن القواعد المدقّقة نجحت، لا أن الصفحة مطابقة.
• لوحات إمكانية الوصول في أدوات المطوّر بالمتصفح — تعرض شجرة إمكانية الوصول والاسم والدور والحالات المحسوبة ومعلومات التباين للعنصر المحدد. لا غنى عنها للتحقق اليدوي من النتائج الآلية.
• pa11y — أداة سطر أوامر مفتوحة المصدر لتشغيل فحوص إمكانية الوصول الآلية على عناوين URL، وتُستخدم كثيراً في سكربتات CI.
• تكاملات أطر الاختبار — تضيف حزم مجتمعية وتجارية تأكيدات إمكانية الوصول إلى Playwright وCypress وJest وما شابهها؛ ومدقّقات الشيفرة الساكنة (مثلاً لـ JSX) تلتقط بعض المشكلات في الشيفرة المصدرية قبل عرض أي شيء.
• الجوال — توثّق Android الاختبار اليدوي باستخدام TalkBack والفحوص الآلية عبر أطر الاختبار وتطبيق Accessibility Scanner؛ ويوفّر XCTest من Apple دعماً لتدقيق إمكانية الوصول في إصدارات Xcode الحديثة.
• الاختيار — تتيح قائمة أدوات تقييم إمكانية الوصول في W3C (Web Accessibility Evaluation Tools List) تصفية الأدوات حسب الإرشاد والنوع والبيئة؛ وتصرّح W3C بأنها لا تزكّي منتجات بعينها.

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

تشغيل الفحوص في اختبارات الوحدة والمكوّنات وE2E وCI

ضع الفحوص في أدنى مستوى يستطيع رؤية المشكلة، ثم أضف فحوصاً أوسع في المستويات الأعلى. تلتقط اختبارات المكوّنات والوحدة الأسماء المفقودة وARIA غير الصالحة في كل نسخة من مكوّن نظام التصميم قبل وجود أي صفحة بوقت طويل. لاحظ أن محاكيات DOM مثل jsdom لا تحسب التخطيط، وأن وثائق axe-core تذكر أن قاعدة color-contrast لا تعمل مع JSDOM، لذا تحتاج قواعد التباين والتخطيط إلى متصفح حقيقي. والاستعلام عن العناصر بالدور والاسم القابل للوصول (الأولوية التي توصي بها وثائق Testing Library) فحص خفيف لإمكانية الوصول بحد ذاته: إذا لم يجد الاختبار الزر باسمه، فلن يجده قارئ الشاشة أيضاً.

تعمل الاختبارات الشاملة (E2E) في متصفحات حقيقية ويمكنها فحص الصفحات في الحالات التي يراها المستخدمون — بعد تسجيل الدخول، ومع نافذة حوار مفتوحة، ومع ظهور أخطاء التحقق. تصف وثائق Playwright هذا النمط باستخدام حزمة مبنية على axe؛ ولدى Cypress إضافات مجتمعية مكافئة. وفي CI شغّل الفحوص في كل طلب دمج (Pull request) على الصفحات والمكوّنات التي يمسّها التغيير، مع فحص مجدول أوسع للموقع كله.

// Example: Playwright + @axe-core/playwright, scanning a page in an error state
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout form with errors has no WCAG A/AA violations', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByRole('button', { name: 'Pay now' }).click(); // trigger validation
  await expect(page.getByRole('alert')).toBeVisible();

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .exclude('#third-party-chat') // documented exclusion, tracked separately
    .analyze();

  expect(results.violations).toEqual([]);
});

افحص الحالات لا عناوين URL فقط

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

فرز النتائج: الإيجابيات الكاذبة والسلبيات الكاذبة

عامِل كل نتيجة كفرضية حتى تتحقق منها في أدوات المطوّر أو بالتقنيات المساعدة. الإيجابيات الكاذبة (False positives) تحدث — تباين قيس مقابل طبقة خلفية خاطئة، أو عنصر مخفي أبلغت عنه الأداة، أو نمط ARIA مشروع لا يمثّله المحرك. أما السلبيات الكاذبة (False negatives) فأكثر شيوعاً بكثير وغير مرئية: نص بديل بلا معنى مثل «image123»، أو تسمية تسمّي الحقل الخطأ، أو قائمة منسدلة مخصّصة بأدوار صحيحة لكن بلا دعم للوحة المفاتيح — كلها تنجح في القواعد.

جمّع النتائج حسب القاعدة والمكوّن لا حسب الصفحة: اسم مفقود واحد في مكوّن زر مشترك قد ينتج مئات النتائج المتطابقة. اربط كل مجموعة بمعيار نجاح WCAG، وحدّد الخطورة حسب أثرها على مهمة المستخدم (دفع متوقف يتقدّم على أيقونة زخرفية)، وأرسل العناصر الموسومة بغير مكتملة أو تحتاج مراجعة إلى شخص بدلاً من تجاهلها. ولاحظ أن WCAG 2.2 أزالت المعيار 4.1.1 Parsing، فنتائج صحة الترميز مثل المعرّفات المكررة ليست إخفاقات في WCAG 2.2 بحد ذاتها — ما لم تكسر شيئاً آخر، مثل تسمية أو aria-labelledby تشير إلى العنصر الخطأ.

جرّبها: اقتراح خطورة الخطأ بالذكاء الاصطناعي

وضع خط أساس للمشكلات القديمة دون إخفائها

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

{
  "generated": "2026-09-28",
  "known": [
    { "rule": "color-contrast", "target": ".legacy-footer a", "ticket": "A11Y-214" },
    { "rule": "label", "target": "#old-search input", "ticket": "A11Y-219" }
  ]
}

الإبلاغ عن النتائج الآلية بأمانة

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

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

الجمع بين الأتمتة والاختبار اليدوي وعيّنات WCAG-EM

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

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

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

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

المراجع

• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)مدخل W3C إلى تقييم إمكانية الوصول: لماذا يبدأ التقييم مبكراً ويستمر طوال التطوير، وكيف تتكامل الفحوص اليدوية والأدوات ومشاركة المستخدمين.
• All ACT RulesW3C Web Accessibility Initiative (WAI)قواعد اختبار مطابقة إمكانية الوصول (ACT): إجراءات اختبار دقيقة وموثّقة لمتطلبات WCAG وARIA، تجعل نتائج الأدوات والاختبار اليدوي متسقة.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• WCAG Evaluation Methodology (WCAG-EM) 2.0W3C · 2026منهجية W3C لتقييم موقع كامل وفق WCAG: تحديد النطاق، والاستكشاف، واختيار عيّنة ممثِّلة، وتدقيقها، ثم إعداد التقرير.
• Web Accessibility Evaluation Tools ListW3C Web Accessibility Initiative (WAI)قائمة قابلة للتصفية بأدوات تقييم إمكانية الوصول حسب النوع والإرشاد والبيئة — تسردها W3C دون أن تزكّي أياً منها.
• Playwright DocumentationMicrosoft (Playwright)التوثيق الرسمي لـ Playwright، إطار الاختبار الشامل الذي يشغّل Chromium وWebKit وFirefox.
• Cypress DocumentationCypress.ioالتوثيق الرسمي لاختبار الويب الشامل واختبار المكونات في المتصفح باستخدام Cypress.
• About Queries — Testing LibraryTesting Libraryأنواع الاستعلامات وأولويتها — الدور والتسمية قبل النص، ومعرّفات الاختبار أخيراً — لتعثر الاختبارات على العناصر كما يفعل المستخدمون والتقنيات المساعدة.