Making Power Apps accessible: lessons from a WCAG 2.x AA remediation
Most accessibility problems in canvas apps and Power Pages come from a handful of settings nobody fills in. Here's what we fixed, in the order we'd fix it again.
I recently worked on bringing a set of canvas apps and Power Pages sites in line with Section 508 and WCAG 2.x AA. The apps worked well for most users. For someone using a screen reader or a keyboard only, several of them were close to unusable.
The good news is that the Power Platform gives you most of what you need. The fixes were rarely about rebuilding. They were about properties that were left blank, colors picked by eye, and screens nobody had tried to use without a mouse.
Why it matters beyond compliance: the Revised Section 508 Standards point to WCAG 2.0 AA, so any app used by or sold to U.S. federal agencies needs to meet it. Many state and local governments, universities and large enterprises now require it too. And every fix below also makes the app easier for everyone else.
1. Give every control a name
Screen readers announce controls by their AccessibleLabel property. When it's blank, users hear "button" or "image" and have to guess. This was the single most common issue we found.
- Icons and image buttons: set
AccessibleLabelto the action, such as "Delete request" or "Open filters", not the icon name. - Decorative images: leave
AccessibleLabelempty so the screen reader skips them. - Inputs: a visible label next to a text box isn't automatically linked to it. Set the input's
AccessibleLabelto match the visible text. - Galleries: label the gallery itself ("Open requests") and make each item's label meaningful, for example
"Request " & ThisItem.Title & ", status " & ThisItem.Status.
2. Fix the focus order
Keyboard users move with Tab, so the order has to follow the screen's visual layout. In canvas apps, focus follows the order controls appear on the screen, from top-left to bottom-right, and TabIndex controls whether a control can receive focus.
- Use
TabIndexof0for interactive controls and-1for things that shouldn't take focus. Avoid values above 0; they create jumpy, hard-to-maintain orders. - If focus order is wrong, fix the layout (containers help a lot) rather than fighting it with numbers.
- Make sure focus is visible. Check
FocusedBorderThicknessandFocusedBorderColoron buttons and inputs, since some themes set them too faint to see. - When a dialog or panel opens, move focus into it with
SetFocus(), and back to the triggering control when it closes.
3. Meet contrast ratios with numbers, not eyes
WCAG AA needs a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text and for UI components like input borders and icons. Brand colors often fail, especially light greys for placeholder text and pale button colors.
| Element | Minimum ratio | Common failure |
|---|---|---|
| Body text, labels | 4.5:1 | Grey text on white |
| Large text (18pt, or 14pt bold) | 3:1 | Colored headers on colored bars |
| Input borders, icons, focus rings | 3:1 | Very light borders on text boxes |
| Disabled controls | Exempt | But make sure they don't look enabled |
We put approved colors in named variables or a theme so nobody had to guess, and we never used color alone to show status. A red "Overdue" badge also says "Overdue".
4. Add structure: headings and live regions
Screen reader users navigate by headings. On labels that act as headings, set the Role property to Heading1 through Heading4 so the screen has a real outline.
When something changes without a page load, such as a "Saved" message or a validation error, set that label's Live property to Polite (or Assertive for errors that block the user). Otherwise the screen reader never announces it.
5. Power Pages: protect what the templates give you
Power Pages starts from accessible templates, and most problems we found were introduced by customization:
- Custom CSS that removed focus outlines or lowered contrast.
- Heading levels chosen for size instead of structure, like jumping from H1 to H4.
- Custom HTML and Liquid blocks with images missing alt text or links that just say "click here".
- Form fields relying on placeholder text instead of real labels, and error messages that weren't tied to the field.
Every time you change the theme or add a custom block, re-test that page. That habit prevents most regressions.
6. Test the way your users actually work
Automated tools catch only part of the problems. We used three layers:
- App checker in Power Apps Studio. Its accessibility section flags missing labels, focus issues and more. Clear it on every screen before anything else.
- Accessibility Insights for Web (free, from Microsoft) for Power Pages and for canvas apps running in the browser.
- Manual testing: unplug the mouse and complete each key task with the keyboard, then do it again with a screen reader such as Narrator, NVDA or JAWS. This is where the real issues show up.
If you can, include a user who relies on assistive technology in UAT. Nothing else gives you the same feedback.
A short checklist to start with
- Every interactive control has a meaningful
AccessibleLabel. - Decorative images have an empty label.
- Tab order follows the visual layout, and focus is always visible.
- Text and UI colors meet 4.5:1 and 3:1.
- Headings use the
Roleproperty, and status messages useLive. - App checker is clean, and each key task works with keyboard and screen reader.
Accessibility is far cheaper to build in than to retrofit. If you set these properties as you build each screen, you'll rarely need a remediation project at all.