8.2 Designing for Accessibility, Performance, Responsiveness, and Usability

AB-410 treats accessibility as a design requirement, not an afterthought. Canvas apps run on touchscreens, keyboards, and assistive technologies, so the exam expects you to know both the tooling and the properties that make an app usable by everyone.

The Accessibility Checker

Power Apps Studio ships a built-in Accessibility checker — open the App checker (the stethoscope icon) and choose Accessibility. It lists issues such as missing accessible labels, missing captions on media, color-contrast problems, and controls unreachable by keyboard. Run it before every publish; it cannot catch everything, but it catches the mechanical mistakes the exam likes to test.

Properties and Patterns That Matter

• AccessibleLabel — every interactive control (buttons, icons, text inputs) needs a short, meaningful label. An icon-only + button should announce "New record", not silence. Screen readers speak this label aloud.
• Tab order — keyboard users move with the Tab key. Keep TabIndex at 0 (participates in tab order) or -1 (skipped). Avoid positive TabIndex values: the recommended pattern is a logical visual layout, not hand-numbered tab stops. Auto-layout containers compute a sensible tab order for free.
• Keyboard navigation — every action must be reachable without a mouse, including moving between items inside a gallery and opening dialogs.
• Color contrast — text should meet a contrast ratio of at least 4.5:1 against its background (WCAG AA). Never convey meaning by color alone; pair the red error indicator with text or an icon.
• Meaningful screen names — screen readers announce the screen name on navigation, so OrderListScreen beats Screen1.
• Media — video needs closed captions, audio needs transcripts, and images that carry meaning need alternative text.
• Keyboard activation — buttons and icons must respond to Enter and Space, and focus indicators must remain visible; do not strip focus styling for aesthetics.

Canvas apps work with platform screen readers — Narrator on Windows, VoiceOver on iOS and macOS, TalkBack on Android, and common desktop readers such as JAWS and NVDA — but only when labels, tab order, and contrast are done right.

Scenario

A field-inspection app shows status as a green or red dot with no text. A color-blind inspector cannot tell the states apart, and a screen reader announces nothing at all. The fix combines an AccessibleLabel on the icon, a written status value next to it, and contrast-checked colors — exactly the class of issues the Accessibility checker guides you through.

Performance: Delegation First

Delegation means Power Apps pushes a query (filter, sort, search) down to the data source to execute. When a formula is non-delegable, the app pulls data to the device and processes it locally — but only up to the data row limit: 500 rows by default, configurable from 1 to 2,000 under Settings > General. A non-delegable filter over a 50,000-row Dataverse table silently scans only the first 500 rows and returns incomplete, wrong-looking results.

For Dataverse, common delegable functions include Filter, LookUp, Search, Sort and SortByColumns, StartsWith, and comparisons such as =, <>, >. String functions like Mid, Len, and Lower, and functions like Choices and Concat, are not delegable. Studio flags these with a yellow triangle on the control and a blue underline in the formula bar — treat them as build errors on the exam.

Other high-value performance practices:

• Concurrent — run independent loads in parallel in App.OnStart: Concurrent(Set(varUser, User()), ClearCollect(colConfig, Config)).
• Keep OnStart light — heavy OnStart logic delays the first screen; use App.StartScreen for navigation instead of Navigate chains, and defer noncritical loads (delayed load).
• Explicit column selection — the setting under Settings > General fetches only the columns the app actually uses, shrinking payloads from wide tables.
• Avoid N+1 calls — a LookUp inside a gallery template fires once per row; restructure with ThisItem, AddColumns, or a Dataverse view instead.
• Measure, don't guess — use Monitor (available from the studio) to watch network calls, row counts, and durations in real time. Chapter 10.1 covers Monitor in depth.

Two more limits the exam likes: keep a screen near 500 controls or fewer (control count, not data volume, is what slows rendering), and remember that collections and context variables live in memory — they never delegate, so the data row limit applies to anything loaded into them. Cache small reference lists (statuses, categories) in a collection once rather than re-querying the source on every screen, and compress large images before embedding them.

Responsive Design

A responsive app adapts to phone, tablet, and browser sizes instead of scaling one fixed canvas:

1. Turn Scale to fit off (Settings > Display). With it on, the app letterboxes and never reflows.
2. Lay out screens with horizontal and vertical containers — auto-layout controls that arrange children by direction, gap, and alignment without X/Y coordinate math.
3. Size controls relative to Parent.Width and Parent.Height, using flexible width/height and Fill portions inside containers.

Usability Patterns

• Navigation — consistent back buttons and clear destinations with Navigate(HomeScreen, ScreenTransition.Fade).
• Loading feedback — show a spinner or progress while data loads so the app never looks frozen.
• Consistent theming — prefer modern controls, which take colors and fonts from a central theme rather than hand-styling every classic control. AB-410 expects awareness that modern theming exists and centralizes styles, not deep property-level knowledge.