Continuous AI for accessibility: How GitHub transforms feedback into inclusion

GitHub built a continuous, AI-assisted accessibility feedback system to replace scattered reports, unclear ownership, and unresolved “phase two” promises. The workflow combines GitHub Actions, Copilot, and GitHub Models to turn user feedback into tracked, prioritized issues while preserving human judgment. Its goal is continuous follow-through: every accessibility barrier is captured, routed, reviewed, and acted upon.

Accessibility as a Living System

• GitHub treats accessibility as an ongoing methodology rather than a one-time audit or standalone product.
• The approach combines:
  • Automation
  • Artificial intelligence
  • Human expertise
• Real user feedback is considered more valuable than automated code scans because it reveals barriers experienced in real workflows.
• The system supports GitHub’s 2025 Global Accessibility Awareness Day pledge to improve accessibility across the open source ecosystem.
• Technology helps process feedback at scale, turning unstructured reports into clearer, implementation-ready work.

Designing for Different Users

The workflow was designed around three primary groups:

• Issue submitters
  • Community managers, support agents, and sales representatives submit reports for users and customers.
  • Since they may not be accessibility specialists, the system guides them and teaches accessibility concepts during submission.
• Accessibility and service teams
  • Engineers and designers need actionable reports containing reproducible steps, WCAG references, severity ratings, and ownership information.
• Program and product managers
  • Leaders need trend data, issue categories, and progress visibility to prioritize investments.

The design treats feedback as data moving through a pipeline and allows the process to evolve over time.

Event-Driven Feedback Workflow

• Each workflow stage triggers a GitHub Action that determines what happens next.
• Key events include:
  • New issues launching Copilot analysis through the GitHub Models API
  • Status changes initiating hand-offs between teams
  • Resolutions triggering follow-up with the original submitter
• Actions can be started manually or rerun, allowing humans to intervene whenever necessary.
• GitHub initially built the system largely by hand in mid-2024; newer tools such as Agentic Workflows could now create similar Actions from natural-language instructions.
• The workflow contains seven stages:
  • Intake
  • Copilot analysis
  • Submitter review
  • Accessibility team review
  • Link audits
  • Closing the loop
  • Improvement
• Feedback loops allow submitters to rerun analysis, resolved issues to return for further review, and improvements to update Copilot prompts.

Actioning Intake

• Accessibility feedback can arrive through support tickets, social media, email, direct outreach, or GitHub’s accessibility discussion board.
• Approximately 90% of feedback currently comes through the public discussion board.
• Public discussions let other users:
  • Confirm reported problems
  • Add context
  • Share workarounds
• Reports from the community often contain more detail than conventional support tickets.
• GitHub acknowledges every report within five business days, including reports it cannot directly address.
• When internal action is needed, a team member creates a tracking issue using a custom accessibility feedback template.
• The template records:
  • The user’s original report
  • The feedback source
  • Relevant product components
• This preserves important context as feedback moves from intake into triage.