أتمتة فحص إمكانية الوصول في الـ CI: امنع كسر موقعك لذوي الإعاقة قبل الدمج

المستوى المطلوب: مبتدئ. المقال مناسب لأي حد بيتعامل مع GitHub وموقع ويب، حتى لو أول مرة يسمع عن "إمكانية الوصول".

أتمتة فحص إمكانية الوصول في الـ CI: امنع كسر موقعك لذوي الإعاقة قبل الدمج

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

المشكلة باختصار

معظم الفرق بتختبر الشكل والوظيفة، وبتنسى إمكانية الوصول (Accessibility). النتيجة: مستخدم بيستعمل قارئ شاشة أو بيتنقّل بالكيبورد يلاقي الموقع مكسور بالنسبة له. حسب تقرير WebAIM Million لسنة 2024، 95.9% من أكبر مليون صفحة رئيسية فيها أخطاء WCAG واضحة، بمتوسط حوالي 57 خطأ لكل صفحة. ودي مش أرقام تجميلية؛ في الولايات المتحدة وحدها اترفعت آلاف القضايا القانونية بسبب مواقع غير متاحة.

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

تخيّل مبنى مدخله سلّم بس. الشخص اللي على كرسي متحرك مش هيقدر يدخل، مش لأنه مش عايز، لكن لأن التصميم نفسه أغلق الباب في وشه. لو حطينا منحدر (ramp) جنب السلّم، الكل بيدخل: اللي ماشي على رجليه، واللي على كرسي، وحتى اللي معاه عربية أطفال.

الموقع بالظبط زي المبنى. إمكانية الوصول هي "المنحدر" الرقمي. علميًا: هي إن الموقع يشتغل صح مع التقنيات المساعدة (assistive tech) زي قارئ الشاشة (screen reader) والتنقّل بالكيبورد، مع الالتزام بمعايير WCAG 2.2 الصادرة عن W3C. أمثلة عملية: كل صورة ليها نص بديل (alt)، كل حقل إدخال ليه تسمية (label)، والتباين اللوني بين النص والخلفية كافٍ عشان ضعاف البصر يقدروا يقروا.

الحل: خلّي pa11y-ci يفحص كل Pull Request

الطريقة الشائعة إن حد يفتح الموقع بإيده مرة كل شوية ويراجع. الطريقة دي بتفشل لأنها بتعتمد على إنك تفتكر، وبتكتشف المشكلة بعد ما توصل المستخدم. البديل: أداة اسمها pa11y-ci بتفحص صفحاتك آليًا مقابل معايير WCAG، وتكسر البناء (build) لو لقت أخطاء. تحت الكابوت بتشغّل متصفح Chrome بلا واجهة، وبتستخدم محرك axe-core لاكتشاف المشاكل.

1. ثبّت الأداة: npm i -D pa11y-ci
2. عرّف الصفحات اللي عايز تفحصها في ملف إعداد اسمه .pa11yci.
3. شغّلها داخل GitHub Actions على كل Pull Request.

{
  "defaults": {
    "standard": "WCAG2AA",
    "timeout": 30000,
    "threshold": 0
  },
  "urls": [
    "http://localhost:3000/",
    "http://localhost:3000/products",
    "http://localhost:3000/checkout"
  ]
}

هنا threshold: 0 معناها: أي خطأ واحد يكفي إن البناء يفشل. دلوقتي شغّل الفحص أوتوماتيك في خط الـ CI:

name: a11y
on: [pull_request]
jobs:
  pa11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build && npm run start &
      - run: npx wait-on http://localhost:3000
      - run: npx pa11y-ci

النتيجة المتوقعة: على كل PR، لو ظهر نص من غير alt أو تباين ضعيف، الـ check بيطلع أحمر و pa11y-ci بيرجّع exit 2، فالدمج بيتوقف تلقائيًا.

مثال واقعي بالأرقام

الافتراض إن عندك متجر إلكتروني بـ 28 ألف زيارة/يوم، وفريق بيدمج 15–20 PR في الأسبوع. مطوّر غيّر لون زرار "أضف للسلة" لرمادي فاتح على خلفية بيضا، فنزل التباين لـ 2.1:1 بدل الحد الأدنى المطلوب 4.5:1. من غير فحص، الزرار فضل شهر كامل صعب القراءة على ضعاف البصر، وبتخسر مبيعات وانت مش عارف السبب. مع pa11y-ci، الـ PR ده كان هيترفض في حوالي 40 ثانية قبل ما يوصل الإنتاج أصلاً.

الـ trade-off وما يجب الانتباه له

ركز في نقطة مهمة: الأدوات الآلية مش بتمسك كل حاجة. pa11y و axe-core بيكتشفوا تقريبًا 30–40% فقط من مشاكل WCAG، يعني الحاجات اللي تتقاس آليًا زي التباين ووجود الـ alt. الباقي — زي إن ترتيب القراءة منطقي، أو إن الوصف البديل مفيد فعلاً مش مجرد كلمة — محتاج مراجعة بشرية بقارئ شاشة. بتكسب: شبكة أمان رخيصة توقف الأخطاء الواضحة تلقائيًا. بتخسر: دقيقة لدقيقتين زيادة في كل CI run، واحتمال "إيجابيات كاذبة" ساعات تحتاج ضبط بسيط.

متى لا تستخدم هذه الطريقة

لو موقعك صفحة هبوط ثابتة صغيرة بتتعدّل مرة كل كام شهر، فحص يدوي مرة واحدة يكفي، وإضافة CI هنا هندسة زيادة. وكمان لو مفيش عندك CI أصلاً، ابدأ بتشغيل npx pa11y http://your-url محليًا الأول، وبعدها انقلها للأتمتة لما يكون عندك خط CI فعلي.

الخطوة التالية

افتح موقعك المحلي وشغّل الأمر ده مرة واحدة: npx pa11y http://localhost:3000. عدّ الأخطاء اللي طلعت. لو الرقم أكبر من صفر، عندك شغل — والخطوة اللي بعدها إنك تحط ملف .pa11yci والـ workflow اللي فوق في الريبو، عشان الرقم ده ميزيدش تاني في أي PR جاي.

المصادر

• WebAIM Million 2024 Report — إحصائيات أخطاء WCAG على مليون صفحة: webaim.org/projects/million
• معايير WCAG 2.2 الرسمية من W3C: w3.org/TR/WCAG22
• توثيق pa11y-ci الرسمي: github.com/pa11y/pa11y-ci
• محرك axe-core من Deque Labs: github.com/dequelabs/axe-core
• الحد الأدنى للتباين اللوني 4.5:1 — WCAG معيار النجاح 1.4.3