An automated report is not accessible merely because its numbers are correct. The review also needs to establish whether a person can find the report, understand the visuals, reach every control, and recover the underlying data without depending on sight, color, a mouse, or a tooltip. The most useful review is a short, repeatable test performed on the same output that readers will receive.
Start with meaning, not decoration
Read the report title, section headings, visual titles, labels, and explanatory text in order. Ask whether they explain the question each visual answers. Decorative artwork should not create noise for assistive technology, while a meaningful chart or diagram needs a useful text alternative. Microsoft tells Power BI authors to add alternative text to every meaningful visual, and the W3C accessibility principles explain that non-text content such as charts, diagrams, and controls needs a text alternative. A good description states the purpose and the important result; it does not simply repeat a chart type.
Complete a keyboard-only pass
Put the mouse aside and enter the report with the keyboard. Move through navigation, filters, slicers, visuals, links, and any menus. Confirm that focus is visible, the order is logical, every interactive element can be reached, and there is a clear way to leave a control. Microsoft's Power BI report accessibility guidance specifically recommends testing keyboard navigation and configuring the tab order. Record the first unreachable item, unexpected jump, hidden focus state, or keyboard trap with the page name and control label.
Check color, contrast, and enlargement
Review the report in high-contrast mode and with enlarged browser or operating-system text. Meaning must survive those changes. A warning, exception, or series should have a label, marker, pattern, or icon in addition to color. Microsoft cautions report authors against using color as the only way to communicate information. Check that labels do not overlap or disappear and that a reader can still distinguish the selected filter state. Tooltips may add detail, but essential facts should also appear in text, labels, or an accessible table because a tooltip can be difficult to discover without precise pointing.
Inspect every table and chart alternative
For a native data table, verify that column and row headers identify the values they govern. The W3C table tutorial explains that structural markup connects header cells with data cells so assistive technology can provide context. For charts, use the product's accessible data view where available and confirm that it contains the same categories, values, units, and time periods shown visually. Microsoft's guidance identifies Show Data as an accessibility feature and recommends making sure the accessible table is useful.
Run a screen-reader spot check
Use a supported screen reader for a representative page rather than assuming labels work. Listen to the page title, navigation landmarks, filter names and states, chart alternative text, data-table headers, and link purpose. The spoken order should match the visual and task order. A label such as “button” or “visual” without purpose is a defect even if the control technically receives focus. Repeat the check after changing a filter, since dynamic states can produce stale labels or silent updates.
Review the delivery route
Accessibility can be lost after the report itself. Test the shared link, sign-in path, embed, exported file, and any email summary used by the actual audience. Confirm that error messages are announced and actionable. If the report refreshes automatically, provide a visible last-updated time and a plain-language note when data is delayed or incomplete. These are review criteria, not proof that every reporting platform implements them automatically.
Keep an evidence-based review record
For each finding, record the page, element, input method, expected behavior, observed behavior, severity, and a reproducible step. Attach a small screenshot only when it adds context; keep the written description sufficient on its own. A release can pass only when critical tasks work without a mouse, meaning is not carried by color alone, meaningful visuals have useful alternatives, table relationships are understandable, and the delivered version was tested. Automated scanners can help find patterns, but this hands-on review decides whether the report is usable in context.
Sources
- Design Power BI reports for accessibility — Microsoft Learn
- Tables Tutorial — W3C Web Accessibility Initiative
- Accessibility Principles — W3C Web Accessibility Initiative