How we’re continuing to enable all developers to build

GitHub aims to be the home for all developers and we know that it is a great privilege and responsibility to make this a reality. We want to ensure that all developers have the opportunity to contribute to open source and use the GitHub platform for personal projects and at work—no matter their physical or cognitive ability. This is important work and we’ve been growing the team dedicated to making GitHub more accessible for developers all over the world.

In honor of Global Accessibility Awareness Day, we wanted to look at some of the challenges we’ve come across, how we’re solving them, and looking forward to what’s next in making GitHub more inclusive. Let’s dive in!

Approaching software development and accessibility

Digital Accessibility is a front-end user-interface (UI) challenge. GitHub is a very large platform that consists of a variety of front-end technologies from GitHub.com, GitHub Enterprise, GitHub Mobile, GitHub CLI, Electron apps for GitHub Desktop, and more. And with all of those front-end surface areas, the products that make up the GitHub platform are constantly being updated (we see our platform get updated several times a day), and each and every one of those updates can have a huge impact on GitHub’s accessibility.

We need to ensure that we’re enabling our many product teams that can affect any one piece of the GitHub UI to learn new skills and habits to make sure accessibility is built into everything we ship.

To summarize where we’re focused:

• Big UI surface area
• UI delivered using numerous different technologies
• Lots of user-generated content
• Large number of teams that need new skills and habits

Our approach

GitHub has created a central accessibility team that consists of designers, engineers, product and program managers—all of whom work with external consultants with disabilities and we subsequently consider their feedback as we build out our solutions. The role of our team is to help enable other teams across GitHub by providing training, tools, and documentation necessary so that teams can build accessible products.

Right now, we’re continuing to expand and grow the tools we provide our teams internally including things like:

• Primer for building an accessible component library
• Building a self-serve platform, including role-specific training, documentation, and tools
• Methods to measure the accessibility of the product
• Methods to ensure teams are accountable for the accessibility of their product

Building a strong foundation will help us meet Web Content Accessibility Guidelines (WCAG) and Authoring Tool Accessibility Guidelines (ATAG) and, go beyond the requirements, creating a highly usable suite of products. Becoming a highly-usable product for people with disabilities will take time. As we learn, we’ll share our accessibility triumphs and help the community understand our approach to interesting accessibility problems.

While we’re on this journey of development, we’re committed to listening and learning from our community, and growing as a company.

Recent accessibility ships

Things like appearance settings let you theme your GitHub experience, and we’ve recently shipped numerous themes which are designed to improve the experience for colorblind users or users who might benefit from a higher contrast experience.

Last year, we introduced accessibility settings that allow users to do things like changing the keyboard shortcuts available enabling “keyboard only” and assistive technology users to navigate GitHub. We also added a keyboard remap feature for the command palette and improved the focus indicators across GitHub.

Today, we’re announcing another accessibility setting which helps all users limit the level of distraction caused by animated images. The new setting will let you disable animated images— when you next come across an animated image, you’ll have options to play or pause the animation.

Looking forward

Internally, we want to build learning paths so that GitHub staff can build accessibility expertise. Externally, and beyond the challenge of making an accessible suite of products, we have lots of ideas related to how GitHub can use its position within the community to amplify accessibility in open source software (OSS). We are deeply excited by these kinds of opportunities:

• How can GitHub make it easier for OSS contributors to build digital accessibility into their software?
• How can GitHub help celebrate and accelerate OSS which already prioritize accessibility?

There are already amazing things happening in open source accessibility, such as projects like W3C Web Accessibility Initiative (WAI), NVDA, orca, MathJax, Teach Access Tutorial, Deque’s axe-core, Microsoft Accessibility Insights, and The Colour Contrast Analyser. We think the world needs more projects like these and more shining examples of OSS with accessibility built in.

We’re also watching where standards are moving, with WCAG 3 “Silver” and new versions of the authoring practices guide, and we’ll be trying to stay current with the latest and greatest from the W3C. While we’re on the subject of standards, a huge thank you to all the amazing contributors at the W3C Web Accessibility Initiative (WAI). The world is a more inclusive place because of your tireless efforts!

How can you get involved?

If you want to contribute to GitHub accessibility, you can join our team or contribute to one of the open source projects which have a direct impact on our product:

• Product documentation
• Primer component library

Don’t forget—if you have accessibility feedback, please get in touch via the GitHub Feedback discussion forum.

Written by

Benjamin Allen

@benjiallen