Accessibility

This page is deprecated in favor of the UXD Handbook.

Our accessibility goals

This document is a guide and starting point for resources in creating accessible applications. In no way is it a final and complete document, but instead, a living document that will surely improve over time.

Our goal is to ensure that everyone can use our applications. To achieve this goal, we must strive for a usable and accessible experience in our applications.

Our goal with Sage is to, at minimum, meet the WCAG 2.1, Level AA standards. Per the WCAG's notes on conformance, it's generally not possible to satisfy all AAA requirements across an entire site.

Accessibility Guiding Principles

✨ We create Perceivable experiences

Components are presented in a way that users can perceive (sight, hearing, touch). For example, if a user has low vision, text alternatives are present and appropriate to images.

Ways we achieve a perceivable application

• We make it easy for users to differentiate content, including separating foreground and background
• We provide appropriate text descriptions for non-text content

✨ We create Operable experiences

Users must be able to use (operate) the application. For example, if a user can click a button, they must also be able to activate that button by a space key or enter key.

Ways we achieve an operable application

• We ensure all interactions are available to a keyboard user
• We ensure all users have enough time to interact with the interface
• We ensure all visual elements are safe for users with seizures or other physical reactions
• We ensure that the user can orient themself within the interface

✨ We create Understandable experiences

Users must be able to understand the interface. For example, the application's reading level should aim for a grade 9 or below. The hemingwayapp.com can help with determining reading level.

Ways we achieve an understandable application

• We ensure that language is simple and concise
• We ensure that functionality is consistent and intuitive
• We create experiences that operate in predictable ways
• We help users avoid and correct mistakes

✨ We create Robust experiences

Content is usable by a wide variety of user agents, including assistive technologies. For example, writing semantic HTML provides an excellent baseline for accessible code. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML

Ways we can achieve robust content

• We create responsive user experiences
• We write valid and semantic HTML

Guidelines / Resources / Tools

Check Your Colors

• Do not rely on color as a navigational tool or as the sole way to differentiate items
• Ensure there is enough contrast between text and its background color.
• Pair values of colors together (not only hues) to increase contrast, and test on-screen using a contrast checker of your choice of one of the following
  • WebAIM Contrast Checker
  • Coolers Contrast Checker

Describe Images

Without exception, images should always include an alt attribute in the markup/code. For purely decorative images, a blank (alt="") value is valid, but in all other cases, the alt text should succinctly describe an image's contents, or more importantly, its meaning. When in doubt, follow this general guideline:

If the content that the image conveys is presented within text in the surrounding context of the image, then an empty alt attribute may suffice.

Note that an empty alt attribute is completely different from not including an alt attribute. An empty alt attribute signifies that the image is not meaningful when relating to the content, but leaving out the attribute completely could result in a screenreader listing the image file's src instead. This is extremely likely to cause confusion.

For a solid overview on writing alt text, refer to the WebAIM guide or this article on accessible images.

Plan For The Keyboard

Functionality should be accessible through mouse and keyboard. Design focus states to help users navigate and understand where they are. Designs should never actively hide focus states. When visitors use the keyboard to navigate, your product should include obvious focus and active states.

Use Semantic HTML

A good base level of accessibility isn't difficult with some advanced planning.

Structure conveys meaning: HTML elements communicate to the browser the type of content they contain and how they should render or treat that content. Instead of reaching for a div when creating a list of items or a clickable element, use an unordered list and a button element, respectively. This not only helps with semantics but also can take advantage of baked-in functionality.

Do I need aria-xxx?

Maybe not! The first rule of ARIA is not to use it.

With properly semantic HTML, adding aria- attributes to your code may not even be necessary. Many of these semantic elements add the bonus of supplying landmarks and roles for screen readers. However, there are cases where aria roles, states, and properties can enhance the user experience. See the WAI-ARIA authoring practices for some useful examples.

Headings

With heading elements (h1 through h6), maintain a consistent hierarchy to indicate the item's importance in the document. Skipping heading levels should be avoided at all costs — keep the hierarchy intact, and use CSS to style differences in visual font size.

Validating

The Design System is only the foundation for accessible application development. We recommend that you review the accessibility of your applications before release and ensure that it meets the WCAG Standard at the AA Level. Basic testing can be performed with either axe for Web or the WAVE browser extension.

Additional resources

• WAI-ARIA design patterns
• Inclusive components