Category: Microsoft Power Apps

Accessibility, Microsoft Power Apps, Power BI

Microsoft Can’t Make Your Power BI Reports Accessible Without Your Help

Meagan Longoria

Every once in a while, someone asks a question like “Can Power BI be accessible?” or “Is Power BI WCAG compliant?” It makes me happy when people recognize the need for accessibility in Power BI. (I’ll save the discussion about compliance not automatically ensuring accessibility for another day.) But most people don’t appreciate the answer to either question.

A woman, man, and person in a wheelchair positioned next to the Power BI logo

The answer is that WCAG compliance and accessible design are highly dependent upon the report creator. Microsoft has added many built-in accessibility features such as keyboard navigation, high contrast view, and screen reader compatibility. But they can’t make your report automatically accessible as there are accessibility features requiring configuration by the report designer. We need to set the tab order and alt text and use descriptive chart titles – there is no artificial intelligence to do this for us (yet?). Beyond that, things like color contrast and colorblind-friendly design are almost entirely the responsibility of the report designer.

Accessible design used to be solely the domain of UI developers. But as we democratize analytics to have everyone building reports, we now have to create awareness and a sense of responsibility among Power BI report creators, especially those who don’t consider themselves developers.

There is a similar challenge going on with data security. It used to be that people thought of it as a concern only for the IT department. Now, it is widely accepted that everyone in an organization plays a role in maintaining data security. I hope the same attitude will be widely adopted when it comes to accessibility in data visualization and analytics.

This challenge is present in any low-code environment with users of diverse backgrounds and technical expertise, which means it is relevant to the entire Power Platform and other similar tools. There is a white paper on PowerApps Accessibility Standards and Guidelines that has a great description of the situation.

PowerApps embodies the idea of “democratization of development”—anyone in your organization can quickly and easily create a powerful app and share it broadly. But the app maker has an ethical, and sometimes legal, obligation to support “democratization of usage” as well—any user of your app must be able to use it as it was intended.

Based upon the popularity of the Power Platform, I’d say the democratization of development has been a wild success. But we still have some steps to take to democratize usage. Microsoft is doing their part to make their products accessible and to fix accessibility bugs quickly. Now we need to recognize and honor our obligation to design inclusively.

The Microsoft Docs on accessible report design were recently updated to provide more guidance. I hope you’ll check them out and start implementing the recommendations in your reports.

Accessibility, Conferences, Microsoft Power Apps, Microsoft Technologies, Power BI

I’m Speaking at Microsoft Ignite 2019

Meagan Longoria

I’m happy to be speaking at Microsoft Ignite this year. I have an unconference session and a regular session, both focused on accessibility in the Power Platform.

The regular session, Techniques for accessible report design in Microsoft Power BI, will be Wednesday, November 6 at 2:15pm. In this session I’ll discuss the features available in Power BI for making accessible reports and demonstrate techniques for making your reports easier to use. This session will be recorded, so if you can’t make it to Ignite, you can catch it online.

My unconference session, Accessibility in the Microsoft Power Platform, is a chance to have a discussion about accessibility in Power BI and PowerApps. It will be held on Thursday, November 7 at 10:45 am. Unconference sessions at Ignite include facilitor-led discussion and exercises that encourage audience participation where everyone can share their experiences and opinions. If you will be at Ignite and want to share struggles or successes in improving accessibility or raising awareness of accessibility issues, please join me.

This year at Ignite there is a reservation system for unconferences. You can RSVP while you are building your schedule on the website. Walk-ins will be accepted just before the session, assuming there is room. But please RSVP if you want to be sure to get a seat in an unconference session. Unconference sessions are not recorded, so this will be an in-person session only. But I will post materials through the Ignite website once the session is over.

If you will be at Ignite, please stop by and say hello and meet Artemis the Power BI accessibility aardvark.

Microsoft Flow, Microsoft Power Apps, Microsoft Technologies

Updating a SharePoint List Item With Flow When You Don’t Have The ID

Meagan Longoria

I recently worked on a project that used Flow to update a SharePoint list each time an item was updated in the Power Apps Common Data Service. In order to update a SharePoint list item, you must have the unique ID, even if there are other fields that are unique to the item. I spent a while searching through forums to find out how to accomplish this, so I’m documenting it here in the hopes it helps someone else.

We know we need a starting point from which the updates originate. For me, that was when a record is updated in an entity in the Common Data Service, but this could be anything (an email arriving, an update occurring in another SharePoint list, etc.). This source doesn’t contain the unique ID for the list item, since that ID is unique to SharePoint. In my example below I have a CDS entity called Tactic. Tactic has three fields that are submitted to the SharePoint list upon creation: Tactic Name, ID, and Tactic ID. My SharePoint list is called Meagan Test Flow List and contains the corresponding fields Title, TacticID, and RecordID.

The next part is the trick that makes this work. You’ll need to add a new action and choose SharePoint – Get items. Be sure that you choose SharePoint Get Items (items is plural). There is another choice called SharePoint – Get Item, which is not the same and will not work for this purpose. In the Get Items action, populate the site address and list name. Then expand the advanced options and add a filter. This filter should use a field in your source that uniquely identifies a record. For my example, the ID field in the CDS entity has unique values for each record. My filter condition is RecordID eq and then the CDS field. RecordID is an integer. If the value on which you are filtering is a string, you’ll want to put single quotes around it.

Once you have completed your filter condition, you can add the final action: SharePoint – Update Item. Flow will automatically add a for each container as you begin to fill in the required fields – this is fine. Even though you are only updating a single record, the Get Items action could potentially get multiple records. As long as you are using a field that uniquely identifies the single record you want to change, this will work.

You should end up with something resembling the image below. 

You should populate the ID field with the ID from the Get Items result. You want to make sure you have mapped the fields from your source to any field that should be updated. The only field I was updating in my list was Title. The TacticID and RecordID do not change after creation.

That’s all there is to it. May the Flow be with you.