Almanac
Microsoft/power-biPower Platform

Consultant KB for Microsoft Power BI: semantic models, DAX and modelling, Power Query and dataflows, reports and visuals, the service and workspaces, capacity and performance, embedding and integration, governance and security, ALM and deployment, and licensing, plus cross-cutting decision guides. Scoped to Power BI, with Microsoft Fabric covered where it touches Power BI directly. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power BI release plans, docs repo and product blog, plus the author's own consultant notes.

feature-report-accessibility.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn

What it does

Power BI ships a set of accessibility capabilities — some automatic, some you have to configure — that let people using keyboards, screen readers and high contrast modes work with a report. Microsoft publishes a report accessibility checklist to check your work against.

Key facts

  • Built in with no configuration: keyboard navigation across all visuals, screen reader compatibility, high contrast colour view, focus mode and the accessible Show Data table.
  • Shift + ? opens the keyboard shortcut dialog. Alt + Shift + F11 opens the screen-reader-friendly data table for a visual.
  • A screen reader reads out the visual's title, its type, and any alt text you've set. Because title and type are read automatically, alt text only needs the description.
  • The Alt Text box is under Format > General for any object, and is limited to 250 characters. It supports conditional formatting, so alt text can be driven by a DAX measure.
  • Tab order is set in the Selection pane via the Tab order tab. Clicking the number next to an object removes it from the tab order — that's how you hide decorative shapes and images from screen readers.
  • Power BI Desktop detects the Windows high contrast theme automatically and applies it, and those colours follow the report on publish. The service's detection depends on the browser; you can set it manually with View > High contrast colors in Edit mode.
  • Microsoft's stated contrast target is WCAG 2.1 success criterion 1.4.3 — at least 4.5:1 between text and background.
  • Colour pairs Microsoft names as difficult to distinguish: green/red, green/brown, blue/purple, green/blue, light green/yellow, blue/grey, green/grey, green/black.
  • Turn scan mode or browse mode off when using a screen reader with Power BI. With Desktop, open the screen reader before opening the file for the best experience.
  • Exporting to PowerPoint carries alt text across; items without it get "No alt text provided".

When to use / skip

There's no skip. Public sector clients have statutory obligations, large private clients usually have internal standards, and the work is cheap if done during the build and expensive if retrofitted. The realistic position is that you can't make every report perfect, so prioritise: alt text and sort order on every visual, contrast checked once at theme level, tab order set on pages people actually navigate, and nothing important reachable only by hover. That covers most of the checklist for a fraction of the effort.

Configuration decisions

  • Whether the report theme is built to pass 4.5:1 contrast from the start, which fixes the problem once instead of per visual.
  • Whether alt text is static or conditional. Conditional is better where the insight changes with the data, but it's a measure to maintain.
  • Tab order per page, including which decorative objects are excluded.
  • Whether markers are turned on for line, area, combo, scatter and bubble visuals so series are distinguishable without colour.
  • Sort order on every visual, set deliberately — the accessible Show Data table uses the sort order you set.
  • Whether data labels are on. Microsoft's advice is to turn them off if your eye is drawn to the labels rather than the data.

Gotchas

  • Tooltips are the classic failure. Microsoft's checklist says outright not to use tooltips to convey important information, because keyboard and non-mouse users struggle to reach them.
  • Information available only through an interaction — a cross-filter, a bookmark, a hover — is inaccessible to some readers. Pre-filter the visual so the conclusion is visible instead.
  • Bookmark-based navigation frequently breaks keyboard flow. Microsoft's checklist explicitly says to navigate a bookmark-driven report with a keyboard and see whether it's acceptable.
  • Decorative shapes and images left in the tab order get announced by screen readers, one by one, before the reader reaches anything useful.
  • The 250-character alt text limit is tighter than people expect once they start writing full sentences.
  • Custom visuals vary wildly. Check the accessible Show Data table — if it doesn't carry enough information, Microsoft's own advice is to pick a different visual.
  • Play Axis and similar animated visuals must not auto-play, and the reader needs to see that a play control exists.

Consultant notes

  • Build accessibility into the theme and the page template at the start of the engagement. Retrofitting alt text across forty visuals is a miserable, unbillable afternoon.
  • Run the checklist as a formal sign-off step alongside UAT, not as an afterthought. It gives the client something concrete and it protects you.
  • The squint test and a brightness-turned-down check take two minutes and catch most contrast problems before any tooling does.
  • For public sector work, ask about the client's accessibility statement and conformance target at kick-off. It changes what "done" means and it's much cheaper to know on day one.
  • Test with an actual keyboard, tab key only, on the main pages. It's the fastest way to find the things the checklist describes abstractly.

Sticky note: recheck tab order and alt text after any page redesign — both silently go stale when visuals get added.

Was this accurate?