PowerBI Charts and Interactive Maps

Table of Contents

Overview

Interactive Power BI charts are typically embedded to a web page via an iFrame. 

It's important that this data is fully accessible to both keyboard only and screen reader users.

Provide a text-based alternative or equivalent for interactive content that cannot be accessed by screen reader or keyboard only users. The text based equivalent (or a link to the text based equivalent) must be placed in close proximity to the interactive content.

All functionality of the content within the Power BI chart or interactive map should be operable through a keyboard interface. For any interactive content that is not operable through a keyboard a text based equivalent must be provided.

Ensure that the content does not "trap" keyboard focus when navigating Power BI charts and interactive maps. Keyboard only users and screen reader users must be provided with a mechanism (using only the keyboard) to exit the charts and interactive maps.

Provide instructions/help text on how to navigate interactive elements within maps/charts.

General Guidelines for Power BI Charts

• Data Tables

  • Data tables in Power BI dashboards must be fully accessible to keyboard and screen reader users.

• Text Based Equivalent

  • For users with learning disabilities and users who find it challenging to interact with the Power BI charts, please provide a text based equivalent of the raw data presented within the chart. The link to the text based equivalent should be placed in close proximity to the actual chart.

• Instructions and Help Text

  • Provide keyboard only users with instructions on how to navigate and interact with the charts and dashboards. This would include instructions on specific keystrokes for users to press.

  • Provide keyboard only users and screen reader users with instructions on how to interact with the filters.

  • Provide a summary and description of the Power BI dashboard content by incorporating a title attribute to the iframe tag that embeds the Power BI dashboard to the webpage.

• Text Labels and Headings

  • Add descriptive, purposeful titles, labels and heading to charts

  • Ensure that all chart labels are displayed horizontally.

  • Avoid unnecessary jargon or acronyms.

• Color and Color Contrast

  • Check that your report page works for users with color vision deficiency.

  • Ensure color contrast between title, axis label, and data label text and the background are at least 4.5:1.

  • Ensure color contrast between non-decorative non-text elements and their background is at least 3:1.

  • Avoid using color as the only means of conveying information. Use text or icons to supplement or replace the color.

  • Ensure that there is enough color contrast between chart legends and chart graphs.

  • Ensure that the color contrast ratio between font and background is at least 4.5:1.

  • Power BI charts often rely on using colors to convey data. However, screen reader users would not be able to pick up this type of information. Make sure that there is a text based equivalent. 

• Shapes

  • Make sure any decorative shapes are marked as hidden in tab order, so they aren’t announced by a screen reader.

  • Avoid using too many decorative shapes to the point where they are distracting.

  • When using shapes to call out data points, use alt text to explain what is being called out. and

• Images and ALT Text

  • Ensure ALT text (alternative text) is added to all non-decorative visuals on the page.

  • When using images inside a visual, such as embedding an SVG in a table or matrix, use alt text to describe the image.

  • When using images to call out data points, use alt text to explain what is being called out.

  • Make sure any decorative images are marked as hidden in tab order, so they aren’t announced by a screen reader.

  • Avoid using too many decorative images, to the point where they are distracting.

• Tooltips

  • Don’t use tooltips to convey important information. Users with motor issues and users who do not use a mouse will have difficulties accessing them.

  • Do add default tooltips to charts as ancillary information. It is included in the accessible Show Data table for each visual.

Please see additional guidelines and standards provided by Data SF, Digital Services and the Controller’s Office.

Data visualization standards for SF.gov | Public Data Visualization Guide

Any time that CCSF is displaying data to the public, it should also be made accessible as a dataset on http://data.sfgov.org

Please contact support@datasf.org if you like to publish new data to the open data website.

Examples of Accessible Power BI Dashboards

Example of accessible Power BI dashboard on sf.gov.

Open

Example of Keyboard Navigation Instructions for Power BI Dashboards

Keyboard users and screen reader users frequently use the TAB key on the keyboard to navigate through actionable items on a web page.

When the dashboard receives keyboard focus the keyboard navigation instructions will appear above the dashboard.

Guidelines for Interactive Maps

Here are some general guidelines to follow.

• Keyboard only users, screen reader users and users with learning disabilities who are unable to interact with the map, must be provided with a text based equivalent of the raw data presented within the map.

• The link to the text based equivalent should be placed in close proximity to the actual map.

Pinch Gesture Requirements Related to Maps

• A web site should include a map view that supports the pinch gesture to zoom into the map content. User interface controls offer the operation using plus and minus buttons to zoom in and out.

• A web site should include a map view that supports the pinch gesture to zoom into the map content. As an single-pointer alternative, the map also allows users to double-tap, hold, and then move the pointer up or down to zoom in or out.

Please see more detailed information regarding these requirements.

Hover States and Focusable Content

Additional content that appears and disappears in coordination with keyboard focus or pointer hover often leads to accessibility issues. Reasons for such issues include:

• the user may not have intended to trigger the interaction

• the user may not know new content has appeared

• the new content may interfere with a user's ability to do a task

Examples of such interactions can include custom tooltips, sub-menus and other nonmodal popups which display on hover and focus. The intent of this success criterion is to ensure that authors who cause additional content to appear and disappear in this manner must design the interaction in such a way that users can:

• perceive the additional content AND

• dismiss it without disrupting their page experience.

There are usually more predictable and accessible means of adding content to the page, which authors are recommended to employ. If an author does choose to make additional content appear and disappear in coordination with hover and keyboard focus, this success criterion specifies three conditions that must be met:

• dismissable

• hoverable

• persistent

Please see more detailed information on how to comply with this guideline.

WCAG Related Guidelines

1.3.1 Info and Relationships (Level A)

1.3.3 Sensory Characteristics (Level A)

1.4.1 Use of Color (Level A)

1.4.3 Contrast Minimum (Level AA)

1.4.11 Non-Text Content (Level AA)

1.4.13 Content on Hover or Focus (Level AA)

2.1.1 Keyboard (Level A)

2.4.6 Headings and Labels (Level AA)

2.5.1 Pointer Gestures (Level A)

3.3.2 Labels and Instructions (Level A)

3.3.5 Help (Level AAA)

4.1.1 Parsing (Level A)