From checks to culture

Like many design organizations, GitHub’s work on accessibility has historically swung between two extremes: either it was an afterthought bolted onto finished designs, or it was reduced to a series of mechanical checks that passed without meaningfully improving anyone’s experience. The gap between “the check passes” and “the experience is actually good” is where the real work lives, and it takes more than a checklist to close it.

That realization has reshaped how GitHub’s design org operates over the past several years. The journey from a small team making incremental fixes to a dedicated Accessibility team embedded earlier in the design process—often called “shifting left”—required three things: a culture shift backed by leadership, full-time accessibility specialists rather than volunteers, and explicit permission to make incremental progress rather than chase perfection.

Start where the energy is

On every team there is someone who asks, usually right after a great design presentation, “does that pass color contrast?” That approach rarely gets people excited about accessibility. A more effective tactic is to find where energy already exists—whether that energy comes from passionate individuals or from a project that naturally draws attention—and attach accessibility work to it.

In 2017, GitHub shipped a visual refresh to its marketing pages with more vibrant colors. Since a color system was already being built to support that launch, it became the vehicle for improving color contrast across both marketing pages and the GitHub UI. The project’s existing momentum carried the accessibility work forward.

The same principle applies to prototyping new processes. Rather than rolling out a program broadly, it works better to start with the people who are most excited and open-minded. Two pilots launched this year follow that model: the Accessibility Design Bootcamp, a tailored training curriculum for specific teams with deep involvement from the GitHub Accessibility team, and the Design Champions program, which gives individual contributors dedicated time for accessibility training, process improvements, and consultation. The first Design Champions cohort was deliberately voluntary, with managers ensuring participants had the bandwidth. Within weeks, the group had already prototyped new processes and tools across design teams, and the momentum is attracting interest from future participants.

Design systems as leverage

Primer, GitHub’s design system, has been central to this work since 2015, when it only included CSS for a small subset of UI patterns. Over time, the team rebuilt Primer’s CSS architecture to be more reusable, introduced more intuitive naming, and added flexible utility classes. The system then expanded into React and Rails UI components, which package markup, styles, and behaviors together—critical for delivering complete, accessible interaction patterns that feature teams can use without reinventing them.

A primitives layer followed, moving color, typography, and spacing into design tokens. In early 2020, GitHub shipped a visual refresh driven primarily by those tokens, which not only modernized the platform but also drove broader adoption of Primer throughout the UI. Later that year, Dark Mode launched alongside a revamped color system, followed by dimmed and high contrast modes to accommodate a wider range of developer preferences.

The architectural payoff of tokens is that changes propagate automatically. When the Primer team updated the color system to address thousands of contrast issues in the default light and dark themes, the fix flowed through the entire design system without manual adjustments. A design system can’t guarantee universal inclusivity, but it provides enormous leverage in delivering and maintaining experiences that work for more people.

Culture is a program, not a memo

GitHub’s design org includes product designers, researchers, brand and marketing, and design systems teams. While designers are embedded in squads with engineering and product, they also identify strongly with the Design Org, which creates an opportunity to influence a microculture even before company-wide change happens.

Leadership has been vocal about accessibility as a priority, but that message only lands when it’s repeated and carried into team-level conversations. Several concrete mechanisms reinforce it:

  • Accessibility office hours. Designers working on accessibility host weekly live sessions for questions and feedback. Regular design reviews now include accessibility questions as a standard part of the template.
  • Org-wide visibility. Monthly design “GitTogethers” typically feature individual contributors presenting their work. Last November, the team hosted an “Accessibility Takeover” with multiple presentations from accessibility designers and design engineers. The Head of Accessibility opened the session to underscore its importance.
  • Dedicated program management. Recognizing that shifting accessibility left across the entire org required a holistic approach, the team hired an Accessibility Program Manager earlier this year to develop programs in coordination with design, engineering, and product. The Design Champions program and the Accessibility Training Bootcamp both came out of that effort.
  • Inclusive workplace practices. Incremental updates to how GitTogethers run, how communication happens in writing and synchronously, and how presentations are made have improved workplace accessibility. These practices build empathy and prepare the team to onboard people who use assistive technologies.

Wins are celebrated almost to the point of over-communication—a deliberate tactic to sustain energy while tackling difficult problems.

Beyond the average user

Averaging all users’ experiences is not a strategy for accessibility. Designing for the “most people” can completely exclude some people, and trade-offs made in pursuit of broad appeal often ignore real needs. GitHub is used by millions of developers and has been shaped by thousands of employees over more than 15 years—changes ripple widely across established interaction patterns and workflows.

Even well-intentioned improvements for assistive technology users can miss the mark if they don’t consider the whole experience. Improving individual features may not be enough. Eventually, GitHub may need to offer application-level customization controls similar to how operating systems let users shape their computing experience. Regardless, assumptions and biases must be challenged. Testing with real people who have a range of abilities and use a variety of assistive technologies is essential, and feedback can be shared through the Accessibility Feedback Community.

Diverse hiring matters equally. When design systems embed bias into tools that the whole company uses, the safest safeguard is a team that better represents the people it designs for.

Progress over perfection

An environment that allows for incremental progress—even when getting things wrong has real consequences—tends to move faster overall than one that demands perfection upfront. Welcoming enthusiasm, encouraging experimentation, and treating mistakes as part of the process all contribute to momentum. Accessibility is everyone’s job at the company, not just the dedicated specialists’ work.