Accessibility

Because the Design System strives for as far-reaching inclusivity as possible, we aim to make the code as accessible as possible. However, because the current implementation of the system does not fully encompass the HTML, CSS and Javascript required to fully realize this goal, achieving accessibility of a Design System application will fall to its implementors.  

Where possible, each component document includes links to a relevant WAI-Authoring pattern that best reflects its intended implementation. You may also find further information within our documentation highlighting significant accessibility notes. 

The technical notes below are intended for developers using the Design System in an application’s code base. Look for accessibility considerations for designers contributing to the Design System components and patterns.

Significant A11y Implementation PatternsSemantic HTML

Currently, the Design System does not provide a standardized HTML template for the general layout pattern of a UL page view. However, coding basic semantic HTML for the main regions of your application is the most important (and easiest) way to begin creating an accessible experience for your users. 

Most applications will include some or all of the same basic landmark regions: 

 

Each of these sections have a corresponding semantic HTML tag that informs assistive technology, such as a screen readers, of the basic purpose of each page section. These tags are: 

  

Occasionally, technical complexities may prevent you from implementing these semantic tags into your codebase. If you are unable to use the appropriate semantic tag, you can flag your landmark region in HTML tags with the “role” attribute. 

For example, if you are unable to use <header>…</header> to indicate your page banner, simply add the role to whatever tag you’re using, as in <div role=”banner”>…</div>. 

 Learn more about landmark regions and how to use them at the ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/. 

ARIA Disclosures

While the DS documentation should point your toward specific implementation of most components, many will include a standard Javascript disclosure pattern. The basic pattern includes a visible trigger element, such as a button or link, that reveals a hidden, collapsed or otherwise dynamic element. 

The trigger element contains two important ARIA attributes, aria-expanded and aria-controls: 

<button type=”button” aria-expanded=”false” aria-controls=”target-id”>Show me</button> 

<div id=”target-id” class=”hidden”>I’m shown</div> 

When the user interacts (eg, by clicking or hovering) with the trigger element, the aria-expanded value should update to reflect whether the target element (identified by its id in the aria-controls attribute) is visible on screen. This updated attribute communicates to assistive technology (via the accessibility tree) that the state of the screen has changed. 

This pattern encompasses several common interactions, including modal display, accordion expansion and contraction, popover appearance and more. (Tabs follow a similar pattern, with “aria-selected” replacing the “aria-expanded” attribute.) 

Depending on your level of WCAG compliance, you may also need to consider focus and keyboard interactions for a fully accessible component.  Learn more about the disclosure pattern and how to fully implement at the ARIA Authoring Practices Guide: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/. 

General A11y References and Resources

Learn more about accessibility and best coding practices at the resources below.