إمكانية الوصول التي يتم فحصها مرة واحدة فقط في السنة، في مراجعة يدوية لمرة واحدة، دائمًا ما تتآكل بسرعة - يمكن لأي تحديث صغير للتعليمات البرمجية أن يعطل شيئًا تم إصلاحه بالفعل. الحل: دمج اختبار إمكانية الوصول في عملية التطوير نفسها (CI/CD) كخطوة تلقائية، بحيث يتم اكتشاف المشكلات قبل أن تصل إلى مرحلة الإنتاج. يشرح هذا المقال كيف.
باختصار – ما تتناوله هذه المقالة
لماذا لا يعد الفحص لمرة واحدة كافيًا
لا يمكن لفريق التطوير الذي يقوم بشحن التحديثات كل أسبوع، أو أحيانًا كل يوم، الاعتماد على تدقيق إمكانية الوصول السنوي للحفاظ على الامتثال المستمر. يمكن أن يؤدي إضافة مكون جديد دون وضع إمكانية الوصول في الاعتبار، أو تغيير CSS الذي يقلل التباين عن طريق الخطأ، إلى كسر إمكانية الوصول التي تم إصلاحها بالفعل - ولا يلاحظها أحد حتى يكشف عنها المستخدم أو شكوى. وينطبق المبدأ نفسه على المستندات أيضًا - راجع دليلنا الخاص بذلكتخطيط الأخطاء الشائعة.
ما هي الأدوات الآلية الموجودة في مسار CI/CD التي يمكنها التقاطها
يمكن تشغيل أدوات مثل axe-core، أو Pa11y، أو Lighthouse CI تلقائيًا عند كل طلب سحب أو قبل كل نشر - في غضون ثوانٍ، تتحقق من أشياء مثل: تباين الألوان، وعلامات ARIA غير الصحيحة أو المكررة، والنص البديل المفقود، وتسميات النماذج المفقودة، وترتيب العناوين غير الصحيح. إذا فشل الفحص، فسيتم حظر طلب السحب تلقائيًا من الدمج - تمامًا مثل مراجعة التعليمات البرمجية العادية أو اختبار الوحدة الفاشلة.
💡 نصيحة عملية
ابدأ في "وضع التحذير" (غير محظور) لبضعة أسابيع لمعرفة عدد المشكلات الموجودة بالفعل في قاعدة التعليمات البرمجية، وفقط بعد التنظيف الأولي، قم بتحويل التحقق إلى أداة حظر النشر - وبهذه الطريقة لا "يتعثر" الفريق في مواجهة مئات الأخطاء في اليوم الأول.
حيث لا تزال هناك حاجة للاختبار اليدوي
تمامًا كما هو الحال مع اختبار المستندات، تكتشف الأدوات الآلية في مسار CI/CD مشكلات هيكلية واضحة، لكنها لا تستطيع الحكم على تجربة المستخدم الفعلية: ما إذا كان التنقل عبر لوحة المفاتيح منطقيًا، أو ما إذا كان قارئ الشاشة "يروي قصة متماسكة" على الصفحة، أو ما إذا كان المكون المخصص (مثل الرف الدائري أو المشروط) قابلاً للاستخدام حقًا في الاستخدام الواقعي. ولهذا السبب، من المفيد إقران عمليات الفحص الآلي المستمرة مع التدقيق اليدوي الدوري - ربع سنوي، على سبيل المثال.
كيفية تنفيذها عمليًا
- اختر أداة اختبار تناسب مجموعة التكنولوجيا الخاصة بك (محور المحور لمعظم مشاريع JavaScript، Lighthouse CI للمشروعات القائمة على المتصفح).
- قم بتشغيله كخطوة في مسار CI الخاص بك - عادةً كإجراء GitHub، أو مهمة GitLab CI، أو خطوة مكافئة في أي أداة CI/CD تستخدمها.
- قم بتعيين حد فشل واضح (على سبيل المثال: لا توجد مشكلات على مستوى "حرج" لكل محور أساسي) قبل أن يصبح الفحص مانعًا.
- قم بتغطية ملفات PDF الخاصة بك أيضًا: إذا كانت مؤسستك تقوم بإنشاء المستندات تلقائيًا (الفواتير والتقارير)، ففكر في إضافة المسح الآلي لهذه المستندات أيضًا، كجزء من عملية النشر.
هل تريد إضافة اختبار PDF آلي إلى عمليتك أيضًا؟
تقوم أداتنا بمسح ملفات PDF وتمنح كل مستند درجة إمكانية الوصول - ويمكنك تشغيلها كفحص دوري جنبًا إلى جنب مع عملية CI/CD الخاصة بك.
افحص موقعك مجانا ←بعد المسح، يمكنك أيضًا جعل المستندات التي تم العثور عليها قابلة للوصول مباشرةً ومجانًا عبرAccessiDoc.