Accessibility is everyone’s responsibility, and the purpose of this document is to provide general accessibility guidelines to developers and designers.
- General guidelines
- Development tools
- Manual testing
- Internal resources
- User support
Our products should be accessible to all. At minimum, features should comply to the requirements listed in 508 Reference Guide - 1194.22 from the US Access Board, and conform to Web Content Accessibility Guidelines 2.0 at Level AA.
Making our products accessible benefits everyone, not just people with disabilities. Below are some examples of use cases in which accessibility is important:
Visual: blindness, low vision, color blindness, using a screen reader or related assistive tech for lifestyle reasons (e.g. long car commute), machine readability and screen scraping technologies
Hearing: deafness, hearing impairment, speech impairment, using closed captioning or other assistive features for lifestyle reasons (e.g. coworking in a loud coffee shop)
Cognitive: including short-term memory issues, dyslexia, learning disabilities, trying to work or consume content while distracted or multitasking, etc.
Mobility: mobility impairments, repetitive stress injuries, power users who love keyboard shortcuts, busy parents holding a sleeping child while trying to operate a computer with one hand, etc.
Always use semantic HTML elements, like
nav. Most modern browsers implement the accessibility features outlined in the specs for these elements; without them, elements will need additional ARIA attributes and roles to be recognized by assistive technologies.
header have meaningful roles assigned, so use them, and use them carefully. This can help assistive technologies read the page better and help users find information quicker.
Only use a
div or a
span to markup up content when there isn't another HTML element that would semantically be more appropriate, or when an element is needed exclusively for applying CSS styles or JS behaviors.
<!-- Do: Button can be focused and tabbed to. --> <button type="button" class="btn">Send</button>
<!-- Don't: Button can't be focused and tabbed to. --> <span class="btn">Send</span>
More on semantic markup:
Make sure elements can be reached via tabbing, and actions can be triggered with a keyboard. Using semantic markup is especially important in this case as it ensures that actionable elements are tabbable and triggerable without a mouse. Note that elements positioned off-screen are still tabbable, but those hidden with
display: none or
visibility: hidden are effectively removed from content since they are neither read by screen readers nor reachable by keyboard.
Tab order is determined by the order of elements in the DOM, and not by their visual positioning on the page after CSS is applied. CSS properties
order for flex items are two common sources for disconnection between visual and DOM order.
tabindex attribute should only be used when absolutely necessary.
tabindex=0/-1makes an element focusable, while
tabindex=0also includes the element in the normal tab order. In both cases, keyboard triggers of the element still require scripting, so where possible, use interactive content instead.
tabindex=1+takes an element to the very front of the default tab order. When it's applied, the element's visual positioning is no longer indicative of its tab order, and the only way to find out where an element is would be by tabbing through the page. Therefore, unless a page is carefully designed around elements with positive tabindex, it is very error-proned, and thus currently prohibited in github.com.
Finally, bear in mind that some assistive technologies have keyboard combinations of their own that will override the combination on the web page, so don't rely on keyboard shortcuts as the only alternative to mouse actions.
<!-- Do: Tab order can be guessed. --> <button type="button" class="btn">1</button> <button type="button" class="btn">2</button> <button type="button" class="btn">3</button>
<!-- Don't: The second button's tab order is unexpected. --> <button type="button" class="btn">1</button> <button type="button" class="btn" tabindex="1">2</button> <button type="button" class="btn">3</button>
More on keyboard accessibility:
Be mindful when using small font size, thin font weight, low contrast colors in designs as it can severely affect usability.
Instead of relying solely on color to communicate information, always combine color with another factor, like shape or position change. This is important because some colors can be hard to tell apart due to color blindness or weak eyesight.
More on visual accessibility:
Text and labels
Make sure text-based alternative is always available when using icons, images, and graphs, and that the text by itself presents meaningful information.
<!-- Do: Link text communicates destination. --> <p>Find out more about <a href="#url">GitHub Enterprise pricing</a>.<br></p>
<!-- Don't: "Click here" is not meaningful. --> <p>To find out more about GitHub Enterprise pricing, <a href="#url">click here</a>.</p>
title to add information on top of existing content.
<a title="@octocat's repositories" href="https://github.com/octocat?tab=repositories">octocat</a>
aria-label when there is no text.
<a href="https://help.github.com/"><%= octicon("question", :"aria-label" => "Help") %></a>
Navigating from a list of all the links on a given web page is very common for assistive technology users. We should make sure that the link text itself is meaningful and unique, and there should be as few duplicated references as possible.
More on link responsibly:
aria-live, or focus management.
More on dynamic content:
Focus management is useful for informing users about updated content, and for making sure users land on the next useful section after performing an action. This means using scripts to change user’s currently focused element, and when focus changes, screen readers will read out change.
It is common for assistive technology users to jump straight to a form when using a website, so make sure most relevant information is in the form and is labelled properly. Labels and inputs should be associated with the
input[id], and help texts should either be part of the label or be associated with
<!-- Do: Click "Email" label to focus on the input, and help text is read out by screen readers when focusing on the input. --> <label for="test_input">Email</label><br> <input id="test_input" aria-describedby="test_input_help_good" class="width-full my-1" type="email"> <div id="test_input_help_good" class="f6">Please enter an email ending with @github.com.</div>
<!-- Don't: Input and label are not associated, and help text is not read out by screen reader when focusing on the input. --> <label>Email</label><br> <input type="email" class="width-full my-1"> <div id="test_input_help_bad" class="f6">Please enter an email ending with @github.com.</div>
We do client side scanning of inaccessible elements in development environment. The inaccessible elements will be styled with red borders with an onclick alert and console warnings.
Google Chrome provides an Accessibility Developer Tools extension. Once installed, go to Audits tab in developer tools, tick Accessibility. It scans the page for violations and suggests solutions.
If you're working on a design that uses color to communicate something, grab the Chromatic Vision Simulator app, this will let you use your iPhone camera to see what a colorblind person would see.
Check out the Web Accessibility showcase on GitHub. GitHubbers are free to add more projects to the showcase.
To use VoiceOver, the built-in screen reader for Mac, just hit ⌘ + F5. This will start voice narration and display most of the spoken information in a text box.
Use alt + control + left/right to navigate a web page. alt + control + space to click on an element. For more help with VoiceOver, check out the built-in tutorial in
System Preferences > Accessibility > VoiceOver > Open VoiceOver Training.
Keep in mind that behaviors in different screen readers can differ when navigating the same web page; just like designing for different browsers, when it comes to accessibility, it is not just the implementation of the browsers that can be different, but also the ones of assistive softwares.
- You can mention these teams when looking for help:
- @github/accessibility: GitHubbers interested in accessibility related topics and work on website accessibility issues.
- @github/colorblind: GitHubbers who are interested in accessibility for colorblindness.
- Go to #accessibility Slack channel to ask questions or discuss accessibility issues.
- Check github/accessibility repository for information on events or learning resources.
Accessibility is a priority for us, if you ever encounter accessibility related issues when using github.com, please don’t hesitate to reach out to us via the contact page or email us at firstname.lastname@example.org, we will try our best to assist.
For information about the accessibility compliance of GitHub products, please refer to our VPAT report, outlining §508 accessibility information for GitHub.com, GitHub Enterprise, and GitHub Desktop.