مطوّر كفيف يعلّم وكيل ذكاء اصطناعي ألا يخترع أخطاء إمكانية وصول في الشيفرة

تخيّل أن وكيل ذكاء اصطناعي يفحص نموذجًا ويعلن بثقة أن الحقل يفتقر إلى aria-describedby. تفتح الشيفرة فتجد أن مكوّن النموذج في المكتبة ينشئ الربط بالتلميح منذ زمن. مثل هذه النتائج الخاطئة تستنزف الثقة بالتدقيق أسرع مما تفعل الأخطاء الفائتة. هذا ما واجهه مبرمج كفيف يستخدم قارئ شاشة ويبني Accessibility Auditor Skill، وهو مجموعة تعليمات لوكيل يفحص إمكانية الوصول من الشيفرة المصدرية وعلى المواقع الحية.

النظر إلى التنفيذ لا إلى موضع الاستدعاء

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

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

دروس من طلبات PR محددة

في طلب PR الخاص بـ RTL حلّل الوكيل رسائل المصادقة والتحميل. الدوران status وalert يحددان أصلًا نمط النطق، لذا قد يقاطع assertive أو role="alert" الزائد كلام قارئ الشاشة. وبالنسبة إلى مؤشر دوّار بجوار نص، القاعدة هي: إذا كانت الرسالة موجودة في النص، فلا يُعطى المؤشر الزخرفي الاسم المتاح نفسه، بل يُخفى عبر aria-hidden. أُغلق هذا الطلب دون دمج، لذا يعرض المقتطف التغيير المقترح فقط؛ أما النطق الفعلي فيجب فحصه في تطبيق يعمل.

في Vets-Who-Code أُضيفت الخاصية feedbackId إلى الواجهة المشتركة بشكل واسع جدًا، فأصبحت متاحة لمكوّنات لا تعالجها. ومن هنا القاعدة: عند إضافة خاصية، يجب معرفة من يدعمها وهل ستصل إلى HTML كسمة زائدة. وتُفحص المعرّفات في حالتين: المولَّد والممرَّر من الخارج. وإلا فسيعمل المثال القياسي بينما يفقد النموذج الذي له ID خاص ارتباطه بالخطأ.

في suitenumerique/docs اعتمد الإصلاح على عنصر داخلي في Cunningham Select. قد تغيّر المكتبة ترميزها فيتعطل المحدِّد. لذلك يفضّل الـ skill الآن واجهة API العامة، وعند التعامل مع العناصر الداخلية يشترط اختبار انحدار على قيم aria-hidden وtabindex النهائية. في تلك الدورة أُضيفت هذه الفحوص إلى اختبار Playwright، لكن لم يُنفَّذ تشغيل e2e كامل.

نتيجة مقبولة وحدود صريحة

طلب PR الوحيد المقبول المذكور هو Nextcloud iOS رقم 4111، الذي قُبل في 28 مايو 2026. لم يكن لصفوف المجلدات في نافذة اختيار مكان الحفظ اسم متاح: كان VoiceOver يركّز على العنصر دون أن ينطق اسم المجلد. جمع الوكيل الاسم من العنوان والمعلومات المعروضة أصلًا في الخلية، وتجاهل القيم الفارغة، وعيّن للصف سمة الزر. فُحصت الشيفرة المصدرية فقط: لم يُجرَ بناء iOS ولا اختبار مع VoiceOver لعدم توفر Xcode في البيئة.

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

ما يمكن الاستفادة منه

إذا كنت تبني وكلاء لمراجعة الشيفرة، فلا تكتفِ بملف واحد. اجعل الوكيل يتتبع السلسلة من الاستدعاء إلى المكتبة ويفحص مستهلكي المكوّنات المشتركة. دوّن الدروس المستفادة من طلبات PR الحقيقية في التعليمات مباشرة كي لا تشرحها من جديد في كل مشروع. واطلب من الوكيل أن يسمّي نوع الفحص بصدق: قراءة الشيفرة لا تغني عن اختبار بقارئ شاشة على جهاز حقيقي.