لماذا لا يعني اجتياز فحص النص البديل أن الصور متاحة فعلاً؟

اجتياز الصورة لفحص آلي لا يعني بالضرورة أن النص البديل المرتبط بها مفيد للمستخدمين الذين يعتمدون على قارئات الشاشة. هذه هي الخلاصة الأساسية التي تعرضها GitHub في مادة هندسية كتبها Taarik Ashenafi وKeenan Zhou بتاريخ 24 أغسطس 2026، بعد تطوير إضافة للنصوص البديلة ضمن GitHub Accessibility Scanner.

تستند المادة إلى تقرير WebAIM Million لعام 2026، الذي وجد أن النص البديل مفقود في 16.2% من الصور الموجودة على الصفحات الرئيسية للمليون موقع الأكثر شعبية على الويب. ومن الصور التي تحتوي على نص بديل، قدمت 10.8% أوصافاً غير مفيدة، مثل image أو اسم الملف الخام أو وصف مكرر من صورة مجاورة. المشكلة أن معظم أدوات الفحص الآلي تتحقق من وجود اسم متاح للصورة، لا من جودة الوصف أو ملاءمته للسياق.

الفصل بين ما يمكن إثباته وما يحتاج إلى حكم

ترى GitHub أن وجود سمة alt حقيقة موضوعية يمكن للأداة إثباتها، بينما ملاءمة النص لوصف الصورة غالباً مسألة تعتمد على السياق. لذلك اختارت الإضافة خمس قواعد حتمية تعمل افتراضياً من دون بيانات اعتماد لنماذج الذكاء الاصطناعي أو اتصالات شبكية.

• غياب السمة أو احتواؤها على مسافات فقط، مع التمييز بين ذلك وبين alt="" الذي يشير عادةً إلى أن الصورة زخرفية.
• استخدام اسم ملف مثل hero.png أو IMG_2847.jpg.
• ترك قيمة مؤقتة مثل TODO أو tbd.
• استخدام كلمة عامة واحدة تصف نوع الوسيط، مثل image أو logo أو chart.
• تكرار النص نفسه عبر صور متجاورة.

تعتمد قاعدة الوصف الغامض على قائمة منتقاة ومطابقة حرفية، بدلاً من تخمينات أكثر تعقيداً. وبذلك تُبلغ عن alt="image"، لكنها لا تعتبر الوصف الأطول، مثل «صورة لشاشة تسجيل الدخول مع إبراز زر الدخول الموحد»، غامضاً تلقائياً. وتوضح GitHub أن تفويت بعض الحالات أفضل من إنتاج إنذارات خاطئة تدفع المطورين إلى تعطيل الأداة.

التجاور البصري أهم من ترتيب HTML

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

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

النموذج البصري اقتراح لا حكم نهائي

تضيف القاعدة الاختيارية سياق الصفحة إلى النص البديل والصورة، بما في ذلك أقرب عنوان، وعنوان الصفحة، وأي figcaption، وما إذا كانت الصورة داخل رابط أو زر، وما يصل إلى 600 حرف من النص المحيط. ويكتسب وجود الرابط أهمية خاصة عندما تكون الصورة المحتوى الوحيد للرابط، لأن النص البديل يصبح حينها الاسم المتاح الذي يصف وجهة الرابط، لا مجرد وصف بصري.

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

الخصوصية والتكلفة والحدود العملية

القاعدة المعتمدة على النموذج متوقفة افتراضياً، وتتطلب تفعيلها صراحةً وإتاحة رمز وصول إلى GitHub Models. كما تُزال معاملات الاستعلام وأجزاء التجزئة من عناوين الصور والروابط، وتُستبدل قيمتا src وsrcset بـ (omitted) قبل إرسال ترميز HTML إلى النموذج. مع ذلك، تظل عناوين الصفحة وHTML الأصلي جزءاً من تقارير الماسح المعتادة، لأن تحديد موضع المشكلة ضروري لإصلاحها. وإذا جرى إعداد بيانات اعتماد Azure AI Vision، فقد تُرسل بيانات الصورة الثنائية أيضاً إلى خدمة ثانية لتنفيذ معالجة OCR اختيارية.

كل استدعاء للنموذج قد يحدث مرة لكل صورة في كل عملية فحص، ما يجعل المواقع الغنية بالصور أكثر كلفة. لذلك تشير التجربة إلى ملاءمة تشغيل الفحص وفق جدول زمني بدلاً من إضافته إلى كل عملية commit.

ولا تغطي الإضافة حالياً سوى عناصر HTML من نوع img، كما أن الصور المحمية بالمصادقة قد تفشل في التحميل عند إعادة جلبها خارج جلسة المتصفح. كذلك قد تمر أخطاء في aria-label لأن الفحص يقرأ سمة alt نفسها لا الاسم المتاح المحسوب. وتبقى النتائج المقترحة مسودات تحتاج إلى مراجعة بشرية، وقد تتكرر بعض الإنذارات مع فحوصات الماسح المدمجة.

ما الذي يتغير عملياً؟

تقدم تجربة GitHub قاعدة قابلة للتعميم عند بناء أدوات الفحص: اجعل الاختبارات التي تثبت خطأً واضحاً رخيصة ومتوقعة ومفعلة افتراضياً، أما الاختبارات التي تشتبه في مشكلة سياقية فاجعلها اختيارية وقدمها كاقتراح لا كحكم. الأهم أن تقييم تجربة المستخدم لا يمكن اختزاله في محتوى DOM أو في رأي نموذج بصري. الأتمتة هنا توسع نطاق المراجعة، لكنها لا تستبدل اختبار الموقع مع أشخاص يستخدمون تقنيات مساعدة.