Accessibility

1. Overview

When creating content, take advantage of built-in and available accessibility and design features to ensure as many people as possible can access it.

Content viewed in full screen mode or embedded in your own application can be made accessible for all users. Upgrade to the latest version to take advantage of accessibility updates such as keyboard support and screen reader compatibility for filters and components, and then keep accessibility in mind as described below.

2. Guidelines

Your organization may require an accessible version of content that meets standards such as WCAG 2.1, for example to meet the criteria labeled as conformance levels A and AA.

See the Web Content Accessibility Guidelines (WCAG) and how to meet their criteria when designing your content and deciding on how to provide functionality. For example:

• To meet criterion 1.4.1 Use of Color, include an alternative way to convey information besides color hues: for example, choose colors that also have different lightness/brightness with at least a 3:1 contrast ratio if the color differences are meaningful or required to distinguish between data points, or label items directly. More options include using different marker/symbol shapes or using the Hatching option.
• To meet criterion 1.4.10 Reflow, you may need to use a responsive layout or add a responsive version of the content unless a two-dimensional layout is required for usage or meaning.
• To meet criterion 2.2.2 Pause, Stop, Hide if you have a visualization that automatically refreshes, you may need to provide a way to customize or disable the refresh interval.

3. Accessible names

Accessible names can be needed in multiple situations:

• Non-text content like charts, or icon buttons without text, should have an accessible name or short description set up to identify it to screen reader users. Unless this text would be a sufficient alternative for non-text content, there should also be a long description such as a table version of the data or a data label conveying the same data, and if necessary you could include instructions for where to find this in your short description (see Situation B in Understanding Success Criterion 1.1.1).
• Some input controls such as filters already contain a built-in label that is both displayed visually and accessible to screen reader users, but Drop Down List and Radio Buttons components should have a label component added and associated with it.
• Any type of content that already has a visible title should have it associated as its accessible name. For example, a table visualization is already made up of text accessible to screen readers but you can associate it with its title.

Add or associate an accessible name by setting ARIA Label in the Text tab of the Properties window:

• Enter an accessible name in the textbox. For example, for non-text content like a chart, you could provide a short description like Current Month Sales Chart.
• If the current item already has a visible title provided by a label component or data label, choose it from the dropdown to associate them together for screen reader users.

Decorative images and other non-interactive elements that don't convey meaning should not have an ARIA label because they should be ignored by screen readers. Hyperlinks and buttons that display text are already accessible to screen readers and normally should not be given an ARIA label.

4. See also

• Design overview
• Responsive layout dashboard mode
• Adding filters
• Web Content Accessibility Guidelines (WCAG)
• How to Meet WCAG
• MDN Web Docs: aria-label