إمكانية الوصول: GitHub يحوّل الملاحظات إلى شمولية باستخدام الذكاء الاصطناعي المستمر

إحداث ثورة في إمكانية الوصول: نهج GitHub للذكاء الاصطناعي المستمر

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

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

الذكاء الاصطناعي المستمر: نظام حي للشمولية

'الذكاء الاصطناعي المستمر لإمكانية الوصول' من GitHub هو أكثر من مجرد أداة؛ إنه منهجية حية تدمج الأتمتة، والذكاء الاصطناعي، والخبرة البشرية لدمج الشمولية مباشرة في نسيج تطوير البرمجيات. تدعم هذه الفلسفة التزام GitHub بتعهد يوم التوعية العالمي بإمكانية الوصول (GAAD) لعام 2025، بهدف تعزيز إمكانية الوصول عبر منظومة المصادر المفتوحة من خلال توجيه وترجمة ملاحظات المستخدمين بفعالية إلى تحسينات مهمة للمنصة.

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

قبل الخوض في الحلول التكنولوجية، تبنت GitHub نهج تصميم يركز على الإنسان، حيث حددت الشخصيات الرئيسية التي يحتاج النظام إلى خدمتها:

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

سمح هذا الفهم الأساسي لـ GitHub بتصميم نظام يتعامل مع الملاحظات كبيانات تتدفق عبر مسار عمل محدد جيدًا، وقادر على التطور مع احتياجاتهم.

أتمتة مسار عمل ملاحظات إمكانية الوصول

قامت GitHub ببناء بنيتها الجديدة حول نمط يعتمد على الأحداث، حيث تؤدي كل خطوة إلى تشغيل GitHub Action لتنسيق الإجراءات اللاحقة، مما يضمن معالجة متسقة للملاحظات بغض النظر عن مصدرها. بينما تم بناء مثل هذا النظام يدويًا في منتصف عام 2024، يمكن الآن تطويره بشكل أسرع بكثير باستخدام أدوات مثل Agentic Workflows، التي تسمح بإنشاء GitHub Actions عبر اللغة الطبيعية.

يستجيب سير العمل للأحداث الرئيسية: يؤدي إنشاء المشكلة إلى بدء تحليل GitHub Copilot عبر GitHub Models API، وتؤدي تغييرات الحالة إلى عمليات تسليم للفريق، ويؤدي حل المشكلة إلى متابعة مع المقدم الأصلي. تغطي الأتمتة المسار الشائع، ولكن يمكن للبشر تشغيل أي إجراء يدويًا أو إعادة تشغيله، مع الحفاظ على الإشراف والمرونة.

سير عمل الملاحظات المكون من سبع خطوات:

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

يضمن هذا التدفق المستمر الرؤية، والهيكل، وقابلية التنفيذ في كل مرحلة من مراحل دورة حياة الملاحظات.

الفرز الذكي لإمكانية الوصول بواسطة GitHub Copilot

في صميم هذا النظام الآلي يقع التحليل الذكي لـ GitHub Copilot. عند إنشاء مشكلة تتبع، يستدعي سير عمل GitHub Action برمجيًا GitHub Models API لتحليل التقرير. اتخذت GitHub خيارًا استراتيجيًا لاستخدام المطالبات المخزنة (التعليمات المخصصة) بدلاً من الضبط الدقيق للنموذج. يسمح هذا لأي عضو في الفريق بتحديث سلوك الذكاء الاصطناعي عبر طلب سحب بسيط، مما يلغي الحاجة إلى مسارات إعادة تدريب معقدة أو معرفة متخصصة بالتعلم الآلي. عندما تتطور معايير إمكانية الوصول، يقوم الفريق بتحديث ملفات markdown والتعليمات، ويتكيف سلوك الذكاء الاصطناعي مع التشغيل التالي.

يتم تكوين GitHub Copilot بتعليمات مخصصة طورها خبراء الموضوع في مجال إمكانية الوصول. تخدم هذه التعليمات دورين حاسمين:

تحليل الفرز: تصنيف المشكلات حسب انتهاك WCAG، والخطورة (sev1-sev4)، ومجموعة المستخدمين المتأثرة.
تدريب على إمكانية الوصول: توجيه الفرق في كتابة ومراجعة التعليمات البرمجية التي تراعي إمكانية الوصول.

تشير ملفات التعليمات إلى سياسات إمكانية الوصول في GitHub، ومكتبة المكونات، والوثائق الداخلية، مما يوفر لـ Copilot فهمًا شاملاً لكيفية تفسير وتطبيق معايير نجاح WCAG.

تتكشف الأتمتة في خطوتين رئيسيتين:

الإجراء الأول: عند إنشاء المشكلة، يحلل Copilot التقرير، ويملأ تلقائيًا ما يقرب من 80% من بيانات تعريف المشكلة. يتضمن ذلك أكثر من 40 نقطة بيانات مثل نوع المشكلة، وشريحة المستخدم، والمصدر الأصلي، والمكونات المتأثرة، وملخص لتجربة المستخدم. ثم ينشر Copilot تعليقًا على المشكلة يحتوي على ملخص للمشكلة، ومعايير WCAG المقترحة، ومستوى الخطورة، ومجموعات المستخدمين المتأثرين، وتعيين الفريق الموصى به، وقائمة مراجعة للتحقق.
الإجراء الثاني: يقوم هذا الإجراء اللاحق بتحليل تعليق Copilot، ويطبق التسميات بناءً على الخطورة المعينة، ويحدث حالة المشكلة على لوحة المشروع، ويعينها للمقدم للمراجعة.

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

الإشراف البشري والتحسينات المتكررة لإمكانية الوصول

يؤكد سير العمل على الإشراف البشري والتعاون. بعد التحليل الآلي لـ Copilot، تسمح مرحلة 'مراجعة المقدم' (الخطوة 3) للمقدم البشري بالتحقق من نتائج الذكاء الاصطناعي. يضمن هذا النهج الذي يشارك فيه الإنسان الدقة ويسمح بالتصحيحات اليدوية أو الأعلام لعملية التحسين المستمر لـ Copilot. الخطوات اللاحقة—مراجعة فريق إمكانية الوصول، وربط المراجعات، وإغلاق الحلقة—تدمج الخبرة البشرية بشكل أكبر، مما يضمن معالجة المشكلات المعقدة من قبل المتخصصين وتلقي المستخدمين لحلول في الوقت المناسب وفعالة.

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

المصدر الأصلي

https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/

الأسئلة الشائعة

What challenges did GitHub face with accessibility feedback before implementing its Continuous AI system?

Prior to the new system, GitHub struggled with a decentralized and inconsistent approach to accessibility feedback. Issues were often scattered across various backlogs, lacked clear ownership, and improvements were frequently postponed. This disorganization led to a lack of follow-through, leaving users with unaddressed concerns and creating a barrier to truly inclusive software development. The cross-cutting nature of accessibility issues, touching multiple teams, exacerbated these coordination challenges, making it difficult to establish a single point of responsibility or a coherent workflow for resolution.

What defines 'Continuous AI for accessibility' and how does it enhance traditional accessibility efforts?

Continuous AI for accessibility is a dynamic methodology that integrates automation, artificial intelligence, and human expertise into the software development lifecycle. Unlike static audits or one-time fixes, it's a living system designed to continuously process and act on user feedback. It goes beyond simple code scanners by actively listening to real people and using AI, particularly GitHub Copilot and GitHub Actions, to clarify, structure, and prioritize that feedback. This ensures that inclusion is woven into the very fabric of development, transforming scattered reports into implementation-ready solutions and fostering ongoing improvement.

How does GitHub Copilot specifically contribute to the efficiency and effectiveness of the accessibility feedback workflow?

GitHub Copilot plays a crucial role by providing intelligent triage and analysis of accessibility reports. Upon issue creation, Copilot, guided by custom instructions from accessibility subject matter experts, programmatically analyzes the report. It automatically populates approximately 80% of an issue's metadata, including WCAG violation classifications, severity levels, affected user groups, and recommended team assignments. This automated analysis significantly reduces manual effort, standardizes issue categorization, and provides immediate, actionable insights, allowing human teams to focus on problem-solving rather-than repetitive data entry and initial assessment.

What are GitHub's 'custom instructions' for Copilot, and why were they chosen over model fine-tuning for this system?

GitHub utilizes 'custom instructions' for Copilot, developed by their accessibility subject matter experts, to guide its behavior for triage analysis and accessibility coaching. These instructions are stored prompts that point to GitHub’s accessibility policies, component library, and internal documentation, detailing how WCAG success criteria are interpreted and applied. This approach was chosen over model fine-tuning because it allows for rapid iteration and team-wide updates. Any team member can update the AI's behavior by modifying markdown and instruction files via a pull request, eliminating the need for complex retraining pipelines or specialized ML knowledge, ensuring the AI's behavior evolves as standards do.

How does GitHub ensure that human judgment and oversight remain central to the accessibility process despite the extensive use of AI automation?

GitHub deliberately designed its system so that AI automates repetitive tasks while humans retain critical judgment and oversight. For example, after GitHub Copilot's initial analysis, a 'submitter review' step ensures a human verifies Copilot's findings. If Copilot's analysis is incorrect, humans can flag it, providing direct feedback for continuous improvement of the AI. Furthermore, every GitHub Action in the workflow can be manually triggered or re-run, ensuring that humans can intervene at any point. The goal is to offload mundane work to AI, empowering humans to focus on complex problem-solving, collaboration, and making informed decisions about software fixes.

Who are the primary beneficiaries of GitHub's enhanced accessibility feedback system, and how does it cater to their specific needs?

The system serves three primary groups. Issue submitters (community managers, support agents, sales reps) benefit from a guided system that standardizes feedback collection and educates them on accessibility concepts. Accessibility and service teams (engineers, designers) receive structured, actionable data including reproducible steps, WCAG mapping, and clear ownership, streamlining their remediation efforts. Program and product managers gain visibility into pain points, trends, and progress, enabling strategic resource allocation. Ultimately, the biggest beneficiaries are the users and customers with disabilities whose feedback is now consistently tracked, prioritized, and acted upon, leading to a more inclusive GitHub experience.

How does GitHub integrate user feedback from external sources into its internal accessibility process, ensuring consistency and actionability?

GitHub acknowledges that accessibility feedback can originate from diverse external sources, including support tickets, social media, email, and direct outreach, with the GitHub accessibility discussion board being a primary channel. Regardless of the source, every piece of feedback is acknowledged within five business days. When external feedback requires action, a team member manually creates an internal tracking issue using a custom accessibility feedback template. This template standardizes the collected information, preventing data loss. This new issue then triggers an automated GitHub Action, engaging GitHub Copilot for analysis and adding it to a centralized project board, ensuring consistent processing and action regardless of its origin.

ابقَ على اطلاع

احصل على آخر أخبار الذكاء الاصطناعي في بريدك.