Why GitHub decentralised its accessibility work
As GitHub scaled up its accessibility assessment process, the volume of issues requiring attention began to strain the centralised accessibility team. The solution was not simply to hire more specialists, but to distribute ownership of accessibility across the organisation. That effort took shape as the GitHub Accessibility Champions program, which trains employees from engineering, design, and content teams to drive accessibility work within their own groups.
The program’s design had to account for practical realities: different time zones, varying levels of employee expertise, and the fact that champions would be balancing accessibility duties against other priorities. Clear goals and measurable objectives were established from the outset, giving champions a defined roadmap and giving the program a way to track its impact both internally and externally.
Starting with a pilot cohort
The curriculum was built around asynchronous materials—videos, articles, and interactive exercises—to accommodate different learning preferences. Training covered WCAG guidelines, inclusive design principles, testing techniques, and best practices for accessible content and interfaces. Participants also learned how to spot and address barriers, advocate for accessibility within their teams, and work with assistive technologies.
The program deliberately launched small, beginning with 17 engineering champions. This pilot phase allowed the team to refine the content and structure based on real feedback before expanding. The cohort has since grown to 52 champions across engineering, design, and content, with a target of over 100 internal champions this year. The incremental scaling built a network of advocates who could support one another as the program matured.
Iterating on feedback
Participant input drove significant changes to the program’s format. Champions asked for more interaction and community, which led to monthly Champions Connect meetings where participants could share insights and collaborate on accessibility challenges. Hands-on bug bashes were introduced as practical learning sessions where teams worked through real accessibility issues together.
“Being able to ask questions and get answers quickly on simple matters is important to my team’s success. Or, if the questions are too complex to get immediate answers, having a forum to take the time and unpack them to get the answers.”
There was also demand for live, synchronous training. GitHub responded with sessions tailored separately to engineers and product managers, offering Q&A opportunities and technical deep dives. The training increasingly leaned on practical exercises—using a codespace to find issues and verify fixes was highlighted by one champion as an effective way to move from learning about assistive technology to acting as an auditor or verifying engineer.
“Getting a codespace to identify issues and identify remediations is an excellent way to move from using and understanding assistive technology to taking on the role of an auditor or engineer who is verifying fixes.”
Roundtable discussions with customers who have disabilities added another layer to the program, giving champions direct exposure to the experiences and needs of end-users.
“Communicating the value of why we should design and create accessible documentation is key to success on my team. Everyone wants to do the right thing and is willing to do more complex tasks if they understand how it helps people better use our product.”
The result of this feedback loop was a program that kept shifting toward hands-on learning and community building:
“I loved that the training was super detailed, to a point where someone with zero information on accessibility can get started with basic concepts all the way to acknowledging problems they didn’t know existed.”
Lessons for other teams
The program’s broader aim is to model an approach other organisations can adapt. The team distilled its experience into a set of practical recommendations for anyone looking to build a similar internal accessibility education effort:
- Start where you are. Assess your organisation’s current state and identify where accessibility education can most usefully be introduced.
- Go where you’re wanted. Invest in teams with clear advocacy for accessibility and a willingness to participate—those are the groups where change will take hold.
- Pilot with a small group. Test the program with a few people first, gather feedback, and then scale up.
- Lean into organic partnerships. Collaborate across roles and departments rather than relying on a single central team to carry the work.
- Seek out, review, and take action on feedback. Iterate the program based on what participants actually need.
- Collect and re-evaluate metrics. Track the program’s impact continuously so it can be refined and justified to stakeholders.
The Accessibility Champions program positions accessibility as an ongoing organisational practice backed by a community of advocates. Its expansion plans will be shared on accessibility.github.com, where the team also invites feedback via its accessibility community discussion page.
