Accessibility at GitHub

GitHub's aim is to be the home for all developers. Being inclusive means we consider accessibility at the core of how we design, build, and ship products, so that everyone can participate fully regardless of how they access GitHub.

Accessibility at GitHub is a program, not a one-time check. It combines clear standards, shared frameworks, and dedicated practices that help teams build accessibility in from the start rather than retrofitting it later.

Accessibility is one of GitHub's Engineering Fundamentals, and our broader accessibility strategy describes where we're headed: continuing to mature internally while engaging the global community of developers.

The standards we hold ourselves to

GitHub aims for Web Content Accessibility Guidelines (WCAG) 2.2 AA conformance. This includes all of WCAG 2.1 AA (with the exception of 4.1.1 Parsing, which was removed) plus additional considerations.

Currently, Section 508 (required by law in the United States) follows WCAG 2.0 AA guidelines for conformance.

To learn the core concepts behind these standards, see Accessibility fundamentals.

How accessibility works at GitHub

We take a "shift-left" approach: the earlier accessibility is considered, the better the outcome for everyone and the lower the cost of getting it right. Our program supports teams across three kinds of activities.

Learn

We invest in building accessibility knowledge across product, design, and engineering through training, playbooks, and role-specific guidance. Much of that thinking is shared publicly through this site, including:

• Accessibility fundamentals — core concepts and considerations.
• Copilot Accessibility Principles — designing AI experiences that work well for everyone.
• Design guidance and patterns and components — practical, implementation-level direction.

Connect

Building accessible products depends on listening to people with disabilities. We gather feedback through several structured pathways, including subject matter experts with lived experience, third‑party accessibility specialists, panels of users with disabilities, and inclusive user research. That input shapes designs, prioritizes fixes, and validates that experiences work in practice.

We also listen in the open. Anyone can submit feedback through the accessibility feedback page or the GitHub Community accessibility discussions, and we acknowledge, track, and work to resolve what we hear.

Apply

We give teams shared frameworks and tools so accessibility becomes part of everyday work rather than a separate task:

• The Scenarios Framework provides a shared way to describe, audit, and track real user tasks across GitHub.
• The Annotation Toolkit helps designers capture accessibility intent that visuals alone can't convey.
• Checklists and extensions and tools help teams check their work as they go.

Building a culture of accessibility

Accessibility scales when it's owned broadly rather than concentrated in a single team. Two practices help us spread that ownership across GitHub:

• Embedded accessibility designers. We embed accessibility designers within product teams so accessibility is considered from the first sketch to the final deployment, rather than reviewed only at the end.
• The Accessibility Champions program. Champions are people from engineering, design, and content teams who are trained in accessibility fundamentals and advocate for it within their teams. The program decentralizes accessibility expertise and builds a network of advocates across the company. You can read about how we built it in Empowering accessibility: GitHub's journey building an in-house champions program.

Accountability and public resources

Accessibility is a priority for GitHub, and we hold ourselves accountable in the open.

• For information about the accessibility conformance of GitHub products, refer to the GitHub Accessibility Conformance Reports.
• If you encounter an accessibility issue when using github.com, please report it on the accessibility community discussion page.
• Visit the accessibility feedback page to learn more about proactive feedback channels, or accessibility.github.com for more about GitHub's commitment to accessibility.

Sharing our work

We write about how we approach accessibility so others can learn from what's worked (and what hasn't). A few highlights from the GitHub Blog and beyond:

• Building GitHub's next chapter in accessibility — where our program is headed after its first five years.
• Scaling accessibility within GitHub and beyond — how we grew accessibility into a company-wide discipline.
• Empowering accessibility: GitHub's journey building an in-house champions program — building our Accessibility Champions program.
• How we're building more inclusive and accessible components at GitHub — accessibility in the Primer design system.
• Continuous AI for accessibility: how GitHub transforms feedback into inclusion — using AI to turn accessibility feedback into action.
• Our pledge to help improve the accessibility of open source software at scale — extending accessibility beyond GitHub to the open source community.
• Accessibility best practices for your project — a practical guide we contributed to opensource.guide, helping maintainers make their open source projects more accessible.

Internal resources