Power Apps, Accessibility, and WCAG

Power Apps, Accessibility, and WCAG Header Image

Introduction – What lies ahead

I have been talking about Accessibility for a while now, and often link this to DELIVERY rather than BUILD. In this post, “Power Apps, Accessibility, and WCAG”, I’m going to bring all this together. I’m also going to tie it in to the Web Content Accessibility Guidelines (WCAG) around colour contrast.

This post itself is going to be a fairly high-level overview of a Power Platform Solution I’ve written. The elements of the solution allow you to build themes, whilst ensuring the colours fit with WCAG Contrast guidelines.

There’s an accompanying video, which you can watch on my YouTube Channel, and there will be more content coming where I will go in more detail. I’ll also discuss improvements for a “Phase 2” build.

Up front I have to acknowledge the awesome work by Sancho Harker (@iAm_ManCat) who’s theming engine inspired me to produce this. You can read more about this in my post “Power Apps – Instant Accessibility using a Theming Template“.

I also must say a big thank you to Eswar Prakash. His Colour Picker PCF control was perfect for this, and he’s likely to have a big influence on Phase 2. You often hear of 2 people in different parts of the world having the same idea at the same time. Here’s a prime example as he’s done some work around colours and WCAG himself recently! You can expect to see some collaboration around that for sure.

The Power Platform solution file for this project can be downloaded from my GitHub page here.

Anyway – on with the post!

What is WCAG and what does it have to do with Accessibility and Power Apps?

WCAG stands for Web Content Accessibility Guidelines and comes from the W3C. Don’t let the “Web” in the name fool you though, it’s rapidly become a standard for all digital content.

The guidelines define whole areas of design and accessibility including colours and interface elements. I first became aware of the Colour specific standards when reviewing the colours of this website. These elements define a set of ratios and ratings that are calculated on the contrast of two colours, e.g. background and text. There are 2 main ratings, AA and AAA, and a ration figure that is used for evaluation. Within this there are also exceptions and different criteria for things like large text or logos.

This got me thinking about some of the colour schemes I’ve seen used in Power Apps. It really opened my eyes to just how some of the colours used are difficult for some people.

So, why not build something that enabled easy theming whilst also meeting the various WCAG standards? Specifically focussing on the AA and AAA rating for standard sized text as that’s the one we use most. I also wanted to make AAA the standard for a full rated pass as that is the more stringent. It is also likely to become the new baseline in the future.

A quick note on Theming your Apps

Why bother with themes? It’s extra hassle, it’s more work, it’s <insert more excuses here>

If you work in a corporate environment, or anywhere that has had a branding/marketing agency design your image, then you’ll have a branding guide. This is usually a document that dictates corporate colours, templates, design language and more. It’s what makes your organisations content cohesive and consistent.

That very consistency should apply to the content we build. And it’s not as much work as you think to make this work in Power Apps etc. Also, by using a theme, if the corporate colours change then you can adjust all your apps with one change.

The other MASSIVE reason for using themes is that you can give your apps the facility to let users select their own themes. This includes High-Contrast colour schemes, schemes for people with colour vision deficiencies (colour blindness). With one easy change your apps suddenly become a whole lot more accessible.

How I’ve built a template system that includes Accessibility and WCAG compliance in Power Apps

Architecture overview for the Theme App. Includes the icons for Power Apps, Power Automate, and Dataverse in a pyramid with 2-way arrows connecting them to each other. Also features the SharePoint and Excel icons underneath the Dataverse one
Theming Architecture – Using Power Apps, Power Automate, and Dataverse

The architecture for the theming template is very simple. Because I’m a Dataverse guy by default, that was always going to be my location for storing the theme data. Of course I’ve included Power Apps, you can’t build a Power App without it after all. Power Automate provides the flow that calls an API to check the theme elements and then records the results.

You could use SharePoint for storing the themes, it’s not a bad use for a SharePoint list in this instance. You could even use an Excel file with a table structure in it. At the end of the day, if a connector exists then you could use any data source.

I’ve created an entity table within Dataverse called “Colour Schemes” that has a set of fields columns to store sets of the following:

  • Background Colour
  • Foreground / Text Colour
  • WCAG AA Result
  • WCAG AAA Result
  • WCAG Ratio

This also has columns for a Highlight Colour (which is not used in any WCAG scoring), and an overall WCAG status for the theme. This overall status will only show a pass if ALL elements have passed both the AA and AAA tests.

A Power App that is WCAG compliant and with Accessibility built in

The front-end, and the purpose really, is the Power App. In this case I’ve built a pretty simple demo app. For full details of it please watch the video over on YouTube. There are 3 screens in the app; Welcome, Simple Theming, and Full Theme. In this post I’m going to focus on the “Full Theme Screen” part of the app as that’s where the cool stuff happens 😎

Power Apps Maker screen showing the tree view on the left and a tablet format app on the right. The app features a dropdown for selecting a Colour Scheme with a section of boxes for editing and testing the theme. There is also a mockup of an app that demonstrates the colours at work.
WCAG / Accessibility Power Apps Theme Builder App

With one very quick and easy glance you can see the name of the colour scheme along with the WCAG status. You can also see a working mock-up of what an app would look like with these colours. The main app itself responds to colour changes so that you can really get a feel for using a theme.

When the Dropdown is Loaded or Changed, the relevant colour scheme record row is retrieved from the Dataverse and this populates a series of variables. These variables in turn are used by the app controls to define all of the colours and elements, dynamically. Once you’ve set the variables on the controls, the colours will be linked to the theme that has been selected.

Of course, you could always just have one theme. This would be a BAD THING though as you really need to ensure that things such as high contrast and colour vision deficiency are catered for.

Within the app the controls can be navigated to using the keyboard (where possible). They are also named in such a way that screen readers should be able to make sense of it all. And that Highlight Colour? That’s used for making sure that when you do hover over, or navigate to using the keyboard, you can see what control you are on!

The biggest part of this screen though is the “Update & Test” button. First of all this updates the row in the Dataverse with the values from the app. It then triggers the Power Automate flow, passing the current colour schemes GUID (its unique key) through as a parameter.

The flow pulls out the values from the row provided and runs through the pairs of colours. Calling an API version of the WCAG checker at WebAIM, it processes the returned values and updates the colour scheme with Pass/Fail statuses and the colour ratios.

At the moment the Power App is refreshed to display the results by clicking on the dropdown box. I will put in a refresh, but it’s not there at the moment!

To Conclude and Be Continued…

So I’ve given you a very quick whistle-stop tour of what has been built. The Power App has barely had the surface covered. I haven’t gone into the minutiae of the table metadata, or the structure of the Power Automate flow. I’ve not even mentioned the Model-Driven App (not much to say there really). That’s all to come, along with much more.

Over the coming weeks I’ll be posting more in-depth videos and posts. In them I’ll cover the various different elements, and taking a look at how they work and how they can be re-used.

Phase 2 of this will hopefully remove the need for a Power Automate flow, with the calculations happening immediately. I am also going to look at ways of learning from what Sancho has built to improve this solution.

The solution file containing the Dataverse Table, the Power Automate Flow, the Model-Driven App, and the main Canvas Power App, can be downloaded over on GitHub. It also includes a single-run flow that just processes two-values passed as parameters. A sample Excel file, containing the two colour schemes used in the video, can be downloaded here.

I hope this is useful and will help you develop Power Apps that are Accessible and meet WCAG guidelines. Please comment, share, and contact me if you want to talk about this!