I’ve recently decided to have a go at vibe coding, using Lovable.
After building my first application to integrate project controls reporting, I started exploring what else might be possible. Naturally, I gravitated towards a problem I’ve been talking about for years, accessibility in Power BI.
So I asked a simple question:
Could I build a lightweight tool that checks accessibility in a .pbix file?
That question became PBIX A11y.
Why This Needed to Exist
Power BI is everywhere in the enterprise, but accessibility is still not treated as a first-class concern.
In practice, the same issues keep appearing. Low-contrast colour choices that look fine on one screen but disappear on another. Fonts that become unreadable as soon as the canvas scales up. Visuals with no meaningful titles. Reports that rely entirely on colour to convey meaning.
These are not isolated cases. They are patterns.
And because they’re patterns, people often ask me during accessibility sessions whether a single tool could catch them all. That question always comes from the same place: if the problems are predictable, surely there must be a way to surface them automatically.
But that’s exactly where the gap is. The real barrier isn’t awareness, most teams already know these issues matter. The barrier is visibility. Developers don’t have a fast, reliable way to see accessibility problems as they build, so the same issues slip through release after release.
The Idea: Make Accessibility Visible
Rather than creating another checklist or guidance document, I wanted to build something practical.
A tool where you can drop in a .pbix file and immediately understand what might be excluding part of your audience.
And one requirement quickly became non-negotiable: the file should never leave your machine.
Designing For Trust
If you work in a corporate environment, you’ll know that sharing .pbix files externally is rarely allowed.
So PBIX A11y takes a different approach.
The entire analysis runs in the browser. The file is opened, interpreted, and assessed locally. Nothing is uploaded, nothing is stored, and nothing can be reconstructed elsewhere.
If results are saved, they are limited to structured findings, never the underlying report.
This isn’t just a technical decision. It’s what makes the tool usable in the real world.
What the Tool Looks For
The checks focus on the issues that consistently affect usability:
1. Contrast and Colour Safety
Contrast is assessed using WCAG standards, ensuring that text remains readable against its actual background rather than an assumed one.
I tried to run a colour blindness safety check but could not make it work properly, so I decided to build a standalone tool where you can upload a screenshot, brand palette or chart and instantly see how it appears under seven types of colour blindness. It runs entirely in the browser and helps us rethink our colour choices
2. Alt Text Presence
Alt text is reviewed for presence and usefulness, because for screen reader users this is often the difference between access and exclusion.
On the top of this check I built the Alt Text Generator. This tool identifies which visuals need alt text, ignores decorative shapes and understands the fields used in each visual.
It then asks a few clarifying questions about the purpose of the insight before generating both static WCAG aligned alt text and dynamic DAX alt text for conditional formatting. This feature is still in test though.
3. Layout Density
Another check done on the audit is layout density, to identify overcrowded pages and overlapping visuals, recognising that accessibility is also about reducing cognitive load.
4. Titles, Structure and Font Size
Titles and structure are assessed to understand whether a report provides clear orientation, and font sizes are evaluated in context, scaling expectations based on the canvas size rather than applying a fixed rule.
Individually, these checks are simple. Together, they provide a meaningful picture of how accessible a report actually is.
5. Tab Order
This is a very last minute feature! Tab order is extremely important because not all users rely on a mouse. Correct tab order ensures effective navigation and also support screen readers.
The new checker reviews the actual focus sequence of all interactive elements on the page and flags anything that breaks a logical reading order (such as visuals that can’t be reached with the keyboard, gaps or jumps in the sequence, or decorative shapes that should not be focusable but are).
Beyond the Audits
Alongside the main report audit, I’ve also built a set of standalone tools that help creators design more accessible Power BI reports:
- Cognitive Load Score
- Theme Accessibility Audit
- Minimum Font Size Calculator
- Colour Contrast Checker (Luminance and APCA methods)
- Colour Blindness Simulator
- Alt Text Generator
From Score to Action
The tool produces a score, but that’s not the point.
The score helps open the conversation. It gives stakeholders something tangible to react to.
What matters more is what sits behind it, a breakdown of findings that can be directly translated into improvements within Power BI.
Accessibility becomes less abstract. Less subjective. More actionable.
The Limits of Automation
There is an important boundary here.
Automated checks are very effective at catching mechanical issues. The kind of problems that come from defaults, formatting decisions, or time pressure.
But they cannot tell you whether your report tells a clear story. They cannot assess whether your design supports decision-making. They cannot replicate how a user navigates and interprets your content.
That still requires human judgement.
PBIX A11y is not a replacement for that. It is the first pass that makes the rest of the work more focused.
Wrap-Up
Accessibility is often framed as compliance, but that framing misses the point.
At its core, accessibility is about usability. It is about ensuring that the insight you worked hard to create can actually be understood and used by the people it is intended for. And in that sense, accessibility is not an extra layer. It is part of good design.
This application is still an evolving experiment. There are areas I want to explore further, particularly around navigation and interaction patterns,
But even in its current format, the tool does something valuable. It makes accessibility visible.
If you’re curious, you can try it here: PBIX A11y
Just drop in a .pbix file and see what comes back.
The application is currently being tested, so if you have any feedback or suggestions, please reach out, I’d really value it.
Thank you for joining me on this journey. Until next time, let’s keep crafting accessible and ethical insights that make a difference!
