Microsoft's own guidance for report authors makes the distinction this whole page rests on, and it makes it in one sentence. The product provides the capability to create accessible reports, and it is up to the report author to incorporate that capability into their reports. Everything a platform can do for you, it has already done. Everything else is a choice somebody made in your file.
So a report audit is not an audit of Power BI. It is an audit of the decisions in one authored report, in one tested environment, with the filters and bookmarks in known positions. That is a scope somebody can agree to, and it is why the worksheet below matters more than any list of general advice.
The Two Lists Microsoft Publishes
The documentation sorts its accessibility features into three categories, and the first two are the ones that decide your scope.
| Feature | Who has to do something | What that means for an audit |
|---|---|---|
| Keyboard navigation | Nobody, it is built in | A finding here is usually the platform's rather than yours |
| Screen reader compatibility | Nobody, it is built in | Same, and worth keeping in its own pile in the report |
| High contrast colours view | Nobody, it is built in | Detected from the operating system, so test it there |
| Focus mode | Nobody, it is built in | A reader can expand a visual, which is a state to check |
| Show data table | Nobody, it is built in | Opens with Alt+Shift+F11, in the sort order the author set |
| Alt text on visuals and objects | The report author, per visual | The largest single source of findings in a report audit |
| Tab order | The report author, per page | Decorative shapes left in the order get announced as noise |
| Titles and labels | The report author | Acronyms and jargon a reader outside the team cannot decode |
| Markers | The report author, per series | Whether colour is the only difference between two lines |
| Report themes | The report author | Contrast on text, on labels and across the chart palette |
Read the bottom five rows and you have the shape of most findings before anybody opens the file. Alt text is a text box somebody either filled in or did not, capped at 250 characters. Tab order is a panel somebody either set or left in creation order. Markers are a toggle that decides whether a colour-blind reader can tell two lines apart.
The top five matter too, in a quieter way. Because keyboard navigation and screen reader compatibility come from the platform, a finding in those areas is usually a Microsoft finding rather than yours, and it belongs in a different pile of your report. That distinction is the same one our white-label and configurable SaaS page draws for products in general.
Five Details From the Documentation That Change a Test Plan
- The alt text box holds 250 characters. Which is a hard ceiling on how much a description can carry, and a good argument for the description saying what the visual shows rather than describing its shape. Our charts guide covers what belongs in that sentence.
- The accessible data table opens with Alt+Shift+F11. It shows the data in the sort order set on the visual, which means the author's sort choice is part of what a screen reader user receives.
- Screen readers cannot read report tooltip content. Microsoft states this directly, both for tooltips on a data point and for the help tooltip icon. Anything only in a tooltip is not available, and that is a scoping question rather than a subtle bug.
- Exporting to PowerPoint fills in the gaps with a placeholder. Where the author supplied no alt text, PowerPoint's default is the string "No alt text provided", which is a useful thing to search an exported deck for.
- Turn scan or browse mode off before testing. Microsoft's own advice for using Power BI with a screen reader, and a tester who skips it will report navigation problems that are really mode problems.
The Authored Report Worksheet
This is the artifact, and it is an inventory before it is a test plan. A Power BI report is not a page, it is a set of pages each holding a set of visuals, each of which can be in several states depending on what is filtered. Write the inventory first and the size of the job stops being a guess.
| What to inventory | What to record | Why it changes the scope |
|---|---|---|
| Report pages | Name, and whether it is hidden or reachable by navigation | A hidden page reached only by a bookmark is still a state somebody lands on |
| Visuals per page | Type, and whether alt text was supplied | The alt text audit is per visual, not per page |
| Custom visuals | Publisher and version | Third-party code, which the platform's built-in behaviour does not cover |
| Slicers and filters | Default state, and what changes when they move | Each meaningful combination is a different rendering to check |
| Drill-through pages | Which visual triggers them, and where focus goes | A destination page nobody reaches by tabbing is a keyboard finding |
| Bookmarks | What each one changes, and how it is triggered | Microsoft's own checklist asks whether bookmark navigation works by keyboard |
| Tooltips carrying information | Which data is only there | Not readable by a screen reader, so the information is missing rather than hidden |
| Tab order per page | Whether it was set, and what was hidden from it | Decorative shapes and images left in the order are announced as noise |
| Export routes offered | PDF, PowerPoint, Excel | Each export is a separate artifact with its own accessibility questions |
| Consumption context | Service, embedded in your app, Teams, publish to web | The surrounding page is yours in some of these and Microsoft's in others |
| Row-level security roles | Which roles see which data | Different data can mean different rendering, so agree which role is tested |
The Question Microsoft's Own Checklist Asks First
Buried in the published checklist is the best question in the whole document. Is key information only accessible through an interaction? If it is, the advice is to rearrange the visuals so the important conclusion is already obvious.
That is worth sitting with, because it is not really a technical instruction. A dashboard where the finding only appears after you hover a bar, drill into a segment and cross-filter a slicer has put the answer behind three pointer gestures. Some readers will not make all three. The accessible route is not always a better keyboard path, it is sometimes a visual that says the thing.
The same checklist asks whether the sort order on each visual was set deliberately, because that order is what the accessible data table presents. It asks whether decorative shapes and images are hidden from the tab order. And it says plainly that tooltips are for ancillary information, never for anything a reader needs.
What a Report Audit Can and Cannot Conclude
Three boundaries keep this work honest, and all three come up in real engagements.
- Microsoft's features do not prove your report conforms. The platform's capability and your file's configuration are separate facts, which is the vendor's own framing rather than ours.
- Custom visuals are third-party code. They are on your page and inside your claim, and they are not covered by the platform's built-in behaviour. If a custom visual is central to the report, name it in scope explicitly.
- An export is a different artifact. A PDF produced from a report is a document with its own tagging, reading order and alt text, and it gets evaluated as one. Our PDF accessibility guide owns that half.
There is a practical boundary too, and it is the one that delays these engagements. A report usually lives behind a workspace login, which means access has to be arranged privately before anything can be tested. Never put credentials in a public enquiry form, ours included.
One honest limit
We audit and never repair, so we will not be rebuilding your visuals or writing your alt text. What an evaluation gives you is the inventory above with findings attached, the states that were tested named alongside the ones that were not, and the platform findings kept apart from yours. Access gets arranged after scope rather than through a web form, so start at contact or read what the dashboard and data visualisation review covers.