How to Design Accessible Power BI Reports That Everyone Can Actually Read

Here is an uncomfortable fact that most report authors never have to confront. Roughly one in five people has some form of disability, and a big chunk of those affect exactly the things a Power BI report leans on: seeing colour, reading small text, using a mouse to hover over a data point. If you build reports for a government department, a bank, a university, or any large Australian employer, some of the people opening your report cannot use it the way you assumed they would. They are tabbing through with a keyboard, or listening to a screen reader, or they physically cannot tell your red bar from your green one.

For a lot of organisations this is not just a nice-to-have either. Government reporting has accessibility obligations. Large enterprises have policies. And the Disability Discrimination Act means "our dashboard doesn't work for people who can't see colour" is not a great position to be defending. The good news is that Power BI has a solid set of accessibility features built in, and most of the work is habit rather than heroics. Microsoft's guide to designing accessible reports is the reference. This is what actually matters in practice and where teams trip up.

Do not rely on colour to carry meaning

This is the single most common accessibility failure, and it is everywhere. A report uses red for "bad" and green for "good", and that is the only signal. If you cannot distinguish red from green, and around one in twelve men cannot, that report tells you nothing. The colour is the entire message and the message is invisible to you.

The fix is not to stop using colour. It is to never let colour be the only thing carrying the meaning. Add a data label, an icon, a shape, a bit of text. A KPI that is red and also has a down arrow and the word "below target" works for everyone. A conditional-formatting traffic-light column that also shows the number works for everyone. Colour becomes reinforcement rather than the sole channel. The quick test: imagine the whole report in greyscale. If you can still read what is good and what is bad, you are fine. If it turns into a grey blur of identical bars, you have a problem, and it is a problem for real people, not just an audit checkbox.

While you are thinking about colour, check contrast. Pale grey text on a white background looks elegant in a design mockup and is genuinely hard to read for anyone with low vision, or honestly for anyone reading on a laptop in a bright meeting room. The target is a contrast ratio of at least 4.5 to 1 between text and its background. There are free contrast checkers online. Run your theme through one once and you will catch the washed-out combinations that slip past on a nice monitor and fall apart on a projector.

Build it so the keyboard works

Plenty of people do not use a mouse. Some use a keyboard exclusively, some use assistive devices that emulate one. If your report only makes sense when you hover, and all the good information is hidden in tooltips that only appear on mouseover, keyboard users get a fraction of it.

Power BI reports are keyboard navigable out of the box. A user can tab between visuals, press Enter to drill in, use arrow keys inside a visual. The thing you control, and the thing that gets ignored, is tab order. By default the tab order follows the order visuals were added to the page, which after a few rounds of editing is usually nonsense: it jumps from the title to a slicer in the corner to a chart at the bottom to a card at the top. A keyboard user tabbing through experiences your report as a random walk.

In the Selection pane you can set the tab order explicitly, so it flows the way a person would actually read the page: title, then filters, then the main visuals top to bottom, left to right. It takes two minutes per page and it is the difference between a report that is usable without a mouse and one that is technically navigable but practically bewildering. While you are in there, hide the purely decorative shapes and background elements from the tab order so keyboard users are not tabbing through six rectangles that mean nothing.

Make it work for screen readers

Screen readers read out what is on screen. For them to say anything useful about your report, the report has to contain useful text. This comes down to a few things you set and most people skip.

Give every visual a meaningful title and, where it helps, alt text. Power BI reads the title and the alt text to screen reader users, so "Chart" tells them nothing while "Monthly revenue by region, trending up since March" tells them what they are looking at without needing to see it. Alt text supports dynamic values too, so you can build a sentence that reflects the actual numbers. That is powerful and worth the effort for the key visuals on a page, though you do not need to write an essay for every decorative element.

Text matters more than you think here. Screen readers handle real text boxes beautifully and handle text baked into an image not at all. So if your report title or your explanatory notes are inside a graphic, they are silent to a screen reader. Keep text as text. This also helps translation, search, and copy-paste, so it is good practice regardless.

One honest caveat: screen reader support in Power BI is good and has improved a lot, but it is not flawless, and complex custom visuals in particular can be a black hole where the screen reader just says "visual" and stops. If accessibility is a hard requirement, favour the standard visuals, which Microsoft has actually tested with assistive technology, over a fancy third-party custom visual that might announce nothing. This is one of those places where the boring choice is the correct one.

Use the accessible-by-default features

A few features do a lot of quiet work. Themes let you set an accessible colour palette once and apply it everywhere, so you are not eyeballing contrast on every new report. There are colourblind-friendly palettes that keep categories distinguishable across the common types of colour vision deficiency, and starting from one of those is easier than fixing a report after the fact.

Report page names get read out, so name them something meaningful rather than leaving "Page 1", "Page 2". Turn on the "Show items with no data" thoughtfully, keep visuals from overlapping because overlap confuses the reading order, and prefer built-in visuals for the reasons above. None of this is heavy lifting. It is a set of small defaults that, taken together, mean your reports are accessible without a special project to make them so.

The mistake is leaving it to the end

The pattern I see over and over: a report gets built, it gets signed off, it gets rolled out, and then someone in the accessibility or compliance team flags that it fails a check. Now you are retrofitting accessibility onto a finished report, which means reworking colour schemes people have gotten used to, rebuilding tab orders, and re-explaining why the pretty pale-grey theme has to go. It is slower, it is more painful, and it makes accessibility feel like a tax imposed at the end rather than a normal part of building something well.

The teams that do this well bake it into the template. Their standard theme already passes contrast. Their build checklist already includes "set tab order" and "add alt text to key visuals" and "check it in greyscale". It stops being a special effort because it is just how reports get made. That shift, from a final audit to a built-in habit, is the whole game, and it is a big part of how we approach report design in our Power BI consulting work.

There is also a nice side effect worth naming. Almost everything that makes a report accessible makes it better for everyone. Clear titles, good contrast, sensible reading order, meaning that does not depend on one narrow channel: those help the fully-sighted mouse user reading on a bad projector in a rushed meeting just as much as they help someone using a screen reader. Accessible design is mostly just good design with the excuses removed.

If you are building reporting for a government body, a regulated business, or any large organisation with accessibility obligations, and you want it to hold up rather than fail an audit later, that is exactly the kind of work we do as part of a broader business intelligence practice. Happy to have a chat about getting accessibility into your report standards so it stops being a scramble at the end.