During the City’s COVID Response, a team of analysts built over 40 public dashboards. Getting all the dashboards published in only a few months was a huge feat. However, user testing of the dashboards with residents uncovered serious gaps.

• Residents complained of poorly sized dashboards when accessing via mobile phones.

• Some of the visuals were so complicated, users felt overwhelmed or frustrated.

• Most troubling, the dashboards were not accessible at all to residents who used a screen reader or a keyboard to navigate.

This is how someone using a screen reader experienced our dashboards.

All of this meant pain for our users, in an already incredibly painful and scary time for the City.

After much research and working with experts, we implemented changes that resulted in simpler, more accessible, and mobile friendly dashboards. Here is the same dashboard with the results of our changes.

There is more work to be done. Nonetheless, this guidance and our learnings have helped us come a long way. By sharing this guidance and template, we hope you are able to avoid our mistakes to make more clear and easy-to-use visuals.

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:

• https://www.data-to-viz.com/

• https://datavizproject.com/

Maps are particularly challenging and should be tested for accessibility and color contrast.

• Power BI tip: For point maps, feel free to use Power BI’s Bing map - but ensure the color of your points contrasts sufficiently with the light grey background. Using the dark blue is best.

• Power BI tip: Visuals change often. In Power BI, we recommend using the built-in visuals. Custom visuals are less reliable and often lack robust accessibility features and are not appropriate for publication.

  • 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:

• NVDA

• JAWS

• VoiceOver (for Mac)

• Microsoft Narrator

• ChromeVox (plugin for Google Chrome)

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.

Report authors should add alt text to every object that conveys meaningful information on a report. Most visualization programs like and Tableau have the ability to add custom alt text to dashboard elements.

Add alt text to all non-decorative visuals on the page.

Alt text should include information about the insight that you'd like the report consumer to take away from a visual.

If you used any images or shapes to call out data points, use alt text to explain what is being called out.

Before writing alt text, test your dashboard with a screen reader to find out what is read automatically.

In Power BI: screen readers read out the title and type of a visual, so developers just need to add a description and keyboard instructions.

Alt text must follow this formula (we use Amy Cesal’s method ).

• "Chart type" + showing + “what’s it showing”. +

• Where “purpose of looking at chart”. +

• "Keyboard instructions", like “Press control + right arrow to enter the chart. Press enter to read specific data points. Use escape to exit the visual.”

Avoid using explicitly spatial language like "higher bars" or “darker colors”. Use “higher values” or “higher case rates” instead.

Example: A bar chart of San Francisco COVID-19 cases by sexual orientation. Higher values show more cases associated with a specific orientation. Press control + right arrow keys to enter the chart. Press Enter key to select data. Escape to exit the visual.

Use to ensure the text is less than 5th grade.

When helpful, use conditional, dynamic alt text so that any key data values are read aloud for users.

Make Alt Text dynamic (connected to the data) where helpful.

Dynamic alt text ensures that screen readers have easy access to key information.

Be careful with dynamic alt text when there is a filter on the page. With a filter, you will want to test the dashboard and ensure the alt text makes sense within the filter environment.

• All cards should have dynamic alt text. This enables users to easily get the value without having to go inside the visual.

• Basic Pattern: Measure Title = “static text” & [DAX measure] & “static text”

• For example: Alt Text for Card = "Card showing recent 7-day rolling average new covid cases is " & round([Most recent rolling average],0) & " new cases, as of " & LASTDATE('Date'[Date]) & ". Press Control + Right Arrow to enter the card. Use Escape to exit."

• Enter this into the alt text by using the fx button:

In Power BI, the title and type of chart is automatically read aloud to users using a screen reader (the first part of the formula above). Don’t repeat this info. Instead, add what isn’t read aloud.

Make sure your alt text is less than 250 characters (the limit in Power BI).

The following are example alt texts you would create for each type of visual (cards should use dynamic alt text to read in the card value):

• Visual:

  • Static: The number of new cases shows how much the virus is spreading in San Francisco. Press Control and Right Arrow keys to enter the chart. Use Enter to select a data point. Use Escape to exit.

  • Dynamic: The number of new cases shows how much the virus is spreading in San Francisco. Most recent average is [Measure of new cases] new cases. Press Control and Right Arrow keys to enter the chart. Use Enter to select a data point. Use Escape to exit.

• Table: Use Control and Right Arrow keys to enter the table. Use arrow keys to navigate around the table. Press the Enter key to select a cell. Select a column header to sort by that column. Escape key to exit.

• Filter: Slicer filters the dates shown on the line chart and table. The default selection is all dates with data. Use Control + right arrow keys to enter the filter. Use Spacebar or Enter keys to select items. Use Escape to exit. Charts will update.

• Card: Card showing cumulative, or running total, confirmed covid cases. Most recent running total is [Cumulative Cases] cases, as of [max date]. Press Control + Right Arrow to enter the card. Use Escape to exit.

• For text boxes, put the text in the alt text box as well.

• Button:

  • Selected radio button entitled “Cumulative totals”. This button is already selected, the dashboard is showing cumulative totals of covid cases and deaths by gender.

  • Unselected radio button entitled “Trends over time”. Press Enter key to select this view and dashboard will update to show trends over time in covid cases by gender.

These guidelines outline best practices for public reporting of data dashboards and visualizations.

This guide was created collaboratively in 2021 by DataSF, Digital Services, Controller’s Office, and several expert volunteers.

We aim to ensure data visualizations created for the public are:

• Thoughtfully designed

• Accessible and enjoyable

• Mobile-responsive

For dashboards or data visuals going on a public website, implementing these guidelines should be considered a minimum criteria for your dashboard or product.

This guide is for analysts publishing visuals to the public.

This guide is for data analysts experienced in data visualization who plan to publish dashboards or data visuals on a public website. While this guidance is applicable for any website, following this guidance is required for any visuals going on the SF.gov platform.

Nonetheless, many of the accessibility best practices are relevant and can be applied to internal reports as well.

Take a look at once these rules have been applied. You can also .

Power BI resources

If you are using Power BI, and associated video tutorial and step-by-step guide . All the guidance below is already applied to our template, so it’s easy to just plug in your data and go!

Analysts can use any visualization software approved by their Department, and all of this same guidance applies.

Thank you!

Special thanks to several expert designers and engineers who worked on this guide and the corresponding Power BI template. Thank you to:

While we include a few key points in this section, there are much more thorough resources:

See more in

Before building a dashboard, align on your goals and audience for your publication. Consider:

• Why are you publishing this dashboard? ​What is your goal - what is the tangible change in the world you expect after publishing?​

• Who will use it?​ What will they do with the information?​ Have you engaged them to verify this is a use-case?​ Is publishing a dashboard the best way to get to your results, or would other engagement (presentations, relationship building) be better?

Confirm your use case is best suited for a public dashboard. Then proceed:

1. • Download the template

   • Import data and connect to data table (ideally a public data table on the City’s Open Data Portal)

   • Data cleaning and transformation

2. • Build within the template: Replace values in charts and tables. Update titles.

   • You can also add a new tab: Re-size to 700 width. Then add visuals.

   • Turn off all interactions.

3. • Update all alt-text

   • Confirm tab order

4. • Duplicate tab

   • Resize visuals and re-size page

   • Order visuals in tab order, confirm filters appear before the visuals that they filter

5. • Remove spacers, delete all mock data tables, apply changes, and verify nothing is broken.

   • Delete all other tabs. Name the final two "desktop” and “mobile”

   • Complete developer checklist

   • Verify alt text and tab order is correct

6. • If you do not have the publish to web permissions, read and then contact your IT and supervisor for permissions.

Follow all guidance in the Digital Services style guide.

All web page content should be at the 5th grade reading level. This grade level means more users can understand your page, and ensures that the translations of the page content are accurate.

Use the Hemingway app to confirm the grade level.

In particular, confirm that intro language and key messages are at a 5th grade level. For data notes with complex content, aim for 5th grade, but no more than 7th grade.

Your dashboard should be embedded at the top of the page, with the section title above the dashboard.

People are likely coming to a data story page for the data, so give them that first.

Your dashboard doesn’t need a dashboard title on the dashboard, instead be sure to clearly and concisely title each data visualization.

Put only essential information before the dashboard, and nothing else.

The only text above a dashboard should be the information needed to understand the data.

Explain any measures and their main purpose above the dashboard. The calculations and details can be in the data notes, but the sentence before the dashboard should explain the key information on why the measure is important and what it means.

Just like with the data visuals, simplicity is key.

Have as few words as possible on the page. The only way to increase the chance that your text is read is to limit the number of words and the complexity as much as possible.

Break content into smaller chunks. Avoid large blocks of text, which are hard to skim and intimidating.

Use section titles to help readers skim. These section headers can show up in Google searches, can be used in the page’s table of contents, and enable users to skim and get key messages. Review your page structure and titles to ensure they are clear.

Break up different topics into different pages. If a page is getting very lengthy, and has more than 3 dashboards, consider breaking these up into separate pages.

Remove or replace unnecessary jargon or acronyms.

Include metadata in a Data Notes section.

Metadata can include information like:

• Link to source data

• Update frequency and schedule

• Who is the publisher of the data (where does it come from)

• Caveats with the data, or limitations

• Any other information you think is needed for users to interpret the data

Test the keyboard navigation

• Are you able to get into your public dashboard using a keyboard?

• Would a user know the keyboard strokes (are they standard strokes)?

• Is the tab order correct? (the order you move from one visual to the next)

• If you used a keyboard and not a mouse, could you get all the same information and functionality?

Test your dashboards with a screen reader

• Install a screen reader. If you use google chrome, you can easily install ChromeVox. If you are using Windows 10 you can use the built in Narrator application.

• Using your keyboard with the screen reader, can you get all the same information and functionality a sighted user has access to?

Test your dashboards on your phone

• Can you read the data and understand the key trends?

• Can you interact with the dashboard easily?

• Are any filters, buttons, or graphs too tiny to read or press?

Much of the content below was taken directly from these two resources:

1. Meagan Longoria's Power BI Accessibility Checklist

2. Microsoft article on how to Design Power BI reports for accessibility

Use standard fonts and sizes.

No font should be smaller than 12 pt.

Power BI tip: All fonts are built into the template.

• Use Segoe Semibold size 15 for visual titles.

• Segoe Semibold size 14 for axis titles.

• Segoe UI size 13 for all other text. All font must be size 12 or larger.

• Segoe UI Bold 35 for cards

Create meaningful chart & axis titles.

Titles on each graph or data visualization are important accessibility features that orient a user. Add descriptive, purposeful titles to charts. Avoid using acronyms or jargon in your report titles.

We recommend using x-axis titles on all your charts. Make the title descriptive. For instance, if your chart is displaying data over time, try to describe how the data is mapped to a date. So the axis title may not be “Date”, but rather, “Date of incident”, “Date test was collected”, etc.

The visual title of your chart should be descriptive enough that a y-axis (value axis) title is not needed. However, if you do need the additional detail of a y-axis, add one.

Power BI tip: You can make a visual’s title dynamic by creating a measure that concatenates your title text and a specific value. For example, this COVID-19 cases chart dynamically tells you the current number of new cases

Use data labels sparingly to avoid cluttering your chart.

Beware of over-using data labels and cluttering your graph. A data label should not obscure the chart's visuals from the reader.

If labels are obscuring the visual, it may be best to not have labels and instead rely on the table below to reveal the data points.

Avoid showing decimals and being overly precise.

Being overly precise can obscure trends. Being overly precise might mean showing unnecessary decimals or showing numbers in the millions/billions that really should be rounded. There shouldn’t be decimals shown on your public dashboards in most cases.

There are exceptions to this. For instance, if you are showing percentages and want to show that a certain percentage isn’t 0, but rather .3 or .4, that may be fine. But in those cases, only one decimal should be used.

Minimize/eliminate movement in any visuals that won’t be accessible to a screen reader.

Avoid any movement or video/audio that automatically plays.

No interactions should be required to access key information.

If critical information is only accessible through an interaction or click, re-organize the dashboard. Rearrange your visuals so they are pre-filtered to make the important conclusion more obvious. Clicking should not be needed for any key information.

Test any interactions to ensure everything works with a mouse and with a keyboard.

Don’t rely on tooltips for important information.

Tooltips are not accessible to keyboard users in Power BI. In addition, users with motor issues may have difficulties accessing them.

Only add tooltips to charts to reinforce information that is also accessible in another way.

Turn off all unnecessary interactions.

Only keep interactions (where one visual filters another) if it is helpful and clear. Most interactions add unnecessary complexity and should be turned off.

Typically, you want to be able to select a point from a graph and have the table filter. And likewise, you want to be able to select a cell in a table to see the point highlighted in the graph.

Designing a public dashboard and the surrounding webpage go hand-in-hand. Use the guidance below to design your dashboard, and the webpage content guidance section to shape the page content.

For an excellent review of more general data visualization basics and best practices, review this Reader on Data Visualization, by Michael Schermann at Santa Clara University. Chapter 2 on the fundamentals of data visualization is a must-read for analysts.

Learn more about inclusive design.

Using Power BI? Use the SF.gov dashboarding template in Power BI. All the guidance below is already applied to our template, so it’s easy to just plug in your data and go!

Understand what data your audience is looking for (or coming to the dashboard for).

This is perhaps the most important part of design. Build in time to talk to your audience to understand what they want. This is not optional - it’s key to your publication’s success!

Keep it very simple.

Do not assume that adding more visuals or filter menus to your dashboard gives users access to more information. In some cases, too many visuals can clutter a dashboard and reduce the usability!

Start by understanding and outlining the most important point or finding in the data. That is your key visual, which should be in the top left. That is your lead.

Channel the progressive enhancement strategy: build your dashboard so that all users can clearly and easily see the key data points and findings. Only then, add buttons or other functionalities for advanced users.

If a key stakeholder requires more specific data or a complicated chart be included, include it in the “deep dive/ enhanced” view. This means, your initial view is simple, and a clear button or toggle (or a link to the underlying data) enables those interested to go deeper.

Power BI tip: Do not create a multi-page report with the expectation users will discover the bottom navigation arrows (in the grey bar).

• If you do need to use multiple pages, and they are all very closely related content, then include another way to access the subpages (like radio buttons). You will need to ensure the desktop views are the exact same dimensions.

• If the pages have slightly different content or purposes, they should be different reports and embedded as different visuals.

  • Remember in Power BI to leverage the Power BI dataset functionality to keep your data pipeline and maintenance simple.

Aim for 2-3 data visuals.

Aim for, at most, 2-3 data visuals (bar/line graphs, maps, cards, tables, etc), and 2 supporting elements (button selector, filters) per dashboard view. You may need to split your initial idea into several dashboards.

Before adding an element, consider: is this needed to understand the main purpose of this data? Is this related to the other data, or does it belong on its own dashboard?

If you have a more complex chart, it will likely need to be the only figure shown (with a table).

Walk your users through the key findings, or purpose of your dashboard.

What is important about your data? What are the key trends, or findings that are the main takeaways? These should be very clear and written out for users to read.

Because most dashboards cannot be translated into different languages, this written text may need to be on the webpage itself.

If you are publishing live-updating data and key findings may change over time, this may not be possible. Even so, offer as much of a text-based equivalent of your dashboard as possible. Read more in the accessibility section.

Example: A line chart with more than 3 lines is generally not clear or discernable for users. Even if you’re using different shapes (and not fully relying on color), it’s still difficult to see trends when lines are on top of each other.

The best version of this visual would be a chart that already highlights the key finding - is there a certain disparity that is important? A key trend over time? An inflection point or turning point? Instead of a chart showing all the data, curate specific charts for each finding.

If the data is live-updating, another potential solution may be using small multiples to show each trend separately (with the same scale, if comparison is important).

Consistency is key.

If you are maintaining more than one dashboard, keep your dashboards as consistent as possible. Keep the formatting, color, design patterns, and common buttons/widgets/elements in the same places. You want your users to know where to go for things. This includes:

• Buttons in the top left. If you’re using buttons or toggles, keep them in the same place. The top left is preferred.

• Filters on the left hand side. Keep all the filters stylistically identical. Users should know exactly where to look to filter.

Use consistent spacing between data visuals.

Don’t place clickable data visuals and user interface elements too close together. In our template, we keep visuals 10 pixels apart, and 15 pixels from the edge.

It’s important to keep things far enough apart that a user can understand that they are different elements. However, they need to be close enough to know that they are related (in the case of UI elements).

Behind any excellent dashboard is a robust data model. For public dashboards, there are specific dataset (and data connection) best practices that are different from internal operational dashboards.

Your underlying data should be publicly available, preferably on the Open Data Portal.

If the underlying data is on the Open Data Portal, link your dashboard up to that data pipeline to ensure both remain synced and to simplify the data pipeline.

Power BI tip: In PowerBI, when connecting to an API, be sure to adjust the limit to bring in all rows (adding ?$limit=999999999999 to the end of the CSV link).

• Double click on "source" step and "Ignore all quoted line breaks"

• For geographic datasets, do not bring in the multipolygon field. Specify only certain columns by: https://data.sfgov.org/resource/d2ef-idww.csv?$limit=99999999999999999&$select=specimen_collection_date,area_type,id,acs_population,new_confirmed_cases,last_updated_at

Review the underlying data for any private, health, or sensitive information before publication.

If you are a CCSF employee DataSF can help with this, along with your department’s privacy or compliance office. You should assume that once you publish the dashboard, users can access all the underlying data tables in your public dashboard. If that is a problem, the data needs to be aggregated to the appropriate observation level before being linked into the dashboard.

Aim for a small, simple underlying data model.

Just as the data visuals for the public need to be clear, simple, and accessible, the underlying data model should mirror this.

If there are complicated data pipelines feeding into your dashboard, aim to have those combined and cleaned upstream from the dashboard itself. This ensures that no complicated logic exists solely in Power BI or Tableau and is inaccessible to other analysts or curious journalists.

Maintain internal data documentation.

Documentation should be is accessible to the entire team maintaining public dashboards. This is critical for the sustainability and resiliency of your dashboards. Create the documentation in whatever tool your whole team has access to and is convenient (this could be Sharepoint Word/Visio/Excel, MIRO, Trello, Asana, etc.).

The documentation should contain vital information on each dashboard, specifically, enough information that someone else on the team could use the information to de-bug a problem and re-publish. This includes:

• Data source information (including all the datasets within the dashboard, links to that data, contact information who owns the source data, time it updates, any special notes).

• Access/audience (confirm the approved audience level for each)

• Location of dashboards (with links to the online reports, datasets, and, if applicable, the desktop files).

• Any step-by-step guidance someone would need to troubleshoot an issue (that isn’t familiar with the dashboard).

• This documentation should include, or link to, any other resources your team may use (like templates, standard work, checklists, etc).

Organize your measures into folders. This is particularly helpful if you have a lot of measures and dynamic titles and alt text. Read more about organizing measures into folders.

Maintain a separate public workspace to contain all public dashboards. This is good for documentation and resiliency (if anything goes down, your whole team will know where to go), and for web performance. Ensure that workspace is not a premium workspace. Read more in DataSF's Publish to Web Tip Sheet.

If you have multiple dashboards/reports that need to connect to one data source (or group of data sources), leverage Power BI’s dataset capability. This will save you many headaches when troubleshooting, updating, or correcting data. Read more about Power BI datasets:

• https://docs.microsoft.com/en-us/power-bi/connect-data/desktop-report-lifecycle-datasets

• https://exceleratorbi.com.au/new-power-bi-reports-golden-dataset/

For SF.gov, size your dashboards to fit properly on the webpage.

For both desktop and mobile, the width of the dashboard is set. The height may vary, but be sure to test your dashboard on the website.

• Desktop: width must be 700, height 700-1100

• Mobile - width must be 360, height 700-1200

• The template has these sizes built in. While the width is set and must remain set (to fit the webpage), you may extend the length within reason (to 1100 for desktop, to 1200 for mobile).

Publish to a designated public workspace.

Publish your dashboard to the specific workspace that houses your public dashboards. Read more about this on DataSF's Power BI Publish to Web Tip Sheet.

Know your dashboard dimensions.

In order to embed on SF.gov, you will need to know your dashboard size.

To re-size the page or confirm the dimensions, go to the report editor (where you’re designing your dashboard). Click outside the dashboard to make sure no visual is selected, then click the page icon with a paint brush and then canvas settings.

Test your final dashboard in the website with different screen sizes to ensure you can see each visual in its entirety on the screen.

Confirm page view is "fit to page".

Ensure that the page view on both tabs of your dashboard are the default “fit to page”.

Get the embed codes.

You will also need to get your embed codes for both the desktop and mobile view.

Within Power BI Online, navigate to your dashboard. Then click File, Embed report, Publish to web (public).

If you do not see this option to embed the report or publish to web, review DataSF's Power BI Publish to Web Tip Sheet. Then contact your IT or administrator to request the necessary account permissions.

You will need to copy the embed link for both your desktop view and your mobile view. Simply change the “default page” to get each link - and confirm the correct view is showing up in the preview window to the right!

You will then enter the URLs and the dashboard dimensions into SF.gov.

Color can be an important part of the design of your dashboard. However, in a data visualization, color shouldn’t be relied on as the only way to distinguish data.

This guidance draws heavily on several excellent articles on color and data viz.

Use our default SF.gov data viz colors.

The color scheme is the standard if you are embedding dashboards in SF.gov. This is built into the Power BI template.

We do not recommend customizing the color profile. If you need to customize the color template, you will need to ensure the combinations are accessible and colorblind friendly. Ensure color contrast between title, axis label, and data label text and the background are at least 4.5:1. Use accessible colors to check color contrast for background/font. Use this contrast checker and make sure colors pass WCAG standards. Use the Viz Palette tool to test colors using different color deficiency lenses.

Power BI tip: Colors are built into the template. Do not use the lighter shades of the colors. Only use the primary colors, and darker. The lighter colors do not contrast enough with white.

Avoid relying on color as the only way of showing certain information.

Avoid using color (including conditional formatting) as the only way of conveying information. Instead, use other symbols and markers to differentiate data. You may also need to split a visual into multiple visuals if you find you are relying on color in a legend. Here is an example using shape and color:

Limit the number of colors.

You may want to use colors to show different categories, to shade data sequentially, or to show data centered around zero converging. No matter what, limit the number of different colors within a visual and use color sparingly to highlight key data.

If you are tempted to use several colors in one visual (more than 3), you may need to explore other types of visuals. For example, converting your visual to small multiples can be more accessible and does not solely rely on color.

Check your dashboard colors

Put your URL into this color checker. You could also use coblis to ensure all elements are visible.

Use the following steps to easily leverage our template and create your own dashboards.

Step 1: Set up

• For this illustration, we create a chart of film locations over time

  • Dataset: https://data.sfgov.org/Culture-and-Recreation/Film-Locations-in-San-Francisco/yitu-d5am

• Download the template

• Save template with new file name, so you can refer back to original template

• Import data and connect to date table

  • Assume that all of the underlying data in a public Power BI dashboard is completely accessible to the public. Before making a public dashboard, you'll need to consider data security.

  • After import, you may need to convert your date/time field to date format

• Identify the format you want to use

• Drop pages you will not be using

Step 2: Visualize data

• Replace values in chart(s)

• Replace values in table(s)

  • Remember: you must have a table of data, and preferably a text equivalent of the data viz

• Update titles

• Turn off interactions

• Review formatting guidance

Step 3: Accessibility updates

• Update all alt text

  • Use example language in the template

• Verify tab order

Step 4: Mobile view

• Duplicate tab

• Resize visuals and re-size page

• Order visuals in tab order, confirm filters appear before the visuals that they filter

• Mobile formatting updates

  • Shorter table

  • If you are using toggles, reformat to show all data without toggles on mobile view

Step 5: Clean up and check your work

• Remove spacers

• Delete all mock data tables, apply changes, and verify nothing is broken.

• Name tabs desktop and mobile

• Complete developer checklist

  • Verify Alt text (click every visual/textbox -> format -> expand general -> inspect alt text)

  • Verify tab order is correct (click outside dashboard and use tab key)

• Publish to Power BI Online

• Use screen reader to verify alt text

• Publish to web

  • If you do not have the publish to web permissions, read DataSF's Power BI Publish to Web Tip Sheet and then contact your IT and supervisor for permissions.

Converting a pre-existing file to the template

If you have a pre-existing Power BI dashboard you'd like to convert to this template, you have options. You can build within the template. In that case, you will just have to re-create your data model within this file. The easiest way to do this is to copy and paste each query code from the advanced editor and recreate your measures. Then just follow the same steps above.

If your pre-existing file is very complex, you can convert a file to this template using the steps below.

• Open pre-existing dashboard

• Apply template JSON style (the json file in this folder)

• Add new tab

• Re-size new blank page to width = 700, height = 800

• Copy/paste visuals from template file. Or, add new visuals

  • DO NOT copy or use any of the pre-existing visuals

• Complete all design and accessibility steps above

• Complete checklist

Creating a mobile view involves more than simply stacking your visuals. You’ll need to test the mobile view on your phone and consider:

• How easy is it to see the key data or information?

• How does the information flow?

Adjust the design as you test.

If your data visualization tool is automatically mobile responsive, test that to ensure figures are stacking as expected. If it is not (like Power BI), you will need to create a second mobile view. In creating your second mobile view, follow the guidance below.

Note: For internal reporting, PowerBI has a and dedicated IOS and Android app. This guide is concerned with public reporting where no dedicated mobile view exists

Create the mobile view last.

This should be the very last thing you do after you’ve finalized all the formatting, alt text, and tab order of the desktop view. You want to ensure the mobile and desktop view match and have all the curated alt text you created.

Power BI tip: In Power BI (as illustrated in the template), you will need to create a second page in your report for the mobile view.

• Duplicate the desktop view page, resize visuals to 330 wide, move visuals to the far left, and make the page size width = 360.

• Name the tabs “desktop” and “mobile”.

Make design and accessibility updates for mobile.

Imagine being on the go and a mobile user of your dashboard. Can you make anything easier for your users to see or infer?

In some cases, it may be helpful to add a card visual to highlight a key metric larger for mobile. Consider this, and then test on mobile.

Make formatting updates for mobile.

Within each visual, you may need to update certain formatting to better fit on mobile. Some possible formatting updates:

• Filters in mobile should be drop-down filters, which saves significant space on mobile (instead of longer pick lists).

• Data labels may need to be removed in mobile. They are often too small and can cover up seeing the trend in the chart.

• Tables may need to be adjusted to better fit on mobile. The title may need to be shortened. Column widths may need to be thinner to fit, and text may need to wrap on mobile.

Put filters above the visuals they affect in the mobile view.

Remember that the reading flow of a mobile dashboard is different from desktop.

On a desktop, users can move around the dashboard and more easily reference an earlier card/visual. In mobile, the view is much more linear from top to bottom.

Do not make users scroll up and down to use filters. They should come across any filters (and be able to use them) before the visuals that are filtered.

Restructure any dashboards using toggles or buttons.

Toggles work on desktop when they are discoverable and easy to use. On mobile, toggles are not recommended, particularly if they rely on users scrolling up and down to remember there are toggles and to see the impacts of clicking them. Instead, consider other dashboard structures.

For example, it may be best to build a mobile view of the first toggle view, and then add visuals to the bottom that capture the key information from the other toggle views. This will create a much longer mobile view, but the information will flow more like a desktop user.

Make tables shorter in the mobile view.

Tables should not be more than 245 pixels long in mobile.

Longer tables can create issues for mobile users: they could get stuck scrolling the table, without being able to scroll beyond the dashboard.

Hospitalizations

Before

After

New cases

Before

After

Cases by gender

Before

After

Vaccinations

Before

After

Design

• by Ashleigh Axios

• Tableau's

• by Midori Nediger

Accessibility

• by Doug Schepers

• by Amy Cesal

• with Meagan Longoria

• on WebAIM

• by Amy Cesal

Color

Screen readers

Power BI Resources

• • Note that some of this information is only relevant for sharing dashboards in Power BI online. Some of the features are not available for public dashboards that have been published to web.

• Using Power BI Datasets

  • by By Matt Allington

No cells should be blank.

They should have a 0 or explain they are missing. Blank cells are confusing and unclear.

Power BI tip: To force a zero to appear add a “+ 0” to your measure. Sum of Sales = Sum(Sales[SalesAmt]) + 0

Sort tables by importance to your users.

This may vary based on your data. For tables showing data over time (so each row is a date or month), sort the table to have the newest or most recent values at the top. Recent data is likely most relevant for your users.

A table below a map should be sorted by the measure or variable that is shown in the map. For example, a table below a choropleth map showing population density should sort the table by population density.

Structure your table intuitively.

If your table includes dates, they should always be rows (each date is a row). In many cases, your table will match your cleaned data structure.

While “wide” data can be more intuitive for users, sometimes a wide table is difficult to use. Therefore, long data is acceptable if the wide table doesn't fit within the template. For example, while this wide table of data by race may be intuitive, the long version is also acceptable because the wide format may not fit on most dashboards.

In general, don’t use data bars.

Data bars within tables are typically difficult to ensure visibility for most users.