Khả năng tiếp cận: GitHub Chuyển Đổi Phản Hồi Thành Sự Hòa Nhập Bằng AI Liên Tục

Cách mạng hóa khả năng tiếp cận: Cách tiếp cận AI liên tục của GitHub

Trong nhiều năm, GitHub đã phải đối mặt với một thách thức phổ biến nhưng quan trọng: quản lý phản hồi về khả năng tiếp cận một cách hiệu quả. Không giống như các vấn đề sản phẩm thông thường, các mối quan ngại về khả năng tiếp cận có tính chất phổ biến, thường xuyên cắt ngang qua nhiều nhóm và hệ thống. Một báo cáo duy nhất từ người dùng trình đọc màn hình có thể liên quan đến điều hướng, xác thực và cài đặt, khiến các quy trình phản hồi bị cô lập truyền thống trở nên kém hiệu quả. Điều này dẫn đến các báo cáo rải rác, lỗi chưa được giải quyết và sự thất vọng của người dùng mà các vấn đề của họ kéo dài trong một "giai đoạn hai" thần thoại hiếm khi trở thành hiện thực.

Nhận thức được sự cần thiết phải thay đổi cơ bản, GitHub đã bắt tay vào hành trình tập trung hóa phản hồi, tạo ra các mẫu tiêu chuẩn và giải quyết một backlog đáng kể. Chỉ sau khi thiết lập nền tảng vững chắc này, câu hỏi mới nảy sinh: Làm thế nào AI có thể biến đổi quy trình này xa hơn nữa? Câu trả lời nằm ở một quy trình làm việc nội bộ sáng tạo, được cung cấp bởi GitHub Actions, GitHub Copilot và GitHub Models, được thiết kế để liên tục biến mọi phản hồi của người dùng thành một vấn đề được theo dõi, ưu tiên và có thể hành động. Cách tiếp cận này đảm bảo rằng AI nâng cao khả năng phán đoán của con người, hợp lý hóa các tác vụ lặp đi lặp lại và cho phép các chuyên gia tập trung vào việc cung cấp phần mềm hòa nhập.

AI liên tục: Một hệ thống sống cho sự hòa nhập

"AI liên tục cho khả năng tiếp cận" của GitHub không chỉ là một công cụ; đó là một phương pháp luận sống tích hợp tự động hóa, trí tuệ nhân tạo và chuyên môn của con người để nhúng trực tiếp sự hòa nhập vào cấu trúc của quá trình phát triển phần mềm. Triết lý này là nền tảng cho cam kết của GitHub đối với lời cam kết Ngày Nhận thức về Khả năng tiếp cận Toàn cầu (GAAD) năm 2025, nhằm tăng cường khả năng tiếp cận trên toàn bộ hệ sinh thái mã nguồn mở bằng cách định tuyến và chuyển đổi phản hồi của người dùng thành những cải tiến nền tảng có ý nghĩa một cách hiệu quả.

Nhận thức cốt lõi là những đột phá có tác động lớn nhất bắt nguồn từ việc lắng nghe những người dùng thực, nhưng việc lắng nghe ở quy mô lớn lại đặt ra những thách thức đáng kể. Để khắc phục điều này, GitHub đã xây dựng một quy trình phản hồi hoạt động như một động cơ năng động thay vì một hệ thống bán vé tĩnh. Tận dụng các sản phẩm của riêng mình, GitHub làm rõ, cấu trúc và theo dõi phản hồi của người dùng và khách hàng, chuyển đổi nó thành các giải pháp sẵn sàng triển khai.

Trước khi đi sâu vào các giải pháp công nghệ, GitHub đã áp dụng phương pháp thiết kế lấy con người làm trung tâm, xác định các đối tượng người dùng chính mà hệ thống cần phục vụ:

Người gửi vấn đề: Quản lý cộng đồng, nhân viên hỗ trợ và đại diện bán hàng cần hướng dẫn để báo cáo vấn đề hiệu quả, ngay cả khi không có chuyên môn sâu về khả năng tiếp cận.
Các nhóm khả năng tiếp cận và dịch vụ: Các kỹ sư và nhà thiết kế yêu cầu dữ liệu có cấu trúc, có thể hành động – chẳng hạn như các bước có thể tái tạo, ánh xạ WCAG và điểm mức độ nghiêm trọng – để giải quyết vấn đề một cách hiệu quả.
Các quản lý chương trình và sản phẩm: Lãnh đạo cần cái nhìn rõ ràng về các điểm khó khăn, xu hướng và tiến độ để đưa ra các quyết định phân bổ tài nguyên chiến lược.

Sự hiểu biết cơ bản này đã cho phép GitHub thiết kế một hệ thống coi phản hồi là dữ liệu chảy qua một đường ống được xác định rõ ràng, có khả năng phát triển theo nhu cầu của họ.

Tự động hóa quy trình phản hồi khả năng tiếp cận

GitHub đã xây dựng kiến trúc mới của mình dựa trên một mô hình hướng sự kiện, trong đó mỗi bước kích hoạt một GitHub Action để điều phối các hành động tiếp theo, đảm bảo xử lý phản hồi nhất quán bất kể nguồn gốc của nó. Mặc dù ban đầu được xây dựng thủ công vào giữa năm 2024, một hệ thống như vậy hiện có thể được phát triển nhanh hơn đáng kể bằng cách sử dụng các công cụ như Quy trình làm việc dựa trên tác nhân, cho phép tạo GitHub Actions thông qua ngôn ngữ tự nhiên.

Quy trình làm việc phản ứng với các sự kiện chính: tạo vấn đề bắt đầu phân tích GitHub Copilot thông qua GitHub Models API, thay đổi trạng thái kích hoạt chuyển giao nhóm và giải quyết vấn đề nhắc nhở theo dõi với người gửi ban đầu. Tự động hóa bao gồm đường dẫn chung, nhưng con người có thể kích hoạt hoặc chạy lại bất kỳ Action nào theo cách thủ công, duy trì sự giám sát và linh hoạt.

Quy trình phản hồi bảy bước:

Tiếp nhận: Phản hồi đến từ nhiều nguồn khác nhau như bảng thảo luận về khả năng tiếp cận của GitHub (chiếm 90% báo cáo), phiếu hỗ trợ, mạng xã hội và email. Tất cả phản hồi được xác nhận trong vòng năm ngày làm việc. Đối với các mục có thể hành động, một thành viên nhóm sẽ tạo thủ công một vấn đề theo dõi bằng cách sử dụng mẫu phản hồi khả năng tiếp cận tùy chỉnh, thu thập ngữ cảnh cần thiết. Sự kiện tạo này kích hoạt một GitHub Action để yêu cầu GitHub Copilot phân tích và thêm vấn đề vào một bảng dự án tập trung.
Phân tích của Copilot: Một GitHub Action gọi GitHub Models API để phân tích vấn đề mới được tạo.
Xem xét của người gửi: Người gửi ban đầu xem xét phân tích của Copilot, xác nhận tính chính xác hoặc thực hiện điều chỉnh.
Xem xét của nhóm khả năng tiếp cận: Nhóm chuyên trách về khả năng tiếp cận thực hiện xem xét sâu hơn và lập chiến lược giải pháp.
Kiểm toán liên kết: Các cuộc kiểm toán hoặc tài nguyên bên ngoài có liên quan được liên kết để cung cấp ngữ cảnh và tuân thủ.
Đóng vòng lặp: Sau khi được giải quyết, vấn đề được chính thức đóng lại và người dùng hoặc khách hàng ban đầu được thông báo.
Cải tiến: Phản hồi về hiệu suất của hệ thống, bao gồm phân tích của Copilot, cung cấp thông tin để cập nhật và tinh chỉnh liên tục.

Luồng liên tục này đảm bảo khả năng hiển thị, cấu trúc và khả năng hành động ở mọi giai đoạn của vòng đời phản hồi.

Phân loại khả năng tiếp cận thông minh của GitHub Copilot

Trọng tâm của hệ thống tự động này là phân tích thông minh của GitHub Copilot. Khi một vấn đề theo dõi được tạo, một quy trình làm việc GitHub Action sẽ gọi lập trình GitHub Models API để phân tích báo cáo. GitHub đã đưa ra một lựa chọn chiến lược là sử dụng các lời nhắc được lưu trữ (hướng dẫn tùy chỉnh) thay vì tinh chỉnh mô hình. Điều này cho phép bất kỳ thành viên nhóm nào cập nhật hành vi của AI thông qua một yêu cầu kéo đơn giản, loại bỏ nhu cầu về các đường dẫn huấn luyện lại phức tạp hoặc kiến thức học máy chuyên biệt. Khi các tiêu chuẩn khả năng tiếp cận phát triển, nhóm sẽ cập nhật các tệp markdown và hướng dẫn, và hành vi của AI sẽ thích ứng với lần chạy tiếp theo.

GitHub Copilot được cấu hình với các hướng dẫn tùy chỉnh được phát triển bởi các chuyên gia về khả năng tiếp cận của họ. Các hướng dẫn này phục vụ hai vai trò quan trọng:

Phân tích phân loại: Phân loại các vấn đề theo vi phạm WCAG, mức độ nghiêm trọng (sev1-sev4) và nhóm người dùng bị ảnh hưởng.
Hướng dẫn khả năng tiếp cận: Hướng dẫn các nhóm trong việc viết và xem xét mã có khả năng tiếp cận.

Các tệp hướng dẫn tham chiếu các chính sách khả năng tiếp cận, thư viện thành phần và tài liệu nội bộ của GitHub, cung cấp cho Copilot sự hiểu biết toàn diện về cách diễn giải và áp dụng các tiêu chí thành công của WCAG.

Quá trình tự động hóa diễn ra trong hai bước chính:

Hành động đầu tiên: Khi vấn đề được tạo, Copilot phân tích báo cáo, tự động điền khoảng 80% siêu dữ liệu của vấn đề. Điều này bao gồm hơn 40 điểm dữ liệu như loại vấn đề, phân đoạn người dùng, nguồn gốc, các thành phần bị ảnh hưởng và tóm tắt trải nghiệm của người dùng. Copilot sau đó đăng một bình luận về vấn đề chứa tóm tắt vấn đề, tiêu chí WCAG được đề xuất, mức độ nghiêm trọng, các nhóm người dùng bị ảnh hưởng, phân công nhóm được khuyến nghị và một danh sách kiểm tra để xác minh.
Hành động thứ hai: Hành động tiếp theo này phân tích bình luận của Copilot, áp dụng các nhãn dựa trên mức độ nghiêm trọng được chỉ định, cập nhật trạng thái của vấn đề trên bảng dự án và giao nó cho người gửi để xem xét.

Điều quan trọng là, nếu phân tích của Copilot không chính xác, bất kỳ ai cũng có thể gắn cờ nó bằng cách mở một vấn đề mô tả sự khác biệt, trực tiếp cung cấp thông tin cho quy trình cải tiến liên tục của GitHub đối với AI.

Giám sát của con người và cải tiến khả năng tiếp cận lặp đi lặp lại

Quy trình làm việc nhấn mạnh sự giám sát và cộng tác của con người. Sau khi Copilot tự động phân tích, giai đoạn "xem xét của người gửi" (bước 3) cho phép người gửi xác minh các phát hiện của AI. Cách tiếp cận có con người tham gia này đảm bảo tính chính xác và cho phép chỉnh sửa thủ công hoặc gắn cờ để Copilot tiếp tục cải thiện. Các bước tiếp theo – Xem xét của nhóm khả năng tiếp cận, Kiểm toán liên kết và Đóng vòng lặp – tiếp tục tích hợp chuyên môn của con người, đảm bảo rằng các vấn đề phức tạp được giải quyết bởi các chuyên gia và người dùng nhận được các giải pháp kịp thời, hiệu quả.

Hệ thống năng động này thể hiện một sự thay đổi đáng kể đối với GitHub. Bằng cách tận dụng AI để xử lý các khía cạnh lặp đi lặp lại và chuyên sâu về dữ liệu của việc quản lý phản hồi, họ đã biến một quy trình hỗn loạn, thường xuyên trì trệ thành một động cơ liên tục, chủ động cho sự hòa nhập. Điều này có nghĩa là mọi phản hồi về khả năng tiếp cận giờ đây đều được theo dõi, ưu tiên và hành động một cách đáng tin cậy, vượt ra ngoài những lời hứa về "giai đoạn hai" để mang lại những cải tiến hữu hình, ngay lập tức cho tất cả người dùng. Mục tiêu cuối cùng không phải là thay thế khả năng phán đoán của con người mà là trao quyền cho nó, giải phóng thời gian và chuyên môn quý giá để tập trung vào các bản sửa lỗi chiến lược và thúc đẩy trải nghiệm phần mềm thực sự dễ tiếp cận.

Nguồn gốc

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

Câu hỏi thường gặp

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.

Cập nhật tin tức

Nhận tin tức AI mới nhất qua email.

Chia sẻ