Consuming Power BI Reports with Accessibility Features - A Practical Guide

Most conversations about accessibility in Power BI focus on the person building the report. Good colour contrast, alt text on visuals, sensible tab order, all the things a report author is supposed to do. That work matters and I am glad it gets attention. But there is a whole other side that gets far less airtime, and it is the side that affects more people day to day: how someone actually consumes a report once it is built. Reading it, navigating it, drilling into it, using a keyboard or a screen reader instead of a mouse and good eyesight.

This is not a niche concern. In any large Australian organisation, a meaningful slice of the people expected to read your dashboards will be doing it with assistive technology, and for government and government-adjacent bodies there are accessibility obligations that are not optional. Microsoft's documentation on consuming reports with accessibility features covers the tools available. Here I want to walk through what actually helps a person get value out of a report they cannot, or would rather not, drive with a mouse.

Why the consumer side gets neglected

Report authors test their work by clicking around with a mouse, because that is how they build it. So the mouse path gets polished and the keyboard and screen reader paths get whatever the platform gives them by default. The result is a report that looks accessible in a checklist sense but is genuinely awkward to use if you are tabbing through it or listening to it read out.

I have sat next to someone navigating a "compliant" dashboard with a screen reader and watched them give up on a page that a sighted mouse user would call perfectly clear. The visuals were technically labelled. The problem was the experience of moving through them in order, one element at a time, with no sense of the overall shape. Accessibility is not a box you tick. It is whether a real person can get the number they came for without a fight.

Keyboard navigation is the foundation

Everything starts with the keyboard, because keyboard access underpins most assistive technology. If a report works properly by keyboard, a lot of other things fall into place.

Power BI gives report consumers keyboard navigation across the whole report. You can move between visuals, into a visual to explore its data, through slicers and filters, and around the page without touching a mouse. Tab moves you forward through the elements, and there are shortcuts to jump into a visual, get back out to the page level, and open the menu of actions on a given visual. There is also a shortcut that brings up the full list of keyboard shortcuts while you are in a report, which is the single most useful thing to know because it means you do not have to memorise the rest.

The honest bit: the experience is decent but it rewards a report that was built with a sensible tab order. If the author never set the order, the keyboard walks through visuals in the sequence they were added to the canvas, which is often nonsensical. So as a consumer, keyboard navigation gives you the mechanism, but how pleasant it is depends heavily on choices the author made or did not make. When we build reports for clients, setting a logical tab order is one of those small things that costs ten minutes and makes the difference between a report that is usable by keyboard and one that is technically navigable but miserable.

Screen readers and what they can and cannot tell you

Power BI works with screen readers, and this is where the consumer experience gets genuinely useful when a report has been built well. As you move through the report, the screen reader announces what you have landed on: the visual's title, its type, and, when you drill into it, the underlying data. On a table or a card that works cleanly. You hear the label, you hear the value, you have what you need.

Where it gets harder is complex visuals. A dense scatter chart or a busy combo chart does not translate to audio the way a simple card does, and no amount of platform cleverness fully solves that. This is where the author's alt text earns its keep. A good alt text description gives the screen reader user the takeaway the chart is trying to convey, which a raw data readout never will. So as a consumer, your screen reader experience is partly the platform and partly whether whoever built the report bothered to describe their visuals in words. When they did, it is good. When they did not, you get a list of data points and are left to assemble the meaning yourself.

My practical advice to consumers: lean on the table and matrix visuals and the "show as table" option where you can. Tabular data reads out cleanly and predictably, and if a chart is fighting you, dropping into its underlying data as a table is often the fastest way to get what you came for.

High contrast and the display settings

Not everyone using accessibility features is using a screen reader. A lot of people just need higher contrast or larger text, and this group is much bigger than teams tend to assume. Power BI respects the operating system's high contrast settings, so if you have Windows set to a high contrast theme, reports pick that up and render accordingly rather than forcing you back into low-contrast colours.

This one works well and I wish more people knew about it. If you find dashboards hard to read, setting a high contrast mode at the OS level and letting Power BI follow it is often a bigger improvement than anything you can do inside a single report. It is a setting-and-forget change that applies across everything, not just Power BI.

The caveat, again, comes back to the author. High contrast mode strips a report back to a stark palette, and if the author leaned on colour to carry meaning, say red versus green to signal good and bad, that meaning can flatten out in high contrast. So the feature does its job, but a report that used colour as its only signal will still lose information. Colour should never be the only thing distinguishing one thing from another, and high contrast mode is exactly where that principle gets tested.

Focus mode and the small quality-of-life tools

There are a few consumer tools that are not headline accessibility features but make a real difference. Focus mode lets you expand a single visual to fill the screen, which helps enormously if you have low vision or just find a crowded dashboard hard to parse. Stripping the page down to one visual at a time removes a lot of the cognitive load of a busy canvas. The "show as table" option I mentioned earlier turns any visual into its underlying data, which is a genuine accessibility win even though it is not badged as one.

These are the sort of tools worth knowing about as a consumer because they are always available regardless of how the report was built. You do not need the author to have done anything special. That makes them reliable in a way that screen reader quality, which depends on alt text and tab order, is not.

Where this leaves an organisation

Here is the thing I want leaders to take away. Accessible consumption is not solely a feature of the platform, and it is not solely the author's responsibility either. It is the combination. Power BI provides the keyboard navigation, screen reader support and high contrast handling. The author provides the tab order, the alt text and the sensible use of colour that lets those features actually work. Get both right and a report is genuinely usable by everyone. Get only the platform half and you have a report that passes an automated check and fails a real person.

For any organisation with accessibility obligations, and that is most of the public sector and a growing number of private ones, this needs to be built into how reports are made rather than audited in at the end. Retrofitting accessibility onto a finished estate of reports is slow and expensive. Baking it into the build standard costs almost nothing per report. That standard-setting is part of what we do when we help teams get their reporting onto a solid footing, and you can read more about how we approach Power BI consulting or the broader services we offer.

If you want a hand making your reporting genuinely usable for your whole organisation, not just compliant on paper, get in touch and we will take a look at where you are and what it would take to get there. The consumer side of accessibility is the part most teams skip, and it is the part your people actually experience.