Accessibility at GitHub

On this page

GitHub's aim is to be the home for all developers. To be inclusive means we must consider accessibility at the core of how we design.

15% of the world's population has a disability (estimated by the World Health Organization based on 2010 data), and that doesn't take into consideration those under temporary or situational disabilities.

In many cases, devices that have been designed with accessibility in mind for a portion of the population end up benefiting everyone. Take the OXO brand's Good Grips line of products; although they were developed for people who have arthritis, most people found them easier to use than other product lines.

When you consider accessibility from the beginning of the design process and incorporate it throughout, it becomes part of an established design process that seeks to include everyone, of all abilities, and allows everyone to achieve more.

When reading through accessibility information, you might find the common abbreviation: "a11y". A11y is a shortening of the word "accessibility". It starts with the first letter, "a", uses the number 11 for the eleven characters inbetween the first and last letter, and ends with the last letter, "y".

What standards you must aim for

GitHub aims for Web Content Accessibility Guidelines (WCAG) 2.1 AA compliance. This includes all of WCAG 2.0 AA plus additional considerations.

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

Who should you consider when designing?

While there are a multitude of disabilities to consider, the majority will fall into one of these categories:

Visual: Anything that deals with sight, or technology that helps someone to see. This includes people who have different types of sight like color blindness.
Cognitive: Concentration, memory, judgement, problem solving, logic skills.
Mobility: Anything that affects movement in a body.
Hearing: A spectrum of disabilities related to sound or audio.

Each disability category can be further divided into three sub-categories:

Permanent: Disability does not go away.
- Example: Someone who is deaf
Temporary: The disability will go away in time.
- Example: Someone who has an ear infection
Situational: The environment someone is in plays a huge factor in how they interact with web content.
- Example: Someone who is at a loud sporting event

For an informative list on real-life disability situations, check An Alphabet of Accessibility Issues, published by The Pastry Box Project.

Microsoft has created a downloadable PDF that looks into the area of inclusive design from a people perspective, with several informative examples. Navigate to the ‘Inclusive 101’ toolkit on the main page of Microsoft’s Inclusive Design website.

Internal resources

If you're GitHub staff and need help with accessibility:

Visit the #accessibility Slack channel to ask questions or discuss accessibility issues
Check the github/accessibility repository (accessible to GitHub staff only) for information on events or learning resources
Attend the inclusive design office hours with @ichelsea on Tuesdays (the time alternates between 10am PST and 1pm PST every other week)

Support

Accessibility is a priority for GitHub. If you ever encounter accessibility related issues when using github.com, please don’t hesitate to get in touch via the contact page or email support@github.com with your concerns.

For information about the accessibility compliance of GitHub products, please refer to the VPAT report, outlining §508 accessibility information for GitHub.com, GitHub Enterprise, and GitHub Desktop.