Alt Text for Grouped Visuals in Power BI: What I Learnt from a Pull Request

It all started with a pull request for PBIR A11y CLI.

PBIR A11y CLI is the command-line version of my PBIX A11y accessibility checker. John Kerski submitted a batch of improvements, including tests for the alt text check. One of his tests showed something odd: a group containing several elements, each with its own alt text, was being flagged as missing alt text.

Interesting.

When I first designed the alt text check for the PBIX A11y website, I hadn’t tested this scenario with grouped elements. In fact, I have completely disregarded!!!

Time to investigate.

I opened Power BI Desktop, created a group and started navigating the report using the Tab key. The first thing I noticed was that Power BI focuses on the group itself before moving to the elements inside it. I also confirmed that Power BI provides a Format pane for the group, including an option to add alt text.

If you can see the screen, you probably don’t think much about this. You can see the group, the chart, the card and how they relate to each other. But what happens if you can’t see the screen and rely on a screen reader? What should a screen reader user hear when they reach a group, and what should that alt text say?

That was the question I wanted to explore, and it’s one of the reasons I appreciate contributions like John’s. A pull request made me look at something I hadn’t previously considered.

What the Guidance Says

I couldn’t find any specific Microsoft guidance on alt text for groups in Power BI. Microsoft’s accessibility guidance explains that you can add alt text to objects in a report, such as visuals and shapes, but it doesn’t say whether groups need their own alt text, what that description should contain, or how it should relate to the elements inside the group. So I looked elsewhere: at WCAG, at guidance for other tools that support grouped objects and, of course, at how Power BI itself handles groups.

The relevant WCAG requirement is Success Criterion 1.1.1, Non-text Content (Level A). It says that non-text content presented to users needs a text alternative serving an equivalent purpose, with some exceptions. One of those exceptions is purely decorative content. If something is only there for visual formatting or decoration, it should be implemented so that assistive technology can ignore it. The W3C explains why: adding unnecessary alt text can distract people using screen readers from the meaningful content on the page. That makes sense, but WCAG doesn’t tell us how to describe a group of objects in Power BI.

The W3C Images Tutorial does, however, provide guidance on groups of images, and it describes two scenarios. When several images work together to convey one piece of information, only one image needs a text alternative describing the entire collection, and the others can have empty alt attributes. The example is a star rating made up of five individual star images. Instead of describing every star, the accessible description can simply be “3.5 out of 5 stars”. When images form a collection, each image needs its own text alternative, alongside information about its relationship to the group, and the group itself is also labelled. The useful point is that the approach depends on what the objects represent. Are they working together to communicate one thing, or are they separate elements that belong together?

PowerPoint also lets you group objects, so I looked at how it handles accessibility. Microsoft’s guidance on the Reading Order pane explains that, after objects are grouped, only the group appears in the pane rather than each individual object, and you can then add a description for the group. A guide from the University of Arkansas for Medical Sciences (UAMS) recommends a similar approach for diagrams made up of multiple shapes, arrows and icons, because without grouping a screen reader might announce every component. It also highlights an important consideration: text inside grouped shapes may not be read individually once the objects are grouped, so the group’s description needs to communicate the essential information. That makes sense for PowerPoint, where the group becomes a single item in the reading order. But Power BI handles groups differently.

How Power BI Handles Groups

In Power BI’s Tab order pane, the group is listed with its elements underneath it. In my example, a donut chart showing budget spending and a card displaying the total budget, it looks like this:

• Budget Overview
  • 1.1 Budget Spending Overview
  • 1.2 Budget Card

(I renamed the group for this example. By default, Power BI would call it something like Group 1, which adds to the confusion if the alt text doesn’t explain what the group is.)

The group has its own position in the tab order, but the individual elements also keep theirs. That is where the W3C’s two scenarios come back in. A star rating works with a single description because the five stars aren’t separate things: they are one rating. A donut chart and a card are separate things that belong together. So a Power BI group is closer to the second scenario, a collection: the group needs a label, and each element still needs its own description. That’s my reading, and WCAG leaves that judgement to us.

As I found earlier, the group receives focus first. If it has no alt text, someone who can’t see the screen may have no way of knowing what the group represents or how many elements it contains. You can try this yourself. Power BI Desktop runs on Windows, so Narrator is already built in, and you can use NVDA or JAWS if you have them. Turn one on and navigate through your report. Even better, try it with your eyes closed. What does it announce when you reach the group? That is the experience we need to consider when designing accessible reports.

What I Recommend

Based on my keyboard testing and the guidance I found, this is the approach I’d recommend.

1. Give the group its own alt text. The description should explain what the group represents and what it contains, so the screen reader user has some context before they reach the elements. For example:

Budget overview. Group of two items: a donut chart showing budget spent against remaining, and a card showing the total budget.

2. Give each element its own alt text. Each meaningful element inside the group needs its own description. Ideally, use conditional formatting to make it dynamic, so it reflects changes when users interact with the report. For the donut chart:

• Donut chart of budget spending: £79.483M spent and £18.358M remaining.
• For the card: Total budget: £97.841M.

This way the user hears information about the group, followed by information about the individual elements.

3. Hide purely decorative elements from the tab order. If the group contains a background shape, a divider line or anything else that doesn’t convey information, consider hiding it from the tab order. This aligns with the WCAG exception for decorative content: there is no need to make someone using a screen reader navigate through objects that don’t add meaningful information. In this example both the donut chart and the card communicate information, so neither needs to be hidden.

Why the numbers belong in the elements, not the group. Alt text for a Power BI chart or card can be driven by a measure through conditional formatting, so the description can update when someone filters the report. The alt text box for a group doesn’t offer that option, so whatever you write there stays static. Imagine adding “Budget overview. £79.483M spent and £18.358M remaining” to the group description. That might be accurate when the report first opens, but what happens when someone changes a slicer? The numbers in the group description won’t update, and they could quickly become incorrect. That’s why I’d keep the group description focused on what the group represents and what it contains, and put the dynamic figures in the alt text of the individual elements. The group provides the context. The elements provide the detail.

One last thought: you don’t always need a group. If the only reason for grouping is to keep a visual together with decorative elements, such as a background shape or a divider line, simply hiding those elements from the tab order may be enough. Anything hidden from the tab order is skipped when navigating with the keyboard as well, so nobody has to tab through elements that add no information. You could also leave the visuals in this example ungrouped, put the total in the visual’s subtitle and give each visual its own dynamic alt text. But if you do group, this is how I’d describe it.

What Changed on PBIX A11y Website

Before this change, a group was read as an unnamed “Unknown” visual. It produced a generic “Missing alt text” failure with nothing to say it was a group, and it was counted as a visual when the score was calculated. Now a group is no longer counted as a visual in the score, although its alt text failures still lower the score, like any other alt text failure.

Now groups are recognised and named, for example Visual group “Revenue block”. That works in older .pbix files and in newer PBIP/PBIR projects, including nested groups. A group is flagged if its alt text is missing, too short, or a placeholder such as “Group 1” or “chart”, with wording written for groups and fix steps that point to the Format pane, Properties, Alt text. The visuals inside a group are still checked one by one, and their finding now says which group they sit in.

Group findings sit under the existing Alt text category, WCAG 2.2 1.1.1 Level A, so they appear in the results, totals, filters and PDF export exactly like other alt text issues.

I’ve also added a note to the results page whenever a report contains groups. It isn’t scored, and it reminds you to hide decorative elements inside a group in the Tab order pane. I can’t check that automatically, because whether an element is decorative is a judgement call. Finally, the How it works page now explains group alt text, with the donut and card example and a link to the W3C tutorial on groups of images.

Please note that I have not yet updated PBIR A11y CLI on GitHub.

Over to You

There is no specific Microsoft guidance on alt text for grouped elements in Power BI that I could find, so this is my recommendation, based on the standards, how PowerPoint handles groups and how tab order behaves in Power BI.

I’m sharing it because I want to understand whether this approach reflects the experience of people who actually use screen readers with Power BI.

If you use a screen reader with Power BI reports, I’d love to hear from you.

What do you hear when you reach a group? Does the group description help? Would you approach grouped elements differently?

And if you’ve got a better way of handling this, please share it. That’s how we learn.

Thanks again to John Kerski for the pull request that started this investigation.

Thank you for joining me on this journey. Until next time, let’s keep crafting accessible and ethical insights that make a difference

References

• Design Power BI reports for accessibility, Microsoft Learn
• Understanding Success Criterion 1.1.1: Non-text Content, W3C
• Groups of Images, W3C Web Accessibility Initiative
• Make slides easier to read by using the Reading Order pane, Microsoft Support
• Grouping PowerPoint Elements for a Single Alt Text, University of Arkansas for Medical Sciences