WCAG 2.1 & Data Visualization

Overview

The success criterion states that content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

Note: Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.

Key messages and examples

• Do not lock the content to either portrait or landscape presentation.
• Allow the user to choose.
• Do not force one particular orientation unless it is essential.

Here is an example of a data visualization that does not adjust when it is reoriented:

A Vertical Bar Chart in Landscape Orientation

A Vertical Bar Chart in Portrait Orientation

To address this reorientation issue, the visualization creator (creator) should, when possible, embed the visualization into a responsive web page hosted by the creator's agency. This allows the web page to display the visualization correctly in both landscape and portrait orientations.

Here is an example of the same vertical chart as above, now rendering appropriately to the display orientation it is in:

Vertical Bar Chart Reorientation Based on Display Orientation

How to implement

When someone views a data visualization: such as one created in Tableau or Excel, on a phone within a responsive web page, the page should adjust the visualization to match the device's orientation (landscape or portrait).

However, if the web page or server hosting the visualization does not allow orientation changes, the visualization will not adjust. This can make the content difficult to view on a mobile device.

• Use CSS to set the orientation to allow both landscape and portrait modes.
• If a maximum width size is preferred for a visualization, a creator can set it (e.g., some State of Minnesota agencies prefer a width of 550 pixels for vertical layout). This preference should be part of the creator's design plan for the visualization.
• In some cases, the creator can choose whether the visualization will be made for desktop, tablet, or phone screens and/or multiple devices. Setting the visualization for a particular device may allow the visualization, such as a dynamic visualization created with Tableau, to adjust appropriately for the user.
• If a certain orientation is required (i.e., the visualization will not be easy to view when in a different orientation), such as map with long horizontal or vertical lines, the creator can make a note about the preferred orientation for the user (using the HTML text), or the creator can create a second, scaled-down (or "basic") version that can be viewed in the non-preferred orientation. Note: The need for this additional version should be determined on a case-by-case basis.

Overall, creators, communications staff, and web staff need to understand the importance of allowing data visualizations to be viewed in different display orientations. To accommodate this, implementing responsive websites or specially formatted web pages may be necessary.

Barriers

• Designing without a responsive design framework.
• Lack of devices to test on, access to testing add-ons or testing tools.

This success criterion is not applicable for data visualizations.

It focuses on helping users identify and complete information in forms. The information typically includes personal details such as name, address, or email address.

This requirement generally does not apply to data visualization software because these tools usually display existing data rather than collect personal information from users.

Overview

Key messages

The intent of this success criterion is to allow users to enlarge text and related content without needing to scroll in two directions to read it. When lines of text extend beyond the edge of the viewport, users must scroll back and forth to read each line. This can cause them to lose their place and increases both physical and cognitive effort.

How to implement

Some visualizations, such as those created in Tableau, can resize when embedded in a responsive web page. This allows them to adjust to the device being used, such as a mobile phone or tablet. However, the data visualizations that resize can still require some horizontal scrolling and become pixelated at higher magnification. There is no clear remedy for this reflow issue because data visualizations are not designed to reflow.

Creators can reduce the need for scrolling by designing visualizations with a maximum CSS width (using the max-width property), often around 550 pixels. If a visualization cannot meet the reflow requirement, creators must provide the same information in an additional accessible format, such as a data table in a CSV file, an Excel spreadsheet, or a Word document.

Tables are an exception to this requirement. They may require two-dimensional scrolling, which is allowed under this success criterion. However, providing the information in an additional format (as mentioned above) is still preferred because it offers the most accessible option.

Testing tools

• Browser Zoom
• Software Program Zoom

Training

• W3C Schools: Accessibility Introductory Tutorial

Overview

The success criterion states the visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

• User Interface Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
• Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Key messages and examples

• It's important to understand that no color is inherently accessible - even though the high contrast color palette provides viable color options against a white background, any of them could fail if placed against a darker colored background. For this reason, content authors should learn to rely on color contrast testing tools, such as the Colour Contrast Analyser tool or WebAIMs Color Contrast Checker tool, to verify their work rather than assume a color is accessible.

How to implement

Creators can use practical techniques to adjust contrast options, such as adding a white or black border or creating space around objects that otherwise do not provide sufficient contrast.

• In Excel, borders of various colors can be added to charts with the "Border" option in the "Format Data Point" feature of the chart options.
• In Tableau, borders can be added through the Color Option on the Marks Card.
• Other visualization software may allow border changes and requires further researching to figure out.

Microsoft Support Center resources:

• Change the appearance of your worksheet web page: Includes steps to change the color of charts in Excel.
• Create and save a custom color scheme web page: Includes steps to customize a color palette in Word.

Color is required to understand graphical content:

• Provide sufficient contrast at the boundaries between adjoining colors
• Note: Add patterns when possible, to create data visualizations that are understandable in black and white.

How to test

For each graphical object required for understanding, use a color contrast tool to:

• Determine the foreground color of the graphical object.
• Determine the adjacent background color. If the background color is a gradient or pattern, identify the color with the least contrast to the foreground color.
• Check that the contrast ratio is equal to or greater than 3:1.
• If part of the background area does not meet 3:1 with the foreground, assume that parts of the icon adjacent to the area or areas are not visible.
• Check that the icon is still recognizable without any area of insufficient contrast.

Testing for color blindness

You can test how your color choices may appear to people with color blindness by using an online color blindness vision simulator, such as the Colblindor's Coblis Color Blindness Simulator or one that is offered in Adobe Creative Cloud applications. In Adobe Illustrator or Photoshop, you can turn on the color blindness simulator by visiting View > Proof Setup in the menu and then selecting the type of color blindness you wish to simulate.

Graph viewed through a colorblindness simulator

This image simulates how the "favorite fruit" graph may appear to someone with deuteranopia-type color blindness. It was generated using the color blindness simulator in Adobe Illustrator.

Graph viewed with grayscale

Another simple method for simulating color blindness is to convert the graph to grayscale. You can see how important the pattern fills are for this graph type.

Testing tools

• WebAIM Contrast Checker or Colour Contrast Analyser
• Colblindor's Coblis Color Blindness Simulator

Training

• W3C Schools: Understanding non-text contrast
• Office of Accessibility's Word eLearning Module 3: Working with Colors

References

• Understanding 1.4.11 Non-Text Contrast (AA)
• Keep Minnesota Bright: Understanding WCAG 2.1, 1.4.11 Color contrast for non-text items
• How to Improve Non-text Contrast: Color Schemes and Interface Components (Understanding Success Criteria 1.4.11 Non-text Contrast)
• More Attractive, Engaging, Accessible: How To Use Color With Intention
• WebAIM Contrast and Color Accessibility: Understanding WCAG 2 Contrast and Color Requirements
• State of Minnesota's Brand Color Palette - provides color options that can be added to Excel charts or Microsoft Word graphics.
• To add the State of Minnesota's Brand Color Palette to Tableau, see Tableau's Design Guide for Accessibility.

Overview

This success criterion requires that text used in a visualization support adjustable spacing without causing text or images to overlap. Content users must be able to override the creator's settings for the visualization using stylesheets, extensions, or other means. The content must remain readable and not be obscured by surrounding elements, such as buttons, banners, or overlapping text.

When text appears within a visualization, it may not support adjustable text spacing unless the software specifically provides responsive settings for certain devices, such as phones or tablets. Because of this limitation, creators should also provide critical information from the visualization in the HTML of the web page or, in the case of Tableau, in a caption when possible.

Providing this information outside the visualization helps ensure that people who override spacing settings, zoom into parts of the visualization, or use assistive technologies can still read and access the content.

Key messages

• Content users must be able to override the creator's settings for the visualization using stylesheets, extensions, or other means, and still be able to read all information without having it obscured by surrounding objects, such as buttons, banners, or overlapping text.
• If a visualization contains text, it may not support user-adjustable text spacing unless the visualization has been specifically designed for certain devices, such as phones or tablets. For this reason, any critically important information shown in the visualization should also be provided in the HTML of the web page or, in the case of Tableau, included in a caption when possible. Providing the information in these formats ensures it remains readable for people who override the visualization creator's settings, zoom into parts of the visualization, or use assistive technologies.

How to implement

Here are a few items to keep in mind when you are working with a visualization with text:

• Keep it short.
• Creators will need to test for text spacing, particularly as software continues to be updated. Creators should ask for assistance from a web developer to implement solutions to accommodate text spacing via CSS or JavaScript.

This success criterion will be monitored for further developments that could change the applicability to data visualizations.

Overview

• Dismissible - A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content.
• Hoverable - If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing.
• Persistent - The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

How to implement

• Technique: Make content on focus or hover hoverable, dismissible, and persistent.

In visualizations, tooltips often appear when the user hovers over a feature with a mouse, like a county section in a map or a specific bar in a bar chart. These tooltips frequently provide information that can't be obtained elsewhere. This excludes some users, like keyboard-only users or blind users, from accessing the information. A tooltip that disappears too quickly can also make it difficult for some users to read the content. To support accessibility, a tooltip should persist until the user dismisses it by moving away from the feature or dismissing the content another way. At the same time, if a tooltip appears unexpectedly or remains on screen without an easy way to dismiss it, especially without using a mouse, it can make the visualization harder to use. Designers should ensure that tooltips are easy to both access and dismiss.

A straightforward solution is to avoid using hover pop-ups and tooltips in data visualizations. If tooltips are necessary and do not meet this success criterion during testing, creators should provide additional accessible options:

• Provide the tooltip information in another way, such as directly in the web page (in the HTML), in an accessible PDF file, or within a downloadable table.
• Provide instructions, when possible, within the tooltip on how to dismiss the pop-up window (e.g., "select the Escape (Esc) key to dismiss").

How to test

• Use only a keyboard to move through the data visualization and test the three requirements

This success criterion is not applicable for data visualizations. It is related to setting Character Key Shortcuts with a keyboard.

Data visualization software does not offer the ability to create and set a shortcut. 

• Creators using other visualization software will need to check for character key shortcuts or interference with screen readers.

This success criterion will be monitored for further developments that could change the applicability to data visualizations.

Overview

The success criterion states that all functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential. Note: This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).

How to implement

Fortunately, most tasks in data visualizations can be accomplished with simple gestures or by using filters. However, some examples that are helpful to know in which complex actions may be required by visualizations:

In Tableau (and possibly other data visualization software) complex keystrokes or mouse clicks may be required, like:

• Making multiple selections from areas on maps while holding down the Control key.
• Using a mouse to select multiple points in a scatter plot while holding the Control key.

On mobile devices, some screen readers may require complex gestures to focus or read information, like:

• Voiceover on iPhones and iPads natively requires a rotor action of twisting two fingers in a circle, like turning a dial, to make a selection. This might be a hindrance to some users, but this interaction with the screen reader on a mobile device is beyond the control of data visualization creators.

If gestures are complex, the creator will need to build another accessible way to accomplish the same outcome as the complex gestures, such as:

• Making a pre-set group of points that can be selected with one selection or filter, such as by a group of counties in a region or a group of facilities.
• Setting a button programmed to accomplish basic common data requests.
• Providing information in an easily accessible format, such as a link to a table available from a panel.

How to test

Creators should make sure to test their visualization dashboards to ensure that the elements can be accessed easily without complex gestures on mobile devices or on desktops without a mouse.

Overview

The success criterion states that when functionality can be operated using a single pointer, at least one of the following is true:

• No Down-Event: The down-event of the pointer is not used to execute any part of the function.
• Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion.
• Up Reversal: The up-event reverses any outcome of the preceding down-event.
• Essential: Completing the function on the down-event is essential.

Note:

• Functions that emulate a keyboard or numeric keypad key press are considered essential.
• This requirement applies to web content that interprets pointer actions (i.e., this does not apply to actions that are required to operate the user agent or assistive technology).

Examples

• One example of meeting this success criterion occurs when a user clicks a Submit button with a mouse but can cancel the action before completing it. For instance, the user can press and hold the mouse button, move the cursor away from the Submit button, and then release the mouse button. In this case, the data should not be submitted after those actions. Fortunately, this type of pointer cancellation response is already an option built into Tableau, and likely other data visualization software as well. However, it would be useful to inform web developers of this success criterion, as they may be the ones embedding data visualizations into a web page and must ensure no changes are made that would cause this criterion to no longer be met and cause an accessibility issue.

Another way to meet this success criterion on mobile devices is to include a confirmation dialog box. This allows users to review and confirm their action before critical information is submitted, effectively providing an opportunity to cancel the action. This success criterion will be monitored for further developments that could change the applicability to data visualizations.

Overview

The success criterion states that when a user interface component with labels that include text or images of text, the name contains the text that is presented visually.

Note: A best practice is to have the text of the label at the start of the name.

Key messages

This success criterion concerns people who rely on voice recognition software to access and use form controls, such as radio buttons, drop-down menus, check boxes, and buttons.This topic is applicable to data visualization software when there is a visible text label for the control, such as "Select a County," but not when there isn't a visible control.

This success criterion requires additional research. We will continue to monitor for developments that could change applicability to data visualizations.

How to implement

Implementing this success criterion may be challenging with current visualization software options. Although a visible name for a control can be added to a dashboard, the accessible name would also need to be checked and changed, if needed. An accessible name is determined by a relatively complex formula determined by the coding of the application. A relatively simple example is from HTML: When a "Submit" button shows visible text that says "Submit" and then also has the same name in the code for the button.

• Here this HTML code meets the success criteria:
  <input type="submit" value="Submit">
• Here the HTML code does not meet the success criteria:
  <input type="submit" value="Send">

Currently, creators can only change an accessible name if they have access to the Application Programming Interface (API) for the software, such as Tableau's API. It also does not appear that the accessible name for the control is automatically added by visualization software, and for controls that do have a name added, the software by default adds the name "Button" or "Filter" before the visible name. Making changes through the API requires coding knowledge, which most data visualization creators are not expected to have. When changes are needed, a web developer may be able to help..

For now, visualization creators should ensure that tooltips always match the text of any controls and titles should be used for all filters.

This success criterion is not applicable for data visualizations.

It relates to the activation of features with a motion, such as twisting, shaking, or tilting. Tableau (and possibly other data visualization software) does not currently have these types of triggers. 

This success criterion will be monitored for developments that could change the applicability to data visualizations.

This success criterion is not applicable for data visualizations.

It concerns status messages that appear after a user action, such as clicking a search button. It does not seem to apply to interactive data visualizations such as Tableau, as Tableau does not create status messages, even if there is an error.

One possible exception: though not directly related to data visualizations, may occur when a user cannot successfully log in to a Tableau Server. For example, this could happen if the server is not running properly, if an incorrect username or password is entered, or if the connection to the server is interrupted. However, these situations are generally related to server administration rather than issues a data visualization creator would address. This success criterion will be monitored for developments that could change the applicability to data visualizations.