ხელმისაწვდომობა: GitHub აერთიანებს უკუკავშირს ინკლუზიაში უწყვეტი ხელოვნური ინტელექტის მეშვეობით

ხელმისაწვდომობის რევოლუციური ტრანსფორმაცია: GitHub-ის უწყვეტი ხელოვნური ინტელექტის მიდგომა

წლების განმავლობაში, GitHub საერთო, მაგრამ კრიტიკული გამოწვევის წინაშე იდგა: ხელმისაწვდომობის უკუკავშირის ეფექტურად მართვა. ტიპური პროდუქტის პრობლემებისგან განსხვავებით, ხელმისაწვდომობის საკითხები ყოვლისმომცველია, ხშირად ეხება მრავალ გუნდსა და სისტემას. ეკრანის წამკითხველის მომხმარებლის ერთი მოხსენება შესაძლოა ეხებოდეს ნავიგაციას, ავთენტიფიკაციას და პარამეტრებს, რაც ტრადიციულ იზოლირებულ უკუკავშირის პროცესებს არაეფექტურს ხდის. ამან გამოიწვია მიმოფანტული მოხსენებები, გადაუჭრელი შეცდომები და მომხმარებლების იმედგაცრუება, რომელთა პრობლემებიც მითიურ "მეორე ფაზაში" რჩებოდა, რომელიც იშვიათად ხორციელდებოდა.

ფუნდამენტური ცვლილების საჭიროების გაცნობიერებით, GitHub შეუდგა მოგზაურობას, რათა ცენტრალიზებულიყო უკუკავშირი, შექმნილიყო სტანდარტიზებული შაბლონები და გაესუფთავებინა მნიშვნელოვანი ჩამორჩენა. მხოლოდ ამ მტკიცე საფუძვლის ჩამოყალიბების შემდეგ გაჩნდა კითხვა: როგორ შეეძლო ხელოვნურ ინტელექტს ამ პროცესის შემდგომი ტრანსფორმაცია? პასუხი მდგომარეობს ინოვაციურ შიდა სამუშაო პროცესში, რომელიც მოქმედებს GitHub Actions-ის, GitHub Copilot-ის და GitHub Models-ის მეშვეობით, შექმნილია იმისთვის, რომ უწყვეტად გარდაქმნას მომხმარებლის უკუკავშირის ყოველი ნაწილი თვალყურის დევნად, პრიორიტეტულ და ქმედით საკითხად. ეს მიდგომა უზრუნველყოფს, რომ ხელოვნური ინტელექტი აძლიერებს ადამიანურ მსჯელობას, ამარტივებს განმეორებით ამოცანებს და საშუალებას აძლევს ექსპერტებს, ფოკუსირება მოახდინონ ინკლუზიური პროგრამული უზრუნველყოფის მიწოდებაზე.

უწყვეტი ხელოვნური ინტელექტი: 'ცოცხალი' სისტემა ინკლუზიისთვის

GitHub-ის "ხელმისაწვდომობისთვის უწყვეტი ხელოვნური ინტელექტი" უფრო მეტია, ვიდრე უბრალოდ ხელსაწყო; ეს არის 'ცოცხალი' მეთოდოლოგია, რომელიც აერთიანებს ავტომატიზაციას, ხელოვნურ ინტელექტს და ადამიანურ ექსპერტიზას, რათა ინკლუზია პირდაპირ პროგრამული უზრუნველყოფის შემუშავების საფუძველში ჩააშენოს. ეს ფილოსოფია საფუძვლად უდევს GitHub-ის ვალდებულებას 2025 წლის ხელმისაწვდომობის გლობალური ცნობიერების ამაღლების დღის (GAAD) ფიცის მიმართ, რომელიც მიზნად ისახავს ხელმისაწვდომობის გაძლიერებას ღია კოდის ეკოსისტემაში მომხმარებლის უკუკავშირის ეფექტურად მიმართვით და მნიშვნელოვან პლატფორმის გაუმჯობესებებში გადატანით.

ძირითადი გაცნობიერება იყო ის, რომ ყველაზე შთამბეჭდავი მიღწევები რეალური ადამიანების მოსმენიდან მოდის, თუმცა მასშტაბური მოსმენა მნიშვნელოვან გამოწვევებს წარმოადგენს. ამის დასაძლევად, 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-მა სტრატეგიული არჩევანი გააკეთა შენახული მოთხოვნების (მორგებული ინსტრუქციების) გამოყენებაზე მოდელის დაზუსტების ნაცვლად. ეს საშუალებას აძლევს გუნდის ნებისმიერ წევრს განაახლოს ხელოვნური ინტელექტის ქცევა მარტივი pull request-ის მეშვეობით, რაც გამორიცხავს რთული გადამზადების მილსადენების ან სპეციალიზებული მანქანური სწავლების ცოდნის საჭიროებას. როდესაც ხელმისაწვდომობის სტანდარტები ვითარდება, გუნდი ანახლებს markdown-ის და ინსტრუქციების ფაილებს, და ხელოვნური ინტელექტის ქცევა ადაპტირდება შემდეგი გაშვებისას.

GitHub Copilot კონფიგურირებულია მორგებული ინსტრუქციებით, რომლებიც შემუშავებულია მათი ხელმისაწვდომობის დარგის ექსპერტების მიერ. ეს ინსტრუქციები ორ კრიტიკულ როლს ასრულებს:

დახარისხების ანალიზი: საკითხების კლასიფიცირება WCAG დარღვევის, სირთულის (sev1-sev4) და დაზარალებული მომხმარებელთა ჯგუფის მიხედვით.
ხელმისაწვდომობის ქოუჩინგი: გუნდების ხელმძღვანელობა ხელმისაწვდომი კოდის წერასა და განხილვაში.

ინსტრუქციების ფაილები ეხება GitHub-ის ხელმისაწვდომობის პოლიტიკას, კომპონენტების ბიბლიოთეკას და შიდა დოკუმენტაციას, რაც Copilot-ს აძლევს ყოვლისმომცველ გაგებას, თუ როგორ უნდა მოხდეს WCAG-ის წარმატების კრიტერიუმების ინტერპრეტაცია და გამოყენება.

ავტომატიზაცია ორ ძირითად ნაბიჯად მიმდინარეობს:

პირველი Action: საკითხის შექმნისთანავე, Copilot აანალიზებს ანგარიშს, ავტომატურად ავსებს საკითხის მეტამონაცემების დაახლოებით 80%-ს. ეს მოიცავს 40-ზე მეტ მონაცემს, როგორიცაა საკითხის ტიპი, მომხმარებლის სეგმენტი, ორიგინალი წყარო, დაზარალებული კომპონენტები და მომხმარებლის გამოცდილების შეჯამება. Copilot შემდეგ აქვეყნებს კომენტარს საკითხზე, რომელიც შეიცავს პრობლემის შეჯამებას, შემოთავაზებულ WCAG კრიტერიუმებს, სირთულის დონეს, დაზარალებულ მომხმარებელთა ჯგუფებს, გუნდისთვის რეკომენდებულ დავალებას და შემოწმების სიას.
მეორე Action: ეს შემდგომი Action აანალიზებს 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.

იყავით ინფორმირებული

მიიღეთ უახლესი AI სიახლეები ელფოსტაზე.

გაზიარება