GitHub تُعلّم قارئات الشاشة قراءة الخطوط الزمنية في issue وPR كقوائم

أعلنت GitHub في سجل التغييرات (changelog) بتاريخ 8 أكتوبر 2026 أن قارئات الشاشة صارت قادرة على التنقل في الخطوط الزمنية لـ issue وpull request كما يُتنقَّل في قائمة. فعندما يتحرك المستخدم في الخط الزمني، يمكن لتقنية المساعدة أن تعلن بنية القائمة وعدد العناصر والموضع الحالي. الإعلان قصير: ففي الجزء المتاح منه ينقطع التعداد عند فاصلة، ولذلك يُستحسن الرجوع إلى المصدر الأصلي للتأكد من القائمة الكاملة للمعلومات التي تُعلَن.

ما الذي تغيّر بالضبط

يُعدّ الخط الزمني في GitHub سطح العمل الرئيسي للمطوّر. ففيه التعليقات وعمليات المراجعة وروابط الـ commits وتغييرات الحالة والإشارات وأحداث الأتمتة. وفي pull request نشط يسهل أن يتضخم هذا الخط إلى عشرات السجلات أو مئاتها. المستخدم المُبصر يقدّر حجمه بنظرة واحدة، من شريط التمرير والفواصل البصرية. أما مستخدم قارئ الشاشة فلا يملك هذه الإمكانية، ويحتاج إلى مؤشرات برمجية.

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

لماذا تهمّ دلالات القائمة

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

والفائدة الرئيسية هنا هي توفير الوقت وتخفيف العبء المعرفي. فمراجعة الشيفرة وتحليل الأخطاء تقومان على قراءة سلاسل طويلة من الأحداث. وأي غموض في التنقل يتضاعف مع كل issue وPR يفتحه المطوّر خلال يوم واحد.

خلاصة ما هو معروف من الإعلان:

• الخطوط الزمنية في issue وpull request مشمولة بالتغيير؛
• يمكن التنقل في الخط الزمني كقائمة؛
• تُعلَن بنية القائمة وعدد العناصر والموضع الحالي؛
• تاريخ النشر: 8 أكتوبر 2026؛
• المصدر: GitHub Changelog.

ما الذي لا يتضمنه الإعلان

لا يقدّم المنشور تفاصيل تقنية. فليس معلومًا أي سمات الترميز استُخدمت، ولا كيف يبدو الدعم في NVDA وJAWS وVoiceOver وTalkBack، ولا في أي المتصفحات يكون السلوك مستقرًا. ولا توجد بيانات عن كيفية إعلان الأحداث المتداخلة والكتل المطوية والأجزاء التي تُحمَّل تدريجيًا من الخط الزمني وسلاسل التعليقات الطويلة مع الردود. وهذه السيناريوهات هي الأكثر تعطيلًا للتنقل، حتى عندما يكون الترميز الأساسي صحيحًا.

ولا توجد كذلك معلومات عمّا إذا كانت قوائم أخرى في المنصة مشمولة بالتغيير: النقاشات والإشعارات وفحوص CI. ويبدو من الصياغة أن الحديث يخص الخطوط الزمنية في issue وPR تحديدًا.

ما الذي ينبغي فحصه عمليًا

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

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

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