كيف قمنا بأتمتة تقارير VPAT الخاصة بإمكانية الوصول في بيئة التكامل المستمر (CI) كيف قمنا بأتمتة تقارير VPAT الخاصة بإمكانية الوصول في بيئة التكامل المستمر (CI)
تصبح عمليات تدقيق إمكانية الوصول قديمة بسرعة؛ فعملية دمج كود واحدة قد تغير كل شيء.
لقد قمنا بحل هذه المشكلة، حيث حولنا تقارير إمكانية الوصول لدينا إلى مخرجات بناء مستمرة (continuous build artifact).
يستخدم خط الأنابيب لدينا ثلاث طبقات للعثور على الأخطاء:
- الفحوصات الساكنة (Static checks): نستخدم
axe-coreلإجراء الاختبارات الأساسية في Storybook. - الاختبارات التفاعلية: نستخدم أدوات مساعدة مخصصة في
Vitestلاختبار قواعد لوحة المفاتيح. - عمليات التدقيق اليدوية: نقوم بتخزين نتائج قارئ الشاشة كملفات
JSON.
يقوم خط أنابيب التكامل المستمر (CI pipeline) لدينا بدمج هذه النتائج.
إذا فشل الاختبار، يفشل طلب السحب (PR). وإذا نجحت جميع الاختبارات، يقوم النظام بإنشاء ملف PDF جديد، ويتم إرفاق ملف PDF هذا مع إصدارك.
لقد جربنا شيئاً واحداً وفشل.
حاولنا استخدام نموذج لغوي كبير (LLM) لاستبدال عمليات التدقيق اليدوية، لكننا توقفنا عن استخدامه على الفور. نتائج الذكاء الاصطناعي متغيرة للغاية، وأنت بحاجة إلى نتائج مستقرة لبوابة التكامل المستمر (CI gate).
اقرأ التحليل التقني الكامل هنا:
المصدر: https://dev.to/yassine_lakhdar_d0226709a/how-we-automated-our-accessibility-vpats-in-ci-46jk
المقال: قام فريق تطوير بأتمتة إنشاء تقارير VPAT (نماذج إمكانية الوصول الطوعية للمنتجات) مباشرة في خط أنابيب التكامل المستمر (CI) الخاص به، محولاً ما كان يُعتبر تقريراً يدوياً دورياً إلى مخرج بناء (build artifact) يُرفق مع كل إصدار. يعمل سير العمل الجديد على إيقاف طلبات السحب (pull requests) التي تتسبب في تراجع إمكانية الوصول، ويقوم بإنشاء مستند امتثال بصيغة PDF تلقائياً عند نجاح عملية البناء، مما يضمن بقاء كل تغيير في الكود ضمن معايير إمكانية الوصول.
لماذا تهم الأتمتة
تصبح عمليات تدقيق إمكانية الوصول غير ذات صلة في اللحظة التي يتم فيها إضافة كود جديد. يمكن لعملية دمج واحدة أن تتسبب في فقدان النص البديل (alt text)، أو ترتيب تركيز غير صحيح، أو مشكلات في قارئ الشاشة مما يبطل تقرير VPAT الصادر مسبقاً. إن الحفاظ على الامتثال يدوياً يعني إعادة تشغيل عمليات التدقيق بعد كل تغيير، وهي عملية مكلفة وعرضة للخطأ وغالباً ما تتأخر عن سرعة التطوير. من خلال دمج الفحوصات في الـ CI، يحصل الفريق على ملاحظات فورية، ويحافظ على حداثة الامتثال، ويتجنب المخاطر القانونية ومخاطر السمعة الناتجة عن إصدار برمجيات غير سهلة الوصول.
نهج الاختبار ثلاثي الطبقات
الفحوصات الساكنة (Static checks) – يقوم خط الأنابيب بتشغيل
axe-core، وهي مكتبة مفتوحة المصدر تقوم بفحص المكونات التي يتم عرضها في Storybook بحثاً عن الانتهاكات المعروفة مثل فقدان المعالم (landmarks) أو عدم كفاية تباين الألوان. تلتقط هذه الاختبارات المشكلات قبل حدوث أي تفاعل.الفحوصات التفاعلية (Interactive checks) – تقوم أدوات
Vitestالمساعدة المخصصة باختبار قواعد التنقل عبر لوحة المفاتيح، والتحقق من أن التركيز (focus) ينتقل بشكل منطقي وأن العناصر التفاعلية تستجيب لأحداث لوحة المفاتيح القياسية. يتجاوز هذا المستوى التحليل الساكن لضمان سهولة الاستخدام في العالم الحقيقي.مخرجات التدقيق اليدوي (Manual audit artifacts) – يتم حفظ نتائج اختبار قارئ الشاشة كملفات
JSON. يسجل المطورون الملاحظات أثناء الاختبار الاستكشافي ويرفقون ملف الـJSONمع الكود. تقوم مهمة الـ CI بدمج هذه المخرجات مع النتائج المؤتمتة، مما ينتج عنه مصدر واحد للحقيقة لتقرير الـ VPAT.
عندما يفشل أي اختبار في الطبقتين الأوليين، يتم حظر طلب السحب (pull request)، مما يمنع التغيير من الوصول إلى بيئة الإنتاج. إذا نجحت جميع الاختبارات، يقوم خط الأنابيب بتجميع البيانات المدمجة في ملف PDF يتم إرفاقه بالإصدار، مما يوفر تقرير VPAT محدثاً دون جهد إضافي.
ما الذي لم ينجح
جرب الفريق استخدام نموذج لغوي كبير (LLM) لإنشاء جزء التدقيق اليدوي تلقائياً. كانت النتائج التي ينتجها الذكاء الاصطناعي متذبذبة للغاية، مما جعل بوابة الـ CI غير موثوقة. الاستقرار أمر ضروري لعملية التحقق الثنائية (نجاح/فشل)، لذا تم التخلي عن التجربة لصالح مخرجات التدقيق اليدوي القائمة على JSON.
ما يجب مراقبته لاحقاً
في الوقت الحالي، يوفر نموذج الـ CI ثلاثي الطبقات مساراً عملياً للحفاظ على حداثة تقارير VPAT، وتقليل العبء اليدوي، وإبقاء إمكانية الوصول في صدارة كل تغيير في الكود.