WCAG AA Accessibility Checklist for Power BI Reports

Most Power BI developers who think about accessibility assume there is a built-in tool they can run. There is not. Power BI Desktop has no accessibility checker.

That absence is the first problem. Without automated tooling, contrast failures ship undetected, alt text goes missing, tab order is never verified. The developers who do think about accessibility are working from documentation and manual testing because the platform gives them nothing else.

This checklist covers what WCAG AA compliance actually requires in a Power BI report and how to verify each criterion before you publish. It follows the principle from the Layout Best Practices guide: accessibility is not finishing work. It is a design constraint you apply throughout the build.

Why WCAG Applies to Power BI Reports

WCAG (Web Content Accessibility Guidelines) is the international standard for web content accessibility, maintained by the W3C. Power BI reports published to the Power BI service or embedded in web applications are web content. WCAG applies.

In enterprise environments, Power BI reports delivered as part of a contract often carry an explicit accessibility requirement: Section 508 in US federal government contexts, EN 301 549 in EU procurement, and WCAG AA as the general baseline referenced by both. Even where there is no legal requirement, building accessible reports is the right default. Around 1 in 12 men have some form of color vision deficiency; a much larger proportion navigate using keyboard shortcuts or assistive technology at some point in their workflow.

The relevant WCAG level for most Power BI contexts is AA. Level AAA adds stricter contrast ratios and additional criteria that are not always achievable within Power BI's rendering constraints. AA is the practical target.

The Missing Baseline: Power BI Has No Accessibility Checker

Power BI Desktop does not have a built-in accessibility checker. There is no menu scan, no automated contrast audit, no flagging of missing alt text. You either check manually or you ship blind.

This is the gap that makes WCAG compliance difficult in practice. Every other platform on this checklist (web browsers, Office, iOS, Android) ships with accessibility tooling baked in. Power BI does not. The developer who wants to ship an accessible report has to build their own verification workflow.

This checklist is that workflow. Work through each section before you publish.

Checklist: WCAG AA for Power BI Reports

1. Color Contrast: Text (WCAG 1.4.3)

Requirement: Normal text (under 18pt regular / 14pt bold) must achieve 4.5:1 contrast against its background. Large text requires 3:1.

In Power BI, this means:

• Data labels against visual backgrounds
• Axis labels against the canvas or visual background
• Card visual values against their background
• Table and matrix cell text against cell backgrounds
• Tooltip text against tooltip background

How to verify: Theme Studio in Draft BI checks contrast across your entire theme at once. It shows the exact ratio for each failing pair alongside the requirement (for example, 2.85:1 when the minimum is 4.5:1), with fixes that adjust the color while preserving its hue. You can also check individual pairs manually with the WebAIM Contrast Checker, though for a full theme with dozens of color combinations, doing them one at a time adds up fast.

Do not estimate by eye. The difference between a ratio of 4.4:1 (fails) and 4.5:1 (passes) is not visible.

The most common failure: Light gray axis labels on a white background. This pattern is everywhere in Power BI reports that aim for a clean aesthetic. The gray that reads as subtle and professional may fail contrast entirely. #999999 on #FFFFFF is a 2.85:1 ratio, well below the 4.5:1 minimum.

2. Non-text Contrast: Graphical Elements (WCAG 1.4.11)

Requirement: Visual elements that convey information (chart bars, line segments, data point markers, icons) must achieve 3:1 contrast against adjacent colors.

In Power BI: This applies to every data color in your theme when that color encodes meaning. A light blue bar against a white background, a thin gray line in a line chart, a data point dot in a scatter chart.

How to verify: Check each data color against the visual background color using the same contrast tools. Pay particular attention to secondary and tertiary data colors in your theme. First and second colors usually get attention; colors three through eight often do not.

3. Alt Text: Every Visual (WCAG 1.1.1)

Requirement: Every non-decorative visual must have text describing the information it conveys.

In Power BI: Format > General > Alt text on every visual. Power BI Desktop also supports dynamic alt text via a DAX measure reference, which lets alt text update based on the current filter context. For reports where the primary KPI values change significantly with slicers, this is worth implementing.

What makes alt text fail despite being present:

• "Sales chart" describes the visual type, not the information. Fails.
• "Bar chart showing revenue" is marginally better. Still fails. What does it show about revenue?
• "Bar chart showing monthly revenue by region for FY2025. Northeast leads at $42M; Southwest shows highest YoY growth at 18%." This is descriptive alt text.

The pattern: state the chart type, state what is being measured, state the key insight a sighted user would take from the visual. Screen reader users deserve the same insight, not a formal label.

Decorative shapes and background images that convey no information should be given empty alt text so screen readers skip them.

4. Tab Order and Keyboard Navigation (WCAG 2.1.1, 2.4.3)

Requirement: All report functionality must be operable via keyboard alone. The tab order through interactive elements must follow a logical sequence, typically reading order: left to right, top to bottom.

In Power BI: Tab order is set in the Selection pane. Open the Selection pane and use the drag handles to reorder elements. The order in the pane (top to bottom) determines tab order.

Verify by actually tabbing through the report in the published Power BI service. What you see in Desktop and what a keyboard user experiences in the service can differ. Publish to a test workspace and tab through every interactive element on every page before signing off.

A logical tab order for a typical report page:

1. Page-level navigation elements (if present)
2. Filter slicers, left to right
3. Primary KPI cards, left to right
4. Supporting charts, in reading order
5. Detail tables
6. Buttons or drill-through links

Elements that are purely visual and non-interactive (background rectangles, decorative lines, static text headers) should be placed below all interactive elements in the Selection pane tab order, or removed from tab order entirely by unchecking the tab stop option in the Selection pane.

5. Color-Only Encoding (WCAG 1.4.1)

Requirement: Color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

This is the criterion most commonly violated in Power BI reports, and the one most likely to be invisible to sighted developers.

Where it commonly fails:

• Line charts with multiple series. If the only way to identify each line is by color, users with color vision deficiency cannot distinguish them. Fix: add data labels at line ends, use different line styles (solid, dashed, dotted), or annotate directly on the chart.
• Red/green conditional formatting. The most ubiquitous example in BI work. A user with deuteranopia sees both colors as similar shades of yellow-brown. Fix: add an icon column (up/down arrow, checkmark/X) that carries the same meaning as the color, or include a text label (Favorable/Unfavorable) alongside the conditional format.
• Legend-only identification. A donut chart where slices are distinguished only by fill color. Fix: add data labels that include the category name.

The test: print the report page to PDF in grayscale. If you cannot derive the same information from the grayscale version as from the color version, you have a color-only encoding failure somewhere on that page.

6. Visual Titles (WCAG 2.4.6)

Requirement: Descriptive labels that help users understand and navigate content.

Every chart and table should have a title that is visible and describes what the visual shows. "Revenue" is a label. "Monthly Revenue by Region, FY2025" is a title.

Hidden titles are a Power BI-specific failure pattern. Developers often hide visual titles to create a cleaner layout, then provide context through surrounding elements. Screen readers cannot infer that context from nearby shapes or text boxes.

If a visual's title is visually redundant because a surrounding header covers it, use a visually hidden title rather than removing it: set the title font size to the minimum value and match the title color to the background. This preserves it for screen readers without cluttering the visual. Power BI does not support the CSS visually-hidden pattern directly. This workaround is the available alternative.

7. Slicer and Filter Accessibility

Slicers are interactive elements and must be keyboard-operable and properly labeled.

Check each slicer:

• Has a visible title describing what is being filtered (not just a raw field name like CalendarYear)
• Is operable via keyboard (tab to reach it, arrow keys to interact within it)
• Does not rely on color alone to indicate selection state

Dropdown slicers are generally more accessible than tile/button slicers because their native rendering is closer to a standard HTML select element. Test tile slicers in the published service with keyboard-only navigation. The experience varies by slicer type.

8. Tooltip Accessibility

Tooltips are triggered by hover and are therefore not accessible to keyboard-only users by default.

Any information available exclusively in a tooltip must also be available another way. If a tooltip shows supplemental context (a note, a definition, a data breakout), that information needs to be reachable without the tooltip.

Options:

• Surface the key tooltip data in a detail section that appears on click or selection
• Include the information in the main visual's data labels
• Accept that the tooltip content is supplemental and confirm the report functions fully without it

Fully accessible Power BI tooltips are a platform limitation. Work with it by treating tooltips as enhancement, not as a primary information channel.

9. Dynamic Visibility and Bookmarks

If your report uses bookmarks, buttons, or page navigation to switch views, each state must be accessible independently:

• Buttons that toggle visibility must have descriptive labels that reflect their current state. A button that shows "Show Detail" when the panel is hidden needs a different label when the panel is visible.
• Bookmark transitions that hide and show visuals change what is available to screen readers. Test these in the published service, not just in Desktop.
• Drill-through buttons must be labeled with the destination context, not just "Drill through."

Pre-Publish Accessibility Sign-Off

Before publishing to a production workspace, run through these seven checks:

1. Run Theme Studio's contrast check and resolve every flagged issue before touching anything else.
2. Verify contrast for every text element and data color — Theme Studio covers your theme colors; spot-check any colors applied outside the theme.
3. Review alt text on every visual for descriptive quality, not just presence.
4. Tab through every interactive element in the published service.
5. Identify every place color encodes meaning and confirm a non-color backup exists.
6. Confirm every visual has a visible, descriptive title.
7. Verify that conditional formatting does not rely on color alone.

Set aside thirty minutes the first time you run this on an existing report. After it is part of the build habit, it takes closer to ten minutes per report.

Closing the Gap Without Built-in Tooling

Because Power BI ships no accessibility tooling, closing the gap is a manual discipline. The developers who do it well test their reports the way a keyboard user would experience them, not as the person who built it. Tab through the report. Read the alt text without looking at the visual. Print it in grayscale. The failures become visible quickly.

Accessibility is not an extra pass at the end of the build cycle. It is a set of constraints that belong in the design phase, before the layout is frozen and the conditional formatting is configured. Retrofitting accessible reports is harder and less complete than designing for it from the start.

If you want to check whether an existing report meets these criteria without a full manual audit, Draft BI's Design Assessment scores your report layout against accessibility and readability best practices, then surfaces specific areas to improve with page-level detail. Try it free.

Tony Thomas

Founder of Draft BI, building the design-first companion for Power BI report development. Writing about PBIR, WCAG accessibility, DAX measures, and the workflows that help Power BI developers and analysts deliver better reports faster.