The March 2019 release of Power BI Desktop has brought us keyboard accessible visual interactions. One of Power BI’s natural strengths is that you can click on a data point within a visual and have it cross-highlight or cross-filter the other visuals on a page. But keyboard-only users weren’t able to use this feature until now. This greatly raises the accessibility of the Power BI report consumption experience.
Below is a demonstration of interacting with a visual using keyboard commands. Notice how I can select specific data points within the line chart, and the other charts on the page filter based upon the selection.
If you are a person that prefers to use a keyboard over a mouse, this might also be something you want to try. Relevant keyboard commands include:
Ctrl + right arrow: Move focus into the chart area of the visual
Tab or Arrow keys: navigate between data points (or legend items in a chart that contains a legend)
Enter or Space: select a data point within a visual
Ctrl + Enter or Ctrl + Space: select multiple data points within a visual
Ctrl + shift + c: clear all selections
I think this was the last big missing piece of keyboard accessibility. I’m excited to see its impact on users. If you try keyboard accessible visual interactions, or are taking advantage of keyboard accessibility in Power BI in general, please let me know how you are liking it. Tweet me at @mmarie or send me a note via my blog contact form.
Like a diamond in the sky. How I wonder what you are! Twinkle, twinkle, little star, Twinkle, twinkle, little star, Up above the world so high, How I wonder what you are!
You were probably expecting a different order. Order is an important element when singing a song or telling a story or explaining information.
In western cultures we tend to read left to right, top to bottom, making a Z-pattern. This applies to books and blogs as well as reports and data visualizations. But if you are using the keyboard to navigate in a Power BI report, the order in which you arrive at visuals will not follow your vision unless you set the new tab order property. If you have low or no vision, this becomes an even bigger issue because you may not be able to see that you are navigating visuals out of visual order because the screen reader just reads whatever comes next.
It takes effort to consume each visual, and many visuals need the context of the other visuals around them to be most useful. When we present information out of order, we are putting more cognitive load on our users, forcing them to hold information in their limited working memory until they arrive at another visual that helps put the pieces together to make sense.
What is Tab Order?
Tab order is the order in which users interact with the items on a page using the keyboard. Generally, we want tab order to be predictable and to closely match the visual order on the page (unless there is a good reason to deviate). If you press the tab key in a Power BI report, you might be surprised at the seemingly random order in which you move from visual to visual on the page. The default order is the order in which the visuals were placed on the page in Power BI Desktop, or the last modified order in PowerBI.com if you have edited your report there.
To set the tab order of visuals on a report page in Power BI Desktop, go to the View tab, open the Selection Pane and select Tab Order at the top of the Selection Pane.
From there, you can move visuals up and down in order, or hide them from tab order completely. This is helpful if you have decorative items on the page whose selection has no value to the user.
To change the tab order, you can either drag an item to a new position in the list, or you can select the item and click the up or down arrows above the list.
In case you missed it, slicers are now keyboard accessible. If you would like users to select values in slicers before using the other visuals on the page, make sure to put the slicers early in the tab order.
It only takes a minute to set the tab order, but it greatly increases usability for keyboard users.
It’s hard to please everyone, especially when everyone means several dozen speakers and thousands of audience members at a tech conference. And especially when it comes to presentations to an international audience. So I get that it can be difficult to make a presentation template that stays on brand and promotes the best presentation of information. But I see a continuing trend that conferences optimize templates for marketing and forget that we are trying to communicate to audiences of varying skills and abilities, many of whom have paid to attend the conference to learn the information in our presentations. I’m not here just to argue aesthetics, although I definitely have opinions on that. I want people to realize that we are unintentionally excluding many of our audience members with our horribly inaccessible slide templates. Accessibility refers to the ability for everyone, regardless of disability or special needs, to access, use, and benefit from everything within their environment. Yes, in many cases use of the conference template is not required, but many speakers will still use it. So the designer of the slide template should be thoughtful about their design more than just staying on brand with colors and conference logos. Basically, we can do better. We should be designing with accessibility in mind.
I’m going to pick on a template that I’m currently working with because it is from a conference that is near and dear to my heart, and it serves as a good example of how we can (and should) improve. Concrete examples seem to have more impact than just providing guidelines. While this year’s PASS Summit template is not the worst conference presentation template I’ve seen, it leaves a lot to be desired in the areas of effectiveness and inclusiveness. I’m writing this publicly to help educate our SQL Family about making better presentations that actually work for our audience. While it is criticism, it is said with love and hope that we can improve for future conferences. The speakers and organizers of PASS Summit are good people who strive to deliver a great conference. I know we can do better.
So what’s wrong with the template?
Let’s start with the title slide.
The title text is 36pt Segoe UI Light, the subheading text is 24pt Segoe UI, and the speaker info text is 14 pt Segoe UI.
Those font sizes alone make it very hard to read from the back of even the smaller rooms at the conference.
In addition to being too small, the gray text for the speaker info doesn’t have enough contrast from the white background. We want to get a contrast ratio of at least 4.5:1 (but 7:1 would be better). The contrast ratio for these colors is 4.0.
While sans serif fonts are generally thought to be easier to read in presentations, it’s better to use fonts with a stroke width that is not too thin – not necessarily wider characters, but thicker lines that make up each letter. So Segoe UI Light would not be my first choice for a title font, but Segoe UI or Segoe UI Bold might be ok.
Also, the red used on the right half of the slide is VERY bright for an element that is purely decorative, to the point that it might be distracting for some people. And the reason we need to squish our title into two lines of too-small text is because that giant red shape takes up half the page. What is more important: a “pretty” red shape to make our slide look snazzy or being able to clearly read the title of the presentation?
Here is the speaker bio slide.
This slide also suffers from the font being way too small.
Speaker name: 32pt (Segoe UI Light)
Title/Company: 20 pt (Segoe UI)
Social media handles: 11pt (Segoe UI)
Biography Point One: 14pt (Segoe UI)
Biography Point body text: 10.5pt (Segoe UI)
Again, there are issues with color contrast, which make the slide difficult to read – especially when shown on a projector that will probably wash out some of the color. The blue font on white background has a contrast ratio of 2.2. The red font on white background has a contrast ratio of 3.67. The dark font color on light gray background is actually ok from a color contrast perspective.
Here is a standard content slide.
What I appreciate about this slide is that it is free from unnecessary decorative shapes/backgrounds and doesn’t use needless bullet points everywhere. And the PASS logo is small in the lower right hand corner, not taking up too much room or being super distracting. But again, font sizes are way too small and the color contrast from the background is not high enough.
The difference in heading styles is a bit distracting. While they should probably differ in size, they don’t need to also differ in capitalization and font and color and boldness. One or two properties would be fine to denote difference, and having so many differences is a bit distracting.
More important than that, if you have three layers of headings on your slide, you probably have too much text. It would have been better not to even suggest that we would need to do such a thing. Putting it in the template passively gives presenters permission or encouragement to do just that.
What’s wrong and why should you care?
Conferences need to consider that some attendees may have varying abilities to see, hear, and understand the presentations. But those attendees paid to attend the conference and shall we say… connect, share, and learn? How can they learn when they can’t read the slide? How can they connect when the speaker contact information is tiny and hard to distinguish from the background? When we use slide templates that don’t work for those attendees, we are basically saying that they don’t matter and aren’t our “real” audience. Do we really want to be just another conference that discriminates against these people and makes them feel unwelcome? No one is purposefully doing this, but our ignorance/thoughtlessness about accessibility still creates that experience for them, whether or not we meant to do so.
Attendees don’t have to have a diagnosed “official” disability to benefit from slides that present information clearly. How many of us just have aging eyes? We can all appreciate when we end up seated at the back of a large conference room and can actually read the slides. Non-native English speakers may appreciate being able to clearly and quickly read slide content as they have to take more time/effort to process information written in English. We all get distracted by our phone/laptop/tablet/watch/neighbor during conference sessions, and it’s nice to be able to refocus on the presentation by focusing on the visual content while we listen to the speaker. But we can’t do that when the speaker’s slides are distracting us from the good information or are just plain hard to read. Slide templates are just one part of the presentation, but they can help set a standard that provides a good, inclusive experience for all attendees.
And what’s going to be better marketing for a conference: slide templates that are hard to read but use the right colors and logos, or attendees that have a great experience and learn a ton and tell their friends and coworkers all about it?
How do we fix it?
There are several basic things we can do to fix our templates to make them more accessible and more engaging (and still on brand for the conference). Here is a (non-comprehensive) list that organizations that create conference slide templates could start with to create accessible templates.
Even better, don’t require/request use of a slide template. Just give speakers a few intro/exit slides with necessary information and let them do what is best to communicate their intended information. It would then be the speaker’s responsibility to create accessible content, but hopefully they care enough about their presentations to do that. PASS Summit requires the use of the title and speaker bio slides (and a few other conference-related slides), but it allows speakers to design their own slides for the rest of the content.
If you have tips or opinions about creating accessible presentation content for conferences, please leave them in the comments.
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.
Last Updated: 13-Mar-2019
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.
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.
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.
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.
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.
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.
Avoid video that automatically starts when the page is rendered.
Ensure your video has captions or provide a transcript.
Avoid audio that automatically starts when the page is rendered.
Provide a transcript for any audio.
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.
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.
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 (mark the item as hidden) on any decorative items.
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.
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.
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).
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.