Design’s journey towards accessibility

As a design organization we have the opportunity to make a significant impact on making GitHub inclusive for all developers. Designing complex interactions for users with a wide range of abilities is challenging. It’s easy to fall into traps where checks pass but the resulting experience isn’t actually a good experience for anyone, including those with disabilities. We are early on our path to accessibility, but we’ve also come a long way.

As a Hubber of 7+ years, I’ve seen a shift from my time as a manager leading a small scrappy design systems team, incrementally finding wins to improve the accessibility of our UI, to leading an org that has dedicated specialists helping to incorporate accessibility earlier into our design process–which is often referred to as “shifting left.” We’re seeing progress and momentum.

When I think about the circumstances that needed to start this shift, several key elements stand out: we needed a cultural shift in the organization with support of leadership, we needed full-time accessibility specialists (it couldn’t just be volunteers), and we needed to give people permission to make incremental progress without feeling they had to achieve perfect results.

The path towards delivering successful outcomes for accessibility is a journey. Like most meaningful change it takes time, a growth mindset, and some trial and error. I’d like to share GitHub design’s journey so far.

Follow the energy

Every design team has that person that asks, usually after a presentation of a potentially great design, “does that pass color contrast?” I’ve been that person. Turns out, it’s not the most effective way to get people energized about tackling accessibility. So, what does?

One of the more effective tactics I’ve found is to follow where the energy is. This can be the energy of passionate people that start to move an effort forward, or the energy an impactful and exciting project draws. For example, in 2017 we shipped a visual refresh to our marketing pages which included updates to making colors more vibrant. Naturally, there was a lot of energy and excitement around this project. We were already working on a color system to support this launch and took the opportunity to also improve the color contrast on marketing pages and GitHub UI via the new color system.

When testing out a new process, I’ve also found it most effective to start with those that are most excited, passionate, and open-minded–they generate the infectious momentum and energy. We’ve kicked off two new pilots this year: our Accessibility Design Bootcamp and Design Champions. The Accessibility Design Bootcamp is a bespoke training curriculum that is tailored to specific teams with a high focus on cultivating a strong relationship with the GitHub Accessibility team. The Design Champions program is designed to empower our individual contributors (ICs) to dedicate time for accessibility through training, process improvements, and accessible design consultation across GitHub.

The Design Champions program required people who were self-starters and passionate about accessibility, so we deliberately asked for people to opt into the first cohort, and worked with managers to ensure the individuals had support and bandwidth to participate. In just a few weeks since the pilot launched, we’ve already seen new processes, tools and approaches prototyped across our design teams. This is energizing for the accessibility team, and the momentum is creating interest from potential future Design Champions.

Building leverage with design systems

When I joined GitHub in 2015, I was very happy that we had the start of a design system with Primer. At the time Primer only included CSS for a small subset of UI patterns, but it was open sourced, packaged up and distributed via npm, and included the most important and highly used components.

Over time the design systems team developed Primer’s CSS architecture to be more reusable by untangling it from specific features and views, updated naming conventions to make it more intuitive, and added flexible single purpose class selectors called utilities. This got us far for a while before we turned to React and Rails UI components, which helped us provide behaviors along with markup and styles. UI components also give us greater ability to provide complete and accessible interaction patterns for feature teams to leverage out of the box.

As we developed UI components, we also developed our primitives layer and moved our color system, typography, and spacing into design tokens. In early 2020, we successfully shipped a visual design refresh to GitHub, primarily leveraging design tokens and style changes. This update not only revitalized the platform’s aesthetics but also prompted a broader adoption of Primer styles and primitives throughout GitHub’s UI. Building on this momentum, we unveiled Dark Mode and introduced a revamped color system at GitHub Universe in 2020, ensuring seamless theming capabilities. To accommodate the diverse needs and preferences of developers, we promptly followed up with the addition of dimmed and high contrast modes.

The architectural investment enabled us to automatically propagate design changes throughout the entire design system, eliminating the need for tedious manual adjustments. Recently, the Primer team was able to make another significant step on our accessibility strategy, and updated our color system to address thousands of color contrast issues in our default light and dark themes.

Primer played a crucial role in our accessibility journey, enabling incremental progress from the start and laying essential foundations for our ongoing efforts. It has now become a critical component of our strategy to deliver inclusive experiences to developers. While a design system ​​cannot guarantee universal inclusivity in everything you ship, it does give you a huge amount of leverage in delivering and maintaining a user experience that can be enjoyed by a broader set of users.

A cultural shift

The GitHub Design Org is home to our product designers, researchers, brand and marketing, and design systems teams. While we work embedded in squads with other functions like engineering and product, most design Hubbers also feel a strong identity to the GitHub Design Org, so although a cultural shift needs to happen at the company level, there are things we can do to influence our own microculture within the GitHub Design Org.

As the leader of our org, I made sure to be vocal about accessibility as a priority; however, the message needs to be repeated and brought into IC and project team communication. For design, that meant bringing this into discussions with my leadership team, ensuring we had clarity, and asking them to bring this into conversations with their managers and their ICs so that the message would cascade down.

Talking about accessibility needs to be backed up with programs, practices, and processes. Some ways we approached this were:

• Hosting accessibility design office hours. Our designers working on accessibility host weekly office hours to give people a “live” opportunity to ask questions and get feedback. We hold regular design reviews with leadership and updated our review templates to include questions about accessibility to ensure it was part of every design review.
• Highlighting in org-wide meetings. We hold monthly design “GitTogethers” where we often have ICs presenting on their work, and last November we hosted an “Accessibility Takeover” featuring multiple presentations from our accessibility designers and design engineers, showcasing examples of collaboration, and how to engage with the team. We also invited our Head of Accessibility, Ed Summers, to kick off the meeting to highlight the priority of this work.
• Program management. It became clear we needed to think about shifting accessibility left across the entire GitHub Design Org and develop a holistic program. With our design leaders focused on delivering updates to our product, we decided to hire an Accessibility Program Manager who joined earlier this year. They’ve been able to work with design leadership as well as our counterparts in engineering and product to develop programs that focus on where design can make a difference in helping generate accessibility enablement at scale. Two such programs are our Design Champions program and Accessibility Training Bootcamp. Both are putting in place education, integration, and systematic approaches to scaling up accessibility across GitHub.
• Inclusive workplace practices. As we’ve learned more about workplace accessibility we’ve incrementally updated our practices, such as improving how we run our GitTogethers, how we communicate in written and synchronous communication, and how we create inclusive presentations. Regardless of the abilities of who we currently work with, adopting inclusive workplace practices builds our practice, empathy and understanding, and sets us up better for onboarding people using assistive technologies in future.

Throughout all of these updates, we’ve celebrated wins to the point of almost over-communicating to keep the energy levels up while we tackle some difficult challenges.

All developers, not average developers

Designing an interface for many different user needs cannot be solved by designing the average of all people’s experiences. One size does not fit all, yet in the field of design we’re often making trade-offs in pursuit of finding a solution that works for the most people. That’s dangerous because what works for most people can completely exclude some people.

GitHub is used by millions of developers around the world, it’s been built and designed by hundreds and thousands of Hubbers, over 15+ years. When we make changes, it can have big impacts to customers who have grown accustomed to interaction patterns and workflows. Even in pursuit of improving our UI for people using a variety of assistive technologies, we could still end up with solutions that do not provide a good user experience. Improving individual features may not be enough, I think we’ll increasingly find the need to provide greater control to our customers at the application-wide level, similar to how an operating system gives customization options that influence your experience using a computer.

Regardless, we have to be careful not to make assumptions and challenge our biases. We need to explore, test, and seek feedback from real people with a range of abilities using a variety of assistive technologies. If you have a suggestion for improvement, a feature request, or just want to share your thoughts, let us know in Accessibility Feedback Community.

It’s important to hire people with disabilities, too. It has been clear to me how important a diverse team is from my experience working on design systems, where we are in danger of embedding our bias into systems the whole company uses to deliver experiences to our customers. We’re more likely to build inclusive experiences if we better represent the people we are designing for.

Progress over perfection

I strongly believe in creating an environment where people have permission to make progress over perfection. This can feel uncomfortable, especially when we understand the impact of getting things wrong. Embracing others’ enthusiasm is key, encouraging a safe environment to experiment where people can learn and make mistakes will result in faster progress overall. Consider everyone throughout the company as part of the accessibility team, not just the dedicated employees, if you want to build momentum on the journey towards accessibility.

If you’d like to learn more about accessibility at GitHub, check out accessibility.github.com.