Data Visualization, Microsoft Technologies, PASS Summit, Power BI

Power BI Visual Usability Checklist

At PASS Summit, I presented a session called “Do Your Data Visualizations Need a Makeover?”. In my session I explained how we often set ourselves up for failure when conducting explanatory data visualization before we ever place a visual on the page by not preparing appropriately, and I provided tips to improve. I also gave examples of visual design mistakes I see often. I polled the audience, and they shared some mistakes that they had seen often or that really bothered them. If you missed my presentation, you can watch it on PASS TV or Youtube.

As a companion to my presentation, I created the Power BI Visualization Usability Checklist. For those who are new to data visualization in Power BI, or those that want to employ some type of quality check, I think this is a good place to start. I occasionally do data viz makeover engagements to help people create a report that is more engaging and more widely adopted. This list draws from that experience as well as the tweaks I find myself making to my own Power BI reports. And now I have added a few things that my PASS Summit audience mentioned – thanks to those who shared their suggestions and experiences!

I’m not here to tell you to always use a certain color theme or font, or that everything should be a bar chart. Data visualization is situational and dependent upon your intended audience. I hope I can encourage you to consider your audience, how they take in information, and what information they are looking for.

This checklist provides guidelines to help make sure your report communicates your intended message in a way that works for your intended audience. It has two pages. The Data Viz Usability Checklist page contains the main checklist for you to use while building or reviewing a Power BI report.

Screenshot of Power BI Visualization Usability Checklist

The Data Viz Usability Concepts page gives you quick definitions and links for further reading about the underlying design concepts that inform my list.

Screenshot of Power BI Visualization Usability Concepts

Download the checklist here. I also have a checklist for accessibility in Power BI reports which you can find here.

If you have a suggestion to add to either list, please leave me a comment!

 

Data Visualization, Microsoft Technologies, Power BI

Considerations for Using Layout Images in Power BI

Using layout images in Power BI has become a popular design trend. When I say layout images, I’m referring to background images with shapes around areas where visuals are placed. This is different from the new wallpaper feature that became available in the July release, which can be used to format the grey area outside your report page and extend the main color of background images.

Layout images can help with spacing and alignment within a report and can help create consistency across reports. They can also help create affordances, using consistent layout and design to make it obvious how users should interact with our reports.

I use layout images in some of my reports, but I don’t think they are necessary on every report. There are a couple of things to consider when using layout images.

  1. Don’t let your layout image take the focus away from the data. This can happen due to lack of color contrast or because the color(s) used in the layout image are much more intense than the visuals on your report page.
  2. While we may strive for consistency in report design, especially in larger organizations, we can’t let a layout keep us from creating the most effective visual to communicate the information in our data. If we start with a layout and limit ourselves to only visuals that fit that layout, that constraint may prevent us from creating a better report. If you have identified the chart type you need to communicate your information, but it doesn’t fit in your 3-column layout because the visual needs to be a bit wider, get a new template that accommodates your visual. I would rather see slightly different templates than ineffective chart types or the right chart types but the visuals squished into a space where they don’t fit (hard to read, truncated labels, etc.).

You can make your own layout images or choose one that someone else has created. PowerBI.Tips offers Power BI layouts in the form of Power BI Templates (.PBIT files) with background images set on the report pages where you replace the data source and repopulate the visuals. The templates also contain report themes.

Frederik Hedenstrom has a grid generator where you can set the width, height, columns, spacing, and colors. Then you can download your image and set it as your page background.

When I make my own layouts, I typically just use PowerPoint. Usually, the layout is the last thing I add rather than the first, but you can do what works best for you. This is the process I use to make layout images:

  1. Take a screenshot of my report page and paste it onto a blank PowerPoint slide.
  2.  Draw shapes (usually rectangles or rectangles with rounded corners) over the screenshot where the visuals are placed.
  3. Delete the screenshot from the slide.
  4. Format the slide background and the shapes (alignment, colors, outline, shadow effects, etc.).
  5. Export the slide as an image.
  6. Import the image as the page background. Adjust the image fit and transparency as needed.

Doing it myself is a bit of work, but it means I get exactly the effect I want. And I’ve gotten pretty quick at it now that I have done it several times. But again, you can take shortcuts using the resources mentioned above. Once I have my background layout image set, I check that it isn’t too distracting by asking myself these questions:

  • Is the background more intense than the visuals to where I look at it before I look at the data visualizations?
  • Do my visuals no longer stand out because the background color is too similar to the colors in my visuals?
  • Can I still clearly read my charts, including all titles and labels now that the background image is in place?

To help illustrate my points, take a look at this example report I have been working on.

PBINoLayoutImage
Version 1: No Layout Image
PBILayoutImage
Version 2: Layout Image Applied
PBILayoutImageTooDark
Version 3: Layout Image Too Distracting

In Version 1, there is no layout image. Some might think the report looks a tad bare. While there is a layout of 3 rows, it’s not immediately obvious.

In version 2, I have applied a layout image. It is subtle, using a light gray background color and a soft shadow around the shapes. It emphasizes the 3 rows, which makes sense in this report. In the top row I have the title and some summary numbers. In the middle row, I’m slicing number of reviews and % recommended by high-level categories. In the bottom row I have one visual that slices average and median ratings by a more detailed category.

In version 3, I changed the background to a dark gray/light black.  With that background, the dark color is the thing in the report that stands out most to me, but it provides no information and doesn’t enhance the user experience more than the subtle light version of the layout image.

Final Thoughts

Layout images can be useful. You can save time by using images created by others, but don’t let a layout needlessly constrain your data visualization or distract from the information in your report.

 

Accessibility, Data Visualization, Microsoft Technologies, Power BI

Power BI Report Accessibility Checklist

In many cases, some small changes can go a long way in making your Power BI reports more accessible for users with different abilities. The checklist below lists considerations you should make in your report design to create more inclusive reports. I’ll update this post as new features are released.

Accessibility Checklist

Last Updated: 29-Nov-2018

All Visuals

  • Ensure color contrast between title, axis label, and data label text and the background are at least 4.5:1.
  • Avoid using color as the only means of conveying information. Use text or icons to supplement or replace the color.
  • Replace unnecessary jargon or acronyms.
  • Ensure alt text is added to all non-decorative visuals on the page.
  • Check that your report page works for users with color vision deficiency.

Slicers

  • If you have a collection of several slicers on your report pages, ensure your design is consistent across pages. Use the same font, colors, and spatial position as much as possible.

Textbox

  • Ensure color contrast between font and background are at least 4.5:1.
  • Make sure to put text contents in the alt text box so screen readers can read them.

Visual Interactions

  • Is key information only accessible through an interaction? If so, rearrange your visuals so they are pre-filtered to make the important conclusion more obvious.
  • Are you using bookmarks for navigation? Try navigating your report with a keyboard to ensure the experience is acceptable for keyboard-only users.

Sort Order

  • Have you purposefully set the sort order of each visual on the page? The accessible Show Data table shows the data in the sort order you have set on the visual.

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 tooltips to charts as ancillary information. It is included in the accessible Show Data table for each visual.

Video

  • Avoid video that automatically starts when the page is rendered.
  • Ensure your video has captions or provide a transcript.

Audio

  • Avoid audio that automatically starts when the page is rendered.
  • Provide a transcript for any audio.

Shapes

  • Avoid using too many decorative shapes. They are announced by the screen reader when reading the page.
  • When using shapes to call out data points, use alt text to explain what is being called out.

Images

  • When using images to call out data points, use alt text to explain what is being called out.
  • Avoid using too many decorative images. They are announced by the screen reader when reading the page.

Custom Visuals

  • Check the accessible Show Data table for custom visuals. If the information shown is not sufficient, look for another visual.
  • If using the Play Axis custom visual, ensure it does not autoplay. Make it obvious that the user must press the play/pause button to start/stop the changing values.

Across Visuals on the Page

  • Set tab order and turn off tab order on any decorative items.

Power BI Accessibility Features

Tools to Check Accessibility in your Power BI Report

Keyboard Only Navigation

  • Use a keyboard to navigate and interact with your report, without using a mouse.

Color Vision Deficiency

Low Vision

  • Use a mobile device with brightness on low to test mobile reports
  • Use WebAIM or Accessible Colors to check color contrast of text vs background
  • Use The Squint Test to check that a Power BI report makes sense to someone with low vision

If you would like to suggest an update to the list, feel free to leave a comment on this post.

Data Visualization, Microsoft Technologies, Power BI

Choosing a Color Palette For Your Power BI Report

Color is a powerful attribute in data visualization. In a good visualization, it can focus attention and enhance meaning and clarity. When color is used poorly, it creates clutter and confusion. Power BI has a default color palette, but it isn’t always optimal or even appropriate for many reports. Luckily, Power BI allows you to use any color that can be defined by a hex code where visuals allow colors to be changed. With so many choices, choosing a color palette can be overwhelming. Below are some tips to help you choose a good color palette for your Power BI reports.

A color palette is simply a collection of colors applied to the visual elements in your report. What we typically refer to as color is a combination of three main properties: hue (base color on the color wheel), intensity (brightness or gray-ness) and value (lightness or darkness). You can build an engaging and professional looking report with just 6 colors. It’s possible to have fewer colors or more colors, but 6 should cover many common visualization needs. If you are using more than 6 colors, you might want to check that you are optimizing engagement and cognitive load.

  1. Main color – default color on graphs
  2. Color 2 – used when multiple colors are needed in a graph or report
  3. Color 3 – used when multiple colors are needed in a graph or report and Color 2 has already been used
  4. Highlight color – a color used to highlight important data points to make them stand out from other points on the page
  5. Border color – a light color used for borders on tables and KPIs where necessary
  6. Title color – color used for visual titles and axis labels as appropriate

Example Power BI color palette with 6 colors

While your title and border colors don’t have to be variations of gray, gray is a practical color for these purposes when using a white background. You could also use brown, blue, purple, etc. You just want to ensure that your text color has sufficient contrast from its background and that it isn’t more intense than your data colors. I tend to make my border color a tint of the title color.

This is a good place to define a few terms. A hue is a base color without black, white, or gray added, which you might find on a basic color wheel. A shade is achieved by adding black to any pure hue, making it darker. A tint is achieve by adding white to a pure hue, making it lighter. A tone is achieved by adding gray to a pure hue, making it less saturated and more muted.

I think it’s easiest to start your color palette by choosing the main color. This could be inspired by your corporate color palette or logo, your favorite color, or a color associated with the subject matter of your report. Be aware that color has cultural meaning and conveys emotion, and you want to choose a color that conveys the appropriate tone of your report. This can get tricky, so just try to make sure you don’t choose a main color that has a lot of cognitive dissonance with your subject. For instance, if you are creating a report for a U.S. audience about our gun violence problem, you probably wouldn’t use a light, happy, pastel green as your main color. But you could be fine using a bright red, dark blue, orange, black, or several other colors.

You will want to choose a main color that has a medium intensity.  If it is too bright or too dark, you won’t have any room to use a more intense version of that color to focus attention. And since you want your main, secondary, and tertiary color to be the same intensity, it would feel as if everything on the page were yelling at you if all three colors were bold. If you are starting from a corporate color palette, be aware that most brand color palettes were designed for websites and print collateral, not data visualization. They are usually too intense or bright to serve as your main data visualization colors. But you can use a tint or tone of your corporate colors so your reports stay on brand.

Once you have chosen your main color, you need to decide what type of color scheme you would like to use. Common options include:

  • monochromatic – tints and shades of a single hue
  • complementary – colors that are opposite each other on the color wheel
  • analogous – colors that are next to each other on the color wheel
  • split complementary – a base color plus two colors that are adjacent to its complement on the color wheel
  • triadic – colors that are evenly spaced on the color wheel

Example color schemes from ColorHexa.com

My current favorite tool for choosing colors is ColorHexa. It provides hex colors, color schemes (as shown above), tints, shades, and tones.

Once you have made some initial color choices, test it out on a few charts to ensure you can answer yes to the following questions:

  • Are all colors easily distinguishable from each other? If you were to use the main, secondary, and tertiary color in a line chart, could you easily follow the lines as they cross each other?
  • Is your color palette color blind friendly? You can use ColorHexa or Coblis to check this. It’s not always obvious when you have people with color vision deficiency in your intended audience, so it’s better to use colors that are easily distinguishable by those with red-green color blindness (deuteranomaly, deuteranopia, protanomaly, and protanopia).
  • Does your highlight color have high contrast from your other colors so it is obvious that it is being used to draw attention to a trend or data point?
  • If you are using a non-white background color, do your colors stand out sufficiently from your background?
  • When you look at your color choices, do you find the combination generally appealing, balanced, and not overly jarring? This is a bit subjective, but if you look at your colors and have a negative reaction then your audience will probably have a similar reaction.

Finally, be aware that colors display differently on different screens and surfaces. You can put a lot of time and effort into choosing the perfect colors, then share a report with someone and have it look rather different on their monitor or when viewed on a projector screen. If you can, review your colors on the equipment that your intended audience will most commonly use to make sure it looks good for them.

If you are still having trouble choosing colors, you can check out the Power BI Report Theme Gallery for some inspiration. Not every example in the gallery shows good color choices, but you can still use it to get ideas.

Once you have your color palette, you can reuse it in future reports by making a report theme. And if you aren’t a fan of manually writing JSON for your report theme, check out the Report Theme Generator from PowerBI.Tips. If you define your colors in a report theme, Power BI will create tints and shades of your colors for you, saving you the trouble of having to look them up yourself.

Power BI Color Picker

If you have advice to help others choose colors, leave a comment on this post or tweet me.

Azure, Microsoft Technologies, Power BI

Thoughts and Lessons Learned From A Power BI Embedded POC

I worked on a Power BI embedded POC where a report with an in-memory Power BI model as the dataset was embedded into an application in an “app owns data” scenario. This means that the application handles all authentication and access, and users do not need to be Active Directory users or have Power BI licenses. This can be a good fit when you want analysts to be able to change the reports as needed and immediately see the changes in the application

High-Level Components and Steps


Overview of Power BI Embedded in an ISV Scenario
Image from Microsoft Docs: https://docs.microsoft.com/en-us/power-bi/developer/embedding

The following items are needed for embedding Power BI content into an ISV/app owns data application:

  • Azure Active Directory tenant
  • Power BI Pro account
  • Power BI dashboard, tile, or report
  • Power BI workspace
  • Power BI embedded capacity (for testing/production)
  • An application in which to embed the Power BI content

While there is pretty good documentation for this, the steps weren’t immediately clear to me because the app owns data and user owns data scenarios are mixed and matched in some parts of the documentation from Microsoft. I found there are 8 main steps to embedding content with row-level security enabled in an app owns data scenario.

  1. Create the Azure Active Directory account to be used by the embedding application. Assign a Power BI Pro license to the account.
  2. Create an app workspace in PowerBI.com. Set the workspace to private. Set the analyst who owns the report as the workspace admin. Set the service account (created in step 1) as a workspace admin.
  3. Update the Power BI report with row-level security roles and filters. Ensure that usernames and corresponding roles are available to the application.
  4. Publish the Power BI report to the app workspace.
  5. Register the application that will show the report in Azure Active Directory.
  6. Add code to the application to get the Active Directory access token.
  7. Add JavaScript to the application to create the Power BI client, get the content item to embed, create the embed token, and load the content.
  8. Provision the appropriate Power BI embedded capacity in Azure and assign the app workspace containing the report to the embedded capacity.

There is an example project in Github for your reference, as well as a utility to help you generate your embedding code.

Thoughts And Lessons Learned

Interestingly, row-level security works just the same as it does on PowerBI.com. You do nothing different in your PBIX file. You just don’t populate the role members in PowerBI.com. Instead, your pass the effective user in your embed token.

Unlike using the Publish To Web feature, Full Screen mode is not available in an embedded report. You can, however, add a button on the page where you embedded the report that allows it to go full screen.

If users are just consuming a report, and you are using slicers to allow them to filter data rather than the filters pane, it’s nice to hide the filter pane. And it just takes a quick bit of JavaScript. But if you hide the filters pane and have charts where users might use the include/exclude functionality on specific data point, you will need to provide a way to reset the filters since the user can’t access the filters pane. This could be a bookmark on the report page or a button on the application page that uses the APIs to reset the filters.

As of March, you can hide visual headers on all visuals in a report in Reading View. This looks much cleaner and alleviates the issues that arise when menus at the top of one visual overlap the bottom of another. But this also means that users won’t be able to access menu options such as In-Focus Mode and Export Data. If these are important, you will want to leave your visual headers visible. If you have some pages where you would like users to export data and others where it isn’t important, consider splitting out the report so you can turn the visual headers on for one report and off for the other.

After making changes and testing your report, make sure to clear any slicer values before publishing, if you have row-level security on a field shown in a slicer and you leave values selected. The selected values will be shown to users when they view the report. For example, let’s say you have created a row-level security role that can only see Product A, but you can see everything, and you left Product A and Product B selected and deployed the report. A user who views the report next and is a member of that RLS role will see the two selected values in the slicer, even though they can’t see the data for Product B on the page. This may not be a big deal for an internal report. But now imagine this is for clients. You don’t want clients to see other clients in the list. This behavior is consistent in the Power BI web service and isn’t specific to embedding. It’s just important to remember this.

By default, a report will load the page that was shown when the user last saved it. This happens in PowerBI.com as well. In embedded solutions, the page of a report can be specified in the embedding code, essentially specifying a default page within the report when viewed through the application. If a user hits the refresh button on their browser while looking at the report, the report will be loaded to the default page rather than the page the user was last viewing.

My POC proved out that Power BI provided the functionality to add great visuals to an application page that a non-developer analyst could manage. It also helped us understand our formatting options. You can get started with Power BI embedded without having to provision the embedded node in Azure, so it’s a no/low dollar commitment to give it a try.

If you have done a Power BI embedded project, please comment and let me know what you liked and didn’t like, or if there are any ideas to which I should add a vote.

Accessibility, Microsoft Technologies, Power BI

Four Easy Things You Can Do Now To Make Your Power BI Reports More Accessible

Accessibility is often overlooked or ignored when it comes to reporting and data visualization. I think there are two reasons why:

  • We often don’t consider user scenarios with which we aren’t familiar. If we don’t know someone with color blindness/low vision/dyslexia/repetitive strain injuries, we don’t understand the difficulties they might have interacting with our reports.
  • Making accessible data viz is still quite challenging. Reporting tools aren’t very mature in this area. It gets overwhelming or disheartening when we can’t accommodate all the different accessibility scenarios with the tools we already have in place. And there aren’t a lot of good examples or design guidelines for making accessible reports.

It’s easier to build accessibility into our report designs from the beginning rather than trying to retrofit. While there aren’t many people talking about building accessible data viz, there is quite a bit of information on accessibility for web design that is applicable to data viz. The WCAG 2.0 guidelines and techniques provide several good ideas.

We should not adopt the attitude that since we can’t make our Power BI reports accessible for everyone, we should not bother making it accessible for anyone. Making reports more accessible often results in increased usability in general. Understanding that we can’t easily meet all current and future accessibility needs, we can identify which design tactics provide the greatest return on effort and start by implementing those. Here are four things that you can do today to increase the accessibility of your Power BI reports that don’t require a lot of effort.

  1. Make sure there is enough contrast between text and background colors. Check your text boxes, chart titles, axis titles, and data labels to make sure they can be easily read over your selected background color(s). Websites like http://accessible-colors.com/ can help you check your color contrast. ISO standards recommend a minimum contrast ratio of 3:1 while WCAG AA standards use 4.5:1. You can copy hex values or use a free tool like Instant Eyedropper to get the hex values of your colors into the site and check your contrast ratio. The Accessible Colors site will check your current contrast ratio and recommend similar colors that increase your contrast ratio to meet WCAG guidelines. This accommodates low vision users as well as people with aging eyes who spend all day looking at a screen. Check out the color combinations here for examples and ideas.
    lowcontrastchart
    Chart with inadequate color contrast between background and text
    AccessibleColorsOutput
    Output from Accessible Colors showing the contrast ratio from hex values entered

    BetterContrastChart
    Chart with improved color contrast between background and text
  2. Avoid using color as the only means of conveying information. Add text cues where possible. It’s very common to show KPIs with a background color or a box next to a metric that uses red/yellow/green to indicate status. Users who have difficulties seeing color need another way to understand the status of a key metric. This could mean that you use a text icon in addition to or instead of color to indicate a status. Power BI reports often include conditional formatting to change the background color or font color of items in a table to convey high/low or acceptable/unacceptable values. If that is important for your users to understand, you could add a field containing the values “high” and “low” to the table itself or to the tooltips. Tooltips are accessible to screen readers via the accessible Show Data table (Alt + Shift + F11).
    Matrix with only color used to indicate year-over-year trend
    Matrix with only color used to indicate the year-over-year sales trend

    Matrix with color and icon used to indicate year-over-year trend
    Matrix with color and icon used to indicate the year-over-year sales trend
  3. Replace unnecessary jargon and acronyms. Try to avoid causing an unnecessary learning curve just to read and understand the titles and labels of your report. This helps those with cognitive disabilities, those whose native language is not that of your report, and those who are new to the subject area your report addresses. There is a balance here – sometimes it’s good to use common industry terms and assume a certain amount of knowledge. We don’t want to oversimplify information in a report or clutter a report with information that distracts most users rather than helps them. And sometimes it’s difficult to fit long chart titles and labels in Power BI. But if you show your report to a representative of your intended audience, and they have to ask about the acronyms/abbreviations/jargon used, you have some opportunities for improvement.
  4. Add alt text to all non-decorative visuals on the page. You may not have screen reader users now, but you may in the future. It only takes a couple of minutes to add alt text to your reports starting now, rather than wait and have to complete a big project to add alt text to all your reports later (or have a user that can’t read your reports because it was decided that it’s not worth the time/cost to go back and add alt text). Alt text is an easy way to summarize the important findings in a visual when you are making a report with static data. When you have data that is periodically refreshed, you can use the alt text to describe what the chart is showing. This helps the user decide if they want to look into the accessible See Data table for more information.
    Alt Text

It’s common to assume that we don’t need to make our Power BI reports accessible when we can’t see anyone in our intended user group that has an obvious disability. Many people have struggles that are not immediately noticeable. And many of the design changes we would make for accessibility also make our reports more usable for people with conditions we don’t consider to be “real” disabilities (distracted/low attention span, aging eyes, new to the job).

Perhaps you don’t have users with low vision (or cognitive or muscular disabilities) consuming your reports today, but wouldn’t it be great if you were already prepared for them when they do begin consuming your reports, rather than being another person who has unintentionally excluded them?

If you would like to learn more about building accessible Power BI reports, please attend my session at SQLSaturday Phoenix on March 17 or SQLSaturday Colorado Springs on March 24.

Accessibility, Data Visualization, Microsoft Technologies, Power BI

Power BI Screen Reader Accessibility

I recently wrote a post on the BlueGranite blog called Improving Screen Reader Accessibility in Power BI Reports. It contains some good reasons why accessibility should be considered when it comes to usability features of any web property or data viz. And it shares several tips to make your report more accessible to screen readers and those who navigate via keyboard only. This all came about because I got the chance to work with my friend Dave Bahr, an accessibility specialist who is also blind and an advanced user of screen readers. He helped me test various features and do the screen capture you see in the video embedded in the BlueGranite blog post.  It was a very interesting and enlightening experience that provided enough content for multiple blog posts. So here’s my second blog post (the first on my Data Savvy blog) with more of what I learned from this experience.

Power BI is off to a good start with screen reader accessibility and keyboard navigation, but there are some gaps. They have added keyboard shortcuts to navigate between pages, examine the visuals on a page, and show the data in an accessible format. These features are consistent across Power BI Desktop and PowerBI.com. Keyboard shortcuts for Power BI reports

It’s also pretty cool that when the screen reader encounters a visual on the report page it announces the visual title, the chart type, and the alt text. Why does this matter? When we talk about charts on a report we tend to say something like “That sales by region bar chart is…[interesting/not showing correct data/etc.].” Now someone using a screen reader can also follow that reference. Props to the Power BI team for making that work. Based upon my testing so far, it also works on custom visuals (for the most part).

Keyboard (and screen reader) users can also access the menu options to drill down a level and expand down a level. When they do this, the accessible Show Data table changes to what is currently shown in the visual.

Power BI Show Data table at top level
Show Data table at top level
Power BI Show Data table after expanding down a level
Show Data table after expanding down a level

The data in the accessible Show Data table will render in the order it is shown in the visual, so you can control that in your design. One exception to this is when the data is rendered in a matrix rather than a table: the total in the accessible Show Data table is positioned at the top rather than the bottom where we see it visually. This is a purposeful design decision to help the user understand the total and then the breakdown of subtotals. Another good thing about the accessible Show Data tables is that tooltips are included, just like when we use the See Data feature.

Another nice feature (not sure if this is built in to JAWS or something the Power BI team added) is that if you have a report page that takes a while to load JAWS will say “Alert: Visual are loading” so it’s obvious to a blind/low vision user that they need to wait to get the full report page.

There is still a bit of work to be done to make Power BI truly accessible to screen readers. Currently, keyboard users cannot interact with visuals on the page. This means that users who do not use a mouse cannot:

  • Click a bar in a bar chart and see other charts on the page cross-filter/cross-highlight
  • Drill down on a single value within a chart
  • Select a value in a slicer
  • Click on a hyperlink in a table or text box
  • Click on an image that is linked to a bookmark or external hyperlink
  • Play or stop audio or video that requires user interaction

This seems like a tall order from a development standpoint. But there are other features that require less effort that could make a big difference in the user experience of a screen reader/keyboard user. I have logged ideas for each of these features, and I hope you will add your vote to my ideas.

  1. Currently, a keyboard user presses the Tab key to move between visuals on a page.  The order in which they arrive at visuals is arbitrary. In Power BI Desktop, it seems to be the order in which the report designer placed the visual on the page. The behavior in PowerBI.com was the same until this month. Now I’m not sure what the order is there.  Most of us design reports that guide our users through a path, with information placed in a specific order that follows their line of thinking/questioning. Keyboard users can’t easily follow the visual order we have imposed because the tab order is basically random (from their point of view). I thought I had a workaround by creating a new report page and copying the visuals over to the new report page in the desired navigation order, but that now only works in Power BI Desktop and not the web service. It would be fairly easy to expose a property in the formatting pane that allows the report designer to set the tab order. Then they could tab in the order we want a user to consume the content. In the image below, the yellow numbers are the current tab order created by Power BI and the green numbers are desired tab order.  I would like the user to consume the left side of the report from top to bottom and then consume the right side of the report from top to bottom. But currently, screen reader users get sent all over the page in an unhelpful order. Please vote here for adding Expose tab order as a property of visuals for keyboard navigation.
  2. When we add hyperlinks in tables, users can click on them to navigate to the target of the link. Users who navigate via keyboard currently cannot do this. There is no way to click on the link. The URL does show up in the accessible Show Data table, but the user has to use the keyboard to find the URL, select it, copy it, and then open a web browser and paste the URL into the address bar. It should be possible to render the URL as a link rather than just text, so a user with a screen reader could just select the link and use it to navigate to the target destination. Please vote here for Make columns containing urls have embedded hyperlink in accessible show data table.
  3. While there is an option to add alt text to each visual, that text is static. So there is no way to use alt text to provide a summary of trends in the chart without manually updating the alt text each time the data is updated. It would be great if the alt text could be populated by fields in the data model. Just like we now have a Tooltips section, we could have an Alt Text section to drag fields into. Where fields in tooltips apply to a specific data point, fields in alt text would be an aggregation over the total data used in the visual, e.g., in a chart that shows sales by month, the alt text would show total sales or last sales amount (depending on what measure was dragged in). But that would be a great start.
    Mockup of requested Alt Text section in the Fields Pane of Power BI
    Mockup of requested Alt Text section in the Fields Pane of Power BI

    The ideal feature for this would be to do something like the Englighten Data Story custom visual where you can add text and then placeholders for fields, then add the fields in the order you want them to fill the placeholders. That would be a bit more complicated, so I would gladly settle for just being able to drag fields into an Alt Text section and have it show summary numbers.  Please vote here for Allow use of field value to populate alt text.

  4. Make textboxes accessible to screen readers. Currently, the contents of a textbox can’t be read via screen reader so you must resort to copying the content to the alt text property. When a user uses the Show Data keyboard command, nothing is available for the textbox – it’s just blank. At the least, the contents of the textbox should be available in a single column/single row table via the Show Data command. Even better would be to auto-populate the alt text with the textbox contents by default. Even better than that would be to reserve the alt text for other comments and add a different property that would allow a screen reader to read out the contents of that property right after the alt text. Please vote here for Make textbox contents accessible to screen readers.

Some other interesting things I learned:

  • Many blind users have their browsers settings such that they don’t load images. It saves time in loading the page without detracting from their user experience. When browsing a Power BI report with the browser set to not load images, the screen reader still knows an image is there and announces it (“image”), even if it doesn’t appear on the screen.
  • If you use the Play Axis custom visual and allow it to interact with a another visual and then look at the accessible Show Data table for the other visual, the contents will continue to change based upon the changing of values in the Play Axis. While this is rather amusing, I’m sure it makes it difficult for screen reader users to figure out what’s going on and actually obtain information.

Power BI has an opportunity to be a leader in accessibility (of all areas, not just for screen readers). In our increasingly data-driven work cultures, people of all abilities need data. Please help the Power BI team know that accessibility should get some of their limited attention and resources by voting for my ideas or logging your own. If you log an accessibility related idea, feel free to link to it in the comments of this post or tag me on Twitter and I’ll help publicize it.