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
Properly labeled headings are one of the most important things a designer can do for developer handoff. 68% of 1207 surveyed screen reader users responded that they are first likely to navigate via the headings when trying to find information on a lengthy web page.
Why? This makes it easier for visual scanning and screen readers to get a map of the page's content.
Use the semantic structure for headings whenever possible on paragraphs and sections (
There should only be one
h1 per web page (Markdown on a page is an exception).
Note: Headings don't need to visually match their semantic meaning, but should follow the correct level and order (
h1 through to
h6), without skipping levels or being removed altogether.
Follow a clear heading hierarchy
Don't use multiple `h1`s, skip over heading hierarchy for visual effect, or forget to label sections of information with headings
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.
Use the HTML
alt attribute when labeling an image. If the image has a descriptive caption already, you should give the image an attribute of
alt="". This will prevent the screenreader from telling the user about the image multiple times.
Why? When screen readers come across images, graphs, and icons, by default the screen reader will speak the name of the file, which most of the time can be unhelpful (for example:
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 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.