Some basics
Ensure that the data message in a visual is accessible in 3 ways: chart, table, sentence.
We want to ensure that all users can learn and interact with data. Often one visual may be great for some users, but inaccessible for others.
The best case scenario here is to have a text-based equivalent of every data visual. This text summarizes and explains the visual and key findings. Learn more about the importance of defining key findings.
At the minimum, include a table of the summarized data on your dashboard below the figure(s). Test your tables with your keyboard and a screen reader. Find some examples of tables in our gallery.
Choose data visualizations that are familiar to viewers.
In general, beware of overly complicated graphs. The increase in cognitive load for users trying to decipher a new type of visual may not be worth it.
Test your visuals to ensure everything is large enough to view and click. Tiny shapes or widgets are difficult to click.
Aim to use vetted, widely-used visuals. Smaller, homegrown, custom visuals may not be reliable enough for public reporting (or may require additional purchase).
For more guidance, check out these tools:
Maps are particularly challenging and should be tested for accessibility and color contrast.
The only exception to this rule is for choropleth maps. For choropleth maps, the Mapbox mapping visual is the best option in Power BI, though it does come with specific challenges. The Power BI template includes several examples and several important specifications for these maps.
Do not put text or explanatory content within the dashboard where it cannot be translated.
Your dashboard should contain data visualizations and any necessary supporting widgets (like filters or slicers). All other supporting content, like explanatory information or data notes, should be embedded into the webpage directly. It should not be inside your dashboard where it is harder for translations and screen readers to access.
The only text that may be included on the dashboard is the name of the publisher “City and County of San Francisco” and information on the refresh date or schedule.
Curate the tab order to provide intentional experience for screen readers.
The tab order is the order that visuals are highlighted for keyboard users and screen readers. Make sure figures are read in the same order a sighted user would read the figures.
Filters must be before the visuals they impact in the tab order.
Make sure any decorative shapes or images are marked as hidden in tab order, so they aren't announced by a screen reader.
Ensure the keyboard focus indicator is easily visible.
This allows those using a keyboard to know where their cursor is and which visual is selected. Learn more about keyboard focus indicators.
Minimize use of decorative images and shapes.
Avoid using too many decorative shapes to the point where they are distracting.
Test your dashboard with a screen reader as you develop the dashboard.
Ensure that you can navigate and get all key information using a screen reader. Ensure the alt text reads any keyboard instructions needed to access the visual or data.
When embedding Power BI dashboards onto SF.gov, the keyboard instructions appear automatically when a user tabs through the website.
Some of the most popular screen readers:
Test for low vision.
Test with the Windows Magnifier to see how your dashboard will be viewed by users using a magnifier tool.
Translate your dashboard.
Best practice is to ensure that dashboards are translated at the same time a user selects the language of the page.
Last updated