If you’ve been using Microsoft’s AI skills to build Power BI reports, you might have noticed that the skills you were used to are no longer there.
On 17 September 2026, Microsoft released version 0.3.17 of skills-for-fabric, merging the four separate Power BI report skills (planning, design, authoring and management) into one: the Power BI Report skill (powerbi-report-cli). (check on GitHub powerbi-report-cli here).
A quick note on naming, so there’s no confusion: Microsoft’s documentation calls it the Power BI Report skill, (check Microsoft Learn page here), while in the skill files, and in your agent, it’s named powerbi-report-cli. They’re the same skill.
Naturally, with all the time I’ve been spending on Power BI accessibility, I wanted to know what this meant for accessible report design. Had anything changed? Was accessibility still part of the instructions? And would an AI agent still pick up those instructions when building or editing a report?
I went through the skill files to find out. The good news is that the accessibility guidance is still there. The catch? Whether your agent uses it depends on what you ask it to do and how you phrase your prompt.
Let’s have a look at what changed.
Four skills became one
Before version 0.3.17, the powerbi-authoring bundle contained four separate report skills, each with its own purpose.
| Previous skill | What it did |
|---|---|
| powerbi-report-planning | Defined requirements, scope and approval for new reports |
| powerbi-report-design | Covered layout, visuals, colour, typography and accessibility |
| powerbi-report-authoring | Handled PBIR/PBIP file edits, validation and previews |
| powerbi-report-management | Managed publishing, rebinding and reports in Fabric |
Now, these four skills are four internal modes within powerbi-report-cli: planning, design, authoring, and management.
According to the v0.3.17 release notes, you no longer need to select a different skill for each phase. You describe the outcome you want, and the skill selects the appropriate mode.
That sounds much simpler. And it is, at least in terms of how you interact with the skill.
There’s also a name change to remember. If your prompts or workflows refer to one of the old skills, you’ll want to use powerbi-report-cli instead.
What does the CLI actually do?
The skill itself is a set of instructions for your AI agent. The CLI part mainly refers to powerbi-report-author, the command-line tool the agent uses to work with your report.
Rather than relying on guesswork when creating or editing Power BI files, the agent can use this tool to:
- Look up visual specifications: Find supported visuals, their fields and the exact names and permitted values of formatting properties.
- Create and validate reports: Create and edit PBIR and PBIP definitions and validate their structure after edits.
- Preview the result: Detect an available preview host (Power BI Desktop, the Power BI service or a browser), then reload the report and capture screenshots to inspect the output.
The skill also covers the Fabric side, such as publishing, downloading and updating reports, through its management mode.
All useful capabilities. However, there’s one distinction worth making before we get to accessibility.
A technically valid report isn’t necessarily an accessible report.
powerbi-report-author validates the structure of your report. Accessibility comes from the skill’s design guidance, which tells the agent to follow a WCAG checklist covering alt text, contrast and keyboard navigation before it finalizes a report. That guidance is a set of instructions, not an automated test, and most of the checks it lists, such as navigating with a keyboard or using a screen reader, still need a person. A report can pass validation and still leave some users struggling.
How the skill decides what to do
This is the part that confused me at first, so let me break it down. There are three layers, and each one makes a different decision.
Layer 1: Does the skill load at all?
Your agent only sees the skill’s short description until it decides the skill is relevant. If your prompt sounds like Power BI report work, the skill loads. Nothing about modes or accessibility has been decided yet.
Layer 2: Which mode handles your request?
Once loaded, the skill’s routing table classifies your request by intent:
| If your request is about… | It goes to… |
|---|---|
| Building a new report | Planning, then design, then authoring |
| How a report should look, or a review | Design, which then hands over to authoring |
| Changing, adding, restyling or fixing something | Authoring |
| Publishing, downloading or rebinding | Management |
Layer 3: Which reference files get read?
Each mode has its own instructions, which tell the agent which detailed guides to load.
- Design mode must produce “accessibility considerations” and points to the accessibility guide. But it can’t edit files. It always ends by handing a Design Brief to authoring.
- Authoring mode edits the files, follows the Design Brief if there is one, and must finish with validation, a preview and a screenshot review.
So, for accessibility, there are really only two paths:
Through design first: the accessibility guide is read, the decisions go into the Design Brief, and authoring builds them in.
Straight to authoring: there’s no Design Brief and no accessibility guide. The only safety net is the screenshot review.
The question isn’t “does the skill do accessibility?” It’s “did your request go through design first?”
So, what happened to accessibility?
The accessibility guidance hasn’t disappeared. I checked the files, and the content of Microsoft’s accessibility reference remains the same as before.
The guide still covers WCAG 2.1 and 2.2 considerations for dashboards, alt text, keyboard navigation, contrast requirements, colour vision deficiencies and DAX-driven alt text.
Accessibility also appears in the instructions for planning and design.
When you’re planning a new report, the last round of questions covers the report’s look and feel, accessibility and where it’s going to be delivered. You won’t be asked about accessibility directly. Instead, the skill applies sensible defaults, like WCAG AA contrast for text and alt text on every chart, and writes them into the spec.
Design mode also instructs the agent to consult the accessibility guide before finalising a report. Its guide for redesigning existing reports points to it too, though only to re-check contrast after a light/dark theme swap.
So far, so good.
The problem is how the skill decides which path to take. There are three things I think you should be aware of.
1. Accessibility is no longer mentioned in the trigger description
Previously, the description for the report design skill explicitly mentioned choosing an accessibility approach.
The new description for Power BI Report CLI doesn’t mention accessibility. It covers planning, designing, authoring, previews, publishing and report management, but accessibility only appears further down, in the routing table.
To be fair, this matters less than it sounds. For most report work, the skill will load anyway (layer 1), and the real decision happens in the routing (layer 2). But a request that’s purely about accessibility, like “Is my report accessible?”, no longer matches anything in the description, so there’s less to tell the agent that this skill is the right one for the job.
2. Restyling an existing report now falls under authoring
This is probably the change I’d pay most attention to if you’re using AI to improve reports you’ve already built.
Previously, the design skill covered redesigning and restyling existing reports. Under the new routing rules, restyling or reformatting an existing local report is classified as authoring, even if your prompt uses design language.
The distinction is between asking for design advice or a design specification, which falls under design, and asking the agent to change the report files, which falls under authoring.
It makes sense from a workflow perspective. However, it also changes which instructions the agent follows.
And this is where it gets confusing. The skill’s own redesign guide sits inside design mode and lists requests like “restyle the visuals” and “make it look professional” as its triggers. It runs the full design workflow, which includes the accessibility guide.
Microsoft’s documentation also shows “Make this report look professional” starting in design. But the main routing rule sends restyling an existing report to authoring. So the same request could take either path, depending on how the agent interprets it, and only one of those paths includes the accessibility guidance.
3. Authoring mode doesn’t reference the accessibility guide
Here’s the bit that concerns me.
I read through the authoring instructions and could not find a reference to accessibility.md. They cover pages, visuals, formatting, themes and expressions. So a request to add a visual, format a chart or restyle a page can be completed without the accessibility guidance ever being loaded.
To be fair, authoring isn’t completely blind. Every authoring task must end with a screenshot review, which asks whether text contrasts with its background and whether labels are readable. But that’s a visual check of a screenshot, not a measured contrast ratio, and it doesn’t cover alt text, tab order or whether meaning relies on colour alone. Those live in the accessibility guide, which authoring never loads.
This wasn’t a new problem introduced by the merge. The previous authoring skill didn’t reference the accessibility guide either.
The difference is that restyling requests, which used to belong to the design skill, now route to authoring, and you no longer pick which skill handles your request.
In other words, asking an AI agent to edit your report doesn’t mean it will apply the full accessibility guidance while making those changes.
How I’d prompt for accessible Power BI reports
The wording of your request can make a difference. Consider these four examples:
| Your prompt | Likely path | Accessibility guide used? |
|---|---|---|
| “Add a bar chart to page 2 showing sales by region.” | Authoring | No, screenshot review only |
| “Fix the accessibility issues in my report.” | Authoring | No, screenshot review only |
| “Review page 2 of my report for accessibility issues.” | Design | Yes |
| “Plan a new executive dashboard for our leadership team.” | Planning (stops for your approval), then design, then authoring | Yes, starting with an accessibility baseline in planning |
These examples follow the routing instructions in the skill. They aren’t a guarantee of how every agent will behave, as that can also depend on the environment and its implementation.
So, what would I do?
Review first, then fix.
If you’re working on an existing report, start by asking the agent to review its accessibility. Ask it to identify the problems before making any changes.
For example:
> Review page 2 of my Power BI report for accessibility issues. Check text and background contrast, alt text, colour use and keyboard navigation order. List your findings and recommendations before changing anything.
Once you’ve reviewed the findings, you can ask the agent to apply the fixes.
This works with the layers rather than against them. A review is clearly a request for advice, so it goes to design and the accessibility guide is read. The fixes then go to authoring with the findings already in the conversation. It also gives you a chance to understand what’s wrong before the report gets changed, and makes it easier to check whether the fixes address the actual problems.
For quick edits, spell out the accessibility requirements.
Sometimes you don’t need a full review. You just want to add a visual or adjust a page.
In that case, include the relevant requirements in your prompt:
> Add a bar chart to page 2 showing sales by region. Follow the skill’s accessibility guidance. Check text and background contrast, provide meaningful alt text where appropriate, and make sure the chart doesn’t rely on colour alone to communicate information.
You’re making the expectations explicit rather than assuming the agent will load the right guidance automatically.
If you’re creating a new report, don’t rush through planning.
The planning mode sets an accessibility baseline before the report is built. Depending on how much detail you give upfront, it either asks you about it or picks conservative accessible defaults. Either way, check what it records in the spec and establish your accessibility requirements early.
It is much easier to communicate your expectations at the beginning than to discover later that your report needs substantial changes.
And finally, check the finished report. Every time.
This is the part I wouldn’t skip, regardless of which skill or AI agent you’re using.
The instructions guide the agent, but they don’t guarantee the outcome. powerbi-report-author validates the structure of the report definition, and the screenshot review is a visual check, not an accessibility audit.
Run a dedicated accessibility check on the final report. For example, you can use PBIX A11y available at https://pbiaudits.com to audit your report for accessibility issues, or use the PBIR A11y CLI, available at https://github.com/Juls-BI/pbir-a11y, in your workflow.
That gives you another opportunity to catch problems, regardless of which path handled the changes.
Power BI Report CLI vs PBIR A11y CLI Skill
I built PBIR A11y CLI (available on GitHub pbir-a11y here). It’s a command-line version of the PBIX A11y browser tool, using the same rule engine but pointed at a PBIP project folder instead of a file upload.
It’s licensed under [PolyForm Shield 1.0.0](https://github.com/Juls-BI/pbir-a11y/blob/main/LICENSE). You’re free to use PBIR A11y CLI in your own workflows, pipelines and paid client work. The only restriction is that you can’t use it to create a product that competes with PBIX A11y or PBIR A11y CLI.
| Differences | Power BI Report CLI | PBIR A11y CLI skill |
|---|---|---|
| What triggers the skill | Report lifecycle work: “plan Power BI report”, “design report page”, “edit PBIR”, “publish report” | Creating, editing or reviewing a report definition (report.json, page.json, visual.json), or any question about Power BI accessibility, WCAG, alt text, contrast, tab order or target size |
| Does the description mention accessibility? | No | Yes, by name, with specific topics |
| When accessibility comes in | Only if the request is routed to design (or planning) | After every visual, page or theme change, and before calling a report “done”, whether or not you asked |
| What a quick edit gets | Authoring and a screenshot review | The audit straight after the change, with fixes |
The biggest difference is what triggers accessibility.
In Power BI Report CLI, accessibility depends on routing. The skill loads for report work, but the accessibility guidance only comes in if your request is classified as design. A quick edit goes straight to authoring, so accessibility depends on how you phrase the prompt.
The PBIR A11y CLI skill works the other way round. Its description is triggered by the activity itself: creating or editing a page, visual or theme, which are exactly the requests that skip Microsoft’s design mode. It’s also triggered by accessibility questions, naming WCAG, alt text, contrast, tab order and target size, which Microsoft’s description doesn’t mention at all. And once it’s loaded, it tells the agent to run the audit after every change, “rather than only when explicitly asked”. The agent fixes mechanical issues like contrast or a missing title, follows the skill’s guidance on alt text and colour, and asks you about anything that needs judgement, like what the alt text should say.
In other words, Microsoft’s skill asks “what kind of request is this?”, while mine asks “did the report just change?”
That’s why they work well side by side. When an agent edits a report, both skills match: Power BI Report CLI makes the change, the PBIR A11y CLI skill makes sure it’s accessible, and the audit checks the result.
What the Power BI product team could do
Prompting well and checking the result are good habits, but they put the responsibility on every user to remember. Ideally, an AI-built report would be accessible by default, regardless of how the prompt is phrased.
Here’s what I’d love to see from Microsoft:
1. Make accessibility a shared rule, not a design-mode extra
The skill already has shared rules that sit above the individual modes, such as its MUST, PREFER and AVOID lists. A short set of accessibility rules in the same place, such as minimum contrast, alt text on every visual, a logical tab order and not relying on colour alone, would apply to every request, including quick edits.
2. Point authoring to the accessibility guide
Authoring is where the files actually change. If it loaded at least the essentials of accessibility.md whenever it adds or formats a visual, quick edits would no longer bypass the guidance.
3. Add accessibility checks to validation
The powerbi-report-author validate command already checks the structure of the report definition after each batch of edits. Accessibility warnings, such as measured text contrast, missing alt text or a missing tab order, would make the agent fix problems in the same loop it already uses for technical errors. That’s the approach I took with PBIR A11y CLI, and it works well with agents.
4. Start from accessible defaults
New projects created with the CLI could start with an accessible theme, alt text on every visual and a set tab order, so the default build passes before anyone asks.
5. Handle “fix accessibility” requests properly
Today, “Fix the accessibility issues in my report” is a file change, so it goes to authoring without the accessibility guide. The skill could recognise accessibility fixes and run a design review first, then apply the changes.
6. Resolve the redesign conflict
Make the routing rule and the redesign guide agree, so a request like “make it look professional” always gets the design and accessibility guidance before any files change.
7. Mention accessibility in the trigger description
It’s a small change, but it would help agents recognise accessibility questions as report work and load the skill.
Until then, the responsibility sits with us.
My take
Combining four skills into one makes the workflow simpler. You describe what you want, and the skill decides how to approach the task.
But there’s a difference between an agent knowing how to edit a Power BI report and knowing how to make that report accessible.
The accessibility guidance is still available within Microsoft’s skills. The challenge is making sure your request goes through design before the files change, particularly when you’re making quick edits to an existing report.
My rule of thumb hasn’t changed: ask for accessibility, and check the result.
I’m curious to hear from others using Microsoft’s Fabric skills. Have you tried the new Power BI Report CLI skill? Have you noticed any differences in how your agent handles report design and accessibility?
Thank you for joining me on this journey. Until next time, let’s keep crafting accessible and ethical insights that make a difference
