Skip to main content

Oregon State Flag An official website of the State of Oregon »

Oregon Health Authority logo

Accessible Data Visualizations Quick Guide

Accessibility Checklist for Data Visualizations

  • Use clear titles, headings, labels, and links
  • Include text summaries
  • Consider moving large blocks of text out of dashboards and onto web pages
  • Keep it simple
  • Make it easier for users to navigate your data visualization
  • Use text that supports readability
  • Choose colors carefully
  • Add alternative text to meaningful images and objects
  • Ensure information that displays on hover, such as tooltips, is accessible to non-mouse users or available elsewhere
  • Check your focus order early in the process
  • Ensure that data tables are enabled for data visualizations
  • Support mobile accessibility and reflow
  • Choose widgets and elements carefully
  • Use the latest available version of your platform to take advantage of accessibility-related updates
  • Test data visualizations  early and often
  • Learn more about accessibilty for data visualizations

Detailed Guidance for Power BI, Tableau, and R Shiny


Use clear descriptions throughout the dashboard or report. This includes:

  • The file name and dashboard or report title if they are used to generate the URL, otherwise a customer URL (if available).
  • Headings for narrative text and figures; if using markup, use hierarchical headings (h1-h6).
  • Labels for user interactivity controls; where practical, match the object name.
  • Links both within the dashboard or report and to external sites with a clear purpose in the link text alone (i.e., not just "link" or "read more").
  • In Shiny, ensure each application has a main title (i.e., title = in fluidPage), and each page has its own unique and descriptive label.

Relevant Standards


​​

Subtitles are encouraged for agency data visualizations (see Health Policy and Analytics [HPA]'s Data ​Visualization Style Guide 3.0 on the OWL). Your subtitle may provide a brief summary of the visual content. If it doesn't, we recommend adding additional text that summarizes the visual content in one to three sentences. This should supplement, not replace, an alternative format for the data itself. In most cases, this means you need both a summary (or subtitle) and an accessible data table for each visualization.​ Enabling data tables for visualizations is discussed further below.

Provide a summary for how people can interact with the data visualization. User interactivity controls should have instructions that don't rely only on shape, color, size or direction and error messages, if applicable, should be descriptive.

Narratives should be provided in text, not images of text.


Relevant Standards

​

​Blocks of text included in a dashboard often can’t be highlighted, copied, searched, magnified, easily translated, or otherwise customized for readability (a WCAG requirement). Dashboard developers are strongly encouraged to embed their dashboards on an OHA website rather than linking to a location on the Tableau or Power BI server, and to move large blocks of text out of dashboards and onto a webpage. In this approach, the embedded dashboard presents only the data visualization with its accompanying title and subtitle. See San Francisco Digital & Data Service’s article A template for accessible data visualizations and the HPA dashboard design standards (on the OWL) for more information on this approach.

​​

Relevant Standards​​


​

​​A clear, uncomplicated layout helps people more easily understand the relationships and patterns in your data. Focus on only the most relevant and important data. Avoid overwhelming users by limiting the detail and granularity of your visualization; that is, limit the number of marks, colors, and shapes in a single view.

Tableau has further guidance on this subject as a part of thei​r Author Views for Accessibility​ article.

Write in plain language, providing definitions for unusual words and abbreviations; aim for a 9th grade reading level. The Department of Administrative Services provides plain language resources​.

Relevant Standards

​

It can greatly help users to have easy access to information about how to navigate the data visualization. Consider adding screen reader and keyboard navigation information directly to your data visualization, or next to it.

In Power BI, helpful commands for screen reader users to know include Alt + Shift + F11 to open a data table, Tab to move focus between objects, and Ctrl + Shift to move focus within an object. Further information is available at Microsoft’s page on consuming reports with accessibility features.

Tableau provides a list of keyboard shortcuts on their webpage "Keyboard Accessibility for Tableau on the Web." Tableau recommends adding a link to the keyboard navigation instructions with an Image Object and Target URL. Appending ‘contentOnly=true’ to the end of the URL improves the user experience. It is also helpful for screen reader users to know that Text Objects require the use of a screen reader’s Browse Mode and down arrow​.

If using markup, the main language on a page and any words in a different language are identified.

In Shiny, use loading indicators that provide visual and screen reader feedback, like spinning loaders (shinycssloaders::withSpinner)) or dynamic status messages (aria-live="polite) to announce when data is loading/updating. Where appropriate, provide short instructions at the top of the dashboard to describe how to move between filters, tables, and visualizations using a keyboard.

If you dashboard or report is part of a series of web pages, be consistent in repeated elements especially for navigation, interactive components, and ways users can find help. Provide multiple ways for users to get to the dashboard or report, for instance by providing a Table of Contents, by linking from a central home page, or by providing links to navigate between related content.

​

Relevant Standards


​​​​

The OHA Graphic Standards Manual (available on the OWL) requires a minimum font size of 12pt and recommends larger font sizes for subtitles and titles: 24pt for level 1 headings, 18pt for level 2 headings, and 14pt for level 3 headings.

Generally speaking, sans serif fonts are better for readability than serif fonts. See agency style guides for further guidance on fonts styles.


You can use color to reinforce meaning, but it cannot be used alone to convey information. Pair color with other visual clues like shape, pattern, lightness, or direct labels. This ensures colorblind readers and readers with low vision can access the visual information.

Text alternatives for each meaningful element in a data visualization ensure that color vision and the ability to distinguish shapes or patterns are not required to understand the visualizations. It also ensures that people who use assistive technology, such as screen readers, have access to the same information. Enabling data tables for visualizations is discussed further below.

When it comes to color contrast, regular-sized text must have a contrast ratio of 4:5 to 1. Large-scale text must have a contrast ratio of 3 to 1. Large-scale text is defined as “at least 18 point or 14 point bold.” User interface components must have a contrast ratio of 3 to 1.

Furthermore, adjacent colors in a data visualization must have 3:1 contrast ratio. In practice, it can be very challenging to select a color palette with 4 or more colors that will provide consistent 3:1 contrast ratio in all possible combinations. If using multiple colors for a data visualization, the easiest way to meet this WCAG requirement is to create contrasting borders--black or white, depending on the lightness of the color palette--around all distinct visual elements in a data visualization and ensure that all colors in your palette have at least 3:1 contrast with the border. The new OHA Graphic Standards Manual (available on the OWL) includes guidance on which color combinations meet WCAG's contrast requirements for text and non-text.

We recommend creating a border of at least 2 pixels (px) width around bars, “pie pieces,” geographic boundaries, or other distinct elements in a visual. To add a border around a visual element in Tableau, click on “Colors” under the marks, and then click Border. In the current version of Power BI, it is also possible to create borders around distinct visual elements in a visual.​

The Health Policy and Analytics Division Infrastructure for Data Engagement and Access (IDEA) team has prepared a Tableau preferences file, Power BI theme file, and Microsoft theme file that align with the OHA Graphic Standards Manual (available at their OWL page) to create a custom color palette in Tableau Desktop. 


Relevant Standards​


​

If an image or object conveys meaningful information, it needs alternative text or alt text.

In R use ARIA labels if no other option meets the user's need, such as alt text. Using the aria-labeledby attribute is the preferred approach, if possible, as this provides support for mulitple languages. Otherwise, using aria-label attributes is acceptable.

You can provide alt text for any object on a Power BI Desktop report by selecting the object (such as a visual, shape, and so on). In the Visualizations pane, select the Format section, expand General, scroll to the bottom, and fill in the Alt Text textbox.

In Tableau, the way developers add alt text depends on the type of dashboard element.

To add alt text to an image, click on the dropdown arrow at the top right of the image or logo and select “Edit Image”. Then, add a URL; the image’s alt text will not be read by screen readers without a URL. Finally, add the alt text to describe what the image is and where the link will redirect the user.

Alt text is now automatically generated for worksheets but must be customized. Developers can edit automatically generated alternative text in the Data Guide panel or in the Accessibility sheet option (2,500 characters limit).

Navigation button tooltips both appear on mouse hover and serve as alt text for screen readers. Click on the dropdown arrow at the top right of the button and select “Edit Button”; add alt text to the Tooltip field. Customizing this text can improve navigation buttons. But it is essential for show/hide buttons. This is because the default text for show/hide buttons simply names the type of layout container and does not provide meaningful user instructions.


Relevant Standards


​​​

Content that displays only on hover is not accessible to non-mouse users, including keyboard users, switch users, and screen reader users.

This is true of tooltips in Power BI. If you use tooltips in Power BI, ensure that the same information is available elsewhere as real, static text. Otherwise, avoid using tooltips in Power BI.

The accessibility improvements added to Tableau by release includes keyboard navigation of text tables (or Visualization Navigation). Sheet tooltips appear with keyboard navigation as of the 2024.1 release, however, these tooltips are not yet screen reader accessible. Therefore, any information displayed in tooltips in Visualization Navigation still needs to be conveyed elsewhere on your dashboard.


Relevant Standards


​​

Focus order (or tab order) refers to the order in which a viewer navigates through a webpage or dashboard when using a keyboard. Setting focus order helps non-mouse users navigate your dashboard in an order that matches the visual order.

In Power BI, tab order must be set manually in the Selection pane, under the View tab. Order should be set for all objects. Tab order should be turned off for any decorative items.

In Tableau, focus order is automatically set to flow from top-to-bottom, left-to-right in dashboards created using Tableau 2021.3 or later. Where possible, choose a dashboard design that supports this default focus order. Developers can edit the focus order, but the process is very technical and time-consuming.


Relevant Standards​


​​

Data tables are the most widely used alternative presentation for data visualizations. Data tables allow all users, including screen reader users, to access the data represented by the visualization in full detail.

In Power BI, data tables are enabled by default. However, it can help screen reader users to be reminded of the key command to open data tables, Alt + Shift + F11, as this is a non-standard command.

In Tableau Public, when a visualization is in focus, users can open the ‘View Data’ window with Shift + Enter (or by tapping Enter twice) if the publisher has turned on the wo​rkbook’s ‘Allow Access’ setting. Note that user access to the ‘View Data’ window on the ODHS|OHA external Tableau Server is controlled in the server project permissions.


Relevant Standards


​​​

People use a variety of devices and browser magnification levels to access digital content. A dashboard or report must be able to scale to 400% without loss of information or function. This may require development of a separate layout to present content in a single column which will render at higher browser magnification levels and mobile devices, in both portrait and landscape. Avoid using fixed height and width items that don't display well at higher magnifications.

In Power BI, there is an option to create a mobile layout view that is linked to your desktop view. You will need to select Mobile Layout View and click “Auto-create." Adjust your layout for optimal sizing by clicking and dragging the image to fill the screen without overflow. After publishing your visualization, be sure to test it on a mobile device to ensure the layout is correct. Note that mobile layouts created this way will only display correctly using the Power BI app.

To create a mobile layout that works without the Power BI app installed, you must create separate mobile versions of each dashboard. These must be built with a mobile-optimized template and embedded into a web page. When a user visits the page, the page must be designed to detect their screen size and display the correct dashboard. See this article for more information: A template for accessible data visualizations.

In Tableau, we recommend creating a custom mobile layout. Tableau provides guidance for Creating Dashboard Layouts for Different Device Types. As noted in the Tableau article on Meeting New WCAG 2.1 Success Criteria in Tableau Dashboards: Reflow:

“[W]hile dashboards will scale without refreshing your browser, a refresh is necessary to trigger the loading of different layouts. Recall that the intent of the Reflow success criterion is to allow content to reflow correctly for browser magnification levels up to 400%. Most users who use browser magnification for low vision leave their browsers set at a magnification level that works for them; for these users, the correct dashboard layout will load the first time they view it."


Relevant Standards


​

Design so that all pointer actions have a keyboard equivalent. For any action that involves dragging, provide a simple pointer alternative. Pointer targets must be at least 24 by 24 pixels or have sufficient spacing.

​In Power BI, custom widgets are not vetted for accessibility. To ensure accessibility, use only Microsoft widgets.

Tableau maintains a list of which Tableau dashboard elements are accessible by software version. Mindfully selec​ting elements that are accessible when designing a dashboard will make the dashboard available to more users and reduce the amount of remediation needed to meet the Web Content Accessibility Guidelines​.​

In Shiny, design dashboards to fully support keyboard-only navigation. Test to ensure all interactive elements (modals, filters, tooltips, buttons) are reachable with the Tab key, can be activated with Enter or Space keys, and allow users to Tab out or close with the Esc key. Explicitly set the language attribute of the dashboard using tags$html(lang="en") so screen readers can interpret content correctly. Additional considerations include adding a "skip to main content" link to help users bypass navigation elements and move directly to the main dashboard content.

Relevant Standards

​​

​Don't save testing until the end! Test as you develop a data visualization to ensure features utilized are accessible. Be sure to test:

  • Different ways users navigate the data visualization, including using only a keyboard and with a screen reader. Listening to the screen reader output can also help catch typos and inform alternative text refinements.
  • Performance on multiple browsers (e.g., Google Chrome, Mozilla Firefox, Edge, Safari) and screen resolutions (e.g., desktop, different browser magnifications, mobile).

Testing as the developer provides a deeper insight into how people interact with the data visualization and informs your design decisions. If you can, ask people who regularly use assistive technology to test as well; they are expert in assessing web content usability.

As new accessibility features are developed, functionality and user experience may change. It’s good practice to retest published dashboards periodically to ensure the dashboard is performing as expected.

Some tools that support testing include:

  • Narrator, a built-in screen reader to Windows, and VoiceOver, a built-in screen reader for iPhones; JAWS and NVDA are commonly utilized by the community but require additional approval to install on state computers.
  • Browser web developer tools, for example FireFox's Accessibility Inspector, can support focus order review.
  • Color contrast checkers that assess whether two colors meet WCAG criteria for normal text, large text and graphical objects, like the Web Accessibility in Mind (WebAIM) Contrast Checker​.
  • WAVE Web Accessibility Evaluation Tools
  • The shinya11y R package. For more, see R Accessibility Links
​​

General accessible data visualization resources​


Platform-Specific Links

​