What it does

A set of control properties, app settings and a built-in checker that together decide whether someone using a screen reader, a keyboard only, or a high-contrast display can actually get through your app. The Accessibility checker lives in the App checker pane in Studio and grades findings as errors, warnings or tips.

Key facts

• The checker detects screen reader and keyboard issues. It does not check colour contrast — that's on you, with separate tooling.
• Microsoft's stated contrast target for text against its background is 4.5:1 or greater. The modern theming guidance references WCAG 2.1 AA as the minimum bar to test against.
• AccessibleLabel is what the screen reader announces. On a decorative image it should be empty or unset; on an image used as a button it should describe the action, with TabIndex set to 0.
• TabIndex should be 0 or -1. Anything greater than 0 is a documented tip-level finding and is described as hard to get right and capable of breaking screen readers. The Simplified tab index app setting should be on.
• Verified screen reader and browser combinations: JAWS on Edge, Narrator on Edge, NVDA on Chrome and Firefox, TalkBack on Chrome and Power Apps mobile, VoiceOver on Power Apps mobile and Safari.
• Each screen should have at least one heading, created by setting the Role property on a Label. Interactive text should be a Button, not a Label.
• The Video control supports closed captions through ClosedCaptionsUrl in WebVTT format. The Timer control announces elapsed time to screen readers and that can't be turned off, even when the timer is hidden by opacity.
• HTML placed in any control other than the HTML text control isn't accessible, and interactive HTML elements aren't supported.
• Modern controls are described by Microsoft as having improved accessibility over classic controls.

When to use / skip

There's no skip. Public sector, education, healthcare and most large enterprises in the UK and EU have procurement rules that make this contractual, and even where they don't, a keyboard-only path is what saves you when someone's mouse breaks in a warehouse. What you can scope is depth: running the checker and fixing every error is a day; a genuine assistive-technology test pass with real users is a workstream. Be clear which one you sold.

Configuration decisions

• Which conformance level the client is actually committing to, and whether that's written into the contract or assumed.
• Whether the checker running clean is the definition of done, or whether manual keyboard and screen reader passes are in scope.
• How pen and signature capture is handled, since PenInput needs a typed alternative and the instructions belong in AccessibleLabel.
• Whether decorative images get an empty AccessibleLabel or are given a description nobody wants read out.
• Whether accessibility review is a gate on release or a backlog item, because in practice it becomes whichever one you set up first.

Gotchas

• The checker passing means the checker's rules passed. Colour contrast, reading order sense, and whether the labels are meaningful rather than merely present are all outside it.
• Someone will set TabIndex to positive numbers to "fix" the tab order. It works in the browser they tested and breaks in the next one. Use containers and layout order instead.
• Galleries scope TabIndex internally — controls outside the gallery aren't part of the navigation order inside it. Keyboard testing needs to happen inside galleries specifically.
• A Timer with low opacity is still announcing to screen readers. This catches people who use timers as background schedulers on visible screens.
• FocusedBorderThickness set to 0 removes the visible focus indicator. It looks tidier and it's a checker error for good reason.

Consultant notes

• Run the checker in front of the client early, on a rough screen. It reframes accessibility as a normal part of building rather than a compliance ambush at UAT.
• If the client names a standard in the tender, get the exact wording. "WCAG 2.1 AA" and "accessible" are very different commitments and the second one is unbounded.
• Microsoft publishes accessibility conformance reports for Power Apps as a product. Those cover the platform, not the app you built on it — make sure the client understands the difference before they cite one.
• Colour contrast is the one that fails at the last minute, because it comes from the brand palette and marketing owns that. Test the theme against contrast requirements before screens get signed off.

---

Worth rechecking whenever the modern control set changes — accessibility properties have already moved once.