Accessibility

Meeting (and exceeding) our accessibility goals

Our goal with Sage is to meet the WCAG 2.1, Level AA standard. However, 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 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.

For a solid overview on writing alt text, please refer to this WebAIM guide.

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?

The first rule of ARIA is not to use it. Adding aria- attributes to your code may not even be necessary with properly semantic HTML, and 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 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