SVG in PowerApps: what about accessibility?

Nelson Boruchowitch — Thu, 27 Aug 2026 00:00:00 +0000

TL;DR : Using SVG has become a reflex for bringing our Canvas Apps to life. Except that some of your users have asked their system to stop animations, and Power Fx has no way of knowing. The CSS embedded in the SVG does: @media (prefers-reduced-motion: reduce) really is evaluated inside a Canvas App, every time a session opens. Here is the ready-to-paste pattern, the test bench that proves it, the precise reason why this reading is a snapshot rather than a stream, and the layered architecture that makes it genuinely usable in production.

Part 1 of 5 · 4 min read

The problem and the answer

The observation, and the code that settles it.

SVGs are convenient, lightweight, crisp at any size, colourable from Power Fx, and given the sheer number of resources available online, we have plenty to work with.

But a trend gradually appeared: the animated SVG. A spinner that turns, a halo that pulses on today's date, an icon that draws itself when the screen opens. It instantly makes an app feel alive, for the trifling cost of a few lines.

Except that for some of your users, that motion is not a nice touch but a physical problem. Vestibular disorders, migraine sensitivity, certain attention disorders: those people have already told their operating system, in the Windows settings, that they no longer want animations, and your app is not listening.

This is not a matter of comfort, it is written into the standards:

WCAG 2.2.2: Pause, Stop, Hide (level A): any moving content that starts automatically and lasts more than 5 seconds must be pausable.
WCAG 2.3.3: Animation from Interactions (level AAA): non-essential animations triggered by an interaction must be able to be disabled.

When accessibility comes up in a Canvas App, we usually talk about AccessibleLabel, TabIndex (tab order), contrast and Live regions. All of that is documented, all of that shows up in the Accessibility Checker. Motion is nowhere to be found. It does not exist in Power Fx either: there is Host.OSType, Host.BrowserUserAgent, App.Width... and nothing at all about the system's accessibility preferences. No Host.PrefersReducedMotion.

In practice: your Timer sliding a panel in, your Transition on a button, your blinking badge, they all run regardless of what the user asked their OS for. And you have, apparently, no way of knowing.

Good news: you do not need Host.PrefersReducedMotion. The preference is already there, inside your SVGs. Three lines of CSS are enough.

2. The answer fits in three lines of CSS

Let us take a real case. In my cmpCalendar component, today's date carries a gently pulsing halo. Here is the version that listens to the system:

"data:image/svg+xml;utf8," & EncodeUrl(
    "" &
    "" &
    "" &
    ""
)

By default: a breathing halo. Under reduce: a crisp, motionless ring, slightly thicker so it stays just as visible. The "this is today" information is intact in both cases. No If() in the formula, no variable, no Power Fx logic: the CSS decides.

Reading your system preference...

no-preferenceyour rendering

The halo breathes. stroke-width:2

reduceyour rendering

Crisp ring, motionless. stroke-width:2.5

One line is missing for this to be reliable, and only one. In App.OnStart:

// App.OnStart
Set(gblBust, GUID())

That variable does not appear in the code above, but it has to be there. Section 8 explains why it is not a debugging artefact but the reading mechanism itself.

That is all. No connector, no PCF, no component. A string of characters.

Now, why it works.

Part 2 of 5 · 7 min read

Why it works

This part explains which door the CSS uses to get into a Canvas App, and why the seemingly obvious route, the No the style sheet is stripped by the sanitiser style="..." No CSS grammar forbids an at-rule inside an attribute Yes the SVG carries its own document, hence its own style sheet

Which completely changes the way to look at the problem. The decisive element is not the Image control, it is the data URI. The Image control is merely the shortest path to using it.

Nothing stops you, then, from having both live in the same control. Here is the complete assembly, to paste into the HtmlText property:

// HtmlText property of an HTML Text control
"" &
    "Your text, your links, your formatting.
" &
    " &
    EncodeUrl(
        " &
        "" &
        "" &
        ""
    ) & "'>" &
"
"

The outer HTML then carries what genuinely belongs to HTML: text, formatting, links. The SVG carries the graphics and the media query. One clarification is needed about interactivity, though, because it comes at a price. The displayed content really is alive: measured in a published app, a link opens a window, a checkbox ticks, a

block unfolds. But it is mute. None of that reaches Power Fx, which will never know the box is ticked. The content lives, but it does not speak.

The only bridge to the application is the control's OnSelect. It exists and it fires, but it is the event of the control, not of its content: it is single and global, and nothing in Power Fx says where the click happened. As many reactive zones as you want, as many controls to place. In a chart component, the useful assembly therefore stays the same: the drawing and its visual behaviour live inside the image, and the interactivity the image cannot provide comes from Power Apps, placed around it or on top of it.

And this is not guesswork. Section 7 builds a test bench that puts every link in the chain to the test: the canary shows that the SVG's CSS really is evaluated, then the prefers-color-scheme and prefers-reduced-motion probes show that user preference media queries answer as well. That bench is written for the Image property, the shortest path; it is the same SVG I placed in the src of an to test the HTML Text control, and section 9 reports on it.

Part 3 of 5 · 5 min read

Doing it properly in production

The mechanism is settled. What remains is using it without degrading the experience: what to put in place of the motion, and how to leave the user the final word anyway.

5. Reducing is not removing

The classic mistake is to treat prefers-reduced-motion: reduce as a master switch: animation: none everywhere, and let us say no more about it. That misses the point. An animation often carries information: "it is loading", "this is what just changed", "this element is active".

If you remove it and put nothing in its place, you are not making the app more accessible: you are stripping a layer of information from an audience that already needs it.

The right rule: replace the motion with a static equivalent that carries the same information. A pulsing halo becomes a solid ring. A slide becomes a fade (changes of opacity and colour are far better tolerated than large displacements). A long duration becomes a short one.

That is what the halo in section 2 does, with its stroke-width going from 2 to 2.5.

5.1. The edge case: the loader

Same principle, different use:

"data:image/svg+xml;utf8," & EncodeUrl(
    "" &
    "" &
    "" &
    ""
)

Careful here: a motionless spinner no longer communicates "in progress". Alongside this SVG, what is needed is a genuine status text next to it, in a PowerApps Label, with Live: Assertive, announcing "Loading..." then "Done". That is what should have been done for screen readers anyway. Reduced mode merely makes the omission visible.

6. The three-mode pattern

The two examples above are good illustrations, but they leave a legitimate objection unanswered: what if the user wants to decide for this particular application? Perhaps they have turned animations off everywhere in Windows but tolerate yours. Perhaps the opposite: Windows says nothing, but your app is a bit much for their taste.

Here is the shape I recommend in production. A three-valued Power Fx variable arbitrates, and the CSS decides in only one of the three cases.

"data:image/svg+xml;utf8," & EncodeUrl(
    " &
        "class='" & Switch(gblMotionMode, "reduce", "red", "full", "ful", "sys") & "' " &
        "data-build='" & gblBust & "'>" &
    "" &
    "" &
    ""
)

Three modes, three behaviours:

`gblMotionMode`	Class	Behaviour
`"system"` or empty	`sys`	the CSS decides, through the media query
`"reduce"`	`red`	motionless ring, whatever Windows says
`"full"`	`ful`	animation, whatever Windows says

Four design points deserve some explanation, because they are counter-intuitive:

The base state is static. .halo on its own carries no animation. The animation is added by .ful, or by .sys under the media query. This is the opposite of what one writes spontaneously (declare the animation, then cancel it with animation: none in a reduce block), and it is the opposite of what the halo in section 2 does. The inverted version is safer: if the CSS is not evaluated, if the class does not arrive, if gblMotionMode is empty, the result is the motionless ring. The safe behaviour becomes the default behaviour, while the animation is only enabled when explicitly asked for. To illustrate a principle, you want to see the cancellation; in production, you would rather a failure stay silent and harmless.

The Switch has a default case. Its last value, "sys", applies if gblMotionMode is empty, which is the state of a user who has never set anything. So the application's default behaviour is "follow the system". That is the right default, and it has to be chosen deliberately: a boolean If() written in haste would return Blank() on the else branch and give you exactly the opposite of what you wanted.

The descendant selector works because the root really is an ancestor of the . This point often causes confusion, but the behaviour here is entirely ordinary.

reduce does not mean "nothing". Note the stroke-width: 2 in animated mode, 2.5 in motionless mode. That is the rule from section 5, applied.

And on the Power Fx side:

Set(gblBust, GUID());
Set(
    gblMotionMode,
    Coalesce(
        LookUp(Preferences, User = User().Email, MotionMode),
        "system"
    )
)

A simple Radio or Dropdown with three options in your preferences screen, a Patch to your list, and you hand control to the user without ever forcing them to configure anything.

Pick a mode: the preview rebuilds itself exactly as gblMotionMode would in your own application.

"system" or empty Class sys: the CSS decides, through the media query. This is the default. "reduce" Class red: motionless ring, whatever Windows says. "full" Class ful: animation, whatever Windows says.

Part 4 of 5 · 11 min read

The proof

Everything above rests on a claim that had to be verified rather than believed. This is the longest part, and the easiest to skip: if you take my word for it, go straight to part 5. If, on the contrary, you want the test bench to paste into your own app, it is here.

7. "But does it really work?": the test bench

Everything above rests on one claim: the media query is evaluated inside an SVG image displayed by a PowerApps control. Here is how I verified it, and how you can verify it on your own hosts in thirty seconds.

The complete formula, to paste into the Image property of an Image control:

"data:image/svg+xml;utf8," & EncodeUrl(
    "" &
    "" &
    "" &
    "1. CSS engine: inactive" &
    "1. CSS engine: active" &
    "2. prefers-color-scheme: not evaluated" &
    "2. prefers-color-scheme: light" &
    "2. prefers-color-scheme: dark" &
    "3. prefers-reduced-motion: not evaluated" &
    "3. prefers-reduced-motion: no-preference" &
    "3. prefers-reduced-motion: reduce" &
    "build: " & gblBust & "" &
    ""
)

And in the app's OnStart (or the screen's OnVisible, or the OnSelect of a "Refresh" button):

Set(gblBust, Text(Now(), "[$-en-US]yyyymmddhhmmssfff"))

A timestamp rather than a GUID() here is deliberate: the bench displays that value at the bottom of the image, and reading the render time keeps you from drawing conclusions on a stale screen. In production, where it is invisible, GUID() does better, and section 8 explains why. As for the [$-en-US] prefix, it is not decorative either: section 10 is devoted to it.

The code looks like a slightly odd pile of CSS classes, but in reality each block answers a precise question of method.

7.1. The principle: three states, one of them "I do not know"

The whole trick rests on a design choice: each probe has a visible default state, meaning "not evaluated".

Take probe 3:

.c0, "not evaluated": opacity: 1 by default, so visible.
.c1, "no-preference": opacity: 0 by default, revealed only by the matching media query.
.c2, "reduce": likewise.

The three texts are stacked at exactly the same place (x='20' y='220'). Only one is visible at a time. The displayed text is the result.

Why this third state? Because without it, two radically different situations cannot be told apart:

the media query is supported and returns false;
the media query is not supported at all, or the CSS does not run.

In both cases, the screen would show nothing special. This is a negative control: without it, the experiment proves nothing. With it, a "not evaluated" left showing in red is usable information, not an ambiguous silence.

It is the same reflex as a unit test that must fail first, so you know it is really testing something.

7.2. Probe 1: the canary

@media (min-width:1px){.a0{opacity:0}.a1{opacity:1}}

This one tests no preference at all. min-width: 1px is true in every case where CSS is evaluated (the SVG is 600 px wide: for this condition, the browser goes by the width of the SVG itself, not that of the screen).

It is a canary. If "CSS engine: active" shows in green, we know that:

the data URI was decoded correctly;

the

`8. gblBust is not a test artefact`


This is by far the point that cost me the most time. It is in fact the reading mechanism itself.
The data URI is the image's URL. If the produced string is identical byte for byte, the browser returns the already decoded image from its memory cache. Yet it is at decoding time, and only then, that the SVG's media queries are evaluated. Unchanged string, no decoding. No decoding, no evaluation.
You change the setting in Windows, you come back to the app, you click everywhere... and nothing moves. Not because it does not work, but because nothing has been reloaded.
The data-build attribute is entirely inert: it has no effect on the rendering. Its only job is to make the string vary, hence the URL, hence to force a fresh decode and a fresh evaluation of the media queries. And the build: ... line shown at the bottom of our test bench is not cosmetic: it tells you which version you are actually looking at.
A direct consequence, and the one that makes the pattern usable in production:
Set(gblBust, GUID())
That line guarantees that at every session opening the data URI string is recreated, then decoded and evaluated against the current state of the system. So a user who has disabled animation effects in Windows automatically gets that setting honoured in your app, with no extra configuration.
It is the line announced in section 2, and the halo must therefore carry a data-build='" & gblBust & "' on its  tag too, exactly as the three-mode pattern in section 6 does.
In production the value is invisible and serves only to break the cache: GUID() guarantees a unique value without depending on the locale or on a date format. During testing, the timestamp was the relevant choice, since it was displayed.
A word on the real scope of that line. On a full page reload, a new document is created and images are decoded afresh anyway. gblBust is there to cover the other cases, which are numerous in an application: internal navigation, redisplaying a screen, coming back from another tab. It is one line of insurance.
9. The decoding lock
Here is the behaviour that surprises everyone, myself first, and that has a precise explanation.
Open the app so that the test bench shows no-preference, the square moves. Without closing the app, go into the Windows settings, disable animation effects, come back. The square is still moving.
It is not that the media query failed, it is that the image buffer was not repainted. Chromium has a filed bug for this, issue 1093736: SVG images are not repainted when media queries change. Rendering works most of the time, but it does not react if the preference flips mid-session. The documented workaround is exactly the one in section 8: force the repaint.
// "Re-read system preference" button, OnSelect
Set(gblBust, GUID())
So we have to be precise about what this pattern is and is not. It is not a stream, it is a snapshot. The SVG reads the preference at the moment it is decoded, and keeps that result until the next decode. Nothing notifies it of a change.
For the more curious among you! We have to go further still, because all of this leads to one question: if the SVG knows the preference, can we not make it tell us? So I tried, again and again. The Image control has a property the engine fills in itself, OriginalWidth, available with CalculateOriginalDimensions. The idea was to build an SVG whose width would depend on the media query: the value would have become a boolean in disguise, readable from Power Fx.
The canary gave me a clear no. With a media query true everywhere, @media (min-width:1px){svg{width:120px}}, the reported width never budged: 240 when the document declares width='240', and 300 when it declares nothing, that is, the browser's fallback size. Never 120, and the readings are rigorously identical whether Windows animation effects are on or off. The CSS is nonetheless very much evaluated, as section 7 proves; it simply plays no part in computing the size reported to the host. The engine returns what the document declares, never what it drew.
One detail of that attempt is worth keeping, because it can catch you out beyond this topic: between two decodes, OriginalWidth passes through 0. A naive reading such as width < 200 therefore returns true during that interval, while the image has not yet recovered its dimensions. That transient state can then be mistaken for a preference. To avoid it, first check that the width really is greater than 0: width > 0 And width < 200.
The conclusion is therefore sharper than the mere observation of a snapshot: the SVG obeys the preference, and the application will never know. No value crosses the border in that direction, neither through the Image control nor through the HTML Text control, whose HtmlText property merely returns the string your own formula produced. To get a genuine boolean into Power Fx, you need a code component (PCF) and its window.matchMedia.
This point can also be verified with the method presented in section 4. The demonstration fits on a single screen, in the published app: two  tags display the same SVG side by side, one with gblBust in its string and one without. You disable animations in Windows without closing the app, you trigger the bust, then you look at the result.



Route
Path taken by the CSS
Canary
Verdict read




A

Nelson Boruchowitch's blog