נגישות: GitHub הופכת משוב להכלה באמצעות AI רציף

מהפכה בנגישות: גישת ה-AI הרציף של GitHub

במשך שנים, GitHub התמודדה עם אתגר נפוץ אך קריטי: ניהול יעיל של משוב נגישות. בניגוד לבעיות מוצר טיפוסיות, חששות נגישות נפוצים, ולעיתים קרובות חוצים צוותים ומערכות מרובים. דיווח יחיד ממשתמש קורא מסך עשוי לגעת בניווט, אימות והגדרות, מה שהופך תהליכי משוב מסורתיים ומבודדים ללא יעילים. זה הוביל לדוחות מפוזרים, באגים בלתי פתורים, ותסכול של משתמשים שבעיותיהם נותרו ב"שלב שני" מיתי שלעיתים רחוקות התממש.

בהכירה בצורך בשינוי מהותי, GitHub יצאה למסע של ריכוז משוב, יצירת תבניות אחידות וניקוי צבר משמעותי. רק לאחר ביסוס יסוד יציב זה עלתה השאלה: כיצד יוכל ה-AI לשנות תהליך זה עוד יותר? התשובה טמונה בתהליך עבודה פנימי חדשני, המופעל על ידי GitHub Actions, GitHub Copilot ו-GitHub Models, שנועד להפוך כל פיסת משוב משתמשים לבעיה במעקב, מתועדפת וניתנת לפעולה. גישה זו מבטיחה שה-AI משפר את שיקול הדעת האנושי, מייעל משימות חוזרות ונשנות ומאפשר למומחים להתמקד באספקת תוכנה מכילה.

AI רציף: מערכת חיה להכלה

"AI רציף לנגישות" של GitHub הוא יותר מסתם כלי; זוהי מתודולוגיה חיה המשלבת אוטומציה, בינה מלאכותית ומומחיות אנושית כדי להטמיע הכלה ישירות במארג פיתוח התוכנה. פילוסופיה זו עומדת בבסיס המחויבות של GitHub להתחייבות יום המודעות העולמי לנגישות (GAAD) לשנת 2025, שמטרתה לחזק את הנגישות בכל המערכת האקולוגית של קוד פתוח על ידי ניתוב ותרגום יעילים של משוב משתמשים לשיפורי פלטפורמה משמעותיים.

ההבנה המרכזית הייתה שפריצות הדרך המשמעותיות ביותר נובעות מהקשבה לאנשים אמיתיים, אך הקשבה בקנה מידה רחב מציבה אתגרים משמעותיים. כדי להתגבר על כך, GitHub בנתה תהליך עבודה של משוב הפועל כמנוע דינמי ולא כמערכת כרטוסים סטטית. במינוף המוצרים שלה, GitHub מבהירה, בונה ועוקבת אחר משוב משתמשים ולקוחות, והופכת אותו לפתרונות מוכנים ליישום.

לפני שצללה לפתרונות טכנולוגיים, GitHub אימצה גישת עיצוב המציבה את האדם במרכז, וזיהתה פרסונות מפתח שהמערכת צריכה לשרת:

מגישי בעיות: מנהלי קהילה, סוכני תמיכה ונציגי מכירות הזקוקים להכוונה לדווח על בעיות ביעילות, גם ללא מומחיות עמוקה בנגישות.
צוותי נגישות ושירות: מהנדסים ומעצבים הדורשים נתונים מובנים וניתנים לפעולה—כגון שלבים ניתנים לשחזור, מיפוי WCAG, וציוני חומרה—כדי לפתור בעיות ביעילות.
מנהלי תוכניות ומוצרים: הנהלה הזקוקה לנראות ברורה לנקודות כאב, מגמות והתקדמות כדי לקבל החלטות אסטרטגיות בהקצאת משאבים.

הבנה יסודית זו אפשרה ל-GitHub לתכנן מערכת המתייחסת למשוב כנתונים הזורמים דרך צינור מוגדר היטב, המסוגל להתפתח בהתאם לצרכיהם.

אוטומציה של צינור המשוב לנגישות

GitHub בנתה את הארכיטקטורה החדשה שלה סביב תבנית מונעת אירועים, כאשר כל שלב מפעיל GitHub Action כדי לתזמר פעולות עוקבות, ובכך מבטיח טיפול עקבי במשוב ללא קשר למקורו. בעוד שבתחילה נבנתה ידנית באמצע 2024, כיום ניתן לפתח מערכת כזו באופן מהיר יותר באופן משמעותי באמצעות כלים כמו Agentic Workflows, המאפשרים יצירת GitHub Actions באמצעות שפה טבעית.

תהליך העבודה מגיב לאירועי מפתח: יצירת בעיה מפעילה ניתוח GitHub Copilot באמצעות GitHub Models API, שינויי סטטוס מפעילים העברת אחריות לצוות, ופתרון בעיות מעורר מעקב מול המגיש המקורי. האוטומציה מכסה את הנתיב הנפוץ, אך בני אדם יכולים להפעיל ידנית או להריץ מחדש כל Action, ובכך לשמור על פיקוח וגמישות.

תהליך העבודה של משוב בשבעה שלבים:

קליטה: משוב זורם ממקורות שונים כמו לוח הדיונים של GitHub לנגישות (אשר מהווה 90% מהדיווחים), קריאות תמיכה, מדיה חברתית ודואר אלקטרוני. כל משוב מקבל אישור תוך חמישה ימי עסקים. עבור פריטים הדורשים פעולה, חבר צוות יוצר ידנית בעיית מעקב באמצעות תבנית משוב נגישות מותאמת אישית, אשר לוכדת הקשר חיוני. אירוע יצירה זה מפעיל GitHub Action כדי לערב את GitHub Copilot ולהוסיף את הבעיה ללוח פרויקטים מרכזי.
ניתוח Copilot: GitHub Action קורא ל-GitHub Models API כדי לנתח את הבעיה שנוצרה לאחרונה.
סקירת מגיש: המגיש הראשוני סוקר את ניתוח Copilot, מאשר את דיוקו או מבצע התאמות.
סקירת צוות נגישות: צוות הנגישות המומחה מבצע סקירה מעמיקה יותר ומתכנן פתרונות.
קישור ביקורות: ביקורות רלוונטיות או משאבים חיצוניים מקושרים לצורך הקשר ועמידה בתקנים.
סגירת מעגל: לאחר הטיפול, הבעיה נסגרת רשמית, והמשתמש או הלקוח המקורי מקבל הודעה.
שיפור: משוב על ביצועי המערכת, כולל ניתוח Copilot, מזין עדכונים ושיפורים מתמשכים.

זרימה מתמשכת זו מבטיחה נראות, מבנה ופעולה בכל שלב של מחזור חיי המשוב.

מיון נגישות חכם באמצעות GitHub Copilot

בלב המערכת האוטומטית הזו נמצא הניתוח החכם של GitHub Copilot. כאשר נוצרת בעיית מעקב, תהליך עבודה של GitHub Action קורא באופן תכנותי ל-GitHub Models API כדי לנתח את הדיווח. GitHub עשתה בחירה אסטרטגית להשתמש בהנחיות שמורות (הוראות מותאמות אישית) במקום בכוונון עדין של המודל. זה מאפשר לכל חבר צוות לעדכן את התנהגות ה-AI באמצעות בקשת משיכה פשוטה, מה שמבטל את הצורך בצינורות אימון מורכבים או בידע מומחה בלמידת מכונה. כאשר תקני הנגישות מתפתחים, הצוות מעדכן את קבצי ה-markdown וההוראות, והתנהגות ה-AI מתאימה את עצמה בהרצה הבאה.

GitHub Copilot מוגדר עם הוראות מותאמות אישית שפותחו על ידי מומחי הנגישות של GitHub. הוראות אלו משרתות שני תפקידים קריטיים:

ניתוח מיון: סיווג בעיות לפי הפרת WCAG, חומרה (sev1-sev4) וקבוצת משתמשים מושפעת.
אימון נגישות: הנחיית צוותים בכתיבה וסקירה של קוד נגיש.

קבצי ההוראות מתייחסים למדיניות הנגישות של GitHub, לספריית הרכיבים ולתיעוד הפנימי, ומספקים ל-Copilot הבנה מקיפה כיצד לפרש וליישם את קריטריוני ההצלחה של WCAG.

האוטומציה מתרחשת בשני שלבים עיקריים:

פעולה ראשונה: עם יצירת בעיה, Copilot מנתח את הדיווח, מאכלס באופן אוטומטי כ-80% מהמטא-דאטה של הבעיה. זה כולל למעלה מ-40 נקודות נתונים כגון סוג בעיה, פלח משתמשים, מקור מקורי, רכיבים מושפעים וסיכום חווית המשתמש. לאחר מכן, Copilot מפרסם תגובה בבעיה המכילה סיכום בעיה, קריטריוני WCAG מוצעים, רמת חומרה, קבוצות משתמשים מושפעות, הקצאת צוות מומלצת, ורשימת בדיקה לאימות.
פעולה שנייה: פעולה עוקבת זו מנתחת את תגובת Copilot, מיישמת תוויות בהתבסס על החומרה שהוקצתה, מעדכנת את סטטוס הבעיה בלוח הפרויקטים, ומקצה אותה למגיש לצורך סקירה.

באופן מכריע, אם הניתוח של Copilot אינו מדויק, כל אחד יכול לסמן זאת על ידי פתיחת בעיה המתארת את הפער, ובכך להזין ישירות את תהליך השיפור המתמשך של GitHub עבור ה-AI.

פיקוח אנושי ושיפורי נגישות איטרטיביים

תהליך העבודה מדגיש פיקוח ושיתוף פעולה אנושיים. לאחר הניתוח האוטומטי של Copilot, שלב "סקירת המגיש" (שלב 3) מאפשר למגיש האנושי לאמת את ממצאי ה-AI. גישה זו של "אדם בלולאה" מבטיחה דיוק ומאפשרת תיקונים ידניים או סימון עבור תהליך השיפור המתמשך של Copilot. השלבים הבאים—סקירת צוות נגישות, קישור ביקורות וסגירת מעגל—משלבים עוד יותר מומחיות אנושית, ומבטיחים שבעיות מורכבות יטופלו על ידי מומחים ושמשתמשים יקבלו פתרונות יעילים ובזמן.

מערכת דינמית זו מייצגת שינוי משמעותי עבור GitHub. על ידי מינוף AI לטיפול בהיבטים החוזרניים והעתירים נתונים של ניהול משוב, הם הפכו תהליך כאוטי, ולעיתים קרובות קפוא, למנוע מתמשך ופרואקטיבי להכלה. משמעות הדבר היא שכל פיסת משוב נגישות עוקבת כעת באופן אמין, מתועדפת ומופעלת, חורגת מעבר להבטחות של "שלב שני" כדי לספק שיפורים מיידיים ומוחשיים לכל המשתמשים. המטרה הסופית אינה להחליף את שיקול הדעת האנושי אלא להעצים אותו, לשחרר זמן ומומחיות יקרים כדי להתמקד בתיקונים אסטרטגיים ולטפח חווית תוכנה נגישה באמת.

מקור מקורי

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.

הישארו מעודכנים

קבלו את חדשות ה-AI האחרונות לתיבת הדוא״ל.

שתף