Accessibility

Our accessibility goals

Our goal with Sage is to meet the WCAG 2.1, Level AAA standard whenever possible. However, per the WCAG's own notes on conformance, it's generally not possible to satisfy all AAA requirements across an entire site, therefore our minimum expectation is WCAG 2.0, Level AA.

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 one of the many free tools available.

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 and be tagged to worked with voice-control systems. 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 highly visible 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 the browser should render or treat that content. Instead of reaching for a div when creating a list of items or a clickable element, make use of 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 importance of the item 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