Accessible experiences start with designers. Tacking on accessibility after a design is implemented costs businesses time and money, and it muddies the original design, leading to a poor user experience for people with and without disabilities.
When we consider accessibility from the beginning, we design for everyone from the start.
Consider how different people will experience your design. For an informative list on real-life disability situations, check An Alphabet of Accessibility Issues, published in The Pastry Box Project.
If you're designing a feature or experience in GitHub, use the following checklist to assess your design for accessibility:
WCAG 2.1 includes more nuanced considerations than what is listed here, but these basic considerations will give you a strong foothold into accessible design.
Text and user interface components on a page must meet a specific minimum contrast ratio to pass WCAG 2.1 AA standards.
Why? People with low vision may have trouble reading or understanding important information. Depending on the contrast ratio, users may not see the item at all. Besides being perceived as disabled items, this makes users struggle with actions like making sure they select the correct option.
Buttons with sufficient text contrast
Buttons with insufficient text contrast
Note: Disabled controls do not need to hit any specific contrast levels.
Official WCAG guidelines:
The main point in the guideline 1.4.1 Use of Color is to make sure that color isn't the sole identifier. If you have an important transition that is only a change in color, make sure that color change has a 3:1 contrast ratio.
A great way to test for this is to navigate that experience in greyscale mode.
Use color and a different shape to indicate issue status
Don't use only color to indicate issue status
Assistive technology users will frequently browse a list of links for easy navigation. For this reason, make sure that the link text is meaningful and unique. There should be as few duplicated references as possible to prevent confusion.
For more detail on accessible links, read the W3C's Understanding 2.4.4 - Link Purpose.
<p>Find out more about <a href="#url">GitHub Enterprise pricing</a>.<br /></p>
Make links meaningful and easy to understand
<p>To find out more about GitHub Enterprise pricing,<a href="#url">click here</a>.</p>
Don't create links that give no indication to the user
Why? Visible labels determine the purpose for inputs, and screen readers can read this information without extra code. If placeholder text contains important information and that information disappears when one starts to type, those with cognitive disabilities will have difficulty completing the form.
Hover cards and tool tips need to be approached with care. To meet the bare minimum for accessibility, tooltips need to be:
For more information read 1.4.13 Content on Hover or Focus.
People using the web should be able to increase font size to 200% without losing content or functionality.
If you'd like to go the extra mile and meet AAA guidelines, you can make sure that:
Read Primer's typography guidelines for more detail about using type on GitHub.
All interactive elements need to be accessed and activated by a keyboard alone (2.1 Keyboard Accessible).
Top three screen readers for computers (data from WebAIM, August 2019):
Top three screen readers for mobile devices (data from WebAIM, August 2019):
Keep in mind that just like there are different browser implementations, there are also different assistive technologies and their behaviors can vary.